Opened 12 years ago
Last modified 8 years ago
#11726 new enhancement
Add ability to flush (merge) Current State into the parent snapshot
Reported by: | bostjan | Owned by: | |
---|---|---|---|
Component: | GUI | Version: | VirtualBox 4.2.12 |
Keywords: | merge current state parent snapshot | Cc: | anonymous1 |
Guest type: | all | Host type: | all |
Description
I have encountered a complex situation which can be resolved by this.
I would like to use VirtualBox with fast disks to store the Current State on. By fast disks, I mean RAM disks (or small SSD disks if that's what someone has available).
When using RAM disks, the space is very precious. But even when we buy a lot of RAM, it still takes long to copy big VMs to it, as the copy is performed from slow drives. Equally slow is copying the changed VMs back when we are done.
Therefore, copying is not ideal. The idea is to keep big VMs in their directory on an SSD disk, while the snapshots directory is relocated to the RAM disk. Like this, non-changing data is read occasionally, but all volatile data is accessed with almost no latency. Also, an SSD disk is spared a lot of wear and tear (assuming using SSD disk as 'the slow' disk).
The funny thing is, that creating such a setup is easy with Virtual PC, because user has total control over the differencing disk chain and the "undo" feature. I tried to do it with VirtualBox GUI and VBoxManage, but couldn't. Maybe someone will correct me, but as far as I know, it is not practically possible with the current VirtualBox.
There are several issues.
- Currently, one may keep only one snapshot per machine, as this is what would actually stay on the SSD. All others would be moved to RAM disk and become volatile. While issue 1 is annoying, it can be bypassed by creating linked clone VMs. Like this, when each machine is kept at maximum of one snapshot, it could retain it on the SSD. However, issue 2 crushes this idea as well - linked machines cannot be used.
- All machines need to be independent, even when I would like to use linked clones to represent several states of the system. This is because when I create a linked clone, VirtualBox creates the initial Current State as a sort-of-snapshot. Now, to utilize the RAM disk, one snapshot of course must be created (for Current State to be pushed onto the RAM disk). But even if I assure that the original linked VM snapshot is placed on the SSD, the moment I want to commit some changes, I need to create a new snapshot and delete the old one. And, because the old "snapshot" is not a base virtual harddrive, it gets merged into its child - onto the RAM disk.
Issue 2 is just impossible to solve, as VirtualBox cycles the differencing disks in such a way. Currently, one cannot merge changes from Current State into its parent (it only makes an exception if the parent is the only snapshot on a non-linked VM). Also, not being able to use linked clones, it means full clones need to be used - always. So this also causes wasting a lot of space for big VMs, and takes a long time when creating them. Not to mention unnecessary wear and tear on the SSD, when you use it as 'the slow' disk. Often, you already know you will discard all changes at the end of session, and you don't want the tens of new gigabytes to touch the SSD at all. That's why OS caching is not a suitable replacement, even if OSes would happily use 30 GiB RAM as read/write cache (which they don't!).
This is exactly why RAM disks exist in the first place: to speed up reads, accumulate a lot of writes, and in the end perform only one flush, or (even more often) discard the changes.
The solution. It's pretty simple. For the Current State, add the option "Flush changes to <name-of-parent-snapshot>".
This would merge the changes to the parent disk. Also important: when doing this, neither of the two disks would have its filename, or disk location, changed. Parent receives the changes, and child (the Current State) becomes empty. If the child disk needs to be destroyed in the process, it should be recreated with the same name.
This enables setups which utilize snapshot directories on RAM disks, including using linked clones.
And, it also adds a good option which I believe many people miss (I know I do). Why do we need to do this:
- Create a new snapshot, retype the same name as the snapshot above.
- Delete the previous snapshot.
when we just want to flush some small changes from the Current State to the snapshot above?
The "flush" option would be most welcome for this reason as well, removing the annoying two-step operation, not to mention the expected speedup (it usually takes much longer to merge parent into child, as the child is the differencing disk and usually caries less data).
Naturally, the new option would only display when Current State is changed and it actually has a parent snapshot.
I have opened Ticket #11802 as the alternative enhancement. Much more complex to do in my opinion, but it would be the full-scale solution.
In my opinion, the enhancement suggested here would still be useful in either case.