Re: VixMntapi_GetVolumeInfo is not returning inGue...

red0mark · ‎07-30-2009

All,

Using VI SDK 4.0 I’ve taken a snapshot of a virtual machine with 3 HD. I pass this information on to the VDDK 1.1 to mount the snapshoted volumes. From the output below you can see that I’m getting the symbolic links for each volume but I’m only getting the inGuestMountPoints for the C: volume… the other(s) are always numGuestMountPoints: 0. Any ideas why?

Thanks,

-Ron

Virtual machine moRef: moRef=176

Working on snapshot: /vmfs/volumes/49763b75-2a1b7d4e-e977-000f1f64bba6/WinXP Pro (2)/WinXP Pro (2).vmx-snapshot-1

Sanpshot disk path: datastore1 WinXP Pro (2)/WinXP Pro (2)_2.vmdk

Number of volumes: 1

Post-mount of volume info----

volume number: 0

type: VIXMNTAPI_DYNAMIC_VOLUME=3

symbolicLink:
.\vstor2-mntapi10-444D494F3A49443AE18E00F06E57F342ADAF9266474D00EA01000000\

isMounted: True

numGuestMountPoints: 0

inGuestMountPoints:

-

Sanpshot disk path: datastore1 WinXP Pro (2)/WinXP Pro (2)_1.vmdk

Number of volumes: 1

Post-mount of volume info----

volume number: 0

type: VIXMNTAPI_DYNAMIC_VOLUME=3

symbolicLink:
.\vstor2-mntapi10-444D494F3A49443A8768BF3D29809E4A9EC734FC0EBA0F2F02000000\

isMounted: True

numGuestMountPoints: 0

inGuestMountPoints:

-

Sanpshot disk path: datastore1 WinXP Pro (2)/WinXP Pro (2).vmdk

Number of volumes: 1

Post-mount of volume info----

volume number: 0

type: VIXMNTAPI_BASIC_PARTITION=1

symbolicLink:
.\vstor2-mntapi10-AAC5AAC5007E00000000000003000000\

isMounted: True

numGuestMountPoints: 1

inGuestMountPoints: C: <<<<<***** Here I get the C:

-

Further testing on other virtual guests I see the following output coming from the Log callback "Log: Unable to GetVolumeMountPoints - Error code b0"... I assume this is the problem but what is a "b0" error mean? Anyone from the VDDK team have an answer? Does the VDDK 1.1 support Windows 2008?

Log: DiskLibProvider_GetDisk: Open successful - index 0.

Number of volumes: 3

-

Working Disk: win2008x32 - gara/win2008x32 - gara_1.vmdk

Volume number in disk: 0

Log: Unable to GetVolumeMountPoints - Error code b0.

type: VIXMNTAPI_BASIC_PARTITION=1

symbolicLink:
.\vstor2-mntapi10-A3841323000010000000000002000000\

isMounted: True

-

Working Disk: win2008x32 - gara/win2008x32 - gara_1.vmdk

Volume number in disk: 1

Log: Unable to GetVolumeMountPoints - Error code b0.

type: VIXMNTAPI_BASIC_PARTITION=1

symbolicLink:
.\vstor2-mntapi10-A38413230000501F0000000003000000\

isMounted: True

-

Working Disk: win2008x32 - gara/win2008x32 - gara_1.vmdk

Volume number in disk: 2

Log: Unable to GetVolumeMountPoints - Error code b0.

type: VIXMNTAPI_BASIC_PARTITION=1

symbolicLink:
.\vstor2-mntapi10-A38413230000903E0000000004000000\

isMounted: True

-

Log: VixDiskLibReaderWriter::Close: Ignoring close

kumars17 · ‎08-12-2009

Any respone on this? I am also seeing the similar issue except that for me it is not returning the mountpoint for the boot voulme even i.e c:

- volumeInfo 0x015ecbd0 {type=VIXMNTAPI_BASIC_PARTITION isMounted=' ' symbolicLink=0x015c3ac0 "
.\vstor2-mntapi10-C445C545007E00000000000001000000\" ...} VixVolumeInfo *

type VIXMNTAPI_BASIC_PARTITION VixVolumeType

isMounted 1 '␁' char

+ symbolicLink 0x015c3ac0 "
.\vstor2-mntapi10-C445C545007E00000000000001000000\" char *

numGuestMountPoints 0 unsigned int

- inGuestMountPoints 0x015ecbe0 char *

+ 0x00000000 <Bad Ptr> char *

red0mark · ‎08-12-2009

I noted my 4.0 VC I would get some of the inGuestMountPoints and on others I would not. So further investigation has revealed that reordering the disk array passed to VixDiskLib_Open() seems to work but I can’t keep guessing at what the order the disk(s) should be for every snapshot.

e.g.

//****** I change the order of the disk names and I got the inGuestMountPoint ********/

char *diskName0 = "[datastore1] WinXPPro/WinXPPro_2.vmdk"

char *diskName1 = "[datastore1] WinXPPro/WinXPPro.vmdk"

diskNames[1] = diskName0;

diskNames[0] = diskName1;

for (i = 0; i < 2; ++i) {

vixError = VixDiskLib_Open(connection,

diskNames[i],

openFlags,

&diskHandle);

CHECK(vixError, cleanup);

diskHandles[i] = diskHandle;

}

Mounted Volume 0, Type 1, isMounted 1, symLink
.\vstor2-mntapi10-AAC5AAC5007E0

0000000000001000000\, numGuestMountPoints 1 (C:)

Mounted Volume 1, Type 1, isMounted 1, symLink
.\vstor2-mntapi10-67A0521000402

0000000000002000000\, numGuestMountPoints 1 (E:)

admin · ‎08-12-2009

VixMntapi assumes the 0th disk is the disk that has the active partition. Also, multi-boot systems are not supported.

-Sudarsan

red0mark · ‎08-12-2009

That's a problem.... one of the reason I'm calling VixMntapi_GetVolumeInfo (for a given snapshot) is so I'll know which volume is the boot partition. How can the be addressed?

-Ron

admin · ‎08-12-2009

How does Windows boot in this scenario, does one have to go to bios and switch the boot order?

If you have a mixed (IDE and SCSI) disks, this may happen. IDE always comes first.

-Sudarsan

red0mark · ‎08-12-2009

In this scenario its IDE then iSCSI but I’m working on a commercial product and I can’t predict how a customer will configure the guest.

Here is my program flow…

1. Use the VI API to snapshot a running guest.

2. Use the VI API to find all disks and paths in the snapshot. i.e. config.hardware.device.backing

3. Use the VDDK API to mount snapshot(ed) disks and volume symlinks for backup.

The question is... How can I determine which config.hardware.device is the boot device? I don’t see a property for this.

My local testing has shown that the order of the VirtualDevice array in config.hardware will very, and the first disk device I hit may not be the boot devivce or it may be... I just never know.

-Ron

admin · ‎08-12-2009

Your flow looks correct to me.

The situation is similar to when Windows boots up - it relies on the 0th disk's active partition to be the boot partition (otherwise, user will need to enter bios and switch the boot order of the disks).

AFAIK, Windows enumerates IDE disks first - so you can place them first. You can also read from the partition table and check for the active partition bit and reorder the disks.

-Sudarsan

red0mark · ‎08-12-2009

Why does the VDDK assume/expect the 0th disk to be the active boot partition? I can't find this in the documentation for the SDK did I miss it? The spirit of an SDK is to remove from the user/developer the nasty details like this, can we get a defect or request for enhancement open on this issue?

One thing I did notice was that VixMntapi_OpenDisks() didn't seem to suffer from the same order dependency issue as VixDiskLib_Open() and VixMntapi_OpenDiskSet(). Can VixMntapi_OpenDisks() be safely used on a Windows guests? The SDK PDF says "Opens disks for mounting on a Linux-based virtual machine. Not supported on Windows. On Linux, the Logical Volume Manager (LVM) is not yet supported." But there is noting in the header file that say this?

Thanks,

-Ron

admin · ‎08-12-2009

I don't think it is right for VDDK to assume a partition to be boot in case of multiple disks. However, perhaps VDDK can make a guess and return one or more candidates, but leave the actual decision to the client. Please file an SR.

What is the problem in keeping IDE disks first?

Thanks

Sudarsan

red0mark · ‎08-12-2009

Sorry I was not clear, in a customer environment, I will not know which disk is the IDE disk... I'm using the VI API to find all the disks that make up the snapshot, it provides the full paths but does not tell me which disk is the IDE. If I could determine this then I have no problems odrering the array. I’m using the VirtualDeviceFileBackingInfo object and its extensions from the VI.

What about VixMntapi_OpenDisks()? Can it be used to open the disk on a Windows system? The programming PDF and header files don't agree.

-Ron

kumars17 · ‎08-13-2009

I have only one disk in the VM and for that also its not giving the guestMountPoint information.

This is what I am doing:

1. Create the snapshot of VM

2. open the base disk in Read only mode

VixDiskLib_Open(_DiskLibConnection,strDiskPath.c_str(),VIXDISKLIB_FLAG_OPEN_READ_ONLY,pDiskHandle);

3.

vixError = VixMntapi_Init(MAJOR_VERSION,MINOR_VERSION,NULL,NULL,NULL,NULL,NULL);

VixDiskSetHandle diskSet;

VixDiskLibHandle diskHandles[]=;

vixError=VixMntapi_OpenDiskSet(diskHandles, 1, 0, &diskSet);

VixDiskSetInfo *diskSetInfo;

VixVolumeHandle *volumeHandles;

size_t numvol;

VixVolumeInfo *volinfo;

VixOsInfo *osinfo;

volumeHandles=(VixVolumeHandle )malloc(5sizeof(VixVolumeHandle));

vixError=VixMntapi_GetVolumeHandles(diskSet,&numvol,&volumeHandles);

for(size_t i = 0; i < numvol; i++) {

VixVolumeHandle volumeHandle = volumeHandles[i];

VixVolumeInfo *volumeInfo;

vixError = VixMntapi_MountVolume(volumeHandle, TRUE) ;

vixError = VixMntapi_GetVolumeInfo(volumeHandle, &volumeInfo) ;

VixMntapi_FreeVolumeInfo(volumeInfo);

VixMntapi_DismountVolume(volumeHandle,true);

}

Any issue you guys see with the above code?

red0mark · ‎08-13-2009

Just two comments....

1. I call both VixDiskLib_InitEx() and then VixMntapi_Init() at the very beginning of my app.

2. At VixMntapi_GetVolumeHandles() I didn't malloc memory for volumeHandles... I assume it get allocated for us as we should call VixMntapi_FreeVolumeHandles() to free it.

Attached is the file I used for testing this issue, its modified from an example Sudarsan had sent me awhile back.

kumars17 · ‎08-13-2009

Mark,

Thanks for your help. I took your sample and compiled and executed it for my environment and even this is not returning the mountpoint info.

Sudarshan, Any help on this?

Log:DISKLIB-LIB : Opened "vpxa-nfc://[Clar_100GB_LUN] ClarVM_Test2/ClarVM_Test

2.vmdk@10.31.223.110:902!52 15 fd 73 c6 da d2 a7-40 15 ae d5 a9 91 9f 5f" (flags

0x1e).

Log:DiskLibProvider_GetDisk: Open successful - index 0.

DiskSet Info - flags 0 (passed - 4), mountPoint (null).

Num Volumes 1

Warn:Unable to copyfile
.\vstor2-mntapi10-09230923007E00000000000001000000
Bo

ot\BCD to C:\DOCUME_1\ADMINI1\LOCALS~1\Temp\vmware-Administrator-500\vixmntapi0

, error = 3.

Warn:Error reading boot.ini file
.\vstor2-mntapi10-09230923007E000000000000010

00000
boot.ini

Log:boot.ini:

timeout=30

default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Enterprise" /f

astdetect

kumars17 · ‎08-13-2009

Okay I figured out the issue.

Mark your sample was working fine too. The reason it was failing for me was i was passing wrong flag to opendiskset.

I have one more question, Isn't it possible to read the guestMountPoint information without mounting the volume.

If mounting is a must, just wanted to check is there any side effect of mounting the volume onto the same Guest OS whose base disk we have opened.

-Sunil

red0mark · ‎08-13-2009

Sunil,

Do you get any data back in from the DiskSet Info call? I'm is always empty.

Thank,

admin · ‎08-13-2009

The mount point information is in the registry, so I don't see how one can get that data without the help of Windows (registry format is not published). As for the side effects, the mounting process involes a kernel mode driver and some user mode code - a new device object is created and exposed to user mode, so it is an intrusive operation.

-Sudarsan

kumars17 · ‎08-13-2009

Even I get the empty value for diskSetInfo

- &diskSetInfo 0x0012fd88 VixDiskSetInfo * *

- 0x016fb340 {openFlags=0 mountPath=0x00000000 <Bad Ptr> } VixDiskSetInfo *

openFlags 0 unsigned int

+ mountPath 0x00000000 <Bad Ptr> char *

All

VixMntapi_GetVolumeInfo is not returning inGuestMountPoints for additional disks