On Tue, Jul 29, 2014 at 08:31:28AM +0100, Alex Bligh wrote: > Serge, > > > I don't think that is in any way a problem. Is migrating to older > > versions ever actually expected to work? In either case I don't > > think for this particular case it's a problem. > > Good; no; and good - respectively. > > > (The "how to handle this in libvirt" question is more interesting) > > I've been giving this some thought. However rococo we make this, > I think the caller is often going to need to modify the command > line anyway, i.e. is going to need to be aware of the migration > problem. > > For instance, taking Ubuntu as an example, 12.04 shipped with > qemu-kvm-1.0, and a pxe-virtio.rom of just under 64k, giving > a 64k ROM slot. 14.04 ships with qemu-2.0 and a pxe-virtio.rom > of over 80k, giving a 128k ROM slot. So however we fix the > machine types, when migrating in a 12.04 initiated VM, qemu > will need > -global virtio-net-pci.romfile=/path/to/pxe-virtio.rom.12.04 > on the command line (or, if you don't much care about PXE > working on a soft reboot, a blank file of the same size), > whereas when migrating in a 14.04 initiated VM, that must > not be on the command line. > > Fixing this properly would entail requiring that the ROMs are > (effectively) distributed with qemu or at least that all > ROM sizes become part of the machine type standard. This > would have the advantage that loading a larger ROM than > the machine type specifies would fail unless the ROM > size was explicitly configured on the command line. But > this is a subject wider than this patch. > > So the long and the short of it is that libvirt (sadly) like > anything else starting qemu machines needs to know a bit about > different versions of qemu, and be able to replace a machine > type option with a machine type option and more on the > command line. > > My previous suggestion doesn't help much because qemu will > still need to be passed something on the command line. > > I think the best way to go with this patch would be something > like: > > * Add pc-1.0-qemu-kvm as a machine type (done) > > * Rename pc-1.0 to pc-1.0-qemu-git > > * Add an alias for pc-1.0 to either pc-1.0-qemu-git or > pc-1.0-qemu-kvm, configurable at build time with > a ./configure option. The distro can then set this > appropriately. This would default to pc-1.0-qemu-git > (i.e. the current behaviour). > > On distros that only every used one of the above, > ./configure will sort things out, +/- self-inflicted > injuries relating to ROM size changes. If life is > more complicated, libvirt (and other callers) will > need to be aware. pc-1.0-qemu-git and pc-1.0-qemu-kvm > can be used to unambiguously mean the relevant machine > type, which will fix things going forward for that > machine type. > > WDYT? This just means we perpetuate the broken-ness. I would rather we teach libvirt to do the right thing unconditionally. > -- > Alex Bligh > > > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list