Daniel P. Berrange wrote:
On Mon, Jul 16, 2007 at 02:23:32PM -0500, Anthony Liguori wrote:
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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx/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?
A good question, to which I don't have any answer :-) Could just say that
any unrecognised URI is passed down to the underlying driver without libvirt
applying any interpretation of its own.
I would like that :-)
Regards,
Anthony Liguori
Dan
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list