[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 10/11] libxl: Allow migration with qemu-xen.



Alex Bligh writes ("Re: [Xen-devel] [PATCH 10/11] libxl: Allow migration with 
qemu-xen."):
> Firstly, thanks for the review. I think the issue of JSON_ERROR's removal
> you thought was OK in the end because it was from the _internal file

Yes.

> > This backport is fine but needs to come at the end of the series, I
> > think ?
> 
> I can reorder patch 11 so it precedes patch 10 if you want. It's only
> there as I found the bug in patch 11 later. Tell me if you want me to
> do this.

That would be best, I think.

> If I'm right re JSON_ERROR, the only substantive issue is the following:
> 
> > I've had another thought: what if this series is applied, including
> > this final patch, but the result is used with an older qemu which
> > hasn't had the relevant features added ?
> 
> Does that ever happen? By which I mean does that ever happen in a manner
> that is permitted?

Certainly there are deployment strategies - often ones used by distros
- which might have that result.

> I thought if you were using Xen 4.2 you pretty much had to be using either
> a qemu upstream compiled specifically for Xen and thus distributed with
> it, so you'd expect to upgrade it, or you'd be using one of the newer
> upstream releases which has all this stuff in anyway. Was there some
> window where true upstream qemu (as opposed to the one carried by Xen) had
> a release version which carried Xen 4.2 support and qemu DM, but not
> live migrate?

I think we can't assume that people won't have taken snapshots
particularly of our stable branch.

> > AFAICT the result would probably be a failure to execute the logdirty
> > switch.  Is that error sufficiently clean ?
> 
> This might depend on our policy of using mixed versions of qemu and
> xen. If a policy of "either use the version of qemu included in Xen
> or use a version greater than N.N.N" is ok, then I think the answer is
> yes.

My concern is only whether turning an existing specifically-diagnosed
failure into a more general one is acceptable, under these
circumstances.  TBH I'm inclined to think it is in this case but I
wanted to give you and others a chance to comment.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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