On Fri, Jul 12, 2013 at 09:47:57AM -0600, Eric Blake wrote: > On 07/12/2013 08:54 AM, Ján Tomko wrote: > > Since qemu-kvm 1.1 [1] (since 1.3. in upstream QEMU [2]) > > '-no-kvm-pit-reinjection' has been deprecated. > > Use -device kvm-pit,lost_tick_policy=discard instead. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=978719 > > > > [1] http://git.kernel.org/cgit/virt/kvm/qemu-kvm.git/commit/?id=4e4fa39 > > [2] http://git.qemu.org/?p=qemu.git;a=commitdiff;h=c21fb4f > > --- > > > @@ -2446,13 +2448,12 @@ virQEMUCapsInitArchQMPBasic(virQEMUCapsPtr qemuCaps, > > > > /* > > * Currently only x86_64 and i686 support PCI-multibus, > > - * -no-acpi and -no-kvm-pit-reinjection. > > + * -no-acpi > > */ > > 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. 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