[Libvir] RFC: Broadcast our presence with avahi
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 -=|
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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
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 -=|
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
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 -=|
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
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 -=|
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
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 -=|
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Gerd Hoffmann -
Richard W.M. Jones