[vbox-dev] Speeding up VM boot/restore

[Klaus Espenlaub]

Nicolay Vizovitin wrote:
> Hello,
> 
> my question boils down to the following: what ways are there to speed
> up either VM boot process or VM restore from a state snapshot? The
> latter case seems more interesting as restore generally happens
> faster. Further in the mail I share my thoughts on this matter, some
> additional data and reasoning.
> 
> We are attempting to implement some kind of isolation environment
> based on virtual machine for testing "small" programs. Think of
> ACM-type programming competitions as a sample use-case. As a
> consequence, one of the most pressing concerns is container
> initialization time (either boot, or restore from snapshot).
> 
> Of course there are ways to decrease this time without touching VM,
> such as OS optimization, or hardware upgrade. But those ways proved
> limited. Currently the best time of initialization we archived is
> about 2 seconds (for restore) for "repackaged" version of Windows 2003
> [tested on: Host OS – Ubuntu 10.04, CPU – Intel Core 2 Duo T5750,
> Memory – 3 Gb, Guest memory – 256 Mb]. This result is quite good, but
> not good enough. So we need some way to speed up the process using VM.
> 
> We already tried to place the snapshot and disk image in RAM
> beforehand. Unfortunately speedup was only about 0.5 seconds. Also we
> tried to optimize VirtualBox VM settings. No promising results there
> yet, but we are still working in this direction.
> 
> Also there was an idea how to gain (probably) significant speedup. As
> simultaneous launch of several VMs from a single snapshot will be
> required, one could implement some kind of copy-on-write mechanism for
> VM's memory pages. Let's say there is already a paused VM in memory.
> To spawn a new container instance we "clone" that machine and use the
> memory pages of the original one, but in a copy-on-write fashion. I.e.
> until the first write to the page memory from original VM is used.
> Hopefully this reduces average VM memory footprint, as well as new VM
> spawn time. We hope that in that case startup time reduction would be
> considerable.
> 
> So, what do you think, would VM "clone" time be better than restoring
> machine from a normal snapshot? If so, what gain could be expected? If
> not, why (maybe complex processing takes more time while restoring
> snapshot than loading it)? Any advice on where to start to implement
> the described feature is greatly appreciated.

So many questions, and all of them very tough to answer...

If you wonder what's going on while the VM is powered up, have a look at 
VBox.log. The timestamp resolution there is high enough to get a pretty 
clear picture what's done when.

> Maybe there is a simpler way to gain reduced startup time?

Simple is a nice word - a normal VM powerup takes a few seconds (usually 
much less than a real PC though), as there's a lot of code run to reach 
the point of starting executing VM code.

 From what I can see here it commonly takes 700msecs before even the 
first line in VBox.log is emitted, and 250msecs to start executing any 
code (BIOS in my case, as I tested without saved state). 2.5 seconds 
later it started booting.

All tweaks to make this faster requires taking shortcuts which aren't 
safe in general, and would have a negligible impact on the general user 
experience.

Klaus

> If not, what will you suggest to enable launching multiple VM
> instances from a single configuration, provided changes to VM are not
> required to be saved after VM is shut down?
> 
> 
> --Best regards,
>   Nicolay
> 
> _______________________________________________
> vbox-dev mailing list
> vbox-dev at virtualbox.org
> http://vbox.innotek.de/mailman/listinfo/vbox-dev


-- 
Dr. Klaus Espenlaub
Sun Microsystems GmbH
Werkstrasse 24
71384 Weinstadt
Germany

=====================================================================
Sitz der Gesellschaft:
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Juergen Kunz
=====================================================================