Re: [libvirt] [PATCH] Improve xend_get error message

2009-01-15 Thread Daniel P. Berrange
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

2009-01-15 Thread Daniel P. Berrange
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

2009-01-15 Thread Richard W.M. Jones
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

2009-01-15 Thread Richard W.M. Jones
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

2009-01-15 Thread John Levon
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

2009-01-15 Thread Daniel P. Berrange
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

2009-01-15 Thread John Levon
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

2009-01-15 Thread Richard W.M. Jones
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

2009-01-15 Thread John Levon
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

2009-01-15 Thread Daniel P. Berrange
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

2009-01-15 Thread Daniel P. Berrange
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

2009-01-15 Thread Konrad Eriksson1
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

2009-01-15 Thread Richard W.M. Jones
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

2009-01-15 Thread Daniel P. Berrange
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

2009-01-15 Thread John Levon
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

2009-01-15 Thread Richard W.M. Jones
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

2009-01-15 Thread Richard W.M. Jones
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

2009-01-15 Thread John Levon
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

2009-01-15 Thread John Levon
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

2009-01-15 Thread Daniel P. Berrange
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

2009-01-15 Thread John Levon
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

2009-01-15 Thread Daniel Veillard
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

2009-01-15 Thread Daniel P. Berrange
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

2009-01-15 Thread Jim Meyering
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

2009-01-15 Thread Daniel Veillard
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

2009-01-15 Thread Daniel P. Berrange
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

2009-01-15 Thread Jim Meyering
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

2009-01-15 Thread Daniel Veillard
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

2009-01-15 Thread Jim Meyering
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

2009-01-15 Thread Jim Meyering
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

2009-01-15 Thread John Levon
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

2009-01-15 Thread John Levon
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

2009-01-15 Thread Daniel Veillard
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

2009-01-15 Thread Daniel P. Berrange
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

2009-01-15 Thread john . levon
# 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

2009-01-15 Thread Daniel Veillard
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

2009-01-15 Thread Daniel P. Berrange
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

2009-01-15 Thread Richard W.M. Jones
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

2009-01-15 Thread Daniel P. Berrange
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

2009-01-15 Thread John Levon
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

2009-01-15 Thread Richard W.M. Jones
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

2009-01-15 Thread Richard W.M. Jones
+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

2009-01-15 Thread Richard W.M. Jones
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

2009-01-15 Thread Richard W.M. Jones
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

2009-01-15 Thread Richard W.M. Jones
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()

2009-01-15 Thread Richard W.M. Jones
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

2009-01-15 Thread Richard W.M. Jones
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

2009-01-15 Thread john . levon
# 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

2009-01-15 Thread Richard W.M. Jones
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

2009-01-15 Thread Daniel P. Berrange
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

2009-01-15 Thread Richard W.M. Jones
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

2009-01-15 Thread Richard W.M. Jones
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

2009-01-15 Thread Richard W.M. Jones
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

2009-01-15 Thread Richard W.M. Jones
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

2009-01-15 Thread Cole Robinson
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

2009-01-15 Thread Richard W.M. Jones
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()

2009-01-15 Thread Richard W.M. Jones
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

2009-01-15 Thread Jim Meyering
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

2009-01-15 Thread Jim Meyering
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

2009-01-15 Thread John Levon
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

2009-01-15 Thread Daniel P. Berrange
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

2009-01-15 Thread Daniel P. Berrange
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

2009-01-15 Thread Daniel P. Berrange
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

2009-01-15 Thread Daniel P. Berrange
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

2009-01-15 Thread Daniel P. Berrange
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()

2009-01-15 Thread John Levon

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

2009-01-15 Thread Jim Meyering
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

2009-01-15 Thread Jim Meyering
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

2009-01-15 Thread john . levon
# 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

2009-01-15 Thread john . levon
# 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?

2009-01-15 Thread Dr. Michael J. Chudobiak

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

2009-01-15 Thread Daniel P. Berrange
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

2009-01-15 Thread David Lutterkort
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

2009-01-15 Thread John Levon
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

2009-01-15 Thread David Lutterkort
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

2009-01-15 Thread Atsushi SAKAI
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

2009-01-15 Thread John Levon
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

2009-01-15 Thread Chris Hoy Poy
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

2009-01-15 Thread Daniel Veillard
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

2009-01-15 Thread Daniel Veillard
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

2009-01-15 Thread Daniel Veillard
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