~/.VirtualBox/VirtualBox.xml problems.

[Markus Duft]

Hey

I now spent a few days hacking back together the media registry... I rebooted my machine, and - oops - the file was back to a version about 2 weeks ago (!!!). i suspect that the problem was that i was running one VM in headless mode (as service), and others through the gui. my suspicion is that the headless vm wrote back VirtualBox.xml, overwriting the intermediate changes... this was really BAD!

onther thing i'd suggest, is that the media registry structure should be pretty much different:

there should be no need to keep all snapshots of harddisks in the media registry; why not do it like all others, and make each snapshot know it's "parent". this way, onlye the VM itself would need to know the "top-most" disk attached to the VM. This would also ease the implementation of the enhancement ticket i just filed (#5136).

Also it seems that if during creation of a snapshot an ISO image is mounted, and the ISO is removed from disk afterwards, the media registry refuses to remove the file from the registry - seems like a snapshot wanting this file locks it somehow...

[Markus Duft]

Replying to mduft:

Hey

I now spent a few days hacking back together the media registry... I rebooted my machine, and - oops - the file was back to a version about 2 weeks ago (!!!). i suspect that the problem was that i was running one VM in headless mode (as service), and others through the gui. my suspicion is that the headless vm wrote back VirtualBox.xml, overwriting the intermediate changes... this was really BAD!

woah... this just happened again with 3.0.8! and this time there was only the GUI in play, no vm running headless. i was happily running approx. 4 VMs. then i powered them off, reverting to the current snapshot (so virtualbox creates a new differencing image for the current state, right). then i closed virtualbox, and rebooted the machine. after this, the media registry is now missing all the newly created differencing disks, created by reverting to the snapshot previously. DAMN! again back to hacking that xml file by hand!

any ideas?

[Markus Duft]

could it be that closing the main vbox window while VMs are running prevents them from writing back their media registry changes? i closed that window while the vms where running, as i already have tons of windows open on all workspaces...

i found this in the vbox.log of an affected VM:

00:08:32.888 ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005) aIID={fd443ec1-0006-4f5b-9282-d72760a66916} aComponent={Mouse} aText={The console is not powered up} aWarning=false, preserve=false

[Sander van Leeuwen]

Sounds strange. Did the GUI or VBoxSVC crash? If not, then there seems to be some file system corruption.

Can you try to do the same, but not reboot in the mean time?

[Frank Mehnert]

To make it clear: Your suspection from the description is wrong. The .xml file is only read / written by the VBoxSVC daemon and only one daemon is running for a particular user.

[Markus Duft]

Replying to sandervl73:

Sounds strange. Did the GUI or VBoxSVC crash? If not, then there seems to be some file system corruption.

i don't think that anything crashed ... no core files, etc.

Can you try to do the same, but not reboot in the mean time?

hmm... i tried the same again (with and without reboot):

boot, load kernel modules start vm close main window revert to current snapshot look at VirtualBox.xml

this time, strange enough, there was a _second_ vdi, parallel to the old vdi which was attached before reverting to the snapshot... :/ so this time, instead of loosing the change, it somehow didn't manage to remove the vdi that i discarded by reverting. the warning i posted above did re-appear in the log, however only once. the last time the warning repeated several times as last lines of the log.

rebooting didn't change anything this time (did it before i read your comment ;)).

i'll keep an eye on what i do, so that i may be able to repro in a smaller test-case than the "i worked two weeks and somewhere in there something happened ;)". i'm aware of that you can't read much out of this tea leaves i'm giving you ;)

Replying to frank:

To make it clear: Your suspection from the description is wrong. The .xml file is only read / written by the VBoxSVC daemon and only one daemon is running for a particular user.

ok, i'll have an eye on which processes are running...

[Markus Duft]

hmm... up until now, i could not repro this problem (although it happend two time before...). i hope this is just because it doesn't happen with my current 3.0.8 anymore ;)

however, one idea i had about the problem is: if i have a headless VM running in the background, and reboot without propperly saving state/shutting down the VM, how does VBoxSVC behave...? could there be a hole in the logic, that makes it somehow destroy things if it gets terminated/killed by SIGTERM/SIGKILL?

Otherwise, i think we can close this issue, and i'll reopen if it really happens again (doesn't look like though...)

[Frank Mehnert]

Please reopen if still relevant.