Chapter 40 xVM System Administration

This chapter covers xVM system administration topics.

Printing Kernel and Machine Information

Use uname to determine the kernel you are running.

hostname% uname -a
SunOS hostname 5.11 snv_80 i86pc i386 i86xpv

Use the isainfo command to print the basic application environments supported by the currently running system.

hostname% isainfo -x
amd64: sse2 sse fxsr amd_3dnowx amd_3dnow amd_mmx mmx cmov cx8 tsc fpu
i386: ahf sse2 sse fxsr amd_3dnowx amd_3dnow amd_mmx mmx cmov cx8 tsc fpu

Use the psrinfo command to display information about processors.

hostname% psrinfo -vp
The physical processor has 1 virtual processor (0)
x86 (Authentic AMD family 15 model 5 step 10 clock 2200 MHz)
Dual Core AMD Opteron(tm) Processor 275

Configuring the Serial Console to Be the Main Console

After an HVM guest domain has been installed, you can configure the OS to use the serial console as the main console.

How to Configure the Serial Console as the Main Console

1. Type:

   # eeprom console=ttya

2. Reboot the HVM guest domain.

virsh Command and Domain Management

The main command interface used to control both Solaris xVM and guest domains is the virsh command. virsh provides a generic and stable interface for controlling virtualized operating systems. Use virsh instead of xm wherever possible.

Many virsh commands act asynchronously. This means that the system prompt can return before the operation has completed.

If you modify CPUs or memory by using the virsh command, these changes will be saved in the configuration file and persist across reboots.

virsh Command Structure

Most virsh commands follow the format:

# virsh subcommand domain-id | name | uuid [options]

subcommand

One of the subcommands listed in the virsh(1M) man page

domain-id, name, or uuid

A domain identifier

options

An option to a subcommand

Example 40–1 Using a virsh Command

This line connects to a domU named sxc18.

# virsh console sxc18

virshCommand

The virsh is used to manage domains. You must run the commands as the root user or by assuming the appropriate role account on the host operating system. The commands cannot be run in the guest domain.

# virsh nodeinfo
CPU model:           i86pc
CPU(s):              2
CPU frequency:       2391 MHz
CPU socket(s):       2
Core(s) per socket:  1
Thread(s) per core:  1
NUMA cell(s):        1
Memory size:         4127744 kB

Ethernet-Type Interface Support

The OpenSolaris^TM OS supports all Ethernet-type interfaces, and their data-links can be administered with the dladm command.

Suspend and Resume Functions and Commands

Some xVM operations are not yet implemented in the virsh command. In those cases, the equivalent xm command can be used. Subcommand terminology differs between the xmand virsh commands. In particular, the suspend and resume commands have different meanings.

Cloning ZFS-Based Solaris Domains

If you are using a ZFS volume as the root disk for a domU, you can use the ZFS snapshot facilities to clone another domU with the same configuration. By taking a clone of the root disk, you can quickly provision similar 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 a Solaris domain in this way requires only the configuration step, rather than a full install. The only extra storage used for the cloned domain is the amount needed for the differences between the domains.

You also have the capability to revert to a previous configuration if necessary.

Any clones created from a snapshot must be destroyed before the snapshot can be destroyed.

How to Use ZFS Snapshot to Clone a Solaris DomU

If you use a ZFS volume as the virtual disk for your guest domain, you can take a snapshot of the storage. The snapshot is used to create clones.

Note that you might want to use the sys-unconfig command described in sys-unconfig(1M) in the domain before you take the snapshot. The resulting clones would not have host names or name services configured, which is also known as "as-manufactured." When it comes up, the new clone displays the configuration screens.

1. Become superuser, or assume the appropriate role.

2. (Optional) To create a snapshot to produce domains that require sysidcfg to complete system identification, use the sys-unconfig command in a domain named domain1.

3. Shut down domain1.

   # virsh shutdown domain1

4. Take a snapshot of the root disk used by domain1.

   # zfs snapshot pool/domain1-root@clone

5. Create a clone named domain2 from the snapshot domain1-root@clone.

   # zfs clone pool/domain1-root@clone pool/domain2-root

6. (Optional) Display the snapshot and clone.

   # zfs list NAME USED AVAIL REFER MOUNTPOINT pool 92.0K 67.0G 9.5K /pool pool/domain1 8K 67.0G 8K /pool/domain1 pool/domain2 8K 67.0G 8K /pool/domain2

7. Dump the configuration of domain1.

   # virsh dumpxml domain1 >domain1.xml

8. Copy the configuration file domain1.xml to a file named domain2.xml.

   # cp domain1.xml domain2.xml

9. Make the following changes in the domain2.xml file.

   1. Replace domain1 in this line:

      <name>domain1</name>

      With the new name, domain2:

      <name>domain2</name>

   2. So that virsh will generate a new domain configuration, remove the UUID line, which looks like this:

      <uuid>72bb96b6e6cf13594fb0cd1290610611</uuid>

   3. Point to the new disk by editing the following line:

      <source dev='/dev/zvol/dsk/export/domain1-root'/>

      Change domain1–root to domain2–root so that the line appears as follows:

      <source dev='/dev/zvol/dsk/export/domain2-root'/>

10. Inform virsh about the new domain:

    # virsh define domain2.xml

11. Boot the cloned domain.

More Information on ZFS Snapshot Features

Also see Chapter 7, Working With ZFS Snapshots and Clones, in Solaris ZFS Administration Guide.

Recovery

You can keep snapshots of the guest domain OS installations that are known to be good images, and use ZFS rollback to revert to a snapshot if the domain has a problem. For more information, see Rolling Back a ZFS Snapshot in Solaris ZFS Administration Guide.

Communication From xVM Hypervisor to Dom0 Using xm

Although the hypervisor and dom0 work closely together to manage a running system, the dom0 operating system has little direct visibility into the hypervisor. The hypervisor's entire address space is inaccessible to the dom0.

The only source of information is provided by the xm command, a user-space tool that communicates with the hypervisor via hypercalls.

Some of the commonly used xm commands are:

xm info

Report static information about the machine, such as number of CPUs, total memory, and xVM version.

# xm info host : test release : 5.11 version : onnv-userj machine : i86pc nr_cpus : 2 nr_nodes : 1 sockets_per_node : 2 cores_per_socket : 1 threads_per_core : 1 cpu_mhz : 2391 hw_caps : 078bfbff:e1d3fbff:00000000:00000010 total_memory : 4031 free_memory : 1953 xen_major : 3 xen_minor : 1 xen_extra : .2-xvm xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p xen_scheduler : credit xen_pagesize : 4096 platform_params : virt_start=0xffff800000000000 xen_changeset : Thu Dec 20 20:11:49 2007 -0800 15623:41d827ccece7 cc_compiler : gcc version 3.4.3 (csl-sol210-3_4-20050802) cc_compile_by : userj cc_compile_domain : lab.sun.com cc_compile_date : Thu Dec 20 20:24:36 PST 2007 xend_config_format : 4

xm list

List all domains and some high-level information.

xm top

Analogous to the Linux top command, but it reports domain information instead of process information. Information about the xVM system and domains is displayed in a continuously updating manner through the xentop command. See xentop.

xm log

Display the contents of the xend log.

xm help

List all the available commands.

xentrace

Capture trace buffer data from xVM.

xentop

Display information about the xVM system and domains in a continuously updating manner. See xm top.

xm start domain

Start a managed domain that was created by virt-install.

If you modify guest domain CPUs or memory by using the xm command, these changes will be saved in the configuration file and persist across reboots.

See the xm(1M) man page for more information.

About Crash Dumps

Domain 0 and Hypervisor Crashes

On a running system, the hypervisor's memory is completely off-limits to dom0. If the hypervisor crashes, however, the resulting panic dump will generate a core file that provides a unified view of both xVM and dom0. In this core file, xVM appears as a Solaris kernel module named xpv. For example:

 > $c
                xpv`panic+0xbf()
                xpv`do_crashdump_trigger+0x19()
                xpv`keypress_softirq+0x35()
                xpv`do_softirq+0x54()
                xpv`idle_loop+0x55()

The following applies to crash dumps:

• If a dom0 crashes with a standard Solaris panic, the dump will include only the dom0.

• When the hypervisor itself panics, the resulting dump includes the xVM state as well as the dom0 state.

How to Force a Crash Dump of a Guest

You can use the following command to force a crash dump of an OpenSolaris guest in the event of problems within the guest:

# virsh dump domain

The crash dump file created can be analyzed through /bin/mdb. The xvm user must be able to write to the location specified.