VirtualBox 3.1 Officially Released

[phoronix]

Phoronix: VirtualBox 3.1 Officially Released

Earlier this month we talked about new VirtualBox 3.1 features when this Sun virtualization platform was still in beta, but this morning VirtualBox 3.1 final is now out the door for those interested in Windows, Linux, and Solaris virtualization. VirtualBox 3.1 adds support for teleportation (live migration of VMs between hosts), VM states can now be restored from arbitrary snapshots, network attachments can now be changed on active VMs, and support for more flexible storage attachments.VirtualBox 3.1 also brings major performance enhancements for PAE and x86_64 guests when running atop a system with Intel VT-x or AMD-V processor technology with normal, non-nested paging...

http://www.phoronix.com/vr.php?view=Nzc0OQ

[khaije1]

new day for MacOSX in vms?

Anyone know if the added EFI (Extensible Firmware Interface) support changes the situation for people interested in running MacOSX in a vm?

My summary understanding was that EFI support was among the few major hurdles, no?

thanks all,

[wswartzendruber]

If you can run Mac OS X inside VirtualBox then I am SO THERE.

[Ranguvar]

If you can run Mac OS X inside VirtualBox then I am SO THERE.

AFAIK VirtualBox still cannot run OS X as a guest on non-Apple hosts.
It doesn't have much to do with EFI; VMware can without EFI (if you turn on EFI in VMware it doesn't work).

Check www.insanelymac.com
I will say no more; it is of questionable legality.

[Kjella]

My summary understanding was that EFI support was among the few major hurdles, no?

From my understanding, not really. OS X lacks drivers for several bits of "standard" virtualized hardware, so there's quite a bit of work. They are presumably working on it for Mac-on-Mac virtualization which is now permitted by the EULA, but who knows what will be possible.

[Peter_Cordes]

VirtualBox 3.1 also brings major performance enhancements for PAE and x86_64 guests when running atop a system with Intel VT-x or AMD-V processor technology with normal, non-nested paging...

http://www.phoronix.com/vr.php?view=Nzc0OQ

32bit WinXP uses PAE by default (for NX support), right?

Has anyone found that virtualbox shared folders are really slow? I would have expected them to be faster than emulated disks, but maybe the overhead of leaving/re-entering VT-X for every access to a small file is high. I guess inside the guest files are often in the guest's disk cache, so it doesn't have to interact with the host...

Hmm, I wonder if shared folders are faster if vbox doesn't use VT-X, just it's old-style ia32 ring tricks.

[rohcQaH]

Shared folders are accessed over the emulated network link, and depending on your settings that may be a slow 10Mbit or 100Mbit connection, which really limits throughput. Make sure you use any of the "Intel PRO/1000" devices, although that may mean you need to manually install drivers on the guest OS.

And with any network file system, many small files mean many server roundtrips, which is always slow. And as you correctly guessed, caches for network file systems are usually invalidated after a few seconds.

Anyway, sequentially reading larger files on shared folders can yield speeds close to the expected maximum.

[Peter_Cordes]

Shared folders are accessed over the emulated network link, and depending on your settings that may be a slow 10Mbit or 100Mbit connection, which really limits throughput. Make sure you use any of the "Intel PRO/1000" devices, although that may mean you need to manually install drivers on the guest OS.

I am.

It's not just SMB, though, is it? I thought it was actually a shortcut between the VM and the host, since you need to install the guest additions to use it. I thought from the guest's perspective it would be: set up a buffer, put some parameters somewhere in memory or registers, and execute a special insn sequence (which calls out to VBox running on the host). When that special insns finishes, the buffer holds the requested file data.

Hmm, it probably can't work like that, because you wouldn't want your guest driver to block the guest CPU while waiting for host I/O. Ok, no wonder it actually goes over the virtual network. That would be much easier to design. Still, I would have thought it would be possible to work out an async I/O scheme that would work.

The workload I tested virtual disk vs. shared folder with was building a customized XP SP3 install disk with nlite, merging about a hundred windows updates into it, and making other mods. So yeah, small files.

I'm not sure if it was the shared folders, or a bug in nlite, or bad permissions on the host filesystem, but it crashed (.net exception in nlite, IIRC) near the end when operating on shared folder. But it worked on the virtual disk. So if any vbox devs are reading this, nlite may be a good stress-test for shared folders.