Restoring a virtual machine fails if VMDK disks are aligned using NetApp's mbralign utility on Windows 2000 and 2003
search cancel

Restoring a virtual machine fails if VMDK disks are aligned using NetApp's mbralign utility on Windows 2000 and 2003

book

Article ID: 344299

calendar_today

Updated On:

Products

VMware vSphere ESXi

Issue/Introduction

Symptoms:
Back up and restore of a Windows 2000/2003 virtual machine whose virtual disks are aligned using NetApp's mbralign utility fails with an error similar to:

2012-04-23T16:18:43.104Z [6D0CEB90 info 'vm:/vmfs/volumes/4e2e9cab-187f6b6e-5661-02215ecb7867/test-aligned-2/test-aligned-2.vmx' opID=2e57e7e2-ed] Failed to unset VM medatadata: FileIO error: Could not find file : /vmfs/volumes/4e2e9cab-187f6b6e-5661-02215ecb7867/test-aligned-2/test-aligned-2-aux.xml.tmp.

2012-04-23T16:18:43.109Z [6D0CEB90 info 'Libs' opID=2e57e7e2-ed] Vix: [3433 foundryVM.c:10650]: Error VIX_E_INVALID_ARG in VixVM_CancelOps(): One of the parameters was invalid



Environment

VMware vSphere Web Services SDK 5.0
Virtual Disk Development Kit 5.0
VMware Virtual Disk Development 1.2
VMware vSphere Web Services SDK 4.1

Cause

The mbralign utility increases the size of the disk by X number of sectors (X can be an odd or even number) when aligning the disks. This increase in size is not reported properly by the vSphere API if X is an odd number.

Example for a 20 GB virtual disk:

Before mbralign, the size returned by the two APIs (vSphere and VDDK) is:
  • vSphere API: 20971520 KB = 41943040 sectors
  • VDDK API: 41943040 sectors
After mbralign, the size returned by the two APIs is:
  • vSphere API: 20971520 KB = 41943040 sectors
  • VDDK API: 41943041 sectors

If the size of the disk is increased by an odd number of sectors, the size of the disk returned by the vSphere API is less than the size of the disk returned by VDDK.

But if the size of the disk is increased by an even number of sectors, the size of the disk returned by the vSphere API is the same as the VDDK returned size.

This is because the vSphere API returns the disk size (that is, the capacity) in KB as a long value. So when the mbralign utility increases the disk size (for example by 1 sector, which is 0.5 KB), the vSphere API rounds the value down when representing it as a long value.

In this case, the virtual disk size must be repaired by making it a multiple of 4 KB before backing up the Virtual Machine. If the disks are already backed up, then during restore adjust the size of the disk so that it is multiple of 4 KB and then back up the restored disk again.

Resolution

To work around this issue and restore a disk which was aligned with mbralign:

  • Case 1 - When a fresh back up and restore is performed after aligning the disk using the mbralign utility, use this procedure:

    1. If the disk size after mbralign is not a multiple of 4 KB, then first repair the disk by adding the appropriate number of sectors to it so that CapacityInKB is a multiple of 4 KB.

      For example, 41943041 sectors = 20971520.5 KB for the 20 GB disk in the example above is not a multiple of 4 KB. Therefore 7 sectors must be added in this example to make the CapacityInKB a multiple of 4 KB. Specifically, 41943041 + 7 = 41943048 sectors, which is equal to 20971524 KB.

      Use the ReconfigVM_Task API to update the disk size (CapacityInKB) to 20971524 KB in the example above.

    2. Perform a backup and restore of the virtual machine as usual.


  • Case 2 - For an already backed up virtual machine, use this procedure:

    1. Create a restore virtual machine with a size 4 KB larger than the saved size to ensure that the disk size is a multiple of 4 KB.

      For example, if the saved size is 20971520 KB, then the size of the restore virtual machine is 20971524 KB (that is, 41943048 sectors).

    2. Restore the backed up VMDK data.

    3. The restored VMDK should not be adjusted again to the previous size that represents an odd number of sectors. This is to ensure that the VMDK does not break again. Once the virtual machine boots successfully, these disks should be backed up again and be used for future restores.


Additional Information