System Administration Information

Overview

Introduction to the xVM Hypervisor

The machine monitor in the xVM hypervisor can securely execute multiple virtual machines simultaneously, each running its own operating system, on a single physical system. Each virtual machine instance is called a domain. There are two kinds of domains. The control domain is called domain0, or dom0. A guest OS, or unprivileged domain, is called a domainU or domU. Unlike virtualization using zones, each domain runs a full instance of an operating system.

A hypervisor is also known as a Virtual Machine Monitor (VMM).

How Hypervisors Work

A hypervisor is a software system that partitions a single physical machine into multiple virtual machines, to provide server consolidation and utility computing. Existing applications and binaries run unmodified.

The hypervisor controls the MMU, CPU scheduling, and interrupt controller, presenting a virtual machine to guests.

The hypervisor separates the software from the hardware by forming a layer between the software running in the virtual machine and the hardware. This separation enables the hypervisor to control how guest operating systems running inside a virtual machine use hardware resources. A hypervisor provides a uniform view of underlying hardware. Machines from different vendors with different I/O subsystems appear the same, which means that virtual machines can run on any available computer. Thus, administrators can view hardware as a pool of resources that can run arbitrary services on demand. Because the hypervisor also encapsulates a virtual machine's software state, the hypervisor layer can map and remap virtual machines to available hardware resources at any time and also live migrate virtual machines across computers. These capabilities can also be used for load balancing among a collection of machines, dealing with hardware failures, and scaling systems. When a computer fails and must go offline or when a new machine comes online, the hypervisor layer can simply remap virtual machines accordingly. Virtual machines are also easy to replicate, which lets administrators bring new services online as needed.

Containment means that administrators can suspend virtual machines and resume them at any time, or checkpoint them and roll them back to a previous execution state. With this general-purpose undo capability, systems can more easily recover from crashes or configuration errors. Containment also supports a very general mobility model. Users can copy a suspended virtual machine over a network or store and transport it on removable media. The hypervisor can also provide total mediation of all interactions between the virtual machine and underlying hardware, thus allowing strong isolation between virtual machines and supporting the multiplexing of many virtual machines on a single hardware platform. The hypervisor can then consolidate a collection of virtual machines with low resources onto a single computer, thereby lowering hardware costs and space requirements. Strong isolation is also valuable for reliability and security. Applications that previously ran together on one machine can now be separated on different virtual machines. If one application experiences a fault, the other applications are isolated from this occurrence and will not be affected. Further, if a virtual machine is compromised, the incident is contained to only that compromised virtual machine.

Resource Virtualization

As a key component of virtual machines, the hypervisor provides a layer between software environments and physical hardware that is programmable and transparent to the software above it, while making efficient use of the hardware below it.

Virtualization provides a way to bypass interoperability constraints. Virtualizing a system or component such as a processor, memory, or an I/O device at a given abstraction level maps its interface and visible resources onto the interface and resources of an underlying, possibly different, real system. Consequently, the real system appears as a different virtual system or even as multiple virtual systems.

Virtualization Types

There are two basic types of virtualization, full virtualization and paravirtualization. The hypervisor supports both models.

In a full virtualization, the operating system is completely unaware that it is running in a virtualized environment. In the more lightweight paravirtualization, the operating system is both aware of the virtualization layer and modified to support it, which results in higher performance.

The paravirtualized domU operating system is ported to run on top of the hypervisor, and uses virtual network, disk, and console devices.

Since dom0 must work closely with the hypervisor layer, dom0 is always paravirtualized. DomUs can be either paravirtualized or fully virtualized, and a system can have both varieties running simultaneously.

A hardware virtual machine (HVM) domU runs an unmodified operating system. These hardware-assisted virtual machines take advantage of Intel-VT or AMD Secure Virtual Machine (SVM) processors.

About Domains

Dom0 and domU are separate entities. Other than by login, you cannot access a domU from dom0. A dom0 should be reserved for system management work associated with running a hypervisor. This means, for example, that users should not have logins on dom0. Dom0 provides shared access to a physical network interface to the guest domains, which have no direct access to physical devices.

A Solaris domU works like a normal Solaris Operating System. All of the usual tools are available.

Domain States

A domain can be in one of six states. States are shown in virt-manager screens and in virsh list --all displays. For example:

# virsh list --all
 Id Name                 State
----------------------------------
  0 Domain-0             running
  9 sxc14                blocked
  - sxc15                shut off
  - sxc16                shut off

The states are:

running

The domain is currently running on a CPU.

blocked

The domain is blocked, and not running or able to be run. This can be caused because the domain is waiting on IO (a traditional wait state) or it has gone to sleep because there was nothing running in it.

paused

The domain has been paused, usually through the administrator running virsh suspend. When in a paused state, the domain will stil l consume allocated resources like memory, but will not be eligible for scheduling by the hypervisor. Run virsh resume to place th e domain in the running state.

crashed

The domain has crashed. Usually this state can only occur if the domain has been configured not to restart on crash.

shut off

The domain is shut down.

in shutdown

The domain is in the process of shutting down or crashing.

SMF Hypervisor Services

• In Solaris, all of the properties from xend-config.sxp have been put into SMF xvm/xend (config/*).

• To modify an existing property:

# svccfg -s xvm/xend listprop
# svccfg -s xvm/xend setprop config/dom0-cpus = 1
# svcadm refresh xvm/xend

• To create a new property.

# svccfg -s xvm/xend setprop config/vncpasswd = astring: \"password\"
# svcadm refresh xvm/xend
# svcadm restart xvm/xend

Enable Live Migration

By default, xend listens only on the loopback address for requests from the localhost. If you want to allow other machines to live migrate to the machine, you must do the following:

• Listen on all addresses (or you can specify a particular interface IP)

  # svccfg -s xend setprop config/xend-relocation-address = \"\"
  

• Create list of hosts from which to accept migrations:

  # svccfg -s xend setprop config/xend-relocation-hosts-allow = \"^flax$ ^localhost$\"
  

• Update the config:

  # svcadm refresh xend && svcadm restart xend
  

How to Debug On xVM

xVM Console

• Typically you will need to enable the hypervisor's serial console first. Type 3 consecutive ctrl-A's on the xen console. You should see the following output on the console.

(xVM) *** Serial input -> xVM (type 'CTRL-a' three times to switch input to 
dom0).

• To exit the xVM console (and get back to the solaris console), type 3 more ctrl-a's.

• The following commands are supported in the xVM console. Commonly used keys are:
  • C - force a Solaris dom0 crash dump (/var/crash/...)
  • q - put solaris dom0 and all solaris domUs at the kmdb prompt (assuming you booted with -k)
  • R - force reboot dom0 (i.e. machine is hung)

(XEN) 'h' pressed -> showing installed handlers
(XEN)  key '%' (ascii '25') => Trap to xendbg
(XEN)  key 'C' (ascii '43') => trigger a crashdump
(XEN)  key 'H' (ascii '48') => dump heap info
(XEN)  key 'N' (ascii '4e') => NMI statistics
(XEN)  key 'R' (ascii '52') => reboot machine
(XEN)  key 'a' (ascii '61') => dump timer queues
(XEN)  key 'd' (ascii '64') => dump registers
(XEN)  key 'h' (ascii '68') => show this message
(XEN)  key 'i' (ascii '69') => dump interrupt bindings
(XEN)  key 'm' (ascii '6d') => memory info
(XEN)  key 'n' (ascii '6e') => trigger an NMI
(XEN)  key 'q' (ascii '71') => dump domain (and guest debug) info
(XEN)  key 'r' (ascii '72') => dump run queues
(XEN)  key 't' (ascii '74') => display multi-cpu clock info
(XEN)  key 'u' (ascii '75') => dump numa info
(XEN)  key 'v' (ascii '76') => dump Intel's VMCS
(XEN)  key 'z' (ascii '7a') => print ioapic info

Copyright 2007 Sun Microsystems, Inc.