Virtual machine snapshots - status "changed" strange behaviour

[Miro_R]

Hi, not sure if this this a bug or a feature, but it confuses me so I would like to ask for your help&opinion:

Situation: I have a linux host and linux virtual machines, VB 6.1 up to date from your repository (but I remember I had the same issue with older VM 6.0). I have a VM with a snapshot, the snapshot is restored and the VB shows VM status as "Current" (I use local translation, so I assume it is "Current" in English). Two examples:

1. When I change configuration of the machine while still being off, the current status changes to "Changed" and when I take new snapshot, the current status changes back to "Current". This works as expected.
2. When I turn on the machine, the current status changes to "Changed". I turn the machine off, status is still "Changed" - as expected. I take new snapshot - but even after that action the current status still shows "Changed". Regarding to the fact that the current snapshot was taken from the current state of the machine - so I believe they should be the same.

Is this an intended behaviour? I found snapshots as something very very usefull (thank you, devs!), but I want to prevent any mistakes (eg. unintended running of "unsaved" snap and ruining part of my work) so I want to know if I can fully trust the status label or not. Thank you for your help!

(fyi It sound like an old ticket #6097 [not allowed to use link], but it was solved a long time ago...)

[scottgus1]

I don't know enough about snapshots to be able to answer your questions, but I have read enough about them in the forum to say this:

If you have valuable work in a VM with a snapshot, be very sure to have a robust restorable backup routine in place, not only of the VM, but also of the data inside the VM. Such a backup routine would include:

• full backups of the VM folder and any disk files kept outside the VM folder when the VM OS is fully shut down, not save-stated.
• a 3rd-party backup software inside the VM to handle backing up the VM's OS, same as would be done in a real PC.
• a 3rd-party live backup routine running inside the VM OS to live-save the data you think is important. (Dropbox/Google Drive/OneDrive/open-source cloud drive to a LAN PC/etc)

The reason for this is that snapshots make a VM more delicate and the forum is replete with users losing their VMs because something either pebcak- or host-PC-induced went wrong.

[Miro_R]

Thank you for your reply, I understand that snapshots can have their issues, however I believe that this is more related to VM Manager (and its way how to check the current snapshot status) more than to the snapshots themselves.

(fyi My data are loaded from external storages separated from the VM itself. I use snapshots for "versioning" my working environment, snapshots allows me easy testing and clean restore in case of any issues during work. And I have to say that they proved themselves during everydays work suprisingly rock-solid so far! I admire the devs that they're able to keep such complicated app working...)

[fth0]

I've seen a similar issue myself regularly, but don't remember if it happened after a VirtualBox update or a VirtualBox Guest Additions update. I never bothered to investigate it myself, because I found an easy workaround: I just create two snapshots in a row and then delete the first of them.

Please reproduce the issue, and immediately afterwards create another snapshot of the new current state. Close the VirtualBox Manager (and all running VMs) and provide a zipped copy of the .vbox file. Afterwards, you can restart the VirtualBox Manager and delete the intermediate snapshot.

[Miro_R]

Thank you. I usualy simply restore the snapshot right after taking it (what removes the confusing "changed" status). Do you believe that creating of another snapshot and deleting the previous has any advantages? Or it is more a matter of personal preferences...

I can try it, should I create a new support ticket after that? BTW It is definitely not related to the Guest Additions as I do not use it.

[fth0]

I usualy simply restore the snapshot right after taking it (what removes the confusing "changed" status). Do you believe that creating of another snapshot and deleting the previous has any advantages?

How should I assess that without knowing what the differences between the settings are? You're keeping the intermediate settings, I'm keeping the newest settings. That's why I asked for the .vbox file at a specific point of the specified procedure.

[Miro_R]

Well, maybe you're familiar with the VB Manager's code and functionality more than I am - I don't know that's why I ask what leads you to use a different routine. But I understand that vbox file may provide us with some answers.

I've done the test as recommended by you and spend some time testing... and I'll save a bit of your time reading the logs: It is probably related to using VBoxVGA graphic controller - the "change bug" occures when using VM with VBoxVGA (no 3D, no GA) after loading splashscreen of the OS (Linux Ubuntu) and then turning the machine off. Everything in .vbox file is the same with two exceptions: 1) uuid of the disks (I assume that both curent machine and every snapshot should have their unique disk id) and 2) <GuestProperties> tag shows three new lines with "HostInfo" properties, namely "VBoxVer", "VBoxRev" and "VBoxRexExt". If you turn off OS before an initial splashscreen of OS or make another snapshot after the "change bug" occurs (as adviced by you as a workaround), the additional <GuestProperties> lines do not appear/disappear in the .vbox and the status field works as expected. Accoding to few test rounds it also looks like that everything works ok while using VMSVGA controller.

My guess is that VBoxVGA uses Guest properties that VM Manager does not expect and due to their presence it assumes that the snapshots are different and throws a "state changed" status. I was even able to simulate a situation when "changed" appears right after restoring the snapshot

[fth0]

When updating to VirtualBox 6.1.32, I also encountered the issue again. In my case there are only additional GuestProperty attributes, all 9 being flagged as TRANSIENT. Does this match your observations?

[Miro_R]

Thank you for your advices and help, tfh0. I confirm, I will just specify that I have only three lines (probably depends on my individual configuration) and with two attributes TRANSIENT (I am not at the PC right now and I forgot to resend the log, but I am 97% sure) and RDONLYGUEST. After viewing a documentation it looks like a bug to me - I understand, that these values should not be stored in .vbox when the VM exits.

After my first tests it looks like that with Linux guest I can use different graphic controller and everything will be fine. But with regard to users of other operation systems who will probably face the same issue I can submit a new bug ticket. If it helps, I'll be happy to help.

[fth0]

AFAIU, you and me have found different ways to trigger the same unwanted behavior. I'll start with describing the common part first:

When the first VirtualBox frontend (e.g. VirtualBox Manager, VBoxManage) or the first VM (e.g. VirtualBoxVM, VBoxHeadless) is started, it automatically starts a background service named VBoxSVC that reads all VM configurations (.vbox files) into its internal memory. While a VM is running, additional transient guest properties are added to VBoxSVC, and when a VM is terminated, the transient guest properties are usually removed from VBoxSVC again. In the cases of the unwanted behavior, the transient guest properties are kept in VBoxSVC, but are not written back to the VM configuration on disk. When creating a snapshot in this situation, the new snapshot contains the transient guest properties and the new current state doesn't, leading to the changed flag.

Workarounds are (1) reverting to the new snapshot, (2) creating another snapshot and deleting the previous one, or (3) stopping and restarting the VirtualBox Manager before taking the new snapshot. (3) only works if the VirtualBox Manager is the last VirtualBox frontend and VirtualBox VM, because then the VBoxSVC background process is automatically terminated after 5 seconds and the transient guest properties get lost (as wanted).

In my case, I've identified two workflows to trigger the unwanted behavior: (a) Starting a Linux or Windows guest, inserting the VirtualBox Guest Additions CD (GA), installing the GA, rebooting the guest OS as requested by the installer, and shutting down the guest OS from within the guest OS. (b) Starting a Windows guest, inserting the VirtualBox Guest Additions CD (GA), and shutting down the guest OS from within the guest OS. Both workflows have made it into the internal bug tracker of the VirtualBox development (invisible to you and me ).

Regarding your workflows of triggering the unwanted behavior, I couldn't reproduce or make a connection to the VBoxVGA graphics controller myself. I'm not sure if it's worth the effort to create a ticket in the Bugtracker, or to wait if the findings reported by me lead to a general solution ...