[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