| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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.
Regards,
Anthony Liguori
Stefan
>
> 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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home