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

Re: [Libvir] Re: [PATCH 1/2] virDomainMigrate implementation (Xen only, no remote, no qemu, no virsh)



Daniel P. Berrange wrote:
On Mon, Jul 16, 2007 at 06:34:57PM +0100, Richard W.M. Jones wrote:
Daniel P. Berrange wrote:
On Mon, Jul 16, 2007 at 11:30:33AM -0500, Anthony Liguori wrote:
Richard W.M. Jones wrote:
Anthony Liguori wrote:
For instance, let's say at a university they use an ldap directory to authenticate users and they decide to implement a migration handler that uses that for authentication. They may name this "uni://" and it'll just work. How would they get at this in libvirt without exposing URIs directly?
My latest proposal[1] has a transport parameter (a string) which covers this, in as much as it would allow you to construct URIs which are:

<transport>://<hostname>:<port>
SSH requires:

ssh://[user ]hostname[:port]

So that wouldn't work :-(
Sure it would - rich was just showing simplified syntax - the URI rules/spec allow for a username and we already use this syntax with a username in the remote driver URIs. eg

$ virsh --connect qemu+ssh://root celery virt boston redhat com/system list --all
Anthony is right that my revised proposal limits the migration to just three parameters: transport, hostname and port.

https://www.redhat.com/archives/libvir-list/2007-July/msg00227.html

Perhaps instead we should replace hostname with a URI parameter, understood as either a simple hostname, IP address, a "hostname:port" string [IPv6?], or a full URI. However I feel inevitably this is going to cause hypervisor dependencies to come into libvirt code, which should be avoidable.

I think we can expose URIs without directly making the libvirt API hypervisor
specific. Even though Anthony is talking with respect to QEMU/KVM there, the concepts is reasonably applicable to Xen too - there's no reason XenD
could not be enhanced to support migration over a user-defined transport.

So, when thinking about URIs for migration we could consider that there are
2 classes of URI

 - Pre-defined 'standard' URIs - TCP, TCP with SSL/TLS, and SSH being the
   most obvious - we can easily define clear & portable semantics for these
   URIs

 - User-define 'custom' URIs - these are really site/deployment specific,
   rather than hypervisor specific. ie, if someone implemented a way to deal
   with foo://bar/, they could provide impls for both Xen & QEMU

How would a user define a custom URI?

Regards,

Anthony Liguori

We should be able to guarentee that 'standard' URIs work forever, while for
custom URIs we can allow them to be passed through, and not provide any
guarentees about their behaviour/usage  - in particular make no guarentees
that a future libvirt won't define more 'standard' URI schemes which could
potentially clash with use-define custom schemes.

Dan.


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