Re: [libvirt] [PATCH] fix MinGW compilation(200808)

2008-08-11 Thread Atsushi SAKAI
Hi, Jim

I am looking around the code about WEXITSTATUS.
It seems that following kind of code needs on gnulib.
http://kerneltrap.org/mailarchive/git/2008/2/27/1003054
What do you think?

Thanks
Atsushi SAKAI



Atsushi SAKAI [EMAIL PROTECTED] wrote:

 Hi, Dan
 
 mkstemp is solved by Jim.
 
 But WEXITSTATUS problem is not solved yet.
 Since sys/wait.h does not exist on MinGW.
 http://www.mingw.org/MinGWiki/index.php/PortingChildren
 
 Thanks
 Atsushi SAKAI
 
 
 
 
 Daniel P. Berrange [EMAIL PROTECTED] wrote:
 
  On Thu, Aug 07, 2008 at 05:56:48PM +0900, Atsushi SAKAI wrote:
   Hi, Jim
   
   Your patch works fine. It passes inet_pton problem.
   Please apply it.
   
   By the way, virsh compilation error.
   Is threre any good suggestion?
   =
   virsh-virsh.o: In function `editWriteToTempFile':
   C:/msys/1.0/home/Administrator/work/libvirt/src/virsh.c:5080: undefined 
   reference to `mkstemp'
  
  Look like there is a gnulib module for that - Jim could say if its license
  compatible
  
   virsh-virsh.o: In function `editFile':
   C:/msys/1.0/home/Administrator/work/libvirt/src/virsh.c:5155: undefined 
   reference to `WEXITSTATUS'
  
  virsh.c seems to be missing  '#include sys/wait.h'
  
  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: [et-mgmt-tools] Re: [libvirt] RE: [Qemu-devel] [ANNOUNCE] virt-mem tools version 0.2.8 released

2008-08-11 Thread Jamie Lokier
Javier Guerra wrote:
 On Thu, Aug 7, 2008 at 8:06 AM, Richard W.M. Jones [EMAIL PROTECTED] wrote:
  I think the message here is, install libvirt  be happy :-)
 
 nice as this tool sounds, i would need far more than this to make me
 switch from a simple, easily scriptable command-line to a generic,
 'lowest common', solution like libvirt.
 
 of course, i hope it keeps getting better.  who knows? maybe in a year
 or so it would be comparable to the CLI.

Regrettably I agree for the moment.

I ended up writing a Perl management script for my KVM VMs because
libvirt was just too muddled and limited for my needs, and because the
config file format confused me, didn't handle everything I needed, and
I didn't find clear documentation on it.

Also, I wanted to import existing guests from another VM, and
libvirt's tools seemed strongly geared around creating new VMs to use
with libvirt.  So I had to write config files for it - see above.

I like the idea of libvirt a lot and wish it well.

My own Perl script was a nightmare to write even though it's not so
long (synchronisation  monitor issues especially), so I respect
what's done.  It's a good goal.

But I just found it too confusing to use in the ways I needed to use
KVM, that I gave up on libvirt for now rather than spend the
considerable time to get to grips with what it's doing, and it's
config format.

What would be nicer is a VM management protocol build in to QEMU, KVM
and XEN, which is a bit like the monitor, but supports multiple client
connections and overlapping operations (where reasonable), and is a
bit more structured, so e.g. you can get the state of anything whose
state you can set, you can wait for events, etc.  The somewhat
object-based config file work that's been discussed not long ago would
be a good thing to structure it around.

-- Jamie

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] /var/run/libvirt

2008-08-11 Thread Daniel P. Berrange
On Sat, Aug 09, 2008 at 09:56:45AM +0100, Richard W.M. Jones wrote:
 On Fri, Aug 08, 2008 at 12:08:05PM +0200, Stefan de Konink wrote:
  My /var/run is empty upon boot. (ramfs) One may wonder why libvirt needs a
  dedicated directory at all for two sockets...
 
 This seems to be a valid point.
 
 Note that /var/run/libvirt is also used for temporary files, and I
 think some of the hypervisor drivers can put stuff there too, so it
 really does need to be a directory.
 
 Dan/Dan, any reason we can't 'mkdir' this when libvirtd starts up?

Yep, it seems that we do need to make this special case for /var/run/libvirt
because of the tmpfs possibility which isn't handled by make install/RPM

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] make sure we call the freshly build libvirtd

2008-08-11 Thread Daniel P. Berrange
On Fri, Aug 08, 2008 at 06:30:56PM +0200, Jim Meyering wrote:
 Guido Guenther [EMAIL PROTECTED] wrote:
  ...not the one in $PATH. I was wondering why this test kept failing...
 
 You shouldn't need that change, since make check already sets PATH
 so that $abs_top_builddir/qemud is early in PATH.  And it does it
 in such a way that it should work even if the absolute path
 contains shell meta-characters.
 
 Are you trying to run the test manually via ./daemon-conf?
 
 If you want to run just that one test, use this:
 
   make -C tests check TESTS=daemon-conf

FYI, I have been slowly fixing individual tests so that you can run them
directly. I'm fundamentally lazy, so want to be able to just run

   ./daemon-conf

I think all the compiled tests support this now - just the shell based
ones left.

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] fix MinGW compilation(200808)

2008-08-11 Thread Jim Meyering
Atsushi SAKAI [EMAIL PROTECTED] wrote:
 I am looking around the code about WEXITSTATUS.
 It seems that following kind of code needs on gnulib.
 http://kerneltrap.org/mailarchive/git/2008/2/27/1003054
 What do you think?

Hi Atsushi,

Yes, git provides MinGW support, and I see it's compat/mingw.h
includes this line:

#define WEXITSTATUS(x) ((x)  0xff)

Could it be as easy as adding this?

  #ifndef WEXITSTATUS
  # define WEXITSTATUS(x) ((x)  0xff)
  #endif

gnulib provides heavy-weight (different API, and GPL'd) support for
running subprocesses via its execute module, but it targets more
than just MinGW.

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [PATCH] fix MinGW compilation(200808)

2008-08-11 Thread Daniel P. Berrange
On Mon, Aug 11, 2008 at 10:41:43AM +0200, Jim Meyering wrote:
 Atsushi SAKAI [EMAIL PROTECTED] wrote:
  I am looking around the code about WEXITSTATUS.
  It seems that following kind of code needs on gnulib.
  http://kerneltrap.org/mailarchive/git/2008/2/27/1003054
  What do you think?
 
 Hi Atsushi,
 
 Yes, git provides MinGW support, and I see it's compat/mingw.h
 includes this line:
 
 #define WEXITSTATUS(x) ((x)  0xff)
 
 Could it be as easy as adding this?
 
   #ifndef WEXITSTATUS
   # define WEXITSTATUS(x) ((x)  0xff)
   #endif

Just adding that to virsh (or one of the libvirt headers) is fine by me.

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] Ensure parted doesn't prompt if labeling disk

2008-08-11 Thread Jim Meyering
Cole Robinson [EMAIL PROTECTED] wrote:
 Trying to 'build' a disk pool uses 'parted mklabel' which can
 prompt for confirmation. Patch adds the '--script' option to
 remove the chance of this happening.

 diff --git a/src/storage_backend_disk.c b/src/storage_backend_disk.c
 index d6548eb..39b857c 100644
 --- a/src/storage_backend_disk.c
 +++ b/src/storage_backend_disk.c
 @@ -406,6 +406,7 @@ virStorageBackendDiskBuildPool(virConnectPtr conn,
  PARTED,
  pool-def-source.devices[0].path,
  mklabel,
 +--script,
  virStorageBackendDiskPoolFormatToString(conn, 
 pool-def-source.format),
  NULL,
  };

Good change.
ACK.

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [PATCH] Ensure parted doesn't prompt if labeling disk

2008-08-11 Thread Daniel P. Berrange
On Sun, Aug 10, 2008 at 10:40:30PM -0400, Cole Robinson wrote:
 Trying to 'build' a disk pool uses 'parted mklabel' which can
 prompt for confirmation. Patch adds the '--script' option to
 remove the chance of this happening.

Can you double-check this works on RHEL-5 - IIRC, the --script arg is
a fairly recent addition to parted.

 diff --git a/src/storage_backend_disk.c b/src/storage_backend_disk.c
 index d6548eb..39b857c 100644
 --- a/src/storage_backend_disk.c
 +++ b/src/storage_backend_disk.c
 @@ -406,6 +406,7 @@ virStorageBackendDiskBuildPool(virConnectPtr conn,
  PARTED,
  pool-def-source.devices[0].path,
  mklabel,
 +--script,
  virStorageBackendDiskPoolFormatToString(conn, 
 pool-def-source.format),
  NULL,
  };

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] Re: [ANNOUNCE][RFC] sVirt: Integrating SELinux and Linux-based virtualization

2008-08-11 Thread James Morris
On Sun, 10 Aug 2008, Casey Schaufler wrote:

  1.1  Rationale
  
  With increased use of virtualization, one security benefit of
  physically separated systems -- strong isolation -- is reduced,
 
 This issue can always be readily resolved by going back to physically
 separated hardware. The strength of isolation of a virtual machine
 mechanism is one of the important characteristics that should be
 considered when it is chosen over a hardware isolation scheme, but
 the systems available today appear to do a pretty good job on this,
 so I would like to see some evidence of this claim before accepting
 it as a primary premise.

I suspect you misunderstood an important aspect of this in that we are 
targeting Linux-based virtualization, where the VMs are running inside 
Linux processes.  In this case, the isolation depends on DAC in the host, 
and the idea behind sVirt is to apply MAC security to these VMs and their 
resources.

Currently, all such VMs run with the same security label, and all of the 
resources accessed (e.g. disk images) have the same labels.

We are simply proposing a mechanism to allow distinct security labels to 
be applied to these entities, which in the simplest case, will allow MAC 
policy to enforce isolation between them.

 
   an
  issue which may be ameliorated with the application of Mandatory
  Access Control (MAC) security in the host system.  
 
 Ok. I've been using VMs for 30 years and MAC for 20, and to my mind
 the only way this statement can possibly be true is if both the MAC
 system and the VM system are inadequate to their respective tasks.

I'm not sure how you come to the conclusion that the MAC system must be 
inadequate, but this scheme does attempt to improve the robustness of 
isolation between Linux-based VMs.

We're applying the idea of containing applications in the face of 
potential flaws and misconfiguration to the case of applications which 
happen to be VMs.  In this sense, it is not different to containing any 
other form of application (e.g. a flaw in the VM might be exploited by 
malicious code).

  Integration of MAC with virtualization will also help increase the
  overall robustness and security assurance of both host and guest
  systems.  Many threats arising from flaws in the VM environment, or
  misconfiguration, may be mitigated through tighter isolation and
  specific MAC policy enforcement.

 
 You are not going to solve any problems of misconfiguration this way,
 you are just going to make the environment more complicated and prone
 to misconfiguration.

I don't think this is valid as an absolute statement.

e.g. by adding distinct labels to VMs and their resources at the toolchain 
level, the admin will not be involved beyond specifying that the VM is to 
be created as an isolated instance.  The VMs will simply be running with 
different labels and bound to their own resources with those labels, 
enforced by MAC policy.  If an admin manually launches a VM and 
accidentally specifies an incorrect disk image, MAC policy will prevent 
the VM from accessing the image.

There is nothing characteristically different between this and the general 
rationale for MAC in the OS, e.g. to ensure that a web server can only 
serve appropriately labeled content.

The risk that the MAC system itself could be misconfigured does not change 
with sVirt, although in the proposed scheme, VM labeling will be 
automated.

Again, keep in mind that we're talking about Linux-based virtualization, 
where the VM is literally just another application running in the host OS.


 
  By incorporating MAC support into the virtualization toolchain 
  and
  documentation, users will also be able to make more use of the MAC
  security capabilities provided by the OS.

 
 Would you back this assertion? VMs seem no better a vehicle for MAC
 integration than user sessions in any way that I can see.

I don't understand what needs to be backed here.  Currently, MAC is not 
used to separate different Linux-based VMs, and by integrating MAC 
support, people will be able to further utilize MAC.

  
  1.2  Use-cases
  
  The following use-cases have been identified:
o Providing virtualized services with a level of isolation
  similar to that previously afforded by physical separation.

 
 As I mentioned before, this doesn't seem to make any sense. I can
 see the value in running a MAC system under a VM in limited cases,
 but the other way around does not seem particularly rational.

Please be specific: in what way is it not rational?

 
o Increased protection of the host from untrusted VM guests (e.g.
  for VM hosting providers, grid/cloud servers etc.).

 
 I can see where someone who is not familiar with VMs might think
 this is plausible, but looking at the interfaces and separation provided
 by VMs makes it pretty clear that this isn't even a belts and braces
 level of 

Re: [libvirt] [PATCH] Change disk type 'dos' to 'msdos'

2008-08-11 Thread Jim Meyering
Cole Robinson [EMAIL PROTECTED] wrote:
 parted doesn't seem to want the label 'dos', instead
 wanting 'msdos'. Patch is basically s/dos/msdos/

Hi Cole,

This definitely needs to be fixed.

FYI, dos appears to be the preferred name for that partition table type
(google for partition table and either dos or msdos; also, partx
--type accepts dos, not msdos).  Too bad Parted added the ms prefix.
If it's not hard to implement, it would be nice to hide the implementation
detail that Parted happens to call it the msdos label type.

 diff --git a/docs/storage.html.in b/docs/storage.html.in
 index 40e8e80..8cab480 100644
 --- a/docs/storage.html.in
 +++ b/docs/storage.html.in
 @@ -258,7 +258,7 @@ libvirt.
  /p
  ul
li
 -codedos/code
 +codemsdos/code
...

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] PATCH: 1/7: Removing state from lxc_vm_t

2008-08-11 Thread Jim Meyering
Daniel P. Berrange [EMAIL PROTECTED] wrote:
 This patch does some simple re-factoring of the way the TTYs and
 control socket are handled to reduce the amount of state stored
 in the lxc_vm_t structure, in preparation for the switchover to
 the generic domain handling APIs.
...
 diff -r 63b8398c302e src/lxc_driver.c
 --- a/src/lxc_driver.cMon Jul 14 12:18:23 2008 +0100
 +++ b/src/lxc_driver.cTue Jul 15 11:55:48 2008 +0100
...
 @@ -989,15 +896,18 @@
lxc_vm_t * vm)
  {
  int rc = -1;
 -lxc_vm_def_t *vmDef = vm-def;
 +int sockpair[2];
...
 +if (lxcOpenTty(conn, parentTty, vm-def-tty, 1)  0) {
  goto cleanup;
  }

  /* open container tty */
 -if (lxcSetupContainerTty(conn, (vm-containerTtyFd), 
 (vm-containerTty))  0) {
 +if (lxcOpenTty(conn, containerTty, containerTtyPath, 0)  0) {
  goto cleanup;
  }

...
 +if (0 != socketpair(PF_UNIX, SOCK_STREAM, 0, sockpair)) {
...
  cleanup:
 -close(vm-sockpair[LXC_PARENT_SOCKET]);
 -vm-sockpair[LXC_PARENT_SOCKET] = -1;
 -close(vm-sockpair[LXC_CONTAINER_SOCKET]);
 -vm-sockpair[LXC_CONTAINER_SOCKET] = -1;
 +close(sockpair[0]);
 +close(sockpair[1]);
 +VIR_FREE(containerTtyPath);

  return rc;
  }

All looks fine except for the possibility that
the cleanup code can close undefined sockpair[0,1].
The obvious fix is to initialize them to -1 and not close in that case.

Oh, and the new name, monitor (new struct member and local/param in
several functions) would be more readable as monitor_fd.

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] PATCH: 1/7: Removing state from lxc_vm_t

2008-08-11 Thread Jim Meyering
Daniel P. Berrange [EMAIL PROTECTED] wrote:
 This patch does some simple re-factoring of the way the TTYs and
 control socket are handled to reduce the amount of state stored
 in the lxc_vm_t structure, in preparation for the switchover to
 the generic domain handling APIs.

One more thing:

...
 diff -r 63b8398c302e src/lxc_container.c
 --- a/src/lxc_container.c Mon Jul 14 12:18:23 2008 +0100
 +++ b/src/lxc_container.c Tue Jul 15 11:55:48 2008 +0100
...
 -close(0); close(1); close(2);
 +/* Just in case someone forget to set FD_CLOEXEC, explicitly
 + * close all FDs before executing the container */
 +open_max = sysconf (_SC_OPEN_MAX);
 +for (i = 0; i  open_max; i++)
 +if (i != ttyfd)
 +close(i);

Do you really need to close all file descriptors  2 ?
I seem to recall that an application doing this caused trouble
when it closed a file descriptor (opened via the shell that I
was using for log output.

I think this might have caused trouble also when I used
valgrind with its --log-* options on that program.

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [PATCH] fix MinGW compilation(200808)

2008-08-11 Thread Atsushi SAKAI
Hi, Jim and Dan

Thank you for commenting.

I compiled with attached patch successfully.

 src/domain_conf.c|1 +
 src/domain_conf.h|2 ++
 src/network_conf.c   |1 +
 src/util.c   |4 ++--
 src/virsh.c  |3 +++
 tests/testutilsxen.c |2 ++
 6 files changed, 11 insertions(+), 2 deletions(-)


Thanks
Atsushi SAKAI




Jim Meyering [EMAIL PROTECTED] wrote:

 Atsushi SAKAI [EMAIL PROTECTED] wrote:
  I am looking around the code about WEXITSTATUS.
  It seems that following kind of code needs on gnulib.
  http://kerneltrap.org/mailarchive/git/2008/2/27/1003054
  What do you think?
 
 Hi Atsushi,
 
 Yes, git provides MinGW support, and I see it's compat/mingw.h
 includes this line:
 
 #define WEXITSTATUS(x) ((x)  0xff)
 
 Could it be as easy as adding this?
 
   #ifndef WEXITSTATUS
   # define WEXITSTATUS(x) ((x)  0xff)
   #endif
 
 gnulib provides heavy-weight (different API, and GPL'd) support for
 running subprocesses via its execute module, but it targets more
 than just MinGW.


fix_mingw_compile_20080811.patch
Description: Binary data
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [PATCH] fix MinGW compilation(200808)

2008-08-11 Thread Daniel P. Berrange
On Mon, Aug 11, 2008 at 07:57:46PM +0900, Atsushi SAKAI wrote:
 Hi, Jim and Dan
 
 Thank you for commenting.
 
 I compiled with attached patch successfully.

This is bit not good:

 diff -u -r1.6 domain_conf.h
 --- src/domain_conf.h   8 Aug 2008 15:03:00 -   1.6
 +++ src/domain_conf.h   11 Aug 2008 10:53:21 -
 @@ -444,9 +444,11 @@
  typedef struct _virDomainObj virDomainObj;
  typedef virDomainObj *virDomainObjPtr;
  struct _virDomainObj {
 +#ifdef WITH_QEMU
  int stdin;
  int stdout;
  int stderr;
 +#endif
  int monitor;
  int logfile;
  int pid;

The domain_conf.{c,h} is *generic* code and should have no driver-specific
bits in it. As such there's no need for WITH_QEMU conditional compilation

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] fix MinGW compilation(200808)

2008-08-11 Thread Atsushi SAKAI
Hi, Dan

  Thank you for commenting it.
Without WITH_QEMU, following errors are appeared.
===
In file included from test.c:44:
domain_conf.h:447: error: syntax error before '' token
domain_conf.h:447: warning: no semicolon at end of struct or union
domain_conf.h:448: error: syntax error before '' token
domain_conf.h:449: error: syntax error before '' token
domain_conf.h:458: error: syntax error before ':' token
domain_conf.h:459: error: syntax error before ':' token
domain_conf.h:468: error: syntax error before '}' token

==snip==


Thanks
Atsushi SAKAI



Daniel P. Berrange [EMAIL PROTECTED] wrote:

 On Mon, Aug 11, 2008 at 07:57:46PM +0900, Atsushi SAKAI wrote:
  Hi, Jim and Dan
  
  Thank you for commenting.
  
  I compiled with attached patch successfully.
 
 This is bit not good:
 
  diff -u -r1.6 domain_conf.h
  --- src/domain_conf.h   8 Aug 2008 15:03:00 -   1.6
  +++ src/domain_conf.h   11 Aug 2008 10:53:21 -
  @@ -444,9 +444,11 @@
   typedef struct _virDomainObj virDomainObj;
   typedef virDomainObj *virDomainObjPtr;
   struct _virDomainObj {
  +#ifdef WITH_QEMU
   int stdin;
   int stdout;
   int stderr;
  +#endif
   int monitor;
   int logfile;
   int pid;
 
 The domain_conf.{c,h} is *generic* code and should have no driver-specific
 bits in it. As such there's no need for WITH_QEMU conditional compilation
 
 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] fix MinGW compilation(200808)

2008-08-11 Thread Jim Meyering
Atsushi SAKAI [EMAIL PROTECTED] wrote:
 Hi, Dan

   Thank you for commenting it.
 Without WITH_QEMU, following errors are appeared.
 ===
 In file included from test.c:44:
 domain_conf.h:447: error: syntax error before '' token
 domain_conf.h:447: warning: no semicolon at end of struct or union
 domain_conf.h:448: error: syntax error before '' token
 domain_conf.h:449: error: syntax error before '' token
 domain_conf.h:458: error: syntax error before ':' token
 domain_conf.h:459: error: syntax error before ':' token
 domain_conf.h:468: error: syntax error before '}' token
...
  +#ifdef WITH_QEMU
   int stdin;
   int stdout;
   int stderr;
  +#endif

Instead of an ifdef, I suggest renaming those three variables.
Then their names won't conflict with the names from stdio.h.

Please make that var-renaming change a separate change set.

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [PATCH] append a newline to expected-output files lacking NL-at-EOF

2008-08-11 Thread Jim Meyering
Jim Meyering [EMAIL PROTECTED] wrote:
 Jim Meyering [EMAIL PROTECTED] wrote:
 Maybe you're talking about something else?
 I proposed to add a trailing newline in the expected output
 as well as in the code to generate the actual output.

 This is the sort of change I was thinking of:

 diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c

 At first I thought that might be incomplete.
 But it's all that's needed on the C side.
 I ran this one-liner to append the missing newlines, and we're all set:

   for i in $(find|grep '\.args$'); do echo  $i;done

 make check and make syntax-check both pass.

Planning to commit that, I rebased against the latest, but found make
check then failed due to three new expected-output .args files without
the now-required trailing newline.  I added them, and now make check
passes, so I've just committed it.

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [PATCH] Ensure parted doesn't prompt if labeling disk

2008-08-11 Thread Cole Robinson
Daniel P. Berrange wrote:
 On Sun, Aug 10, 2008 at 10:40:30PM -0400, Cole Robinson wrote:
 Trying to 'build' a disk pool uses 'parted mklabel' which can
 prompt for confirmation. Patch adds the '--script' option to
 remove the chance of this happening.
 
 Can you double-check this works on RHEL-5 - IIRC, the --script arg is
 a fairly recent addition to parted.
 

My 5.2 box has it. The --script option is also used elsewhere in the
disk code, so I assume it's safe.

Thanks,
Cole

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [PATCH] Change disk type 'dos' to 'msdos'

2008-08-11 Thread Cole Robinson
Jim Meyering wrote:
 Cole Robinson [EMAIL PROTECTED] wrote:
 parted doesn't seem to want the label 'dos', instead
 wanting 'msdos'. Patch is basically s/dos/msdos/
 
 Hi Cole,
 
 This definitely needs to be fixed.
 
 FYI, dos appears to be the preferred name for that partition table type
 (google for partition table and either dos or msdos; also, partx
 --type accepts dos, not msdos).  Too bad Parted added the ms prefix.
 If it's not hard to implement, it would be nice to hide the implementation
 detail that Parted happens to call it the msdos label type.
 

We could just keep the outward facing label the same, and internally
map it to use msdos if calling 'parted mklabel' since it's the only
command that seems to use that value. Whatever people think is best.

Thanks,
Cole

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] PATCH: 2/7: Re-arrange methods acros LXC source files

2008-08-11 Thread Jim Meyering
Daniel P. Berrange [EMAIL PROTECTED] wrote:
 The lxc_driver.c file contains quite a large amount of code,
 serving two reasonably well separated purposes. First there
 is the direct implemntation of each of the libvirt driver
 APIs. Second there is the code to spawn a container and a
 controller for forwarding I/O to/from the PTYs. This patch
 attempts to re-arrange the code across files to better reflect
 the split in functionality. The general idea is thus:

  - lxc_driver.c: implementation of the libvirt driver APIs
  - lxc_container.c: code for creating containers
  - lxc_controller.c: code for managing an active container

 So this entails the following re-arrangement:

Most changes were straight function copies.
In the few cases where there were nontrivial changes,
they looked fine, though it was tedious to extract the diffs.

I liked the s/0/false/ and s/1/true/ changes.
It'd be nice to make more use of the bool type in libvirt.

ACK

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


[libvirt] [PATCH] Implement vol delete for disk pools

2008-08-11 Thread Cole Robinson
The patch below implements virStorageVolDelete for volumes
on a disk pool.

The only interesting thing here is that parted wants a
partition number to delete, so we need to peel off the
end of the volume's target path which will be of the form
'/dev/sda1' or similar (I assume. If not, it's still
better than having nothing implemented).

Thanks,
Cole
diff --git a/src/storage_backend_disk.c b/src/storage_backend_disk.c
index dac827b..28e0a52 100644
--- a/src/storage_backend_disk.c
+++ b/src/storage_backend_disk.c
@@ -22,11 +22,13 @@
  */
 
 #include config.h
+#include string.h
 
 #include internal.h
 #include storage_backend_disk.h
 #include util.h
 #include memory.h
+#include c-ctype.h
 
 enum {
 VIR_STORAGE_POOL_DISK_DOS = 0,
@@ -416,13 +418,6 @@ virStorageBackendDiskBuildPool(virConnectPtr conn,
 return 0;
 }
 
-
-static int
-virStorageBackendDiskDeleteVol(virConnectPtr conn,
-   virStoragePoolObjPtr pool,
-   virStorageVolDefPtr vol,
-   unsigned int flags);
-
 static int
 virStorageBackendDiskCreateVol(virConnectPtr conn,
virStoragePoolObjPtr pool,
@@ -486,14 +481,41 @@ virStorageBackendDiskCreateVol(virConnectPtr conn,
 
 static int
 virStorageBackendDiskDeleteVol(virConnectPtr conn,
-   virStoragePoolObjPtr pool ATTRIBUTE_UNUSED,
-   virStorageVolDefPtr vol ATTRIBUTE_UNUSED,
+   virStoragePoolObjPtr pool,
+   virStorageVolDefPtr vol,
unsigned int flags ATTRIBUTE_UNUSED)
 {
-/* delete a partition */
-virStorageReportError(conn, VIR_ERR_NO_SUPPORT,
-  _(Disk pools are not yet supported));
-return -1;
+char *part_num = NULL;
+int i;
+
+/* Strip target path (ex. '/dev/sda1') of its partition number */
+for (i = (strlen(vol-target.path)-1); i = 0; --i) {
+if (!c_isdigit(vol-target.path[i]))
+break;
+part_num = (vol-target.path[i]);
+}
+
+if (!part_num) {
+virStorageReportError(conn, VIR_ERR_INTERNAL_ERROR,
+  _(cannot parse partition number from target 
+path '%s'), vol-target.path);
+return -1;
+}
+
+/* eg parted /dev/sda rm 2 */
+const char *prog[] = {
+PARTED,
+pool-def-source.devices[0].path,
+rm,
+--script,
+part_num,
+NULL,
+};
+
+if (virRun(conn, prog, NULL)  0)
+return -1;
+
+return 0;
 }
 
 
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


[libvirt] [PATCH] Fix python error reporting for some storage operations

2008-08-11 Thread Cole Robinson
In the python bindings, all vir* classes expect to be
passed a virConnect object when instantiated. Before
the storage stuff, these classes were only instantiated
in virConnect methods, so the generator is hardcoded to
pass 'self' as the connection instance to these classes.

Problem is there are some methods that return pool or vol
instances which aren't called from virConnect: you can
lookup a storage volume's associated pool, and can lookup
volumes from a pool. In these cases passing 'self' doesn't
give the vir* instance a connection, so when it comes time
to raise an exception crap hits the fan.

Rather than rework the generator to accomodate this edge
case, I just fixed the init functions for virStorage* to
pull the associated connection out of the passed value
if it's not a virConnect instance.

Thanks,
Cole

diff --git a/python/generator.py b/python/generator.py
index 01a17da..c706b19 100755
--- a/python/generator.py
+++ b/python/generator.py
@@ -962,8 +962,12 @@ def buildWrappers():
list = reference_keepers[classname]
for ref in list:
classes.write(self.%s = None\n % ref[1])
-if classname in [ virDomain, virNetwork, virStoragePool, 
virStorageVol ]:
+if classname in [ virDomain, virNetwork ]:
 classes.write(self._conn = conn\n)
+elif classname in [ virStorageVol, virStoragePool ]:
+classes.write(self._conn = conn\n + \
+  if not isinstance(conn, 
virConnect):\n + \
+  self._conn = conn._conn\n)
classes.write(if _obj != None:self._o = _obj;return\n)
classes.write(self._o = None\n\n);
destruct=None

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [PATCH] fix MinGW compilation(200808)

2008-08-11 Thread Atsushi SAKAI
Hi, Jim and Dan

How about this?

 src/domain_conf.c|1 +
 src/domain_conf.h|6 +++---
 src/network_conf.c   |1 +
 src/qemu_driver.c|   32 
 src/util.c   |4 ++--
 src/virsh.c  |3 +++
 tests/testutilsxen.c |2 ++
 7 files changed, 28 insertions(+), 21 deletions(-)

Thanks
Atsushi SAKAI



Jim Meyering [EMAIL PROTECTED] wrote:

 Atsushi SAKAI [EMAIL PROTECTED] wrote:
  Hi, Dan
 
Thank you for commenting it.
  Without WITH_QEMU, following errors are appeared.
  ===
  In file included from test.c:44:
  domain_conf.h:447: error: syntax error before '' token
  domain_conf.h:447: warning: no semicolon at end of struct or union
  domain_conf.h:448: error: syntax error before '' token
  domain_conf.h:449: error: syntax error before '' token
  domain_conf.h:458: error: syntax error before ':' token
  domain_conf.h:459: error: syntax error before ':' token
  domain_conf.h:468: error: syntax error before '}' token
 ...
   +#ifdef WITH_QEMU
int stdin;
int stdout;
int stderr;
   +#endif
 
 Instead of an ifdef, I suggest renaming those three variables.
 Then their names won't conflict with the names from stdio.h.
 
 Please make that var-renaming change a separate change set.


fix_mingw_compile_20080812.patch
Description: Binary data
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list