Quantcast
Channel: VMware Communities: Message List
Viewing all articles
Browse latest Browse all 230412

Re: The VMDK chain gets broken after using VixDiskLib_CheckRepair() for a file(other than the last child) in the VMDK chain.

$
0
0

Hi Manickam,

 

Initially i have opened VMDK files in Read_Only mode.,

But for Opening Windows 2012 guest OS's VMDK files i have changed to R/W mode open.( http://communities.vmware.com/thread/449611)

 

thanks for the pointer, now I can remember, thanks a lot.

 

The problem is because of the CID of the VMDK file gets changed after the VixDiskLib_CheckRepair() call.

 

I understand. Now that the CID changes with the VixDiskLib_CheckRepair() call seems sensible. Whatever CheckRepair() does in addition to resetting the uncleanshutdown flag, the fact that it checks the disk may also mean that it checks its contents somehow and so an update of the CID is suggested.

 

1. Is there any way to Read the CID and parentCID values from the VMDK file before using VixDiskLib_CheckRepair() and then write(Open with VIXDISKLIB_FLAG_OPEN_SINGLE_LINK flag) the CID and parentCID values in the same VMDK file after VixDiskLib_CheckRepair() call

 

2. I have seen some functions like VixDiskLib_ReadMetadata() and VixDiskLib_WriteMetadata().

 

3. Is there any way to read and wtite the metadata of a VMDK file by using the above mentioned functions.

 

  1. Yes there is a way to read and write CID and parentCID. But as CID and parentCID are acutally part of the disk descriptor header you will have to write code which is able to manipulate the descriptor header. However this can be tedious and my advice is not to do so as long as you can take any other route.
  2. As far as I can tell VixDiskLib_ReadMetadata() and VixDiskLib_WriteMetadata() only access the disk database of the disk descriptor which is only the last part of the disk descriptor and unfortunately CID and parentCID reside in the descriptor header and not in disk database. So from my point of view currently no way to read/write CID and parentCID via those functions.
  3. Yes, but as I see it only the meta data stored in the disk database.

 

Phew, lots of stuff ;-)

 

Now my suggestion is as follows:

 

Disk Chaining and Redo Logs tells us not to open intermediate children in the chain but use VixDiskLib_Attach() to attach a child into the chain and open that one. Now to be honest I have not used VixDiskLib_Attach() yet and I am also not completely sure what this function does. So I cannot recommend using it. Maybe this can throw some light on it for you. But anyway for the moment we can achieve constant CIDs and parentCIDs without using VixDiskLib_Attach() as follows:

 

In your chain, if you want to access the contents of win2012-child1.vmdk

 

  1. Open it with VixDiskLib BUT open it READ_ONLY. Opening read only will assure constant CID and parentCID.
  2. Use VixDiskLib_CreateChild() to create a child disk in front of win2012-child1.vmdk. You could call it win2012-child1ATTACH.vmdk for example.
  3. Close win2012-child1.vmdk again.
  4. Open  win2012-child1ATTACH.vmdk in R/W mode
  5. Do whatever you want
  6. Close win2012-child1ATTACH.vmdk
  7. Delete win2012-child1ATTACH.vmdk using VixDiskLib_Unlink()
  8. Hopefully be happy

 

In step 4 you actually shield the contents of interest from any changes that may occur due to whatever and that's the crux of the routine.

 

I have tried the above algorithm over here and it seems to work fine. Please let me know if it also works for you ;-)

--

Thomas G.


Viewing all articles
Browse latest Browse all 230412

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>