(fix mailing list links) |
(Xen is gone. Revamp totally for current fedora offerings.) |
||
Line 1: | Line 1: | ||
== Using virtualization on fedora == | == Using virtualization on fedora == | ||
Fedora | Fedora uses the libvirt family of tools as it's virtualization solution. By default libvirt on Fedora will use Qemu to run guest instances. | ||
For information on other virtualization platforms, refer to http://virt.kernelnewbies.org/TechComparison. | |||
Qemu can emulate a host machine in software, or given a CPU with hardware support (see below) can use [[ KVM | http://www.linux-kvm.org ]] to provide a fast full virtualization. | |||
Other virtualization products and packages are available but are not covered by this guide. | Other virtualization products and packages are available but are not covered by this guide. | ||
{{Admon/note | Fedora can run as a Xen Guest OS, but using Fedora as a Xen Host is currently not supported. }} | |||
Fedora | |||
== Installing and configuring fedora for virtualized guests == | == Installing and configuring fedora for virtualized guests == | ||
This section covers setting up | This section covers setting up libvirt on your system. After the successful completion of this section you will be able to create virtualized guest operating systems. | ||
=== System requirements === | === System requirements === | ||
Line 24: | Line 20: | ||
* At least 600MB of hard disk storage per guest. A minimal command-line fedora system requires 600MB of storage. Standard fedora desktop guests require at least 3GB of space. | * At least 600MB of hard disk storage per guest. A minimal command-line fedora system requires 600MB of storage. Standard fedora desktop guests require at least 3GB of space. | ||
* At least 256 megs of RAM per guest plus 256 for the base OS. At least 756MB is recommended for each guest of a modern operating system. A good rule of thumb is to think about how much memory is required for the operating system normally and allocate that much to the virtualized guest. | * At least 256 megs of RAM per guest plus 256 for the base OS. At least 756MB is recommended for each guest of a modern operating system. A good rule of thumb is to think about how much memory is required for the operating system normally and allocate that much to the virtualized guest. | ||
==== Additional requirements for fully virtualized guests ==== | ==== Additional requirements for fully virtualized guests ==== | ||
Full virtualization with | Full virtualization with KVM requires a CPU with virtualization extensions, that is, the Intel VT or AMD-V extensions. | ||
Verify whether your Intel CPU has Intel VT support (the 'vmx' flag): | Verify whether your Intel CPU has Intel VT support (the 'vmx' flag): | ||
Line 67: | Line 50: | ||
This will install <code>qemu-kvm</code>, <code>python-virtinst</code>, <code>qemu</code>, <code>virt-manager</code>, <code>virt-viewer</code> and all dependencies are needed. Optional packages in this group are <code>gnome-applet-vm</code> and <code>virt-top</code>. | This will install <code>qemu-kvm</code>, <code>python-virtinst</code>, <code>qemu</code>, <code>virt-manager</code>, <code>virt-viewer</code> and all dependencies are needed. Optional packages in this group are <code>gnome-applet-vm</code> and <code>virt-top</code>. | ||
=== | === Confirm libvirtd is running === | ||
After installing the above group, start the libvirtd service. | |||
<pre> | <pre> | ||
su -c "service libvirtd start" | |||
</pre> | |||
</pre> | |||
You may also wish to confirm that it's set to start on boot. | |||
<pre> | <pre> | ||
chkconfig libvirtd on | |||
</pre> | </pre> | ||
=== Networking Support === | |||
By default libvirt will create a private network for your guests on the host machine. This private network will use a 192.168.x.x subnet and not be reachable directly from the network the host machine is on, but virtual guests can use the host machine as a gateway and can connect out via it. If you need to provide services on your guests that are reachable via other machines on your host network you can use iptables DNAT rules to forward in specific ports, or you can setup a Bridged env. | |||
See the [ libvirt networking setup page | http://wiki.libvirt.org/page/Networking ] for more information on how to setup a Bridged network. | |||
=== Creating a fedora guest === | === Creating a fedora guest === | ||
The installation of Fedora guests using anaconda is supported. The installation can be started on the command line via the <code>virt-install</code> program or in the GUI program <code>virt-manager</code> | The installation of Fedora guests using anaconda is supported. The installation can be started on the command line via the <code>virt-install</code> program or in the GUI program <code>virt-manager</code>. | ||
==== Creating a | ==== Creating a guest with virt-install ==== | ||
<code>virt-install</code> is a command line based tool for creating virtualized guests. To start the interactive install process, run the <code>virt-install</code> command | <code>virt-install</code> is a command line based tool for creating virtualized guests. To start the interactive install process, run the <code>virt-install</code> command with the --prompt parameter. | ||
<pre> | <pre> | ||
su -c "/usr/sbin/virt-install" | su -c "/usr/sbin/virt-install --prompt" | ||
</pre> | </pre> | ||
Line 116: | Line 85: | ||
# What is the name of your virtual machine? This is the label that will identify the guest OS. This label is used with <code>virsh</code> commands and <code>virt-manager</code>(Virtual Machine Manager). | # What is the name of your virtual machine? This is the label that will identify the guest OS. This label is used with <code>virsh</code> commands and <code>virt-manager</code>(Virtual Machine Manager). | ||
# How much RAM should be allocated (in megabytes)? This is the amount of RAM to be allocated for the guest instance in megabytes (eg, 256). Note that installation with less than 256 megabytes is not recommended. | # How much RAM should be allocated (in megabytes)? This is the amount of RAM to be allocated for the guest instance in megabytes (eg, 256). Note that installation with less than 256 megabytes is not recommended. | ||
# What would you like to use as the disk (path)? The local path and file name of the file to serve as the disk image for the guest (eg, / | # What would you like to use as the disk (path)? The local path and file name of the file to serve as the disk image for the guest (eg, /var/lib/libvirt/images/name.img). This will be exported as a full disk to your guest. It's best to specify the default /var/lib/libvirt/images/ directory. | ||
# How large would you like the disk to be (in gigabytes)? The size of the virtual disk for the guest (only appears if the file specified above does not already exist). 4.0 gigabytes is a reasonable size for a "default" install | # How large would you like the disk to be (in gigabytes)? The size of the virtual disk for the guest (only appears if the file specified above does not already exist). 4.0 gigabytes is a reasonable size for a "default" install | ||
# What is the install CD-ROM/ISO or URL? This is the path to a Fedora installation tree in the format used by anaconda. NFS, FTP, and HTTP locations are all supported. Examples include: | |||
# What is the install | |||
#* <code>nfs:my.nfs.server.com:/path/to/test2/tree/</code> | #* <code>nfs:my.nfs.server.com:/path/to/test2/tree/</code> | ||
#* <code>http://my.http.server.com/path/to/tree/</code> | #* <code>http://my.http.server.com/path/to/tree/</code> | ||
Line 131: | Line 99: | ||
If graphics were enabled, a VNC window will open and present the graphical installer. If graphics were not enabled, a text installer will appear. Proceed with the fedora installation. | If graphics were enabled, a VNC window will open and present the graphical installer. If graphics were not enabled, a text installer will appear. Proceed with the fedora installation. | ||
==== Creating a | ==== Creating a guest with virt-manager ==== | ||
Start the GUI Virtual Machine Manager by selecting it from the "Applications-->System Tools" menu, or by running the following command: | Start the GUI Virtual Machine Manager by selecting it from the "Applications-->System Tools" menu, or by running the following command: | ||
Line 140: | Line 108: | ||
Enter the <code>root</code> password when prompted. | Enter the <code>root</code> password when prompted. | ||
# Open a connection to a hypervisor by choosing File--> | # Open a connection to a hypervisor by choosing File-->Add connection... | ||
# Choose "qemu" for KVM, or "Xen" for Xen. | # Choose "qemu" for KVM, or "Xen" for Xen. | ||
# Choose "local" or select a method to connect to a remote hypervisor | # Choose "local" or select a method to connect to a remote hypervisor | ||
Line 166: | Line 134: | ||
{1} If you are not root, you will be prompted to enter the root password. Choose<code>Run unprivileged</code> to operate in a read-only non-root mode. | {1} If you are not root, you will be prompted to enter the root password. Choose<code>Run unprivileged</code> to operate in a read-only non-root mode. | ||
* Choose | * Choose the host you wish to manage and click "Connect" in the "Open Connection" dialog window. | ||
* The list of virtual machines is displayed in the main window. | * The list of virtual machines is displayed in the main window. Guests that are running will display a ">" icon. Guests that are not running will be greyed out. | ||
* To manage a particular guest, double click on it, or right click and select "Open". | |||
* A new window for the guest will open that will allow you to use it's console, see information about it's virtual hardware and start/stop/pause it. | |||
* | |||
For further information about <code>virt-manager</code> consult the [http://virt-manager.et.redhat.com/ project website] | For further information about <code>virt-manager</code> consult the [http://virt-manager.et.redhat.com/ project website] | ||
Line 180: | Line 145: | ||
==== Managing guests with virsh ==== | ==== Managing guests with virsh ==== | ||
The <code>virsh</code> command | The <code>virsh</code> command line utility that allows you to manage virtual machines. | ||
Guests can be managed on the command line with the <code>virsh</code> utility. The <code>virsh</code> utility is built around the libvirt management | Guests can be managed on the command line with the <code>virsh</code> utility. The <code>virsh</code> utility is built around the libvirt management APIl: | ||
* <code>virsh</code> has a stable set of commands whose syntax and semantics are preserved across updates to the underlying virtualization platform. | * <code>virsh</code> has a stable set of commands whose syntax and semantics are preserved across updates to the underlying virtualization platform. | ||
* <code>virsh</code> can be used as an unprivileged user for read-only operations (e.g. listing domains, listing domain statistics). | * <code>virsh</code> can be used as an unprivileged user for read-only operations (e.g. listing domains, listing domain statistics). | ||
* <code>virsh</code> can manage domains running under Xen or | * <code>virsh</code> can manage domains running under Xen, Qemu/KVM, esx or other backends with no perceptible difference to the user | ||
{{Admon/note | A valid URI may be passed to <code>virsh</code> with "-c' to connect to a remote libvirtd instance. For details, see http://libvirt.org/uri.html}} | |||
{{Admon/note | A valid URI | |||
To start a virtual machine: | To start a virtual machine: | ||
<pre> | <pre> | ||
su -c "virsh | su -c "virsh create <name of virtual machine>" | ||
</pre> | </pre> | ||
Line 199: | Line 163: | ||
<pre> | <pre> | ||
su -c "virsh -c | su -c "virsh list" | ||
</pre> | |||
To list all virtual machines, running or not: | |||
<pre> | |||
su -c "virsh list --all" | |||
</pre> | </pre> | ||
To gracefully power off a guest: | To gracefully power off a guest: | ||
<pre> | <pre> | ||
su -c "virsh -c | su -c "virsh shutdown <virtual machine (name | id | uuid)>" | ||
</pre> | |||
To non gracefully power off a guest: | |||
<pre> | |||
su -c "virsh destroy <virtual machine (name | id | uuid)>" | |||
</pre> | </pre> | ||
To save a snapshot of the machine to a file: | To save a snapshot of the machine to a file: | ||
<pre> | <pre> | ||
su -c "virsh | su -c "virsh save <virtual machine (name | id | uuid)> <filename>" | ||
</pre> | </pre> | ||
To restore a previously saved snapshot: | To restore a previously saved snapshot: | ||
<pre> | <pre> | ||
su -c "virsh | su -c "virsh restore <filename>" | ||
</pre> | </pre> | ||
To export the configuration file of a virtual machine: | To export the configuration file of a virtual machine: | ||
<pre> | <pre> | ||
su -c "virsh | su -c "virsh dumpxml <virtual machine (name | id | uuid)" | ||
</pre> | </pre> | ||
Line 230: | Line 205: | ||
Bugs in the <code>virsh</code> tool should be reported in [http://bugzilla.redhat.com BugZilla] against the 'libvirt' component. | Bugs in the <code>virsh</code> tool should be reported in [http://bugzilla.redhat.com BugZilla] against the 'libvirt' component. | ||
== Troubleshooting virtualization == | == Troubleshooting virtualization == | ||
Line 258: | Line 229: | ||
The level and type of logging produced by <code>libvirtd</code> | The level and type of logging produced by <code>libvirtd</code> | ||
may be modified in {{filename|/etc/libvirt/libvirtd.conf}}. | may be modified in {{filename|/etc/libvirt/libvirtd.conf}}. | ||
=== Serial console access for troubleshooting and management === | === Serial console access for troubleshooting and management === | ||
Serial console access is useful for debugging kernel crashes and remote management can be very helpful. | |||
Fully-virtualized guest OS will automatically have a serial console configured, but the guest kernel will not be configured to use this out of the box. To enable the guest console in a Linux fully-virt guest, edit the /etc/grub.conf in the guest and add 'console=ttyS0 console=tty0'. This ensures that all kernel messages get sent to the serial console, and the regular graphical console. The serial console can then be access in same way as paravirt guests: | |||
<pre> | <pre> | ||
Line 302: | Line 240: | ||
</pre> | </pre> | ||
Alternatively, the graphical <code>virt-manager</code> program can display the serial console. Simply display the 'console' or 'details' window for the guest | Alternatively, the graphical <code>virt-manager</code> program can display the serial console. Simply display the 'console' or 'details' window for the guest & select 'View -> Serial console' from the menu bar. | ||
=== | === Graphical console access === | ||
In order to get a graphical console on your guest you can either use 'virt-manager' and select the console icon for the guest, or you can use the 'virt-viewer' tool to just directly connect to the console: | |||
<pre> | <pre> | ||
virt-viewer guestname | |||
</pre> | </pre> | ||
=== Accessing data on guest disk images === | === Accessing data on guest disk images === | ||
{{Admon/caution | Remember never to do this while the guest is up and running, as it could corrupt the filesystem}} | {{Admon/caution | Remember never to do this while the guest is up and running, as it could corrupt the filesystem}} | ||
The 'guestfish' package allows you to use a simple shell interface to manipulate guest disk images without needing to run the guest. | |||
<pre> | <pre> | ||
su -c | su -c 'yum install guestfish' | ||
</pre> | </pre> | ||
See 'man guestfish' and [ guestfish recipies | http://libguestfs.org/recipes.html ] for information and some common recipies. | |||
guestfish can also be scripted to change a group of guest disk images in a row. | |||
=== Getting help === | |||
If the Troubleshooting section above does not help you to solve your problem, check the | If the Troubleshooting section above does not help you to solve your problem, check the | ||
list of existing [[Virtualization bugs|virtualization bugs]], and search the archives of the mailing lists in the resources section. If you believe your problem is a previously undiscovered bug, please [[How to debug Virtualization problems|report it]] to Bugzilla. | list of existing [[Virtualization bugs|virtualization bugs]], and search the archives of the mailing lists in the resources section. If you believe your problem is a previously undiscovered bug, please [[How to debug Virtualization problems|report it]] to Bugzilla. | ||
==== Resources ==== | ==== Resources ==== | ||
===== Mailing lists ===== | |||
* General virtualization discussion including [http://www.linux-kvm.org/page/Main_Page KVM] and [http://www.nongnu.org/qemu/ QEMU] | * General virtualization discussion including [http://www.linux-kvm.org/page/Main_Page KVM] and [http://www.nongnu.org/qemu/ QEMU] | ||
: Fedora [http://lists.fedoraproject.org/mailman/listinfo/virt <code>virt</code>] mailing list | : Fedora [http://lists.fedoraproject.org/mailman/listinfo/virt <code>virt</code>] mailing list | ||
Line 399: | Line 284: | ||
* [http://www.libvirt.org Libvirt] discussion | * [http://www.libvirt.org Libvirt] discussion | ||
: Red Hat [http://www.redhat.com/mailman/listinfo/libvir-list <code>libvir-list</code>] mailing list | : Red Hat [http://www.redhat.com/mailman/listinfo/libvir-list <code>libvir-list</code>] mailing list | ||
===== IRC Channels ===== | |||
* Some support for libvirt can be found in the #fedora channel on irc.freenode.net | |||
* More specific libvirt support can be found in #virt on irc.oftc.net. | |||
=== References === | === References === |
Revision as of 18:49, 28 February 2010
Using virtualization on fedora
Fedora uses the libvirt family of tools as it's virtualization solution. By default libvirt on Fedora will use Qemu to run guest instances.
For information on other virtualization platforms, refer to http://virt.kernelnewbies.org/TechComparison.
Qemu can emulate a host machine in software, or given a CPU with hardware support (see below) can use http://www.linux-kvm.org to provide a fast full virtualization.
Other virtualization products and packages are available but are not covered by this guide.
Installing and configuring fedora for virtualized guests
This section covers setting up libvirt on your system. After the successful completion of this section you will be able to create virtualized guest operating systems.
System requirements
The common system requirements for virtualization on fedora are:
- At least 600MB of hard disk storage per guest. A minimal command-line fedora system requires 600MB of storage. Standard fedora desktop guests require at least 3GB of space.
- At least 256 megs of RAM per guest plus 256 for the base OS. At least 756MB is recommended for each guest of a modern operating system. A good rule of thumb is to think about how much memory is required for the operating system normally and allocate that much to the virtualized guest.
Additional requirements for fully virtualized guests
Full virtualization with KVM requires a CPU with virtualization extensions, that is, the Intel VT or AMD-V extensions.
Verify whether your Intel CPU has Intel VT support (the 'vmx' flag):
$ grep vmx /proc/cpuinfo flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm
On some Intel based systems(usually laptops) the Intel VT extensions are disabled in BIOS. Enter BIOS and enable Intel-VT or Vanderpool Technology which is usually located in the CPU options or Chipset menus.
Verify whether your AMD CPU has AMD-V support (the 'svm' flag):
$ grep svm /proc/cpuinfo flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8_legacy
Via Nano processors use the 'vmx' instruction set.
You can use QEMU software emulation for full virtualization. Software virtualization is far slower than virtualization using the Intel VT or AMD-V extensions. QEMU can also virtualize other processor architectures like ARM or PowerPC.
Installing the virtualization packages
When installing fedora, the virtualization packages can be installed by selecting Virtualization in the Base Group in the installer.
For existing fedora installations, QEMU, KVM, and other virtualization tools can be installed by running the following command:
su -c "yum groupinstall 'Virtualization'"
This will install qemu-kvm
, python-virtinst
, qemu
, virt-manager
, virt-viewer
and all dependencies are needed. Optional packages in this group are gnome-applet-vm
and virt-top
.
Confirm libvirtd is running
After installing the above group, start the libvirtd service.
su -c "service libvirtd start"
You may also wish to confirm that it's set to start on boot.
chkconfig libvirtd on
Networking Support
By default libvirt will create a private network for your guests on the host machine. This private network will use a 192.168.x.x subnet and not be reachable directly from the network the host machine is on, but virtual guests can use the host machine as a gateway and can connect out via it. If you need to provide services on your guests that are reachable via other machines on your host network you can use iptables DNAT rules to forward in specific ports, or you can setup a Bridged env.
See the [ libvirt networking setup page | http://wiki.libvirt.org/page/Networking ] for more information on how to setup a Bridged network.
Creating a fedora guest
The installation of Fedora guests using anaconda is supported. The installation can be started on the command line via the virt-install
program or in the GUI program virt-manager
.
Creating a guest with virt-install
virt-install
is a command line based tool for creating virtualized guests. To start the interactive install process, run the virt-install
command with the --prompt parameter.
su -c "/usr/sbin/virt-install --prompt"
The following questions for the new guest will be presented.
- What is the name of your virtual machine? This is the label that will identify the guest OS. This label is used with
virsh
commands andvirt-manager
(Virtual Machine Manager). - How much RAM should be allocated (in megabytes)? This is the amount of RAM to be allocated for the guest instance in megabytes (eg, 256). Note that installation with less than 256 megabytes is not recommended.
- What would you like to use as the disk (path)? The local path and file name of the file to serve as the disk image for the guest (eg, /var/lib/libvirt/images/name.img). This will be exported as a full disk to your guest. It's best to specify the default /var/lib/libvirt/images/ directory.
- How large would you like the disk to be (in gigabytes)? The size of the virtual disk for the guest (only appears if the file specified above does not already exist). 4.0 gigabytes is a reasonable size for a "default" install
- What is the install CD-ROM/ISO or URL? This is the path to a Fedora installation tree in the format used by anaconda. NFS, FTP, and HTTP locations are all supported. Examples include:
nfs:my.nfs.server.com:/path/to/test2/tree/
http://my.http.server.com/path/to/tree/
ftp://my.ftp.server.com/path/to/tree
These options can be passed as command line options, execute virt-install --help
for details.
virt-install
can use kickstart files, for example
virt-install -x ks=kickstart-file-name.ks
.
If graphics were enabled, a VNC window will open and present the graphical installer. If graphics were not enabled, a text installer will appear. Proceed with the fedora installation.
Creating a guest with virt-manager
Start the GUI Virtual Machine Manager by selecting it from the "Applications-->System Tools" menu, or by running the following command:
su -c "virt-manager"
Enter the root
password when prompted.
- Open a connection to a hypervisor by choosing File-->Add connection...
- Choose "qemu" for KVM, or "Xen" for Xen.
- Choose "local" or select a method to connect to a remote hypervisor
- After a connection is opened, click the new icon next to the hypervisor, or right click on the active hypervisor and select "New" (Note - the new icon is going to be improved to make it easier to see)
- A wizard will present the same questions as appear with the
virt-install
command-line utility (see descriptions above). The wizard assumes that a graphical installation is desired and does not prompt for this option. - On the last page of the wizard there is a "Finish" button. When this is clicked, the guest OS is provisioned. After a few moments a VNC window should appear. Proceed with the installation as normal.
Remote management
The following remote management options are available:
- Create SSH keys for root, and use
ssh-agent
andssh-add
before launchingvirt-manager
. - Set up a local certificate authority and issue x509 certs to all servers and clients. For information on configuring this option, refer to http://libvirt.org/remote.html.
Guest system administration
When the installation of the guest operating system is complete, it can be managed using the GUI virt-manager
program or on the command line using virsh
.
Managing guests with virt-manager
Start the Virtual Machine Manager. Virtual Machine Manager is in the "Applications-->System Tools" menu, or execute:
su -c "virt-manager"
{1} If you are not root, you will be prompted to enter the root password. ChooseRun unprivileged
to operate in a read-only non-root mode.
- Choose the host you wish to manage and click "Connect" in the "Open Connection" dialog window.
- The list of virtual machines is displayed in the main window. Guests that are running will display a ">" icon. Guests that are not running will be greyed out.
- To manage a particular guest, double click on it, or right click and select "Open".
- A new window for the guest will open that will allow you to use it's console, see information about it's virtual hardware and start/stop/pause it.
For further information about virt-manager
consult the project website
Bugs in the virt-manager
tool should be reported in BugZilla against the 'virt-manager' component
Managing guests with virsh
The virsh
command line utility that allows you to manage virtual machines.
Guests can be managed on the command line with the virsh
utility. The virsh
utility is built around the libvirt management APIl:
virsh
has a stable set of commands whose syntax and semantics are preserved across updates to the underlying virtualization platform.virsh
can be used as an unprivileged user for read-only operations (e.g. listing domains, listing domain statistics).virsh
can manage domains running under Xen, Qemu/KVM, esx or other backends with no perceptible difference to the user
To start a virtual machine:
su -c "virsh create <name of virtual machine>"
To list the virtual machines currently running:
su -c "virsh list"
To list all virtual machines, running or not:
su -c "virsh list --all"
To gracefully power off a guest:
su -c "virsh shutdown <virtual machine (name | id | uuid)>"
To non gracefully power off a guest:
su -c "virsh destroy <virtual machine (name | id | uuid)>"
To save a snapshot of the machine to a file:
su -c "virsh save <virtual machine (name | id | uuid)> <filename>"
To restore a previously saved snapshot:
su -c "virsh restore <filename>"
To export the configuration file of a virtual machine:
su -c "virsh dumpxml <virtual machine (name | id | uuid)"
For a complete list of commands available for use with virsh
:
su -c "virsh help"
Or consult the manual page: man 1 virsh
Bugs in the virsh
tool should be reported in BugZilla against the 'libvirt' component.
Troubleshooting virtualization
SELinux
The SELinux policy in Fedora has the necessary rules to allow the use of virtualization. The main caveat to be aware of is that any file backed disk images need to be in the directory /var/lib/libvirt/images
. This applies both to regular disk images, and ISO images. Block device backed disks are already labelled correctly to allow them to pass SELinux checks.
Beginning with Fedora 11, virtual machines under SELinux are isolated from each other with sVirt.
Log files
The graphical interface, virt-manager
, used to create and manage
virtual machines, logs to $HOME/.virt-manager/virt-manager.log
.
The virt-install
tool, used to create virtual machines, logs to $HOME/.virtinst/virt-install.log
Logging from virt-manager
and virt-install
may be increased by setting the environment variable LIBVIRT_DEBUG=1
.
See http://libvirt.org/logging.html
All QEMU command lines executed by libvirt
are logged to /var/log/libvirt/qemu/$DOMAIN.log
where $DOMAIN
is the name of the guest.
The libvirtd
daemon is responsible for handling connections from
tools such as virsh
and virt-manager
.
The level and type of logging produced by libvirtd
may be modified in /etc/libvirt/libvirtd.conf
.
Serial console access for troubleshooting and management
Serial console access is useful for debugging kernel crashes and remote management can be very helpful.
Fully-virtualized guest OS will automatically have a serial console configured, but the guest kernel will not be configured to use this out of the box. To enable the guest console in a Linux fully-virt guest, edit the /etc/grub.conf in the guest and add 'console=ttyS0 console=tty0'. This ensures that all kernel messages get sent to the serial console, and the regular graphical console. The serial console can then be access in same way as paravirt guests:
su -c "virsh console <domain name>"
Alternatively, the graphical virt-manager
program can display the serial console. Simply display the 'console' or 'details' window for the guest & select 'View -> Serial console' from the menu bar.
Graphical console access
In order to get a graphical console on your guest you can either use 'virt-manager' and select the console icon for the guest, or you can use the 'virt-viewer' tool to just directly connect to the console:
virt-viewer guestname
Accessing data on guest disk images
The 'guestfish' package allows you to use a simple shell interface to manipulate guest disk images without needing to run the guest.
su -c 'yum install guestfish'
See 'man guestfish' and [ guestfish recipies | http://libguestfs.org/recipes.html ] for information and some common recipies. guestfish can also be scripted to change a group of guest disk images in a row.
Getting help
If the Troubleshooting section above does not help you to solve your problem, check the list of existing virtualization bugs, and search the archives of the mailing lists in the resources section. If you believe your problem is a previously undiscovered bug, please report it to Bugzilla.
Resources
Mailing lists
- Fedora
virt
mailing list
- Xen discussion
- Virtual Machine Manager,
virt-inst
and related tools
- Red Hat
et-mgmt-tools
mailing list
- Libvirt discussion
- Red Hat
libvir-list
mailing list
IRC Channels
- Some support for libvirt can be found in the #fedora channel on irc.freenode.net
- More specific libvirt support can be found in #virt on irc.oftc.net.
References
- http://www-128.ibm.com/developerworks/linux/library/l-linux-kvm/?ca=dgr-lnxw07LinuxKVM
- http://kerneltrap.org/node/8088
Previous Fedora Virtualization Guides: