ESXi 6.0, and using QNAP for snapshots storage

[DrorAmbar]

Hello all,

First, I'm new to this forum and to VMWare so your kindness is appreciated.

Here's the background:

I have 4 servers in different locations that are running ESXi 6.0, two are Dell R220, one HP DL 380 G9, and one is HP DL 160 G9.

The servers were built a few years ago by a previous VoIP vendor and are hosting ShoreTel servers and virtual switches.

The problem is that the vendor selected too small of hard drives and there isn't enough space for snapshots.

We have QNAPs available in each location.

I was wondering if it's possible to use them as storage locations for snapshots?

If so, can I be guide how to do that?

I tried consulting with QNAP support but they weren't helpful.

If more information is required, I will gladly provide it.

Thanks in advance.

[IRIX201110141]

No, creating or removing a snapshot can also performing when the VM is on.  This would be the normal way... but we dont know your VMs and how they react.

Regards,
Joerg

[DrorAmbar]

Got it.

So to conclude everything that was said earlier:

I should Delete All snapshots and that would bring the parent VM to the last state when the VM was on the snapshot.

Andre's suggestion to take the snapshot when the VM powered off is specific to this case - generally speaking, snapshots are taken when the VM is running.

Snapshots should not be kept for 3.5 years... What is the longest time recommended to keep a snapshot?

Another question: suppose the upgrade fails and I want to delete the snapshot without having it effecting the parent VM, so I am guessing that I revert to the parent VM, then hit "Delete All"?

And finally, what was the record for the longest VM running on a snapshot before me?:smileylaugh:

[a_p_]

I should Delete All snapshots and that would bring the parent VM to the last state when the VM was on the snapshot.

Yes, this will merge all delta data from the snapshot .vmdk file into the base/flat .vmdk file.

Andre's suggestion to take the snapshot when the VM powered off is specific to this case - generally speaking, snapshots are taken when the VM is running.

The reason why I suggested to create the snapshot in a powered off state is to ensure that the VM is in a defined state in case you need to revert. Taking the snasphot with the VM powered on may work too, but remember that in this case files, and databases are open. Especially with time critical application like phone systems, I tend to create offline snapshots. Some applications/vendors even do not officially support reverting to an online snapshot.

Snapshots should not be kept for 3.5 years... What is the longest time recommended to keep a snapshot?

As long as really needed. Ask yourself, for how long it makes sense to revert to the snapshot. Remember that if you revert, you will loose all delta data that's been modified since you took the snapshot.

Another question: suppose the upgrade fails and I want to delete the snapshot without having it effecting the parent VM, so I am guessing that I revert to the parent VM, then hit "Delete All"?

Reverting to a snapshot will discard the deltas, and bring the VM back to the point in time at which you took the snapshot. What it doesn't do is to delete the snapshot file itself, so that subsequent changes will be stored in the delta file. So yes, if you want to get rid of the delta file, revert the VM, and then delete the snapshot if you don't need it anymore (e.g. for a second update try).

André

[DrorAmbar]

I see, so in this case it is better to take the snapshot when the vm is powered down since it's a phone system.

Is it also preferred in this case to Delete All while it's powered off, since my understanding that due to the size of the delta file after 3.5 years, the machine will probably lag and freeze?

I can fail over all the accounts on that server to a different site so services will not be interrupted.

And generally speaking, is there also an advantage in Deleting All on a phone system VM while it's powered off?

[a_p_]

I usually delete snapshots while the VMs are up, and running. Unless your disk subsystem is overloaded , you shouldn't really notice the deletion, regardless of the snapshot size.

One reason that I could think of, when snapshots need to be deleted offline, is when VM's are hit by really heavy disk traffic, where online deletion fails to complete the job successfully.

André

[DrorAmbar]

I have another question: What is the functionality of the Consolidate option in Snapshot?

It sounds like Delete All is basically consolidating snapshots but I am sure that there's a difference if that option is there, or am I wrong?

[daphnissov]

Consolidate is a "commit all" function for when the snapshot descriptor file is missing.

[IRIX201110141]

DrorAmbar​

The normal Snapshotmanager works only if the Snapshotdatabase is healthy. The DB is a simple ASCII text file within the VM folder and can easily overridden and the Snapshot manager will show nothing in the GUI. If you cannot select anything you cant press the delete/delete all button.

The Consolidate function will always try to delete all snaps regardless what the GUI displays. The consolidates alarms kicks in when for example only a few vDISKs of a VM have a snap on the other have none.

Regards,
Joerg

[DrorAmbar]

First of all I wanted to thank everyone who took the time to reply to all my questions.

Thanks to you guys I was able to start my project and so far everything is going well.

I did run into a situation though when I increase the provisioning size of a disk from 80 GB to 110 GB where the max allowed is 114 GB, and then the vm wouldn't start.

I apologize in advance for not having a screenshot of the error message, I had a WTF moment and closed it... if I remember it correctly if had to do with not enough disk space or something like that.

I hope that you understand why I didn't try to recreate the issue, so no screenshot.

I restored the original files so disk size was set to 80 GB again, however the provisioned size was still set as 110 GB in 'Edit settings' and could not be reduced.

I then used vmkfstools to increase the size to 96 GB which met my requirements and everything worked fine after that.

So although the actual new disk size is 96 GB, the provisioned size remained 110 GB in 'Edit settings' and the only option is to increase the size of the disk.

My questions are:

Why wasn't I able to increase the disk size to the max or even to less than that?

If the max is not the actual max size I can set it to, is there a calculation that I can use to find out what is the actual max size allowed for that machine?

Why is the provisioned size is still set as 110 GB in 'Edit settings' even though the actual size is 96 GB? Is there a way to have it show the actual size again?

Thanks!

[IRIX201110141]

If you use "thinprovisoning" you can set the size you want, regardless if the space is available or not.

If you power on a VM a swapfile is creating in the same size as the VM have configured vMEM. If you try to resize a vDisk when its powered off the available diskspace is larger.

Regards,
Joerg

[DrorAmbar]

I am using thick provision lazy zeroed so I guess space availability is relevant in this case.

I did try expanding when the guest was powered down and got the error message of not enough space for page file again when I powered it up.

From what you wrote and what I experienced I've concluded that the actual max size in my case is the available space in the datastore when all guests are powered up, subtracting the memory size.

Once I followed that calculation I didn't run into any issues.

The workarounds I figured out are either reduce the memory size for any of the guests if possible, or increase the datastore size if possible.

With that said, the only reason I use thick provision lazy zeroed is because that's how the vendor who set up these machine did it, since I guess this is the option selected by default.

So my questions are:

Is there any advantage in using thin provisioning over thick other than the available size and expansion?

Is there a downside using thin provisioning?

If I'm better off using thin provisioning, is there a way to convert a thick provisioning to thin?

Also, what is the difference between thick/lazy and thick eager?

Thanks!

[IRIX201110141]

The workarounds I figured out are either reduce the memory size for any of the guests if possible, or increase the datastore size if possible.

Well,  you can set a 100% or partial vMem reservation and that sets the size of the swap file to Zero (when VM is startet next time).  But increasing the datastore is the first option.

With that said, the only reason I use thick provision lazy zeroed is because that's how the vendor who set up these machine did it, since I guess this is the option selected by default.

So my questions are:

Is there any advantage in using thin provisioning over thick other than the available size and expansion?

No, but on NFS and vSAN thin provisiong is the default.

Is there a downside using thin provisioning?

If your Datastore running out of space all thin provisioning and VM with a snapshot stops working because they cant write.

If I'm better off using thin provisioning, is there a way to convert a thick provisioning to thin?

You can migrate a VM and in the adv. option you can specify new option for the VM or per vDisk. From the command line there is vmkfstools -d thin when cloning VMs.

Also, what is the difference between thick/lazy and thick eager?

Both  allocated the full space buy only eager (pre-)allocated including initialization and preparing for the first write. The lazy one needs 2 write IOs for the first write.  Think in the same way as Windows quick format == Lazy and  without quick format == eager.

Regards,

Joerg