Author Topic: [SOLVED] Virtualbox - machines being saved, but... not saved after reboot of hos  (Read 4073 times)

Offline CJ

  • Sr. Member
  • ****
  • Posts: 456
Since my fresh install of PCLOS 2010, I have had a problem saving my virtual machine's state... that is, I ask VB to save the machine state, it does so, e.e. it takes its time, the % meter counts up, and the machine state is reported as Saving, then Saved in the VB OSE status overview.

If I start once of the machines again, it restores it from the saved state, but...

After a reboot of the host machine, none of these images are reported as Saved, but instead as Powered off.

First I thought it might be a permissions issue, but since it works prior to a full reboot, this cannot be.

All virtuals are XP sp3.

Please help as this is driving me insane!

Cheers!
CJ
« Last Edit: May 17, 2010, 06:36:37 AM by CJ »

Offline kjpetrie

  • PCLinuxOS Tester
  • Hero Member
  • *******
  • Posts: 4037
Where is the .VirtualBox/Machines folder kept and how is it mounted?
-----------
KJP
-----------------------------------------------------------
PClos64 RC1 on Intel D945GCLF2 motherboard (Atom 330), 2GB DDR2 RAM, Maxtor STM325031, HL-DT-ST DVDRAM GSA-H42N, Amilo LSL 3220T monitor. Also Acer 5810TG (with custom kernel) and Asus eeePC 2G surf

Offline CJ

  • Sr. Member
  • ****
  • Posts: 456
Where is the .VirtualBox/Machines folder kept and how is it mounted?

The Machines folder is in its default place, i.e. ~/.VirtualBox/Machines.

The actual .vdi files have their own partition, which is mounted from fstab (/dev/sda7 /mnt/c-vm ext3 rw,defaults,umask=0000 1 2).

None of this has changed from the previous install, though it should be mentioned that the Machines folder has been copied over manually from the previous install's /home.

Cheers!
CJ

Offline kjpetrie

  • PCLinuxOS Tester
  • Hero Member
  • *******
  • Posts: 4037
Check the permissions and ownership of the Machines folder and its contents. I take it it's not a mount point for a partition or share, then.

Also, have you tried running VirtualBox from a terminal to see whether there are any error messages when saving the machine state.

Do you save other things successfully to your home partition, even after a reboot? Silly question, I know, but it needs to be asked.
-----------
KJP
-----------------------------------------------------------
PClos64 RC1 on Intel D945GCLF2 motherboard (Atom 330), 2GB DDR2 RAM, Maxtor STM325031, HL-DT-ST DVDRAM GSA-H42N, Amilo LSL 3220T monitor. Also Acer 5810TG (with custom kernel) and Asus eeePC 2G surf

Offline CJ

  • Sr. Member
  • ****
  • Posts: 456
kjpetrie, thanks for helping out, much appreciated!

Check the permissions and ownership of the Machines folder and its contents. I take it it's not a mount point for a partition or share, then.
Yes and no - insofar as my /home is on its separate partition... but it is in its default place, if that's what you mean.

Also, have you tried running VirtualBox from a terminal to see whether there are any error messages when saving the machine state.
I tried both starting the machine (VBoxManage startvm "BONZO_XP_ASP" --type gui) from terminal, as well as VirtualBox: no errors given, and all seems fine until the next reboot.

Do you save other things successfully to your home partition, even after a reboot? Silly question, I know, but it needs to be asked.
Yes, no problem there.


Ok, I think we are one step nearer to the problem: I just noticed that one of my machines actually do get saved, even after reboot. (I should have noticed earlier, I don't use this particular machine very often, sorry.)

The difference? The path to the Snapshot folder!
The one that works is saved to ~/VirtualBox/Machines/<machine_name>/Snapshots; the others are set to save to a Snapshot folder on the separate partition where I also have the .vdi files.
I have checked the permissions between the two Snapshot folders - as well as the save files in them - and there is no difference.
Additionally, I can see that the .sav files are being saved to... at least, the last modified date/time stamp does update.
Thirdly, if the permissions were the issue, why would it work until a reboot and then not?

So... what can cause this, i.e. a .sav file that can be saved and read - until after a reboot where it cannot be read?

I guess I could change the Snapshot location to the one in the /home/Machines/etc. that I know work, but I would rather have it on the separate partition... not to mention, I would really like to know why this is going on... if at all I could!

Any ideas? I am stumped.

Cheers!
CJ

Offline kjpetrie

  • PCLinuxOS Tester
  • Hero Member
  • *******
  • Posts: 4037
I would guess the partition is not writeable. Either mounted read-only (check the options in PCC or in /etc/fstab) or it has an error which prevents it being written. An error is highly likely because the system thinks it is writeable until it actually tries to write to it. If you press Esc during shutdown I expect you will see a message about not being able to unmount the partition. Your changes get saved to the disc cache, and can be read back from there, but when the cache goes to write it out to the disc to save it at shutdown - it can't.

At the next host system start-up I would open a konsole, su to root, unmount that partition and give it the fsck -f treatment (fsck -f /dev/sd<letter and number of partition>) and see what that does.
« Last Edit: May 13, 2010, 11:18:23 AM by kjpetrie »
-----------
KJP
-----------------------------------------------------------
PClos64 RC1 on Intel D945GCLF2 motherboard (Atom 330), 2GB DDR2 RAM, Maxtor STM325031, HL-DT-ST DVDRAM GSA-H42N, Amilo LSL 3220T monitor. Also Acer 5810TG (with custom kernel) and Asus eeePC 2G surf

Offline CJ

  • Sr. Member
  • ****
  • Posts: 456
I would guess the partition is not writeable. Either mounted read-only (check the options in PCC or in /etc/fstab)
It is definitely writeable. Additionally, all the changes I make to the machines stored there, get saved (e.g. installing applications, changing drive letters, etc.).

... or it has an error which prevents it being written. An error is highly likely because the system thinks it is writeable until it actually tries to write to it. If you press Esc during shutdown I expect you will see a message about not being able to unmount the partition. Your changes get saved to the disc cache, and can be read back from there, but when the cache goes to write it out to the disc to save it at shutdown - it can't.
Good call, but it doesn't seem so. There are no errors on shut-down; I have tried umounting it after a .sav file write; and as above, changes to the .vdi files go through.

At the next host system start-up I would open a konsole, su to root, unmount that partition and give it the fsck -f treatment (fsck -f /dev/sd<letter and number of partition>) and see what that does.
Again, no errors.


I tried changing the Snapshot location of one of the affected machines to /home/VirtualBox/etc... just to make sure, and all works when that is the locations.
I then tried copying that .sav file over to the separate partition location and changing the Snapshot folder location back to there. I still does not read it after reboot.

Moreover, leaving the Snapshot location on the separate partiotion and saving state again, but - after reboot - copying the 'old' working .sav file (from /home/etc/...) over it; then tried the same before reboot. Made absolutely no difference. It will write it, but it will not see it after reboot.

Both partitions (/home and the vm one) are ext3, no errors reported either.

Only thing I can think of now is to try setting the Snapshot folder to a completely separate HDD (a secondary one), just to try it.
Will do so now - oh, am I getting tired of reboots - and post back.

Cheers!
CJ

EDIT: Forgot to mention... I also tried changing the Snapshot location of the working machine... right as rain, it didn't work saving to the separate partition either. In other words, it must be ruled out that the issue is with the machines themselves.
« Last Edit: May 14, 2010, 08:01:09 AM by CJ »

Offline CJ

  • Sr. Member
  • ****
  • Posts: 456
Only thing I can think of now is to try setting the Snapshot folder to a completely separate HDD (a secondary one), just to try it.
Will do so now - oh, am I getting tired of reboots - and post back.

Ok, I set the Snapshot location to a different HDD with the same result. I think, thus, that we can rule out a HDD write error for good.

Could it be something out of our control, i.e. a bug in VB? I have searched but have not come up with anything...

Unless I missed something, I should have tried all your suggestions. If you have any further ideas, they are of course welcome. Again, thank you so much for your help and time!

Cheers!
CJ

Offline kjpetrie

  • PCLinuxOS Tester
  • Hero Member
  • *******
  • Posts: 4037
I have just tested on my own system and I can save the state to the partition where I keep my VDIs with no problem at all.

What you are getting is bizarre behaviour with files written to a partition vanishing when the machine is shut down. To my mind it is unthinkable the machine would delete them when shutting down, so the only logical explanation is they are not reaching the disc surface, but are being held in RAM of some kind - either a buffer in the machine's RAM or a cache in the disc drive. Hardware failure seems to be ruled out by the fact two discs are affected, and general system or BIOS settings by the fact not all partitions on the disc behave the same, so we need to investigate further.

I think it is unlikely to be specific to VirtualBox, but that's the next test. Can you save an ordinary text file to that partition and see whether it survives a reboot?

Also, please open a terminal, type "mount" without the quotes, and paste the output.
-----------
KJP
-----------------------------------------------------------
PClos64 RC1 on Intel D945GCLF2 motherboard (Atom 330), 2GB DDR2 RAM, Maxtor STM325031, HL-DT-ST DVDRAM GSA-H42N, Amilo LSL 3220T monitor. Also Acer 5810TG (with custom kernel) and Asus eeePC 2G surf

Offline CJ

  • Sr. Member
  • ****
  • Posts: 456
kjpetrie, I am not at the machine just now, but would just clear a thing up: The files themselves do survive the reboot, they are just not used by VirtualBox after a reboot... no, the partition is just fine, also after reboot.
Also, there is no problem saving anything to the partition, text file or otherwise. Even the .sav files get to the full size (and, as mentioned before, the changes made to the machines themselves, e.g. installing new apps, survive the reboot fine).
What I guess (!) I should be looking for is probably more something that lets VB know that is has a saved snapshot, which is gone after the reboot. The only thing that fits would be in the xml files (I assume), but I have checked those as well as best as I can, no joy (they are still in the machines folder on /home/...).

I will post the mount next time I am on the machine, if you think it helpful. As per above, though, I doubt there is a fault there. I have used the exact same setup, mount-wise, since I started using PCLOS some three-four years ago. (It even worked fine on PCLOS2009 with KDE4 too). Even the entries in fstab are a straight copy from previous incarnations.

Actually, the more I think about it, the more impossible the scenario appears! Yet, still it happens...  ???

Cheers!
CJ

Offline kjpetrie

  • PCLinuxOS Tester
  • Hero Member
  • *******
  • Posts: 4037
OK, sounds as if I've been completely on the wrong track.

When you reboot, do you shut virtualbox down first?

I'm just thinking one big change in 2010 is the order in which services start and stop, so if virtualbox is still running when you shut down it might find it is too late to store something away, especially if it's on a partition which has already been unmounted, or the service it uses has already been shut down. Or maybe there's a similar race condition on start up.

What happens if you shut VB down without rebooting and then restart it? Do the saved machines still work correctly then? I expect you've tried all scenarios but I'm just looking for a clue.
-----------
KJP
-----------------------------------------------------------
PClos64 RC1 on Intel D945GCLF2 motherboard (Atom 330), 2GB DDR2 RAM, Maxtor STM325031, HL-DT-ST DVDRAM GSA-H42N, Amilo LSL 3220T monitor. Also Acer 5810TG (with custom kernel) and Asus eeePC 2G surf

Offline menotu

  • PCLinuxOS Tester
  • Super Villain
  • *******
  • Posts: 15515
  • ┌∩┐(◕_◕)┌∩┐
Don't know whether this info helps at all:

Snapshots

    * A snapshot bookmarks the state of the VM (specifically the VM file system) at the point in time the snapshot is made.

    * You return to a previous snapshot by deleting the current state and all newer snapshots.

    * When you create a snapshot, changes to the file system accumulate in the current snapshot file, older snapshot files and disk image files are effectively read-only.

    * If there are no snapshots the VM’s disk image file accumulates file system changes just like normal disks.

With respect to copying the important thing to understand about snapshots is that there is no easy way to copy them, so if your source VM has any snapshot information that you want to copy you first need to merge the snapshot(s) into the source VM’s disk images.
PCLinuxOS 32bit KDE 4.10.4; kernel-3.4.11-pclos1.bfs & 64bit 3.4.38bfs; NVidia GeForce 8400GS 1GB 310.19 driver

Sony Vaio SVE1513A4ESI Laptop, Intel Core i5, 2.6GHz, 6GB RAM, 750GB, 15.6" Intel HD Graphics 4000

Offline CJ

  • Sr. Member
  • ****
  • Posts: 456
With respect to copying the important thing to understand about snapshots is that there is no easy way to copy them, so if your source VM has any snapshot information that you want to copy you first need to merge the snapshot(s) into the source VM’s disk images.

Thanks for chipping in.
As far as I understand it, that is exactly the job of VB (the merging). I have before copied snapshots over without problems but I am not planning to make a habit of it.  :D
Anyway, that was just a small test to try to localise the issue... it wasn't there...

OK, sounds as if I've been completely on the wrong track.
No, you have actually been a big help in narrowing the focus!

When you reboot, do you shut virtualbox down first?
Yes, but I have tried without too, makes no difference.

What happens if you shut VB down without rebooting and then restart it? Do the saved machines still work correctly then? I expect you've tried all scenarios but I'm just looking for a clue.
Yes, then the saved states persist. I have done it several times without problems, hence my initial confusion when suddenly the saved states did not persist over a reboot (it took me a while to realise that was what was actually going on).


As said, I have been running this setup pretty much exactly the same for years, to the best of my knowledge. The more we rule out, the more I get the felling that the issue might be within VB itself. Obviously, not something I am eager to push, but I really can't see any other reason by now.
Would be strange also that noone else seems to have that issue, but maybe people generally just let it run of the /home/... folder.
I don't know... maybe it's time to head over to the VB forums and try my luck there... :-\

Cheers!
CJ
« Last Edit: May 17, 2010, 06:20:01 AM by CJ »

Offline CJ

  • Sr. Member
  • ****
  • Posts: 456
Would be strange also that noone else seems to have that issue, but maybe people generally just let it run of the /home/... folder.


Eureka! I tried again - must have been using better search words - and actually found a match: Apparently, it is a bug within VB!
Here is what one poster had to say (VB forums):
Quote
The problem seems to be caused by not using the standard locations for snapshots etc. Humour Virtualbox and allow it to keep all its files in the standard directory, i.e. c:\Documents and Settings\%user%\.VirtualBox\. Unfortunately VirtualBox wont let you change the snapshot directory unless you delete all snapshots, but it would not allow me to delete the last snapshot! In desperation I uninstalled and reinstalled VirtualBox and then recreated the guest - what a schlep - but at least it now works properly!


Ticket has been raise with priority (http://www.virtualbox.org/ticket/5656).

I guess that is as far as we get just now... at least I found and answer!

Cheers!
CJ

Offline menotu

  • PCLinuxOS Tester
  • Super Villain
  • *******
  • Posts: 15515
  • ┌∩┐(◕_◕)┌∩┐
Hey CJ - at least you've found what was causing it.

If you now consider this post solved, do you wanna enter Solved in the Subject line of your first post. Ta.
PCLinuxOS 32bit KDE 4.10.4; kernel-3.4.11-pclos1.bfs & 64bit 3.4.38bfs; NVidia GeForce 8400GS 1GB 310.19 driver

Sony Vaio SVE1513A4ESI Laptop, Intel Core i5, 2.6GHz, 6GB RAM, 750GB, 15.6" Intel HD Graphics 4000