Can't run VBox VM anymore after deleting snapshots

[systemdlete]

I am now unable to launch a VM that was running just minutes ago. Part of this could be my own doing as I will explain.

The VM had been running for several days when I decided to shut it down to do some reconfiguration. I wanted to add a new virtual disk to the VM. So I removed it using the Vbox GUI, then rebooted the VM just to make sure it would still boot. The reboot without the removed disk worked without a problem.

However, I could not delete the disk. In the media manager dialog, I could see that the disk had snapshots attached to the VM. So I proceeded to remove as many snapshots from the VM as possible, hoping that this would free the disk to be completely detached from the VM, and thus, I would be able to remove and delete that disk. This process was interrupted after many minutes during the deletion of one of these snapshots with an error message.

Worried that I may have corrupted the VM, I tried to launch it just to see if it would run, but that failed. Several more attempts also failed. I am convinced that the VM is probably ruined. Even after re-attaching the removed virtual disk, it still will not boot.

(It's OK, though. This is a test machine and a VM used for development of some local programs I wrote. I have backups and source repos on a different hardware host. And I think I can still attach the remaining disks to a fresh VM to copy files over, but that remains to be seen. In the worst case, I have backups. I'd still like to see if I can restore the VM, just for convenience.)

All of this occurred on a machine with 32GB memory, plenty of disk space, with a Thuban Athlon II X6 processor. The host is running Devuan Chimaera, as was the VM. VBox 6.1.42.

Attached is the log from a recent attempt at booting the VM. As always, thank you for your help. Again, this might be own dumb fault.

[scottgus1]

This process was interrupted after many minutes during the deletion of one of these snapshots with an error message.

This is a test machine and a VM used for development of some local programs I wrote. I have backups and source repos on a different hardware host

Kudos to you for having backups! Due to the error (which we can't diagnose because we don't have the error message text) the VM may require a restore from a backup.

Snapshots make a guest more delicate and do not work as backups. They are similar to Windows' System Restore points: they are point-in-past-time markers, not extractable, useless without the base system in place, but easier to corrupt because the files are accessible on the host drive. They do not store "files", like a backup folder would. Virtualbox snapshots store changed disk sectors, which may or may not contain the entire file. They should only be used on guests you're experimenting with and with data you wouldn't mind losing. (The forums are replete with users destroying their important data because they did something wrong with a snapshot. Additionally, a host glitch while deleting a snapshot can kill the VM.)

[systemdlete]

So no idea what MIGHT have happened, based on the scenario described? If not, OK.

However, if removing a virtual disk that is tied to a snapshot of the VM, maybe Vbox ought to at least warn the user before destruction can occur because of that. It really just did not occur to me; I had forgotten I had snapshots on that particular VM. I don't think anyone should expect a user to recall such a thing before proceeding to damage a VM unintentionally.

I am not saying Vbox is necessarily the culprit here, but a warning would have been nice. I am just relieved that it was not a critical VM and that I have backups of my own work. Which BTW, I do not have backups of the VM itself, only the data and programs I wrote within the context of the running VM. When I mentioned backups, I just meant that my work was not lost, even if the VM was.

[systemdlete]

One other thing... the snapshot that the log indicates is missing or damaged is not even part of the virtual disk that I had detached. It is part of the first of the 3 disks originally attached to the VM. I would think that if vbox were to complain about missing virtual devices, it would only complain for those that are connected to the VM configuration at boot time.

I see there are a total of 9 snapshot vdi files in the Snapshots subdirectory of the VM storage, but the media manager interface is showing a total of 10. The missing file is the one in question. I have no idea at all why that snapshot is missing--I never touched any of the files in Snapshots, nor anything having to do with the first virtual disk. Again, it was the 3rd virtual disk I had detached, not the 1st one.

Now, I WAS in fact deleting snapshots when the error message appeared. If the snapshot (the missing one) is associated with the 1st disk, there should not be a problem having detached the 3rd disk unless there is a problem with how snapshots are managed, or some esoteric bug in the host file system, etc.

Even re-attaching the 3rd disk, just as a sanity check, does not correct the problem. See https://imgur.com/D6YGgi9.png for a view of the media manager.

[systemdlete]

Another other thing...

This VM in question is the same one that I had briefly tried running under vbox 7.0.6 in order to see if a problem I was having (viewtopic.php?f=7&t=108421) might go away under the more recent version. It didn't, and I was not ready to upgrade the works just yet. So I reverted back to 6.1.42.

And I just know that that could be a problem right there. In fact, I think there may have been an advisory posted in the forum about this very issue. Whether my problem in this thread is in any way connected to having upgraded, run the VM, then reverted and run the VM again I cannot say.

[scottgus1]

Pictures can be posted using the forum's Upload Attachment tab.


I haven't seen your picture yet, I don't want to see whatever smut the picture-sharing site might advertise in the sides.

Why did Virtualbox let you do what you did? We don't yet exactly know what you did, unfortunately, we can only go on your description of what you did. You may have missed something. But Virtualbox is a powerful tool, and it can be used in ways we can't yet imagine. I'm not a snapshot user, so what's good and not good snapshot practices (aside from integrity-confirmed backups wink wink) are out of my ken. Could be that what you tried is perfectly acceptable and something else happened or went wrong.

And our commodity hardware computers aren't server-class devices like Amazon and Google use, with fault tolerance out the wazoo. Building a house of snapshot cards on a wobbly table may not work so well in the long term.

Since you had an error come up while deleting a snapshot, and Virtualbox now complains of a missing snapshot, you have only two options:

1. Restore the whole snapshotted VM from a backup (Which you actually do not have; trapeze without a net is exciting until you miss. Chant with me: backup, backup, backup...)

2. Use forum guru Mpack's CloneVDI to make a clone of the latest snapshot disk file that CloneVDI won't error on, then use that clone disk file in a brand-new VM. Some more recent data may be missing.

[systemdlete]

Again, I do NOT have backups of the VDI files, so a restore of such is impossible. Sorry if that was not clear.

I will file a bug to have vbox issue a warning when user attempts to remove a drive which has snapshots that could impact the integrity of the VM. I am a bit surprised that this is not already protocol.

[scottgus1]

Again, I do NOT have backups of the VDI files,... Sorry if that was not clear.

Regrettably, that was perfectly clear. Thus:

1. Restore the whole snapshotted VM from a backup (Which you actually do not have...

But there is always option 2:

2. Use forum guru Mpack's CloneVDI to make a clone...

[systemdlete]

I'm not sure why you keep referring to VM backups. You even state that you know I don't have them.

Thank you for your help. I think I will file an enhancement request and leave it at that. And I know that it might not get immediate attention.

[fth0]

From your description in the initial post, it's not clear to me what you really did, and I also do not understand what you mean by:

I will file a bug to have vbox issue a warning when user attempts to remove a drive which has snapshots that could impact the integrity of the VM.

Please try to give an example how to reproduce the issue.

[scottgus1]

I'm not sure why you keep referring to VM backups.

Those are big hints to start making them. Look at the forest, not only the trees.

As fth0 says, we need to know exactly the steps you did to check what Virtualbox does in response. If there is no reproducible method to trigger the condition you saw, then there is nothing to tell the devs and no reason for the Bugtracker ticket.

And please don't respond with "I told you above". Tell us again, numbered step by numbered step.

[systemdlete]

I put in an enhancement request. The idea is for virtualbox to warn the GUI user if they try to remove or delete any virtual disk or snapshot from a VM in cases where doing so could corrupt the VM. I did not file it as a bug (but I guess vbox devs are free to change it to a bug if they wish). The issue here is ensuring the integrity of the VM regardless of if/when the user decides to detach or attach virtual devices.

As far as backups of the disk images, I see no reason to do that. I am already backing up my own work within the VM using a standard backup utility, and I do this for any and all VMs which contain content I am concerned with preserving. To backup vdi files would take a lot of disk space and time.

[scottgus1]

To backup vdi files would take a lot of disk space and time.

It would also render such questions as the initial stance of this topic unnecessary.

"I bunged up my VM! Bummer! Well, pull out the backups. Back in business! "

Drive space is cheap.

[fth0]

I've re-read your ticket 21510, this thread and the test-chimaera-2023-02-19-03-32-48.log file, and I have roughly understood what you did. I also appreciate the amount of details that you gave! But:

The idea is for virtualbox to warn the GUI user if they try to remove or delete any virtual disk or snapshot from a VM in cases where doing so could corrupt the VM.

The difficulty with this idea is as follows: VirtualBox already prevents the user from removing or deleting virtual disks or snapshots from a VM when it knows that it wouldn't work as expected. What you've experienced is an unexpected behavior (bug). How should VirtualBox warn the user when it doesn't know about a danger?

FWIW, I can generally add/remove virtual disks to/from a VM during its lifetime, take snapshots in between and remove them later. There are many possible sequences of events, and you've experienced one that leads to a failure. If you cannot give instructions to reproduce the issue (which is perfectly ok!), I don't expect anything to happen.

[systemdlete]

I've re-read your ticket 21510, this thread and the test-chimaera-2023-02-19-03-32-48.log file, and I have roughly understood what you did. I also appreciate the amount of details that you gave! But:

The idea is for virtualbox to warn the GUI user if they try to remove or delete any virtual disk or snapshot from a VM in cases where doing so could corrupt the VM.

The difficulty with this idea is as follows: VirtualBox already prevents the user from removing or deleting virtual disks or snapshots from a VM when it knows that it wouldn't work as expected. What you've experienced is an unexpected behavior (bug). How should VirtualBox warn the user when it doesn't know about a danger?

Right, which is why I said, in my report, if this is a bug, then feel free to change the type of report. Of course. I was just trying to avoid being accused of covering too many cases--one thing I've learned over the years is that not everyone agrees to what the limits of safety ought to be, that's all.

FWIW, I can generally add/remove virtual disks to/from a VM during its lifetime, take snapshots in between and remove them later. There are many possible sequences of events, and you've experienced one that leads to a failure. If you cannot give instructions to reproduce the issue (which is perfectly ok!), I don't expect anything to happen.

I deeply apologize for not at least attempting to copy the error message. At the point at which it happened, I figured it was probably just one of those instances where a momentary lack of resources or the like was at work and that re-trying (after carefully checking resource availability, of course) would clear it out. I was wrong, obviously.

I think we can agree that I hit some kind of corner case and encountered a bug. I am not sure exactly what should be done. For the moment, however, I am trying to restore from (internal) backups so I can get back to beating up the poor VM with more testing, which is why I created it in the first place! (I assure you none of this testing involves vbox itself; this is just testing some tools I wrote.)