Standards, Environments, and Macros xVM(5)
NAME
xVM, xvm - Solaris x86 virtual machine monitor
DESCRIPTION
The Solaris xVM software (hereafter xVM) is a virtualization
system, or virtual machine monitor, for the Solaris operat-
ing system on x86 systems. Solaris xVM enables you to run
multiple virtual machines simultaneously on a single physi-
cal machine, often referred to as the host. Each virtual
machine, known as a domain, runs its own complete and dis-
tinct operating system instance, which includes its own I/O
devices. This differs from zone-based virtualization, in
which all zones shares the same kernel. (See zones(5).)
Each domain has a name and a UID. Domains can be renamed
but typically retain the same UID. A domain ID is an
integer that is specific to a running instance. It changes
on every boot of the guest domain. Non-running domains do
not have a domain ID.
The xVM hypervisor is responsible for controlling and exe-
cuting each of the domains and runs with full privileges.
xVM also includes control tools for management of the
domains. These tools run under a specialized control domain,
often referred to as domain 0.
To run Solaris xVM, select the entry labelled Solaris xVM in
the grub(5) menu at boot time. This boots the hypervisor,
which in turn boots the control domain. The control domain
is a version of Solaris modified to run under the xVM hyper-
visor. At the point at which the control domain is running,
the control tools are enabled. In most other respects, the
domain 0 instance behaves just like a "normal" instance of
the Solaris operating system.
The xVM hypervisor delegates control of the physical devices
present on the machine to domain 0. Thus, by default, only
domain 0 has access to such devices. The other guest domains
running on the host are presented with virtualized devices
with which they interact as they would physical devices.
The xVM hypervisor schedules running domains (including
domain 0) onto the set of physical CPUs as configured. The
xVM scheduler is constrained by domain configuration (the
number of virtual CPUs allocated, and so forth) as well as
any run-time configuration, such as pinning virtual CPUs to
physical CPUs.
SunOS 5.11 Last change: 14 Jan 2009 1
Standards, Environments, and Macros xVM(5)
The default domain scheduler in xVM is the credit scheduler.
This is a work-conserving, fair-share domain scheduler; it
balances virtual CPUs of domains across the allowed set of
physical CPUs according to workload.
xVM supports two modes of virtualization. In the first, the
operating system is aware that it is running under xVM. This
mode is called paravirtualization. In the second mode,
called fully virtualized, the guest operating system is not
aware that it is running under xVM. A fully virtualized
guest domain is sometimes referred to as a Hardware-assisted
Virtual Machine (HVM). A variation on a Hardware-assisted
Virtual Machine is to use paravirtualized drivers for
improved performance. This variation is abbreviated as HVM ]
PV.
With paravirtualization, each device, such as a networking
interface, is presented as a fully virtual interface, and
specific drivers are required for it. Each virtual device is
associated with a physical device and the driver is split
into two. A frontend driver runs in the guest domain and
communicates over a virtual data interface to a backend
driver. The backend driver currently runs in domain 0 and
communicates with both the frontend driver and the physical
device underneath it. Thus, a guest domain can make use of a
network card on the host, store data on a host disk drive,
and so forth.
Solaris xVM currently supports two main split drivers used
for I/O. Networking is done by means of the xnb (xVM Net-
working Backend) drivers. Guest domains, whether Solaris or
another operating system, use xnb to transmit and receive
networking traffic. Typically, a physical NIC is used for
communicating with the guest domains, either shared or dedi-
cated. Solaris xVM provides networking access to guest
domains by means of MAC-based virtual network switching.
Block I/O is provided by the xdb (xVM Disk Backend) driver,
which provides virtual disk access to guest domains. In the
control domain, the disk storage can be in a file, a ZFS
volume, or a physical device.
Using ZFS volumes as the virtual disk for your guest domains
allows you to take a snapshot of the storage. As such, you
can keep known-good snapshots of the guest domain OS instal-
lation, and revert the snapshot (using zfs rollback) if the
domain has a problem. The zfs clone command can be used for
SunOS 5.11 Last change: 14 Jan 2009 2
Standards, Environments, and Macros xVM(5)
quick provisioning of new domains. For example, you might
install Solaris as a guest domain, run sys-unconfig(1M),
then clone that disk image for use in new Solaris domains.
Installing Solaris in this way requires only a configuration
step, rather than a full install.
When running as a guest domain, Solaris xVM uses the xnf and
xdf drivers to talk to the relevant backend drivers. In
addition to these drivers, the Solaris console is virtual-
ized when running as a guest domain; this driver interacts
with the xenconsoled(1M) daemon running in domain 0 to pro-
vide console access.
A given system can have both paravirtualized and fully vir-
tualized domains running simultaneously. The control domain
must always run in paravirtualized mode, because it must
work closely with the hypervisor layer.
As guest domains do not share a kernel, xVM does not require
that every guest domain be Solaris. For paravirtualized mode
and for all types of operating systems, the only requirement
is that the operating system be modified to support the vir-
tual device interfaces.
Fully-virtualized guest domains are supported under xVM with
the assistance of virtualization extensions available on
some x86 CPUs. These extensions must be present and enabled;
some BIOS versions disable the extensions by default.
In paravirtualized mode, Solaris identifies the platform as
i86xpv, as seen in the return of the following uname(1) com-
mand:
% uname -i
i86xpv
Generally, applications do not need to be aware of the plat-
form type. It is recommended that any ISA identification
required by an application use the -p option (for ISA or
processor type) to uname, rather than the -i option, as
shown above. On x86 platforms, regardless of whether Solaris
is running under xVM, uname -p always returns i386.
SunOS 5.11 Last change: 14 Jan 2009 3
Standards, Environments, and Macros xVM(5)
You can examine the domcaps driver to determine whether a
Solaris instance is running as domain 0:
# cat /dev/xen/domcaps
controld
Note that the domcaps file might also contain additional
information. However, the first token is always controld
when running as domain 0.
xVM hosts provide a service management facility (SMF) ser-
vice (see smf(5)) with the FMRI:
svc:/system/xvm/domains:default
...to control auto-shutdown and auto-start of domains. By
default, all running domains are shutdown when the host is
brought down by means of init 6 or a similar command. This
shutdown is analogous to entering:
# virsh shutdown mydomain
A domain can have the setting:
onxendstop=ignore
...in which case the domain is not shut down even if the
host is. Such a setting is the effective equivalent of:
# virsh destroy mydomain
If a domain has the setting:
onxendstart=start
SunOS 5.11 Last change: 14 Jan 2009 4
Standards, Environments, and Macros xVM(5)
...then the domain is automatically booted when the xVM host
boots. Disabling the SMF service by means of svcadm(1M) dis-
ables this behavior for all domains.
Solaris xVM is partly based on the work of the open source
Xen community.
Control Tools
The control tools are the utilities shipped with Solaris xVM
that enable you to manage xVM domains. These tools interact
with the daemons that support xVM: xend(1M),
xenconsoled(1M), and xenstored(1M), each described in its
own man page. The daemons are, in turn, managed by the SMF.
You install new guest domains with the command line virt-
install(1M) or the graphical interface, virt-manager.
The main interface for command and control of both xVM and
guest domains is virsh(1M). Users should use virsh(1M) wher-
ever possible, as it provides a generic and stable interface
for controlling virtualized operating systems. However, some
xVM operations are not yet implemented by virsh. In those
cases, the legacy utility xm(1M) can be used for detailed
control.
The configuration of each domain is stored by xend(1M) after
it has been created by means of virt-install, and can be
viewed using the virsh dumpxml or xm list -l commands.
Direct modification of this configuration data is not recom-
mended; the command-line utility interfaces should be used
instead.
Solaris xVM supports live migration of domains by means of
the xm migrate command. This allows a guest domain to keep
running while the host running the domain transfers owner-
ship to another physical host over the network. The remote
host must also be running xVM or a compatible version of
Xen, and must accept migration connections from the current
host (see xend(1M)).
For migration to work, both hosts must be able to access the
storage used by the domU (for example, over iSCSI or NFS),
and have enough resources available to run the migrated
domain. Both hosts must currently reside on the same subnet
for the guest domain networking to continue working prop-
erly. Also, both hosts should have similar hardware. For
SunOS 5.11 Last change: 14 Jan 2009 5
Standards, Environments, and Macros xVM(5)
example, migrating from a host with AMD processors to one
with Intel processors can cause problems.
Note that the communication channel for migration is not a
secure connection.
GLOSARY
backend
Describes the other half of a virtual driver from the
frontend driver. The backend driver provides an inter-
face between the virtual device and an underlying physi-
cal device.
control domain
The special guest domain running the control tools and
given direct hardware access by the hypervisor. Often
referred to as domain 0.
domain 0
See control domain.
frontend
Describes a virtual device and its associated driver in
a guest domain. A frontend driver communicates with a
backend driver hosted in a different guest domain.
full virtualization
Running an unmodified operating system with hardware
assistance.
guest domain
A virtual machine instance running on a host. Unless the
guest is domain 0, such a domain is also called a
domain-U, where U stands for "unprivileged".
host
The physical machine running xVM.
SunOS 5.11 Last change: 14 Jan 2009 6
Standards, Environments, and Macros xVM(5)
Hardware-assisted Virtual Machine (HVM)
A fully-virtualized guest domain.
node
The name used by the virsh(1M) utility for a host.
virtual machine monitor (VM)
Hypervisor software, such as xVM, that manages multiple
domains.
SEE ALSO
uname(1), dladm(1M), svcadm(1M), sys-unconfig(1M),
virsh(1M), virt-install(1M), xend(1M), xenconsoled(1M),
xenstored(1M), xm(1M), zfs(1M), attributes(5), grub(5),
liveupgrade(5), smf(5), zones(5)
NOTES
Any physical Ethernet datalink (as shown by dladm show-phys)
can be used to network guest domains.
SunOS 5.11 Last change: 14 Jan 2009 7
|
