Hot clone VM with snapshots

[Kermitdafwog]

Hi

We have a problematic VM which has multiple (we've hit the 32 mark!) orphaned snapshots cauSed by netbackup. We've tried a few ways of getting rid of the snapshots but they all appear to be a child of one another so they cannot be moved or deleted without causing the VM to pwoer off.  We've decided to clone it to a new datastore and run with the clone before deleting the original.

Are we able to hot clone the VM either with VC or Converter resulting in the snapshots being left behind?  The server is in production and we'd prefer to keep it running it at all possible

The environment is running ESXi 4.1 with vCentre 4.1

Thanks

Kerms

[memaad]

Hi,

1. You can try with converter to convert the VM.

2. Also you can try to clone when the VM is powered On.

3. IF above two option fails , then you have to shutdown the VM and do cloning from command line using vmkfstools -i command.

Here is syntax.

vmkfstools -i   latestsnapshot.vmdk  /vmfs/volumes/datastore/new-folder/YOUVM.vmdk.

4. If this two fails then you have to use this KB, where you have split while cloning.

http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=1004545&sl...

REgards

Mohammed

[Kermitdafwog]

Hi

Thanks for the reply. Unfortunately I need to report to management what our options are in terms of running the clone whilst the VM is powered on and I am unable to test

Do you know what are the probably outcomes of hot cloning with vcentre and/or converter?

Thanks again

Kerms

[memaad]

Hi,

Do be honest, I can predict, however I can say there will be performance impact when you have 32 snapshot and doing cloining or conversion. My recommendation will be to perform powered Of cloning.

Regards

Mohammed

[vLarus]

Are you sure that the 32 snapshots are active? Ive had this happen on multiple occasions with clients, and 99% of the time, these snapshots are "dead" snapshot files. This seems to happen a lot when backup solutions create a Quiecsing-only snapshot, and the deletion/consolidation fails. Then a snapshot is left behind, but not connected to the parent disk.

You can confirm this by going to the Datastore browser, and find. Search for the name of the machine, and download the small .vmdk decriptor files for the parent disk, and the snapshot deltas, and see if the CID number is in a row between the parent disk and the first snapshot, the first snapshot and the second snapshot etc.

regards,

Larus.

[Kermitdafwog]

Hi

Not sure if the snapshots are classed as "active" - they dont appear in the snapshot manager window, however, if any are moved to another folder the VM powers off.

Here's an example of the vmdk files, the first, second, third and last descriptor files: -

Vm01.vmdk

# Disk DescriptorFile

version=3

encoding="UTF-8"

CID=0c8c022a

parentCID=ffffffff

isNativeSnapshot="no"

createType="vmfs"

# Extent description

RW 83886080 VMFS "VM01-flat.vmdk"

# Change Tracking File

changeTrackPath="VM01-ctk.vmdk"

# The Disk Data Base

#DDB

ddb.deletable = "true"

ddb.toolsVersion = "8295"

ddb.virtualHWVersion = "7"

ddb.longContentID = "8c913eb728b4e7614111e30b0c8c022a"

ddb.uuid = "60 00 C2 9d ad 20 bd 45-67 a3 fa 1e 41 f2 11 c5"

ddb.geometry.cylinders = "5221"

ddb.geometry.heads = "255"

ddb.geometry.sectors = "63"

ddb.adapterType = "lsilogic"

VM01-000001.vmdk

# Disk DescriptorFile

version=3

encoding="UTF-8"

CID=7d3226b5

parentCID=0c8c022a

isNativeSnapshot="no"

createType="vmfsSparse"

parentFileNameHint="VM01.vmdk"

# Extent description

RW 83886080 VMFSSPARSE "VM01-000001-delta.vmdk"

# Change Tracking File

changeTrackPath="VM01-000001-ctk.vmdk"

# The Disk Data Base

#DDB

ddb.deletable = "true"

ddb.longContentID = "e4d6802814b676ec6400def77d3226b5"

VM01-000002.vmdk

# Disk DescriptorFile

version=3

encoding="UTF-8"

CID=bcd268c7

parentCID=7d3226b5

isNativeSnapshot="no"

createType="vmfsSparse"

parentFileNameHint="VM01-000001.vmdk"

# Extent description

RW 83886080 VMFSSPARSE "VM01-000002-delta.vmdk"

# Change Tracking File

changeTrackPath="VM01-000002-ctk.vmdk"

# The Disk Data Base

#DDB

ddb.longContentID = "e9dfa56689c0496514f47bd7bcd268c7"

VM01-000032

# Disk DescriptorFile

version=3

encoding="UTF-8"

CID=766f20c9

parentCID=1e071ddf

isNativeSnapshot="no"

createType="vmfsSparse"

parentFileNameHint="VM01-000031.vmdk"

# Extent description

RW 83886080 VMFSSPARSE "VM01-000032-delta.vmdk"

# Change Tracking File

changeTrackPath="VM01-000032-ctk.vmdk"

# The Disk Data Base

#DDB

ddb.longContentID = "791601e13d12d6a6c93eeb4f766f20c9"

To me, it looks like each snapshot is dependent on the one before it which is why we are considering the cloning option to remove them.

How does it look to you?

thanks

Kerms

[vLarus]

They are active, thats for sure.

Have you tried the ususal consolidation techniques for vSphere 4?

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=100784...

rgds,

Larus

[Kermitdafwog]

Hi

Yrs we have, we're even logged it with VMWare who have suggested the clone route!

Ideally I want to know if i can safely hot clone the server....VMWare have since closed the ticket!

Thanks

[vLarus]

It really depends on the application the server is running. When you hot clone a server, a snapshot is created, and the server is cloned to a new VM from the time the snapshot it created. If this is a busy SQL server, my recommendation is to turn of the service, but then again you'll probably just be better off doing a cold clone.

The bottom line is, if data is being actively being written to this server, you will lose that data between the the time the cloning process started, to the time you turn on the clone, and turn off the old VM.

Larus.

[TomHowarth]

The basic answer is it depends, it depand on what application you are running, what Operating system and patch level you are running. but on the whole most modern MS based OSes can be hot cloned,

applications that will not hot clone well are SQL servers,  Exchange servers and Domain Controllers,  in fact the last one the recommendation is to just create a new DC and move FSMO roles if necesary.

With the latest versions of Converter you can utiise MS VSS technology to trickle convert your machine, this will result is a slower but more stable and less intrusive migration. (think Storage vmotion or vmotion where the transfere is done and then finally synced before change over).

I would advise you to read the converter documentation

Also I am moving this post to the dedicated Converter subsection of the forum,