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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list