David Scott wrote:
Something like the attached, which seems to work well for me when
specifying driverName = qemu, e.g.
disk type='file' device='disk'
driver name='qemu'/
source file='/var/lib/xen/images/sles11sp2-pv/disk0.raw'/
target dev='xvda' bus='xen'/
/disk
This also works for me!
Good to hear. I'll send the patch to the libvirt list.
On a related note, what do you think about the attached patch? It
allows the user to select a non-default qemu via the emulator
element. My domain XML looked like this:
devices
emulator/usr/lib/xen/bin/qemu-system-i386/emulator
IMO, the possible emulators should be exposed in the capabilities. E.g.
on a machine with both kvm and qemu, both emulators are shown as
possibilities for an hvm, x86_64 guest
# virsh capabilities
...
guest
os_typehvm/os_type
arch name='x86_64'
wordsize64/wordsize
domain type='qemu'
emulator/usr/bin/qemu-system-x86_64/emulator
machinepc-1.1/machine
machine canonical='pc-1.1'pc/machine
machinepc-1.0/machine
machinepc-0.15/machine
machinepc-0.14/machine
machinepc-0.13/machine
machinepc-0.12/machine
machinepc-0.11/machine
machinepc-0.10/machine
machineisapc/machine
/domain
domain type='kvm'
emulator/usr/bin/qemu-kvm/emulator
machinepc-1.1/machine
machine canonical='pc-1.1'pc/machine
machinepc-1.0/machine
machinepc-0.15/machine
machinepc-0.14/machine
machinepc-0.13/machine
machinepc-0.12/machine
machinepc-0.11/machine
machinepc-0.10/machine
machineisapc/machine
/domain
/guest
...
disk device=disk type=network
driver name='qemu'/
source protocol=rbd name=rbd:rbd/ubuntu1204.img/
target dev=hda/
/disk
graphics type=vnc port=-1 autoport=yes listen=0.0.0.0/
/devices
Now that upstream qemu is the default in xen-4.3, it seems useful to
be able to select the traditional qemu for older VMs.
Agreed. And reporting that both emulators exist via the capabilities
would be helpful for users.
Also I backported this to my xen-4.2 system and used this patch + your
patch + the previous 'stat()' fix to successfully start a VM on ceph
storage via libvirt + libxl (my quest is almost complete!)
Nice!
diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
index f549a5d..abbd3c0 100644
--- a/src/libxl/libxl_conf.c
+++ b/src/libxl/libxl_conf.c
@@ -811,6 +811,30 @@ libxlMakeCapabilities(libxl_ctx *ctx)
}
int
+libxlMakeEmulator(virDomainDefPtr def, libxl_domain_config *d_config)
+{
+/* No explicit override means use the default */
+if (!def-emulator) {
+return 0;
+}
+if (strstr(def-emulator, /qemu-system-)) {
+d_config-b_info.device_model_version =
+LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;
+return 0;
+}
Here we could check the requested emulator against the capabilities, and
then do the proper mapping for device_model_version.
Do you have time for an upstream libvirt patch to expose the possible
emulators in the capabilities, along with this patch allowing the user
to specify one?
Regards,
Jim
+if (strstr(def-emulator, /qemu-dm)) {
+d_config-b_info.device_model_version =
+LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
+return 0;
+}
+virReportError(VIR_ERR_INTERNAL_ERROR,
+ _(libxenlight doesn't support emulator '%s'),
+ def-emulator);
+return -1;
+}
+
+
+int
libxlBuildDomainConfig(libxlDriverPrivatePtr driver,
virDomainDefPtr def, libxl_domain_config *d_config)
{
@@ -834,6 +858,10 @@ libxlBuildDomainConfig(libxlDriverPrivatePtr driver,
goto error;
}
+if (libxlMakeEmulator(def, d_config) 0) {
+goto error;
+}
+
d_config-on_reboot = def-onReboot;
d_config-on_poweroff = def-onPoweroff;
d_config-on_crash = def-onCrash;
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
