t h e V irtualization options for wenjin Hu, Todd desHane, and Solaris have been expanding rapidly. In this jeanna Matthews article we discuss three types of virtualiza- tion systems available in OpenSolaris for x86: Solaris Containers, Solaris xVM, and Sun xVM VirtualBox. We include instruc- Solaris virtualization tions on how to deploy each solution and options a detailed comparison of the three to help system administrators and virtualization Wenjin Hu is a PhD student in Computer Science fans alike choose the appropriate virtualiza- at Clarkson University. He focuses on applying virtualization and file system techniques to provide tion technology for their needs. Even if you security and reliability on the desktop. don’t use Solaris, we do explain the differ- [email protected] ences among OS-level virtualization, para- virtualization, and full-virtualization clearly. Todd Deshane is a PhD student in Engineering Science at Clarkson University. His current research deals with using virtualization to provide security Solaris has included Containers (also called Zones) on the desktop. since Solaris 10 was released in 2005. Containers [email protected] are an operating-system-level virtualization facility, meaning that the OS itself provides the illusion of multiple independent systems, each with its own Jeanna Neefe Matthews is an associate profes- IP address and file system, all based on the same sor of Computer Science at Clarkson University in base kernel. More recently, support for paravirtu- Potsdam, NY, where she leads an incredible team of alization in the form of Xen (called Sun xVM on students. She is currently on sabbatical and work- ing with VMware in Cambridge, MA. Solaris) has been added and now, with the acquisi- tion of VirtualBox, full virtualization on Solaris is [email protected] also an option. Unlike OS-level virtualization, par- avirtualization and full virtualization both offer the ability to run guest operating systems that are dif- ferent from the underlying OS. Full virtualization can run unmodified operating systems, whereas paravirtualization requires targeted changes to the hardware interface and therefore correspond- ing changes in the OS source code. As a result, proprietary operating systems such as Microsoft Windows can typically only be run on virtualiza- tion systems that support full virtualization. Some virtualization systems, such as Xen, require hard- ware support for virtualization, such as Intel VT or AMD-V, to support full virtualization. getting started with solaris containers In Solaris Containers/Zones, a virtual machine is called a zone and a zone with resource limitations is called a container. The basic command to operate a zone’s configuration file is zonecfg –z newzone. This will bring up a shell in which you can issue a variety of commands to manipulate the specified zone. As shown in Listing 1, you create a zone, add the attached devices such as add net, set zone options such as set autoboot=true, display the configuration, verify the configuration, and finally commit a zone’s resources, which writes out a ;LOGIN: OctOber 2008 sOLArIs vIrtualizAtion Options 7 final configuration file for the zone. You can also use zonecfg to browse the characteristics of an existing zone and modify it as desired. # zonecfg -z newzone newzone: No such zone configured Use ‘create’ to begin configuring a new zone. zonecfg:newzone> create zonecfg:newzone> set zonepath=/export/home/newzone zonecfg:newzone> set autoboot=true zonecfg:newzone> add net zonecfg:newzone:net> set address=192.168.16.109 zonecfg:newzone:net> set physical=pcn0 zonecfg:newzone:net> end zonecfg:newzone> verify zonecfg:newzone> commit zonecfg:newzone> exit Listing 1: the steps shOwing the ZOne ConfiguratiOn Solaris provides a number of options to manage the resources that a zone can own, including the CPU, the memory, and the number of the pro- cesses. This is the heart of making a zone into a container with resource limitations. In Listing 2, we illustrate how to add a variety of restrictions to our new zone. (These commands are also issued at the zonecfg prompt.) The capped-cpu command limits the CPU cycles assigned to the zone to a fourth of one CPU. Similarly, our capped-memory command assigns the zone 128 MB of memory and 512 MB of swap space. It also guarantees that 64 MB of the zone’s memory will be resident in physical memory at all times. Finally, the set max-lwps command illustrates how we can place limits on things besides physical resources. It limits the number of light- weight processes in a running zone and is useful for preventing problems such as fork-bombs from taking down the whole machine. add capped-cpu set ncpus=0.25 end add capped-memory set physical=128M set swap=512M set locked=64M end set max-lwps=175 Listing 2: the OptiOns Limiting the Container’s resOurces Once our new zone is configured, we are ready to instantiate it with the command zoneadm –z newzone install and then run it with the com- mand zoneadm –z newzone boot. zoneadm can also be used for other zone administration functions such as listing the configured zones, install- ing or uninstalling the zones, and booting, pausing, and halting installed zones. Listing 3 shows the output of running zoneadm list after installing our new zone. The parameter –c will display all the configured zones’ infor- mation; –v will display the detailed information of zones. # zoneadm list -vc ID NAME STATUS PATH BRAND IP 0 global running / native shared 1 newzone running /export/home/newzone native shared Listing 3: a ZOneadm List shOwing all zones 8 ;LOGIN: vOL. 33, NO. 5 Finally, we are ready to log in to our new zone with the command zlogin newzone. It will be running the same version of OpenSolaris as the base operating system, as is required with OS-level virtualization. However, the zone will behave like a separate system, with its own IP address, its own file system, and its own set of installed applications. getting started with solaris xVM A virtual machine in xVM is called a domain, just as it is in other Xen im- plementations. Domains are divided into two major categories: paravirtual- ized (PV) domains and Hardware-assisted Virtual Machine (HVM) domains. In a PV domain, the hardware abstraction presented to the guest VM is not identical to the underlying physical hardware; instead, strategic changes are made to make the system easier to virtualize. To run properly on the para- virtualized hardware, the guest operating system must be modified to be aware of these changes. This requires source-code-level changes to the OS and is therefore rarely available for proprietary operating systems such as Windows. Two common choices for paravirtualized guest domains are So- laris and Linux. In an HVM domain, the hardware abstraction presented to the guest is iden- tical to the underlying hardware, so any operating system that runs on x86 hardware architecture can be installed. To make this possible, an HVM do- main relies on special hardware support for virtualization such as Intel V-T or AMD-V. If your system does not have this hardware support for virtual- ization, then paravirtualized domains are your only option. Xen is a virtual machine monitor, called a hypervisor, which intercepts the guest domain’s system calls. It is necessary to boot the Xen-enabled Solaris kernel on the physical machine rather than a normal Solaris kernel. Since Solaris Nevada Version build 75, Xen has been developed and well inte- grated into Solaris Express Community Edition through a variety of boot options in the GRUB menu. For example, the standard GRUB menu displays three choices: Solaris Express Community Edition snv87 X86, Solaris xVM, and Solaris Failsafe; the second grub option, Solaris xVM, should be chosen. Xen also relies on a special, privileged domain, called Domain0, and the Xen control daemon, Xend, for communication between the hypervisor and the guests. Domain0 is granted the full privileges of managing the guest do- mains and the physical devices by the Xen hypervisor, similar to a “normal” Solaris OS instance. Device drivers can also be fully virtualized or paravirtualized. Even a system that does full virtualization of the CPU and memory can load paravirtual- ized drivers to handle external devices such as a disk or network interface. In a paravirtualized driver, the driver running in the guest operating system is aware of the hypervisor and explicitly participates in communicating its requests to domain0 where the real physical device drivers are running. In a fully virtualized driver, the real device access still occurs on the Domain0 drivers, but the guest driver is unaware of this, so the hypervisor must trap accesses to I/O space or DMA operations in order to forward them on to the proper device driver in Domain0. PV drivers have much lower overhead, be- cause they avoid this expensive process of trapping and forwarding. Our first step in running Xen guests is to make sure that the hypervisor, Domain0, and Xend are all running. After Solaris xVM boots up, you can use the command virsh list as shown in Listing 4 to check whether Domain0 is running. ;LOGIN: OctOber 2008 sOLArIs vIrtualizAtion Options 9 # virsh list Id Name State --------------------------------------------------- 0 Domain-0 running 110 newSolaris blocked Listing 4: Virsh List shOwing Domain0 Next, we check that Xend is running and specify the default network in- terface in Xend first so that our guest domains are able to set up the virtual network based on that physical NIC. Xend is wrapped as an application ser- vice in Solaris. Listing 5 illustrates the use of svccfg and svcadm facilities to configure and restart Xend. The –s parameter specifies the Xend service; setprop specifies the Xend configuration options.