Richard W.M. Jones wrote: Attached is the patch to add the additional types of errors to virterror. VIR_FROM_REMOTE indicates that the error originated in the remote driver. There are two further subclasses for general RPC-related errors and GnuTLS-related errors. Note that if a regular error (eg. VIR_FROM_XEN) is generated on the server side it is passed through the connection to the client transparently (there is no "wrapping" of errors or anything like that). Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 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. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)

On Wed, May 02, 2007 at 07:08:28PM +0100, Richard W.M. Jones wrote: Looks fine to me, the only comment I have is that if you have an extra string you expect it to be the full message error instead of just an extra information, but that's okay. Please apply I don't see anything controversial there :-) 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/

Richard W.M. Jones wrote: These are the additional files required to describe the XDR-based protocol for client-server communications, with the homebrew RPC mechanism on top. The first file is the protocol itself. The second file is a Perl script to run after rpcgen which allows the code to compile with -Wall -Werror -fstrict-aliasing, and fixes a 64 bit bug (that fix really should go upstream BTW). The last two files are the actual rpcgen-generated rpcgen_fix-fixed code. I put these two files into EXTRA_DIST because I feel that people shouldn't be required to have rpcgen & Perl just to compile libvirt. (These files are arch-independent so there is no need to recompile them unless remote_protocol.x itself changes). Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 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. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland) /* -*- c -*- * remote_protocol.x: private protocol for communicating between * remote_internal driver and libvirtd. This protocol is * internal and may change at any time. * * Copyright (C) 2006-2007 Red Hat, Inc. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA * * Author: Richard Jones <rjones(a)redhat.com&gt; */ /* Notes: * * (1) The protocol is internal and may change at any time, without * notice. Do not use it. Instead link to libvirt and use the remote * driver. * * (2) See bottom of this file for a description of the home-brew RPC. * * (3) Authentication/encryption is done outside this protocol. * * (4) For namespace reasons, all exported names begin 'remote_' or * 'REMOTE_'. This makes names quite long. */ %#include "libvirt/libvirt.h" /*----- Data types. -----*/ /* Maximum total message size (serialised). */ const REMOTE_MESSAGE_MAX = 262144; /* Length of long, but not unbounded, strings. * This is an arbitrary limit designed to stop the decoder from trying * to allocate unbounded amounts of memory when fed with a bad message. */ const REMOTE_STRING_MAX = 65536; /* A long string, which may NOT be NULL. */ typedef string remote_nonnull_string<REMOTE_STRING_MAX>; /* A long string, which may be NULL. */ typedef remote_nonnull_string *remote_string; /* This just places an upper limit on the length of lists of * domain IDs which may be sent via the protocol. */ const REMOTE_DOMAIN_ID_LIST_MAX = 16384; /* Upper limit on lists of domain names. */ const REMOTE_DOMAIN_NAME_LIST_MAX = 1024; /* Upper limit on cpumap (bytes) passed to virDomainPinVcpu. */ const REMOTE_CPUMAP_MAX = 256; /* Upper limit on number of info fields returned by virDomainGetVcpus. */ const REMOTE_VCPUINFO_MAX = 2048; /* Upper limit on cpumaps (bytes) passed to virDomainGetVcpus. */ const REMOTE_CPUMAPS_MAX = 16384; /* Upper limit on lists of network names. */ const REMOTE_NETWORK_NAME_LIST_MAX = 256; /* Domains and networks are represented on the wire by (name, UUID). */ typedef opaque remote_uuid[VIR_UUID_BUFLEN]; struct remote_name { remote_nonnull_string name; remote_uuid uuid; }; /* A domain or network which may not be NULL. */ typedef struct remote_name remote_nonnull_domain; typedef struct remote_name remote_nonnull_network; /* A domain or network which may be NULL. */ typedef remote_nonnull_domain *remote_domain; typedef remote_nonnull_network *remote_network; /* Error message. See <virterror.h> for explanation of fields. */ /* NB. Fields "code", "domain" and "level" are really enums. The * numeric value should remain compatible between libvirt and * libvirtd. This means, no changing or reordering the enums as * defined in <virterror.h> (but we don't do that anyway, for separate * ABI reasons). */ struct remote_error { int code; int domain; remote_string message; int level; remote_domain dom; remote_string str1; remote_string str2; remote_string str3; int int1; int int2; remote_network net; }; /* Wire encoding of virVcpuInfo. */ struct remote_vcpu_info { unsigned int number; int state; unsigned hyper cpu_time; int cpu; }; /*----- Calls. -----*/ /* For each call we may have a 'remote_CALL_args' and 'remote_CALL_ret' * type. These are omitted when they are void. The virConnectPtr * is not passed at all (it is inferred on the remote server from the * connection). Errors are returned implicitly in the RPC protocol. * * Please follow the naming convention carefully - this file is * parsed by 'remote_generate_stubs.pl'. */ struct remote_open_args { /* NB. "name" might be NULL although in practice you can't * yet do that using the remote_internal driver. */ remote_string name; int flags; }; struct remote_get_type_ret { remote_nonnull_string type; }; struct remote_get_version_ret { hyper hv_ver; }; struct remote_get_max_vcpus_args { /* The only backend which supports this call is Xen HV, and * there the type is ignored so it could be NULL. */ remote_string type; }; struct remote_get_max_vcpus_ret { int max_vcpus; }; struct remote_node_get_info_ret { char model[32]; hyper memory; int cpus; int mhz; int nodes; int sockets; int cores; int threads; }; struct remote_get_capabilities_ret { remote_nonnull_string capabilities; }; struct remote_list_domains_args { int maxids; }; struct remote_list_domains_ret { int ids<REMOTE_DOMAIN_ID_LIST_MAX>; }; struct remote_num_of_domains_ret { int num; }; struct remote_domain_create_linux_args { remote_nonnull_string xml_desc; int flags; }; struct remote_domain_create_linux_ret { remote_nonnull_domain dom; }; struct remote_domain_lookup_by_id_args { int id; }; struct remote_domain_lookup_by_id_ret { /* XXX "Not found" semantic is ill-defined. */ remote_nonnull_domain dom; }; struct remote_domain_lookup_by_uuid_args { remote_uuid uuid; }; struct remote_domain_lookup_by_uuid_ret { /* XXX "Not found" semantic is ill-defined. */ remote_nonnull_domain dom; }; struct remote_domain_lookup_by_name_args { remote_nonnull_string name; }; struct remote_domain_lookup_by_name_ret { /* XXX "Not found" semantic is ill-defined. */ remote_nonnull_domain dom; }; struct remote_domain_suspend_args { remote_nonnull_domain dom; }; struct remote_domain_resume_args { remote_nonnull_domain dom; }; struct remote_domain_shutdown_args { remote_nonnull_domain dom; }; struct remote_domain_reboot_args { remote_nonnull_domain dom; int flags; }; struct remote_domain_destroy_args { remote_nonnull_domain dom; }; struct remote_domain_get_os_type_args { remote_nonnull_domain dom; }; struct remote_domain_get_os_type_ret { remote_nonnull_string type; }; struct remote_domain_get_max_memory_args { remote_nonnull_domain dom; }; struct remote_domain_get_max_memory_ret { unsigned hyper memory; }; struct remote_domain_set_max_memory_args { remote_nonnull_domain dom; unsigned hyper memory; }; struct remote_domain_set_memory_args { remote_nonnull_domain dom; unsigned hyper memory; }; struct remote_domain_get_info_args { remote_nonnull_domain dom; }; struct remote_domain_get_info_ret { unsigned char state; unsigned hyper max_mem; unsigned hyper memory; unsigned short nr_virt_cpu; /* XXX cpu_time is declared as unsigned long long */ unsigned hyper cpu_time; }; struct remote_domain_save_args { remote_nonnull_domain dom; remote_nonnull_string to; }; struct remote_domain_restore_args { remote_nonnull_string from; }; struct remote_domain_core_dump_args { remote_nonnull_domain dom; remote_nonnull_string to; int flags; }; struct remote_domain_dump_xml_args { remote_nonnull_domain dom; int flags; }; struct remote_domain_dump_xml_ret { remote_nonnull_string xml; }; struct remote_domain_list_defined_domains_args { int maxnames; }; struct remote_domain_list_defined_domains_ret { remote_nonnull_string names<REMOTE_DOMAIN_NAME_LIST_MAX>; }; struct remote_domain_num_of_defined_domains_ret { int num; }; struct remote_domain_create_args { remote_nonnull_domain dom; }; struct remote_domain_define_xml_args { remote_nonnull_string xml; }; struct remote_domain_define_xml_ret { remote_nonnull_domain dom; }; struct remote_domain_undefine_args { remote_nonnull_domain dom; }; struct remote_domain_set_vcpus_args { int nvcpus; }; struct remote_domain_pin_vcpu_args { int vcpu; opaque cpumap<REMOTE_CPUMAP_MAX>; }; struct remote_domain_get_vcpus_args { remote_nonnull_domain dom; int maxinfo; int maplen; }; struct remote_domain_get_vcpus_ret { remote_vcpu_info info<REMOTE_VCPUINFO_MAX>; opaque cpumaps<REMOTE_CPUMAPS_MAX>; }; struct remote_domain_get_max_vcpus_args { remote_nonnull_domain dom; }; struct remote_domain_get_max_vcpus_ret { int num; }; struct remote_domain_attach_device_args { remote_nonnull_domain dom; remote_nonnull_string xml; }; struct remote_domain_detach_device_args { remote_nonnull_domain dom; remote_nonnull_string xml; }; struct remote_domain_get_autostart_args { remote_nonnull_domain dom; }; struct remote_domain_get_autostart_ret { int autostart; }; struct remote_domain_set_autostart_args { remote_nonnull_domain dom; int autostart; }; /* Network calls: */ struct remote_num_of_networks_ret { int num; }; struct remote_list_networks_args { int maxnames; }; struct remote_list_networks_ret { remote_nonnull_string names<REMOTE_NETWORK_NAME_LIST_MAX>; }; struct remote_num_of_defined_networks_ret { int num; }; struct remote_list_defined_networks_args { int maxnames; }; struct remote_list_defined_networks_ret { remote_nonnull_string names<REMOTE_NETWORK_NAME_LIST_MAX>; }; struct remote_network_lookup_by_uuid_args { remote_uuid uuid; }; struct remote_network_lookup_by_uuid_ret { /* XXX "Not found" semantic is ill-defined. */ remote_nonnull_network net; }; struct remote_network_lookup_by_name_args { remote_nonnull_string name; }; struct remote_network_lookup_by_name_ret { /* XXX "Not found" semantic is ill-defined. */ remote_nonnull_network net; }; struct remote_network_create_xml_args { remote_nonnull_string xml; }; struct remote_network_create_xml_ret { remote_nonnull_network net; }; struct remote_network_define_xml_args { remote_nonnull_string xml; }; struct remote_network_define_xml_ret { remote_nonnull_network net; }; struct remote_network_undefine_args { remote_nonnull_network net; }; struct remote_network_create_args { remote_nonnull_network net; }; struct remote_network_destroy_args { remote_nonnull_network net; }; struct remote_network_dump_xml_args { remote_nonnull_network net; int flags; }; struct remote_network_dump_xml_ret { remote_nonnull_string xml; }; struct remote_network_get_bridge_name_args { remote_nonnull_network net; }; struct remote_network_get_bridge_name_ret { remote_nonnull_string name; }; struct remote_network_get_autostart_args { remote_nonnull_network net; }; struct remote_network_get_autostart_ret { int autostart; }; struct remote_network_set_autostart_args { remote_nonnull_network net; int autostart; }; /*----- Protocol. -----*/ /* Define the program number, protocol version and procedure numbers here. */ const REMOTE_PROGRAM = 0x20008086; const REMOTE_PROTOCOL_VERSION = 1; enum remote_procedure { REMOTE_PROC_OPEN = 1, REMOTE_PROC_CLOSE = 2, REMOTE_PROC_GET_TYPE = 3, REMOTE_PROC_GET_VERSION = 4, REMOTE_PROC_GET_MAX_VCPUS = 5, REMOTE_PROC_NODE_GET_INFO = 6, REMOTE_PROC_GET_CAPABILITIES = 7, REMOTE_PROC_DOMAIN_ATTACH_DEVICE = 8, REMOTE_PROC_DOMAIN_CREATE = 9, REMOTE_PROC_DOMAIN_CREATE_LINUX = 10, REMOTE_PROC_DOMAIN_DEFINE_XML = 11, REMOTE_PROC_DOMAIN_DESTROY = 12, REMOTE_PROC_DOMAIN_DETACH_DEVICE = 13, REMOTE_PROC_DOMAIN_DUMP_XML = 14, REMOTE_PROC_DOMAIN_GET_AUTOSTART = 15, REMOTE_PROC_DOMAIN_GET_INFO = 16, REMOTE_PROC_DOMAIN_GET_MAX_MEMORY = 17, REMOTE_PROC_DOMAIN_GET_MAX_VCPUS = 18, REMOTE_PROC_DOMAIN_GET_OS_TYPE = 19, REMOTE_PROC_DOMAIN_GET_VCPUS = 20, REMOTE_PROC_DOMAIN_LIST_DEFINED_DOMAINS = 21, REMOTE_PROC_DOMAIN_LOOKUP_BY_ID = 22, REMOTE_PROC_DOMAIN_LOOKUP_BY_NAME = 23, REMOTE_PROC_DOMAIN_LOOKUP_BY_UUID = 24, REMOTE_PROC_DOMAIN_NUM_OF_DEFINED_DOMAINS = 25, REMOTE_PROC_DOMAIN_PIN_VCPU = 26, REMOTE_PROC_DOMAIN_REBOOT = 27, REMOTE_PROC_DOMAIN_RESUME = 28, REMOTE_PROC_DOMAIN_SET_AUTOSTART = 29, REMOTE_PROC_DOMAIN_SET_MAX_MEMORY = 30, REMOTE_PROC_DOMAIN_SET_MEMORY = 31, REMOTE_PROC_DOMAIN_SET_VCPUS = 32, REMOTE_PROC_DOMAIN_SHUTDOWN = 33, REMOTE_PROC_DOMAIN_SUSPEND = 34, REMOTE_PROC_DOMAIN_UNDEFINE = 35, REMOTE_PROC_LIST_DEFINED_NETWORKS = 36, REMOTE_PROC_LIST_DOMAINS = 37, REMOTE_PROC_LIST_NETWORKS = 38, REMOTE_PROC_NETWORK_CREATE = 39, REMOTE_PROC_NETWORK_CREATE_XML = 40, REMOTE_PROC_NETWORK_DEFINE_XML = 41, REMOTE_PROC_NETWORK_DESTROY = 42, REMOTE_PROC_NETWORK_DUMP_XML = 43, REMOTE_PROC_NETWORK_GET_AUTOSTART = 44, REMOTE_PROC_NETWORK_GET_BRIDGE_NAME = 45, REMOTE_PROC_NETWORK_LOOKUP_BY_NAME = 46, REMOTE_PROC_NETWORK_LOOKUP_BY_UUID = 47, REMOTE_PROC_NETWORK_SET_AUTOSTART = 48, REMOTE_PROC_NETWORK_UNDEFINE = 49, REMOTE_PROC_NUM_OF_DEFINED_NETWORKS = 50, REMOTE_PROC_NUM_OF_DOMAINS = 51, REMOTE_PROC_NUM_OF_NETWORKS = 52, REMOTE_PROC_DOMAIN_CORE_DUMP = 53, REMOTE_PROC_DOMAIN_RESTORE = 54, REMOTE_PROC_DOMAIN_SAVE = 55 }; /* Custom RPC structure. */ /* Each message consists of: * int length Number of bytes in message _including_ length. * remote_message_header Header. * then either: args Arguments (for REMOTE_CALL). * or: ret Return (for REMOTE_REPLY, status = REMOTE_OK) * or: remote_error Error (for REMOTE_REPLY, status = REMOTE_ERROR) * * The first two words (length, program number) are meant to be compatible * with the qemud protocol (qemud/protocol.x), although the rest of the * messages are completely different. */ enum remote_message_direction { REMOTE_CALL = 0, /* client -> server */ REMOTE_REPLY = 1, /* server -> client */ REMOTE_MESSAGE = 2 /* server -> client, asynchronous [NYI] */ }; enum remote_message_status { /* Status is always REMOTE_OK for calls. * For replies, indicates no error. */ REMOTE_OK = 0, /* For replies, indicates that an error happened, and a struct * remote_error follows. */ REMOTE_ERROR = 1 }; struct remote_message_header { unsigned prog; /* REMOTE_PROGRAM */ unsigned vers; /* REMOTE_PROTOCOL_VERSION */ remote_procedure proc; /* REMOTE_PROC_x */ remote_message_direction direction; unsigned serial; /* Serial number of message. */ remote_message_status status; }; /* * vim: set tabstop=4: * vim: set shiftwidth=4: * vim: set expandtab: */ /* * Local variables: * indent-tabs-mode: nil * c-indent-level: 4 * c-basic-offset: 4 * tab-width: 4 * End: */

Richard W.M. Jones wrote: Turns out that the way virDomainPtr & virNetworkPtr are handled in those files is pretty broken. I'm reworking that now - so please ignore those. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 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. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)

On Sat, May 05, 2007 at 11:53:32AM +0100, Richard W.M. Jones wrote: While I generally don't like having auto-generated files in CVS, I wonder if this makes us better off for portability to Solaris / BSD. eg, the Perl post-processor probably wouldn't work with someone else's rpcgen output. As long as the generated files are calling 100% public RPC related APIs internally we're probably best off distributing the generated files as part of the release & only manually doing re-generation when we have real changes. Historically NULL == 'Xen', so should we just force 'name = Xen' in src/libvirt.c and then no internal driver ever has to worry about NULLs in this scenario again. Good point. I'll implement this API for QEMU real soon now.... We should remember to formally define the semantics before release :-) hyper == 64-bits according to the latest XDR spec isn't it. The only guarentee we need is that cpu_time is at least 64-bits. Given the granularity we should never hit a scenario where cpu_time would overflow 64-bits. So if long long ever happens to be 128, then it shouldn't matter that hyper were only 64. So I reckon we can remove the XXX there. As above. Any significance to this number :-) Regards, 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 -=|

OK so this is step 2.5 out of 8 ... it wasn't part of the original plan. 2.5 Export virGetDomain and virGetNetwork ----------------------------------------- M src/libvirt_sym.version M src/hash.c M src/internal.h This patch exports virGetDomain and virGetNetwork functions as "internal" functions (__virGetDomain and __virGetNetwork) for use by the remote daemon. The use is as follows: client needs to invoke a function such as virDomainSuspend (virDomainPtr dom). In order to do this it has to send a reference to "dom" over the wire to the server, which it does by encoding a remote_nonnull_domain XDR object (basically the name and UUID). On the server side we use virGetDomain to pull out the corresponding virDomainPtr from the hash associated with the connection. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 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. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)

Daniel P. Berrange wrote: Committed to CVS. Rich.

On Sat, May 05, 2007 at 12:17:44PM +0100, Richard W.M. Jones wrote: What sort of info is currently stored in the $sysconfdir/libvirtd.conf file ? It seems to be referred to by both the client & server. Although there will be options common to both the client & server I think it may be worth having them refer to separate files (cf ssh_config, sshd_config). ACAICT there's no compelling need to have them refer to same file since the client & server will be on different machines anyway. The separation could be useful if there turns out to be a reasonble to make libvirtd.conf mode 0600. On the subject of We've got to think about best way to provide TLS parameters. Bearing in mind that people may want to port to Mozilla NSS in the future I think it is probably best to not provide formal APIs for these options at this time, and instead pick them up from the client's config file. As previously discussed there's no clear standard for location of TLS certs, so I reckon we just default to something like tls_ca_cert = "/etc/pks/tls/ca-cert.pem" tls_secret = "/etc/pks/tls/libvirt-key.pem" tls_cert = "/etc/pks/tls/libvirt-cert.pem" This actually does suggest we need separate libvirt.conf & libvirtd.conf because obviously the server needs to point to its own key/cert & also keep a whitelist of client keys. The client might actually need a more flexible config - allowing it to present different keys, per host. We could do something based on a placeholder, with a default fallback tls_ca_cert = "/etc/pks/tls/ca-cert.pem" tls_default_secret = "/etc/pks/tls/libvirt-key.pem" tls_default_cert = "/etc/pks/tls/libvirt-cert.pem" tls_host_cert = "/etc/pks/tls/libvirt-%h-key.pem" tls_host_cert = "/etc/pks/tls/libvirt-%h-cert.pem" Since we're using client certs for authentication to start with, we ought to actually make it possible to keep the certs in per-user home dirs rather than globally readable. eg $HOME/.pki/tls/libvirt-key.pem and mode 0600 Wrt to this snippet in negotiate_gnutls_on_connection() Do we have support in the client/server for doing whatever checks are needed for the OpenPGP style 'certs'. If not we should probably comment out the OpenGPG option for now. This all loooks good to me. Only thought I had was perhaps that GET_PRIVATE (conn, -1); is slightly more readable as struct private_data *priv = GET_PRIVATE (conn, -1); ie, to make it clear to the readable what local variable is being provided, while still hiding away all the tedious error checking / assertion logic. In the 'call' method: Serial numbers only need to be unique within the scope of a single client <-> server socket connection. So could we just store the counter in the virConectPtr private data struct to avoid the threading question here This looks consistent with the way other drivers are using __virErrorMsg at least. Anything in particular you thought was wrong ? 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 Sat, May 05, 2007 at 12:17:44PM +0100, Richard W.M. Jones wrote: I've got a question about this comment /* XXX This loop contains a subtle problem. In the case * where a host is accessible over IPv4 and IPv6, it will * try the IPv4 and IPv6 addresses in turn. However it * should be able to present different client certificates * (because the commonName field in a client cert contains * the client IP address, which is different for IPv4 and * IPv6). At the moment we only have a single client * certificate, and no way to specify what address family * that certificate belongs to. */ It is my understanding that the 'commonName' should be the public user facing name of the server. eg, if the user is accessing https://foo.example.com/ Then commonName in the certificate would be 'foo.example.com'. The commonName should be verified against the user supplied address, which in this case would also be foo.example.com. So if foo.example.com in turn resolved to both IPv4 & IPv6, eg $ host foo.example.com foo.example.com has address 60.64.20.142 foo.example.com has IPv6 address 2001:71c2:1:ee34::2 Then it really shouldn't matter whether we ended up connecting over IPv4 or IPv6, because we're still comparing foo.example.com against foo.example.com AFAICT. Now, if the certificate was configured with an IP adress in it commonName, and the user connected to 'foo.example.com' then certificate validation should fail because 60.64.20.142 != foo.example.com and neither is the IPv6 address 2001:71c2:1:ee34::2. It should only succeeed if the user ewas explicitly connecting with https://60.64.20.142/ Basically DNS lookups should not be involved in any part of the certificate validation process - user provided hostname should be validated unchanged against the certificate's embedded commonName. Regards, 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 Tue, May 08, 2007 at 12:20:17PM +0100, Richard W.M. Jones wrote: Ahh. So the question is, is there any meaningful security to be gained by having the server check the commonName field of the client's certificate against the client's incoming IP addr whether v4 or v6 ? Perhaps the only thing the server should be using the client cert's commonName field for is lookups in its whitelist of allowed clients ? Have you any idea what, say Exim or Apache, do for validation when getting a client cert ? Do they bother to check the commonName against the client's source addr, or do they merely use it for access control lookups ? 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 -=|

Hey, On Tue, 2007-05-08 at 12:28 +0100, Daniel P. Berrange wrote: When we discussed this on irc back in February, I looked this up in Postfix. So, looking back over the irc log: * Postfix will auth a client if it can validate the cert (i.e. the CA which issued the cert is trusted) and the fingerprint of the client's cert is listed in the list of allowed clients: http://www.postfix.org/postconf.5.html#relay_clientcerts * It would seem reasonable to me that you could list *either* the cert fingerprint of an allowed client or its SubjectName. In the latter case, you'd merely check that the SubjectName field in the (already validated) cert matches an entry in the list of allowed clients - i.e. you don't interpret the contents of SubjectName. I've no clue why Postfix doesn't allow this - if you trust the CA, then you can trust the SubjectName. This scheme would e.g. allow you to issue a new certificate for a given client without updatin the list of allowed clients on the server. * Also, Postfix allows you to trust all clients with certs from trusted CAs: http://www.postfix.org/postconf.5.html#permit_tls_all_clientcerts It seems like an odd configuration option to me. You'd probably only use this with a single trusted CA which you have direct control over. Cheers, Mark.

On Mon, 2007-05-14 at 09:27 +0100, Richard W.M. Jones wrote: Yes. I don't grok this ... why would you want a wildcard in the subjectName of a client certificate? Or do you mean allowing wildcards in the access control list of client subjectNames? Cheers, Mark.

On Mon, 2007-05-14 at 10:01 +0100, Richard W.M. Jones wrote: Yep. I don't think this is useful or good practice. The IP address of the client is irrelevant, ignore it. Think about clients connecting from behind NAT, for example. And this has nothing to do with TLS or X.509 certificates. It's no different from e.g. libwrap. Again, I don't think this is useful. This looks essentially like a list of strings which will be compared against the SubjectName field in certificates presented by clients. It looks like it requires that the contents of the SubjectName is an X.500 DN, which is probably sane, and allows matching against individual fields in the DN which is similar to wildcards. I think this is just another confirmation of what I was saying would be a sane way to do this: 1) Validate the cert was issued by a trusted CA, deny if no 2) Ignore the IP address of client 3) First check whether the cert fingerprint is on the list of allowed client fingerprints, allow if yes 4) Otherwise check whether the contents of the SubjectName name field is on the list of allowed client SubjectNames, allow if yes, deny if no Postfix does (3), but not (4). Apache does (4), in a fairly fancy way, but not (3). Cheers, Mark.

Hi Rich, On Mon, 2007-05-14 at 14:04 +0100, Richard W.M. Jones wrote: Ah, that explains it. Just to be pedantic: + Subject Name : the field in X.509 certs which details the identity of the holder of the associated private key + Distinguished Name : the X.500 format for describing identity which should be used in the Subject Name field + Common Name : one of the possible fields in a Distinguished Name Nope, we don't. A list of allowed subject names would be fine for us. I do like the option of a list of fingerprints too, but it's not that important if we have the subject name list. And we could also have the "allow all clients with valid certs" option. Cheers, Mark.

On Sat, May 05, 2007 at 12:17:44PM +0100, Richard W.M. Jones wrote: A small bug in there - If the TLS session fails to init, then we die with SEGV when calling gnutls_bye() on a NULL priv.session - In the remoteOpen() method the goto is in the wrong place if (priv.uses_tls) { priv.session = negotiate_gnutls_on_connection (conn, priv.sock, no_verify, server); if (!priv.session) { close (priv.sock); priv.sock = -1; continue; } goto tcp_connected; } Noeeds to be if (priv.uses_tls) { priv.session = negotiate_gnutls_on_connection (conn, priv.sock, no_verify, server); if (!priv.session) { close (priv.sock); priv.sock = -1; continue; } } goto tcp_connected; Otherwise tcp connections will never succceed. 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 Sat, May 05, 2007 at 12:30:13PM +0100, Richard W.M. Jones wrote: Good idea. Not really many comments for these files. Could those two variables instead be void * - to avoid the need to cast all assignments to them ? Finally, with Is it possible to tweak the macro definition so its use appears as CHECK_CONN(client); So its clear what variable this macro is doing work against. Regards, 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 -=|

Richard W.M. Jones wrote: Attached is the updated remote.c. The only difference is that CHECK_CONN now takes an extra client connection as requested above. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 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. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)

Again, this is Dan's patch to make QEMUD use the XDR protocol: http://www.redhat.com/archives/libvir-list/2007-March/msg00333.html The modifications I have made: (1) Use REMOTE_MESSAGE_MAX from remote_protocol.x (2) Make the protocol superficially similar to the remote protocol so that we can dispatch on it, although in the current implementation this is actually not used. Instead we make our dispatch decision based on whether the daemon was started with --remote on the command line. (3) Allow the daemon to listen on TCP sockets. (4) Allow the daemon to require GnuTLS encryption negotiation on sockets. In addition, the daemon can now check the client's IP address and certificate against a whitelist. (5) Add support for a configuration file (/etc/libvirt/libvirtd.conf by default, but can be overridden on the command line), which allows the sockets and certificate stuff to be configured. To do: Find a good default place in the filesystem to find the CA and client certificates. Change the start-up script so that it can start a QEMU/network daemon and a remote daemon. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 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. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland) /* -*- c -*- * protocol_xdr.x: wire protocol message format & data structures * * Copyright (C) 2006, 2007 Red Hat, Inc. * Copyright (C) 2006 Daniel P. Berrange * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA * * Author: Daniel P. Berrange <berrange(a)redhat.com&gt; */ const QEMUD_UUID_RAW_LEN = 16; const QEMUD_MAX_NAME_LEN = 50; const QEMUD_MAX_XML_LEN = 4096; /*#define QEMUD_MAX_IFNAME_LEN IF_NAMESIZE */ const QEMUD_MAX_IFNAME_LEN = 50; const QEMUD_MAX_NUM_DOMAINS = 100; const QEMUD_MAX_NUM_NETWORKS = 100; /* * Damn, we can't do multiplcation when declaring * constants with XDR ! * These two should be QEMUD_MAX_NUM_DOMAIN * QEMUD_MAX_NAME_LEN */ const QEMUD_MAX_DOMAINS_NAME_BUF = 5000; const QEMUD_MAX_NETWORKS_NAME_BUF = 5000; const QEMUD_MAX_ERROR_LEN = 1024; /* Possible guest VM states */ enum qemud_domain_runstate { QEMUD_STATE_RUNNING = 1, QEMUD_STATE_PAUSED, QEMUD_STATE_STOPPED }; /* Message sent by a client */ enum qemud_packet_client_data_type { QEMUD_CLIENT_PKT_GET_VERSION, QEMUD_CLIENT_PKT_GET_NODEINFO, QEMUD_CLIENT_PKT_LIST_DOMAINS, QEMUD_CLIENT_PKT_NUM_DOMAINS, QEMUD_CLIENT_PKT_DOMAIN_CREATE, QEMUD_CLIENT_PKT_DOMAIN_LOOKUP_BY_ID, QEMUD_CLIENT_PKT_DOMAIN_LOOKUP_BY_UUID, QEMUD_CLIENT_PKT_DOMAIN_LOOKUP_BY_NAME, QEMUD_CLIENT_PKT_DOMAIN_SUSPEND, QEMUD_CLIENT_PKT_DOMAIN_RESUME, QEMUD_CLIENT_PKT_DOMAIN_DESTROY, QEMUD_CLIENT_PKT_DOMAIN_GET_INFO, QEMUD_CLIENT_PKT_DOMAIN_SAVE, QEMUD_CLIENT_PKT_DOMAIN_RESTORE, QEMUD_CLIENT_PKT_DUMP_XML, QEMUD_CLIENT_PKT_LIST_DEFINED_DOMAINS, QEMUD_CLIENT_PKT_NUM_DEFINED_DOMAINS, QEMUD_CLIENT_PKT_DOMAIN_START, QEMUD_CLIENT_PKT_DOMAIN_DEFINE, QEMUD_CLIENT_PKT_DOMAIN_UNDEFINE, QEMUD_CLIENT_PKT_NUM_NETWORKS, QEMUD_CLIENT_PKT_LIST_NETWORKS, QEMUD_CLIENT_PKT_NUM_DEFINED_NETWORKS, QEMUD_CLIENT_PKT_LIST_DEFINED_NETWORKS, QEMUD_CLIENT_PKT_NETWORK_LOOKUP_BY_UUID, QEMUD_CLIENT_PKT_NETWORK_LOOKUP_BY_NAME, QEMUD_CLIENT_PKT_NETWORK_CREATE, QEMUD_CLIENT_PKT_NETWORK_DEFINE, QEMUD_CLIENT_PKT_NETWORK_UNDEFINE, QEMUD_CLIENT_PKT_NETWORK_START, QEMUD_CLIENT_PKT_NETWORK_DESTROY, QEMUD_CLIENT_PKT_NETWORK_DUMP_XML, QEMUD_CLIENT_PKT_NETWORK_GET_BRIDGE_NAME, QEMUD_CLIENT_PKT_DOMAIN_GET_AUTOSTART, QEMUD_CLIENT_PKT_DOMAIN_SET_AUTOSTART, QEMUD_CLIENT_PKT_NETWORK_GET_AUTOSTART, QEMUD_CLIENT_PKT_NETWORK_SET_AUTOSTART, QEMUD_CLIENT_PKT_GET_CAPABILITIES, QEMUD_CLIENT_PKT_MAX }; /* Messages sent by a server */ enum qemud_packet_server_data_type { QEMUD_SERVER_PKT_FAILURE = 0, QEMUD_SERVER_PKT_GET_VERSION, QEMUD_SERVER_PKT_GET_NODEINFO, QEMUD_SERVER_PKT_LIST_DOMAINS, QEMUD_SERVER_PKT_NUM_DOMAINS, QEMUD_SERVER_PKT_DOMAIN_CREATE, QEMUD_SERVER_PKT_DOMAIN_LOOKUP_BY_ID, QEMUD_SERVER_PKT_DOMAIN_LOOKUP_BY_UUID, QEMUD_SERVER_PKT_DOMAIN_LOOKUP_BY_NAME, QEMUD_SERVER_PKT_DOMAIN_SUSPEND, QEMUD_SERVER_PKT_DOMAIN_RESUME, QEMUD_SERVER_PKT_DOMAIN_DESTROY, QEMUD_SERVER_PKT_DOMAIN_GET_INFO, QEMUD_SERVER_PKT_DOMAIN_SAVE, QEMUD_SERVER_PKT_DOMAIN_RESTORE, QEMUD_SERVER_PKT_DUMP_XML, QEMUD_SERVER_PKT_LIST_DEFINED_DOMAINS, QEMUD_SERVER_PKT_NUM_DEFINED_DOMAINS, QEMUD_SERVER_PKT_DOMAIN_START, QEMUD_SERVER_PKT_DOMAIN_DEFINE, QEMUD_SERVER_PKT_DOMAIN_UNDEFINE, QEMUD_SERVER_PKT_NUM_NETWORKS, QEMUD_SERVER_PKT_LIST_NETWORKS, QEMUD_SERVER_PKT_NUM_DEFINED_NETWORKS, QEMUD_SERVER_PKT_LIST_DEFINED_NETWORKS, QEMUD_SERVER_PKT_NETWORK_LOOKUP_BY_UUID, QEMUD_SERVER_PKT_NETWORK_LOOKUP_BY_NAME, QEMUD_SERVER_PKT_NETWORK_CREATE, QEMUD_SERVER_PKT_NETWORK_DEFINE, QEMUD_SERVER_PKT_NETWORK_UNDEFINE, QEMUD_SERVER_PKT_NETWORK_START, QEMUD_SERVER_PKT_NETWORK_DESTROY, QEMUD_SERVER_PKT_NETWORK_DUMP_XML, QEMUD_SERVER_PKT_NETWORK_GET_BRIDGE_NAME, QEMUD_SERVER_PKT_DOMAIN_GET_AUTOSTART, QEMUD_SERVER_PKT_DOMAIN_SET_AUTOSTART, QEMUD_SERVER_PKT_NETWORK_GET_AUTOSTART, QEMUD_SERVER_PKT_NETWORK_SET_AUTOSTART, QEMUD_SERVER_PKT_GET_CAPABILITIES, QEMUD_SERVER_PKT_MAX }; struct qemud_packet_failure_reply { uint32_t code; char message[QEMUD_MAX_ERROR_LEN]; }; struct qemud_packet_get_version_reply { uint32_t versionNum; }; struct qemud_packet_get_node_info_reply { char model[32]; uint32_t memory; uint32_t cpus; uint32_t mhz; uint32_t nodes; uint32_t sockets; uint32_t cores; uint32_t threads; }; struct qemud_packet_get_capabilities_reply { char xml[QEMUD_MAX_XML_LEN]; }; struct qemud_packet_list_domains_reply { int32_t numDomains; int32_t domains[QEMUD_MAX_NUM_DOMAINS]; }; struct qemud_packet_num_domains_reply{ int32_t numDomains; }; struct qemud_packet_domain_create_request { char xml[QEMUD_MAX_XML_LEN]; }; struct qemud_packet_domain_create_reply { int32_t id; unsigned char uuid[QEMUD_UUID_RAW_LEN]; char name[QEMUD_MAX_NAME_LEN]; }; struct qemud_packet_domain_lookup_by_id_request { int32_t id; }; struct qemud_packet_domain_lookup_by_id_reply { unsigned char uuid[QEMUD_UUID_RAW_LEN]; char name[QEMUD_MAX_NAME_LEN]; }; struct qemud_packet_domain_lookup_by_name_request { char name[QEMUD_MAX_NAME_LEN]; }; struct qemud_packet_domain_lookup_by_name_reply { int32_t id; unsigned char uuid[QEMUD_UUID_RAW_LEN]; }; struct qemud_packet_domain_lookup_by_uuid_request { unsigned char uuid[QEMUD_UUID_RAW_LEN]; }; struct qemud_packet_domain_lookup_by_uuid_reply { int32_t id; char name[QEMUD_MAX_NAME_LEN]; }; struct qemud_packet_domain_suspend_request { int32_t id; }; struct qemud_packet_domain_resume_request { int32_t id; }; struct qemud_packet_domain_destroy_request { int32_t id; }; struct qemud_packet_domain_get_info_request { unsigned char uuid[QEMUD_UUID_RAW_LEN]; }; struct qemud_packet_domain_get_info_reply { uint64_t cpuTime; uint32_t runstate; uint32_t memory; uint32_t maxmem; uint32_t nrVirtCpu; }; struct qemud_packet_domain_save_request { int32_t id; char file[PATH_MAX]; }; struct qemud_packet_domain_restore_request { char file[PATH_MAX]; }; struct qemud_packet_domain_restore_reply { int32_t id; }; struct qemud_packet_domain_dump_xml_request { unsigned char uuid[QEMUD_UUID_RAW_LEN]; }; struct qemud_packet_domain_dump_xml_reply { char xml[QEMUD_MAX_XML_LEN]; }; struct qemud_packet_list_defined_domains_reply{ uint32_t numDomains; char domains[QEMUD_MAX_DOMAINS_NAME_BUF]; }; struct qemud_packet_num_defined_domains_reply{ uint32_t numDomains; }; struct qemud_packet_domain_start_request { unsigned char uuid[QEMUD_UUID_RAW_LEN]; }; struct qemud_packet_domain_start_reply { int32_t id; }; struct qemud_packet_domain_define_request { char xml[QEMUD_MAX_XML_LEN]; }; struct qemud_packet_domain_define_reply { unsigned char uuid[QEMUD_UUID_RAW_LEN]; char name[QEMUD_MAX_NAME_LEN]; }; struct qemud_packet_domain_undefine_request { unsigned char uuid[QEMUD_UUID_RAW_LEN]; }; struct qemud_packet_num_networks_reply { uint32_t numNetworks; }; struct qemud_packet_list_networks_reply { uint32_t numNetworks; char networks[QEMUD_MAX_NETWORKS_NAME_BUF]; }; struct qemud_packet_num_defined_networks_reply { uint32_t numNetworks; }; struct qemud_packet_list_defined_networks_reply { uint32_t numNetworks; char networks[QEMUD_MAX_NETWORKS_NAME_BUF]; }; struct qemud_packet_network_lookup_by_name_request { char name[QEMUD_MAX_NAME_LEN]; }; struct qemud_packet_network_lookup_by_name_reply { int32_t id; unsigned char uuid[QEMUD_UUID_RAW_LEN]; }; struct qemud_packet_network_lookup_by_uuid_request { unsigned char uuid[QEMUD_UUID_RAW_LEN]; }; struct qemud_packet_network_lookup_by_uuid_reply { int32_t id; char name[QEMUD_MAX_NAME_LEN]; }; struct qemud_packet_network_create_request { char xml[QEMUD_MAX_XML_LEN]; }; struct qemud_packet_network_create_reply { unsigned char uuid[QEMUD_UUID_RAW_LEN]; char name[QEMUD_MAX_NAME_LEN]; }; struct qemud_packet_network_define_request { char xml[QEMUD_MAX_XML_LEN]; }; struct qemud_packet_network_define_reply { unsigned char uuid[QEMUD_UUID_RAW_LEN]; char name[QEMUD_MAX_NAME_LEN]; }; struct qemud_packet_network_undefine_request { unsigned char uuid[QEMUD_UUID_RAW_LEN]; }; struct qemud_packet_network_start_request { unsigned char uuid[QEMUD_UUID_RAW_LEN]; }; struct qemud_packet_network_destroy_request { unsigned char uuid[QEMUD_UUID_RAW_LEN]; }; struct qemud_packet_network_dump_xml_request { unsigned char uuid[QEMUD_UUID_RAW_LEN]; }; struct qemud_packet_network_dump_xml_reply { char xml[QEMUD_MAX_XML_LEN]; }; struct qemud_packet_network_get_bridge_name_request { unsigned char uuid[QEMUD_UUID_RAW_LEN]; }; struct qemud_packet_network_get_bridge_name_reply { char ifname[QEMUD_MAX_IFNAME_LEN]; }; struct qemud_packet_domain_get_autostart_request{ unsigned char uuid[QEMUD_UUID_RAW_LEN]; }; struct qemud_packet_domain_get_autostart_reply { uint32_t autostart; }; struct qemud_packet_domain_set_autostart_request { unsigned char uuid[QEMUD_UUID_RAW_LEN]; uint32_t autostart; }; struct qemud_packet_network_get_autostart_request { unsigned char uuid[QEMUD_UUID_RAW_LEN]; }; struct qemud_packet_network_get_autostart_reply { uint32_t autostart; }; struct qemud_packet_network_set_autostart_request { unsigned char uuid[QEMUD_UUID_RAW_LEN]; uint32_t autostart; }; union qemud_packet_client_data switch (qemud_packet_client_data_type type) { case QEMUD_CLIENT_PKT_GET_VERSION: void; case QEMUD_CLIENT_PKT_GET_NODEINFO: void; case QEMUD_CLIENT_PKT_LIST_DOMAINS: void; case QEMUD_CLIENT_PKT_NUM_DOMAINS: void; case QEMUD_CLIENT_PKT_DOMAIN_CREATE: qemud_packet_domain_create_request domainCreateRequest; case QEMUD_CLIENT_PKT_DOMAIN_LOOKUP_BY_ID: qemud_packet_domain_lookup_by_id_request domainLookupByIDRequest; case QEMUD_CLIENT_PKT_DOMAIN_LOOKUP_BY_UUID: qemud_packet_domain_lookup_by_uuid_request domainLookupByUUIDRequest; case QEMUD_CLIENT_PKT_DOMAIN_LOOKUP_BY_NAME: qemud_packet_domain_lookup_by_name_request domainLookupByNameRequest; case QEMUD_CLIENT_PKT_DOMAIN_SUSPEND: qemud_packet_domain_suspend_request domainSuspendRequest; case QEMUD_CLIENT_PKT_DOMAIN_RESUME: qemud_packet_domain_resume_request domainResumeRequest; case QEMUD_CLIENT_PKT_DOMAIN_DESTROY: qemud_packet_domain_destroy_request domainDestroyRequest; case QEMUD_CLIENT_PKT_DOMAIN_GET_INFO: qemud_packet_domain_get_info_request domainGetInfoRequest; case QEMUD_CLIENT_PKT_DOMAIN_SAVE: qemud_packet_domain_save_request domainSaveRequest; case QEMUD_CLIENT_PKT_DOMAIN_RESTORE: qemud_packet_domain_restore_request domainRestoreRequest; case QEMUD_CLIENT_PKT_DUMP_XML: qemud_packet_domain_dump_xml_request domainDumpXMLRequest; case QEMUD_CLIENT_PKT_LIST_DEFINED_DOMAINS: void; case QEMUD_CLIENT_PKT_NUM_DEFINED_DOMAINS: void; case QEMUD_CLIENT_PKT_DOMAIN_START: qemud_packet_domain_start_request domainStartRequest; case QEMUD_CLIENT_PKT_DOMAIN_DEFINE: qemud_packet_domain_define_request domainDefineRequest; case QEMUD_CLIENT_PKT_DOMAIN_UNDEFINE: qemud_packet_domain_undefine_request domainUndefineRequest; case QEMUD_CLIENT_PKT_NUM_NETWORKS: void; case QEMUD_CLIENT_PKT_LIST_NETWORKS: void; case QEMUD_CLIENT_PKT_NUM_DEFINED_NETWORKS: void; case QEMUD_CLIENT_PKT_LIST_DEFINED_NETWORKS: void; case QEMUD_CLIENT_PKT_NETWORK_LOOKUP_BY_UUID: qemud_packet_network_lookup_by_uuid_request networkLookupByUUIDRequest; case QEMUD_CLIENT_PKT_NETWORK_LOOKUP_BY_NAME: qemud_packet_network_lookup_by_name_request networkLookupByNameRequest; case QEMUD_CLIENT_PKT_NETWORK_CREATE: qemud_packet_network_create_request networkCreateRequest; case QEMUD_CLIENT_PKT_NETWORK_DEFINE: qemud_packet_network_define_request networkDefineRequest; case QEMUD_CLIENT_PKT_NETWORK_UNDEFINE: qemud_packet_network_undefine_request networkUndefineRequest; case QEMUD_CLIENT_PKT_NETWORK_START: qemud_packet_network_start_request networkStartRequest; case QEMUD_CLIENT_PKT_NETWORK_DESTROY: qemud_packet_network_destroy_request networkDestroyRequest; case QEMUD_CLIENT_PKT_NETWORK_DUMP_XML: qemud_packet_network_dump_xml_request networkDumpXMLRequest; case QEMUD_CLIENT_PKT_NETWORK_GET_BRIDGE_NAME: qemud_packet_network_get_bridge_name_request networkGetBridgeNameRequest; case QEMUD_CLIENT_PKT_DOMAIN_GET_AUTOSTART: qemud_packet_domain_get_autostart_request domainGetAutostartRequest; case QEMUD_CLIENT_PKT_DOMAIN_SET_AUTOSTART: qemud_packet_domain_set_autostart_request domainSetAutostartRequest; case QEMUD_CLIENT_PKT_NETWORK_GET_AUTOSTART: qemud_packet_network_get_autostart_request networkGetAutostartRequest; case QEMUD_CLIENT_PKT_NETWORK_SET_AUTOSTART: qemud_packet_network_set_autostart_request networkSetAutostartRequest; case QEMUD_CLIENT_PKT_GET_CAPABILITIES: void; }; union qemud_packet_server_data switch (qemud_packet_server_data_type type) { case QEMUD_SERVER_PKT_FAILURE: qemud_packet_failure_reply failureReply; case QEMUD_SERVER_PKT_GET_VERSION: qemud_packet_get_version_reply getVersionReply; case QEMUD_SERVER_PKT_GET_NODEINFO: qemud_packet_get_node_info_reply getNodeInfoReply; case QEMUD_SERVER_PKT_LIST_DOMAINS: qemud_packet_list_domains_reply listDomainsReply; case QEMUD_SERVER_PKT_NUM_DOMAINS: qemud_packet_num_domains_reply numDomainsReply; case QEMUD_SERVER_PKT_DOMAIN_CREATE: qemud_packet_domain_create_reply domainCreateReply; case QEMUD_SERVER_PKT_DOMAIN_LOOKUP_BY_ID: qemud_packet_domain_lookup_by_id_reply domainLookupByIDReply; case QEMUD_SERVER_PKT_DOMAIN_LOOKUP_BY_UUID: qemud_packet_domain_lookup_by_uuid_reply domainLookupByUUIDReply; case QEMUD_SERVER_PKT_DOMAIN_LOOKUP_BY_NAME: qemud_packet_domain_lookup_by_name_reply domainLookupByNameReply; case QEMUD_SERVER_PKT_DOMAIN_SUSPEND: void; case QEMUD_SERVER_PKT_DOMAIN_RESUME: void; case QEMUD_SERVER_PKT_DOMAIN_DESTROY: void; case QEMUD_SERVER_PKT_DOMAIN_GET_INFO: qemud_packet_domain_get_info_reply domainGetInfoReply; case QEMUD_SERVER_PKT_DOMAIN_SAVE: void; case QEMUD_SERVER_PKT_DOMAIN_RESTORE: qemud_packet_domain_restore_reply domainRestoreReply; case QEMUD_SERVER_PKT_DUMP_XML: qemud_packet_domain_dump_xml_reply domainDumpXMLReply; case QEMUD_SERVER_PKT_LIST_DEFINED_DOMAINS: qemud_packet_list_defined_domains_reply listDefinedDomainsReply; case QEMUD_SERVER_PKT_NUM_DEFINED_DOMAINS: qemud_packet_num_defined_domains_reply numDefinedDomainsReply; case QEMUD_SERVER_PKT_DOMAIN_START: qemud_packet_domain_start_reply domainStartReply; case QEMUD_SERVER_PKT_DOMAIN_DEFINE: qemud_packet_domain_define_reply domainDefineReply; case QEMUD_SERVER_PKT_DOMAIN_UNDEFINE: void; case QEMUD_SERVER_PKT_NUM_NETWORKS: qemud_packet_num_networks_reply numNetworksReply; case QEMUD_SERVER_PKT_LIST_NETWORKS: qemud_packet_list_networks_reply listNetworksReply; case QEMUD_SERVER_PKT_NUM_DEFINED_NETWORKS: qemud_packet_num_defined_networks_reply numDefinedNetworksReply; case QEMUD_SERVER_PKT_LIST_DEFINED_NETWORKS: qemud_packet_list_defined_networks_reply listDefinedNetworksReply; case QEMUD_SERVER_PKT_NETWORK_LOOKUP_BY_UUID: qemud_packet_network_lookup_by_uuid_reply networkLookupByUUIDReply; case QEMUD_SERVER_PKT_NETWORK_LOOKUP_BY_NAME: qemud_packet_network_lookup_by_name_reply networkLookupByNameReply; case QEMUD_SERVER_PKT_NETWORK_CREATE: qemud_packet_network_create_reply networkCreateReply; case QEMUD_SERVER_PKT_NETWORK_DEFINE: qemud_packet_network_define_reply networkDefineReply; case QEMUD_SERVER_PKT_NETWORK_UNDEFINE: void; case QEMUD_SERVER_PKT_NETWORK_START: void; case QEMUD_SERVER_PKT_NETWORK_DESTROY: void; case QEMUD_SERVER_PKT_NETWORK_DUMP_XML: qemud_packet_network_dump_xml_reply networkDumpXMLReply; case QEMUD_SERVER_PKT_NETWORK_GET_BRIDGE_NAME: qemud_packet_network_get_bridge_name_reply networkGetBridgeNameReply; case QEMUD_SERVER_PKT_DOMAIN_GET_AUTOSTART: qemud_packet_domain_get_autostart_reply domainGetAutostartReply; case QEMUD_SERVER_PKT_DOMAIN_SET_AUTOSTART: void; case QEMUD_SERVER_PKT_NETWORK_GET_AUTOSTART: qemud_packet_network_get_autostart_reply networkGetAutostartReply; case QEMUD_SERVER_PKT_NETWORK_SET_AUTOSTART: void; case QEMUD_SERVER_PKT_GET_CAPABILITIES: qemud_packet_get_capabilities_reply getCapabilitiesReply; }; struct qemud_packet_client { uint32_t serial; struct qemud_packet_client_data data; }; struct qemud_packet_server { uint32_t serial; uint32_t inReplyTo; struct qemud_packet_server_data data; }; /* The first two words in the messages are length and program number * (previously called "magic"). This makes the protocol compatible * with the remote protocol, although beyond the first two words * the protocols are completely different. * * Note the length is the total number of bytes in the message * _including_ the length and program number. */ const QEMUD_PROGRAM = 0x20001A64; const QEMUD_PKT_HEADER_XDR_LEN = 8; struct qemud_packet_header { uint32_t length; uint32_t prog; };

These are the changes to make it build. libvirtd.conf is a suggested configuration file. I'm not really sure if we should include this. RENAMES is my collection of file renames that we might want to carry out to make the naming scheme of things like drivers in the libvirt source more consistent (particularly after xen-unified went it). Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 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. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland) # Example /etc/libvirt/libvirtd.conf file. tls_no_verify_certificate = 1 # Suggested list of file renames. # # File renames don't normally go into patches because they make # the patches much harder to read, so list them here instead. # # $Id$ # Clearer naming scheme after Xen-unified patch went in. src/xen_internal.c src/xen_internal_hv.c src/xen_internal.h src/xen_internal_hv.h src/proxy_internal.c src/xen_internal_proxy.c src/proxy_internal.h src/xen_internal_proxy.h src/xend_internal.c src/xen_internal_xend.c src/xend_internal.h src/xen_internal_xend.h src/xm_internal.c src/xen_internal_inactive.c src/xm_internal.h src/xen_internal_inactive.h src/xs_internal.c src/xen_internal_xenstore.c src/xs_internal.h src/xen_internal_xenstore.h src/xen_unified.c src/xen_internal.c src/xen_unified.h src/xen_internal.h # Test driver should really be called test_internal. src/test.c src/test_internal.c src/test.h src/test_internal.h # This would be better: src/*_internal*.c src/*_driver*.c src/*_internal*.h src/*_driver*.h # Qemud is now the qemud + remote driver. qemud/protocol.x qemud/qemud_protocol.x qemud/* remote/*

Richard W.M. Jones wrote: I've just pushed a documentation update which contains sections on how to generate and install TLS certificates and how to create a libvirtd.conf configuration file. The updated docs will appear within the next hour, here: http://libvirt.org/remote.html#Remote_certificates Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 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. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)

On Fri, May 11, 2007 at 11:25:00PM +0100, Daniel P. Berrange wrote: I've just spent /hours/ trying to work out why c = libvirt.openReadOnly(uri); for i in range(100000): d = c.listDefinedDomains() for dom in d: f = c.lookupByName(dom) Was at least x100 slower with qemu+tcp://localhost/system than with qemu:///system Neither the server, nor the client showed *any* cpu time. The box was completely idle. No sleep states anywhere in the code either. After much confusion I finally realized that we were being hit by Nagle. Since each RPC operation requires < 100 bytes to be read & written, every write was being queued up for some 10's of ms being being sent out. Pointless since the RPC ops are synchronous we'd never fill a big enough packet to cause the data to be sent before Nagle timeout. When I do int no_slow_start = 1; setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, (void *)&no_slow_start, sizeof(no_slow_start)); On both the client & server end every socket then performance using qemu+tcp://localhost/system was basically identical to qemu:///system Now if going across the LAN/WAN the delay caused by Nagle will be a smaller proportion of the RPC call time, due to extra round trip time on the real network. It is still wasteful to leave it enable though because its inserting arbitrary delays & due to the sync call-reply nature of our RPC it'll never get enough data to fill a packet. So I say disable Nagle all the time. 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: Yes, I've fixed this in the latest version so it prints out meaningful & helpful errors. I don't know why this is necessary, since the remote driver is always supposed to be called first. But anyway I added: if (!uri->scheme || strcmp(uri->scheme, "qemu") || + uri->server || /* remote driver should handle these */ !uri->path) { xmlFreeURI(uri); return VIR_DRV_OPEN_DECLINED; } 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