On 07/12/2013 09:53 AM, Daniel P. Berrange wrote:
>>> if (qemuCaps->arch == VIR_ARCH_X86_64 ||
>>> qemuCaps->arch == VIR_ARCH_I686) {
>>> virQEMUCapsSet(qemuCaps, QEMU_CAPS_PCI_MULTIBUS);
>>> virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_ACPI);
>>> - virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_KVM_PIT);
>>
>> This part seems dubious, like it might break upgrades. If an older
>> libvirt says that qemu has a feature, and a VM is running, then when you
>> upgrade libvirtd and the feature is no longer provided by qemu, then
>> libvirtd may silently drop the domain definition because it can't find a
>> qemu binary that supports the same features as were required by the
>> older libvirtd. It shouldn't hurt to leave this cap bit set, even if
>> the rest of this patch is about avoiding the need to rely on this cap bit.
>
> That shouldn't happen I think. For any runing guest, we have recorded
> the original capabilities in the domain status XML file. So any caps
> we detect against QEMU binaries upon restart will only impact newly
> started guests.
I seem to recall difficulties in the past, such as when developing on a
RHEL machine, where the upstream and the downstream list of cap bits are
different, and where restarting upstream libvirtd had problems with
domains already started by downstream libvirtd. I'd feel better if this
were explicitly tested (easy enough to do - build libvirtd without this
patch, start a domain, rebuild libvirtd with the patch, restart
libvirtd, and see if virsh can still control the domain).
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list