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

Re: [Xen-devel] A migration framework for external devices

Stefan Berger wrote:
The problem that I would see with a framework living outside XenD is that you now have two different entities taking care of migration. Certainly it should be one piece of code that does everything. I don't understand your argument about a push/pull migration model. I mean in certain ways everything is push/pull and push is certainly what we have today with a command like "xm migrate <DomID> <Host>", which effectively pushes the vm onto another machine. What would be different in the new model?
Sorry, I should have been more specific. You still have an xm migrate <Dom> <Host> command, but instead of always having a daemon running on Host to receive the migration, it instead uses something like ssh to execute an "xm migrate-incoming <port>" command on the host. Locally, you would use an "xm migrate-outgoing <Dom> <Host> <port>" command.

Since migration doesn't actually do anything when not migrating there's no point in just having an idle thread in Xend (or any idle daemon at all). It also allows you to do clever things like vary the port which should add to the security of migration.
Plug-ins will need to exist in some form on another since knowledge is needed about how to migarte a specific technology and prepare the target system for it - and maybe check the target system first whether that technology is supported there or migration requirements can be met. In a way they do exist today with classes like xen/xend/{pciif,netif,blkif,usbif,tpmif}.py which are all implementing technology-specific code - not for migration, though.
Why do plugins have to exist? The only reason to have a plugin mechanism is to be able to maintain plugins outside of the Xend tree which would require a stable plugin interface. I don't think we're at a point where we can do that.

> Is it static throughout the lifetime of the domain or does it change? The TPM state itself is not static throughout the lifetime of a domain. It does change - if that's what you mean.

> How much state are we talking about migrating?

It's not going to be much in terms of kilobytes or so, but it might end up being the first device that lives outside a domain an needs to be migrated.
How many round trips would it require? If the data is dynamic, it has to be transferred (or at least finalized) during the final stage of migration which is performance critical.
My gut feeling is that we need to design a flexible migration protocol that is is extensibile. So I am just looking around what other poeple think, although I am doing some coding as well :-).
This all sounds like it's going to add complexity. The tools are already far too complex.


Anthony Liguori

> Regards,
> Anthony Liguori
> > Clients on the source machine would communicate with that daemon and
> > transfer the state. The clients would have to be triggered by XenD
> > after a partition is not scheduled anymore and be given the IP address
> > of the target machine. Afterwards there needs to be some
> > synchronization on resuming the scheduling on the target machine after
> > all state has been deserialized.
> > The plugable deamon itself would handle the communication sockets, a
> > low-level protocol which the plugins and clients would use, have
> > support for timing and protocol time-outs and provide threading. The
> > plugins would have to do the rest of what's necessary to communicate
> > with the infrastructure and the higher-level protocol shared with the
> > clients.
> >   Comments?
> >
> >   Stefan
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
> > >

Xen-devel mailing list



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