Snapshot deletion painfully slow

Right-click on a first snapshot and select 'Delete Snapshot and Its Subsequent Snapshots':

If VMs are on a USB drive, please give it some time to complete, do not stop the operation as you might lose the entire VM.

 

My personal experience is that this issue comes and goes with different upgrades of Parallels Desktop. I've just updated to the latest version (13.3.2) and snapshots are extremely slow to delete (the first time I did it, it was nearly an hour). The previous version was probably the fastest experience (maybe 2 minutes) and the versions before that were anywhere from slow-ish to very slow.

But, reading this thread, I'll have to check out the related threads on Smart Guard, etc. and re-evaluate if I want these features ON or not.
I submitted a case with ID: 265297081

I'm also using an SSD drive so it's not a HW issue.

Cheers. Brett

ps. I think I need to review my whole backup strategy. I'm using Time Machine but that seems to be backing up the entire virtual each time, which isn't very efficient and discourages me from backing up - not a good thing at all!

 

Hi Brett_Conlon,
As might be aware snapshots are saved state of the hard disk. The file created for snapshot will be merged with the default hard disk file and which is time-consuming as the data saved on that file need to be moved to the main file. If you want to delete all snapshots at once then you can use a merge command in Terminal Window which will also take time but it will be less when compared to the time taken for deleting multiple snapshots. As anything might happen during deletion or merging of snapshots, we have to backup the pvm before working with snapshots.

 

I'm using Parallels 13. I have read all of the posts and anything else WRT speeding up snapshots. I haven't seen anything other than generic how to stuff which is, to be frank, pretty useless and doesn't answer the questions(s) posed about HOW TO speed up snapshot deletion.

I have a development VM that I am protecting with smarguard. When I delete a snapshot (or when smarguard deletes a snapshot) it takes in excess of two (2) hours. So I am sitting on my behind unable to do anything because my system is not usable for 2-3 hours. I cannot schedule smartguard (you do not have that facility). I understand if I start smartguard at say 3:00 am it will schedule say every 48 hours and run at 3:00 am (great system).
BUT that does not alter the fact that deleting a snapshot takes a stupidly long time AND my whole system grinds to a halt (almost) with the snapshot deletion grunging along.

I'm running a mid-2015 15" MBP Retina with i7, 16Gb RAM, and a 1Tb OWC internal SSD.
My VM size is physically 290Gb on disk - that includes all of the associated snapshots.
The point I am making is that snapshot management is ridiculously slow and is counter productive, ie. I'd be better just not using them YET THAT'S WHY I USE VIRTUALISATION SOFTWARE, to have the protection of snapshots that I can just revert to.

So can you offer any advice (and please don't insult my intelligence and point me to generic articles and blogs about snapshots, why we use them etc) WRT how to speed this up to something more manageable. Even though many posters are very concerned deleting a snapshot takes 15-30 minutes, I'd be delighted if I could get it down to that sort of time (instead of 2-3 hours)?

 

@KevinB16, can you please send us problem report after such slow snapshot deletion and post report id here? For this select window of the VM in question, go to app menu Help -> Send Technical Data.

 

@rkulikov,
Technical data has been sent. I have posted your request in the Description Field.

PING: Anyone watching, any result ???????

 

Just to keep this thread alive and close the loop, I finally got contacted by Support and they asked for tech data during the snapshot deletion (and a host of other questions). I stupidly started this a 0900 and by 1000 it had gone about 15% - most of my day would be gone. However I found out that you cannot stop snapshot deletion once commenced. The whole shebang seemed to have hung. So I deleted the VM (212Gb) and am doing a timemachine restore from yesterday (not much done on Sunday and all of my dev stuff is in Dropbox so hopefully anything I've done since yesterday at 1230 will be recovered when Dropbox syncs).

Of course the Timemachine restore takes 2-3 hours (probably should have left the snapshot delete, but it is what it is). Of note, I backup all of my VMs with Time Machine (as well as occasionally copying them to other USB drives). The originals are on a 1Tb OWC SSD and I have two 2Tb HDD for Timemachine. This has saved my arse several times. You can say what you like about macOS, like it or love it, but Timemachine is the bees knees. I wish there was a windows version of TimeMachine, it's one of the staples that keeps me paying stupid prices for Apple hardware, but I digress.

I will post the advice I get from support when I delete the snapshot (after midnight) and they get back. My guess is it will be the stock answer ...deleting snapshots is complicated and takes time... Which would be fine if you could schedule smartguard (other than staying up 'til 0300 and starting it then so that the next snapshot delete/create will be 24hours later at 0300.
UPDATE:
I've emailed (during a snapshot delete) three SEND TECHNICAL DATA and three SPINDUMPs as well as the timings to copy a large (6Gb) file. Waiting to hear back.

 

Hi,

Seeing this thread is over 2 years old and just upgraded to Mojave (and APFS) - could it be related entirely to APFS?
Maybe parallels snapshot file structure is a very bad combination with APFS? but was ok with HFS+?

 

I'm not using Mojave yet, High Sierra and haven't upgraded. The disk (OWC 1Tb SSD) is formatted macOSX Extended (Journaled) (CoreStorage Logical Volume). I cannot comment WRT parallels V13, Mojave and APFS.

Seeing this thread is over 2 years old and just upgraded to Mojave (and APFS) - could it be related entirely to APFS?
Maybe parallels snapshot file structure is a very bad combination with APFS? but was ok with HFS+?​

So I don't think so given my setup. I've been working through with Parallels tech support for several weeks now. And this is the sort of things that has been happening, see below (you don't have to read it all, you get the gist). We are at the point where I have bulk deleted all snapshots, taken a single snapshot, Disk Space Reclaim, turned on TRIM (although I am a bit sceptical about any performance degradation) and turned on smart guard. I will attempt to delete some snapshots this week to serif (after all that) it takes a long time and send a system report to parallels:

This ticket has been created in the Seconline support queue in order to coninue the ivnestigation of the issue you've reported on the Parallels forum: https://forum.parallels.com/threads/snapshot-deletion-painfully-slow.341337/page-2#post-844149

The Engineering team already started the investigation based on the forum thread outlined above and to continue with it we need additional technical information from your side.

Just for the confirmation, the steps to reproduce the issue are as follows am I right?
1. Start Parallels Desktop, then launch Windows 10 virtual machine.
2. Manually start deleting a snapshot/a snapshot is being deleted by the SmartGuard feature. For both cases the process takes around two hours.

Additionaly, it would be great in you provide us with aswers to the following questions:
1. If you manually deleting a snapshot and it takes two hours is it a manually or SmartGuard created snapshot? Or there is no difference which snapshots to delete?
2. According to the already provided technical report there were two virtual machines running on the host at the same time. Both of them have SmartGuard feature enabled? If only one virtual machine is running, the process take the same amount of time?
3. If you attempt to delete a snapshot on stopped virtual machine, the time of the operation would be the same as on the running one or not?

To colect the technical data for the Engineering team do the following, please:
1. Open Parallels Desktop preferences (Right-click on Parallels Desktop icon in Dock > Preferences... or || icon in the top menu bar > Preferences).
2. Switch to the Advanced tab.
3. Enable "Use detailed log messages" option.
4. Start deleting a snapshot and after a period of time collect system-wide spindump (for the sake of the investigation it would be better to have at least a couple of them, the more the better):
- Launch Terminal ( Finder > Applications > Utilities > Terminal).
- Execute the following command:
sudo spindump
NOTE: No symbols will be shown due to security measures, so just hit the keys and use return/Enter.
-Wait until you receive the following output: Spindump analysis written to file /tmp/spindump.txt
5. Archive the files and attach it to your reply.
6. In addition to the spindumps, to analyze product processes and possibly find the source of the slowness of the snapshot deleting process we need a couple of technical reports collected during the process. To collect technical report: Click on || icon in the top menu bar > Help > Send Technical Data...

Best regards,

Ivan,

Just for the confirmation, the steps to reproduce the issue are as follows am I right?1. Start Parallels Desktop, then launch Windows 10 virtual machine. 2. Manually start deleting a snapshot/a snapshot is being deleted by the SmartGuard feature. For both cases the process takes around two hours.
Correct, it doesn't matter whether I am deleting manually or via smart guard it takes a very long time. The problem is/was you cannot schedule smart guard and because I started it around 1300, it would delete the snapshot in the middle of my working day. I know I can set the alarm for 3:00 am and get up and start it then, but that seems excessive.
Additionally, it would be great in you provide us with aswers to the following questions:
1. If you manually deleting a snapshot and it takes two hours is it a manually or SmartGuard created snapshot? Or there is no difference which snapshots to delete?

No difference as far as I recall.
2. According to the already provided technical report there were two virtual machines running on the host at the same time. Both of them have SmartGuard feature enabled? If only one virtual machine is running, the process take the same amount of time?

I have no idea. The second machine is no longer used (only to recover some data), the first machine was a clone of that machine. I recall having the same issue with that VM, but it's not used. It was coincidence if it was running when I created the log files.

3. If you attempt to delete a snapshot on stopped virtual machine, the time of the operation would be the same as on the running one or not?

I will need to try it (and I'm running out of snapshots to delete AND they are further up the snapshot chain, ie. closer to the actual VM). I'm deleting a non-smartguard snapshot with the VM NOT running.

After 15 minutes, about 10% and the progress bar doesn't seem to be moving at all.

In addition to the spindumps, to analyze product processes and possibly find the source of the slowness of the snapshot deleting process we need a couple of technical reports collected during the process. To collect technical report: Click on || icon in the top menu bar > Help > Send Technical Data...

First at the 20 minute mark (image not showing, but about 10%). I didn't enable Use detailed log messages and cannot STOP the snapshot deletion (which is going to take at least a couple of hours). I cannot see how to abort the snapshot deletion and I need to get some work done. I'll probably need to recover the PVM with time machine and try this deletion overnight.

And after several towing and froing:

Please clarify the following points:
1. According to the logs, there is com.paragon-software.lvm-for-mac kernel extension loaded on the Mac side and it's possible that its presence could affect the creation/deletion speed of snapshots.
Please check the behaviour when the com.paragon-software.lvm-for-mac kernel extension is unloaded.
The software was removed . KEXT files might be hanging around and did not get removed when the paragon software (Trial only) was trashed.
1. Launch Terminal ( Applications > Utilities > Terminal) 2. Execute the following command:
sudo kextunload -b com.paragon-software.lvm-for-mac

They have been physically deleted.
2. When the last time First Aid tool of Disk Utility has been used? If it wasn't used in a while, please perform it.

Recently, so that should not be a problem, but i have rerun it and everything coms up OK.
3. According to the first technical report the creation of the snapshot has taken around 40 minutes. Kindly collect a couple of spindumps during the creation of a snapshot next time.
Snapshot creation isn't an issue, as bad as deleting snapshots. It gets to the end of the progress bar in a minute and sits there for a while, but the total process takes only a few minutes (unlike delete).
Additionally, in you last email you've mentioned: "The delete took well over 1 hour, I went to bed after an hour and it was at 44%." I may presume that you're referring to the snapshot deletion, am I right?
Yes, that's the problem, not creating snapshots.
And as the last part, perform the command you've used for testing with one addition, the second file name shouldn't be the same, e.g. "copy_Windows 10.iso". According to the previously provided command, the Windows 10.iso file has been copied into itself, e.g. time cp "Windows 10.iso" "copyWindows10.iso"
No, that was not the case: Windows10.iso was copied to Windows (SPACE) 10.iso.

Then:

While we were waiting for an update from your side I have had another discussion regarding your case with the Engineering team and I've received the following recommendation which could help to increase the speed of deleting snapshots.

Since you're developing inside the virtual machine and presumably compiling projects and due to the fact that TRIM isn't enabled in the virtual machine settings as a result with a high possibility, there are a lot of free information blocks being created as a result of compilations thus increasing the size of the virtual disk. E.g. the size of the disk is 100GBs and the actual information is only for 30 GBs there the rest are free blocks there were the files before/after compilations.

The recommendations are as follows:
1. Create a backup of the virtual machine and shut it down.
2. Merge all snapshots using the Terminal command:
prl_disk_tool merge --hdd /Users/kevin/Virtual\ Machines/Parallels/Parallels\ Windows\ 10 Guest\ Development\ XE10\ Community.pvm/Windows\ 10-0.hdd
If the command won't work, copy paste the first part of it as is 'prl_disk_tool merge --hdd' (without quotes) then add space and using Finder go to the folder /Users/kevin/Virtual Machines/Parallels/ then right-click on the virtual machine file > Show Package Contents, then drag and drop hdd file into the Terminal window.
3. Then perform disk space reclaim: In the Parallels Desktop Control Center press cogwheel button near the name of the virtual machine or right-click on the name > Configure
On the General tab perform reclaim and wait until the process is finished.
4. Then switch to the Hardware tab > Hard Disk and expand Advanced Settings drop-down menu and enable 'Enable TRIM' option.
5. Create a snapshot on a stopped virtual machine and then continue using SmartGuard feature.

Once you had time please follow these recommendations and reply us back with the results.

And now:

Thank you for waiting. I can confirm that we've received your last reply.
About the pictures you've seen in Manage Snapshots window, they were leftovers of the merge process. Merge command has merged available snapshots and left their thumbnails and descriptions. I'm sorry, I've missed that part in the previous email.
Frankly speaking, it's quite strange that you've received a notification what the virtual machine isn't located on the SSD drive although it's located on it.
This situation also worth sending to the Engineering team for investigation.
For that purpose we need a fresh technical report collected on the running virtual machine, this would be enough for this part of the investigation.
Additionally, a fresh technical report will contain all timings of the operations you've performed following our suggestions.

Regarding your request about the SmartGuard scheduler, I've added it to the existing feature request and informed the Engineering team.
Moreover we would like to hear the results of snapshots removal created by SmartGuard feature from you after performing our suggestions.

We're looking forward to hear from you soon. If we won't hear from you around the middle for the week we'll send you a short follow-up email.

Kevin

 

Few more update ons my end.
I'm using Mojave with Parallels v13 on a MacBookPro 15 mid-2014 with a 1TB OWC Aura drive
The VM is a 4 years old Windows7 machine which has seen many install and uninstall of various programs - and mostly used for developing using windows only tools (like Visual Studio and Keil)

I've rebooted my Mac, disabled smart watch and manually tried to delete the snapshots while the VM is off.
The performance difference was immense.
So I continued to reclaim (now that snapshots were gone) - 6GB reclaimed.

Turned SmartWatch up again, booted up the system - will report if there any speed difference in the next few days.

 

After a week of letting smart guard collect 3 snapshots and with my baseline snapshot, ie. 4 in total, I deleted the second (middle) snapshot as a test. It took 3 minutes to delete. here's my response back to parallels support:

I have sent the technical report, ID: 280965633

As noted I wanted to get several smart guard snapshots to test a delete. I now have a weeks worth of snapshots, the first one I took after merging/deleting all snapshots and three created by smart guard.

I deleted the second snapshot (SmartGuard2 in the list) so that it was in the middle of the snapshots I had. The snapshot delete took about 3 minutes (as opposed to 3 hours before):

FIRST Snapshot -->Smartguard1-->Smartguard2-->SmartGuard3-->Current

So the deletion time now 'seems' to be excellent (by comparison to before). Can you confirm that, if the snapshots start to take a very long time to create/delete, the process to follow would be:

1. Stop SmartGuard
2. Shutdown system
3. Merge and delete all snapshots
4. Reclaim any disk space
5. Ensure Trim is enabled for VM HDD
6. Take a baseline snapshot
7. Restart SmartGuard

Based on what you see in report: 280965633, I believe you can close this issue.​

If I hear back with confirmation of the above process, I'll respond with any changes.

Kevin

 

A lot of confusion could be resolved by with a simple prompts saying "deleting a snapshot can take 60 minutes or more due to the complexity. Please be patient, don't restart, thinking the process has hanged. Also do this at night so half your work day wont be wasted."

 

but it should be easy and fast to delete all snapshots

 

Snapshots are the saved state of the virtual HDD which contains data when a snapshot is deleted all the data will be merged with the previous snapshot or the default snapshot. So the process is time-consuming. We can use a terminal command to merge all the snapshots.

 

Is merging all the snapshots fast? What is the command? Then I could delete just one snapshot. I don't see why there is not an option to delete them all.

 

Hi, you can find more info here

 

Hey Parallels, it'd be solid if you didn't outsource your support team to the world's second most populous country.

 

Hey Parallels support, this goes with tech report #346071071.

I tried deleting a snapshot and so far it has been over 10 hours and it's still processing! Nothing looks hung, but these processes are hovering around:

• Parallels Desktop ~10% of CPU
• prl_disp_service ~90% of CPU

Is there any way to cancel the process without losing any data from the "current state"?

 

You cannot cancel the delete snapshot process. To make sure the process is merging the data, you can right-click the PVM file and select "Get Info" which will show the reduction in size.

 

It eventually finished after 11 hours. Please consider improving performance in future versions.