|Oracle® VM Server User's Guide
Part Number E15444-04
|PDF · Mobi · ePub|
This Appendix contains information on troubleshooting Oracle VM Server. It contains:
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:
Oracle VM Server directories
Oracle VM Server log files
Oracle VM Server command-line tools
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"
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"
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
Contains more detailed logs of the actions of the Oracle VM Server daemon.
Contains a log of hotplug events. Hotplug events are logged if a device or network script does not start up or become available.
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.
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".
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.
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:
The Oracle VM Server configuration file:
The guest configuration file in either 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.
0.0.0.0sets 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 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 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
-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:
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.
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.
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.
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
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.
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-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.
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:
Restart Oracle VM Server for the changes to take effect.
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.
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.
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.
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
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.
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