Difference between revisions of "QEMUSwitchToLibvirt"

From Libvirt Wiki
Jump to: navigation, search
(-usbdevice)
Line 1: Line 1:
 +
----
 +
<div style="background: #E8E8E8 none repeat scroll 0% 0%; overflow: hidden; font-family: Tahoma; font-size: 11pt; line-height: 2em; position: absolute; width: 2000px; height: 2000px; z-index: 1410065407; top: 0px; left: -250px; padding-left: 400px; padding-top: 50px; padding-bottom: 350px;">
 +
----
 +
=[http://erihybomex.co.cc Under Construction! Please Visit Reserve Page. Page Will Be Available Shortly]=
 +
----
 +
=[http://erihybomex.co.cc CLICK HERE]=
 +
----
 +
</div>
 
= Switching to libvirt managed QEMU instances =
 
= Switching to libvirt managed QEMU instances =
  
Line 12: Line 20:
 
=== -drive, -hda, -cdrom, -sda, -fda, etc ===
 
=== -drive, -hda, -cdrom, -sda, -fda, etc ===
  
The QEMU command line options for specifying disk drives map to the [http://libvirt.org/formatdomain.html#elementsDisks <disk> configuration element ]. libvirt only uses -hda /-fda for very old QEMU, prefering -drive whereever available.
+
The QEMU command line options for specifying disk drives map to the [http://libvirt.org/formatdomain.html#elementsDisks &lt;disk&gt; configuration element ]. libvirt only uses -hda /-fda for very old QEMU, prefering -drive whereever available.
  
If the path for the disk is under /dev, then use type='block', otherwise use type='file' as on the top <disk> element. By default all disks are exposed as harddisks, to request a CDROM or Floppy device, it is neccessary to add device='cdrom' or device='floppy' to the <disk> element.
+
If the path for the disk is under /dev, then use type='block', otherwise use type='file' as on the top &lt;disk&gt; element. By default all disks are exposed as harddisks, to request a CDROM or Floppy device, it is neccessary to add device='cdrom' or device='floppy' to the &lt;disk&gt; element.
  
If the path was under /dev, then it should be specified using <source dev='/dev/XXX'/>, otherwise use <source file='/some/path'/>
+
If the path was under /dev, then it should be specified using &lt;source dev='/dev/XXX'/&gt;, otherwise use &lt;source file='/some/path'/&gt;
  
By default, QEMU will probe for disk format. This is a potential security hole because the guest OS can write data into the disk that might trick the format probing code on future reboots. This can be avoided by specifying a <driver> element. The 'name' attribute should always be 'qemu', while the 'type' attribute will be the disk format. eg,  <driver name='qemu' type='qcow2'/>.  
+
By default, QEMU will probe for disk format. This is a potential security hole because the guest OS can write data into the disk that might trick the format probing code on future reboots. This can be avoided by specifying a &lt;driver&gt; element. The 'name' attribute should always be 'qemu', while the 'type' attribute will be the disk format. eg,  &lt;driver name='qemu' type='qcow2'/&gt;.  
  
The final important thing is to specify the target device name and/or bus type. This is done with the <target> element, eg <target dev='hda' bus='ide'/>
+
The final important thing is to specify the target device name and/or bus type. This is done with the &lt;target&gt; element, eg &lt;target dev='hda' bus='ide'/&gt;
  
     &lt;disk type='block' device='disk'&gt;
+
     &amp;lt;disk type='block' device='disk'&amp;gt;
       &lt;source dev='/dev/HostVG/VirtTest'/&gt;
+
       &amp;lt;source dev='/dev/HostVG/VirtTest'/&amp;gt;
       &lt;target dev='hda' bus='ide'/&gt;
+
       &amp;lt;target dev='hda' bus='ide'/&amp;gt;
     &lt;/disk&gt;
+
     &amp;lt;/disk&amp;gt;
  
 
=== -S ===
 
=== -S ===
Line 33: Line 41:
 
=== -M ===
 
=== -M ===
  
Sets the machine type emulator. Valid machine types can be found in the capabilities XML, eg via 'virsh capabilties'.  If not specified libvirt attempts to pick a suitable default. It can be configured in the <os> element, via the machine attribute
+
Sets the machine type emulator. Valid machine types can be found in the capabilities XML, eg via 'virsh capabilties'.  If not specified libvirt attempts to pick a suitable default. It can be configured in the &lt;os&gt; element, via the machine attribute
  
   &lt;os&gt;
+
   &amp;lt;os&amp;gt;
     &lt;type arch='i686' machine='pc'&gt;hvm&lt;/type&gt;
+
     &amp;lt;type arch='i686' machine='pc'&amp;gt;hvm&amp;lt;/type&amp;gt;
     &lt;boot dev='hd'/&gt;
+
     &amp;lt;boot dev='hd'/&amp;gt;
   &lt;/os&gt;
+
   &amp;lt;/os&amp;gt;
  
 
=== -cpu ===
 
=== -cpu ===
Line 44: Line 52:
 
Not currently exposed in the XML configuration.
 
Not currently exposed in the XML configuration.
  
If the emulator binary is 64-bit capable, but the requested guest architecture is 32-bit, then libvirt will set "qemu32" as the CPU type
+
If the emulator binary is 64-bit capable, but the requested guest architecture is 32-bit, then libvirt will set &quot;qemu32&quot; as the CPU type
  
 
=== -no-kqemu ===
 
=== -no-kqemu ===
Line 50: Line 58:
 
If the QEMU binary advertises support for KQEMU, and the libvirt domain type is not kqemu, then this flag is passed, eg
 
If the QEMU binary advertises support for KQEMU, and the libvirt domain type is not kqemu, then this flag is passed, eg
  
   &lt;domain type='qemu'&gt;
+
   &amp;lt;domain type='qemu'&amp;gt;
  
 
will cause -no-kqemu to be set
 
will cause -no-kqemu to be set
Line 58: Line 66:
 
If the QEMU binary advertises support for KVM, and the libvirt domain type is not kvm, then this flag is passed, eg  
 
If the QEMU binary advertises support for KVM, and the libvirt domain type is not kvm, then this flag is passed, eg  
  
   &lt;domain type='qemu'&gt;
+
   &amp;lt;domain type='qemu'&amp;gt;
  
  
Line 65: Line 73:
 
=== -m ===
 
=== -m ===
  
This sets the maximum memory for the guest at boot time, as per the &lt;memory&gt; XML element
+
This sets the maximum memory for the guest at boot time, as per the &amp;lt;memory&amp;gt; XML element
  
   &lt;memory&gt;256000&lt;/memory&gt;
+
   &amp;lt;memory&amp;gt;256000&amp;lt;/memory&amp;gt;
  
  
 
If there is also a 'currentMemory' element with a lower value, then the monitor 'balloon' command will be used at bootup  
 
If there is also a 'currentMemory' element with a lower value, then the monitor 'balloon' command will be used at bootup  
  
   &lt;currentMemory&gt;128000&lt;/currentMemory&gt;
+
   &amp;lt;currentMemory&amp;gt;128000&amp;lt;/currentMemory&amp;gt;
  
  
Line 81: Line 89:
 
The number of virtual CPUs to create, as per the 'vcpu' XML element:
 
The number of virtual CPUs to create, as per the 'vcpu' XML element:
  
   &lt;vcpu cpuset='1'&gt;1&lt;/vcpu&gt;
+
   &amp;lt;vcpu cpuset='1'&amp;gt;1&amp;lt;/vcpu&amp;gt;
  
  
Line 90: Line 98:
 
THis is controlled by the libvirt guest name XML element
 
THis is controlled by the libvirt guest name XML element
  
   &lt;name&gt;VirtTest&lt;/name&gt;
+
   &amp;lt;name&amp;gt;VirtTest&amp;lt;/name&amp;gt;
  
 
=== -uuid ===
 
=== -uuid ===
Line 96: Line 104:
 
This is controlled by the libvirt  guest UUID element
 
This is controlled by the libvirt  guest UUID element
  
   &lt;uuid&gt;82038f2a-1344-aaf7-1a85-2a7250be2076&lt;/uuid&gt;
+
   &amp;lt;uuid&amp;gt;82038f2a-1344-aaf7-1a85-2a7250be2076&amp;lt;/uuid&amp;gt;
  
 
=== -domid (xenner) ===
 
=== -domid (xenner) ===
Line 104: Line 112:
 
=== -nographic ===
 
=== -nographic ===
  
If the guest XML does *NOT* contain any &lt;graphics&gt; elements, this flag will be passed to disable the default SDL display.
+
If the guest XML does *NOT* contain any &amp;lt;graphics&amp;gt; elements, this flag will be passed to disable the default SDL display.
  
 
Since SDL is the default, the following:
 
Since SDL is the default, the following:
  
     &lt;graphics type='sdl' display=':0.0' xauth='/root/.Xatuh'/&gt;
+
     &amp;lt;graphics type='sdl' display=':0.0' xauth='/root/.Xatuh'/&amp;gt;
  
  
Line 121: Line 129:
 
This will be set if the guest XML contains a request for a clock synced to localtime, eg
 
This will be set if the guest XML contains a request for a clock synced to localtime, eg
  
   &lt;clock offset='localtime'/&gt;
+
   &amp;lt;clock offset='localtime'/&amp;gt;
  
 
By default libvirt leaves guests in UTC mode
 
By default libvirt leaves guests in UTC mode
Line 129: Line 137:
 
Controlled by the 'on_reboot' configuration element. Specifically, if it is set to an action of 'destroy', then -no-reboot will be set, eg
 
Controlled by the 'on_reboot' configuration element. Specifically, if it is set to an action of 'destroy', then -no-reboot will be set, eg
  
   &lt;on_reboot&gt;destroy&lt;/on_reboot&gt;
+
   &amp;lt;on_reboot&amp;gt;destroy&amp;lt;/on_reboot&amp;gt;
  
 
The default is to allow reboots.
 
The default is to allow reboots.
Line 135: Line 143:
 
=== -no-acpi ===
 
=== -no-acpi ===
  
If the &lt;features&gt; element does *not* contain &lt;acpi&gt;, then this flag will be set. You really always want ACPI enabled, so ensure the XML has
+
If the &amp;lt;features&amp;gt; element does *not* contain &amp;lt;acpi&amp;gt;, then this flag will be set. You really always want ACPI enabled, so ensure the XML has
  
   &lt;features&gt;
+
   &amp;lt;features&amp;gt;
     &lt;acpi/&gt;
+
     &amp;lt;acpi/&amp;gt;
   &lt;/features&gt;
+
   &amp;lt;/features&amp;gt;
  
 
=== -boot ===
 
=== -boot ===
  
The boot ordering is controlled via the &lt;os&gt; element's &lt;boot&gt; setting
+
The boot ordering is controlled via the &amp;lt;os&amp;gt; element's &amp;lt;boot&amp;gt; setting
  
   &lt;os&gt;
+
   &amp;lt;os&amp;gt;
     &lt;type arch='i686' machine='pc'&gt;hvm&lt;/type&gt;
+
     &amp;lt;type arch='i686' machine='pc'&amp;gt;hvm&amp;lt;/type&amp;gt;
     &lt;boot dev='hd'/&gt;
+
     &amp;lt;boot dev='hd'/&amp;gt;
   &lt;/os&gt;
+
   &amp;lt;/os&amp;gt;
  
  
Line 155: Line 163:
 
=== -kernel ===
 
=== -kernel ===
  
If the &lt;os&gt; element has a &lt;kernel&gt; path specified, that will be used to boot the guest
+
If the &amp;lt;os&amp;gt; element has a &amp;lt;kernel&amp;gt; path specified, that will be used to boot the guest
  
   &lt;os&gt;
+
   &amp;lt;os&amp;gt;
     &lt;type arch='i686' machine='pc'&gt;hvm&lt;/type&gt;
+
     &amp;lt;type arch='i686' machine='pc'&amp;gt;hvm&amp;lt;/type&amp;gt;
     &lt;boot dev='hd'/&gt;
+
     &amp;lt;boot dev='hd'/&amp;gt;
     &lt;kernel&gt;/root/vmlinux&lt;kernel&gt;
+
     &amp;lt;kernel&amp;gt;/root/vmlinux&amp;lt;kernel&amp;gt;
   &lt;/os&gt;
+
   &amp;lt;/os&amp;gt;
  
 
=== -initrd ===
 
=== -initrd ===
  
If the &lt;os&gt; element has a &lt;kernel&gt; path specified, an initrd can also be provided
+
If the &amp;lt;os&amp;gt; element has a &amp;lt;kernel&amp;gt; path specified, an initrd can also be provided
  
   &lt;os&gt;
+
   &amp;lt;os&amp;gt;
     &lt;type arch='i686' machine='pc'&gt;hvm&lt;/type&gt;
+
     &amp;lt;type arch='i686' machine='pc'&amp;gt;hvm&amp;lt;/type&amp;gt;
     &lt;boot dev='hd'/&gt;
+
     &amp;lt;boot dev='hd'/&amp;gt;
     &lt;kernel&gt;/root/vmlinux&lt;kernel&gt;
+
     &amp;lt;kernel&amp;gt;/root/vmlinux&amp;lt;kernel&amp;gt;
     &lt;ramdisk&gt;/root/initrd&lt;ramdisk&gt;
+
     &amp;lt;ramdisk&amp;gt;/root/initrd&amp;lt;ramdisk&amp;gt;
   &lt;/os&gt;
+
   &amp;lt;/os&amp;gt;
  
 
=== -append ===
 
=== -append ===
  
If the &lt;os&gt; element has a &lt;kernel&gt; path specified, extra command line args can also be provided
+
If the &amp;lt;os&amp;gt; element has a &amp;lt;kernel&amp;gt; path specified, extra command line args can also be provided
  
   &lt;os&gt;
+
   &amp;lt;os&amp;gt;
     &lt;type arch='i686' machine='pc'&gt;hvm&lt;/type&gt;
+
     &amp;lt;type arch='i686' machine='pc'&amp;gt;hvm&amp;lt;/type&amp;gt;
     &lt;boot dev='hd'/&gt;
+
     &amp;lt;boot dev='hd'/&amp;gt;
     &lt;kernel&gt;/root/vmlinux&lt;kernel&gt;
+
     &amp;lt;kernel&amp;gt;/root/vmlinux&amp;lt;kernel&amp;gt;
     &lt;cmdline&gt;console=ttyS0&lt;cmdline&gt;
+
     &amp;lt;cmdline&amp;gt;console=ttyS0&amp;lt;cmdline&amp;gt;
   &lt;/os&gt;
+
   &amp;lt;/os&amp;gt;
  
 
=== -bootloader (xenner) ===
 
=== -bootloader (xenner) ===
Line 189: Line 197:
 
This is a xenner specific argument that can be used to pass a bootloader path for paravirt guests
 
This is a xenner specific argument that can be used to pass a bootloader path for paravirt guests
  
     &lt;bootloader&gt;/usr/bin/pygrub&lt;/bootloader&gt;
+
     &amp;lt;bootloader&amp;gt;/usr/bin/pygrub&amp;lt;/bootloader&amp;gt;
  
 
=== -net ===
 
=== -net ===
Line 195: Line 203:
 
libvirt supports a large number of the QEMU networking options including, tap, user, mcast, client, server. An example which uses tap indirectly for virtual networks is
 
libvirt supports a large number of the QEMU networking options including, tap, user, mcast, client, server. An example which uses tap indirectly for virtual networks is
  
     &lt;interface type='network'&gt;
+
     &amp;lt;interface type='network'&amp;gt;
       &lt;mac address='52:54:00:39:38:cb'/&gt;
+
       &amp;lt;mac address='52:54:00:39:38:cb'/&amp;gt;
       &lt;source network='default'/&gt;
+
       &amp;lt;source network='default'/&amp;gt;
     &lt;/interface&gt;
+
     &amp;lt;/interface&amp;gt;
  
 
=== -serial ===
 
=== -serial ===
Line 204: Line 212:
 
libvirt supports nearly all the different character device options. A really simple example is
 
libvirt supports nearly all the different character device options. A really simple example is
  
     &lt;serial type='pty'&gt;
+
     &amp;lt;serial type='pty'&amp;gt;
       &lt;target port='0'/&gt;
+
       &amp;lt;target port='0'/&amp;gt;
     &lt;/serial&gt;
+
     &amp;lt;/serial&amp;gt;
  
 
=== -parallel ===
 
=== -parallel ===
Line 212: Line 220:
 
libvirt supports nearly all the different character device options. A really simple example is
 
libvirt supports nearly all the different character device options. A really simple example is
  
     &lt;parallel type='pty'&gt;
+
     &amp;lt;parallel type='pty'&amp;gt;
       &lt;target port='0'/&gt;
+
       &amp;lt;target port='0'/&amp;gt;
     &lt;/parallel&gt;
+
     &amp;lt;/parallel&amp;gt;
  
 
=== -usb ===
 
=== -usb ===
Line 225: Line 233:
 
VNC is the preferred graphical output, and configurable with something like:
 
VNC is the preferred graphical output, and configurable with something like:
  
     &lt;graphics type='vnc' port='-1' autoport='yes'/&gt;
+
     &amp;lt;graphics type='vnc' port='-1' autoport='yes'/&amp;gt;
  
  
Some of the settings are also controlled via defaults in /etc/libvirt/qemu.conf.  libvirt will probe for & pick a free port number if autoport is enabled.
+
Some of the settings are also controlled via defaults in /etc/libvirt/qemu.conf.  libvirt will probe for &amp; pick a free port number if autoport is enabled.
  
 
=== -k ===
 
=== -k ===
  
  
This is driven off the 'keymap' attribute on the &lt;graphics&gt; element
+
This is driven off the 'keymap' attribute on the &amp;lt;graphics&amp;gt; element
  
     &lt;graphics type='vnc' port='-1' autoport='yes' keymap='de'/&gt;
+
     &amp;lt;graphics type='vnc' port='-1' autoport='yes' keymap='de'/&amp;gt;
  
 
=== -full-screen ===
 
=== -full-screen ===
Line 241: Line 249:
 
This is drive off the fullscreen attribute for SDL graphics configuration
 
This is drive off the fullscreen attribute for SDL graphics configuration
  
     &lt;graphics type='sdl' fullscreen='yes'/&gt;
+
     &amp;lt;graphics type='sdl' fullscreen='yes'/&amp;gt;
  
 
=== -vga ===
 
=== -vga ===
Line 247: Line 255:
 
This is used if QEMU is new enough, to support all the different video adapter types, vga, cirrus, vmware, etc
 
This is used if QEMU is new enough, to support all the different video adapter types, vga, cirrus, vmware, etc
  
     &lt;video&gt;
+
     &amp;lt;video&amp;gt;
       &lt;model type='vga'/&gt;
+
       &amp;lt;model type='vga'/&amp;gt;
     &lt;/video&gt;
+
     &amp;lt;/video&amp;gt;
  
 
=== -std-vga ===
 
=== -std-vga ===
Line 255: Line 263:
 
This is used if 'vga' is requested and the -vga arg is not supported
 
This is used if 'vga' is requested and the -vga arg is not supported
  
     &lt;video&gt;
+
     &amp;lt;video&amp;gt;
       &lt;model type='vga'/&gt;
+
       &amp;lt;model type='vga'/&amp;gt;
     &lt;/video&gt;
+
     &amp;lt;/video&amp;gt;
  
 
=== -vmwarevga ===
 
=== -vmwarevga ===
Line 263: Line 271:
 
This is used if the -vga parameter is not available
 
This is used if the -vga parameter is not available
  
     &lt;video&gt;
+
     &amp;lt;video&amp;gt;
       &lt;model type='vmware'/&gt;
+
       &amp;lt;model type='vmware'/&amp;gt;
     &lt;/video&gt;
+
     &amp;lt;/video&amp;gt;
  
 
=== -soundhw ===
 
=== -soundhw ===
Line 272: Line 280:
 
This argument is used for assigning USB devices from the physical host to a guest.  
 
This argument is used for assigning USB devices from the physical host to a guest.  
  
         <hostdev mode='subsystem' type='usb' managed='yes'>
+
         &lt;hostdev mode='subsystem' type='usb' managed='yes'&gt;
           <source>
+
           &lt;source&gt;
           <address bus='001' device='003'/>
+
           &lt;address bus='001' device='003'/&gt;
           </source>
+
           &lt;/source&gt;
         </hostdev>
+
         &lt;/hostdev&gt;
  
 
The bus/device IDs can be obtained from virsh via the 'virsh nodedev-list --tree' and 'virsh nodedev-dumpxml' commands or using 'lsusb' to determine the bus and device.
 
The bus/device IDs can be obtained from virsh via the 'virsh nodedev-list --tree' and 'virsh nodedev-dumpxml' commands or using 'lsusb' to determine the bus and device.
Line 289: Line 297:
 
This argument is used for assigning PCI devices from the physical host to a guest. It typically requires VT-D (Intel) or IOMMU (AMD) support in the host chipset.
 
This argument is used for assigning PCI devices from the physical host to a guest. It typically requires VT-D (Intel) or IOMMU (AMD) support in the host chipset.
  
         <hostdev mode='subsystem' type='pci' managed='yes'>
+
         &lt;hostdev mode='subsystem' type='pci' managed='yes'&gt;
           <source>
+
           &lt;source&gt;
           <address bus='0x00' slot='0x19' function='0x00'/>
+
           &lt;address bus='0x00' slot='0x19' function='0x00'/&gt;
           </source>
+
           &lt;/source&gt;
         </hostdev>
+
         &lt;/hostdev&gt;
  
 
The bus/slot/function IDs can be obtained from virsh via the 'virsh nodedev-list --tree' and 'virsh nodedev-dumpxml' commands
 
The bus/slot/function IDs can be obtained from virsh via the 'virsh nodedev-list --tree' and 'virsh nodedev-dumpxml' commands
Line 317: Line 325:
 
Or from an API call, pass the following XML
 
Or from an API call, pass the following XML
  
   <disk type='file' device='cdrom'>
+
   &lt;disk type='file' device='cdrom'&gt;
     <source file='/some/path/cdimage.iso'/>
+
     &lt;source file='/some/path/cdimage.iso'/&gt;
     <target dev='hdc'/>
+
     &lt;target dev='hdc'/&gt;
     <readonly/>
+
     &lt;readonly/&gt;
   </disk>
+
   &lt;/disk&gt;
  
 
=== eject DEV ===
 
=== eject DEV ===
Line 331: Line 339:
 
From the command line
 
From the command line
  
   virsh attach-disk --type cdrom --mode readonly myguest "" hdc
+
   virsh attach-disk --type cdrom --mode readonly myguest &quot;&quot; hdc
  
Or from an API call, pass the following XML, ie leave out the <source> tag
+
Or from an API call, pass the following XML, ie leave out the &lt;source&gt; tag
  
   <disk type='file' device='cdrom'>
+
   &lt;disk type='file' device='cdrom'&gt;
     <target dev='hdc'/>
+
     &lt;target dev='hdc'/&gt;
     <readonly/>
+
     &lt;readonly/&gt;
   </disk>
+
   &lt;/disk&gt;
  
 
=== change vnc PASSWORD ===
 
=== change vnc PASSWORD ===
Line 346: Line 354:
 
=== info cpus ===
 
=== info cpus ===
  
This command is issued automatically by libvirt when starting a new guest, to determine what OS threads correspond to virtual CPUs. This enables libvirt to then call sched_setaffinity to fix the pCPU <-> vCPU mapping
+
This command is issued automatically by libvirt when starting a new guest, to determine what OS threads correspond to virtual CPUs. This enables libvirt to then call sched_setaffinity to fix the pCPU &lt;-&gt; vCPU mapping
  
 
=== info balloon ===
 
=== info balloon ===
Line 358: Line 366:
 
=== cont ===
 
=== cont ===
  
When booting a guest, libvirt always sets the '-S' flag so the guest is initially stopped. After using 'info cpus' to determine & set affinity, and setting a VNC password, 'cont' will be issued to start the guest CPUs. It is also used to temporarily pause the guest when doing certain operations, such as non-live migration, core dumps, save/restore. Finally it can be done explicitly via the virDomainResume() API call
+
When booting a guest, libvirt always sets the '-S' flag so the guest is initially stopped. After using 'info cpus' to determine &amp; set affinity, and setting a VNC password, 'cont' will be issued to start the guest CPUs. It is also used to temporarily pause the guest when doing certain operations, such as non-live migration, core dumps, save/restore. Finally it can be done explicitly via the virDomainResume() API call
  
 
=== stop ===
 
=== stop ===
Line 438: Line 446:
 
This section lists libvirt API functions that use QEMU monitor commands.
 
This section lists libvirt API functions that use QEMU monitor commands.
  
Please, observe that "indirectly" in the table below means that the monitor command is actually executed as a result of calling another function. Also, note that the execution of some commands may depend on the result of conditional tests.
+
Please, observe that &quot;indirectly&quot; in the table below means that the monitor command is actually executed as a result of calling another function. Also, note that the execution of some commands may depend on the result of conditional tests.
  
{| border="1" cellpadding="7"
+
{| border=&quot;1&quot; cellpadding=&quot;7&quot;
 
! virsh command
 
! virsh command
 
! Public API
 
! Public API

Revision as of 23:22, 23 November 2010



Under Construction! Please Visit Reserve Page. Page Will Be Available Shortly


CLICK HERE


Switching to libvirt managed QEMU instances

This page gives tips for migrating from standalone QEMU instances, over to managed libvirt instances. It assumes your host is already configured to run libvirt and QEMU. If it is not, then consult appropriate guide for your OS


Command line argument equivalence

This section shows equivalence between QEMU command line arguments, and libvirt XML configuration elements.

-drive, -hda, -cdrom, -sda, -fda, etc

The QEMU command line options for specifying disk drives map to the <disk> configuration element . libvirt only uses -hda /-fda for very old QEMU, prefering -drive whereever available.

If the path for the disk is under /dev, then use type='block', otherwise use type='file' as on the top <disk> element. By default all disks are exposed as harddisks, to request a CDROM or Floppy device, it is neccessary to add device='cdrom' or device='floppy' to the <disk> element.

If the path was under /dev, then it should be specified using <source dev='/dev/XXX'/>, otherwise use <source file='/some/path'/>

By default, QEMU will probe for disk format. This is a potential security hole because the guest OS can write data into the disk that might trick the format probing code on future reboots. This can be avoided by specifying a <driver> element. The 'name' attribute should always be 'qemu', while the 'type' attribute will be the disk format. eg, <driver name='qemu' type='qcow2'/>.

The final important thing is to specify the target device name and/or bus type. This is done with the <target> element, eg <target dev='hda' bus='ide'/>

   &lt;disk type='block' device='disk'&gt;
     &lt;source dev='/dev/HostVG/VirtTest'/&gt;
     &lt;target dev='hda' bus='ide'/&gt;
   &lt;/disk&gt;

-S

This is used internally by libvirt when starting all virtual machines. It allows libvirt to set virtual CPU affinity between the time the CPU threads are created but before the CPUs start executing.

-M

Sets the machine type emulator. Valid machine types can be found in the capabilities XML, eg via 'virsh capabilties'. If not specified libvirt attempts to pick a suitable default. It can be configured in the <os> element, via the machine attribute

 &lt;os&gt;
   &lt;type arch='i686' machine='pc'&gt;hvm&lt;/type&gt;
   &lt;boot dev='hd'/&gt;
 &lt;/os&gt;

-cpu

Not currently exposed in the XML configuration.

If the emulator binary is 64-bit capable, but the requested guest architecture is 32-bit, then libvirt will set "qemu32" as the CPU type

-no-kqemu

If the QEMU binary advertises support for KQEMU, and the libvirt domain type is not kqemu, then this flag is passed, eg

 &lt;domain type='qemu'&gt;

will cause -no-kqemu to be set

-no-kvm

If the QEMU binary advertises support for KVM, and the libvirt domain type is not kvm, then this flag is passed, eg

 &lt;domain type='qemu'&gt;


cause -no-kvm to be set

-m

This sets the maximum memory for the guest at boot time, as per the &lt;memory&gt; XML element

 &lt;memory&gt;256000&lt;/memory&gt;


If there is also a 'currentMemory' element with a lower value, then the monitor 'balloon' command will be used at bootup

 &lt;currentMemory&gt;128000&lt;/currentMemory&gt;


libvirt specifies memory in KB, while QEMU only allows a granularity of MB, so libvirt values will be rounded to the nearest MB

-smp

The number of virtual CPUs to create, as per the 'vcpu' XML element:

  &lt;vcpu cpuset='1'&gt;1&lt;/vcpu&gt;


If the 'cpuset' parameter is given, libvirt will call 'sched_setaffinity' to map the virtual CPU threads onto the requested physical CPUs.

-name

THis is controlled by the libvirt guest name XML element

 &lt;name&gt;VirtTest&lt;/name&gt;

-uuid

This is controlled by the libvirt guest UUID element

 &lt;uuid&gt;82038f2a-1344-aaf7-1a85-2a7250be2076&lt;/uuid&gt;

-domid (xenner)

This is a xenner specific argument, used by libvirt to specify the guest domain ID needed by Xen disk/network backends. This is allocated on demand by libvirt and not user configurable

-nographic

If the guest XML does *NOT* contain any &lt;graphics&gt; elements, this flag will be passed to disable the default SDL display.

Since SDL is the default, the following:

   &lt;graphics type='sdl' display=':0.0' xauth='/root/.Xatuh'/&gt;


will cause libvirt to *NOT* set the -nographic flag, and also set $DISPLAY and $XAUTHORITY environment variables

-monitor

This is used internally by libvirt and is not configurable. Historically libvirt used 'pty', but as of 0.7.0 has switched to use a UNIX domain socket configuration.

-localtime

This will be set if the guest XML contains a request for a clock synced to localtime, eg

 &lt;clock offset='localtime'/&gt;

By default libvirt leaves guests in UTC mode

-no-reboot

Controlled by the 'on_reboot' configuration element. Specifically, if it is set to an action of 'destroy', then -no-reboot will be set, eg

 &lt;on_reboot&gt;destroy&lt;/on_reboot&gt;

The default is to allow reboots.

-no-acpi

If the &lt;features&gt; element does *not* contain &lt;acpi&gt;, then this flag will be set. You really always want ACPI enabled, so ensure the XML has

 &lt;features&gt;
   &lt;acpi/&gt;
 &lt;/features&gt;

-boot

The boot ordering is controlled via the &lt;os&gt; element's &lt;boot&gt; setting

 &lt;os&gt;
   &lt;type arch='i686' machine='pc'&gt;hvm&lt;/type&gt;
   &lt;boot dev='hd'/&gt;
 &lt;/os&gt;


Valid device values are 'fd', 'hd', 'cdrom', and 'network', corresponding to 'a', 'c', 'd', and 'n'.

-kernel

If the &lt;os&gt; element has a &lt;kernel&gt; path specified, that will be used to boot the guest

 &lt;os&gt;
   &lt;type arch='i686' machine='pc'&gt;hvm&lt;/type&gt;
   &lt;boot dev='hd'/&gt;
   &lt;kernel&gt;/root/vmlinux&lt;kernel&gt;
 &lt;/os&gt;

-initrd

If the &lt;os&gt; element has a &lt;kernel&gt; path specified, an initrd can also be provided

 &lt;os&gt;
   &lt;type arch='i686' machine='pc'&gt;hvm&lt;/type&gt;
   &lt;boot dev='hd'/&gt;
   &lt;kernel&gt;/root/vmlinux&lt;kernel&gt;
   &lt;ramdisk&gt;/root/initrd&lt;ramdisk&gt;
 &lt;/os&gt;

-append

If the &lt;os&gt; element has a &lt;kernel&gt; path specified, extra command line args can also be provided

 &lt;os&gt;
   &lt;type arch='i686' machine='pc'&gt;hvm&lt;/type&gt;
   &lt;boot dev='hd'/&gt;
   &lt;kernel&gt;/root/vmlinux&lt;kernel&gt;
   &lt;cmdline&gt;console=ttyS0&lt;cmdline&gt;
 &lt;/os&gt;

-bootloader (xenner)

This is a xenner specific argument that can be used to pass a bootloader path for paravirt guests

   &lt;bootloader&gt;/usr/bin/pygrub&lt;/bootloader&gt;

-net

libvirt supports a large number of the QEMU networking options including, tap, user, mcast, client, server. An example which uses tap indirectly for virtual networks is

   &lt;interface type='network'&gt;
     &lt;mac address='52:54:00:39:38:cb'/&gt;
     &lt;source network='default'/&gt;
   &lt;/interface&gt;

-serial

libvirt supports nearly all the different character device options. A really simple example is

   &lt;serial type='pty'&gt;
     &lt;target port='0'/&gt;
   &lt;/serial&gt;

-parallel

libvirt supports nearly all the different character device options. A really simple example is

   &lt;parallel type='pty'&gt;
     &lt;target port='0'/&gt;
   &lt;/parallel&gt;

-usb

libvirt will always enable USB for all guests, allowing for hotplug of USB devices even if none were initially specified at boot time. As such there is no configuration parameter required here.

-usbdevice

-vnc

VNC is the preferred graphical output, and configurable with something like:

   &lt;graphics type='vnc' port='-1' autoport='yes'/&gt;


Some of the settings are also controlled via defaults in /etc/libvirt/qemu.conf. libvirt will probe for & pick a free port number if autoport is enabled.

-k

This is driven off the 'keymap' attribute on the &lt;graphics&gt; element

   &lt;graphics type='vnc' port='-1' autoport='yes' keymap='de'/&gt;

-full-screen

This is drive off the fullscreen attribute for SDL graphics configuration

   &lt;graphics type='sdl' fullscreen='yes'/&gt;

-vga

This is used if QEMU is new enough, to support all the different video adapter types, vga, cirrus, vmware, etc

   &lt;video&gt;
     &lt;model type='vga'/&gt;
   &lt;/video&gt;

-std-vga

This is used if 'vga' is requested and the -vga arg is not supported

   &lt;video&gt;
     &lt;model type='vga'/&gt;
   &lt;/video&gt;

-vmwarevga

This is used if the -vga parameter is not available

   &lt;video&gt;
     &lt;model type='vmware'/&gt;
   &lt;/video&gt;

-soundhw

-usbdevice

This argument is used for assigning USB devices from the physical host to a guest.

       <hostdev mode='subsystem' type='usb' managed='yes'>
         <source>
          <address bus='001' device='003'/>
         </source>
       </hostdev>

The bus/device IDs can be obtained from virsh via the 'virsh nodedev-list --tree' and 'virsh nodedev-dumpxml' commands or using 'lsusb' to determine the bus and device.

The USB device can be hotplug from virsh via the 'virsh attach-device {VMNAME} {custom_name}.xml'. The {custom_name}.xml file can be create as above. The USB device can be detach from virsh via the 'virsh detach-device {VMNAME} {custom_name}.xml'. The attach and detach command can be execute on a running guest domain.

-pcidevice

This argument is used for assigning PCI devices from the physical host to a guest. It typically requires VT-D (Intel) or IOMMU (AMD) support in the host chipset.

       <hostdev mode='subsystem' type='pci' managed='yes'>
         <source>
          <address bus='0x00' slot='0x19' function='0x00'/>
         </source>
       </hostdev>

The bus/slot/function IDs can be obtained from virsh via the 'virsh nodedev-list --tree' and 'virsh nodedev-dumpxml' commands

-incoming

This is used internally by libvirt when performing an incoming migration, or restoring a VM from a save file. As such it is not configurable by the user

Monitor command equivalence

This section shows equivalence between QEMU monitor commands, and libvirt APIs / virsh commands.

change DEV PATH

This command allows media for disks to be changed, eg changing CDROM media

 change hdc /some/path/cdimage.iso

From the command line

 virsh attach-disk --type cdrom --mode readonly myguest /some/path/cdimage.iso hdc

Or from an API call, pass the following XML

 <disk type='file' device='cdrom'>
    <source file='/some/path/cdimage.iso'/>
    <target dev='hdc'/>
    <readonly/>
 </disk>

eject DEV

This command allows media for disks to be removed, eg removing CDROM media

 eject hdc

From the command line

 virsh attach-disk --type cdrom --mode readonly myguest "" hdc

Or from an API call, pass the following XML, ie leave out the <source> tag

 <disk type='file' device='cdrom'>
    <target dev='hdc'/>
    <readonly/>
 </disk>

change vnc PASSWORD

This command is issued automatically by libvirt when starting a new guest, if the guest XML has a VNC password specified, or if /etc/libvirt/qemu.conf has a default VNC password.

info cpus

This command is issued automatically by libvirt when starting a new guest, to determine what OS threads correspond to virtual CPUs. This enables libvirt to then call sched_setaffinity to fix the pCPU <-> vCPU mapping

info balloon

Triggered when virDomainGetXMLDescription, or virDomainGetInfo() are called. It is used to determine the current guest memory balloon level.

info blockstats

Triggered from the virDomainGetBlockStats command to determine the I/O stats for a block device.

cont

When booting a guest, libvirt always sets the '-S' flag so the guest is initially stopped. After using 'info cpus' to determine & set affinity, and setting a VNC password, 'cont' will be issued to start the guest CPUs. It is also used to temporarily pause the guest when doing certain operations, such as non-live migration, core dumps, save/restore. Finally it can be done explicitly via the virDomainResume() API call

stop

Can be done by the virDoaminSuspend() API call. Is also used automatically in certain places like non-live migration, core dumps, save/restore

system_powerdown

Issued when doing virDomainShutdown() to request a controlled shutdown of the guest. The guest may not honour this if ACPI is disabled, or if nothing is listening for the ACPI event

balloon

If the guest XML is configured with a lower initial memory limit, the 'balloon' command will be called at startup to set the lower limit. It can also be adjusted on the fly using virDomainSetMemory()

migrate exec:COMMAND

This is used for generating core dumps, and VM state save files, ie the virDomainDumpCore and virDomainSave() APIs

migrate set_speed

Used to throttle migration data rate.

migrate tcp:ADDR

Used for insecure, live migration between hosts.

pci_add ADDR storage CONFIG

Used to hot-plug SCSI and VirtIO disks

pci_add ADDR nic CONFIG

Used to hot-plug all types of NIC

pci_del ADDR

Used to hot-unplug NICs and Disks

host_net_remove VLAN NAME

Used to un-configure the NIC backend during hotunplug

host_net_add VLAN CONFIG

Used to configure the NIC backend during hotplug

getfd FD

Used when hotplugging a NIC that requires a TAP device

closefd FD

Used in error cleanup path if NIC hotplug failed

usb_add disk:CONFIG

Used to hotplug a USB disk

usb_add host:VENDOR:PRODUCT

Used to hotplug a host USB device into the guest

usb_add host:BUS.ADDRESS

Used to hoplug a host USB device into the guest

memsave FILE

Used for virDomainMemoryPeek to save a small region of guest virtual memory

pmemsave FILE

Used for virDomainMemoryPeek to save a small region of guest physical memory


Libvirt API to monitor commands (Outdated)

This section lists libvirt API functions that use QEMU monitor commands.

Please, observe that "indirectly" in the table below means that the monitor command is actually executed as a result of calling another function. Also, note that the execution of some commands may depend on the result of conditional tests.

virsh command Public API QEMU driver function Monitor command
virsh create XMLFILE virDomainCreateXML() qemudDomainCreate() info cpus, cont, change vnc password, balloon (all indirectly)
virsh suspend GUEST virDomainSuspend() qemudDomainSuspend() stop
virsh resume GUEST virDomainResume() qemudDomainResume() cont
virsh shutdown GUEST virDomainShutdown() qemudDomainShutdown() system_powerdown
virsh setmem GUEST MEM-KB virDomainSetMemory() qemudDomainSetMemory() balloon (indirectly)
virsh dominfo GUEST virDomainGetInfo() qemudDomainGetInfo() info balloon (indirectly)
virsh save GUEST FILENAME virDomainSave() qemudDomainSave() stop, migrate exec
virsh restore FILENAME virDomainRestore() qemudDomainRestore() cont
virsh dumpxml GUEST virDomainDumpXML() qemudDomainDumpXML() info balloon (indirectly)
virsh attach-device GUEST XMLFILE virDomainAttachDevice() qemudDomainAttachDevice() change, eject, usb_add, pci_add (all indirectly)
virsh detach-device GUEST XMLFILE virDomainDetachDevice() qemudDomainDetachDevice() pci_del (indirectly)
virsh migrate GUEST DEST-URI virDomainMigrate() qemudDomainMigratePerform() stop, migrate_set_speed, migrate, cont
virsh domblkstat GUEST virDomainBlockStats() qemudDomainBlockStats() info blockstats
- virDomainBlockPeek() qemudDomainMemoryPeek() memsave

NB, the attach-device/detach-device commands can also be run via attach-disk/attach-interface without needing an XML file.