On 18/12/18 09:06, Thomas Huth wrote: > On 2018-12-17 23:57, Michael S. Tsirkin wrote: >> On Mon, Dec 17, 2018 at 05:35:22PM -0200, Eduardo Habkost wrote: >>> On Mon, Dec 17, 2018 at 05:57:37PM +0100, Thomas Huth wrote: >>>> They've been deprecated for two releases and nobody complained that they >>>> are still required anymore, so it's time to remove these now. >>>> And while we're at it, mark the other remaining old 0.x machine types >>>> as deprecated (since they can not properly be used for live-migration >>>> anyway). >>> >>> Do you know why exactly they can't be used for live-migration? > > I don't remember the gory details, but IIRC Paolo once said that when > you live-migrate from a QEMU version < 1.3 and then reboot the guest, it > crashes, ... or something similar. Maybe Paolo can give some details again? Yes---due to the introduction of the memory API, the firmware is not migrated correctly from source to destination. On QEMU <1.3 the 0xf0000-0xfffff area is basically a copy of the higher 0xffff0000-0xffffffff area, while on more recent versions it is initialized with zeroes and the firmware copies from 0xffff0000 to 0xf0000. When you migrate from old to new QEMU, after reboot there's nothing at 0xf0000 and bugs ensue. Paolo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list