Re: [Xen-API] Xen Management API draft
xen-api-bounces@xxxxxxxxxxxxxxxxxxx wrote on 06/26/2006
> Ewan Mellor wrote:
> > On Mon, Jun 26, 2006 at 06:36:22PM +0100, Daniel P. Berrange
> >>>> VM needs a migrate method:
> >>>> Bool migrate(session id s, vm ref vm, host ref current,
> >>>> destination, Bool test)
> >>> D'oh! We probably want a migrate command in there
> >> How would authentication operate - the destination host must
> >> kind of authentication process before accepting migration
of a VM from
> >> another host. So would this API assume that authentication
> >> have been previoously set up behind the scenes ? If not then
> >> API would need some way to request / receive authenitcation
> > How about this?
> > /**
> > * @returns authToken
> > */
> > String vm_migrate_authorise(String session, String uuid)
> > void vm_migrate(String session, String uuid, String destination,
> > String
> > So you log in to the destination and source as normal, and then
> > "migrate_authorise" to the destination, receive a token
> > has generated randomly, give that to the source, and then the
> > that authToken to the destination as part of the handshake on
> > channel (the connection that the actual memory contents go down).
> > Does that sound OK? This restricts the authentication exchange
> > messages (however we want to do that) and then relies upon session
> tokens from
> > then on.
> It seems there should be a mechanism for ensuring the target host
> capable of hosting the VM as well. Does the target host have
> architecture, cpu flags (if that matters), hypervisor version, etc.?
> guess one could argue that clients should be responsible for ensuring
> the target is acceptable prior to performing the migration, particularly
> when one considers all of the things that could go wrong - e.g. some
> disk on the SAN that the VM requires is not available at the target.
The whole migration procedure should in the optimal
case be 'atomic'. One could allocate resources on the target system and
lock the allocation to ensure that no other system migrates a VM there
that makes your system perform worse on the target system than where it's
being migrated from.
> a minimum though the implementation should handle migration failures
> gracefully and not "lose" the VM, i.e. we start shoveling
pages over to
> the target host and for whatever reason we are unable to bring the
> up there *and* it is no longer running on the source host.
I think Xend actually handles that case already.
> Also, should we be concerned about migrating VMs across untrusted
> networks? Should there be mechanisms to support encrypting the
It would certainly be interesting to have this as
an option. You could use the passed-around authentication token from your
suggestion above to establish a shared key between the source and destination
> xen-api mailing list
xen-api mailing list