Skip Headers
Oracle® VM Server User's Guide
Release 2.1

Part Number E10898-04
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

E Troubleshooting

This Appendix contains information on troubleshooting Oracle VM Server. It contains:

E.1 Debugging Tools

If domain creation fails, check the Oracle VM Server log files and use the command-line tools to help you find the cause of a problem. There are a number of useful command-line tools, important directories, and log files that you should check when troubleshooting problems with Oracle VM Server. This section discusses:

E.1.1 Oracle VM Server Directories

The important Oracle VM Server directories you should check when troubleshooting problems with Oracle VM Server are listed in Table E-1, "Oracle VM Server directories"

Table E-1 Oracle VM Server directories

Directory Purpose

/etc/xen

Contains Oracle VM Server configuration files for the Oracle VM Server daemon and virtualized guests.

/etc/xen/scripts

Contains networking related scripts

/var/log/xen

Contains Oracle VM Server log files.


E.1.2 Oracle VM Server Log Files

The Oracle VM Server log files you should check when troubleshooting problems with Oracle VM Server are listed in Table E-2, "Oracle VM Server log files"

Table E-2 Oracle VM Server log files

Log File Purpose

xend.log

Contains a log of all the actions of the Oracle VM Server daemon. Actions are normal or error conditions. This log contains the same information as output using the xm log command.

xend-debug.log

Contains more detailed logs of the actions of the Oracle VM Server daemon.

xen-hotplug.log

Contains a log of hotplug events. Hotplug events are logged if a device or network script does not start up or become available.

qemu-dm.pid.log

Contains a log for each hardware virtualized guest. This log is created by the quemu-dm process. Use the ps command to find the pid (process identifier) and replace this in the file name.


E.1.3 Oracle VM Server Command-Line Tools

The Oracle VM Server command-line tools you should use when troubleshooting problems with Oracle VM Server are listed in Table E-2, "Oracle VM Server log files".

Table E-3 Oracle VM Server command-line tools

Command-Line Tool Purpose

xen top

Displays real-time information about Oracle VM Server and domains.

xm dmesg

Displays log information on the hypervisor.

xm log

Displays log information of the Oracle VM Server daemon.


E.2 Using DHCP

It is recommended that you install Oracle VM Server on a computer with a static IP address. If your computers uses DHCP you should configure your DHCP server to assign static DHCP addresses. This makes sure your host always receives the same IP address. The behavior of the Oracle VM Server host is undefined if used in an environment where your IP address may change due to DHCP lease expiry.

E.3 Guest Console Access

You can connect to a guest's console using Oracle VM Manager. If you do not have access to Oracle VM Manager, you can configure access to a guest's console with VNC (Virtual Network Computing). VNC access to guests requires that VNC access is enabled in the guest's configuration file, vm.cfg. Some VNC parameters (for example, the listening address and password) can be configured in one, either, or both of the following locations:

Hardware virtualized guests use the vnc=1 parameter in the guest configuration file, for example

vnc=1
vnclisten '0.0.0.0'

Paravirtualized guests use the VNC virtual frame buffer in the guest configuration file, for example

vfb = ['type=vnc,vncunused=1,vnclisten=0.0.0.0,vncpasswd=mypassword']

VNC settings defined in the guest configuration file override the settings in the Oracle VM Server configuration file. For example, if the following is specified in a hardware virtualized guest configuration file:

vnc=1
vnclisten '0.0.0.0'
vncpassword 'mypassword'

The values set in the guest configuration file are used for VNC access, rather than any corresponding values set in the Oracle VM Server configuration.

Note:

Setting vnclisten to 0.0.0.0 sets VNC to allow access to any computer. This may compromise security on the host computer.

If the following is specified in a hardware virtualized guest configuration file:

vnc=1

VNC is enabled in the guest, and the vnclisten parameter is used from the Oracle VM Server configuration file. If vnclisten is not specified in the Oracle VM Server configuration file, a default value of 127.0.0.1 is used. If the following is specified in the hardware virtualized guest configuration file:

vnc=0

VNC access to the guest is disabled.

Setting the default configuration options for VNC access in the Oracle VM Server configuration file enables you to configure access for all guests, and then individually override VNC access by setting the VNC parameters in the guest configuration file.

The following example is a VNC configuration entry in a paravirtualized guest configuration file:

vfb = ['type=vnc,vncunused=1,vnclisten=0.0.0.0,vncpasswd=mypassword']

The following example as a VNC configuration entry in a hardware virtualized guest configuration fie:

vnc = 1                   # vnc=1 enabled, 0=disabled
vncconsole = 1            # vncconsole=1 enables spawning VNC viewer for domain's
                          # console. Default=0
vnclisten = 0.0.0.0       # Address that should be listened on for the VNC server
                          # if VNC is set. Default (if vnc=0) is to use
                          # 'vnc-listen' setting from /etc/xen/xend-config.sxp
vncpasswd = 'mypassword'  # VNC password
vncunused = 1             # vncunused=1 - find an unused port for the VNC server
                          # to listen on. Default=1

In this example, the vncunused=1 parameter allocates a new VNC port number each time a guest is created and assigns it to the guest. Port numbers are allocated starting at the default VNC port number of 5900, so dom1 is allocated port 5900, dom2 is allocated port 5901, dom3 port 5902, and so on.

Connect to the guest on the host computer with the command

# vncviewer -Shared ipaddress:port

The -Shared parameter enables you to share the VNC connection. If you do not include this parameter, another user may destroy your VNC session if they connect at the same time. Connect from a remote computer with a VNC viewer using the connection string:

ipaddress:port

In both examples, ipaddress is the IP address or hostname of the Oracle VM Server, and port is the VNC port number of the guest.

E.4 Cannot Display Graphical Installer When Creating Guests

If the graphical installer does not start when creating a guest using the virt-install command-line tool, you should check your X11 configuration. If you are using a console through an ssh (Secure Shell) connection, connect to the console and set the DISPLAY environment variable, for example

# ssh root@example
# export DISPLAY=example:0.0

Alternatively, you can enable connect to a console and enable ssh forwarding using the ssh -X command, for example

# ssh -X root@example

If you use Putty to connect to a console, you must connect from an X11 capable operating system.

E.5 Hardware Virtualized Guest Console Not Displayed

If a console is not displayed after you create a hardware virtualized guest, your disk device specification may be incorrect. When you create a hardware virtualized guest, you must specify the VNC console setup. This is not required for a paravirtualized guest.

E.6 Setting the Guest's Clock

Paravirtualized guests may perform their own system clock management, for example, using the NTPD (Network Time Protocol daemon), or the hypervisor may perform system clock management for all guests.

You can set paravirtualized guests to manage their own system clocks by setting the xen.independent_wallclock parameter to 1 in the /etc/sysctl.conf file. For example

"xen.independent_wallclock = 1"

If you want to set the hypervisor to manage paravirtualized guest system clocks, set xen.independent_wallclock to 0. Any attempts to set or modify the time in a guest will fail.

You can temporarily override the setting in the /proc file. For example

"echo 1 > /proc/sys/xen/independent_wallclock"

Note:

This setting does not apply to hardware virtualized guests.

E.7 Wallclock Time Skew Problems

Oracle VM Release 2.1.1 introduces the use of the timer_mode parameter for hardware virtualized guests. This parameter, when properly applied, can reduce or even eliminate problems with wallclock time skew in most hardware virtualized guests. Wallclock time skew problems do not occur in paravirtualized guests.

Since the application of the correct value of the timer_mode parameter can be difficult to determine, you can pass the os-type and os-variant command-line switches to virt-install to select the best timer_mode value for the guest operating system. When you use these virt-install parameters, the correct timer_mode value is automatically added to the guest configuration file. For example, to create an Oracle Enterprise Linux 5 64-bit guest, add the following to the virt-install command-line:

# virt-install --hvm ... --os-type=linux --os-variant=el5_64 ...

For best results, additional parameters may be needed in the boot loader (grub.conf) configuration file for certain operating system variants after the guest is installed. Specifically, for optimal clock accuracy, Linux guest boot parameters should be specified to ensure that the pit clock source is utilized. Adding clock=pit nohpet nopmtimer for most guests will result in the selection of pit as the clock source for the guest. Published templates for Oracle VM will include these additional parameters.

Proper maintenance of virtual time can be tricky. The various parameters provide tuning for virtual time management and supplement, but do not replace, the need for an ntp time service running within guest. Ensure that the ntpd service is running and that the /etc/ntpd.conf configuration file is pointing to valid time servers.

E.8 Mouse Pointer Tracking Problems

If your mouse pointer fails to track your cursor in a VNC Viewer session in a hardware virtualized guest, add the following to the Oracle VM Server configuration file located at /etc/xen/xend-config.sxp to force the device model to use absolute (tablet) coordinates:

usbdevice='tablet'

Restart Oracle VM Server for the changes to take effect.

E.9 Hardware Virtualized Guest Stops

When running hardware virtualized guests, the QEMU process (qemu-dm) may have its memory usage grow substantially, especially under heavy I/O loads. This may cause the hardware virtualized guest to stop as it runs out of memory. If the guest is stopped, increase the memory allocation for dom0, for example from 512MB to 768MB.

E.10 Hardware Virtualized Guest Devices Not Working as Expected

Some devices, such as sound cards, may not work as expected in hardware virtualized guests. In a hardware virtualized guest, a device that requires physical memory addresses instead uses virtualized memory addresses, so incorrect memory location values may be set. This is because DMA (Direct Memory Access) is virtualized in hardware virtualized guests.

Hardware virtualized guest operating systems expect to be loaded in memory starting somewhere around address 0 and upwards. This is only possible for the first hardware virtualized guest loaded. Oracle VM Server virtualizes the memory address to be 0 to the size of allocated memory, but the guest operating system is actually loaded at another memory location. The difference is fixed up in the shadow page table, but the operating system is unaware of this.

For example, a sound is loaded into memory in a hardware virtualized guest running Windows at an address of 100MB may produce garbage through the sound card, instead of the intended audio. This is because the sound is actually loaded at 100MB plus 256MB. The sound card receives the address of 100MB, but it is actually at 256MB.

An IOMMU (Input/Output Memory Management Unit) in the computer's memory management unit would remove this problem as it would take care of mapping virtual addresses to physical addresses, and enable hardware virtualized guests direct access to the hardware.

E.11 Hardware Virtualized Guest Windows Installation

During the installation of Microsoft Windows™ XP and Microsoft Windows™ 2003 as hardware virtualized guests, the domain requires a restart and attempts to find the installation CDROM. Oracle VM Server does not know how to find the CDROM. To workaround this problem:

  1. During the domain restart, press F6 or F5 to select a new HAL (Hardware Abstraction Layer).

  2. Select Standard PC and add the CDROM to your guest configuration file, for example, add the following the /etc/xen/myWindowsGuest file:

  3. disk = [ 'file:/ovm/guests/win2003sp1.dsk,hda,w','file:/ovm/trees/ISO/WIN/en_windows_server_2003_with_sp1_standard.iso,hdc:cdrom,r', ]
    cdrom="/ovm/trees/ISO/WIN/en_windows_server_2003_with_sp1_standard.iso"
    
  4. Restart the hardware virtualized guest with the xm create command. The installation continues.

E.12 CD-ROM Image Not Found

If you create a paravirtualized or hardware virtualized guest using a configuration file, and the CDROM image cannot be found during the installation, you may have the IDE devices in the incorrect order. Putting the IDE devices in order fixes this problem. Check that the disk = [ ... ] parameter is defined as hdc:cdrom and is included before hda, otherwise the usual boot='dc' configuration fails to find the CDROM image.

E.13 Firewall Blocks NFS Access

Oracle VM Server blocks NFS access from any external computer (or guest) by default. This may cause problems when trying to create a guest using an NFS connection. To resolve this, disable the firewall with the following command:

# service iptables stop

E.14 Migrating Domains

You cannot migrate domains on computers with hardware that is not identical. To migrate a domain, you must have hardware that is the same make and model. You must also have the same Oracle VM Server release.

E.15 Attaching to a Console with the Grub Boot Loader

Tracking down startup problems with a hardware virtualized guest may be difficult because you may not be able to attach a console using the xm console command. To workaround this problem, you can include a console in the guest's Grub boot loader, and connect to a console during boot.

To include a console in the Grub boot loader, add the following lines before the first "title ..." line in the /etc/grub.conf file:

serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console