Re: [libvirt] [PATCH] Improve xend_get error message
On Wed, Jan 14, 2009 at 06:04:19PM -0800, john.le...@sun.com wrote: # HG changeset patch # User john.le...@sun.com # Date 1231982481 28800 # Node ID 082e0f7d5de236e69bea177c8d4c4204350144c1 # Parent 1a16d4b76232845091c1f800569ec462860cb1fb Improve xend_get error message Signed-off-by: John Levon john.le...@sun.com ACK Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Solaris least privilege support
On Wed, Jan 14, 2009 at 07:32:28PM -0800, john.le...@sun.com wrote: @@ -638,10 +657,32 @@ static int qemudInitPaths(struct qemud_s static int qemudInitPaths(struct qemud_server *server, char *sockname, char *roSockname, - int maxlen) { + int maxlen) +{ uid_t uid = geteuid(); - +#ifdef __sun +char *base = NULL; + +if (virAsprintf (base, %s/run/libvirt, LOCAL_STATE_DIR) == -1) { +VIR_ERROR0(_(Out of memory)); +return -1; +} +if (mkdir (base, 0755)) { +if (errno != EEXIST) { +VIR_ERROR0(_(unable to create rundir)); +free (base); +exit(-1); +} +} + +free (base); +#endif This chunk is potentially usefull on Linux too, so can just remove the #ifdef here. Also make sure to use VIR_FREE rather than free() Finally, the exit(-1) should be a return -1; +#ifdef __sun +if (uid == 60) { +#else if (!uid) { +#endif Rather than have this magic value in the code, lets put a #define at the top of the file #ifdef __sun #define SYSTEM_ACCOUNT 60 #else #define SYSTEM_ACCOUNT 0 #endif And then just change all use of !uid to 'uid == SYSTEM_ACCOUNT' +#ifdef __sun +{ +ucred_t *ucred = NULL; +const priv_set_t *privs; + +if (getpeerucred (fd, ucred) == -1 || +(privs = ucred_getprivset (ucred, PRIV_EFFECTIVE)) == NULL) { +if (ucred != NULL) +ucred_free (ucred); +close (fd); +return -1; +} + +if (!priv_ismember (privs, PRIV_VIRT_MANAGE)) { +ucred_free (ucred); +close (fd); +return -1; +} + +ucred_free (ucred); Can move the ucred_free up before priv_ismember() call and thus avoid the need for the call in the cleanup path. +} +#endif /* __sun */ + /* Disable Nagle. Unix sockets will ignore this. */ setsockopt (fd, IPPROTO_TCP, TCP_NODELAY, (void *)no_slow_start, sizeof no_slow_start); @@ -2140,6 +2204,10 @@ remoteReadConfigFile (struct qemud_serve if (auth_unix_rw == REMOTE_AUTH_POLKIT) unix_sock_rw_mask = 0777; #endif +#ifdef __sun +unix_sock_rw_mask = 0666; +#endif Can we move this up to the declaration point - this function should only be reacting to config file settings. FOr the global default we can just declare it #ifdef __sun static int unix_sock_rw_mask = 0666; /* Allow world */ static int unix_sock_ro_mask = 0777; /* Allow world */ #else static int unix_sock_rw_mask = 0700; /* Allow user only */ static int unix_sock_ro_mask = 0777; /* Allow world */ #endif +#ifdef __sun +static void +qemudSetupPrivs (struct qemud_server *server) +{ +chown (/var/run/libvirt, 60, 60); +chown (/var/run/libvirt/libvirt-sock, 60, 60); +chmod (/var/run/libvirt/libvirt-sock, 0666); +chown (server-logDir, 60, 60); Again prefer to see the #define SYTEM_ACCOUNT instead of the magic numbers. Is the chmod of the socket really required for solaris ? We already set the umask before creating the socket, so it ought to get desired permissions from moment it appears. We avoided an explicit chmod because that leaves a gap between socket creation, and correct ownership and permissions being configured. Also, if this libvirtd is running as UID 60, so the chown really needed ? We also setgid before creating the socket so that it gets desired group ownership at time of creation, rather than having to change it post-create. + +if (__init_daemon_priv (PU_RESETGROUPS | PU_CLEARLIMITSET, +60, 60, PRIV_XVM_CONTROL, NULL)) { +fprintf (stderr, additional privileges are required\n); +exit (1); +} + +if (priv_set (PRIV_OFF, PRIV_ALLSETS, PRIV_FILE_LINK_ANY, PRIV_PROC_INFO, +PRIV_PROC_SESSION, PRIV_PROC_EXEC, PRIV_PROC_FORK, NULL)) { +fprintf (stderr, failed to set reduced privileges\n); +exit (1); +} +} +#else +#define qemudSetupPrivs(a) +#endif /* Print command-line usage. */ static void @@ -2417,6 +2510,8 @@ int main(int argc, char **argv) { sig_action.sa_handler = SIG_IGN; sigaction(SIGPIPE, sig_action, NULL); +qemudSetupPrivs(server); + if (!(server = qemudInitialize(sigpipe[0]))) { This would appear to make it try to change the socket ownership and permissions, before we've actually created the socket, which is much later in the main() method where we call NetworkInit diff --git a/qemud/remote.c b/qemud/remote.c --- a/qemud/remote.c +++ b/qemud/remote.c @@ -424,6 +424,15 @@ remoteDispatchOpen (struct qemud_server flags = args-flags; if (client-readonly) flags |= VIR_CONNECT_RO; +#ifdef __sun +/* + * On Solaris, all clients are forced to go via virtd. As a result, + * virtd must indicate it
Re: [libvirt] [PATCH] Introduce virt-console
On Wed, Jan 14, 2009 at 07:21:10AM -0800, john.le...@sun.com wrote: +#ifdef __sun I'm really unhappy about adding #ifdef __sun everywhere in this file. Configure should detect the features that are needed / available / missing, and the #ifdefs should go on the result of that. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Compiling on Windows with MinGW/MSYS
On Thu, Jan 15, 2009 at 11:21:51AM +0100, Brecht Sanders wrote: Hi, It's been a long time since I tried to compile libvirt on Windows using the MinGW/MSYS environment. I tried it again and I have good news and bad news. The good news is thet when I disable support for most things (--without-xen --without-qemu --without-openvz --without-uml --without-test --without-libvirtd --with-remote-pid-file=none --with-init-scripts=none --with-depends --without-sasl --without-polkit) it now builds fine and even the DLL was built (libvirt-0.dll). The bad news is that when I enable Xen support, it now depends on the xenstore library. Unfortunately I wasn't able to build this library on Windows. Is this dependancy necessary? Does anyone know of xenstore on Windows? You're well outside the envelope of what we've tried or what we support. On Windows we only support client connections through the remote driver, so you have to disable everything else: http://hg.et.redhat.com/cgi-bin/hg-misc.cgi/fedora-mingw--devel/file/61e54817b85c/libvirt/mingw32-libvirt.spec#l48 I'm confused actually as to what use libvirt + Xen would be on Windows -- does Xen Enterprise now have the ability to use Windows as dom0? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Solaris least privilege support
On Thu, Jan 15, 2009 at 10:19:58AM +, Daniel P. Berrange wrote: +#ifdef __sun +{ +ucred_t *ucred = NULL; +const priv_set_t *privs; + +if (getpeerucred (fd, ucred) == -1 || +(privs = ucred_getprivset (ucred, PRIV_EFFECTIVE)) == NULL) { +if (ucred != NULL) +ucred_free (ucred); +close (fd); +return -1; +} + +if (!priv_ismember (privs, PRIV_VIRT_MANAGE)) { +ucred_free (ucred); +close (fd); +return -1; +} + +ucred_free (ucred); Can move the ucred_free up before priv_ismember() call and thus avoid the need for the call in the cleanup path. Nope, privs points into the ucred structure. Is the chmod of the socket really required for solaris ? We already I'll double check these. Also, if this libvirtd is running as UID 60, so the chown really needed ? We also setgid before creating the socket so that it gets desired group ownership at time of creation, rather than having to change it post-create. At this point in the code (I think) we're still root. This would appear to make it try to change the socket ownership and permissions, before we've actually created the socket, which is much later in the main() method where we call NetworkInit Hmm, let me re-check. +#ifdef __sun +/* + * On Solaris, all clients are forced to go via virtd. As a result, + * virtd must indicate it really does want to connect to the + * hypervisor. + */ +name = xen:///; +#endif This should not be neccessary if the client end + drivers are correctly written. Can you explain a bit more? Why don't we need to rewrite the URI as xen? If you want Xen to always go via the demon, the only change that should be required, is to make xenUnifiedOpen() return VIR_DRV_OPEN_DECLINED. Hmm, yes you might be right. Let me experiment. if (err == 0) { -error (in_open ? NULL : conn, - VIR_ERR_RPC, _(socket closed unexpectedly)); +DEBUG(conn %p: socket closed unexpectedly, conn); return -1; } } These two I/O methods here have been completely re-written in my thread patches. Why is removing the error messages required ? If we try to connect w/o privilege, then the socket is closed straight after accept() - so it's not longer an RPC error for this to happen. +/* + * If the connection over a socket failed abruptly, it's probably + * due to not having the right privileges. + */ +if (sigpipe) +vshError(ctl, TRUE, _(failed to connect (insufficient privileges?))); + It will also be seen if the daemon drops the connection due to an OOM condition, or the max-clients limit being exceeded, so perhaps a little more detailed message. Suggestions? thanks john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 25/25: Support ac97 sound card
On Wed, Jan 14, 2009 at 09:34:51AM -0500, Cole Robinson wrote: Daniel P. Berrange wrote: On Tue, Jan 13, 2009 at 05:49:02PM +, Daniel P. Berrange wrote: QEMU now has support for a sound card of type ac97, so enable that in the XML parser / qemu driver. Also remove some unused cruft relating to sound in Xen. domain_conf.c |3 ++- domain_conf.h |1 + xend_internal.c | 46 -- 3 files changed, 3 insertions(+), 47 deletions(-) Now we added 'ac97', we can no longer blindly convert Xen's 'all' string into all possible sound card types - must restrict it to just the 3 that were around historically. This fixes the Xen test case Prior to the xml parsing unification, 'pcspk' was not allowed as a valid option for xen. At least the xen version on f8 didn't offer it, so this may be incorrect. Not sure if current upstream xen supports 'pcspk' though. Yes, logs show I mistakenly added pcspk. I'll remove that from the back-compat support too. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Introduce virt-console
On Thu, Jan 15, 2009 at 11:47:13AM +, Richard W.M. Jones wrote: On Wed, Jan 14, 2009 at 07:21:10AM -0800, john.le...@sun.com wrote: +#ifdef __sun I'm really unhappy about adding #ifdef __sun everywhere in this file. Configure should detect the features that are needed / available / missing, and the #ifdefs should go on the result of that. This is Solaris stuff that doesn't and won't exist anywhere else. It would just be moving the #ifdef __sun into configure.in - I can't think what advantage you would be expecting from this, or indeed how to even test the need to do the I_PUSHes. regards john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Introduce virt-console
On Thu, Jan 15, 2009 at 12:59:36PM +, John Levon wrote: On Thu, Jan 15, 2009 at 11:47:13AM +, Richard W.M. Jones wrote: On Wed, Jan 14, 2009 at 07:21:10AM -0800, john.le...@sun.com wrote: +#ifdef __sun I'm really unhappy about adding #ifdef __sun everywhere in this file. Configure should detect the features that are needed / available / missing, and the #ifdefs should go on the result of that. This is Solaris stuff that doesn't and won't exist anywhere else. It would just be moving the #ifdef __sun into configure.in - I can't think what advantage you would be expecting from this, [...] The problem is that someone comes along needing, say, AIX support or Watcom on Windows or whatever, and before you know it you've got code like this ... http://svn.python.org/projects/python/branches/py3k/Modules/posixmodule.c We really should go by features detected in configure, not assumptions about the platform which may not even be true. or indeed how to even test the need to do the I_PUSHes. The autoconf manual is voluminous but comprehensive: http://www.gnu.org/software/autoconf/manual/autoconf.html For the I_PUSHes I think the best way is to have a tiny test program and use AC_COMPILE_IFELSE: http://www.gnu.org/software/autoconf/manual/autoconf.html#Running-the-Compiler (There's an example of how to use it in the preceeding section, 6.3, in the manual). If that doesn't help, we have Jim Meyering on this list who is the world's expert at this sort of thing. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Introduce virt-console
On Thu, Jan 15, 2009 at 01:15:13PM +, Richard W.M. Jones wrote: We really should go by features detected in configure, not assumptions about the platform which may not even be true. That's my point. They are true, and they always will be. In fact, it's MUCH safer in these cases to check __sun. I can't check for stropts.h, since someone might have installed that icky STREAMS stuff on Linux, which would then break. I can't check for priv.h, since it's generic enough to exist in different form on other platforms. Even if least priv in the exact Solaris form gets ported to say BSD, it won't have __init_suid_priv(), for example. I'm not arguing against configure checks in the general case (e.g. cfmakeraw), but these two cases (STREAMS terminals and least priv) are very different. If I thought there were any possibility of this ever applying to another platform (like, say, DTrace), I'd be all for it. or indeed how to even test the need to do the I_PUSHes. The autoconf manual is voluminous but comprehensive: I'm not asking how to write autoconf macros. I'm asking how to write a build-time test that ptys are STREAMS-based (and possibly just Solaris STREAMS), without it being essentially #ifdef __sun. Of course, my preferred fix would be for Solaris to drop STREAMS, but that's a vain hope :) regards, john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Introduce virt-console
On Wed, Jan 14, 2009 at 07:21:10AM -0800, john.le...@sun.com wrote: # HG changeset patch # User John Levon john.le...@sun.com # Date 1231946128 28800 # Node ID dd17b3062611925baa2698ff5923579d0f2cd34e # Parent a0d98d39955f4f304d318c7c780742ab929eb351 Introduce virt-console Separate console handling out into a separate binary to allow management of privileges. Signed-off-by: John Levon john.le...@sun.com diff --git a/src/Makefile.am b/src/Makefile.am --- a/src/Makefile.am +++ b/src/Makefile.am @@ -479,12 +479,16 @@ libvirt_test_la_LDFLAGS = $(test_LDFLAGS libvirt_test_la_LDFLAGS = $(test_LDFLAGS) libvirt_test_la_CFLAGS = $(COVERAGE_CFLAGS) +libexec_PROGRAMS = virt-console This can just be bin_PROGRAMS - not need to hide it outside of /usr/bin - its fine to let users just run virt-console directly if they wish #ifndef HAVE_CFMAKERAW static void -cfmakeraw (struct termios *attr) +cfmakeraw(struct termios *attr) { attr-c_iflag = ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); @@ -57,46 +91,432 @@ cfmakeraw (struct termios *attr) attr-c_lflag = ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); attr-c_cflag = ~(CSIZE | PARENB); attr-c_cflag |= CS8; + +#ifdef __sun +attr-c_cc[VMIN] = 0; +attr-c_cc[VTIME] = 0; +#endif Both those constants are available on Linux too, so seems reasonable to just remove the #ifdef here. +static void make_tty_raw(int fd, struct termios *attr) +{ +struct termios ttyattr; +struct termios rawattr; + +if (attr == NULL) +attr = ttyattr; + +if (tcgetattr(fd, attr) 0) { +fprintf(stderr, _(Unable to get tty attributes: %s\n), +strerror(errno)); +exit(EXIT_FAILURE); +} + +rawattr = *attr; +cfmakeraw(rawattr); + +if (tcsetattr(STDIN_FILENO, TCSAFLUSH, rawattr) 0) { +fprintf(stderr, _(Unable to set tty attributes: %s\n), +strerror(errno)); +exit(EXIT_FAILURE); +} +} This make_tty_raw function does not appear to be used anywhere in the patch. + +static void +usage(int exitval) +{ +FILE *f = stderr; + +if (exitval == EXIT_SUCCESS) +f = stdout; + +fprintf(f, _(usage: virt-console [options] domain\n\n + options:\n + -c | --connect urihypervisor connection URI\n + -h | --help this help\n + -v | --verbose be verbose\n\n)); + +exit(exitval); +} We need to add an explicit argument to turn on the automatic reconnect of VMs when they reboot. Existing apps calling virsh console rely on its current semantics which are to exit upon domain reboot and we can't break them I'd suggest that when tracking across reboots, we should wait forever by default, and hav an optional timeout arg if you want to make it only wait 10 seconds. -r | --reconnectreconnect when a VM reboots -t | --timeout=Nexit if VM hasn't started after N seconds Finally, if we're waiting after reboots, it seems sensible to also have the ability for wait for initial startup -w | --wait wait for VM to start if not running That lets people launch virt-console before they start the VM for the first time, so they can catch initial mesages easily. +static int +get_domain(virConnectPtr *conn, virDomainPtr *dom, +virDomainInfo *info, int lookup_by_id) +{ +int ret = 0; +int id; + +__priv_bracket(PRIV_ON); + +printf(1\n); +*conn = virConnectOpenAuth(conn_name, virConnectAuthPtrDefault, +VIR_CONNECT_RO); +printf(2\n); Debug prints :-) +if (*conn == NULL) { +fprintf(stderr, _(Failed to connect to the hypervisor)); +exit(EXIT_FAILURE); +} + +*dom = virDomainLookupByName(*conn, dom_name); + +if (*dom == NULL) +*dom = virDomainLookupByUUIDString(*conn, dom_name); +if (*dom == NULL lookup_by_id +virStrToLong_i(dom_name, NULL, 10, id) == 0 id = 0) +*dom = virDomainLookupByID(*conn, id); + +if (*dom == NULL) +goto out; + +if (info != NULL) { +if (virDomainGetInfo(*dom, info) 0) +goto out; +} + +ret = 1; + +out: +if (ret == 0) { +if (*dom != NULL) +virDomainFree(*dom); +virConnectClose(*conn); +} +__priv_bracket(PRIV_OFF); +return ret; +} + +static void +put_domain(virConnectPtr conn, virDomainPtr dom) +{ +__priv_bracket(PRIV_ON); +if (dom != NULL) +virDomainFree(dom); +virConnectClose(conn); +__priv_bracket(PRIV_OFF); +} +static char * +get_domain_tty(void) +{ +xmlXPathContextPtr ctxt = NULL; +xmlDocPtr xml = NULL; +virConnectPtr conn = NULL; +virDomainPtr dom = NULL; +char *doc = NULL; +char *tty = NULL; + +if
Re: [libvirt] [PATCH] Introduce virt-console
On Thu, Jan 15, 2009 at 01:27:00PM +, John Levon wrote: On Thu, Jan 15, 2009 at 01:15:13PM +, Richard W.M. Jones wrote: We really should go by features detected in configure, not assumptions about the platform which may not even be true. That's my point. They are true, and they always will be. In fact, it's MUCH safer in these cases to check __sun. I can't check for stropts.h, since someone might have installed that icky STREAMS stuff on Linux, which would then break. I can't check for priv.h, since it's generic enough to exist in different form on other platforms. Even if least priv in the exact Solaris form gets ported to say BSD, it won't have __init_suid_priv(), for example. I'm not arguing against configure checks in the general case (e.g. cfmakeraw), but these two cases (STREAMS terminals and least priv) are very different. I think configure.ac checks for things like the ioctl flags for TTY attr settings are reasonable, because it is conceivable that other OS may implement such flags later. For stuff like the STREAMS/privilege bits they are so completely Solaris specific its easier to just #ifdef __sun them Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Fine grained Access Control in libVirt
Hi, After some background research it doesn't look like anyone have taken on the task yet to add fine-grained access control to libVirt (only option right now is R/W or RO mode). Desired is an addition to libVirt that enables access control on individual actions and data that can be accessed through the library API. This could take the form of an AC-module that, based on the identity of the caller, checks each call and grants/denies access to carry out the action (could also take parameters in account) and optionally filter the return data. The AC-module could then interface different backend AC solutions (SELinux, RBAC, ...) or alternatively implement an internal scheme. When looking at the libvirt core and driver framework it seems promising to inject these kind of call-out hooks either in libvirt.c or between libvirt.c and the underlying drivers, by doing this AC will be enforced independent of if a local or remote call is done to libVirt. I propose an approach to create an AC-module that conforms to the driver API in libVirt and to inject it in the call-path between libvirt.c and the driver(s) to enable the AC-module to inspect the call before sending it to the real driver. Normal call path: user - libvirt.c - driver_x AC-module injected in call path: user - libvirt.c - AC-module - driver_x By doing this it can be loaded/unloaded in run-time and also selectable what driver paths it should enforce (hypervisor(aka. driver), storage, network...). The AC-module can also be made in different flavors for different AC backend (SELinux, RBAC, internal, ...) solutions and the appropriate AC-module could be loaded without needing re-compiling. This approach would also leave a very small footprint in existing libvirt code (only need to inject AC-module driver after normal drivers has been loaded) Feel free to comment and to come with improvement ideas. Freundliche GrĂ¼sse / Best regards Konrad Eriksson Trusted Computing / Security Assurance IBM Zurich Research Laboratory Saeumerstrasse 4 8803 Rueschlikon Switzerland image/gif smime.p7s Description: S/MIME Cryptographic Signature -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Introduce virt-console
On Thu, Jan 15, 2009 at 01:27:00PM +, John Levon wrote: On Thu, Jan 15, 2009 at 01:15:13PM +, Richard W.M. Jones wrote: We really should go by features detected in configure, not assumptions about the platform which may not even be true. That's my point. They are true, and they always will be. In fact, it's MUCH safer in these cases to check __sun. I can't check for stropts.h, since someone might have installed that icky STREAMS stuff on Linux, which would then break. Doesn't working STREAMS exist on UnixWare too? I still think the right thing to do is to detect STREAMS. If someone installs broken STREAMS on Linux, then it is their responsibility to find a more discrete test which differentiates between broken STREAMS and working STREAMS on Solaris/UnixWare. I can't check for priv.h, since it's generic enough to exist in different form on other platforms. Even if least priv in the exact Solaris form gets ported to say BSD, it won't have __init_suid_priv(), for example. Right, but don't just check for the header. Check for both the header and some common symbol inside it. Of course, my preferred fix would be for Solaris to drop STREAMS, but that's a vain hope :) There's the problem - if Solaris drop streams, the #ifdef __sun checks will be incorrect. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Introduce virt-console
On Thu, Jan 15, 2009 at 01:37:01PM +, Daniel P. Berrange wrote: On Thu, Jan 15, 2009 at 01:27:00PM +, John Levon wrote: On Thu, Jan 15, 2009 at 01:15:13PM +, Richard W.M. Jones wrote: We really should go by features detected in configure, not assumptions about the platform which may not even be true. That's my point. They are true, and they always will be. In fact, it's MUCH safer in these cases to check __sun. I can't check for stropts.h, since someone might have installed that icky STREAMS stuff on Linux, which would then break. I can't check for priv.h, since it's generic enough to exist in different form on other platforms. Even if least priv in the exact Solaris form gets ported to say BSD, it won't have __init_suid_priv(), for example. I'm not arguing against configure checks in the general case (e.g. cfmakeraw), but these two cases (STREAMS terminals and least priv) are very different. I think configure.ac checks for things like the ioctl flags for TTY attr settings are reasonable, because it is conceivable that other OS may implement such flags later. For stuff like the STREAMS/privilege bits they are so completely Solaris specific its easier to just #ifdef __sun them One caveat on the latter though - if there's solaris specific stuff that is only available on newer Solaris versions, then a configure.ac check would be sensible to allow it to still build on earlier versions, depending on how much back-compat support you want todo, and whether its still practical to work without the feature in question. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Introduce virt-console
On Thu, Jan 15, 2009 at 01:28:37PM +, Daniel P. Berrange wrote: +libexec_PROGRAMS = virt-console This can just be bin_PROGRAMS - not need to hide it outside of /usr/bin - its fine to let users just run virt-console directly if they wish Solaris policy is not to introduce plumbing into the user's PATH. virt-console is undocumented and there is no advantage to running it directly. If it were in PATH we would have to document it, and we have no intention of doing that... We need to add an explicit argument to turn on the automatic reconnect of VMs when they reboot. Existing apps calling virsh console rely on its current semantics which are to exit upon domain reboot and we can't break them We argued about this last time. Looks like we'll have to keep this change private, and let Linux users suffer. Oh well :) I'd suggest that when tracking across reboots, we should wait forever by default, and hav an optional timeout arg if you want to make it only wait 10 seconds. -r | --reconnectreconnect when a VM reboots -t | --timeout=Nexit if VM hasn't started after N seconds Finally, if we're waiting after reboots, it seems sensible to also have the ability for wait for initial startup -w | --wait wait for VM to start if not running That lets people launch virt-console before they start the VM for the first time, so they can catch initial mesages easily. Sure. +if (tcgetattr(ttyfd, ttyattr) 0) { +ioctl(ttyfd, I_PUSH, ptem); +ioctl(ttyfd, I_PUSH, ldterm); +tcgetattr(ttyfd, ttyattr); +} + +cfmakeraw(ttyattr); +tcsetattr(ttyfd, TCSANOW, ttyattr); +#endif The caller of open_tty() is also doing the getattr/makeraw/setattr operation, so this block appears to be redundant - just need to Nope, that's on STDIN, not the pty slave. Stupid STREAMS semantics. regards john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Fine grained Access Control in libVirt
On Thu, Jan 15, 2009 at 02:39:20PM +0100, Konrad Eriksson1 wrote: When looking at the libvirt core and driver framework it seems promising to inject these kind of call-out hooks either in libvirt.c or between libvirt.c and the underlying drivers, by doing this AC will be enforced independent of if a local or remote call is done to libVirt. In libvirt.c is probably easier ... And abstract out the read-only checks at the same time. Feel free to comment and to come with improvement ideas. All sounds good. There's a wiki page waiting to be filled in with the details here: http://wiki.libvirt.org/page/TodoFineGrainedSecurity Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Introduce virt-console
On Thu, Jan 15, 2009 at 01:45:50PM +, John Levon wrote: On Thu, Jan 15, 2009 at 01:28:37PM +, Daniel P. Berrange wrote: +libexec_PROGRAMS = virt-console This can just be bin_PROGRAMS - not need to hide it outside of /usr/bin - its fine to let users just run virt-console directly if they wish Solaris policy is not to introduce plumbing into the user's PATH. virt-console is undocumented and there is no advantage to running it directly. If it were in PATH we would have to document it, and we have no intention of doing that... This is the same as the Fedora policy too. If users aren't meant to use virt-console directly then it should be in libexec as you say. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Introduce virt-console
On Thu, Jan 15, 2009 at 01:40:06PM +, Daniel P. Berrange wrote: One caveat on the latter though - if there's solaris specific stuff that is only available on newer Solaris versions, then a configure.ac check would be sensible to allow it to still build on earlier versions, depending on how much back-compat support you want todo, and whether its still practical to work without the feature in question. Earlier versions would be Solaris 10. Whilst it's conceivable that at some point we would have libvirt there, it's rather unlikely, and in such a case would involve a lot more work. regards john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Introduce virt-console
On Thu, Jan 15, 2009 at 01:40:03PM +, Richard W.M. Jones wrote: Doesn't working STREAMS exist on UnixWare too? I still think the UnixWare? Seriously? right thing to do is to detect STREAMS. If someone installs broken STREAMS on Linux, then it is their responsibility to find a more They're not broken - installing the STREAMS support doesn't magically rewrite the Linux kernel pty code to use it. You seem to be arguing that I should introduce potential bugs, with zero benefit. Of course, my preferred fix would be for Solaris to drop STREAMS, but that's a vain hope :) There's the problem - if Solaris drop streams, the #ifdef __sun checks will be incorrect. No - if this ever happens, it will not break pty-using code. Again, what test are you thinking of to detect that the pty code is STREAMS based? I'm not being obstructive here - I genuinely cannot conceive what such a test would look like. regards, john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Introduce virt-console
On Thu, Jan 15, 2009 at 01:45:50PM +, John Levon wrote: On Thu, Jan 15, 2009 at 01:28:37PM +, Daniel P. Berrange wrote: +libexec_PROGRAMS = virt-console This can just be bin_PROGRAMS - not need to hide it outside of /usr/bin - its fine to let users just run virt-console directly if they wish Solaris policy is not to introduce plumbing into the user's PATH. virt-console is undocumented and there is no advantage to running it directly. If it were in PATH we would have to document it, and we have no intention of doing that... I'll volunteer to write a manual page for virt-console, since even existing manpage for 'virsh console' is non-existant. We need to add an explicit argument to turn on the automatic reconnect of VMs when they reboot. Existing apps calling virsh console rely on its current semantics which are to exit upon domain reboot and we can't break them We argued about this last time. Looks like we'll have to keep this change private, and let Linux users suffer. Oh well :) You explicitly break virt-install by doing this. Have virt-console provide the more sensible default auto-reconnect semantics, and make 'virsh console' call it with a flag to turn this off to preserve existing semantics not break users like virt-install. +if (tcgetattr(ttyfd, ttyattr) 0) { +ioctl(ttyfd, I_PUSH, ptem); +ioctl(ttyfd, I_PUSH, ldterm); +tcgetattr(ttyfd, ttyattr); +} + +cfmakeraw(ttyattr); +tcsetattr(ttyfd, TCSANOW, ttyattr); +#endif The caller of open_tty() is also doing the getattr/makeraw/setattr operation, so this block appears to be redundant - just need to Nope, that's on STDIN, not the pty slave. Stupid STREAMS semantics. Oh, can you add a comment to this effect -- easy to miss that distinction when browsing the code :-) Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Introduce virt-console
On Thu, Jan 15, 2009 at 01:52:08PM +, Daniel P. Berrange wrote: Solaris policy is not to introduce plumbing into the user's PATH. virt-console is undocumented and there is no advantage to running it directly. If it were in PATH we would have to document it, and we have no intention of doing that... I'll volunteer to write a manual page for virt-console, since even existing manpage for 'virsh console' is non-existant. Hmm, I thought we'd picked up our virsh man page from upstream. But, I don't see it there. We need to add an explicit argument to turn on the automatic reconnect of VMs when they reboot. Existing apps calling virsh console rely on its current semantics which are to exit upon domain reboot and we can't break them We argued about this last time. Looks like we'll have to keep this change private, and let Linux users suffer. Oh well :) You explicitly break virt-install by doing this. Break how? Have virt-console provide the more sensible default auto-reconnect semantics, and make 'virsh console' call it with a flag to turn this off to preserve existing semantics not break users like virt-install. This is horrible IMHO - the user has to run some strange command instead of virsh like they use for everything else? I'd rather not auto-reconnect than this. The caller of open_tty() is also doing the getattr/makeraw/setattr operation, so this block appears to be redundant - just need to Nope, that's on STDIN, not the pty slave. Stupid STREAMS semantics. Oh, can you add a comment to this effect -- easy to miss that distinction when browsing the code :-) Yep. regards, john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 1/25: Implement virKill for Win32
On Tue, Jan 13, 2009 at 05:38:11PM +, Daniel P. Berrange wrote: This patches provides a minimal implementation for virKill on Win32. We don't particularly need this, but it avoids a need to #ifdef out code elsewhere and may come in handy. Looks fine to me but I'm unable to asser the correctness of the Win32 code :) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Introduce virt-console
On Thu, Jan 15, 2009 at 01:56:56PM +, John Levon wrote: On Thu, Jan 15, 2009 at 01:52:08PM +, Daniel P. Berrange wrote: Solaris policy is not to introduce plumbing into the user's PATH. virt-console is undocumented and there is no advantage to running it directly. If it were in PATH we would have to document it, and we have no intention of doing that... I'll volunteer to write a manual page for virt-console, since even existing manpage for 'virsh console' is non-existant. Hmm, I thought we'd picked up our virsh man page from upstream. But, I don't see it there. We need to add an explicit argument to turn on the automatic reconnect of VMs when they reboot. Existing apps calling virsh console rely on its current semantics which are to exit upon domain reboot and we can't break them We argued about this last time. Looks like we'll have to keep this change private, and let Linux users suffer. Oh well :) You explicitly break virt-install by doing this. Break how? It relies on virsh console exiting when the domain shuts down. Have virt-console provide the more sensible default auto-reconnect semantics, and make 'virsh console' call it with a flag to turn this off to preserve existing semantics not break users like virt-install. This is horrible IMHO - the user has to run some strange command instead of virsh like they use for everything else? I'd rather not auto-reconnect than this. Its not so strange in the context of all the other virt commands we have, in particular in relation to virt-viewer virt-viewer - graphical console virt-console - text console virt-top virt-df virt-manager virt-install ...etc.. If anything, virsh is the odd one out. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 1/25: Implement virKill for Win32
Daniel P. Berrange berra...@redhat.com wrote: This patches provides a minimal implementation for virKill on Win32. We don't particularly need this, but it avoids a need to #ifdef out code elsewhere and may come in handy. ACK, looks reasonable. (caveat: I haven't read documentation for any of those MS-specific functions) util.c | 45 + 1 file changed, 45 insertions(+) Daniel diff --git a/src/util.c b/src/util.c --- a/src/util.c +++ b/src/util.c @@ -1379,5 +1379,50 @@ int virKillProcess(pid_t pid, int sig) return -1; } +#ifdef WIN32 +/* Mingw / Windows don't have many signals (AFAIK) */ +switch (sig) { +case SIGINT: +/* This does a Ctrl+C equiv */ +if (!GenerateConsoleCtrlEvent(CTRL_C_EVENT, pid)) { +errno = ESRCH; +return -1; +} +break; + +case SIGTERM: +/* Since TerminateProcess is closer to SIG_KILL, we do + * a Ctrl+Break equiv which is more pleasant like the + * good old unix SIGTERM/HUP + */ +if (!GenerateConsoleCtrlEvent(CTRL_BREAK_EVENT, pid)) { +errno = ESRCH; +return -1; +} +break; + +default: +{ +HANDLE proc; +proc = OpenProcess(PROCESS_TERMINATE, FALSE, pid); +if (!proc) { +errno = ESRCH; /* Not entirely accurate, but close enough */ +return -1; +} + +/* + * TerminateProcess is more or less equiv to SIG_KILL, in that + * a process can't trap / block it + */ +if (!TerminateProcess(proc, sig)) { +errno = ESRCH; +return -1; +} +CloseHandle(proc); +} +} +return 0; +#else return kill(pid, sig); +#endif } -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 2/25: Internal threads APIs + impl
On Tue, Jan 13, 2009 at 05:38:55PM +, Daniel P. Berrange wrote: The forthcoming set of patches will do alot of work relating to threads, which requires mutual exclusion primitives. This will include mutexes, condition variables and thread locals. We spefically do not need the ability to actually create thread though, at least not in the libvirt.so, only in the daemon. We currently stub out all the mutex calls to no-ops when pthread.h is missing. This is undesirable because it means we cannot clearly state the thread safety rules for use of libvirt. Saying it is thread safe on Linux, but not on Windows is IMHO not acceptable if we want to have portability of apps using libvirt. So this patch - Adds an internal API for mutexes, condition variables and thread locals - Implements this API for pthreads (covers Liunux, Solaris, and all BSD variants). - Implements this API for Win32 threads (covers Win32 :-) - Updates all code to use these internal APIs instead of pthread-XXX directly. - Adds missing mutex destroy calls from earlier patches. The pthreads implementation is utterly trivial, since I purposely designed the internal API to map 1-to-1 onto pthreads, albeit with many unneccessary bits not exposed. Agreed with design and principle, that's basically what we ended up doing for libxml2 but in a more limited way. The Win32 implementatioin is more fun. Mutexes are trivial, I just followed the libxml2/glib impls for that. Thread locals are harder since Windows doesn't provide for any destructor to be called when a thread exits, meaning there's a potential memory leak. To address this I maintain some state for Win32 thread locals, in particular the destructor callback. I then added a DllMain() impl, which triggers upon thread-exit and explicitly calls the destructors. This is what DBus/win32-pthread does for thread locals. Finally condition variables are also hard because there's no native condition variable impl on Windows. I followed the GLib condition variable impl for this which uses a queue of waiters, a mutex and a Win32 event for wakeup. Not all that hard in the end. Well thread local storage is always a bit painful, whatever the platform. I did consider whether we could use win32-pthreads, but there's a few things I wasn't happy with. There are several different binary DLLs you have to choose between depending on what behaviour you want to C++ apps + exceptions. libvirt really shouldn't have to make that choice. More annoyingly, its pthread.h #include's its own config.h, so it seriously pollutes the global namespace with configure settings that clash with our own. This is a show stopper really. We also don't need the full ability to create threads, so wrapping Win32 thread natively wasn't very hard and that's what nearly every other app already does, so by using Win32 threads directly we should get better interoperabiltiy with other libraries doing the same. Agreed again, when the base OS has the API with proper semantic it's really better to go native. went though the patch, most of it is well replacement from old pthread_* to the new calls. The only thing which surprized me was the Init() routines error, it's the caller which reports the error instead of the callee, I'm wondering a bit why doing it that way. but looks fine, +1 Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Fine grained Access Control in libVirt
On Thu, Jan 15, 2009 at 02:39:20PM +0100, Konrad Eriksson1 wrote: After some background research it doesn't look like anyone have taken on the task yet to add fine-grained access control to libVirt (only option right now is R/W or RO mode). Desired is an addition to libVirt that enables access control on individual actions and data that can be accessed through the library API. This could take the form of an AC-module that, based on the identity of the caller, checks each call and grants/denies access to carry out the action (could also take parameters in account) and optionally filter the return data. The AC-module could then interface different backend AC solutions (SELinux, RBAC, ...) or alternatively implement an internal scheme. When looking at the libvirt core and driver framework it seems promising to inject these kind of call-out hooks either in libvirt.c or between libvirt.c and the underlying drivers, by doing this AC will be enforced independent of if a local or remote call is done to libVirt. I propose an approach to create an AC-module that conforms to the driver API in libVirt and to inject it in the call-path between libvirt.c and the driver(s) to enable the AC-module to inspect the call before sending it to the real driver. Normal call path: user - libvirt.c - driver_x AC-module injected in call path: user - libvirt.c - AC-module - driver_x By doing this it can be loaded/unloaded in run-time and also selectable what driver paths it should enforce (hypervisor(aka. driver), storage, network...). The AC-module can also be made in different flavors for different AC backend (SELinux, RBAC, internal, ...) solutions and the appropriate AC-module could be loaded without needing re-compiling. This approach would also leave a very small footprint in existing libvirt code (only need to inject AC-module driver after normal drivers has been loaded) FYI, I had discussed the alternative approach with Konrad offlist prior to this thread. Namely, instead of having a driver, layered in, put a call to something like virCheckAccess() directly into libvirt.c replacing the RO checks. The complication with doing it this way, is deciding what information to pass to the virCheckAccess methods. Obviously the operation name, and then some context for the object to the be checked. Do we just pass the virDomainPtr in there. Might need the XML for a new domain create call. Might want the other virConnectPtr for a migrate call and so on. Seems like we'd quickly end up having to pass all possible params through to the virCheckAcces method. At which point it really just becomes simpler to layer in the checks via the driver API which already has access to all the neccessary bits of info. So I think its reasonable to have MAC calls stacked into the driver API as Konrad illustrates above. The initial impl would just duplicate our existing RO checks, then we can consider other impls RBAC/SELinux etc Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 6/25: Avoid event loop wakups in remote driver
Daniel P. Berrange berra...@redhat.com wrote: When going into the call() method, we temporarily disable the event wakup callback. The call() method is already processing any async messages which arrive, so letting the main event loop wakup here is inefficient, and indeed will block the main event loop on the mutex while the main thread is in call(). We really don't want that ! remote_internal.c | 42 ++ 1 file changed, 34 insertions(+), 8 deletions(-) Daniel diff --git a/src/remote_internal.c b/src/remote_internal.c ... +doCall (virConnectPtr conn, struct private_data *priv, ... +static int +call (virConnectPtr conn, struct private_data *priv, + int flags /* if we are in virConnectOpen */, + int proc_nr, + xdrproc_t args_filter, char *args, + xdrproc_t ret_filter, char *ret) +{ +int rv; +/* + * Avoid needless wake-ups of the event loop in the + * case where this call is being made from a different + * thread than the event loop. These wake-ups would + * cause the event loop thread to be blocked on the + * mutex for the duration of the call + */ +if (priv-watch = 0) +virEventUpdateHandle(priv-watch, 0); + +rv = doCall(conn, priv,flags, proc_nr, +args_filter, args, +ret_filter, ret); + +if (priv-watch = 0) +virEventUpdateHandle(priv-watch, VIR_EVENT_HANDLE_READABLE); Looks fine. ACK. At first I wondered if someday the incoming event-update-handle type might be something other than VIR_EVENT_HANDLE_READABLE, in which case you'd want to save the original before doCall, and restore it afterward. Probably won't happen. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 4/25: Cleanup exit paths in remote driver
On Thu, Jan 15, 2009 at 11:31:53AM +, Daniel P. Berrange wrote: On Wed, Jan 14, 2009 at 10:41:50PM +, Daniel P. Berrange wrote: On Wed, Jan 14, 2009 at 08:39:02PM +0100, Jim Meyering wrote: Daniel P. Berrange berra...@redhat.com wrote: This patch ensures all public API methods only have a single exit path, to make mutex unlocking simpler. good idea ... Updated to remove that bogus chunk. I could not spot anythings suspect, +1 Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 7/25: Minor windows fix to remote driver
Daniel P. Berrange berra...@redhat.com wrote: Minor problem in the remote driver when lacking support for virExec(), we report an error and then carry on executing anyway. Of course we get a EINVAL error later when we try to write() on a FD of -1. Trivial fix remote_internal.c |1 + 1 file changed, 1 insertion(+) Daniel diff --git a/src/remote_internal.c b/src/remote_internal.c --- a/src/remote_internal.c +++ b/src/remote_internal.c @@ -690,6 +690,7 @@ doRemoteOpen (virConnectPtr conn, case trans_ext: error (conn, VIR_ERR_INVALID_ARG, _(transport methods unix, ssh and ext are not supported under Windows)); +goto failed; ACK. an obvious improvement. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 4/25: Cleanup exit paths in remote driver
Daniel P. Berrange berra...@redhat.com wrote: On Wed, Jan 14, 2009 at 10:41:50PM +, Daniel P. Berrange wrote: On Wed, Jan 14, 2009 at 08:39:02PM +0100, Jim Meyering wrote: Daniel P. Berrange berra...@redhat.com wrote: This patch ensures all public API methods only have a single exit path, to make mutex unlocking simpler. remote_internal.c | 1256 +++--- Hi Dan, I got about halfway through it and spotted something odd: diff --git a/src/remote_internal.c b/src/remote_internal.c ... static int remoteDomainGetSchedulerParameters (virDomainPtr domain, virSchedParameterPtr params, int *nparams) ... +cleanup: xdr_free ((xdrproc_t) xdr_remote_domain_get_scheduler_parameters_ret, (char *) ret); -return 0; +if (rv != 0) { +for ( ; i = 0 ; i--) +VIR_FREE(params[i].field); +} + +done: +return rv; } Freeing the .field member looks bogus. Hmmm, not sure why I added that - I must have been thinking it was a malloc'd char * at the time. Clearly bogus Updated to remove that bogus chunk. ACK to that. I confirmed it removes just those 6 lines and updated the git patch to match. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Introduce virt-console
On Thu, Jan 15, 2009 at 02:04:56PM +, Daniel P. Berrange wrote: You explicitly break virt-install by doing this. Break how? It relies on virsh console exiting when the domain shuts down. I'm confused, we've been using virt-install without apparent problems for quite some time like this? Have virt-console provide the more sensible default auto-reconnect semantics, and make 'virsh console' call it with a flag to turn this off to preserve existing semantics not break users like virt-install. This is horrible IMHO - the user has to run some strange command instead of virsh like they use for everything else? I'd rather not auto-reconnect than this. Its not so strange in the context of all the other virt commands we have, in particular in relation to virt-viewer virt-viewer - graphical console The existence of the other tools doesn't make it sensible for obscure behaviour changes between two ways of doing the exact same thing. The /only/ reason I'm introducing virt-console is to correctly implement the least priv support. virt-manager aside (which is more or less a graphical virsh/virt-install), all of these should have indeed been virsh commands. It's horrible that I have to use a separate tool with a different interface to install my guest, then virsh to manage it. regards, john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Introduce virt-console
On Thu, Jan 15, 2009 at 02:05:14PM +, Richard W.M. Jones wrote: No - if this ever happens, it will not break pty-using code. Again, what test are you thinking of to detect that the pty code is STREAMS based? I'm not being obstructive here - I genuinely cannot conceive what such a test would look like. I think something as simple as: AC_CHECK_FUNCS([isastream]) is sufficient to check whether the libc claims to support STREAMS. That wasn't what I asked for. If it turns out that someone has installed a buggy STREAMS implementation, we can make the check more fine-grained later. Again, it's NOT buggy for isastream to exist, and pty's to be non-STREAMS. My way: - definitely not buggy, less code Your way: - possibly buggy, more code What platform are you expecting this extra code to help? It's not the BSDs, Mac OS X, Solaris, Linux, or Windows. I'll buy you tea at the Ritz if someone ports libvirt to UnixWare :) regards, john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 8/25: Concurrent dispatch of RPC methods
On Tue, Jan 13, 2009 at 05:41:48PM +, Daniel P. Berrange wrote: This patch re-writes the code for dispatching RPC calls in the remote driver to allow use from multiple threads. Only one thread is allowed to send/recv on the socket at a time though. If another thread comes along it will put itself on a queue and go to sleep. The first thread may actually get around to transmitting the 2nd thread's request while it is waiting for its own reply. It may even get the 2nd threads reply, if its own RPC call is being really slow. So when a thread wakes up from sleeping, it has to check whether its own RPC call has already been processed. Likewise when a thread owning the socket finishes with its own wor, it may have to pass the buck to another thread. The upshot of this, is that we have mutliple RPC calls executing in parallel, and requests+reply are no longer guarenteed to be FIFO on the wire if talking to a new enough server. This refactoring required use of a self-pipe/poll trick for sync between threads, but fortunately gnulib now provides this on Windows too, so there's no compatability problem there. The new code is actually a bit easier to read than the old one I think, but I didn't grasp all the details I must admit. The only worry I have with the pass the buck scheme is the piling up on recursive calls, I don't think there is any risk with the normal libvirt APIs as they are all 'terminal calls' in a sense, but I'm wondering what's happening say in conjunction with a high flow of events back to a client, the client doing calls as a result of the events etc ... Seems we are safe because no direct call from within the library is triggered by the reception of an event. Maybe I'm just wrong though, anyway the best is to push the change and monitor what is happening in the worst case circumstances. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 8/25: Concurrent dispatch of RPC methods
On Thu, Jan 15, 2009 at 04:03:16PM +0100, Daniel Veillard wrote: On Tue, Jan 13, 2009 at 05:41:48PM +, Daniel P. Berrange wrote: This patch re-writes the code for dispatching RPC calls in the remote driver to allow use from multiple threads. Only one thread is allowed to send/recv on the socket at a time though. If another thread comes along it will put itself on a queue and go to sleep. The first thread may actually get around to transmitting the 2nd thread's request while it is waiting for its own reply. It may even get the 2nd threads reply, if its own RPC call is being really slow. So when a thread wakes up from sleeping, it has to check whether its own RPC call has already been processed. Likewise when a thread owning the socket finishes with its own wor, it may have to pass the buck to another thread. The upshot of this, is that we have mutliple RPC calls executing in parallel, and requests+reply are no longer guarenteed to be FIFO on the wire if talking to a new enough server. This refactoring required use of a self-pipe/poll trick for sync between threads, but fortunately gnulib now provides this on Windows too, so there's no compatability problem there. The new code is actually a bit easier to read than the old one I think, but I didn't grasp all the details I must admit. The only worry I have with the pass the buck scheme is the piling up on recursive calls, I don't think there is any risk with the normal libvirt APIs as they are all 'terminal calls' in a sense, but I'm wondering what's happening say in conjunction with a high flow of events back to a client, the client doing calls as a result of the events etc ... Seems we are safe because no direct call from within the library is triggered by the reception of an event. We shouldn't get recursion here. There are two scenarios 1. Thread is in the call() function, when an event arrives - The event is put on a queue, and a 0 second timer is activated in the app's event loop - Once call() finishes, the 0 second timer fires, and the event is dispatched to the app. 2. Event arrives when no one is in call() function. - The event is dispatched to app straightaway Now, the apps' callback which receives the event, may in turn make libvirt calls. This won't cause any recursion because the two scenarios above both guarentee that the event callback is not run from within the contxt of a call() command. When processing queued events we are also careful to handle our data structures such that a different thread can still safely make calls / receive queue more events. There's always a possible impl bug in there, but I believe the general structure / design is correctly coping the neccessary scenarios Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Avoid passing NULL to printf %s specifier
# HG changeset patch # User john.le...@sun.com # Date 1232032750 28800 # Node ID 0335828806b5b3855c8eeaee31446a7bd0c02974 # Parent e542223a4c52d978d4507de709f50885920a5b44 Avoid passing NULL to printf %s specifier This is non-portable. Signed-off-by: John Levon john.le...@sun.com diff --git a/src/internal.h b/src/internal.h --- a/src/internal.h +++ b/src/internal.h @@ -7,6 +7,7 @@ #include errno.h #include limits.h +#include verify.h #ifdef HAVE_SYS_SYSLIMITS_H #include sys/syslimits.h @@ -115,6 +116,13 @@ #define ATTRIBUTE_RETURN_CHECK #endif /* __GNUC__ */ +/* + * Use this when passing possibly-NULL strings to printf-a-likes. + */ +#define NULLSTR(s) \ +((void)verify_true(sizeof *(s) == sizeof (char)), \ + (s) ? (s) : (null)) + /** * TODO: * diff --git a/src/libvirt.c b/src/libvirt.c --- a/src/libvirt.c +++ b/src/libvirt.c @@ -864,10 +864,10 @@ do_open (const char *name, port %d\n path %s\n, name, - ret-uri-scheme, ret-uri-opaque, - ret-uri-authority, ret-uri-server, - ret-uri-user, ret-uri-port, - ret-uri-path); + NULLSTR(ret-uri-scheme), NULLSTR(ret-uri-opaque), + NULLSTR(ret-uri-authority), NULLSTR(ret-uri-server), + NULLSTR(ret-uri-user), ret-uri-port, + NULLSTR(ret-uri-path)); } else { DEBUG0(no name, allowing driver auto-select); } @@ -1056,7 +1056,7 @@ virConnectOpenAuth(const char *name, if (virInitialize() 0) return NULL; -DEBUG(name=%s, auth=%p, flags=%d, name, auth, flags); +DEBUG(name=%s, auth=%p, flags=%d, NULLSTR(name), auth, flags); return do_open (name, auth, flags); } -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 8/25: Concurrent dispatch of RPC methods
On Thu, Jan 15, 2009 at 03:12:11PM +, Daniel P. Berrange wrote: On Thu, Jan 15, 2009 at 04:03:16PM +0100, Daniel Veillard wrote: On Tue, Jan 13, 2009 at 05:41:48PM +, Daniel P. Berrange wrote: This patch re-writes the code for dispatching RPC calls in the remote driver to allow use from multiple threads. Only one thread is allowed to send/recv on the socket at a time though. If another thread comes along it will put itself on a queue and go to sleep. The first thread may actually get around to transmitting the 2nd thread's request while it is waiting for its own reply. It may even get the 2nd threads reply, if its own RPC call is being really slow. So when a thread wakes up from sleeping, it has to check whether its own RPC call has already been processed. Likewise when a thread owning the socket finishes with its own wor, it may have to pass the buck to another thread. The upshot of this, is that we have mutliple RPC calls executing in parallel, and requests+reply are no longer guarenteed to be FIFO on the wire if talking to a new enough server. This refactoring required use of a self-pipe/poll trick for sync between threads, but fortunately gnulib now provides this on Windows too, so there's no compatability problem there. The new code is actually a bit easier to read than the old one I think, but I didn't grasp all the details I must admit. The only worry I have with the pass the buck scheme is the piling up on recursive calls, I don't think there is any risk with the normal libvirt APIs as they are all 'terminal calls' in a sense, but I'm wondering what's happening say in conjunction with a high flow of events back to a client, the client doing calls as a result of the events etc ... Seems we are safe because no direct call from within the library is triggered by the reception of an event. We shouldn't get recursion here. There are two scenarios 1. Thread is in the call() function, when an event arrives - The event is put on a queue, and a 0 second timer is activated in the app's event loop - Once call() finishes, the 0 second timer fires, and the event is dispatched to the app. 2. Event arrives when no one is in call() function. - The event is dispatched to app straightaway Now, the apps' callback which receives the event, may in turn make libvirt calls. This won't cause any recursion because the two scenarios above both guarentee that the event callback is not run from within the contxt of a call() command. When processing queued events we are also careful to handle our data structures such that a different thread can still safely make calls / receive queue more events. There's always a possible impl bug in there, but I believe the general structure / design is correctly coping the neccessary scenarios Okay, thanks, I agree that the best at this point is to push it to get broader testing, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Solaris least privilege support
On Thu, Jan 15, 2009 at 12:57:49PM +, John Levon wrote: +#ifdef __sun +/* + * On Solaris, all clients are forced to go via virtd. As a result, + * virtd must indicate it really does want to connect to the + * hypervisor. + */ +name = xen:///; +#endif This should not be neccessary if the client end + drivers are correctly written. Can you explain a bit more? Why don't we need to rewrite the URI as xen? If you want Xen to always go via the demon, the only change that should be required, is to make xenUnifiedOpen() return VIR_DRV_OPEN_DECLINED. Hmm, yes you might be right. Let me experiment. There's three scenarios to worry about: 1. uri == NULL or 2. uri == xen:/// or xen+unix:/// 3. uri == remote:/// or remote+unix:/// First of all, in the client case assume that Xen driver has neccessary smart to decline the first two URIs, and it trivially ignores the 3rd case already Now the open request proceeds to the remote driver, which is happy to accept all 3 of these URIs I've outlined above. It looks at the URI, strips out any bits that are relevant to its own use (eg remove the +unix bit, or any query parameters). It thus builds a URI to pass to the remote daemon. In the 3 examples above, the URIs which remote_internal.c builds to pass to the daemon over the wire are: 1. 2. xen:/// 3. So, inside the daemon, when virConnectOpen is run, all three of those URIs will happily be accepted by the Xen driver thus the code to force 'name = xen:///' in qemud/remote.c is not required. Tthe key really thing you need to ensure that all Xen calls take place inside the daemon, is simply to make sure the Xen driver always returns VIR_DRV_OPEN_DECLINED for non-daemon open calls. Everything else should 'just work' Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Avoid passing NULL to printf %s specifier
On Thu, Jan 15, 2009 at 07:19:33AM -0800, john.le...@sun.com wrote: # HG changeset patch # User john.le...@sun.com # Date 1232032750 28800 # Node ID 0335828806b5b3855c8eeaee31446a7bd0c02974 # Parent e542223a4c52d978d4507de709f50885920a5b44 Avoid passing NULL to printf %s specifier +1 to this patch. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] FYI: Mercurial repository with read-only CVS mirror
FYI. After a number of requests I have setup a anonymously accessible mercurial repository containing a read-only mirror of libvirt CVS. It is accessible via HTTP only by running: cd $HOME hg clone http://libvirt.org/hg/libvirt-mirror/ The conversion is done using Tailor, and synced every 15 minutes. It is an incremental sync, so you can pull down new changes as they appear by then doing cd $HOME cd libvirt-mirror hg pull -u Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Solaris least privilege support
On Thu, Jan 15, 2009 at 03:34:11PM +, Daniel P. Berrange wrote: Tthe key really thing you need to ensure that all Xen calls take place inside the daemon, is simply to make sure the Xen driver always returns VIR_DRV_OPEN_DECLINED for non-daemon open calls. Everything else should 'just work' Yes, this sounds much cleaner - thanks regards john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 1/25: Implement virKill for Win32
On Tue, Jan 13, 2009 at 05:38:11PM +, Daniel P. Berrange wrote: This patches provides a minimal implementation for virKill on Win32. We don't particularly need this, but it avoids a need to #ifdef out code elsewhere and may come in handy. util.c | 45 + 1 file changed, 45 insertions(+) +1. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 2/25: Internal threads APIs + impl
+1 to this. Implementation looks reasonable, and I agree with your decision not to use win32-pthreads. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 5/25: Locking in remote driver
On Tue, Jan 13, 2009 at 05:40:18PM +, Daniel P. Berrange wrote: Adds locking in the remote driver. This obtains the lock on every single API method. This is quite poor, not giving any parallelism - that will be added in 2 patch's time, when we drop the lock while waiting on I/O remote_internal.c | 523 +- 1 file changed, 481 insertions(+), 42 deletions(-) I worry about remoteNetworkOpen, but the code there already is tortuous enough. remoteDevMonOpen is even more horrible, but it appears correct. Guarded +1. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 7/25: Minor windows fix to remote driver
On Tue, Jan 13, 2009 at 05:41:15PM +, Daniel P. Berrange wrote: Minor problem in the remote driver when lacking support for virExec(), we report an error and then carry on executing anyway. Of course we get a EINVAL error later when we try to write() on a FD of -1. Trivial fix remote_internal.c |1 + 1 file changed, 1 insertion(+) Daniel diff --git a/src/remote_internal.c b/src/remote_internal.c --- a/src/remote_internal.c +++ b/src/remote_internal.c @@ -690,6 +690,7 @@ doRemoteOpen (virConnectPtr conn, case trans_ext: error (conn, VIR_ERR_INVALID_ARG, _(transport methods unix, ssh and ext are not supported under Windows)); +goto failed; #endif /* WIN32 */ +1, obvious. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 9/25: Make global error object thread local
On Tue, Jan 13, 2009 at 05:42:15PM +, Daniel P. Berrange wrote: The virGetLastError() and virConnGetLastError() methods are not even remotely thread safe, and the virCopyLastError/virConnCopyLastError methods don't help in this goal, being open to a race condition. This patch changes the internal impl of the global error object to store its virError instance in a thread local variable. All errors are now reported against the global error object. In the public API entry points, we explicitly reset the global error object to ensure no stale errors are hanging around. In all error paths we also set a generic error, if the internal driver forget to set an explicit error. Finally we also copy the global error to the per connection error object for back-compatability, though the global object remains non-threadsafe for application access. src/datatypes.c | 31 src/datatypes.h | 15 src/libvirt.c| 3276 --- src/virterror.c | 258 +++ src/virterror_internal.h |5 tests/cpuset |2 tests/read-bufsiz|2 tests/start |4 tests/undefine |8 tests/vcpupin|4 10 files changed, 2507 insertions(+), 1098 deletions(-) Yup, looks good, and also fixes lots of potential bugs where the connection object might have been corrupted. +1. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 10/25: Remove use of strerror()
On Tue, Jan 13, 2009 at 05:42:41PM +, Daniel P. Berrange wrote: The strerror() method is not guarenteed to be re-entrant, which is rather a pain because the strerror_r() method is rather unpleasant to use. In addition our code is quite inconsistent about using VIR_ERR_SYSTEM_ERROR vs VIR_ERR_INTERNAL_ERROR for problems which have an 'errno' avilable. Likewise we're not very consistent about OOM reporting error codes This patch thus introduces two convenient functions for reporting a system error and OOM error. virReportSystemError(conn, theerrno, fmt,...) virReportOOMError(conn) Yes, a very welcome change. I've looked through the patch briefly and it looks good, and hoping gcc would pick up any gross argument mismatches. So +1. diff --git a/autobuild.sh b/autobuild.sh --- a/autobuild.sh +++ b/autobuild.sh @@ -65,6 +65,7 @@ if [ -x /usr/bin/i686-pc-mingw32-gcc ]; --build=$(uname -m)-pc-linux \ --host=i686-pc-mingw32 \ --prefix=$AUTOBUILD_INSTALL_ROOT/i686-pc-mingw32/sys-root/mingw \ +--enable-compile-warnings=error \ --without-sasl \ --without-avahi \ --without-polkit \ Intended? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 11/25: Public APIs for incrementing refcount
On Tue, Jan 13, 2009 at 05:43:08PM +, Daniel P. Berrange wrote: With the domain events code, the callbacks triggered upon events get given a virDomainPtr object instance. In many cases it'd be desirable to grab this object and keep it in your app code. Unfortunately it is free'd the moment the callback finishes executing. When allowing multiple threads to access a single virConnectPtr object it is neccessary to ensure no thread releases it (virConnectCLose) while another thread is still using it. The way to address both of these problems is to allow an application to take an explicit reference on the object in question. So this patch exposes methods to allow an app to increment the ref count on all our public objects. To release the ref count, the existing virConectClose/ virDOmainFree, etc methods suffice include/libvirt/libvirt.h|6 + include/libvirt/libvirt.h.in |6 + src/libvirt.c| 183 +++ src/libvirt_public.syms | 12 ++ 4 files changed, 206 insertions(+), 1 deletion(-) Poor man's garbage collection ... +1. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Solaris least privilege support
# HG changeset patch # User john.le...@sun.com # Date 1232039546 28800 # Node ID b9d4d60bca87633897cb133461e1415d1223c823 # Parent 25a0c46588d5de1653b16dfed6bc357abf11db77 Solaris least privilege support On Solaris dom0, virtd runs as a privilege barrier: all libvirt connections are routed through it, and it performs the relevant privilege checks for any clients. Signed-off-by: John Levon john.le...@sun.com diff --git a/qemud/qemud.c b/qemud/qemud.c --- a/qemud/qemud.c +++ b/qemud/qemud.c @@ -84,6 +84,39 @@ #endif +#ifdef __sun +#include ucred.h +#include priv.h + +#ifndef PRIV_VIRT_MANAGE +#define PRIV_VIRT_MANAGE ((const char *)virt_manage) +#endif + +#ifndef PRIV_XVM_CONTROL +#define PRIV_XVM_CONTROL ((const char *)xvm_control) +#endif + +#define PU_RESETGROUPS 0x0001 /* Remove supplemental groups */ +#define PU_CLEARLIMITSET0x0008 /* L=0 */ + +extern int __init_daemon_priv(int, uid_t, gid_t, ...); + +#define SYSTEM_UID 60 + +static gid_t unix_sock_gid = 60; /* Not used */ +static int unix_sock_rw_mask = 0666; +static int unix_sock_ro_mask = 0666; + +#else + +#define SYSTEM_UID 0 + +static gid_t unix_sock_gid = 0; /* Only root by default */ +static int unix_sock_rw_mask = 0700; /* Allow user only */ +static int unix_sock_ro_mask = 0777; /* Allow world */ + +#endif /* __sun */ + static int godaemon = 0;/* -d: Be a daemon */ static int verbose = 0; /* -v: Verbose mode */ static int timeout = -1;/* -t: Shutdown timeout */ @@ -101,10 +134,6 @@ static char *listen_addr = (char *) LIB static char *listen_addr = (char *) LIBVIRTD_LISTEN_ADDR; static char *tls_port = (char *) LIBVIRTD_TLS_PORT; static char *tcp_port = (char *) LIBVIRTD_TCP_PORT; - -static gid_t unix_sock_gid = 0; /* Only root by default */ -static int unix_sock_rw_mask = 0700; /* Allow user only */ -static int unix_sock_ro_mask = 0777; /* Allow world */ #if HAVE_POLKIT static int auth_unix_rw = REMOTE_AUTH_POLKIT; @@ -638,10 +667,11 @@ static int qemudInitPaths(struct qemud_s static int qemudInitPaths(struct qemud_server *server, char *sockname, char *roSockname, - int maxlen) { + int maxlen) +{ uid_t uid = geteuid(); -if (!uid) { +if (uid == SYSTEM_UID) { if (snprintf (sockname, maxlen, %s/run/libvirt/libvirt-sock, LOCAL_STATE_DIR) = maxlen) goto snprintf_error; @@ -1105,6 +1135,29 @@ static int qemudDispatchServer(struct qe return -1; } +#ifdef __sun +{ +ucred_t *ucred = NULL; +const priv_set_t *privs; + +if (getpeerucred (fd, ucred) == -1 || +(privs = ucred_getprivset (ucred, PRIV_EFFECTIVE)) == NULL) { +if (ucred != NULL) +ucred_free (ucred); +close (fd); +return -1; +} + +if (!priv_ismember (privs, PRIV_VIRT_MANAGE)) { +ucred_free (ucred); +close (fd); +return -1; +} + +ucred_free (ucred); +} +#endif /* __sun */ + /* Disable Nagle. Unix sockets will ignore this. */ setsockopt (fd, IPPROTO_TCP, TCP_NODELAY, (void *)no_slow_start, sizeof no_slow_start); @@ -2239,6 +2292,29 @@ version (const char *argv0) { printf (%s (%s) %s\n, argv0, PACKAGE_NAME, PACKAGE_VERSION); } + +#ifdef __sun +static void +qemudSetupPrivs (struct qemud_server *server) +{ +chown (/var/run/libvirt, SYSTEM_UID, SYSTEM_UID); +chown (server-logDir, SYSTEM_UID, SYSTEM_UID); + +if (__init_daemon_priv (PU_RESETGROUPS | PU_CLEARLIMITSET, +SYSTEM_UID, SYSTEM_UID, PRIV_XVM_CONTROL, NULL)) { +fprintf (stderr, additional privileges are required\n); +exit (1); +} + +if (priv_set (PRIV_OFF, PRIV_ALLSETS, PRIV_FILE_LINK_ANY, PRIV_PROC_INFO, +PRIV_PROC_SESSION, PRIV_PROC_EXEC, PRIV_PROC_FORK, NULL)) { +fprintf (stderr, failed to set reduced privileges\n); +exit (1); +} +} +#else +#define qemudSetupPrivs(a) +#endif /* Print command-line usage. */ static void @@ -2417,6 +2493,20 @@ int main(int argc, char **argv) { sig_action.sa_handler = SIG_IGN; sigaction(SIGPIPE, sig_action, NULL); +/* Change the group ownership of /var/run/libvirt to unix_sock_gid */ +if (geteuid () == 0) { +const char *rundir = LOCAL_STATE_DIR /run/libvirt; + +if (mkdir (rundir, 0755)) { +if (errno != EEXIST) { +VIR_ERROR0 (_(unable to create rundir)); +return (-1); +} +} +} + +qemudSetupPrivs(server); + if (!(server = qemudInitialize(sigpipe[0]))) { ret = 2; goto error2; diff --git a/src/remote_internal.c b/src/remote_internal.c --- a/src/remote_internal.c +++ b/src/remote_internal.c @@ -90,7 +90,7 @@ #define MAGIC 999 /* private_data-magic if OK */ #define
Re: [libvirt] PATCH: 12/25: Remove global state from Inotify driver
On Tue, Jan 13, 2009 at 05:43:38PM +, Daniel P. Berrange wrote: The 'inotify' driver currently keeps all its state in a global static variables. Not so great since we access this from all sorts of places and its hard to guarentee thread safety. Also, we're using per-connection FD watches to update this state, so if multiple Xen connections were active, they'd all be updating the same globl state. So we move the state into the virConnect object. This will increase memory usage if a single process has multiple Xen connections open though, but not by very much I'm not really familiar with this code. It seems reasonable, but I'll let someone else check it. Just to say ... -if (!memcmp(uuid, configInfoList-doms[i]-uuid, VIR_UUID_BUFLEN)) { memcmp (...) == 0 or define a new equality test macro? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 8/25: Concurrent dispatch of RPC methods
On Thu, Jan 15, 2009 at 05:07:01PM +, Richard W.M. Jones wrote: On Tue, Jan 13, 2009 at 05:41:48PM +, Daniel P. Berrange wrote: +/* Get a unique serial number for this message. */ +rv-serial = priv-counter++; This (and similar) are safe because we hold the remoteDriverLock until we enter the actual call? That is correct - the first thing all the public API entry points do is grab the lock. The lock is only then released, when the main thread is waiting on I/O in the poll() call: +remoteDriverUnlock(priv); + +repoll: +ret = poll(fds, ARRAY_CARDINALITY(fds), -1); +if (ret 0 errno == EINTR) +goto repoll; +remoteDriverLock(priv); Or when additional threads are sleeping on the condition variable. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 13/25: Remove global state from XM driver
On Tue, Jan 13, 2009 at 05:44:00PM +, Daniel P. Berrange wrote: The 'xm' driver currently keeps all its state in a global static variables. Not cool, since we access this from all sorts of places and its hard to guarentee thread safety. So we move the state into the virConnect object. This will increase memory usage if a single process has multiple Xen connections open though. Undecided whether this is a big problem or not. If so, I'll can try and redo the next thread locking patch to use a lock over the existing global state. xen_inotify.c |4 xen_unified.c |1 xen_unified.h | 14 ++- xm_internal.c | 262 +- xm_internal.h |3 5 files changed, 149 insertions(+), 135 deletions(-) The patch appears straightforward enough, and for the XM driver (ie. ancient history Xen) I'm sure we don't care much about a tiny bit of extra memory. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 14/25: Xen thread safety
On Tue, Jan 13, 2009 at 05:44:21PM +, Daniel P. Berrange wrote: This patch makes the various Xen drivers threadsafe by adding a mutex lock on the xenUnifiedPrivatePtr object. The XenD driver does not really need much locking, since it usually just calls out to XenD. Likewise the Xen driver just makes hypercalls. Locks are needed for libxenstore access, and the xm/inotify drivers since they have shared state src/proxy_internal.c | 173 - src/xen_inotify.c | 25 +++- src/xen_internal.c| 29 +++-- src/xen_unified.c | 176 +- src/xen_unified.h | 36 +-- src/xend_internal.c | 37 ++- src/xm_internal.c | 256 +- src/xs_internal.c | 130 +++-- src/xs_internal.h |7 - tests/sexpr2xmltest.c | 19 +++ 10 files changed, 575 insertions(+), 313 deletions(-) + /* Many puppies died to bring you this code. */ This code makes my head spin ... Looks reasonable, but to be honest I would _only_ trust automated verification that the locks are being acquired and dropped correctly, and the structure elements are only being used while locks are acquired. The CIL stuff is doing that? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 15/25: Prohibit non-threadsafe POSIX apis
On Tue, Jan 13, 2009 at 05:44:51PM +, Daniel P. Berrange wrote: There are a huge list of functions in POSIX which are not safe to use from multiple threads currently. I generated the list by looking at all libc symbol exports for variants which have a parallel _r symbol. nm -D --defined-only /lib/libc.so.6 \ | grep '_r$' \ | awk '{print $3}' \ | grep -v __ \ | grep -v qsort \ | grep -v readdir \ | sort \ | uniq \ | sed -e 's/_r//' The qsort one is a red herring, since you only need qsort_r if you need to pass a extra 'void * opaque' data blob to your sort function - we don't, so don't need qsort_r. The readdir one is also unneccessary, since reading from a single DIR* is safe from a single thread. readdir_r is also horrific http://womble.decadentplace.org.uk/readdir_r-advisory.html This patch adds a 'make sc_prohibit_nonrentrant' rule to the 'syntax-check' for these forbidden functions. .x-sc_prohibit_nonreentrant |8 Makefile.am |2 + Makefile.maint | 11 + Makefile.nonreentrant | 85 4 files changed, 106 insertions(+) Yup, perfect, +1. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 16/25: Fix GNULIB warnings on Mingw
On Tue, Jan 13, 2009 at 05:45:14PM +, Daniel P. Berrange wrote: The GNULIB Makefile.am doesn't set any particular compiler warning flags in the belief that upstream GNULIB developers sort out all warnings before committing their code. This is reasonable for builds on mainstream Linux platforms, but MinGW builds of GNULIB don't have nearly the same level of testing. So This patch adds the libvirt $(WARN_CFLAGS) to the gnulib Makefile.am and then fixes the problems this showed up. Nothing of consequence really. Leave it upto gnulib developers whether its worth fixing these. Makefile.am|2 gettimeofday.c |5 +- ioctl.c|1 poll.c |4 - strerror.c | 128 - I can't really comment, but it seems OK. Should we CC this patch to the bug-gnulib mailing list? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Fix vm define error with back compat console device
If you define a domain with serial devs 0 parallel devs = serial devs, libvirtd segfaults when trying to set up the back compat console device. We were using a previous loop counter where we shouldn't. The attached patch fixes this. Thanks, Cole diff --git a/src/domain_conf.c b/src/domain_conf.c index 8bb51f7..890afe0 100644 --- a/src/domain_conf.c +++ b/src/domain_conf.c @@ -3320,8 +3320,9 @@ char *virDomainDefFormat(virConnectPtr conn, if (virDomainChrDefFormat(conn, buf, def-console, console) 0) goto cleanup; } else if (def-nserials != 0) { -/* ..else for legacy compat duplicate the serial device as a console */ -if (virDomainChrDefFormat(conn, buf, def-serials[n], console) 0) +/* ..else for legacy compat duplicate the first serial device as a + * console */ +if (virDomainChrDefFormat(conn, buf, def-serials[0], console) 0) goto cleanup; } -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 8/25: Concurrent dispatch of RPC methods
On Thu, Jan 15, 2009 at 05:22:52PM +, Daniel P. Berrange wrote: On Thu, Jan 15, 2009 at 05:07:01PM +, Richard W.M. Jones wrote: On Tue, Jan 13, 2009 at 05:41:48PM +, Daniel P. Berrange wrote: +/* Get a unique serial number for this message. */ +rv-serial = priv-counter++; This (and similar) are safe because we hold the remoteDriverLock until we enter the actual call? That is correct - the first thing all the public API entry points do is grab the lock. The lock is only then released, when the main thread is waiting on I/O in the poll() call: +remoteDriverUnlock(priv); + +repoll: +ret = poll(fds, ARRAY_CARDINALITY(fds), -1); +if (ret 0 errno == EINTR) +goto repoll; +remoteDriverLock(priv); Or when additional threads are sleeping on the condition variable. +1 then. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 10/25: Remove use of strerror()
On Thu, Jan 15, 2009 at 05:23:46PM +, Daniel P. Berrange wrote: Yes, I noticed the MinGW build is now completely free of warnings so figured I'd add that to stop us ever re-introducing warnings on MinGW :-) Cool, +1! Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Solaris least privilege support
john.le...@sun.com wrote: Solaris least privilege support On Solaris dom0, virtd runs as a privilege barrier: all libvirt connections are routed through it, and it performs the relevant privilege checks for any clients. Hi John, When reposting a patch, please say a few words about what you've changed since the previous, the more the better ;-) That helps everyone involved. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fix vm define error with back compat console device
Cole Robinson crobi...@redhat.com wrote: If you define a domain with serial devs 0 parallel devs = serial devs, libvirtd segfaults when trying to set up the back compat console device. We were using a previous loop counter where we shouldn't. The attached patch fixes this. Thanks, Cole diff --git a/src/domain_conf.c b/src/domain_conf.c index 8bb51f7..890afe0 100644 --- a/src/domain_conf.c +++ b/src/domain_conf.c @@ -3320,8 +3320,9 @@ char *virDomainDefFormat(virConnectPtr conn, if (virDomainChrDefFormat(conn, buf, def-console, console) 0) goto cleanup; } else if (def-nserials != 0) { -/* ..else for legacy compat duplicate the serial device as a console */ -if (virDomainChrDefFormat(conn, buf, def-serials[n], console) 0) +/* ..else for legacy compat duplicate the first serial device as a + * console */ +if (virDomainChrDefFormat(conn, buf, def-serials[0], console) 0) goto cleanup; } Hi Cole, ACK! This looks like an obviously-right fix. Thanks for the sample input file you provided, I confirmed and used it to write a test case that demonstrates the problem. With the following test, running this command, make check -C tests TESTS=define-dev-segfault VERBOSE=yes would fail with output including this: + libvirtd + virsh --connect qemu:///session define devs.xml ./define-dev-segfault: line 84: 4882 Segmentation fault libvirtd log 21 With your patch applied, the test passes. From b16f407a6369cf4c3a5770c4b49515b565f29b4f Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Thu, 15 Jan 2009 19:51:39 +0100 Subject: [PATCH] exercise a bug that could make libvirtd segfault * tests/define-dev-segfault: New file. * tests/Makefile.am (test_scripts): Add define-dev-segfault. --- tests/Makefile.am |1 + tests/define-dev-segfault | 92 + 2 files changed, 93 insertions(+), 0 deletions(-) create mode 100755 tests/define-dev-segfault diff --git a/tests/Makefile.am b/tests/Makefile.am index 0486ee3..7acb745 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -59,6 +59,7 @@ test_scripts = domainschematest if WITH_LIBVIRTD test_scripts += \ test_conf.sh \ + define-dev-segfault \ cpuset \ daemon-conf \ int-overflow \ diff --git a/tests/define-dev-segfault b/tests/define-dev-segfault new file mode 100755 index 000..903568f --- /dev/null +++ b/tests/define-dev-segfault @@ -0,0 +1,92 @@ +#!/bin/sh +# Exercise a bug whereby defining a valid domain could kill libvirtd. + +if test $VERBOSE = yes; then + set -x + libvirtd --version + virsh --version +fi + +test -z $srcdir srcdir=$(pwd) +test -z $abs_top_srcdir abs_top_srcdir=$(pwd)/.. +. $srcdir/test-lib.sh + +fail=0 + +# Domain definition from Cole Robinson. +cat \EOF devs.xml || fail=1 +domain type='kvm' +nameD/name +uuidaaa3ae22-fed2-bfbd-ac02-3bea3bcfad82/uuid +memory262144/memory +currentMemory262144/currentMemory +vcpu1/vcpu +os +type arch='i686' machine='pc'hvm/type +boot dev='cdrom'/ +/os +features +acpi/ +/features +clock offset='utc'/ +on_poweroffdestroy/on_poweroff +on_rebootrestart/on_reboot +on_crashdestroy/on_crash +devices +emulator/usr/bin/qemu-kvm/emulator +disk type='file' device='cdrom' + target dev='hdc' bus='ide'/ + readonly/ +/disk +disk type='file' device='floppy' + target dev='fdb' bus='fdc'/ +/disk +disk type='file' device='cdrom' +target dev='sda' bus='scsi'/ +readonly/ +/disk +interface type='network' +mac address='54:52:00:6c:a0:ca'/ +source network='aa'/ +/interface +interface type='network' +mac address='54:52:00:6c:bb:ca'/ +source network='default'/ +/interface +serial type='pty'/ +serial type='pty'/ +serial type='pty'/ +parallel type='pty'/ +parallel type='pty'/ +parallel type='pty'/ +input type='mouse' bus='ps2'/ +sound model='pcspk'/ +sound model='es1370'/ +hostdev mode='subsystem' type='usb' +source +address bus='3' device='3'/ +/source +/hostdev +hostdev mode='subsystem' type='usb' +source +vendor id='0x0483'/ +product id='0x2016'/ +/source +/hostdev +/devices +/domain +EOF + +libvirtd log 21 pid=$! +sleep 1 + +virsh --connect qemu:///session define devs.xml out 21 \ + || fail=1 + +kill $pid + +printf 'Domain D defined from devs.xml\n\n' exp || fail=1 + +compare exp out || fail=1 +compare /dev/null log || fail=1 +exit $fail -- 1.6.1.233.g5b4a8 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Solaris least privilege support
On Thu, Jan 15, 2009 at 08:00:38PM +0100, Jim Meyering wrote: On Solaris dom0, virtd runs as a privilege barrier: all libvirt connections are routed through it, and it performs the relevant privilege checks for any clients. When reposting a patch, please say a few words about what you've changed since the previous, the more the better ;-) That helps everyone involved. Sorry, I was being unnecessarily brief to say the least. I believe this addresses all Dan's review comments, and picks up his suggestion of declining the Xen driver to non-daemon users. An additional change I forgot to mention was the dropping of the sigpipe handling in virsh - I hadn't noticed that behaviour has changed since 0.4.0, and the connection failure happens much earlier now. regards, john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fix vm define error with back compat console device
On Thu, Jan 15, 2009 at 07:55:52PM +0100, Jim Meyering wrote: Cole Robinson crobi...@redhat.com wrote: If you define a domain with serial devs 0 parallel devs = serial devs, libvirtd segfaults when trying to set up the back compat console device. We were using a previous loop counter where we shouldn't. The attached patch fixes this. Thanks, Cole diff --git a/src/domain_conf.c b/src/domain_conf.c index 8bb51f7..890afe0 100644 --- a/src/domain_conf.c +++ b/src/domain_conf.c @@ -3320,8 +3320,9 @@ char *virDomainDefFormat(virConnectPtr conn, if (virDomainChrDefFormat(conn, buf, def-console, console) 0) goto cleanup; } else if (def-nserials != 0) { -/* ..else for legacy compat duplicate the serial device as a console */ -if (virDomainChrDefFormat(conn, buf, def-serials[n], console) 0) +/* ..else for legacy compat duplicate the first serial device as a + * console */ +if (virDomainChrDefFormat(conn, buf, def-serials[0], console) 0) goto cleanup; } Hi Cole, ACK! This looks like an obviously-right fix. Thanks for the sample input file you provided, I confirmed and used it to write a test case that demonstrates the problem. With the following test, running this command, make check -C tests TESTS=define-dev-segfault VERBOSE=yes would fail with output including this: + libvirtd + virsh --connect qemu:///session define devs.xml Shouldn't use qemu:///session for test cases like this - this is what the test:///default driver is for, avoiding the fragility danger of using the daemon live hypervisor drivers. +# Domain definition from Cole Robinson. +cat \EOF devs.xml || fail=1 +domain type='kvm' +nameD/name +uuidaaa3ae22-fed2-bfbd-ac02-3bea3bcfad82/uuid +memory262144/memory +currentMemory262144/currentMemory +vcpu1/vcpu +os +type arch='i686' machine='pc'hvm/type +boot dev='cdrom'/ +/os +features +acpi/ +/features +clock offset='utc'/ +on_poweroffdestroy/on_poweroff +on_rebootrestart/on_reboot +on_crashdestroy/on_crash +devices +emulator/usr/bin/qemu-kvm/emulator +disk type='file' device='cdrom' + target dev='hdc' bus='ide'/ + readonly/ +/disk +disk type='file' device='floppy' + target dev='fdb' bus='fdc'/ +/disk +disk type='file' device='cdrom' +target dev='sda' bus='scsi'/ +readonly/ +/disk +interface type='network' +mac address='54:52:00:6c:a0:ca'/ +source network='aa'/ +/interface +interface type='network' +mac address='54:52:00:6c:bb:ca'/ +source network='default'/ +/interface +serial type='pty'/ +serial type='pty'/ +serial type='pty'/ +parallel type='pty'/ +parallel type='pty'/ +parallel type='pty'/ +input type='mouse' bus='ps2'/ +sound model='pcspk'/ +sound model='es1370'/ +hostdev mode='subsystem' type='usb' +source +address bus='3' device='3'/ +/source +/hostdev +hostdev mode='subsystem' type='usb' +source +vendor id='0x0483'/ +product id='0x2016'/ +/source +/hostdev +/devices +/domain +EOF Can you pass that XML through xmllint -format so is has more readable indentation - good to remove all the disk/interface/hostdev devices too, since they're not relevant to the test in question. +libvirtd log 21 pid=$! +sleep 1 No need for the libvirtd daemon if using the test driver. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 1/25: Implement virKill for Win32
On Thu, Jan 15, 2009 at 04:52:26PM +, Richard W.M. Jones wrote: On Tue, Jan 13, 2009 at 05:38:11PM +, Daniel P. Berrange wrote: This patches provides a minimal implementation for virKill on Win32. We don't particularly need this, but it avoids a need to #ifdef out code elsewhere and may come in handy. util.c | 45 + 1 file changed, 45 insertions(+) +1. Committed this patch. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 2/25: Internal threads APIs + impl
On Thu, Jan 15, 2009 at 04:55:26PM +, Richard W.M. Jones wrote: +1 to this. Implementation looks reasonable, and I agree with your decision not to use win32-pthreads. Thanks, committed this one. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 4/25: Cleanup exit paths in remote driver
On Thu, Jan 15, 2009 at 03:41:35PM +0100, Jim Meyering wrote: Daniel P. Berrange berra...@redhat.com wrote: On Wed, Jan 14, 2009 at 10:41:50PM +, Daniel P. Berrange wrote: On Wed, Jan 14, 2009 at 08:39:02PM +0100, Jim Meyering wrote: Daniel P. Berrange berra...@redhat.com wrote: This patch ensures all public API methods only have a single exit path, to make mutex unlocking simpler. remote_internal.c | 1256 +++--- Hi Dan, I got about halfway through it and spotted something odd: diff --git a/src/remote_internal.c b/src/remote_internal.c ... static int remoteDomainGetSchedulerParameters (virDomainPtr domain, virSchedParameterPtr params, int *nparams) ... +cleanup: xdr_free ((xdrproc_t) xdr_remote_domain_get_scheduler_parameters_ret, (char *) ret); -return 0; +if (rv != 0) { +for ( ; i = 0 ; i--) +VIR_FREE(params[i].field); +} + +done: +return rv; } Freeing the .field member looks bogus. Hmmm, not sure why I added that - I must have been thinking it was a malloc'd char * at the time. Clearly bogus Updated to remove that bogus chunk. ACK to that. I confirmed it removes just those 6 lines and updated the git patch to match. Comitted this patch now. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 7/25: Minor windows fix to remote driver
On Thu, Jan 15, 2009 at 03:29:27PM +0100, Jim Meyering wrote: Daniel P. Berrange berra...@redhat.com wrote: Minor problem in the remote driver when lacking support for virExec(), we report an error and then carry on executing anyway. Of course we get a EINVAL error later when we try to write() on a FD of -1. Trivial fix remote_internal.c |1 + 1 file changed, 1 insertion(+) Daniel diff --git a/src/remote_internal.c b/src/remote_internal.c --- a/src/remote_internal.c +++ b/src/remote_internal.c @@ -690,6 +690,7 @@ doRemoteOpen (virConnectPtr conn, case trans_ext: error (conn, VIR_ERR_INVALID_ARG, _(transport methods unix, ssh and ext are not supported under Windows)); +goto failed; ACK. an obvious improvement. Comitted this. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] NULL deref in xenStoreDomainReleased()
I got a crash with this stack: - lwp# 1 / thread# 1 7f312a6c xenStoreDomainReleased () + 24 7f312774 xenStoreWatchEvent () + 6c 004181fb virEventDispatchHandles () + 4cb 00418651 virEventRunOnce () + 139 0041bc1e qemudOneLoop () + e 0041be7b qemudRunLoop () + 13b 0041dd43 main () + 6cb 00416f1c () It looks to me like activeDomainList became NULL. But we've already removed this watch by this point in xenStoreClose(). I'm not au fait with the event locking - does the watch removal need the event lock, or something? thanks john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fix vm define error with back compat console device
Daniel P. Berrange berra...@redhat.com wrote: ... + virsh --connect qemu:///session define devs.xml Shouldn't use qemu:///session for test cases like this - this is what the test:///default driver is for, avoiding the fragility danger of using the daemon live hypervisor drivers. There's no failure with test:///default. But I'll adjust it to use the new unix_sock_dir config option I proposed. However, when run by root, it'll still leave logs in the wrong place, which is currently hard-coded, so I'll have to do more. Either add a config. directive to change the root (log/sockdir,etc) directory, or yet another config setting, just for the log. Preference: log_dir or log_file? Can you pass that XML through xmllint -format so is has more Good idea. Done. readable indentation - good to remove all the disk/interface/hostdev devices too, since they're not relevant to the test in question. too much hubris ;-) Done, too. +libvirtd log 21 pid=$! +sleep 1 No need for the libvirtd daemon if using the test driver. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 3/25: Remove use of macros from remote driver
Daniel P. Berrange berra...@redhat.com wrote: On Wed, Jan 14, 2009 at 02:29:14PM +0100, Jim Meyering wrote: Daniel P. Berrange berra...@redhat.com wrote: ... No, they are all correct AFAIK. The *existing* code was buggy using the wrong macros in many places. ... You need to compare with the function context shown in the patch, rather than assume the original code was correct :-) Yeah, assuming can cause trouble ;-) It would help others down the road if there were a note in the ChangeLog that this change set also fixes several bugs. I comitted this in two parts, the first doing the bug fix. Thanks! FYI, I've rebased the git tree. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] patch queue: bridge-script
# HG changeset patch # User john.le...@sun.com # Date 1232052415 28800 # Node ID 04139c088854c23dc548c0f9f4abf54c4ed07e0d # Parent 253da3acb103a4ce764cb8192a65a4d51833c2f1 patch queue: bridge-script diff --git a/src/domain_conf.c b/src/domain_conf.c --- a/src/domain_conf.c +++ b/src/domain_conf.c @@ -276,6 +276,7 @@ void virDomainNetDefFree(virDomainNetDef case VIR_DOMAIN_NET_TYPE_BRIDGE: VIR_FREE(def-data.bridge.brname); +VIR_FREE(def-data.bridge.script); break; } @@ -877,7 +878,8 @@ virDomainNetDefParseXML(virConnectPtr co VIR_FREE(ifname); } } else if ((script == NULL) - (def-type == VIR_DOMAIN_NET_TYPE_ETHERNET) + (def-type == VIR_DOMAIN_NET_TYPE_ETHERNET || +def-type == VIR_DOMAIN_NET_TYPE_BRIDGE) xmlStrEqual(cur-name, BAD_CAST script)) { script = virXMLPropString(cur, path); } else if (xmlStrEqual (cur-name, BAD_CAST model)) { @@ -928,6 +930,10 @@ virDomainNetDefParseXML(virConnectPtr co } def-data.bridge.brname = bridge; bridge = NULL; +if (script != NULL) { +def-data.bridge.script = script; +script = NULL; +} break; case VIR_DOMAIN_NET_TYPE_CLIENT: @@ -2864,6 +2870,9 @@ virDomainNetDefFormat(virConnectPtr conn case VIR_DOMAIN_NET_TYPE_BRIDGE: virBufferEscapeString(buf, source bridge='%s'/\n, def-data.bridge.brname); +if (def-data.bridge.script) +virBufferEscapeString(buf, script path='%s'/\n, + def-data.bridge.script); break; case VIR_DOMAIN_NET_TYPE_SERVER: diff --git a/src/domain_conf.h b/src/domain_conf.h --- a/src/domain_conf.h +++ b/src/domain_conf.h @@ -153,6 +153,7 @@ struct _virDomainNetDef { } network; struct { char *brname; +char *script; } bridge; } data; char *ifname; diff --git a/src/xend_internal.c b/src/xend_internal.c --- a/src/xend_internal.c +++ b/src/xend_internal.c @@ -58,6 +58,12 @@ #define XEN_SCHED_CRED_NPARAM 2 #endif /* PROXY */ + +#ifdef __sun +#define DEFAULT_VIF_SCRIPT vif-vnic +#else +#define DEFAULT_VIF_SCRIPT vif-bridge +#endif /** * xend_connection_type: @@ -1775,15 +1781,22 @@ xenDaemonParseSxprNets(virConnectPtr con if (VIR_ALLOC(net) 0) goto no_memory; -if ((tmp2 strstr(tmp2, bridge)) || tmp) { +if (tmp != NULL || (STREQ(tmp2, DEFAULT_VIF_SCRIPT))) { net-type = VIR_DOMAIN_NET_TYPE_BRIDGE; /* XXX virtual network reverse resolve */ if (tmp !(net-data.bridge.brname = strdup(tmp))) goto no_memory; +if (tmp2 +net-type == VIR_DOMAIN_NET_TYPE_BRIDGE +!(net-data.bridge.script = strdup(tmp2))) +goto no_memory; } else { net-type = VIR_DOMAIN_NET_TYPE_ETHERNET; +if (tmp2 +!(net-data.ethernet.script = strdup(tmp2))) +goto no_memory; } tmp = sexpr_node(node, device/vif/vifname); @@ -1820,11 +1833,6 @@ xenDaemonParseSxprNets(virConnectPtr con tmp = sexpr_node(node, device/vif/ip); if (tmp !(net-data.ethernet.ipaddr = strdup(tmp))) -goto no_memory; - -if (tmp2 -net-type == VIR_DOMAIN_NET_TYPE_ETHERNET -!(net-data.ethernet.script = strdup(tmp2))) goto no_memory; if (model @@ -5093,6 +5101,8 @@ xenDaemonFormatSxprNet(virConnectPtr con int xendConfigVersion, int isAttach) { +const char *script = DEFAULT_VIF_SCRIPT; + if (def-type != VIR_DOMAIN_NET_TYPE_BRIDGE def-type != VIR_DOMAIN_NET_TYPE_NETWORK def-type != VIR_DOMAIN_NET_TYPE_ETHERNET) { @@ -5114,7 +5124,10 @@ xenDaemonFormatSxprNet(virConnectPtr con switch (def-type) { case VIR_DOMAIN_NET_TYPE_BRIDGE: virBufferVSprintf(buf, (bridge '%s'), def-data.bridge.brname); -virBufferAddLit(buf, (script 'vif-bridge')); +if (def-data.bridge.script) +script = def-data.bridge.script; + +virBufferVSprintf(buf, (script '%s'), script); break; case VIR_DOMAIN_NET_TYPE_NETWORK: @@ -5137,7 +5150,7 @@ xenDaemonFormatSxprNet(virConnectPtr con return -1; } virBufferVSprintf(buf, (bridge '%s'), bridge); -virBufferAddLit(buf, (script 'vif-bridge')); +virBufferVSprintf(buf, (script '%s'), script); VIR_FREE(bridge); } break; diff --git a/src/xm_internal.c b/src/xm_internal.c
[libvirt] [PATCH] Parse ipaddr for bridge network types
# HG changeset patch # User john.le...@sun.com # Date 1232054247 28800 # Node ID 2b8a53968637c1ba806a1cdd94a24f4d15f8072a # Parent 04139c088854c23dc548c0f9f4abf54c4ed07e0d Parse ipaddr for bridge network types As well as supporting round-tripping of the IP address, this fixes a leak if ipaddr was specified in the Xen domain config. Signed-off-by: John Levon john.le...@sun.com diff --git a/src/domain_conf.c b/src/domain_conf.c --- a/src/domain_conf.c +++ b/src/domain_conf.c @@ -277,6 +277,7 @@ void virDomainNetDefFree(virDomainNetDef case VIR_DOMAIN_NET_TYPE_BRIDGE: VIR_FREE(def-data.bridge.brname); VIR_FREE(def-data.bridge.script); +VIR_FREE(def-data.bridge.ipaddr); break; } @@ -867,7 +868,8 @@ virDomainNetDefParseXML(virConnectPtr co address = virXMLPropString(cur, address); port = virXMLPropString(cur, port); } else if ((address == NULL) - (def-type == VIR_DOMAIN_NET_TYPE_ETHERNET) + (def-type == VIR_DOMAIN_NET_TYPE_ETHERNET || +def-type == VIR_DOMAIN_NET_TYPE_BRIDGE) (xmlStrEqual(cur-name, BAD_CAST ip))) { address = virXMLPropString(cur, address); } else if ((ifname == NULL) @@ -933,6 +935,10 @@ virDomainNetDefParseXML(virConnectPtr co if (script != NULL) { def-data.bridge.script = script; script = NULL; +} +if (address != NULL) { +def-data.bridge.ipaddr = address; +address = NULL; } break; @@ -2870,6 +2876,9 @@ virDomainNetDefFormat(virConnectPtr conn case VIR_DOMAIN_NET_TYPE_BRIDGE: virBufferEscapeString(buf, source bridge='%s'/\n, def-data.bridge.brname); +if (def-data.bridge.ipaddr) +virBufferVSprintf(buf, ip address='%s'/\n, + def-data.bridge.ipaddr); if (def-data.bridge.script) virBufferEscapeString(buf, script path='%s'/\n, def-data.bridge.script); diff --git a/src/domain_conf.h b/src/domain_conf.h --- a/src/domain_conf.h +++ b/src/domain_conf.h @@ -154,6 +154,7 @@ struct _virDomainNetDef { struct { char *brname; char *script; +char *ipaddr; } bridge; } data; char *ifname; diff --git a/src/xend_internal.c b/src/xend_internal.c --- a/src/xend_internal.c +++ b/src/xend_internal.c @@ -1792,10 +1792,18 @@ xenDaemonParseSxprNets(virConnectPtr con net-type == VIR_DOMAIN_NET_TYPE_BRIDGE !(net-data.bridge.script = strdup(tmp2))) goto no_memory; +tmp = sexpr_node(node, device/vif/ip); +if (tmp +!(net-data.bridge.ipaddr = strdup(tmp))) +goto no_memory; } else { net-type = VIR_DOMAIN_NET_TYPE_ETHERNET; if (tmp2 !(net-data.ethernet.script = strdup(tmp2))) +goto no_memory; +tmp = sexpr_node(node, device/vif/ip); +if (tmp +!(net-data.ethernet.ipaddr = strdup(tmp))) goto no_memory; } @@ -1829,11 +1837,6 @@ xenDaemonParseSxprNets(virConnectPtr con net-mac[4] = mac[4]; net-mac[5] = mac[5]; } - -tmp = sexpr_node(node, device/vif/ip); -if (tmp -!(net-data.ethernet.ipaddr = strdup(tmp))) -goto no_memory; if (model !(net-model = strdup(model))) @@ -5128,6 +5131,8 @@ xenDaemonFormatSxprNet(virConnectPtr con script = def-data.bridge.script; virBufferVSprintf(buf, (script '%s'), script); +if (def-data.bridge.ipaddr != NULL) +virBufferVSprintf(buf, (ip '%s'), def-data.bridge.ipaddr); break; case VIR_DOMAIN_NET_TYPE_NETWORK: diff --git a/src/xm_internal.c b/src/xm_internal.c --- a/src/xm_internal.c +++ b/src/xm_internal.c @@ -1086,6 +1086,9 @@ xenXMDomainConfigParse(virConnectPtr con if (script[0] !(net-data.bridge.script = strdup(script))) goto no_memory; +if (ip[0] +!(net-data.bridge.ipaddr = strdup(ip))) +goto no_memory; } else { if (script[0] !(net-data.ethernet.script = strdup(script))) @@ -1822,6 +1825,8 @@ static int xenXMDomainConfigFormatNet(vi switch (net-type) { case VIR_DOMAIN_NET_TYPE_BRIDGE: virBufferVSprintf(buf, ,bridge=%s, net-data.bridge.brname); +if (net-data.bridge.ipaddr) +virBufferVSprintf(buf, ,ip=%s, net-data.bridge.ipaddr); break;
[libvirt] sharing multiple identical USB devices?
Hi, I have Windows XP running on Fedora 10. I can successfully share a single USB-to-RS232 converter by inserting this in my xml file: hostdev mode='subsystem' type='usb' source vendor id='0x0403'/ product id='0x6001'/ /source /hostdev However, I can't seem to get two of these to work at the same time. I want to do: hostdev mode='subsystem' type='usb' source vendor id='0x0403'/ product id='0x6001'/ address bus='0x03' device='0x02'/ /source /hostdev hostdev mode='subsystem' type='usb' source vendor id='0x0403'/ product id='0x6001'/ address bus='0x03' device='0x03'/ /source /hostdev using the address stanza to identify the devices uniquely, but it just doesn't work. Is this a bug, or am I doing something wrong? With the two device setup, Windows still only assigns one serial port to one of the devices, and none to the other. - Mike -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fix vm define error with back compat console device
On Thu, Jan 15, 2009 at 10:17:56PM +0100, Jim Meyering wrote: Daniel P. Berrange berra...@redhat.com wrote: ... + virsh --connect qemu:///session define devs.xml Shouldn't use qemu:///session for test cases like this - this is what the test:///default driver is for, avoiding the fragility danger of using the daemon live hypervisor drivers. There's no failure with test:///default. I'm rather surprised at that - both drivers use identical XML formating routines here, so given the same config, both should fail just as badly. Is this perhaps a case where we need to run it under valgrind to make it reliably fail. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] RFC: configuring host interfaces with libvirt
For certain applications, we want libvirt to be able to configure host network interfaces in a variety of ways; currently, we are most interested in teaching libvirt how to set up ordinary ethernet interfaces, bridges, bonding and vlan's. Below is a high-level proposal of how that could be done. Please comment copiously ;) 1. XML Format = The first question is how the user would describe the host interfaces they want. Below are some sketches of what an XML representation of the various kinds of interfaces would look like. This covers the minimal amount of settings for these to be useful, though I am sure we'll need to add more over time. interface device=eth0 onboot=yes hwaddr00:19:d2:9f:88:96/hwaddr dhcp peerdns=yes/ /interface interface device=eth1 onboot=yes hwaddr00:19:d2:9f:88:97/hwaddr static ipaddr=192.168.0.5 gateway=192.168.0.1 netmask=255.255.255.0/ /interface interface device=eth2 onboot=yes hwaddr00:19:d2:9f:88:98/hwaddr /interface bond name=bond00 onboot=yes mode=active-backup slave device=eth0 primary=yes/ slave device=eth1/ /bond bridge name=br0 stp=off onboot=yes member device=eth2/ dhcp peerdns=yes/ /bridge vlan device=eth0 tag=42 reorder_hdr=yes/ All of these should also allow a uuid element for specifying a uuid; I omitted that for brevity. 2. API Changes == There are two options for dealing with network interfaces: (1) use the existing virNetwork* calls or (2) add completely new API calls. Repurposing existing virNetwork* calls -- The existing calls map well to the operations we need for managing interfaces, with a few exceptions: - virNetworkGetAutostart/SetAutostart: depending on how we implement all this (see below), 'autostart' might actually mean 'on boot', not 'when libvirtd starts' - virNetworkGetBridgeName doesn't make sense for interfaces, and should return NULL for interfaces We'll probably also end up adding some functions to query details about an interface, in particular, a call to see what kind of network/interface a virNetworkPtr represents Add completely new virInterface* calls -- This would add roughly the same API calls as the virNetwork* calls, i.e. we'd have something like typedef struct virInterface *virInterfacePtr; int virInterfaceCreate(virInterfacePtr); virInterfacePtr virInterfaceCreateXML(..); ... plus some calls to extract information from a virInterfacePtr The second option seems cleaner to me and easier to implement, and avoids any subtle changes in the behavior of existing API, though I don't like that we'll be adding another 20 or so calls to libvirt's public API, with attendant churn both in the drivers and in virsh. 3. Implementation = Configuring network interfaces is highly OS and OS-variant/distro dependant. There are at least two different ways how libvirt can go about modifying the host to create interfaces: 1. Modify the system's network setup scripts (ifcfg-XXX on RH) 2. Directly use the system's network utilities like ifconfig 3. Rely on NetworkManager (not an option right now, as NM doesn't know about bridges and the like) Option (1) saves us from replicating every bit of network setup functionality that those scripts already have - besides configuring the interface, we also might have to setup routes, run dhclient etc. Option (2) would require far fewer backend implementations than (1) - we should be able to get away with one implementation for Linux, rather than one for Fedora/RHEL, one for Debian, one for SuSe, three for gentoo etc. If we want 'autostart' for an interface to mean 'bring up the interface as soon as the system boots', we are pretty much forced to go with option (1). All in all, option (1) seems more attractive, since it should save us from dealing with a lot of low-level details of network setup, and the distro scripts should be much better integrated with the rest of the system than what we come up with for libvirt. 4. Misc issues == * Should interfaces have labels/roles ('data-interface') to help admins make sense of the current config ? * Do we expect interfaces to be in a specific state before we create them or do we just tear them down and reconfigure them no matter what ? * Are there crucial config options that are not covered by the sketches above (e.g., setting an explicit MTU) ? Are there things in the XML sketches above that will be impossible to implement on some OS ? * Should this even be done as part of libvirt ? It seems like a very generic network config tool, and libvirt merely the conduit to exposing this through an API, most importantly, a remotable API. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: configuring host interfaces with libvirt
On Fri, Jan 16, 2009 at 01:13:18AM +, David Lutterkort wrote: * Should this even be done as part of libvirt ? It seems like a very generic network config tool, and libvirt merely the conduit to exposing this through an API, most importantly, a remotable API. My humble opinion would be no. This argument equally applies to everything you could configure on a host, and I don't think anyone wants to turn libvirt into libmanagement. Would it be feasible for libvirtd to have a 'passthrough' mode that feeds unknown stuff off to some other daemon? Especially in this case - interface management is very complex as you note. regards john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: configuring host interfaces with libvirt
On Fri, 2009-01-16 at 01:26 +, John Levon wrote: On Fri, Jan 16, 2009 at 01:13:18AM +, David Lutterkort wrote: * Should this even be done as part of libvirt ? It seems like a very generic network config tool, and libvirt merely the conduit to exposing this through an API, most importantly, a remotable API. My humble opinion would be no. This argument equally applies to everything you could configure on a host, and I don't think anyone wants to turn libvirt into libmanagement. Would it be feasible for libvirtd to have a 'passthrough' mode that feeds unknown stuff off to some other daemon? Especially in this case - interface management is very complex as you note. I am not disagreeing with you, but either way, libvirt needs _some_ way to control host interfaces. And seeing how there are no tools that do something like the above in a portable way, it seems worthwhile, too. The question is probably more whether some of this functionality should be split out in a way that can be used independenty of libvirt. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Fine grained Access Control in libVirt
Hi, Dan Would you explain the difference with sVirt? The final goal sVirt seems same form me. (for example, define many security domain etc in .te file.) Or it just a little changes from sVirt implementation? Thanks Atsushi SAKAI Daniel P. Berrange berra...@redhat.com wrote: On Thu, Jan 15, 2009 at 02:39:20PM +0100, Konrad Eriksson1 wrote: After some background research it doesn't look like anyone have taken on the task yet to add fine-grained access control to libVirt (only option right now is R/W or RO mode). Desired is an addition to libVirt that enables access control on individual actions and data that can be accessed through the library API. This could take the form of an AC-module that, based on the identity of the caller, checks each call and grants/denies access to carry out the action (could also take parameters in account) and optionally filter the return data. The AC-module could then interface different backend AC solutions (SELinux, RBAC, ...) or alternatively implement an internal scheme. When looking at the libvirt core and driver framework it seems promising to inject these kind of call-out hooks either in libvirt.c or between libvirt.c and the underlying drivers, by doing this AC will be enforced independent of if a local or remote call is done to libVirt. I propose an approach to create an AC-module that conforms to the driver API in libVirt and to inject it in the call-path between libvirt.c and the driver(s) to enable the AC-module to inspect the call before sending it to the real driver. Normal call path: user - libvirt.c - driver_x AC-module injected in call path: user - libvirt.c - AC-module - driver_x By doing this it can be loaded/unloaded in run-time and also selectable what driver paths it should enforce (hypervisor(aka. driver), storage, network...). The AC-module can also be made in different flavors for different AC backend (SELinux, RBAC, internal, ...) solutions and the appropriate AC-module could be loaded without needing re-compiling. This approach would also leave a very small footprint in existing libvirt code (only need to inject AC-module driver after normal drivers has been loaded) FYI, I had discussed the alternative approach with Konrad offlist prior to this thread. Namely, instead of having a driver, layered in, put a call to something like virCheckAccess() directly into libvirt.c replacing the RO checks. The complication with doing it this way, is deciding what information to pass to the virCheckAccess methods. Obviously the operation name, and then some context for the object to the be checked. Do we just pass the virDomainPtr in there. Might need the XML for a new domain create call. Might want the other virConnectPtr for a migrate call and so on. Seems like we'd quickly end up having to pass all possible params through to the virCheckAcces method. At which point it really just becomes simpler to layer in the checks via the driver API which already has access to all the neccessary bits of info. So I think its reasonable to have MAC calls stacked into the driver API as Konrad illustrates above. The initial impl would just duplicate our existing RO checks, then we can consider other impls RBAC/SELinux etc Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: configuring host interfaces with libvirt
On Fri, Jan 16, 2009 at 02:59:17AM +, David Lutterkort wrote: I am not disagreeing with you, but either way, libvirt needs _some_ way to control host interfaces. This is far from obvious to me. Could you explain more? regards john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: configuring host interfaces with libvirt
Hi all, I think I agree with David here I think that some method of configuring host network interfaces is inline with configuring CPU or RAM allocations for a guest. You want to provision say, a new server, you might want to add a tagged VLAN bridge for it to sit off as well. Or perhaps establish a private bridge or subnet for it. At the moment, you have to set that up manually. While it can be easily standardized ( I think ) - there are some complexities ( ie MTU settings - jumbo frames, or allowing for tagged vlan overhead without appropriate hardware.. ). Am I inline with your thinkings, David? ;) cheers; //Chris - Original Message - From: John Levon le...@movementarian.org To: David Lutterkort lut...@redhat.com Cc: libvir-list@redhat.com Sent: Friday, 16 January, 2009 12:29:43 PM GMT +08:00 Beijing / Chongqing / Hong Kong / Urumqi Subject: Re: [libvirt] RFC: configuring host interfaces with libvirt On Fri, Jan 16, 2009 at 02:59:17AM +, David Lutterkort wrote: I am not disagreeing with you, but either way, libvirt needs _some_ way to control host interfaces. This is far from obvious to me. Could you explain more? regards john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Avoid passing NULL to printf %s specifier
On Thu, Jan 15, 2009 at 07:19:33AM -0800, john.le...@sun.com wrote: # HG changeset patch # User john.le...@sun.com # Date 1232032750 28800 # Node ID 0335828806b5b3855c8eeaee31446a7bd0c02974 # Parent e542223a4c52d978d4507de709f50885920a5b44 Avoid passing NULL to printf %s specifier ACK, please push :-) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Solaris least privilege support
On Thu, Jan 15, 2009 at 09:19:39AM -0800, john.le...@sun.com wrote: # HG changeset patch # User john.le...@sun.com # Date 1232039546 28800 # Node ID b9d4d60bca87633897cb133461e1415d1223c823 # Parent 25a0c46588d5de1653b16dfed6bc357abf11db77 Solaris least privilege support On Solaris dom0, virtd runs as a privilege barrier: all libvirt connections are routed through it, and it performs the relevant privilege checks for any clients. This looks fine to me except that chunk: @@ -2417,6 +2493,20 @@ int main(int argc, char **argv) { sig_action.sa_handler = SIG_IGN; sigaction(SIGPIPE, sig_action, NULL); +/* Change the group ownership of /var/run/libvirt to unix_sock_gid */ +if (geteuid () == 0) { +const char *rundir = LOCAL_STATE_DIR /run/libvirt; + +if (mkdir (rundir, 0755)) { +if (errno != EEXIST) { +VIR_ERROR0 (_(unable to create rundir)); +return (-1); +} +} +} + +qemudSetupPrivs(server); + The comment and the code don't seems to match, and it seems to me that this code would fail except in the first time the daemon is launched because mkdir /var/run/libvirt will return -1 and errno EEXIST in all following cases. I'm worried about this, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fix vm define error with back compat console device
On Fri, Jan 16, 2009 at 12:09:33AM +, Daniel P. Berrange wrote: On Thu, Jan 15, 2009 at 10:17:56PM +0100, Jim Meyering wrote: Daniel P. Berrange berra...@redhat.com wrote: ... + virsh --connect qemu:///session define devs.xml Shouldn't use qemu:///session for test cases like this - this is what the test:///default driver is for, avoiding the fragility danger of using the daemon live hypervisor drivers. There's no failure with test:///default. I'm rather surprised at that - both drivers use identical XML formating routines here, so given the same config, both should fail just as badly. Is this perhaps a case where we need to run it under valgrind to make it reliably fail. Maybe that can be debugged separately, I would like to see the patch fixed, maybe we can isolate the problem in the test driver (if any) but it should not block the initial patch from being commited, thanks, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list