QEMU / KVM support in libvirt & virt-manager

FYI, as of libvirt 0.2.0 and virt-manager 0.3.1 there is now (experimental!) support for managing virtual machines running under QEMU or KVM virtualization platforms, as well as the existing Xen support.

Project sites:

http://libvirt.org/
http://virt-manager.org/

Release announcements here:

http://www.redhat.com/archives/libvir-list/2007-February/msg00033.html
http://www.redhat.com/archives/et-mgmt-tools/2007-February/msg00121.html

A little background info, since we've not updated any docs yet... (yes we suck, will do better with docs soon)

The QEMU driver provides a spawn-on-demand daemon which manages all the QEMU instances, their monitor consoles, and config files for offline guest VMs. The KVM support is implemented as part of the generic QEMU driver in libvirt, and can be activated by setting the domain type to 'kvm' in the XML description of a guest being created. As an example description of a KVM guest with QEMUs slirp based user networking, a single harddisk and VNC graphics console, the XML would look like:

<domain type='kvm'>

    <name>demo</name>
    <uuid>c7a5fdb0-3daf-9455-926a-d65c16db1809</uuid>
    <memory>403456</memory>
    <currentMemory>403456</currentMemory>
    <vcpu>1</vcpu>
    <os>
      <type arch='i686' machine='pc'>hvm</type>
      <boot dev='hd'/>
    </os>
    <devices>
      <emulator>/usr/bin/qemu</emulator>
      <disk type='file' device='disk'>
        <source file='/home/berrange/q.img'/>
        <target dev='hda'/>
      </disk>
      <interface type='user'>
      </interface>
      <graphics type='vnc' port='-1'/>
    </devices>

</domain>

The 'virsh' tool can be used to interact with libvirt & QEMU/KVM from the shell by specifying an explicit hypervisor URI. eg to list machines:

   virsh --connect  qemu://session  list

The 'virt-install' tool has also been adapted to support provisioning of QEMU / KVM guests, for example:

   virt-install \
       --connect qemu://session \
       --name demo \
       --ram 400 \
       --file /home/berrange/q.img \
       --cdrom /home/berrange/fedora-core-6-boot-x86_64.iso \
       --accelerate  \
       --vnc \
       --vncport 5905

Finally, 'virt-manager' has been adapted to support all its usual management capabilities for QEMU / KVM guests. Simply select 'QEMU' as the hypevisor type when it puts up the initial 'open connection' dialog.

NB. These are the very first prototype releases to support QEM & KVM and we know of many bugs[1] / limitations. We expect to have updated releases over the coming weeks/months which will make it much more robust / generally useful to regular users....

Regards,
Dan.

[1] The spawn-on-demand bit is broken, so requires /usr/libexec/libvirt_qemud to be run manually.

|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Great; as I see it hit FC6-updates I'll give it a shot.

One thing I saw is that it pulls in Xen as part of the dependencies; perhaps a libvirt-xen and libvirt-kvm subpackage split is called for?

Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

How is one supposed to use it? I tried entering 'qemu://' and 'kvm://' in the 'other hypervisor' thingy, but that didn't work.

error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

The virt-manager in Fedora Core 6 hasn't been updated to the newest 0.3.1 release yet - only the underling libvirt has been pushed to FC6 thus far. What follows is an example illustrating use of the low level 'virsh' command. First we create an XML file describing the VM we want to create, then create a file to serve as a disk image. Then we start virsh connecting to the QEMU hypervisor, define the domain, start it and dump the runtime info & XML. Finally it connects to the VNC port to access the console

 $ cat > newvm.xml <<EOF
 <domain type='qemu'>
   <name>Fedora</name>
   <uuid>c7a5fdbdcdaf9455926ad65c16db1809</uuid>
   <os>
     <type>hvm</type>
     <boot dev='cdrom'/>
   </os>
   <memory>219200</memory>
   <vcpu>2</vcpu>
   <devices>
     <disk type='file' device='disk'>
       <source file='/home/berrange/fedora.img'/>
       <target dev='hda'/>
     </disk>
     <disk type='file' device='cdrom'>
       <source file='/home/berrange/boot.iso'/>
       <target dev='hdc'/>
     </disk>
     <interface type='user'>
       <mac address='00:16:3e:62:a5:08'/>
     </interface>
     <graphics type='vnc' port='5900'/>
   </devices>
 </domain>
 EOF
 $ dd if=/dev/zero of=/home/berrange/fedora.img bs=1M seek=5000 count=0
 $ virsh --connect qemu:///session
 Welcome to virsh, the virtualization interactive terminal.

Type: 'help' for help with commands
'quit' to quit

virsh > define /home/berrange/qemu.xml Domain Fedora defined from /home/berrange/qemu.xml

virsh > list --all
Id Name State
----------------------------------
- Fedora shut off

virsh > start Fedora
Domain Fedora started

virsh > list
Id Name State
----------------------------------
4 Fedora running

virsh > dominfo Fedora

 Id:             4
 Name:           Fedora
 UUID:           c7a5fdbd-cdaf-9455-926a-d65c16db1809
 State:          running
 CPU(s):         2
 CPU time:       0.0s
 Max memory:     219200 kB
 Used memory:    219200 kB

virsh > dumpxml Fedora
<domain type='qemu' id='4'>
<name>Fedora</name> <uuid>c7a5fdbd-cdaf-9455-926a-d65c16db1809</uuid> <memory>219200</memory> <currentMemory>219200</currentMemory> <vcpu>2</vcpu>
<os>

     <type arch='i686' machine='pc'>hvm</type>
     <boot dev='cdrom'/>
   </os>
   <devices>
     <emulator>/usr/bin/qemu</emulator>
     <disk type='file' device='cdrom'>
       <source file='/home/berrange/boot.iso'/>
       <target dev='hdc'/>
       <readonly/>
     </disk>
     <disk type='file' device='disk'>
       <source file='/home/berrange/fedora.img'/>
       <target dev='hda'/>
     </disk>
     <interface type='user'>
     </interface>
     <graphics type='vnc' port='5900'/>

</devices>
</domain>

virsh > quit

 $ vncviewer :0

VNC Viewer Free Edition 4.1.2 for X - built
...

The above illustrates creating a QEMU domain. The use of KVM is completely identical - still use qemu:///session as the hypervisor URL. The change is in the XML file describing the guest VM - in the top level '<domain>' attribute use type='kvm' instead of type='qemu'. You can also use type='kqemu' if desired. NB you can create 'qemu' guests as an user, but if you want to create kvm/kqemu guests you must either be root, or chown the device nod.e

Dan.

|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Will we see it in FC6-updates? I'd like to try it, but I'm not keen on rawhide.

error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Understandable :-)

I'll push it out to FC6 updates soon - I need to do more testing to ensure I don't introduce regressions in the otherwise stable FC6 stack.

Regards,
Dan.

|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Yeah, we've not figured out exactly how to address that dependancy issue yet - the libvirt.so has to link to libxenstore as part of the Xen driver, so even if you only want to manage QEMU instances we still end up pulling in Xen. We're certainly going to make it possible to turn off the Xen stuff at compile time. Not clear how we'd address the RPM dep issue though because the Fedora builds of libvirt will include both Xen & QEMU support. Perhaps we'll have to try a dlopen() approach.

Dan.

|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

I would suggest a /usr/lib/libvirt/xen.so and a /usr/lib/libvirt/qemu.so, which are enumerated by reading /usr/lib/libvirt, and dlopen()ed by libvirt.so. Only /usr/lib/libvirt/xen.so links to libxenstore.

That way, a third party can add a backend by dropping a .so into /usr/lib/libvirt, and libvirt.so itself has no backend-related dependencies -- it doesn't know anything concrete about the backends, in fact.

error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV