[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 0/6] [VERY RFC] Migration Stream v2
On 14/04/14 18:49, George Dunlap wrote: > On Thu, Apr 10, 2014 at 12:21 PM, Andrew Cooper > <andrew.cooper3@xxxxxxxxxx> wrote: >> On 10/04/14 11:42, Ian Campbell wrote: >>> On Wed, 2014-04-09 at 19:28 +0100, Andrew Cooper wrote: >>>> Some design decisions have been take very deliberately (e.g. splitting the >>>> logic for PV and hvm migration) while others have been more along the >>>> lines of >>>> "I think its a sensible thing to do given a lack of any evidence/opinion to >>>> the contrary". >>> Is there some indication of which is which? >> Not really, given the clean rewrite, and also that it is only partially >> complete. >> >>> Should we check in the desigh/spec which was previously posted as part >>> of this? >> I knew I forgot something... >> >> http://xenbits.xen.org/people/andrewcoop/domain-save-format-E.pdf > > What did you imagine might constitute an "Optional" record? > > Other than that, everything looks sensible so far -- but having only > save/restore of one guest type is the easy bit. It's when you start > to have to multiplex across {PV, HVM, PVH} x {disk, network, remus} > that things are going to get more "interesting". > > -George I did not opt for optional records, nor did I author them into the spec. Frankly, I cannot forsee a need for anything other than mandatory records. Nothing required for migration can possibly be optional, and anything else is likely to be toolstack data which necessarily has to be ahead of the domain in the migration stream so the receiving toolstack can create a suitable domain for the new xc_domain_restore() to restore into. As for multiplexing, I have been considering that given the implementation of the live part of migration (which now works, as of a few hours ago). Domain save and domain restore are two very very different operations. Save involves prodding at a live domain and stuffing values into a stream. Restore involves taking stuff from a stream and updating paused state. A lot of the structure of save is common to all types of domain and roughly follows: send some headers start logdirty send some preamble state (p2m size, p2m etc) while consulting dirty bitmap: send some memory pause domain send remaining memory send postamble state (vcpus, tsc, qemu blob etc) send end record I was considering writing a common save routine with domain/arch hooks. This would allow for one canonical implementation of the save code (including how to do the 'live' bit, or how to apply remus) while separating the architecture bits. Restore on the other hand is much more simple, and just involves reading records from the stream in the order found and applying the required changes to the specified domain. Each architecture can have a do {} while() loop which accepts valid records for the specific type of domain. I will experiment with the domain/arch hooks when implementing HVM migration (which should be rather more simple) ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |