[Libguestfs] [PATCH libguestfs 0/4] Add a libvirt backend to libguestfs.

Daniel P. Berrange berrange at redhat.com
Mon Jul 23 09:39:59 UTC 2012


On Sat, Jul 21, 2012 at 08:20:45PM +0100, Richard W.M. Jones wrote:
> This preliminary patch series adds a libvirt backend to libguestfs.
> It's for review only because although it launches the guest OK, there
> are some missing features that need to be implemented.
> 
> The meat of the patch is in part 4/4.
> 
> To save you the trouble of interpreting libxml2 fragments, an example
> of the generated XML and the corresponding qemu command line are
> attached below.  Note the hack required to work around lack of support
> for '-drive [...]snapshot=on'
> 
> Some questions:
> 
> - I've tried to use the minimum set of XML possible to create the
>   guest, leaving libvirt to fill out as much as possible.  How does
>   this XML look?
> 
> - The <name> is mandatory, and I generate one randomly.  Is this a
>   good idea?  I notice that my $HOME/.libvirt directory fills up with
>   random files.  Really I'd like libvirt to generate a random name and
>   just deal with the logfiles.

That's a good question - I have the same issue with libvirt-sandbox
and filling up with log files.

> - How do we query libvirt to find out if qemu supports virtio-scsi?

Info about supported devices is not available via the API. You'd
have to try the create attempt and handle VIR_ERR_CONFIG_UNSUPPORTED

> - Will <source file> work if the source is a host device?

You might be lucky but for correctness you should use source type=block
if the source is a host device. This will almost certainly make a
difference to the way disk locking is performed in the future.

> - Since when has <memory unit> attribute been available?  For example,
>   is it available in RHEL 6?

http://libvirt.org/formatdomain.html#elementsMemoryAllocation


   "unit since 0.9.11"

so, not RHEL6

> - I'm using type="kvm" and I've only tested this on baremetal, but I
>   don't want to force KVM.  If only software emulation is available,
>   I'd like to use it.

You have to query the capabilities to see if KVM is present, otherwise
use type=qemu

> - Is there an easy way to get -cpu host?  Although I have the libvirt
>   capabilities, I'd prefer not to have to parse it if I can avoid
>   that, since libxml2 from C is so arcane.

Yes,   <cpu mode='host-model'/>  uses the host capabilities to
specify a CPU that matches the host verbosely, while
 <cpu mode='host-passthrough'/> just uses '-cpu host'.


> - <source mode> attribute is undocumented.
> 
> Rich.
> 
> ----------------------------------------------------------------------
> 
> <?xml version="1.0"?>
> <domain type="kvm" xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0">
>   <name>1dhdpe3sb9ub2vxd</name>

It would be nice to at least prefix this with 'guestfs-XXXX' so admins
know what app is responsible for the guest.

>   <memory unit="MiB">500</memory>
>   <currentMemory unit="MiB">500</currentMemory>
>   <vcpu>1</vcpu>
>   <clock offset="utc"/>
>   <os>
>     <type>hvm</type>
>     <kernel>/home/rjones/d/libguestfs/.guestfs-500/kernel.3198</kernel>
>     <initrd>/home/rjones/d/libguestfs/.guestfs-500/initrd.3198</initrd>
>     <cmdline>panic=1 console=ttyS0 udevtimeout=600 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm </cmdline>
>   </os>
>   <devices>
>     <controller type="scsi" index="0" model="virtio-scsi"/>
>     <disk type="file" device="disk">
>       <source file="/home/rjones/d/libguestfs/test1.img"/>
>       <target dev="sda" bus="scsi"/>
>       <driver name="qemu" format="raw" cache="none"/>
>       <address type="drive" controller="0" bus="0" target="0" unit="0"/>

NB you don't need to specify <address> elements unless you actually
want to have full control over the controller/bus/target/unit
numbering

>     </disk>
>     <disk type="file" device="disk">
>       <source file="/home/rjones/d/libguestfs/.guestfs-500/root.3198"/>
>       <target dev="sdb" bus="scsi"/>
>       <driver name="qemu" format="raw" cache="unsafe"/>
>       <address type="drive" controller="0" bus="0" target="1" unit="0"/>
>     </disk>
>     <channel type="unix">
>       <source mode="bind" path="/home/rjones/d/libguestfs/libguestfsSSg3Kl/guestfsd.sock"/>

NB, current SELinux policy will prevent QEMU creating a socket
in this location. You probably want to ask the SELinux folks
to add a rule to the policy to allow creation of sockets
like  $HOME/.libguestfs/qemu/$VMNAME.guestfsd


>       <target type="virtio" name="org.libguestfs.channel.0"/>
>     </channel>
>   </devices>
>   <qemu:commandline>
>     <qemu:arg value="-set"/>
>     <qemu:arg value="drive.drive-scsi0-0-1-0.snapshot=on"/>
>   </qemu:commandline>
> </domain>


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|




More information about the Libguestfs mailing list