[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.