virtualbox.org

I have a VM with a normal fixed disk which has accumulated over 50 snapshots. The VM is running fine so I'd like to merge all the data back into the base VDI removing the accumulated snapshot files.

In the past I've constructed a script using VBoxManage to delete each snapshot, one at a time, and run it overnight. This works well. However, the scripts tedious to construct and I do this fairly often.

Is there another way I could do this more easily, that could run during the night unattended? I was hoping for a single 'delete all' command right in the VBox GUI or using VBoxManage, or highlight multiple snapshots within the GUI and issue the delete on them all at once. No joy finding either one.

I thought about cloning the last snapshot VDI with either VBoxManage or the CloneVDI tool, but these are fixed VDI's and they're large. Both methods require extra diskspace to hold the new VDI until it can be registered and replace the old VDI and accumulated snapshots. In the case of CloneVDI, one more step to convert back to fixed. That's doable, but I'm unsure what happens to the 'current state' when this is done? Is it lost?

Please let me know if you have any ideas for easily automating this process, to run overnight unattended?

Kind regards,
--appyface

As far as I know, cloning is the only quickest way to do what you want.

appyface wrote:I'm unsure what happens to the 'current state' when this is done? Is it lost?

The current state file appears in the snapshot folder as the most recent "snapshot file" (using the term very loosely). If you clone the current state file you get the most uptodate version of your disk. Current state should not be confused with the save file for a suspended VM. The former is just the latest differences for a single disk image, the latter is basically a core dump of the VM, with memory contents, CPU registers etc. You should completely shut down (not suspend) a VM before cloning it, so the save file issue doesn't arise. This is necessary to ensure that all cached disk writes are flushed to disk.

I can't leave this without commenting... a fixed sized base image with snapshots seems like a strange monstrosity to me. I can appreciate (without agreeing with) the paranoia behind using the simplest possible image format, but to use that and then use snapshots... is IMHO perverse. You end up with the worst of all possible worlds in terms of reliability, performance, and host disk space hogged.

So my recommendations are: clone your disk image to a single dynamic (compacted) VDI - and leave it dynamic until you can produce hard numbers to justify any other course of action. Preferably use CloneVDI as it has better optimization features. And stop using snapshots. From now on if you want to "snapshot" your VM, just make a simple copy of your VDI and store it in offline storage. No more host disk space worries, and you should notice a big improvement in performance.

mpack, I appreciate your concerns, but if you want to educate in general about dynamic vs. fixed disks, please use your own thread. If you wish to discuss my specific reasons for using fixed disks, I would very much appreciate you asking me for my reasons first. Thank you.

The disk space needed to go the 2 or 3 copies route is significant (these disks are 220G+ in size, and full). I have a good bit of free space available so while this is a doable alternative, it does limit the number of VM's I can process concurrently. Thank you for the information regarding the current state and especially for the clarification of suspended VM states. That makes me feel more comfortable scripting out this approach and trying it out.

My practice has been to take one more snapshot after full shutdown (not suspend) of the VM, to serve as 'insurance' that all current state data is captured into a 'deleteable' snapshot. If I understand what you wrote, this is an unnecessary extra step. Is that correct?

Current method is to use a regex script to read and strip what I need from the VM's XML file, outputting a temporary custom script containing all the VBoxManage snapshot delete commands, which I then submit. When it finishes I delete the temporary script and it's all done. So while it's not a terribly involved effort, it does rely on accurate generation and use of temporary custom scripts.

Unfortunately the UUIDs of the snapshots are not the same as the UUID's of the corresponding hard disk VDI's, otherwise I could simplify this a bit by using a script loop to pick up the filenames from the snapshot directory and strip the UUIDs to feed to VBoxManage commands. But that still requires constructing a temporary custom script to do the processing.

A directly usable script that can be passed, for example, the name or UUID of the VM only would be preferable. Seems like there ought to be a way to do this, but I couldn't find it... If that is true, is there a suggestion area where I can submit this as a request for possible inclusion in VBoxManage? Something like: Kind regards,
--appyface

appyface wrote:mpack, I appreciate your concerns, but if you want to educate in general about dynamic vs. fixed disks, please use your own thread. If you wish to discuss my specific reasons for using fixed disks, I would very much appreciate you asking me for my reasons first. Thank you.

I offer help and get an arrogant rebuff? Note that I was very careful to answer your questions first (as best I could) before querying your general plan. If that is offensive to you then... goodbye, I'm outa here!

As far as 'offering help' -- your solution for me was to stop using fixed disks (I already know that is not possible in my situation), stop using snapshots (I don't think that is possible and still meet my requirements, but I would be willing to explore alternatives as I'm not positive about that), and to increase the performance of the disks (not a concern at the moment and not part of my question). 'Stop using snapshots' might be possible but I'd have to have more information about how my requirements could be met without them and without introducing another downside.

My response neither arrogant nor a rebuff, I asked for your respect in my thread. That you choose to see my intentions differently actually furthers the reason I requested your respect. But I am OK with your decision to never 'help' me again.

To others reading here: If what I wish to do is not possible, is there a way I can make suggestion for the feature? If I missed find the procedure to follow, please point me there and I'll follow it up. Thank you,

Kind regards,
--appyface

If you click on the "jump to" box at the bottom of the page you can link to the "Suggestions" forum.

I would not rate you suggestion as likely to win support. It is too specialised to warrant the effort required.

BillG,

Thank you for the info, I see the 'jump to' box. (Couldn't find it at first because it doesn't present on the main board index page or while replying to a thread.)

Kind regards,
--appyface

And now I see the 'jump to' link takes me to the 'Suggestions' forum on the main board. I didn't know it was for virtualbox suggestions, I had assumed it was a place for *forum* suggestions (that's the purpose of 'suggestions' forum on some of the other boards I frequent). Bad assumption on my part, I should have looked in there. Thanks again.

--appyface

I've had to do this more than once so I whipped up a GUI to do it, if you're interested:
https://github.com/c0state/VirtualBox-S ... letion-GUI

The app uses .NET and is written in IronPython.
It uses VBoxManage to query for the VMs and snapshots--a bit hacky but easier than using the VBox API.
It works on Windows for now (you'll need IronPython), but with some minor work, should work on OS X or Linux as well (with Mono).

Disclaimer: I make no guarantees with respect to this software.

@stephen_liu

I'm not sure who you're responding to... but if it's me I already create scripts from the VM's XML file using regex (see my rather lengthy post above at 18. Aug 2010, 05:23, paragraph 4 for details).

The improvement I'm looking for, is for a single VBoxManage command (example, "VBoxManage <vmname> merge all"). Something that doesn't use any specific or dependent parameters other than the VM name.

The end result I'm looking for, is the base to end up running equivalent to how it runs in its "current state" while getting rid of all snapshot files and any references to them. In other words, if I were to 1) clone the current state of a VM (which would give me a new VDI/VDK base with all changes in "current state" included), then 2) detach the original base and snapshots from the VM, removing all references to them and delete them from OS filesystem, then 3) attach the new cloned VDI/VDK to the VM. That accomplishes what I'm after (ideally with the UUID not changing). Much easier to me is a one-line non-specific VBoxManage command that has VBox handle this for the VM "in place".

Kind regards,
--appyface