Tuesday, March 3, 2009

VMotion CPU Compatibility Requirements for Intel Processors

VMotion CPU Compatibility Requirements for Intel Processors
KB Article 1991
Updated Feb. 04, 2009
Products
VMware ESX
VMware ESXi
VMware VirtualCenter
Details

Why am I unable to migrate virtual machines with VMotion across Intel processors?


Solution

To ensure production-system stability during migration with VMotion, VirtualCenter requires the source and target CPUs to be compatible, as defined in these documents:

If the source and target CPUs are incompatible for VMotion, you can:

  • Perform a cold migration (rather than a VMotion migration), thereby removing VMotion CPU requirements as an issue.
  • Remove VMotion compatibility constraints by modifying the default bit-mask used by VirtualCenter. Note that some modifications discussed in this knowledge base article are neither supported nor recommended by VMware for production environments. In general, any CPU feature (or extended feature) that circumvents the virtualization layer (such as SSE3) is not supported for VMotion.
Here are some resources that can help you obtain information about a host system's CPU:
  • VMware's ESX Server 3.x CD-ROM includes an ISO image file (\images\cpuid.iso.gz ) that can be uncompressed and used to create a bootable CD-ROM that provides CPU information about a given host prior to operating system (or ESX Server) installation. If you have questions about obtaining or using this tool, contact VMware Technical Support.
  • Intel's processor identification utility, which can be obtained from Intel at:
    http://www.intel.com/support/processors/tools/piu/
This knowledge base article discusses VMotion compatibility constraints for Intel CPUs. For detailed information about how to apply the masks discussed in this article, see knowledge base article 1993, "Migrations with VMotion Prevented Due to CPU Mismatch—How to Override Masks." 
 

VMotion Compatibility Groups for Intel Processors

To guarantee successful migrations with VMotion, VMware has defined several compatibility groups based on processor family (Pentium 4, Core) and implementation of SSE3 and SSSE3 instructions.

By default, VirtualCenter supports VMotion migrations within each CPU compatibility group. For example, migration within group A is allowed, but migration from group A to group B or from group B to group C is not, as shown in the tables.

Intel Pentium 4 CPU Family

VMotion CPU Compatibility Group CPU Details

 

 ESX Server 3.x

 

ESX Server 2.x
 
 
 
 
 
 
 
 
Group A
Without SSE3, without XD (eXecute Disable) bit.
Models include:
  • Early Intel P4s prior to Model 3, Stepping 1.
    For example, Willamette and Northwood.
  • Early Xeon and Xeon MP CPUs (prior to Nocona, Q3 2004).
    For example, Foster, Prestonia, and Gallatin.
 
 
 
For A <-> B VMotion, apply SSE3 mask (not supported).




 

 

 

 

 

 

For A <-> B VMotion, apply SSE3 mask (not supported). 

 
 
 
 
 
 
Group B
(Group B and C are the same for VC 1.x)

 
With SSE3, without XD (eXecute Disable) bit.
Models include:
  • P4s from Model 3, Stepping 1 onward (introduced in early 2004).
    For example, Prescott, or numbered 5x0, 5x5, 5x9.
  • Xeon with 64-bit (EM64T) enabled.
    For example, Nocona.

 

 
 
 
 
 
For B <-> C VMotion, apply NX mask (supported).


 
 
 
 
 
 
 
 
 
Group C
(Group B and C are the same for VC 1.x)

 
With SSE3 and XD (eXecute Disable) bit.
Models include:
  • P4s from Model 3, Stepping 1 onward (introduced in early 2004).
    For example, Prescott, or numbered 5x0j, 5x5j, 5x9j.
  • P4s with 64 bit (EM64T) enabled.
    For example, Prescott 2M, Cedar Mill, or numbered 5x1, 5x6, 6x0, 6x1, 6x2.
  • P4s with dual-core (marketed as Pentium D).
    For example, Smithfield, Pressler, or numbered 8x0.
  • Xeon and Xeon MP with 64-bit (EM64T) enabled.
    For example, Irwindale, Cranford, and Potomac.Xeon and Xeon MP.
    For example, Paxville, Dempsey, and Tulsa, or numbered 50xx, 70xx, and 71xx.

 

Intel Core CPU Family

VMotion CPU Compatibility Group

CPU Details

ESX Server 3.x

ESX Server 2.x

 

Group A

Without SSSE3.

Models include:

Dual-core Xeon LV based on Intel Core Microarchitecture.
For example, Sossaman.

For A <-> B VMotion, apply SSSE3 mask (not supported).

For A <-> B VMotion, apply SSSE3 mask (not supported).

Group B

With SSSE3.

Models include:

Intel Dual-core Xeon family based on Intel Core Microarchitecture.
For example, Woodcrest, Clovertown, or numbered 51xx.

For B <-> C VMotion, apply SSE4.1 mask (not supported)

For B <-> C VMotion, apply SSE4.1 mask (not supported)

Group C

With SSE4.1

Models include:

Penryn-based CPUs, for example Harpertown, Wolfdale

 

Applying the Masks

For information about how to apply masks referenced in the tables, see the appropriate sections in the "Migrations with VMotion Prevented Due to CPU Mismatch—How to Override Masks" (KB 1993 http://kb.vmware.com/kb/1993), as follows: 

  • For VirtualCenter 1.x masks, see Modifying the Default Bit Mask.
  • For VirtualCenter 2.x masks, see Modifying the Default Mask. 
Note that for production environments, VMware neither supports nor recommends modifying VMotion masks for SSE3, SSSE3, or SSE4.1 because of the risk of failure of the application or guest operating system after migration.
 

VMotion Between Single-Core and Multi-Core Processors

Support for dual-core processors was introduced in VirtualCenter version 1.3.0 and ESX Server version 2.5.2 (not shown in table above). Migrations between some single-core and multi-core Intel processors are supported, as long as the source and target CPUs have compatible CPU features (or the features are masked) as outlined in the tables above.

For More Information

For more information about the Intel Pentium 4 CPU family, go to:

For more information about the Intel Core CPU family, go to:
 
For more information about SSE3, SSSE3, and SSE4, go to:
 
 
Note: Knowledge base articles 1991, 1992, and 1993 replace article 1377.
 
 

Product Versions
VMware ESX 2.5.x
VMware ESX 3.0.x
VMware ESX 3.5.x
VMware VirtualCenter 1.3.x
VMware VirtualCenter 1.4.x
VMware VirtualCenter 2.0.x
VMware VirtualCenter 2.5.x
No comments:
Labels: ,

VMotion CPU Compatibility Requirements for Intel Processors

VMotion CPU Compatibility Requirements for Intel Processors
KB Article 1991
Updated Feb. 04, 2009
Products
VMware ESX
VMware ESXi
VMware VirtualCenter
Details

Why am I unable to migrate virtual machines with VMotion across Intel processors?


Solution

To ensure production-system stability during migration with VMotion, VirtualCenter requires the source and target CPUs to be compatible, as defined in these documents:

If the source and target CPUs are incompatible for VMotion, you can:

  • Perform a cold migration (rather than a VMotion migration), thereby removing VMotion CPU requirements as an issue.
  • Remove VMotion compatibility constraints by modifying the default bit-mask used by VirtualCenter. Note that some modifications discussed in this knowledge base article are neither supported nor recommended by VMware for production environments. In general, any CPU feature (or extended feature) that circumvents the virtualization layer (such as SSE3) is not supported for VMotion.
Here are some resources that can help you obtain information about a host system's CPU:
  • VMware's ESX Server 3.x CD-ROM includes an ISO image file (\images\cpuid.iso.gz ) that can be uncompressed and used to create a bootable CD-ROM that provides CPU information about a given host prior to operating system (or ESX Server) installation. If you have questions about obtaining or using this tool, contact VMware Technical Support.
  • Intel's processor identification utility, which can be obtained from Intel at:
    http://www.intel.com/support/processors/tools/piu/
This knowledge base article discusses VMotion compatibility constraints for Intel CPUs. For detailed information about how to apply the masks discussed in this article, see knowledge base article 1993, "Migrations with VMotion Prevented Due to CPU Mismatch—How to Override Masks." 
 

VMotion Compatibility Groups for Intel Processors

To guarantee successful migrations with VMotion, VMware has defined several compatibility groups based on processor family (Pentium 4, Core) and implementation of SSE3 and SSSE3 instructions.

By default, VirtualCenter supports VMotion migrations within each CPU compatibility group. For example, migration within group A is allowed, but migration from group A to group B or from group B to group C is not, as shown in the tables.

Intel Pentium 4 CPU Family

VMotion CPU Compatibility Group CPU Details

 

 ESX Server 3.x

 

ESX Server 2.x
 
 
 
 
 
 
 
 
Group A
Without SSE3, without XD (eXecute Disable) bit.
Models include:
  • Early Intel P4s prior to Model 3, Stepping 1.
    For example, Willamette and Northwood.
  • Early Xeon and Xeon MP CPUs (prior to Nocona, Q3 2004).
    For example, Foster, Prestonia, and Gallatin.
 
 
 
For A <-> B VMotion, apply SSE3 mask (not supported).




 

 

 

 

 

 

For A <-> B VMotion, apply SSE3 mask (not supported). 

 
 
 
 
 
 
Group B
(Group B and C are the same for VC 1.x)

 
With SSE3, without XD (eXecute Disable) bit.
Models include:
  • P4s from Model 3, Stepping 1 onward (introduced in early 2004).
    For example, Prescott, or numbered 5x0, 5x5, 5x9.
  • Xeon with 64-bit (EM64T) enabled.
    For example, Nocona.

 

 
 
 
 
 
For B <-> C VMotion, apply NX mask (supported).


 
 
 
 
 
 
 
 
 
Group C
(Group B and C are the same for VC 1.x)

 
With SSE3 and XD (eXecute Disable) bit.
Models include:
  • P4s from Model 3, Stepping 1 onward (introduced in early 2004).
    For example, Prescott, or numbered 5x0j, 5x5j, 5x9j.
  • P4s with 64 bit (EM64T) enabled.
    For example, Prescott 2M, Cedar Mill, or numbered 5x1, 5x6, 6x0, 6x1, 6x2.
  • P4s with dual-core (marketed as Pentium D).
    For example, Smithfield, Pressler, or numbered 8x0.
  • Xeon and Xeon MP with 64-bit (EM64T) enabled.
    For example, Irwindale, Cranford, and Potomac.Xeon and Xeon MP.
    For example, Paxville, Dempsey, and Tulsa, or numbered 50xx, 70xx, and 71xx.

 

Intel Core CPU Family

VMotion CPU Compatibility Group

CPU Details

ESX Server 3.x

ESX Server 2.x

 

Group A

Without SSSE3.

Models include:

Dual-core Xeon LV based on Intel Core Microarchitecture.
For example, Sossaman.

For A <-> B VMotion, apply SSSE3 mask (not supported).

For A <-> B VMotion, apply SSSE3 mask (not supported).

Group B

With SSSE3.

Models include:

Intel Dual-core Xeon family based on Intel Core Microarchitecture.
For example, Woodcrest, Clovertown, or numbered 51xx.

For B <-> C VMotion, apply SSE4.1 mask (not supported)

For B <-> C VMotion, apply SSE4.1 mask (not supported)

Group C

With SSE4.1

Models include:

Penryn-based CPUs, for example Harpertown, Wolfdale

 

Applying the Masks

For information about how to apply masks referenced in the tables, see the appropriate sections in the "Migrations with VMotion Prevented Due to CPU Mismatch—How to Override Masks" (KB 1993 http://kb.vmware.com/kb/1993), as follows: 

  • For VirtualCenter 1.x masks, see Modifying the Default Bit Mask.
  • For VirtualCenter 2.x masks, see Modifying the Default Mask. 
Note that for production environments, VMware neither supports nor recommends modifying VMotion masks for SSE3, SSSE3, or SSE4.1 because of the risk of failure of the application or guest operating system after migration.
 

VMotion Between Single-Core and Multi-Core Processors

Support for dual-core processors was introduced in VirtualCenter version 1.3.0 and ESX Server version 2.5.2 (not shown in table above). Migrations between some single-core and multi-core Intel processors are supported, as long as the source and target CPUs have compatible CPU features (or the features are masked) as outlined in the tables above.

For More Information

For more information about the Intel Pentium 4 CPU family, go to:

For more information about the Intel Core CPU family, go to:
 
For more information about SSE3, SSSE3, and SSE4, go to:
 
 
Note: Knowledge base articles 1991, 1992, and 1993 replace article 1377.
 
 

Product Versions
VMware ESX 2.5.x
VMware ESX 3.0.x
VMware ESX 3.5.x
VMware VirtualCenter 1.3.x
VMware VirtualCenter 1.4.x
VMware VirtualCenter 2.0.x
VMware VirtualCenter 2.5.x
No comments:
Labels:

VMware ESX and ESXi 3.5 U3 I/O failure on SAN LUN(s) and LUN queue is blocked indefinitely

VMware ESX and ESXi 3.5 U3 I/O failure on SAN LUN(s) and LUN queue is blocked indefinitely
KB Article 1008130
Updated Jan. 30, 2009
Products
VMware ESX
Product Versions
VMware ESX 3.5.x
VMware ESXi 3.5.x Embedded
VMware ESXi 3.5.x Installable
Symptoms

One or more of the following may be present:

  • VMware ESX or ESXi host might get disconnected from VirtualCenter.
     
  • All paths to the LUNs are in standby state.
     
  • esxcfg-rescan might take a long time to complete or never completes (hung).
     
  • Error messages matching this pattern are repeated continually in vmkernel:
    <date and time> <hostname> vmkernel: <server uptime> cpu6:1177)SCSI: 675: Queue for device vml.<Vol. Dev. ID> has been blocked for 7 seconds.
    <date and time> <hostname> vmkernel: <server uptime> cpu7:1184)SCSI: 675: Queue for device vml.<Vol. Dev. ID> has been blocked for 6399 seconds.
     
    If you look at log entries previous to the first blocked message, you will see storage events and a failover attempt.
    Example:
    <date and time> <hostname> vmkernel: 31:19:32:26.199 cpu3:3824)Fil3: 5004:  READ error 0xbad00e5
    <date and time> <hostname> vmkernel: 31:19:32:29.224 cpu1:3961)StorageMonitor: 196: vmhba0:0:0:0 status = 0/5 0x0 0x0 0x0
    <date and time> <hostname> vmkernel: 31:19:32:29.382 cpu2:1144)FS3: 5034: Waiting for timed-out heartbeat [HB state abcdef02 offset 3736576 gen 26 stamp 2748610023852 uuid 4939b0cf-c85aa695-158d-00144f021dd4 jrnl <FB 383397> drv 4.31]
    <date and time> <hostname> vmkernel: 31:19:32:29.638 cpu3:1053)<6>qla2xxx_eh_device_reset(1): device reset failed
    <date and time> <hostname> vmkernel: 31:19:32:29.638 cpu3:1053)WARNING: SCSI: 4279: Reset during HBA failover on vmhba1:2:1 returns Failure
    <date and time> <hostname> vmkernel: 31:19:32:29.638 cpu3:1053)WARNING: SCSI: 3746: Could not switchover to vmhba1:2:1. Check Unit Ready Command returned an error instead of NOT READY for standby controller .
    <date and time> <hostname> vmkernel: 31:19:32:29.638 cpu3:1053)WARNING: SCSI: 4622: Manual switchover to vmhba1:2:1 completed unsuccessfully.
    <date and time> <hostname> vmkernel: 31:19:32:29.638 cpu3:1053)StorageMonitor: 196: vmhba0:2:1:0 status = 0/1 0x0 0x0 0x0
    <date and time> <hostname> vmkernel: 31:19:32:29.640 cpu2:1067)scsi(1): Waiting for LIP to complete...
    <date and time> <hostname> vmkernel: 31:19:32:29.640 cpu2:1067)<6>qla2x00_fw_ready ha_dev_f=0xc
    <date and time> <hostname> vmkernel: 31:19:32:30.532 cpu2:1026)StorageMonitor: 196: vmhba0:0:0:0 status = 0/2 0x0 0x0 0x0
    <date and time> <hostname> last message repeated 31 times
    <date and time> <hostname> vmkernel: 31:19:32:31.535 cpu2:1067)<6>dpc1 port login OK: logged in ID 0x81
    <date and time> <hostname> vmkernel: 31:19:32:31.541 cpu2:1067)<6>dpc1 port login OK: logged in ID 0x82
    <date and time> <hostname> vmkernel: 31:19:32:31.547 cpu2:1067)<6>dpc1 port login OK: logged in ID 0x83
    <date and time> <hostname> vmkernel: 31:19:32:31.568 cpu2:1067)<6>dpc1 port login OK: logged in ID 0x84
    <date and time> <hostname> vmkernel: 31:19:32:31.573 cpu2:1067)<6>dpc1 port login OK: logged in ID 0x85
    <date and time> <hostname> vmkernel: 31:19:32:31.576 cpu2:1067)<6>dpc1 port login OK: logged in ID 0x86
    <date and time> <hostname> vmkernel: 31:19:32:32.531 cpu2:4267)StorageMonitor: 196: vmhba0:0:0:0 status = 0/2 0x0 0x0 0x0
    <date and time> <hostname> last message repeated 31 times
    <date and time> <hostname> vmkernel: 31:19:32:32.532 cpu1:3973)StorageMonitor: 196: vmhba0:0:0:0 status = 2/0 0x6 0x29 0x0


Resolution
This issue can occur on VMware ESX servers under the following conditions:
  • Hypervisor version: VMware ESX 3.5 U3.
  • SAN hardware: Active/Passive and Active/Active arrays (Fibre Channel and iSCSI).
  • Trigger: This occurs when VMFS3 metadata updates are being done at the same time failover to an alternate path occurs for the LUN on which the VMFS3 volume resides .
A reboot is required to clear this condition.
 
Note: This issue is resolved in the following patches, released Jan. 30, 2009:

No comments:
Labels: ,

VMware ESX and ESXi 3.5 U3 I/O failure on SAN LUN(s) and LUN queue is blocked indefinitely

VMware ESX and ESXi 3.5 U3 I/O failure on SAN LUN(s) and LUN queue is blocked indefinitely
KB Article 1008130
Updated Jan. 30, 2009
Products
VMware ESX
Product Versions
VMware ESX 3.5.x
VMware ESXi 3.5.x Embedded
VMware ESXi 3.5.x Installable
Symptoms

One or more of the following may be present:

  • VMware ESX or ESXi host might get disconnected from VirtualCenter.
     
  • All paths to the LUNs are in standby state.
     
  • esxcfg-rescan might take a long time to complete or never completes (hung).
     
  • Error messages matching this pattern are repeated continually in vmkernel:
    <date and time> <hostname> vmkernel: <server uptime> cpu6:1177)SCSI: 675: Queue for device vml.<Vol. Dev. ID> has been blocked for 7 seconds.
    <date and time> <hostname> vmkernel: <server uptime> cpu7:1184)SCSI: 675: Queue for device vml.<Vol. Dev. ID> has been blocked for 6399 seconds.
     
    If you look at log entries previous to the first blocked message, you will see storage events and a failover attempt.
    Example:
    <date and time> <hostname> vmkernel: 31:19:32:26.199 cpu3:3824)Fil3: 5004:  READ error 0xbad00e5
    <date and time> <hostname> vmkernel: 31:19:32:29.224 cpu1:3961)StorageMonitor: 196: vmhba0:0:0:0 status = 0/5 0x0 0x0 0x0
    <date and time> <hostname> vmkernel: 31:19:32:29.382 cpu2:1144)FS3: 5034: Waiting for timed-out heartbeat [HB state abcdef02 offset 3736576 gen 26 stamp 2748610023852 uuid 4939b0cf-c85aa695-158d-00144f021dd4 jrnl <FB 383397> drv 4.31]
    <date and time> <hostname> vmkernel: 31:19:32:29.638 cpu3:1053)<6>qla2xxx_eh_device_reset(1): device reset failed
    <date and time> <hostname> vmkernel: 31:19:32:29.638 cpu3:1053)WARNING: SCSI: 4279: Reset during HBA failover on vmhba1:2:1 returns Failure
    <date and time> <hostname> vmkernel: 31:19:32:29.638 cpu3:1053)WARNING: SCSI: 3746: Could not switchover to vmhba1:2:1. Check Unit Ready Command returned an error instead of NOT READY for standby controller .
    <date and time> <hostname> vmkernel: 31:19:32:29.638 cpu3:1053)WARNING: SCSI: 4622: Manual switchover to vmhba1:2:1 completed unsuccessfully.
    <date and time> <hostname> vmkernel: 31:19:32:29.638 cpu3:1053)StorageMonitor: 196: vmhba0:2:1:0 status = 0/1 0x0 0x0 0x0
    <date and time> <hostname> vmkernel: 31:19:32:29.640 cpu2:1067)scsi(1): Waiting for LIP to complete...
    <date and time> <hostname> vmkernel: 31:19:32:29.640 cpu2:1067)<6>qla2x00_fw_ready ha_dev_f=0xc
    <date and time> <hostname> vmkernel: 31:19:32:30.532 cpu2:1026)StorageMonitor: 196: vmhba0:0:0:0 status = 0/2 0x0 0x0 0x0
    <date and time> <hostname> last message repeated 31 times
    <date and time> <hostname> vmkernel: 31:19:32:31.535 cpu2:1067)<6>dpc1 port login OK: logged in ID 0x81
    <date and time> <hostname> vmkernel: 31:19:32:31.541 cpu2:1067)<6>dpc1 port login OK: logged in ID 0x82
    <date and time> <hostname> vmkernel: 31:19:32:31.547 cpu2:1067)<6>dpc1 port login OK: logged in ID 0x83
    <date and time> <hostname> vmkernel: 31:19:32:31.568 cpu2:1067)<6>dpc1 port login OK: logged in ID 0x84
    <date and time> <hostname> vmkernel: 31:19:32:31.573 cpu2:1067)<6>dpc1 port login OK: logged in ID 0x85
    <date and time> <hostname> vmkernel: 31:19:32:31.576 cpu2:1067)<6>dpc1 port login OK: logged in ID 0x86
    <date and time> <hostname> vmkernel: 31:19:32:32.531 cpu2:4267)StorageMonitor: 196: vmhba0:0:0:0 status = 0/2 0x0 0x0 0x0
    <date and time> <hostname> last message repeated 31 times
    <date and time> <hostname> vmkernel: 31:19:32:32.532 cpu1:3973)StorageMonitor: 196: vmhba0:0:0:0 status = 2/0 0x6 0x29 0x0


Resolution
This issue can occur on VMware ESX servers under the following conditions:
  • Hypervisor version: VMware ESX 3.5 U3.
  • SAN hardware: Active/Passive and Active/Active arrays (Fibre Channel and iSCSI).
  • Trigger: This occurs when VMFS3 metadata updates are being done at the same time failover to an alternate path occurs for the LUN on which the VMFS3 volume resides .
A reboot is required to clear this condition.
 
Note: This issue is resolved in the following patches, released Jan. 30, 2009:

No comments:
Labels:

Consolidating snapshots

Consolidating snapshots
KB Article 1007849
Updated Jan. 14, 2009
Products
VMware ESX
Product Versions
VMware ESX 3.0.x
VMware ESX 3.5.x
Symptoms
When powering on a virtual machine, the following error message is displayed:

The parent virtual disk has been modified since the child was created

Resolution
This error can occur under the following circumstances:
  • The base disk of the virtual machine has been changed
  • Running out of space on the LUN that contains the snapshot
  • Virtual machine suffers a blue screen exception when a snapshot is taken
For more details about snapshots and missing header files, see Cannot power on a virtual machine because the virtual disk cannot be opened (1004232) .
Before implementing the solution, ensure:
  • You know the file names of all virtual disks associated with the virtual machine. Use the following command and record the output:

    # grep -i filename /vmfs/volumes/old_datastore/vmdir/*.vmx | grep -i vmdk

  • That there is enough space on the target datastore to receive the cloned virtual disks. Use the following command to assess how much space is needed:

    # ls -lah /vmfs/volumes/old_datastore/vmdir/*flat.vmdk

    Note: This example assumes that all of the virtual disks are contained in the directory with the virtual machine configuration file (.vmx ).

  • A complete snapshot chain with matching CIDs and Parent CIDs (obtained from step 2 in the procedure).
  • The virtual machine is in a powered off state.
  • There is enough time to commit the snapshots. This procedure can take an extended amount of time depending on the size of the delta files.
To match the CID of the snapshot to the base disk:
  1. Find out what disks the virtual machine is using.

    Log in to the ESX host and navigate to the directory that contains the virtual machine. Run the following command to identify which virtual disk files are being used:

    # grep -i filename *.vmx

    The output appears similar to:

    scsi0:0.fileName = "vm-000002.vmdk"
    scsi0:1.fileName = "vm_1-000002.vmdk"

    This virtual machine has two virtual disks.

  2. Check the CID of the base disks and compare them to the snapshots to see if they match.

    Run the following command to obtain the information about the virtual disk:

    # cat vm_1-000002.vmdk

    The output appears similar to:

    CID=929c1b7d
    parentCID=20d215cd
    createType="vmfsSparse"
    parentFileNameHint="vm_1-000001.vmdk"

    This indicates that the file vm_1-000001.vmdk has the CID of 20d215cd.

    Do this for each file in the snapshot chain until you get to the base disk.

  3. Clone the virtual disk to a new base disk.

    To clone the virtual disk:

    1. Run the vmkfstools -i command to copy out and consolidate the snapshots. This requires enough space for the base disk. The command ls -l *-flat.vmdk gives the size of each base disk in the current directory.
    2. Create a directory on a the target datastore if you are not cloning to the current directory:

      # mkdir /vmfs/volumes/new_datastore/recover
    3. Run the vmkfstools -i command to clone out the last vmdk delta disk pointer VMDK:

      # vmkfstools -i /vmfs/volumes/old_datastore/vmdir/vm_1-000002.vmdk /vmfs/volumes/new_datastore/recover/vm_1.vmdk

      The output appears similar to:

      Destination disk format: VMFS thick
      Cloning disk '/vmfs/volumes/old_datastore/vmdir/vm_1-000002.vmdk'...
      Clone: 100% done.

      Note: If the above process does not work, choose the next snapshot up the tree as the one you are on (or one of the higher ones) is corrupt.

    4. Detach the disk from the virtual machine using the VI Client.
    5. Attach the new disk, /vmfs/volumes/new_datastore/recover/vm-disk2.vmdk to the virtual machine.
    6. Power up the virtual machine and ensure data integrity (Event Viewer, SQL, E-mail, etc).

  4. Delete the base disk and only it's snapshot disks.

    # grep -A2 parentFile vm_1-000002.vmdk | grep -v "#"

    The output appears similar to:

    parentFileNameHint="vm_1-000001.vmdk"
    RW 41943040 VMFSSPARSE "vm_1-000002-delta.vmdk"

    This indicates that the pointer vm_1-000002.vmdk points to vm_1-000002-delta.vmdk and is using vm_1-000001.vmdk as it's parent disk.

    You may run the same command on the parent pointer to determine what files it uses, until you locate them all.

    # rm /vmfs/volumes/old_datastore/vmdir/vm_1-000002.vmdk
    # rm /vmfs/volumes/old_datastore/vmdir/vm_1-000002-delta.vmdk
    # rm /vmfs/volumes/old_datastore/vmdir/vm_1-000001.vmdk
    # rm /vmfs/volumes/old_datastore/vmdir/vm_1-000001-delta.vmdk
    # rm /vmfs/volumes/old_datastore/vmdir/vm_1.vmdk
    # rm /vmfs/volumes/old_datastore/vmdir/vm_1-flat.vmdk

    Note: If you are going to use rm with a wildcard, echo the command first. This allows you to see which files are being targeted for erase.

    # echo rm *.vmdk

  5. Move the VMDKs back to the original location and re-associate the virtual machine with the new disks.

    To move the VMDKs back to the original location:
    1. Run the following command to clone the disk back to the original data store.

      # vmkfstools -i /vmfs/volumes/new_datastore/recover/vm_1.vmdk /vmfs/volumes/old_datastore/vmdir/vm_1.vmdk

    2. Detach the recovered disk from the virtual machine using the VI Client
    3. Attach the new disk in the original location, /vmfs/volumes/old_datastore/vmdir/vm-disk2.vmdk to the virtual machine.
    4. Power up the virtual machine and ensure data integrity (Event Viewer, SQL, E-mail, etc).

  6. Clean up the snapshot database.

    Rename the .vmsd file, remove the virtual machine from inventory, and re-add the virtual machine to clear the snapshot database.

    # mv vm.vmsd vm.oldvmsd

No comments:
Labels: ,
Subscribe to: Posts (Atom)

LinkWithin

Popular Posts