Quoting Alex Bligh (alex@xxxxxxxxxxx): > > On 29 Sep 2014, at 11:08, Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > > On Sun, Sep 28, 2014 at 09:33:08PM +0100, Alex Bligh wrote: > >> Hang on a second! v2 of this patch DID use a new virtual machine, > >> called exactly that. I thought you were objecting to that and > >> wanting a machine parameter instead! It's far easier with a new > >> machine type, and I'd far prefer a new machine type. > >> > >> If you were just objecting to the fact that pc-1.0 was made to > >> be an alias of either one or the other at compile time, simply > >> drop the second patch of the v2 patchset. > > > > I think same applies to v3 that I reviewed right? > > Absolutely, I'm fine with just a new machine type. > > This means that management tools will need to learn to > > add -qemu-kvm suffix to the machine name if user > > requested compatibility with qemu-kvm. > > I think there were some implementation issues with patch 1/2 > > though. > > > >> If we have a new machine type, I don't /think/ I need the early_init > >> thing at all (I may be wrong about that). > > > > Good. > > OK, I will respin this when I get a chance with the new machine > type back and hopefully address some of the other issues you > brought up. Thanks, Alex. I've got working packages for 12.04, 14,04 and 14.10 at ppa:serge-hallyn/qemu-migration2 and have opened three bugs (https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1374622, https://bugs.launchpad.net/ubuntu/+bug/1374617, and https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1374612) to get them into the archive. However if the machine type patches may end up upstream, then obviously I'd prefer to wait for the final upstream set. As we're approaching final freeze for 14.10, I suspect this will mean getting the patches into 15.04 on the first day of the cycle (no FFEs needed there) and then a quick SRU into 12.04 and 14.04. -serge -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list