[Libvir] Register libvirtd ports with IANA ?

Daniel Veillard 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
>    http://www.iana.org/protocols/forms.htm
> 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 
dump though.

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 mailing list