Oliver's picture

Hi,

congratulation for your great work. It saves a lot of time. Thank you.

I have one issue with my VirtualBox appliance: If the TKL14-Debian8-64bit-guest is running and I standby my host and wake it up again, the reboot/shutdown procedure of the guest can take a lot of time (let's say 3 min up to 7 min).

The message comes up: A stop job is running for LSB: Apache2 web server (x min / 5 min). Often it takes much longer.

Is there an chance to avoid this delay?

Best regards, Oliver

Forum: 
Jeremy Davis's picture

It sounds like your host OS is not properly dealing with the VM when it goes into standby. Essentially this issue is caused by a combination of TurnKey servers being built to be constantly on; and your OS not being aware of what it should do with the running VM. Back when I used to use Windows (7) I recall having a similar issue, although I found that mine often resulted is VM disk corruption too (probably 1 in 5 standbys required a fsck on the VM vHDD; sometimes actually requiring me to restore to a previous snapshot because it was so broken). Assuming you're also using Windows then it sounds like there has actually been some positive progression! :)

I ended up configuring Windows to also put my VM to sleep (i.e. power off but saving the state via a snapshot) prior to going into standby. It meant that everytime my computer came out of standby I had to restart my VM manually but that was much better IMO than having to fix it. I don't recall the steps that I used but I'm sure you will find something via google.

Please let us know how you go and post back with the info if/when you work it out.

Oliver's picture

Thanks for your input.

The host is Windows 8.1.

Sometimes I think, it's not a matter of the host's OS. Sometimes I think, the Linux screws up realizing maybe some timers differ... But this is only an unproven assumption ;-)

I'll let you know if there is progress...

Kind regards,
Oliver

Jeremy Davis's picture

My previous post does read like I was blaming Windows. I didn't conciously intend that and I apologise if that was the impression that I gave. For background I'm not a big fan of Windows. I was for a long time, but for the last ~3-4 years I exclusively use Linux (but still work as SysAdmin on a network of ~10 Windows PCs). Whilst as a user it's a fine OS; since my full switch to Linux (and my experience with sysadmin on multiple Win desktops) I generally find Windows frustrating and painful to work with. Regardless I'll try to put my preferences aside and be objective and fair...

4 factors

IMO there are 4 factors that are contributing to your issue (which for the record I still think is related to virtual harddrive corruption). None of them are problems per se, it's just how they interact that causes the issue:

1) A headless server is intended to be always on. It is not designed to go to "sleep" because it makes no sense. Under normal circumstance there would be no way to wake it up again! It is rare to even need to reboot a Linux server.

2) Windows 8.1 OOTB is not optimised (or even designed or configured) to run as a hyper-visor and/or host virtual machines.

3) VirtualBox is a 3rd party; cross-platform virtual machine hosting software that happens to support Windows. It is essentially (IMO anyway) "consumer grade" software. It is not optimised (nor configured) to be ideal for running server type OS, nor is it optimised for any particular OS or OS version (AFAIK anyway - please correct me if you know different).

4) Strictly this is probably a sub point of 3. Anyway, by it's nature a VM platform and the VMs runnning on it are much more complex than most other software processes. Because lots of things are constantly going on in a VM the normal way that an OS sleeps is sub-optimal for a VM platform or the VMs that are running. It's no accident that most Enterprise level virtualisation software is designed to run on an "always on" server OS.

Despite all these shortcomings, as a general rule VirtualBox runs pretty sweet on all current versions of Windows and hosts TurnKey VMs pretty smoothly and stably too!

Ideal config

IMO, ideally when the host PC goes to sleep it should power down the VM (saving it's state in the process). This will add an extra few seconds to the time it takes the OS to go to sleep, but shouldn't be too significant. Doing that eliminates the risk of the VM having HDD or RAM corruption when the host goes to sleep.

If everything is configured and working as it should, then when the OS wakes up; the VM should be either powered off (if it was powered off prior to OS sleep) or powered off but with a saved state (if it was powered on prior to OS sleep). If it has been configured awesomely then the VM will auto resume it's previous state (i.e. start if it was running prior to OS sleep)!

When the VM starts after OS wakeup (either from manual start or auto one) it will take a few seconds to load the RAM data from disk (but shouldn't be too significant). When that's complete it should be in exactly the same state as it was prior to sleep. In other words there should be no need for the VM to boot; services to stop or start; etc. It should be as if it was never turned off...

That wasn't my experience of running TurnKey VMs on VirtualBox on Windows 7. And it doesn't sound like it's your experience of running TurnKey VMs on VirtualBox on Windows 8.1 either! Under the regime that I suggest the server never really starts or stops (so services shouldn't be starting or stopping either).

FWIW after I tweaked the config on my Win7 OS (to make it force VBox VMs to power off with saved state and forced Win to properly wait for that to finish), my VirtualBox VMs worked exactly as I state above and I never had any issues with them after! :)

Timing

VM time keeping may be an issue (and/or cause some problems). But TBH it's never something that I've had an issue with. Personally I highly doubt that it is at all related to the issues you are experiencing. But perhaps I'm wrong...?

FWIW if the OS is powered off (with a saved state) as far as the OS is concerned it has just experienced a time jump. When it's restarted (after being frozen, i.e powered off with saved state) it should not even realise that it's been off. The biggest issue would be that the clock would be wrong (until it updated via NTP). That would effect all the log times but not sure what else.

Add new comment