TroubleshootingThis chapter provides answers to commonly asked questions. In order to improve your user experience with VirtualBox, it is recommended to read this section to learn more about common pitfalls and get recommendations on how to use the product.
General
Collecting debugging information
For problem determination, it is often important to collect debugging information which can be analyzed by VirtualBox support. This section contains information about what kind of information can be obtained.
Every time VirtualBox starts up a VM, a log file is created containing some information about the VM configuration and runtime events. The log file is called VBox.log and resides in the VM log file folder. Typically this will be a directory like this:
$HOME/.VirtualBox/Machines/{machinename}/Logs
When starting a VM, the configuration file of the last run will be renamed to .1, up to .3. Sometimes when there is a problem, it is useful to have a look at the logs.
Also when requesting support for VirtualBox, supplying the corresponding log file is mandatory.
For convenience, for each virtual machine, the VirtualBox main window can show these logs in a window. To access it, select a virtual machine from the list on the left and select “Show logs...“ from the “Machine” window.
Occasionally, some host file systems provide very poor writing performance and as a consequence cause the guest to time out IDE commands. This is normal behavior and should normally cause no real problems, as the guest should repeat commands that have timed out. However some guests (e.g. some Linux versions) have severe problems if a write to a VDI file takes longer than about 15 seconds. Some file systems however require more than a minute to complete a single write, if the host cache contains a large amount of data that needs to be written.
The symptom for this problem is that the guest can no longer access its files during large write or copying operations, usually leading to an immediate hang of the guest.
In order to work around this problem (the true fix is to use a faster file system that doesn’t exhibit such unacceptable write performance), it is possible to ush the VDI
after a certain amount of data has been written. This interval is normally infinite, but can be configured individually for each disk of a VM using the following command:
VBoxManage setextradata
"VBoxInternal/Devices/piix3ide/0/LUN#[x]/Config/FlushInterval" [b]
The value [x] that selects the disk is 0 for the master device on the first channel, 1 for the slave device on the first channel, 2 for the master device on the second channel or 3 for the master device on the second channel. Only disks support this configuration option. It must not be set for CD-ROM drives.
The unit of the interval [b] is the number of bytes written since the last ush. The value for it must be selected so that the occasional long write delays do not occur.
Since the proper ush interval depends on the performance of the host and the host filesystem, finding the optimal value that makes the problem disappear requires some experimentation. Values between 1000000 and 10000000 (1 to 10 megabytes) are a good starting point. Decreasing the interval both decreases the probability of the problem and the write performance of the guest. Setting the value unnecessarily low will cost performance without providing any benefits. An interval of 1 will cause a ush for each write operation and should solve the problem in any case, but has a severe write performance penalty.
Providing a value of 0 for [b] is treated as an infinite ush interval, effectively disabling this workaround. Removing the extra data key by specifying no value for [b] has the same effect.
Responding to guest IDE ush requests
If desired, the virtual disk images (VDI) can be ushed when the guest issues the IDE FLUSH CACHE command. Normally these requests are ignored for improved performance. To enable ushing, issue the following command:
VBoxManage setextradata
"VBoxInternal/Devices/piix3ide/0/LUN#[x]/Config/IgnoreFlush" 0
The value [x] that selects the disk is 0 for the master device on the first channel, 1 for the slave device on the first channel, 2 for the master device on the second channel or 3 for the master device on the second channel. Only disks support this configuration option. It must not be set for CD-ROM drives.
Linux kernel module refuses to load
If the VirtualBox kernel module (vboxdrv) refuses to load, i.e. you get an “Error inserting vboxdrv: Invalid argument”, check (as root) the output of the dmesg command to find out why the load failed. The most common reasons are:
• With Linux 2.6.19 and higher, the NMI watchdog may be active. Add nmi_watchdog=0 to the kernel command line (e.g. in your grub configu-
ration) and reboot. With the Debian and Ubuntu installation modules, execute sudo dpkg-reconfigure virtualbox again.
• The kernel disagrees about the version of the gcc used to compile the module.
Make sure that you use the same compiler as used to build the kernel.
Linux host’s CD/DVD drive not found
If you have configured a virtual machine to use the host’s CD/DVD drive, but this does not appear to work, make sure that the current user has permission to access the corresponding Linux device file (usually /dev/cdrom or similar). On most distributions, the user must be added to a corresponding group (usually called cdrom or cdrw).
Also, if your CD/DVD device has a different name, VirtualBox may be unable to find it. On Linux hosts, VirtualBox performs the following steps to locate your CD/DVD drives:
1. VirtualBox examines if the environment variable VBOX_CDROM is defined (see below). If so, VirtualBox omits all the following checks.
2. VirtualBox tests if /dev/cdrom works.
3. In addition, VirtualBox checks if any CD/DVD drives are currently mounted by chec ing /etc/mtab.
4. In addition, VirtualBox checks if any of the entries in /etc/fstab point to CD/DVD devices.
In other words, you can try to set VBOX_CDROM to contain a list of your CD/DVD devices, separated by colons, for example as follows:
export VBOX_CDROM=’/dev/cdrom0:/dev/cdrom1’
Linux host’s oppy not found
The previous instructions (for CD/DVD drives) apply accordingly to oppy disks, except that VirtualBox tests for /dev/fd* devices by default. This can be overridden with the VBOX_FLOPPY environment variable.
Strange guest IDE error messages when writing to CD/DVD
If the experimental CD/DVD writer support is enabled with an incorrect VirtualBox, host or guest configuration, it is possible that any attempt to access the CD/DVD writer fails and simply results in guest kernel error messages (for Linux guests) or application error messages (for Windows guests). VirtualBox performs the usual consistency checks when a VM is powered up (in particular it aborts with an error message if the device for the CD/DVD writer is not writable by the user starting the VM), but it cannot detect all misconfigurations. The necessary host and guest OS configuration is not specific for VirtualBox, but a few frequent problems are listed here which occurred in connection with VirtualBox.
Special care must be taken to use the correct device. The configured host CD/DVD device file name (in most cases /dev/cdrom) must point to the device that allows writing to the CD/DVD unit. For CD/DVD writer units connected to a SCSI controller or to a IDE controller that interfaces to the Linux SCSI subsystem (common for some SATA controllers), this must refer to the SCSI device node (e.g. /dev/scd0). Even for IDE CD/DVD writer units this must refer to the appropriate SCSI CD-ROM device node (e.g. /dev/scd0) if the ide-scsi kernel module is loaded. This module is required for CD/DVD writer support with all Linux 2.4 kernels and some early 2.6 kernels. Many Linux distributions load this module whenever a CD/DVD writer is detected in the system, even if the kernel would support CD/DVD writers without the module. VirtualBox supports the use of IDE device files (e.g. /dev/hdc), provided the kernel supports this and the ide-scsi module is not loaded. Similar rules (except that within the guest the CD/DVD writer is always an IDE device) apply to the guest configuration. Since this setup is very common, it is likely that the default configuration of the guest works as expected.
VBoxSVC IPC issues
On Linux, VirtualBox makes use of a custom version of Mozilla XPCOM (cross platform component object model) for inter and intra process communication. The process VBoxSVC serves as a communication hub between different VirtualBox processes and maintains the global configuration, i.e. the XML database. When starting a VirtualBox component, the processes VBoxSVC and VirtualBoxXPCOMIPCD are started automatically. They are only accessible from the user account they are running under. VBoxSVC owns the VirtualBox configuration database which normally resides in ˜ /.VirtualBox and while it is running, the configuration files are locked. Communication between the various VirtualBox components and VBoxSVC is performed through a local domain socket residing in /tmp/.vbox-
cation problems (i.e. a VirtualBox application cannot communicate with VBoxSVC), terminate the daemons and remove the local domain socket directory.
If USB is not working on your Linux host, make sure that the current user has permission to access the USB filesystem (usbfs), which VirtualBox relies on to retrieve valid information about your host’s USB devices.
As usbfs is a virtual filesystem, a chmod on /proc/bus/usb has no effect. The permissions for usbfs can therefore only be changed by editing the /etc/fstab file.
For example, most Linux distributions have a user group called usb or similar, of which the current user must be a member. To give all users of that group access to usbfs, make sure the following line is present:
# 85 is the USB group
none /proc/bus/usb usbfs devgid=85,devmode=664 0 0
Replace 85 with the group ID that matches your system (search /etc/group for “usb” or similar). Alternatively, if you don’t mind the security hole, give all users access to USB by changing “664” to “666”.
The various distributions are very creative from which script the usbfs filesys tem is mounted. Sometimes the command is hidden in unexpected places.
For SuSE 10.0 the mount command is part of the udev configuration file /etc/udev/rules.d/50-udev.rules. As this distribution has no user group
called usb, you may e.g. use the vboxusers group which was created by the VirtualBox installer. Since group numbers are allocated dynamically, the following example uses 85 as a placeholder. Modify the line containing (a linebreak has been inserted to improve readability)
DEVPATH="/module/usbcore", ACTION=="add",
RUN+="/bin/mount -t usbfs usbfs /proc/bus/usb"
and add the necessary options (make sure that everything is in a single line):
DEVPATH="/module/usbcore", ACTION=="add",
RUN+="/bin/mount -t usbfs usbfs /proc/bus/usb -o devgid=85,devmode=664"
Debian Etch has the mount command in /etc/init.d/mountkernfs.sh. Since that distribution has no group usb, it is also the easiest solution to allow all members of the group vboxusers to access the USB subsystem. Modify the line
domount usbfs usbdevfs /proc/bus/usb -onoexec,nosuid,nodev
so that it contains
domount usbfs usbdevfs /proc/bus/usb -onoexec,nosuid,nodev,devgid=85,devmode=664
As usual, replace the 85 with the actual group number which should get access to
USB devices.
Other distributions do similar operations in scripts stored in the /etc/init.d directory.
PAX/grsec kernels
Linux kernels including the grsec patch (see http://www.grsecurity.net/) and derivates have to disable PAX_MPROTECT for the VBox binaries to be able to start a VM. The reason is that VBox has to create executable code on anonymous memory.
Custom Search
If you liked this article, subscribe to the feed by clicking the image below to keep informed about new contents of the blog:
0 comments:
Post a Comment