[Libvir] Register libvirtd ports with IANA ?
veillard at redhat.com
Mon Jun 18 09:29:37 UTC 2007
On Sun, Jun 17, 2007 at 10:44:05PM +0100, Daniel P. Berrange wrote:
> For the libvirtd we currently use two ports
> 16509 - TCP unencrypted stream
> 16514 - TLS encrypted stream
> My first thought is that we should really use consequetive port numbers
> eg 16510 and 16511.
that would be nicer
> Second, we should register our port numbers with IANA
> Thoughts ?
it's better to do it than not do it :-) The worse case would be a rejection.
I think we need to use that form
I see XenSource already registered 1 port:
xsmsvc 6936/tcp XenSource Management Service
xsmsvc 6936/udp XenSource Management Service
# Roger Klorese <roger&xensource.com> June 2006
and the 2 you suggest are in a currently unassigned area
# 15346-15362 Unassigned
3link 15363/tcp 3Link Negotiation
3link 15363/udp 3Link Negotiation
# Brant Thomsen <brant_thomsen&3com.com> January 2003
# 15364-15554 Unassigned
cisco-snat 15555/tcp Cisco Stateful NAT
cisco-snat 15555/udp Cisco Stateful NAT
Let's discuss the content of the form submission:
Your Name: / Your E-mail:
I guess potentially me, Dan or Rich could be the point of contact.
I'm not against doing it, I'm not against someone else doing it :-)
3 "What message formats are used?"
If I understand correctly in the first case we could describe succintly
the remote_message_header from remote_protocol.h there, at least for
the encrypted version.
4 "What message types are used?"
that would correspond more or less to remote_message_direction
5 "What message op codes are used?"
remote_procedure enum would fit, not sure they want a complete
6 "What message sequences are used?"
Request/reply pairs with optional asynchronous messages.
7 "What functions are performed by this protocol?"
Provide a remote access mechanism for a virtualization API.
"no broadcast or multicast"
8 " Please give us a technical description of your proposed use of the
user port number. (At least 2 paragraphs)"
Hum .... let's try :
When the virtualization layer is started on servers, a daemon is created
to serve local and remote requests allowing control of the virtualization
engine. This includes monitoring of the hypervisor and running domains,
and the possibility to create, control and destroy the set of domains
The port is opened by the daemon waiting for requests. User of the libvirt
API (see http://libvirt.org/) on the controling host(s) will open a connection
to the daemon for the time the application will need to monitor the
virtualization. [After successful TLS authentication ] the daemon will
process requests corresponding to entry points in the libvirt API.
Requests are read from the socket and processed locally, and the result is
returned as a reply message. There is also a need to send asynchronous
messages to provide feedback on specific condition which may arise in
the host or to local virtualized domains. The connection is usually closed
when the application stops monitoring the remote node.
9 "What is the proposed name of the user port number? "
Virtualization Management Service
Libvirt Management Service
I'm not sure if we should put the library name there or the kind of service.
10 " What SHORT name (14 CHARACTER MAXIMUM) do you want associated with this port number?"
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
More information about the libvir-list