Windows 2008 R2 64 bit V2V conversion fails with “Unable to determine Guest Operating System” error

Windows 2008 R2 64 bit V2V conversion fails with the below error:

 

 

 

 

 

 

 

 

 

The V2V was across the VC with both the source and destination (vCenter and ESXi) being on 4.0 U2 and VMware convertor running on 4.0.1 Build -161434

Resolution: Just change the guest OS type (Right Click the VM> Edit Settings> Options tab)  to anything below 2008 R2 on the source machine and the V2V should go through fine

Thanks to: http://wiert.me/2010/06/10/vmware-converter-4-01-unable-to-obtain-hardware-information-or-unable-to-determine-guest-operating-system/

Advertisements

Storage Hardware Acceleration

Hardware Acceleration helps ESXi to offload the Storage and Virtual Machine operations to Storage Hardware, thus consuming less CPU, Memory and Storage Bandwidth. It’s supported by Blocked storage devices, SAN, iSCSI and NAS devices

Can view the status in the Hardware Acceleration column of Devices View and datastore view in vSphere Client

vSphere uses ESXi extensions referred to as Storage API’s – Array Integration (formerly known as VAAI). With the release of vSphere 5, these extensions are implemented as T10 SCSI based commands else the ESXi reverts to using the VAAI Plug in’s

With Hardware Acceleration, host can get hardware assistance on:

–          Storage vMotion

–          Cloning/Deploying VM’s from Template

–          VMFS file locking, Atomic Test Set (ATS) (no use of SCSI Reservations)

–          Writes to Thin and Thick provisioned disks

–          Creating/Cloning thick disks on NAS devices

Hardware Acceleration on NAS Devices is implemented through vendor-specific NAS plug-ins and no claim rules are required

–          File clone; this is similar to VMFS block cloning, except NAS clones entire files instead of file segments

–          Create Thick disks

–          Accurately report Space Utilization for Virtual Machines

Hardware Acceleration Considerations

The VMFS data mover does not leverage hardware offloads and instead uses software data movement when one of the following occurs:

–          The source and destination VMFS datastores have different block sizes.

–          The source file type is RDM and the destination file type is non-RDM (regular file).

–          The source VMDK type is eagerzeroedthick and the destination VMDK type is thin.

–          The source or destination VMDK is in sparse or hosted format.

–          The source virtual machine has a snapshot.

–          The logical address and transfer length in the requested operation are not aligned to the minimum alignment required by the storage device. All datastores created with the vSphere Client are aligned automatically.

–          The VMFS has multiple LUNs or extents, and they are on different arrays.

Some quick Command lines:

Display Hardware Acceleration Plug-Ins and Filter

esxcli –server=server_name storage core plugin list –plugin-class=value (Filter or VAAI)

Verify Hardware Acceleration Support Status

esxcli –server=server_name storage core device list -d=device_ID

Verify Hardware Acceleration Support Details

esxcli –server=server_name storage core device vaai status get -d=device_ID

List Hardware Acceleration Claim Rules

esxcli –server=server_name storage core claimrule list –claimrule-class=value (Filter or VAAI)

Add Hardware Acceleration Claim Rules, only for Storage Devices that do not support T10 SCSI Commands

esxcli –server=server_name storage core claimrule add –claimrule-class=Filter –plugin=VAAI_FILTER

esxcli –server=server_name storage core claimrule add –claimrule-class=VAAI

esxcli –server=server_name storage core claimrule load –claimrule-class=Filter

esxcli –server=server_name storage core claimrule load –claimrule-class=VAAI

esxcli –server=server_name storage core claimrule run –claimrule-class=Filter

Verify Hardware Acceleration Status for NAS, will require you to install the NAS Plug-ins using VIB’s

esxcli –server=server_name storage nfs list

**END**