[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[libvirt] [PATCH] Allow changing ejectable device in domains using default qemu emulator



When a qemu domain is launched but an emulator is not explicitly
defined, the default emulator is used. Attempts to attach ejectable
devices to a domains using the default emulator fail with the error:
"Error Connecting CDROM: internal error\nCannot determine QEMU argv
syntax (null)".

The following patch is based on similar code in qemudStartVMDaemon() and
qemudBuildCommandLine(). I've tested it and it works.

Honestly, though, I think this patch is just a band-aid. I'd like to
supply a better patch, but I don't have enough experience to judge
certain side effects.

Instead of requiring functions to determine the emulator that will be
used to launch the next qemu domain, qemudStartVMDaemon() should record
the emulator that was used to start the current domain. It should also
record the emulator's capabilities.

This would make it unnecessary to call virDomainDefDefaultEmulator() in
qemudDomainChangeEjectableMedia(). It would also make it possible to
remove the virDomainDefDefaultEmulator() call from
qemudBuildCommandLine().

However, testCompareXMLToArgvFiles() will fail because
qemudBuildCommandLine() needs to know vm->def->emulator and
virDomainDefParseFile() doesn't set vm->def->emulator to a default
value. I don't know if this is a real problem, or if it just means the
test needs to be updated.

In addition, if we simply set vm->dev->emulator =
strdup(virDomainDefDefaultEmulator()) in qemudStartVMDaemon() then
virDomainDefFormat() will dump <emulator>...</emulator> for domains that
did't actually have it explicitly defined. I don't know if this is a bug
or improvement, but it is a change in behavior.

Attachment: 0001-Allow-changing-ejectable-device-in-domains-using-def.patch
Description: application/mbox


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]