[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] live migration from 4.12 to 4.13 fails due to qemu-xen bug
> -----Original Message----- > From: Olaf Hering [mailto:olaf@xxxxxxxxx] > Sent: 27 January 2020 13:00 > To: Durrant, Paul <pdurrant@xxxxxxxxxxxx> > Cc: xen-devel@xxxxxxxxxxxxx > Subject: Re: [Xen-devel] live migration from 4.12 to 4.13 fails due to > qemu-xen bug > > Am Mon, 27 Jan 2020 11:54:37 +0000 > schrieb "Durrant, Paul" <pdurrant@xxxxxxxxxxxx>: > > > > Should the string "pc-i440fx-3.0" become a configure option? > > I suppose. Could we have "pc-i440fx" as the default, which libxl prefix > matches against qemu's supported versions to select the latest? > > I think the qemu machine variant must become a property of the running > domU, so that it will not get lost during migration. For incoming domUs > without such property some default must be selected by libxl. libxl at > runtime has no info what the initial qemu command was. So this fallback > must become a compile or runtime knob as well. Not sure if it would be too > cumbersome for host admins to apply the equivalent of > "device_model_args_hvm=" to a five or six digit number of running domUs > during or prior their migration. > > There should be a --qemuu-hvm-machine, which may just default to 'pc-1.0' > if not specified. That string should go to > domain_build_info.u.hvm.qemuu_machine, so that it becomes part of the domU > properties. > Could we have an opinion from a toolstack maintainer (cc-ed), please? Paul _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |