Glenn Faden's Blog

  • September 21, 2008

Updates on Running Virtualized Guests in Labeled Zones

Guest Author

Last April I posted some procedures for running Vista in labeled zones using VirtualBox. When VirtualBox 2.0 was released a few weeks ago, I decided to try out some of the new features. I think the coolest one is the way the seamless mode works with Trusted Extensions. In seamless mode, all the Vista windows, including the Task Bar are rendered in a single fullscreen X11 window using the Shape extension. Previously I've seen this extension used for non-rectangular windows like round clocks. But, in this case, the all the Vista windows are in a single plane, with holes cut our where the Vista desktop would normally appear. So the GNOME windows, including the nautilus desktop are visible through these holes. Furthermore, the pointer focus passes through these holes to the next window, so the Trusted Stripe accurately displays the label of the pointer as it is moved across Vista windows and the GNOME windows behind the holes.

In my previous blog entry, I mentioned that it was necessary to start an instance of VirtualBox in the global zone since the vboxdrv driver couldn't  be loaded from a non-global zone. I've come up with a simple alternative, although it isn't officially supported. Instead of starting a new instance of VirtualBox in the global zone, it is sufficient to keep the device open using a command like the following:

tail -f /dev/vboxdrv >/dev/null 2>&1 &

For expediency, I added this single line to the end of the start method in the zones SMF service, /lib/svc/method/svc-zones. While this actually works, we need to figure out a more supportable technique.

Another issue that I raised in the previous blog entry was that the Vista guest needs to communicate directly with the DNS server, so it must be assigned a single-level network template with the same label as the zone in which the guest is running. However, this causes problems with applications in other zones that rely on the Name Server Cache Daemon, nscd(1M), which proxies DNS requests from labeled zones into the global zone. An interesting workaround is to allow nscd in the global zone to send requests to unlabeled servers even if their labels don't match. This can be specified by wrapping the start method for nscd, in the file /lib/svc/method/svc-nscd as follows:

/usr/bin/ppriv -M -e /usr/sbin/nscd < /dev/null > /dev/msglog 2>&1 &

The -M option of ppriv(1) enables the special process attribute NET_MAC_AWARE. The combination of this process attribute, the privilege, priv_net_mac_aware, and the assignment of a matching trusted network template entry in tnrhdb, allows the global zone instance of nscd to proxy DNS requests from all zones, and concurrently allows the Vista guest to communicate directly with the remote DNS server.

Using these techniques, I can now run two instances of Vista in separate VirtualBoxes, each in their own labeled zones. The first instance, running in the public zone, uses the public network. The other Vista instance, running in the internal zone, uses a commercial Windows VPN application, so only its VPN endpoint requires a matching label.

To save time, disk space and virtual memory, I created a ZFS dataset for the public instance of Vista, and created a ZFS snapshot after completing the Vista installation. I then cloned the snapshot for use in the internal zone. Normally this would cause a problem with VirtualBox which requires that each Virtual Disk Image (.vdi) has a unique UUID. However, since the two instances of VirtualBox are completely isolated from each other in uniquely labeled zones, they can share the same UUID.

On the other hand, to comply with the Microsoft license, each instance of Vista requires a unique activation key.

Join the discussion

Comments ( 1 )
  • Tom Jobbins Saturday, September 27, 2008

    Sadly, VirtualBox 2.0.2 is just as unstable as all the other VBox releases for Solaris.

    3 minutes into XP installation, my Solaris 10 U5 server hard locked - no ping, no panic, no messages on console. Just dead to the world.

    I had similar problems with 1.6.4 except then it related to using a Dynamic VDI instead of Fixed. I was using Fixed in 2.0.2 but it still hung. There are many other reports of this problem on the VBox forums.

    VBox has great potential, but is being ruined by a complete disregard for any QA. The first release with 'Solaris support' - 1.5 I think it was - wouldn't even load on Solaris unless LD_LIBRARY_PATH was used, and a 64bit dlpi library taken from OpenSolaris. 1.5.2 wouldn't boot any VMs for me. 1.5.4 and above booted but hard locked when a Dynamic VDI was used, but did have some success with a fixed VDI. Now 2.0.2 hard locks again.

    It's getting a bit embarrasing now. I wish the team would just take three months to get it right rather than keep putitng out half-baked versions which clearly have been barely tested.

    Sorry for the rant, I know it's not your issue, just I find it very frustrating - I expect a lot more from Sun.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.