9:26 p.m.
All the really trendy network services these days broadcast their presence
on the LAN using mDNS. In Linux world this means becoming an Avahi client
and registering our services. virt-manager is also able to become an Avahi
client and browser for services. So you'll be able to let the user just
pick a host straight off a list instead of typing in hostname.
The attached patch does two things:
- Extends our event loop implementation so it can modify the event mask
associated with an FD, and the timeout associated with a timer. While
you could simulate this with an add & remove, this has the possibility
of failure (from malloc). Merely updating an existing event can be done
without failure. Avahi needs this ability for its event loop integration
- Added qemu/mdns.c file to actually provide the service information. This
has two parts. The first section of code is taken straight from one of
the Avahi example programs. The second section is a implementaiton of the
Avahi event loop contract in terms of our event API - it works very nicely
which says good things about design of our event loop
Some things...
- I arbitrarily picked a service type of '_libvirtd._tcp'. The docs on
picking service types seem non-existant on Avahi website, but it seems
to be common to use service name from /etc/services and protocol both
prefixed with _.
- I advertise two subtypes, of '_xen.libvirtd._tcp' and
'_qemu.libvirtd._tcp'
What I actually want todo is to be able to probe the libvirt local drivers
to auto-discover what virtualization platforms are available. A sort of
lightweight virConnectOpen which merely returns TRUE/FALSE and doesn't
actually allocate a virConnectPtr object. Need to extend the internal
driver API for this.
- I want to advertise whether the server is configured with TLS certs or
not, so remote clients can automatically choose to use SSH urls with
the remote driver if neccessary.
- Let the admin turn advertisement on/off in the config file because some
people may not like it on their LAN.
If you fancy trying it, avahi-browse --all from another host on the LAN
should show the service being advertised. The advertisements do not cross
LAN routers by default.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
1:43 a.m.
On Fri, Sep 14, 2007 at 03:26:40AM +0100, Daniel P. Berrange wrote:
All the really trendy network services these days broadcast their
presence
on the LAN using mDNS. In Linux world this means becoming an Avahi client
and registering our services. virt-manager is also able to become an Avahi
client and browser for services. So you'll be able to let the user just
pick a host straight off a list instead of typing in hostname.
+1 on the principle, allows to break the bootstrap problem and way better
from an UI perspective (as long as you don't end up with a 200 host lost to
pick from.
The attached patch does two things:
- Extends our event loop implementation so it can modify the event mask
associated with an FD, and the timeout associated with a timer. While
you could simulate this with an add & remove, this has the possibility
of failure (from malloc). Merely updating an existing event can be done
without failure. Avahi needs this ability for its event loop integration
- Added qemu/mdns.c file to actually provide the service information. This
has two parts. The first section of code is taken straight from one of
the Avahi example programs. The second section is a implementaiton of the
Avahi event loop contract in terms of our event API - it works very nicely
which says good things about design of our event loop
Some things...
- I arbitrarily picked a service type of '_libvirtd._tcp'. The docs on
picking service types seem non-existant on Avahi website, but it seems
to be common to use service name from /etc/services and protocol both
prefixed with _.
- I advertise two subtypes, of '_xen.libvirtd._tcp' and
'_qemu.libvirtd._tcp'
What I actually want todo is to be able to probe the libvirt local drivers
to auto-discover what virtualization platforms are available. A sort of
lightweight virConnectOpen which merely returns TRUE/FALSE and doesn't
actually allocate a virConnectPtr object. Need to extend the internal
driver API for this.
- I want to advertise whether the server is configured with TLS certs or
not, so remote clients can automatically choose to use SSH urls with
the remote driver if neccessary.
- Let the admin turn advertisement on/off in the config file because some
people may not like it on their LAN.
If you fancy trying it, avahi-browse --all from another host on the LAN
should show the service being advertised. The advertisements do not cross
LAN routers by default.
Can't review the patch right now, will try over the week-end,
thanks !
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
8:56 a.m.
On Fri, Sep 14, 2007 at 02:43:45AM -0400, Daniel Veillard wrote:
On Fri, Sep 14, 2007 at 03:26:40AM +0100, Daniel P. Berrange wrote:
> All the really trendy network services these days broadcast their presence
> on the LAN using mDNS. In Linux world this means becoming an Avahi client
> and registering our services. virt-manager is also able to become an Avahi
> client and browser for services. So you'll be able to let the user just
> pick a host straight off a list instead of typing in hostname.
+1 on the principle, allows to break the bootstrap problem and way better
from an UI perspective (as long as you don't end up with a 200 host lost to
pick from.
That's for the administrator to decide. If they enable Avahi on their Linux
boxes on a LAN where 100's of boxes are on the same segment they're making
a conscious choice to end up which a huge list ! I wouldn't imagine large
scale deployments using it really because the amount of mDNS traffic may
well get far too large. Very well suited for home / small business users
though
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
2:25 a.m.
New subject: Sense available hypervisors (was: Re: [Libvir] RFC: Broadcast our presence with avahi)
Daniel P. Berrange wrote:
- I advertise two subtypes, of '_xen.libvirtd._tcp' and
'_qemu.libvirtd._tcp'
What I actually want todo is to be able to probe the libvirt local drivers
to auto-discover what virtualization platforms are available. A sort of
lightweight virConnectOpen which merely returns TRUE/FALSE and doesn't
actually allocate a virConnectPtr object. Need to extend the internal
driver API for this.
I wanted this feature too, however I don't think the way that you're
proposing is right.
Just as virConnectGetCapabilities returns the capabilities of the
current hypervisor, I think there should be a call like 'virGetInfo' (or
something like that) which returns the capabilities of the node, which
would include what hypervisors are supported.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
8:53 a.m.
New subject: Sense available hypervisors (was: Re: [Libvir] RFC: Broadcast our presence with avahi)
On Fri, Sep 14, 2007 at 08:25:07AM +0100, Richard W.M. Jones wrote:
Daniel P. Berrange wrote:
> - I advertise two subtypes, of '_xen.libvirtd._tcp' and
> '_qemu.libvirtd._tcp'
> What I actually want todo is to be able to probe the libvirt local
> drivers
> to auto-discover what virtualization platforms are available. A sort of
> lightweight virConnectOpen which merely returns TRUE/FALSE and doesn't
> actually allocate a virConnectPtr object. Need to extend the internal
> driver API for this.
I wanted this feature too, however I don't think the way that you're
proposing is right.
Just as virConnectGetCapabilities returns the capabilities of the
current hypervisor, I think there should be a call like 'virGetInfo' (or
something like that) which returns the capabilities of the node, which
would include what hypervisors are supported.
That would solve the issue of having to have the mdns code hard code the
list of URIs / drivers to probe for. Perhaps virNodeGetCapabilities(). Not
sure what other info we'd want to return besides just a list of usable
connection URIs, or available drivers.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
2:29 a.m.
I'll test the patch out later, just a couple of things though:
+struct qemud_mdns {
+//
+};
+
Hmm?
#define LIBVIRTD_TLS_PORT "16514"
+#define LIBVIRTD_TLS_PORT_NUM 16514
#define LIBVIRTD_TCP_PORT "16509"
+#define LIBVIRTD_TCP_PORT_NUM 16509
In theory the current remote code allows you to use named services
instead of port numbers, which is why they are strings. So this might
(although almost vanishingly unlikely) break existing configuration files.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
8:51 a.m.
On Fri, Sep 14, 2007 at 08:29:47AM +0100, Richard W.M. Jones wrote:
I'll test the patch out later, just a couple of things though:
+struct qemud_mdns {
+//
+};
+
Hmm?
#define LIBVIRTD_TLS_PORT "16514"
+#define LIBVIRTD_TLS_PORT_NUM 16514
#define LIBVIRTD_TCP_PORT "16509"
+#define LIBVIRTD_TCP_PORT_NUM 16509
In theory the current remote code allows you to use named services
instead of port numbers, which is why they are strings. So this might
(although almost vanishingly unlikely) break existing configuration files.
Indeeed. This was a quick hack. The correct thing approach is to call the
getnameinfo() API on the socket FD, using AI_NUMERIC to reverse resolve
the actual address we're listening on back into a port number
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
3:20 a.m.
Hi,
- I arbitrarily picked a service type of '_libvirtd._tcp'.
The docs on
picking service types seem non-existant on Avahi website, but it seems
to be common to use service name from /etc/services and protocol both
prefixed with _.
Cool.
- I want to advertise whether the server is configured with TLS
certs or
not, so remote clients can automatically choose to use SSH urls with
the remote driver if neccessary.
Hmm. Shouldn't work that simply by port number? The tls and non-tls
connections use different port numbers, right? The ssh tunneling case
is a bit icky though ...
And while you are at it, how about announcing the vm vnc screens too
(assuming they are not bound to the loopback interface only) as _rfb._tcp?
cheers,
Gerd
8:50 a.m.
On Fri, Sep 14, 2007 at 10:20:53AM +0200, Gerd Hoffmann wrote:
Hi,
> - I arbitrarily picked a service type of '_libvirtd._tcp'. The docs on
> picking service types seem non-existant on Avahi website, but it seems
> to be common to use service name from /etc/services and protocol both
> prefixed with _.
Cool.
> - I want to advertise whether the server is configured with TLS certs or
> not, so remote clients can automatically choose to use SSH urls with
> the remote driver if neccessary.
Hmm. Shouldn't work that simply by port number? The tls and non-tls
connections use different port numbers, right? The ssh tunneling case
is a bit icky though ...
Yes, actually the port number should be sufficient, even for the SSH case.
In the latter we just advertise _libvirtd._tcp with port 22. Though I think
we might still want to include the info about whether it requires TLS or
not, since as Rich mentions the user can override the default port number
And while you are at it, how about announcing the vm vnc screens too
(assuming they are not bound to the loopback interface only) as _rfb._tcp?
I thought about that too. It is easy for VNC provided by the regular
QEMU driver, since libvirtd manages all the QEMU instances, so knows when
they are running. Its harder for Xen since we don't know when they're
running currently. We'd have to add in the APIs in the driver for getting
notifications back - which would let us use xenstore watches to discover
when Xen instances come & go. To be honest I want this now anyway for
virt-manager so we can reduce the amount of polling we have todo to monitor
VMs on a remote connection, so its probably worth trying this now (at least
for the internal API to start off with).
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
6279
days inactive
6279
days old
8 comments
4 participants
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Gerd Hoffmann -
Richard W.M. Jones