VMware Cloud Community
mleszek
Contributor
Contributor
Jump to solution

Removing all snapshots

Hello

I triggered all snapshot removal from VM almost 4h ago. It went to 95% at start and stopped till now. After 90 mins of waiting I realized that VM was turned on (oops) so I decided to turn it off while removal was still working. VM's system turned off but the machine not. I coudn't have done it yet because (i think) snapshot removal is in progress.

Now, how can I check if removal process is still working or this 95% is sth like zomie-process? In fact, this VM is not the one I need, but still there are other VMs working so I think I can't turn whole ESX host to break removal.

Last rows of VM's log dump:

Feb 23 16:05:39.149: mks| MKS: Base polling period is 10000us
Feb 23 16:05:39.551: mks| VNCENCODE 55 encoding mode change: (720x400x16depth,16bpp,1440bytes/line)
Feb 23 16:05:39.562: mks| VNCENCODE 55 encoding mode change: (720x400x16depth,16bpp,1440bytes/line)
Feb 23 16:05:53.470: vcpu-2| TOOLS autoupgrade protocol version 0
Feb 23 16:05:53.501: vcpu-2| TOOLS ToolsCapabilityGuestTempDirectory received 0
Feb 23 16:05:53.502: vcpu-2| TOOLS ToolsCapabilityGuestConfDirectory received 0
Feb 23 16:05:53.560: vcpu-2| GuestRpc: Reinitializing Channel 0(toolbox)
Feb 23 16:05:53.674: vcpu-2| GuestRpc: Channel 0 reinitialized.
Feb 23 16:05:54.448: vcpu-3| Balloon: Start: vmmemctl reset balloon
Feb 23 16:05:54.448: vcpu-3| Balloon: Reset (n 3 pages 0)
Feb 23 16:05:54.448: vcpu-3| Balloon: Reset: nUnlocked 0 size 0
Feb 23 16:05:58.775: mks| SOCKET 55 (72) recv error 104: Connection reset by peer
Feb 23 16:05:58.776: mks| SOCKET 55 (72) destroying VNC backend on socket error: 1
Feb 23 16:05:58.810: mks| MKS: Base polling period is 1000000us
Feb 23 16:06:32.768: vcpu-0| Vix: [126031 vmxCommands.c:7612]: VMAutomation_HandleCLIHLTEvent. Do nothing.
Feb 23 16:06:32.769: vcpu-0| Msg_Hint: msg.monitorevent.halt (sent)
Feb 23 16:06:32.769: vcpu-0| The CPU has been disabled by the guest operating system. You will need to power off or reset the virtual machine at this point.
Feb 23 16:06:32.769: vcpu-0| ---------------------------------------
Feb 23 16:08:37.288: mks| MKS: Base polling period is 10000us
Feb 23 16:08:37.748: mks| VNCENCODE 56 encoding mode change: (720x400x16depth,16bpp,1440bytes/line)
Feb 23 16:08:37.761: mks| VNCENCODE 56 encoding mode change: (720x400x16depth,16bpp,1440bytes/line)
Feb 23 16:08:49.367: mks| SOCKET 56 (127) recv error 104: Connection reset by peer
Feb 23 16:08:49.368: mks| SOCKET 56 (127) destroying VNC backend on socket error: 1
Feb 23 16:08:49.397: mks| MKS: Base polling period is 1000000us
Feb 23 16:22:34.311: mks| MKS: Base polling period is 10000us
Feb 23 16:22:34.751: mks| VNCENCODE 57 encoding mode change: (720x400x16depth,16bpp,1440bytes/line)
Feb 23 16:22:34.775: mks| VNCENCODE 57 encoding mode change: (720x400x16depth,16bpp,1440bytes/line)
Feb 23 16:27:32.428: mks| SOCKET 57 (120) recv error 104: Connection reset by peer
Feb 23 16:27:32.429: mks| SOCKET 57 (120) destroying VNC backend on socket error: 1
Feb 23 16:27:32.458: mks| MKS: Base polling period is 1000000us
Feb 23 17:50:51.442: mks| MKS: Base polling period is 10000us
Feb 23 17:50:51.893: mks| VNCENCODE 58 encoding mode change: (720x400x16depth,16bpp,1440bytes/line)
Feb 23 17:50:51.903: mks| VNCENCODE 58 encoding mode change: (720x400x16depth,16bpp,1440bytes/line)
Feb 23 17:50:58.793: mks| SOCKET 58 (120) recv error 104: Connection reset by peer
Feb 23 17:50:58.794: mks| SOCKET 58 (120) destroying VNC backend on socket error: 1
Feb 23 17:50:58.823: mks| MKS: Base polling period is 1000000us

Fast help appreciate, thanks.

Reply
0 Kudos
1 Solution

Accepted Solutions
a_p_
Leadership
Leadership
Jump to solution

Is it important to remove snapshot when VM is off or it does not matter?

It does not really matter. However, depending on the workload of the VM and the amount of free disk space on the datastore you may need to remove the snapshots while the VM is powered off.

When VM has one disk, let's say 50GB with several snapshots, why data in  folder is splitted on several files which in total occupy more than  120GB even if snapshots are removed?

The VM's are split into several files, configuration files as well as data files. Each snapshot will start a new files (actually two files).

In another discussion you mentioned that you use ESX 4.0. Which build do you use? With Update 2 and newer you will usually have no issues removing multiple snapshots using the "Delete All" button, but with older builds you could easily run out of disk space if space is already low.

André

View solution in original post

Reply
0 Kudos
8 Replies
a_p_
Leadership
Leadership
Jump to solution

Welcome to the Community,

depending on the size and number of snapshots as well as the exact ESX version you use, the snapshot removal may take some time. The 95% you see is ok, that's expected. If you want to see whether the snapshot removal process is still running, you can either take a look at e.g. the disk performance in the vSphere Client or use esxtop on the command line.

I'd recommend you remain patient and wait. Usually the snapshot removal works fine.

André

mleszek
Contributor
Contributor
Jump to solution

Thanks for warm words 😉

I use ESX 4.0 with vSphere 4.0. Disk usage is at level of about 6MB/s while 7 other VMs running. Shouldn't it be faster during snapshot removal?

Reply
0 Kudos
aravinds3107
Virtuoso
Virtuoso
Jump to solution

Snapshot removal goes to 95% at faster speed but it will reman there for hours until the snapshot are committd, depending the size of the snapshot it will take time, Be Patient keep watching

If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful |Blog: http://aravindsivaraman.com/ | Twitter : ss_aravind
mleszek
Contributor
Contributor
Jump to solution

Two more questions.

Is it important to remove snapshot when VM is off or it does not matter?

When VM has one disk, let's say 50GB with several snapshots, why data in folder is splitted on several files which in total occupy more than 120GB even if snapshots are removed?

Reply
0 Kudos
ArunNukula
Contributor
Contributor
Jump to solution

Nope , When you turn off the machine , you do not have any current I/O going to the machine so it would be faster.

Regards, Arun Nukula Cloud Consultant VCP4 VCP5 VCA-DT
Reply
0 Kudos
a_p_
Leadership
Leadership
Jump to solution

Is it important to remove snapshot when VM is off or it does not matter?

It does not really matter. However, depending on the workload of the VM and the amount of free disk space on the datastore you may need to remove the snapshots while the VM is powered off.

When VM has one disk, let's say 50GB with several snapshots, why data in  folder is splitted on several files which in total occupy more than  120GB even if snapshots are removed?

The VM's are split into several files, configuration files as well as data files. Each snapshot will start a new files (actually two files).

In another discussion you mentioned that you use ESX 4.0. Which build do you use? With Update 2 and newer you will usually have no issues removing multiple snapshots using the "Delete All" button, but with older builds you could easily run out of disk space if space is already low.

André

Reply
0 Kudos
mleszek
Contributor
Contributor
Jump to solution

I use build 164009. I guess that's not Update 2 You mentioned about.

So from what I understood, after removing all snapshots I need to manually delete snapshots that server didn't because of low space left?

Reply
0 Kudos
a_p_
Leadership
Leadership
Jump to solution

I use build 164009. I guess that's not Update 2 You mentioned about.

That's correct. You are using the GA (initial( version.

So  from what I understood, after removing all snapshots I need to manually  delete snapshots that server didn't because of low space left?
I'm not quite sure what you mean. You should NEVER delete any files manually! Please provide a list of files in the VM's folder showing the full names, sizes, etc. and let me know how much free disk space you currently have on the datastore.
André
Reply
0 Kudos