Updates on Running Virtualized Guests in Labeled Zones
By Glenn Faden-Oracle on Sep 21, 2008
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.