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?
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.
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list