[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq server
> -----Original Message----- > From: Andrew Cooper [mailto:andrew.cooper3@xxxxxxxxxx] > Sent: 11 May 2016 13:23 > To: Olaf Hering; xen-devel@xxxxxxxxxxxxx; Paul Durrant > Subject: Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq > server > > On 11/05/16 13:18, Olaf Hering wrote: > > Migrating a HVM guest from staging-4.4 to staging fails: > > > > # cat /var/log/xen/qemu-dm-fv-x64-sles12sp1-clean--incoming.log > > char device redirected to /dev/pts/3 (label serial0) > > xen: ioreq server create: Cannot allocate memory > > qemu-system-x86_64: xen hardware virtual machine initialisation failed > > > > Looks like hvm_alloc_ioreq_gmfn finds no bit in > > d->arch.hvm_domain.ioreq_gmfn.mask. Is there a slim change that 4.4 > does not > > know about HVM_PARAM_NR_IOREQ_SERVER_PAGES, and as a result 4.7 > fails to > > configure the guest properly? > > HVM_PARAM_NR_IOREQ_SERVER_PAGES was introduced in 4.6 iirc. CC'ing > Paul > who did this work. The problem is because the new QEMU will assume that the guest was provisioned with ioreq server pages. Somehow it needs to know to behave as a 'default' ioreq server (as qemu trad would) in which case the compatibility code in the hypervisor would DTRT. I guess it would be ok to just have QEMU fall back to the old 'default' HVM param mechanism if creation of an IOREQ server fails. The only other way out would be allow Xen to 'steal' the default server's pages if it doesn't exist. The former obviously requires a patch to QEMU (but the compat code already exists as a compile-time option so it's probably a small-ish change) and the latter requires a patch to Xen. Which is more preferable at this stage? Paul > > ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |