Removal of large Snapshot

[tghagan]

We have two virtual machines (a file server and a mail server each running Windows Server 2008 R2). The file server is a domain controller. They both have very large Snapshots (approx 524GB). We would like to remove these snapshot because we get warnings in Veeam and also for good practise reasons. We have done some testing and we have found that if we backup the machine and then restore it it removes the backup.

What would be the recommended approach for the removal of the Snapshot?
1. Power down machine, back it up, restore it.
2. Power down machine, back it up, remove the Snapshot

Any other thoughts welcome.

Reagrds

[Vitaliy S.]

Hi Tony,

Why do you want to power down these VMs at all? You can commit the snapshot using one of the approaches below:

1. Use vSphere Client to consolidate the snapshot with its parent virtual disk. It's pretty straightforward, but there is one significant drawback you should be aware about - you may see behavior mentioned in this thread: Snapshot removal issues of a large VM

2. Another way of getting rid of this this snapshot is to replicate this VM locally and then perform VM failover operation. Since snapshots are not backed up through vStorage API, your new VM will not have it.

Thanks!

[Gostev]

Or use Veeam quick migration... and I am curios if Storage VMotion would do the same as well, since vSphere 5 did add support for Storage vMotioning VMs with snapshots.

[Berniebgf]

Or, safest and most likely fastest...

Shutdown the VM and Clone it to another location (Seperate disk pack would be best for speed)...

Do it overnight would be best, then test the clone is operational and delete the old VM..

Bernie.

[Gostev]

Definitely not the fastest, as quick migration will:
a) Send compressed traffic over the network (unlike uncompressed in case of cloning)
b) Uncompress this data only at target proxy, and use the super fast hot add processsing mode to populate the target VM disks with data (instead of very slow NBD throttled by the ESX(i) management console)
c) Actual downtime will be minutes versus hours

And regarding safest, they are equally safe now because we have added an option not to delete the source VM in 6.1

[Berniebgf]

Sorry I don't agree...

If the customer can afford the after hours task, it is always going to be safest to shutdown the VM and clone it from one datastore to another (why across network?).

Then you are......

Not relying on Veeam
Not relying on VMware snapshots
Have taken load off the Storage (VM off)
And can be assured your "Guest OS" file system is dis-mounted and safe.....
And have a definitive failback position to a safe and sound powered off Guest OS...

Sound safe and simple to me? With a snapshot this size I would not stuff around....

Bernie.

[Gostev]

What specifically you don't agree with in my post above? We are just giving different options for the OP and future readers, while not assuming like you do that every customer will be able to afford extended downtime to pull this, or even have enough disk space on the same storage to make a full copy of a VM.

[Berniebgf]

Agree with requirements for space, that's a given.

Its just my opinion, I don't completely trust VMware snapshots and I always try to reduce IO workload as much as possible when in these types of situations.
Moving large data sets between data-store's is going to be better that moving it across the network, in my opinion the less products and layers that touch it the better.

Don't get me wrong, this is not something that I do all of the time but when dealing with large machines and especially large snapshots... and in my book 524GB snapshot is on the big side.....I generally keep it simple and keep it safe...

Depending on the storage solution we could be looking at many..many.. hours to merge this snapshots......

lets still be friends...

Bernie.

[Gostev]

Sure

[dellock6]

I think we are all waiting for VMware to change snapshot behaviour from "copy-on-write" to "redirect-on-write" as many storage systems already do, and we will live happily ever after.