[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |