date:20080619

Re: [libvirt] libvirt on mingw: undefined reference to htonl/ntohl

2008-06-19 Thread Brecht Sanders


No. Can you tell me where to find it?
I also noticed that I only produced one DLL: libvirt-0.dll.
No Python module DLL was built. Were you able to build this?

Atsushi SAKAI wrote:

Hi,

Did you check my instruction for libvirt on MinGW?

Thanks
Atsushi SAKAI


Brecht Sanders [EMAIL PROTECTED] wrote:

  

Hi,
Some time passed by and I thought I'd have another go at compiling 
libvirt for win32 using MinGW/MSYS again.
I tried to compile libvirt-0.4.3 and I got around most obstacles. Now it 
just seems I am stuck when it is trying to link.

My search on google showed me that I am not the first one to see this issue.
Usually i means -lws2_32 is in the wrong place. However I tried moving 
it around without luck.
Also it doesn't make sense to me that only htonl and ntohl are missing. 
It appears anything else used from the winsock library is found during 
linking.
I feel we're very close to getting libvirt compiled on win32. Or do you 
know if anyone already succeeded?

Regards
Brecht Sanders

gcc -shared  .libs/libvirt_la-libvirt.o .libs/libvirt_la-memory.o 
.libs/libvirt_la-hash.o .libs/libvirt_la-test.o .libs/libvirt_la-buf.o 
.libs/libvirt_la-qparams.o .libs/libvirt_la-capabilities.o 
.libs/libvirt_la-xml.o .libs/libvirt_la-event.o 
.libs/libvirt_la-xen_unified.o .libs/libvirt_la-xen_internal.o 
.libs/libvirt_la-xs_internal.o .libs/libvirt_la-xend_internal.o 
.libs/libvirt_la-stats_linux.o .libs/libvirt_la-sexpr.o 
.libs/libvirt_la-virterror.o .libs/libvirt_la-proxy_internal.o 
.libs/libvirt_la-conf.o .libs/libvirt_la-xm_internal.o 
.libs/libvirt_la-remote_internal.o .libs/libvirt_la-bridge.o 
.libs/libvirt_la-iptables.o .libs/libvirt_la-uuid.o 
.libs/libvirt_la-qemu_driver.o .libs/libvirt_la-qemu_conf.o 
.libs/libvirt_la-openvz_conf.o .libs/libvirt_la-openvz_driver.o 
.libs/libvirt_la-lxc_driver.o .libs/libvirt_la-lxc_conf.o 
.libs/libvirt_la-lxc_container.o .libs/libvirt_la-nodeinfo.o 
.libs/libvirt_la-util.o .libs/libvirt_la-remote_protocol.o 
-Wl,--whole-archive ../gnulib/lib/.libs/libgnu.a -Wl,--no-whole-archive  
-L/mingw/lib /mingw/lib/libxml2.dll.a /mingw/lib/libgnutls.dll.a 
-L/home/bsanders/inst_libgcrypt-1.4.1/lib -lintl -lpthread 
/mingw/lib/libportablexdr.dll.a -lws2_32  
-Wl,--version-script=./libvirt_sym.version -o .libs/libvirt-0.dll 
-Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker 
.libs/libvirt.dll.a

Creating library file: .libs/libvirt.dll.a
.libs/libvirt_la-remote_protocol.o:remote_protocol.c:(.text+0xa46): 
undefined reference to `htonl'
.libs/libvirt_la-remote_protocol.o:remote_protocol.c:(.text+0xa5f): 
undefined reference to `htonl'
.libs/libvirt_la-remote_protocol.o:remote_protocol.c:(.text+0xa78): 
undefined reference to `htonl'
.libs/libvirt_la-remote_protocol.o:remote_protocol.c:(.text+0xa91): 
undefined reference to `htonl'
.libs/libvirt_la-remote_protocol.o:remote_protocol.c:(.text+0xaaa): 
undefined reference to `htonl'
.libs/libvirt_la-remote_protocol.o:remote_protocol.c:(.text+0xac3): more 
undefined references to `htonl' follow
.libs/libvirt_la-remote_protocol.o:remote_protocol.c:(.text+0xc5d): 
undefined reference to `ntohl'
.libs/libvirt_la-remote_protocol.o:remote_protocol.c:(.text+0xc74): 
undefined reference to `ntohl'
.libs/libvirt_la-remote_protocol.o:remote_protocol.c:(.text+0xc8b): 
undefined reference to `ntohl'
.libs/libvirt_la-remote_protocol.o:remote_protocol.c:(.text+0xca2): 
undefined reference to `ntohl'
.libs/libvirt_la-remote_protocol.o:remote_protocol.c:(.text+0xcb9): 
undefined reference to `ntohl'
.libs/libvirt_la-remote_protocol.o:remote_protocol.c:(.text+0xccc): more 
undefined references to `ntohl' follow

collect2: ld returned 1 exit status
make[2]: *** [libvirt.la] Error 1
make[2]: Leaving directory `/home/bsanders/libvirt-0.4.3/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/bsanders/libvirt-0.4.3'
make: *** [all] Error 2

--
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] How does libvirt access kvm infomation?

2008-06-19 Thread Chris Lalancette

Akio Takebe wrote:
 Hi,
 
 AFAIK kvm has only an interface of qemu console when we use device
 hotplug, migration and so on. How does libvirt access the interface
 of qemu console?

As far as I understand it (from looking at the code recently), you can tell the
qemu monitor to open against a pty.  libvirtd does this, and holds on to the
other end of the pty, and then issues commands through the PTY to do anything
that you need through the monitor interface.

Look at src/qemu_driver.c:qemudWaitForMonitor() (or thereabouts) for where this
is setup while starting a domain.

Chris Lalancette

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

Re: [libvirt] How does libvirt access kvm infomation?

2008-06-19 Thread Akio Takebe


Hi, Chris

Chris Lalancette wrote:

Akio Takebe wrote:
  

Hi,

AFAIK kvm has only an interface of qemu console when we use device
hotplug, migration and so on. How does libvirt access the interface
of qemu console?



As far as I understand it (from looking at the code recently), you can tell the
qemu monitor to open against a pty.  libvirtd does this, and holds on to the
other end of the pty, and then issues commands through the PTY to do anything
that you need through the monitor interface.

Look at src/qemu_driver.c:qemudWaitForMonitor() (or thereabouts) for where this
is setup while starting a domain.
  

Thank you for your information.
I understand it. I'll ckeck around the codes.

Best Regards,

Akio Takebe

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

Re: [libvirt] libvirt on mingw: undefined reference to htonl/ntohl

2008-06-19 Thread Brecht Sanders


Hi,
I guesss I had got as far as you did.
To Install Python on Windows you will need to download and install the 
following:

   http://www.python.org/ftp/python/2.5.2/python-2.5.2.msi
   
http://ftp.gnome.org/pub/GNOME/binaries/win32/pygobject/2.14/pygobject-2.14.1-1.win32-py2.5.exe
   
http://ftp.gnome.org/pub/GNOME/binaries/win32/pycairo/1.4/pycairo-1.4.12-1.win32-py2.5.exe
   
http://ftp.gnome.org/pub/GNOME/binaries/win32/pygtk/2.12/pygtk-2.12.1-2.win32-py2.5.exe

Also, don't forget to set some environment variables:
   export PYDIR=/C/Prog/Python25
   export PYTHONHOME=$PYDIR
   export PYTHONPATH=$PYDIR/Lib/site-packages
   export PATH=$MINGWPREFIX:$MINGWPREFIX/bin:$PATH
Just out of curiosity, have you done anything with virsh or the DLL you 
have built?

Regards,
   Brecht

Atsushi SAKAI wrote:

Hi, Bericht

By your suggestion, I am recognizing python bindings are not created(on my 
configuration).
If you notice me to install python on MinGW, I will try to investigate it.

My posting mail is follows(it does not create python library)
https://www.redhat.com/archives/libvir-list/2008-June/msg00201.html
It creates general library and virsh only.

Thanks
Atsushi SAKAI


Brecht Sanders [EMAIL PROTECTED] wrote:

  

No. Can you tell me where to find it?
I also noticed that I only produced one DLL: libvirt-0.dll.
No Python module DLL was built. Were you able to build this?

Atsushi SAKAI wrote:


Hi,

Did you check my instruction for libvirt on MinGW?

Thanks
Atsushi SAKAI


Brecht Sanders [EMAIL PROTECTED] wrote:

  
  

Hi,
Some time passed by and I thought I'd have another go at compiling 
libvirt for win32 using MinGW/MSYS again.
I tried to compile libvirt-0.4.3 and I got around most obstacles. Now it 
just seems I am stuck when it is trying to link.

My search on google showed me that I am not the first one to see this issue.
Usually i means -lws2_32 is in the wrong place. However I tried moving 
it around without luck.
Also it doesn't make sense to me that only htonl and ntohl are missing. 
It appears anything else used from the winsock library is found during 
linking.
I feel we're very close to getting libvirt compiled on win32. Or do you 
know if anyone already succeeded?

Regards
Brecht Sanders

gcc -shared  .libs/libvirt_la-libvirt.o .libs/libvirt_la-memory.o 
.libs/libvirt_la-hash.o .libs/libvirt_la-test.o .libs/libvirt_la-buf.o 
.libs/libvirt_la-qparams.o .libs/libvirt_la-capabilities.o 
.libs/libvirt_la-xml.o .libs/libvirt_la-event.o 
.libs/libvirt_la-xen_unified.o .libs/libvirt_la-xen_internal.o 
.libs/libvirt_la-xs_internal.o .libs/libvirt_la-xend_internal.o 
.libs/libvirt_la-stats_linux.o .libs/libvirt_la-sexpr.o 
.libs/libvirt_la-virterror.o .libs/libvirt_la-proxy_internal.o 
.libs/libvirt_la-conf.o .libs/libvirt_la-xm_internal.o 
.libs/libvirt_la-remote_internal.o .libs/libvirt_la-bridge.o 
.libs/libvirt_la-iptables.o .libs/libvirt_la-uuid.o 
.libs/libvirt_la-qemu_driver.o .libs/libvirt_la-qemu_conf.o 
.libs/libvirt_la-openvz_conf.o .libs/libvirt_la-openvz_driver.o 
.libs/libvirt_la-lxc_driver.o .libs/libvirt_la-lxc_conf.o 
.libs/libvirt_la-lxc_container.o .libs/libvirt_la-nodeinfo.o 
.libs/libvirt_la-util.o .libs/libvirt_la-remote_protocol.o 
-Wl,--whole-archive ../gnulib/lib/.libs/libgnu.a -Wl,--no-whole-archive  
-L/mingw/lib /mingw/lib/libxml2.dll.a /mingw/lib/libgnutls.dll.a 
-L/home/bsanders/inst_libgcrypt-1.4.1/lib -lintl -lpthread 
/mingw/lib/libportablexdr.dll.a -lws2_32  
-Wl,--version-script=./libvirt_sym.version -o .libs/libvirt-0.dll 
-Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker 
.libs/libvirt.dll.a

Creating library file: .libs/libvirt.dll.a
.libs/libvirt_la-remote_protocol.o:remote_protocol.c:(.text+0xa46): 
undefined reference to `htonl'
.libs/libvirt_la-remote_protocol.o:remote_protocol.c:(.text+0xa5f): 
undefined reference to `htonl'
.libs/libvirt_la-remote_protocol.o:remote_protocol.c:(.text+0xa78): 
undefined reference to `htonl'
.libs/libvirt_la-remote_protocol.o:remote_protocol.c:(.text+0xa91): 
undefined reference to `htonl'
.libs/libvirt_la-remote_protocol.o:remote_protocol.c:(.text+0xaaa): 
undefined reference to `htonl'
.libs/libvirt_la-remote_protocol.o:remote_protocol.c:(.text+0xac3): more 
undefined references to `htonl' follow
.libs/libvirt_la-remote_protocol.o:remote_protocol.c:(.text+0xc5d): 
undefined reference to `ntohl'
.libs/libvirt_la-remote_protocol.o:remote_protocol.c:(.text+0xc74): 
undefined reference to `ntohl'
.libs/libvirt_la-remote_protocol.o:remote_protocol.c:(.text+0xc8b): 
undefined reference to `ntohl'
.libs/libvirt_la-remote_protocol.o:remote_protocol.c:(.text+0xca2): 
undefined reference to `ntohl'
.libs/libvirt_la-remote_protocol.o:remote_protocol.c:(.text+0xcb9): 
undefined reference to `ntohl'
.libs/libvirt_la-remote_protocol.o:remote_protocol.c:(.text+0xccc): more 
undefined references to `ntohl' follow

collect2: ld returned 1 exit status
make[2]: *** [libvirt.la] Error 1
make[2]: Leaving directory

[libvirt] [PATCH]: Fix VIR_ALLOC_N for 0 byte arrays

2008-06-19 Thread Chris Lalancette

Hello,
 For 0.4.3, danpb's new memory management scheme went into libvirt.  This is
fine, except that is subtly alters the semantics of malloc(), calloc(), and
realloc().  In particular, if you say:

foo = malloc(0);

glibc will happily return a non-NULL pointer to you.  However, with the new
memory management stuff, if you say:

foo = VIR_ALLOC(0);

you will actually get a NULL pointer back.  Personally, I think this is a
dangerous deviation from malloc() semantics that everyone is used to, and is
indeed causing problems with the remote driver.  The short of it is that the
remote driver allocates memory on behalf of the remote side using VIR_ALLOC_N,
and this call is returning NULL so that the NULL checks elsewhere in the code
fire and return failure.

The attached patch fixes this situation by removing the 0 checks from the memory
allocation paths, and just lets them fall through to the normal malloc(),
calloc(), or realloc() routines, restoring old semantics.

Signed-off-by: Chris Lalancette [EMAIL PROTECTED]
Index: src/memory.c
===
RCS file: /data/cvs/libvirt/src/memory.c,v
retrieving revision 1.7
diff -u -r1.7 memory.c
--- a/src/memory.c	6 Jun 2008 11:09:57 -	1.7
+++ b/src/memory.c	19 Jun 2008 08:44:01 -
@@ -97,11 +97,6 @@
 }
 #endif
 
-if (size == 0) {
-*(void **)ptrptr = NULL;
-return 0;
-}
-
 *(void **)ptrptr = calloc(1, size);
 if (*(void **)ptrptr == NULL)
 return -1;
@@ -130,11 +125,6 @@
 }
 #endif
 
-if (size == 0 || count == 0) {
-*(void **)ptrptr = NULL;
-return 0;
-}
-
 *(void**)ptrptr = calloc(count, size);
 if (*(void**)ptrptr == NULL)
 return -1;
@@ -163,11 +153,6 @@
 return -1;
 #endif
 
-if (size == 0 || count == 0) {
-free(*(void **)ptrptr);
-*(void **)ptrptr = NULL;
-return 0;
-}
 if (xalloc_oversized(count, size)) {
 errno = ENOMEM;
 return -1;
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH]: fix ruby-libvirt bindings when virConnectNum* returns 0

2008-06-19 Thread Chris Lalancette

Daniel Veillard wrote:
   Hum, looking at the bugzilla it's for storage that the problem was raised.
 It's a bit annoying, the main domain and network functions accept a max = 0
 The documentation of virConnectListDefinedStoragePools doesn't prevent
 maxnames = 0
 
   Actually the check done in the function is 
 if ((names == NULL) || (maxnames  0))
 
 i.e. it allows 0, and pass it to the underlying driver. One solution
 would be to just return 0 there, as attached in this patch, the other
 solution would be to check which underlying storage driver failed and
 fix it,

Right.  After going through this, I found out that it is actually a NULL check
firing, not a 0 check (see my posted patch for details).  That being said, a
patch of the type posted here might be worthwhile; it would short-circuit the
rest of the calls through the stack, and in particular would avoid on-the-wire
calls in the remote case, to do essentially no work.  I think it would be a nice
optimization for all of the List type operations, but not necessarily required.

Chris Lalancette

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

Re: [libvirt] [PATCH]: Fix VIR_ALLOC_N for 0 byte arrays

2008-06-19 Thread Jim Meyering

Chris Lalancette [EMAIL PROTECTED] wrote:
  For 0.4.3, danpb's new memory management scheme went into libvirt.  This 
 is
 fine, except that is subtly alters the semantics of malloc(), calloc(), and
 realloc().  In particular, if you say:

 foo = malloc(0);

 glibc will happily return a non-NULL pointer to you.  However, with the new
 memory management stuff, if you say:

 foo = VIR_ALLOC(0);

 you will actually get a NULL pointer back.  Personally, I think this is a
 dangerous deviation from malloc() semantics that everyone is used to, and is
 indeed causing problems with the remote driver.  The short of it is that the
 remote driver allocates memory on behalf of the remote side using VIR_ALLOC_N,
 and this call is returning NULL so that the NULL checks elsewhere in the code
 fire and return failure.

 The attached patch fixes this situation by removing the 0 checks from the 
 memory
 allocation paths, and just lets them fall through to the normal malloc(),
 calloc(), or realloc() routines, restoring old semantics.

Wow.  That's a nasty one, violating such assumptions.
Good catch.

In case anyone reading along wonders about the portability of libvirt's
assumption that those functions return non-NULL for N=0, it's fine
because gnulib wrappers protect us from libc functions with the
undesirable semantics.

ACK.

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

Re: [libvirt] [PATCH]: Fix VIR_ALLOC_N for 0 byte arrays

2008-06-19 Thread Daniel Veillard

On Thu, Jun 19, 2008 at 10:49:59AM +0200, Chris Lalancette wrote:
 Hello,
  For 0.4.3, danpb's new memory management scheme went into libvirt.  This 
 is
 fine, except that is subtly alters the semantics of malloc(), calloc(), and
 realloc().  In particular, if you say:
 
 foo = malloc(0);
 
 glibc will happily return a non-NULL pointer to you.  However, with the new
 memory management stuff, if you say:
 
 foo = VIR_ALLOC(0);
 
 you will actually get a NULL pointer back.  Personally, I think this is a
 dangerous deviation from malloc() semantics that everyone is used to, and is
 indeed causing problems with the remote driver.  The short of it is that the
 remote driver allocates memory on behalf of the remote side using VIR_ALLOC_N,
 and this call is returning NULL so that the NULL checks elsewhere in the code
 fire and return failure.
 
 The attached patch fixes this situation by removing the 0 checks from the 
 memory
 allocation paths, and just lets them fall through to the normal malloc(),
 calloc(), or realloc() routines, restoring old semantics.
 
 Signed-off-by: Chris Lalancette [EMAIL PROTECTED]

  Agreed, it's a problem, +1, but
since Dan explicitely made the == 0 test to return NULL he probably 
had a purpose about this (I suspect detecting 0 sized memory allocations).
So i would not apply the patch before he had a chance to comment on it,
but yes I personally thing we should reverse that bit. A zero lenght
allocation is legal, and may be later extended with realloc. This can
lead to vastly simplified code (to the expense of a seemingly useless 
initial allocation).

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard  | virtualization library  http://libvirt.org/
[EMAIL PROTECTED]  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

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

[libvirt] [PATCH]: Fix allocation of tapfds when starting qemu

2008-06-19 Thread Chris Lalancette

All,
 When doing the conversion to danpb's new memory API, a small bug was
introduced into the qemudNetworkIfaceConnect() function.  In particular, there
is a call:

if (VIR_ALLOC_N(vm-tapfds, vm-ntapfds+2)  0)
goto no_memory;

However, the tapfds structure is used to track *all* of the tap fds, and is
called once for each network that is being attached to the domain.  VIR_ALLOC_N
maps to calloc().  So the first network would work just fine, but if you had
more than one network, subsequent calls to this function would blow away the
stored fd's that were already there and fill them all in with zeros.  This
causes multiple problems, from the qemu domains not starting properly to
improper cleanup on shutdown.  The attached patch just changes the VIR_ALLOC_N()
to a VIR_REALLOC_N(), and everything is happy again.

Signed-off-by: Chris Lalancette [EMAIL PROTECTED]
Index: src/qemu_conf.c
===
RCS file: /data/cvs/libvirt/src/qemu_conf.c,v
retrieving revision 1.78
diff -u -r1.78 qemu_conf.c
--- a/src/qemu_conf.c	13 Jun 2008 07:56:59 -	1.78
+++ b/src/qemu_conf.c	19 Jun 2008 10:01:53 -
@@ -2317,7 +2317,7 @@
 if (!(retval = strdup(tapfdstr)))
 goto no_memory;
 
-if (VIR_ALLOC_N(vm-tapfds, vm-ntapfds+2)  0)
+if (VIR_REALLOC_N(vm-tapfds, vm-ntapfds+2)  0)
 goto no_memory;
 
 vm-tapfds[vm-ntapfds++] = tapfd;
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH]: Fix allocation of tapfds when starting qemu

2008-06-19 Thread Daniel Veillard

On Thu, Jun 19, 2008 at 12:06:28PM +0200, Chris Lalancette wrote:
 All,
  When doing the conversion to danpb's new memory API, a small bug was
 introduced into the qemudNetworkIfaceConnect() function.  In particular, there
 is a call:
 
 if (VIR_ALLOC_N(vm-tapfds, vm-ntapfds+2)  0)
 goto no_memory;
 
 However, the tapfds structure is used to track *all* of the tap fds, and is
 called once for each network that is being attached to the domain.  
 VIR_ALLOC_N
 maps to calloc().  So the first network would work just fine, but if you had
 more than one network, subsequent calls to this function would blow away the
 stored fd's that were already there and fill them all in with zeros.  This
 causes multiple problems, from the qemu domains not starting properly to
 improper cleanup on shutdown.  The attached patch just changes the 
 VIR_ALLOC_N()
 to a VIR_REALLOC_N(), and everything is happy again.
 
 Signed-off-by: Chris Lalancette [EMAIL PROTECTED]

  Dohh, okay, +1 please push :-)

   thanks !

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard  | virtualization library  http://libvirt.org/
[EMAIL PROTECTED]  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

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

Re: [libvirt] [PATCH]: Fix allocation of tapfds when starting qemu

2008-06-19 Thread Chris Lalancette

Daniel Veillard wrote:
 On Thu, Jun 19, 2008 at 12:06:28PM +0200, Chris Lalancette wrote:
 
   Dohh, okay, +1 please push :-)
 
thanks !

Committed.

Chris Lalancette

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

Re: [libvirt] [PATCH]: Fix allocation of tapfds when starting qemu

2008-06-19 Thread Jim Meyering

Chris Lalancette [EMAIL PROTECTED] wrote:
 All,
  When doing the conversion to danpb's new memory API, a small bug was
 introduced into the qemudNetworkIfaceConnect() function.  In particular, there
 is a call:

 if (VIR_ALLOC_N(vm-tapfds, vm-ntapfds+2)  0)
 goto no_memory;

 However, the tapfds structure is used to track *all* of the tap fds, and is
 called once for each network that is being attached to the domain.  
 VIR_ALLOC_N
 maps to calloc().  So the first network would work just fine, but if you had
 more than one network, subsequent calls to this function would blow away the
 stored fd's that were already there and fill them all in with zeros.  This
 causes multiple problems, from the qemu domains not starting properly to
 improper cleanup on shutdown.  The attached patch just changes the 
 VIR_ALLOC_N()
 to a VIR_REALLOC_N(), and everything is happy again.

 Signed-off-by: Chris Lalancette [EMAIL PROTECTED]
 Index: src/qemu_conf.c
 ===
 RCS file: /data/cvs/libvirt/src/qemu_conf.c,v
 retrieving revision 1.78
 diff -u -r1.78 qemu_conf.c
 --- a/src/qemu_conf.c 13 Jun 2008 07:56:59 -  1.78
 +++ b/src/qemu_conf.c 19 Jun 2008 10:01:53 -
 @@ -2317,7 +2317,7 @@
  if (!(retval = strdup(tapfdstr)))
  goto no_memory;

 -if (VIR_ALLOC_N(vm-tapfds, vm-ntapfds+2)  0)
 +if (VIR_REALLOC_N(vm-tapfds, vm-ntapfds+2)  0)
  goto no_memory;

  vm-tapfds[vm-ntapfds++] = tapfd;

Yow.  Another good catch.
That's obviously the right fix.
ACK.

I went looking for similar bugs and actually found one!

  $ g show d3470efcda15f59549ac0aaa76cd25df319c217b \
|grep -A2 realloc|grep VIR_ALLOC
  +if (VIR_ALLOC_N(vm-tapfds, vm-ntapfds+2)  0)
  +if (VIR_ALLOC_N(buf, alloc)  0) {

That's in the fread_file_lim function, and the fix is the same.
To demonstrate, make virsh read a file containing more than
BUFSIZ bytes, e.g.,

Create a legit definition, but with enough spaces
at the end to push the size over the limit:

  { ./virsh -c test:///default dumpxml 1; printf %9000s ' ' }  t

Demonstrate that virsh-0.4.2 reads/parses it fine:

$ virsh --version
0.4.2
$ virsh --connect test:///default define t
Domain test defined from t

Show that just-built (pre-patch) virsh fails:

$ ./virsh --version
0.4.3
$ ./virsh --connect test:///default define t
libvir: Test error : XML description for domain is not well formed or 
invaliderror: Failed to define domain from t

[Exit 1]

Show that patched, it works fine:

$ ./virsh --connect test:///default define t
Domain test defined from t
$

Here's the patch I'll push soon:

From 02172b2c2e529a0afd04d5880ff8f32ad480ed9d Mon Sep 17 00:00:00 2001
From: Jim Meyering [EMAIL PROTECTED]
Date: Thu, 19 Jun 2008 12:36:36 +0200
Subject: [PATCH] virsh fails to read files larger than BUFSIZ bytes

* src/util.c (fread_file_lim): Use VIR_REALLOC_N, not VIR_ALLOC_N.
Bug introduced in d3470efcda15f59549ac0aaa76cd25df319c217b
---
 src/util.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/src/util.c b/src/util.c
index ad7683d..5e50ef2 100644
--- a/src/util.c
+++ b/src/util.c
@@ -306,7 +306,7 @@ fread_file_lim (FILE *stream, size_t max_len, size_t 
*length)
 if (alloc  size + BUFSIZ + 1)
 alloc = size + BUFSIZ + 1;

-if (VIR_ALLOC_N(buf, alloc)  0) {
+if (VIR_REALLOC_N(buf, alloc)  0) {
 save_errno = errno;
 break;
 }
@@ -797,4 +797,3 @@ int virDiskNameToIndex(const char *name) {

 return idx;
 }
-
--
1.5.6.rc3.23.gc3bdd

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

Re: [libvirt] [PATCH]: Fix allocation of tapfds when starting qemu

2008-06-19 Thread Chris Lalancette

Jim Meyering wrote:
 diff --git a/src/util.c b/src/util.c
 index ad7683d..5e50ef2 100644
 --- a/src/util.c
 +++ b/src/util.c
 @@ -306,7 +306,7 @@ fread_file_lim (FILE *stream, size_t max_len, size_t 
 *length)
  if (alloc  size + BUFSIZ + 1)
  alloc = size + BUFSIZ + 1;
 
 -if (VIR_ALLOC_N(buf, alloc)  0) {
 +if (VIR_REALLOC_N(buf, alloc)  0) {
  save_errno = errno;
  break;
  }
 @@ -797,4 +797,3 @@ int virDiskNameToIndex(const char *name) {
 
  return idx;
  }

Yep.  Good catch.  Confirmed by following your test procedure, and confirmed
that this fixes the issue.

ACK

Chris Lalancette

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

Re: [libvirt] [PATCH]: Fix VIR_ALLOC_N for 0 byte arrays

2008-06-19 Thread Daniel P. Berrange

On Thu, Jun 19, 2008 at 05:51:07AM -0400, Daniel Veillard wrote:
 On Thu, Jun 19, 2008 at 10:49:59AM +0200, Chris Lalancette wrote:
  Hello,
   For 0.4.3, danpb's new memory management scheme went into libvirt.  
  This is
  fine, except that is subtly alters the semantics of malloc(), calloc(), and
  realloc().  In particular, if you say:
  
  foo = malloc(0);
  
  glibc will happily return a non-NULL pointer to you.  However, with the new
  memory management stuff, if you say:
  
  foo = VIR_ALLOC(0);
  
  you will actually get a NULL pointer back.  Personally, I think this is a
  dangerous deviation from malloc() semantics that everyone is used to, and is
  indeed causing problems with the remote driver.  The short of it is that the
  remote driver allocates memory on behalf of the remote side using 
  VIR_ALLOC_N,
  and this call is returning NULL so that the NULL checks elsewhere in the 
  code
  fire and return failure.
  
  The attached patch fixes this situation by removing the 0 checks from the 
  memory
  allocation paths, and just lets them fall through to the normal malloc(),
  calloc(), or realloc() routines, restoring old semantics.
  
  Signed-off-by: Chris Lalancette [EMAIL PROTECTED]
 
   Agreed, it's a problem, +1, but
 since Dan explicitely made the == 0 test to return NULL he probably 
 had a purpose about this (I suspect detecting 0 sized memory allocations).

No, this was just a stupid bug on my part. This patch is fine.

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] libvirt on mingw: undefined reference to htonl/ntohl

2008-06-19 Thread Atsushi SAKAI

Hi, Breｃｈｔ

I can make .a file(not .dll).
With following instruction.

==1==
Install 
http://www.python.org/ftp/python/2.5.2/python-2.5.2.msi
to /usr/local/(C:\msys\1.0\local)

and copy to include file to /usr/include/python2.5
and copy /usr/local/python.exe pythonw.exe to /usr/local/bin

==2==
Install to /usr/local (C:\msys\1.0\local)
http://ftp.gnome.org/pub/GNOME/binaries/win32/pygobject/2.14/pygobject-2.14.1-1.win32-py2.5.exe

make and make install seems work fine.

Thanks
Atsushi SAKAI





Atsushi SAKAI [EMAIL PROTECTED] wrote:

 Hi, Brecht
 
  Just out of curiosity, have you done anything with virsh or the DLL you 
  have built?
 Yes
 
 By the way, I am doing to build Python bingings on MinGW.
 But it will need to do tomorrow, since many compilation warnings.
 
 Thanks
 Atsushi SAKAI
 
 
 
 
 Brecht Sanders [EMAIL PROTECTED] wrote:
 
  Hi,
  I guesss I had got as far as you did.
  To Install Python on Windows you will need to download and install the 
  following:
  http://www.python.org/ftp/python/2.5.2/python-2.5.2.msi
  
  http://ftp.gnome.org/pub/GNOME/binaries/win32/pygobject/2.14/pygobject-2.14.1-1.win32-py2.5.exe
  
  http://ftp.gnome.org/pub/GNOME/binaries/win32/pycairo/1.4/pycairo-1.4.12-1.win32-py2.5.exe
  
  http://ftp.gnome.org/pub/GNOME/binaries/win32/pygtk/2.12/pygtk-2.12.1-2.win32-py2.5.exe
  Also, don't forget to set some environment variables:
  export PYDIR=/C/Prog/Python25
  export PYTHONHOME=$PYDIR
  export PYTHONPATH=$PYDIR/Lib/site-packages
  export PATH=$MINGWPREFIX:$MINGWPREFIX/bin:$PATH
  Just out of curiosity, have you done anything with virsh or the DLL you 
  have built?
  Regards,
  Brecht
  
  Atsushi SAKAI wrote:
   Hi, Bericht
  
   By your suggestion, I am recognizing python bindings are not created(on 
   my configuration).
   If you notice me to install python on MinGW, I will try to investigate it.
  
   My posting mail is follows(it does not create python library)
   https://www.redhat.com/archives/libvir-list/2008-June/msg00201.html
   It creates general library and virsh only.
  
   Thanks
   Atsushi SAKAI
  
  
   Brecht Sanders [EMAIL PROTECTED] wrote:
  
 
   No. Can you tell me where to find it?
   I also noticed that I only produced one DLL: libvirt-0.dll.
   No Python module DLL was built. Were you able to build this?
  
   Atsushi SAKAI wrote:
   
   Hi,
  
   Did you check my instruction for libvirt on MinGW?
  
   Thanks
   Atsushi SAKAI
  
  
   Brecht Sanders [EMAIL PROTECTED] wrote:
  
 
 
   Hi,
   Some time passed by and I thought I'd have another go at compiling 
   libvirt for win32 using MinGW/MSYS again.
   I tried to compile libvirt-0.4.3 and I got around most obstacles. Now 
   it 
   just seems I am stuck when it is trying to link.
   My search on google showed me that I am not the first one to see this 
   issue.
   Usually i means -lws2_32 is in the wrong place. However I tried moving 
   it around without luck.
   Also it doesn't make sense to me that only htonl and ntohl are 
   missing. 
   It appears anything else used from the winsock library is found during 
   linking.
   I feel we're very close to getting libvirt compiled on win32. Or do 
   you 
   know if anyone already succeeded?
   Regards
   Brecht Sanders
  
   gcc -shared  .libs/libvirt_la-libvirt.o .libs/libvirt_la-memory.o 
   .libs/libvirt_la-hash.o .libs/libvirt_la-test.o .libs/libvirt_la-buf.o 
   .libs/libvirt_la-qparams.o .libs/libvirt_la-capabilities.o 
   .libs/libvirt_la-xml.o .libs/libvirt_la-event.o 
   .libs/libvirt_la-xen_unified.o .libs/libvirt_la-xen_internal.o 
   .libs/libvirt_la-xs_internal.o .libs/libvirt_la-xend_internal.o 
   .libs/libvirt_la-stats_linux.o .libs/libvirt_la-sexpr.o 
   .libs/libvirt_la-virterror.o .libs/libvirt_la-proxy_internal.o 
   .libs/libvirt_la-conf.o .libs/libvirt_la-xm_internal.o 
   .libs/libvirt_la-remote_internal.o .libs/libvirt_la-bridge.o 
   .libs/libvirt_la-iptables.o .libs/libvirt_la-uuid.o 
   .libs/libvirt_la-qemu_driver.o .libs/libvirt_la-qemu_conf.o 
   .libs/libvirt_la-openvz_conf.o .libs/libvirt_la-openvz_driver.o 
   .libs/libvirt_la-lxc_driver.o .libs/libvirt_la-lxc_conf.o 
   .libs/libvirt_la-lxc_container.o .libs/libvirt_la-nodeinfo.o 
   .libs/libvirt_la-util.o .libs/libvirt_la-remote_protocol.o 
   -Wl,--whole-archive ../gnulib/lib/.libs/libgnu.a 
   -Wl,--no-whole-archive  
   -L/mingw/lib /mingw/lib/libxml2.dll.a /mingw/lib/libgnutls.dll.a 
   -L/home/bsanders/inst_libgcrypt-1.4.1/lib -lintl -lpthread 
   /mingw/lib/libportablexdr.dll.a -lws2_32  
   -Wl,--version-script=./libvirt_sym.version -o .libs/libvirt-0.dll 
   -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker 
   .libs/libvirt.dll.a
   Creating library file: .libs/libvirt.dll.a
   .libs/libvirt_la-remote_protocol.o:remote_protocol.c:(.text+0xa46): 
   undefined reference to `htonl'
   .libs/libvirt_la-remote_protocol.o:remote_protocol.c:(.text+0xa5f): 
   undefined reference to

Re: [libvirt] libvirt on mingw: undefined reference to htonl/ntohl

2008-06-19 Thread Atsushi SAKAI

Hi, Brecht

I can compile and generate .a file on python directory.
Sorry for spelling (I am using Zen-kaku(2byte) character in your name.)

Thanks
Atsushi SAKAI


Atsushi SAKAI [EMAIL PROTECTED] wrote:

 Hi, Breｃｈｔ
 
 I can make .a file(not .dll).
 With following instruction.
 
 ==1==
 Install 
 http://www.python.org/ftp/python/2.5.2/python-2.5.2.msi
 to /usr/local/(C:\msys\1.0\local)
 
 and copy to include file to /usr/include/python2.5
 and copy /usr/local/python.exe pythonw.exe to /usr/local/bin
 
 ==2==
 Install to /usr/local (C:\msys\1.0\local)
 http://ftp.gnome.org/pub/GNOME/binaries/win32/pygobject/2.14/pygobject-2.14.1-1.win32-py2.5.exe
 
 make and make install seems work fine.
 
 Thanks
 Atsushi SAKAI
 
 
 
 
 
 Atsushi SAKAI [EMAIL PROTECTED] wrote:
 
  Hi, Brecht
  
   Just out of curiosity, have you done anything with virsh or the DLL you 
   have built?
  Yes
  
  By the way, I am doing to build Python bingings on MinGW.
  But it will need to do tomorrow, since many compilation warnings.
  
  Thanks
  Atsushi SAKAI
  
  
  
  
  Brecht Sanders [EMAIL PROTECTED] wrote:
  
   Hi,
   I guesss I had got as far as you did.
   To Install Python on Windows you will need to download and install the 
   following:
   http://www.python.org/ftp/python/2.5.2/python-2.5.2.msi
   
   http://ftp.gnome.org/pub/GNOME/binaries/win32/pygobject/2.14/pygobject-2.14.1-1.win32-py2.5.exe
   
   http://ftp.gnome.org/pub/GNOME/binaries/win32/pycairo/1.4/pycairo-1.4.12-1.win32-py2.5.exe
   
   http://ftp.gnome.org/pub/GNOME/binaries/win32/pygtk/2.12/pygtk-2.12.1-2.win32-py2.5.exe
   Also, don't forget to set some environment variables:
   export PYDIR=/C/Prog/Python25
   export PYTHONHOME=$PYDIR
   export PYTHONPATH=$PYDIR/Lib/site-packages
   export PATH=$MINGWPREFIX:$MINGWPREFIX/bin:$PATH
   Just out of curiosity, have you done anything with virsh or the DLL you 
   have built?
   Regards,
   Brecht
   
   Atsushi SAKAI wrote:
Hi, Bericht
   
By your suggestion, I am recognizing python bindings are not created(on 
my configuration).
If you notice me to install python on MinGW, I will try to investigate 
it.
   
My posting mail is follows(it does not create python library)
https://www.redhat.com/archives/libvir-list/2008-June/msg00201.html
It creates general library and virsh only.
   
Thanks
Atsushi SAKAI
   
   
Brecht Sanders [EMAIL PROTECTED] wrote:
   
  
No. Can you tell me where to find it?
I also noticed that I only produced one DLL: libvirt-0.dll.
No Python module DLL was built. Were you able to build this?
   
Atsushi SAKAI wrote:

Hi,
   
Did you check my instruction for libvirt on MinGW?
   
Thanks
Atsushi SAKAI
   
   
Brecht Sanders [EMAIL PROTECTED] wrote:
   
  
  
Hi,
Some time passed by and I thought I'd have another go at compiling 
libvirt for win32 using MinGW/MSYS again.
I tried to compile libvirt-0.4.3 and I got around most obstacles. 
Now it 
just seems I am stuck when it is trying to link.
My search on google showed me that I am not the first one to see 
this issue.
Usually i means -lws2_32 is in the wrong place. However I tried 
moving 
it around without luck.
Also it doesn't make sense to me that only htonl and ntohl are 
missing. 
It appears anything else used from the winsock library is found 
during 
linking.
I feel we're very close to getting libvirt compiled on win32. Or do 
you 
know if anyone already succeeded?
Regards
Brecht Sanders
   
gcc -shared  .libs/libvirt_la-libvirt.o .libs/libvirt_la-memory.o 
.libs/libvirt_la-hash.o .libs/libvirt_la-test.o 
.libs/libvirt_la-buf.o 
.libs/libvirt_la-qparams.o .libs/libvirt_la-capabilities.o 
.libs/libvirt_la-xml.o .libs/libvirt_la-event.o 
.libs/libvirt_la-xen_unified.o .libs/libvirt_la-xen_internal.o 
.libs/libvirt_la-xs_internal.o .libs/libvirt_la-xend_internal.o 
.libs/libvirt_la-stats_linux.o .libs/libvirt_la-sexpr.o 
.libs/libvirt_la-virterror.o .libs/libvirt_la-proxy_internal.o 
.libs/libvirt_la-conf.o .libs/libvirt_la-xm_internal.o 
.libs/libvirt_la-remote_internal.o .libs/libvirt_la-bridge.o 
.libs/libvirt_la-iptables.o .libs/libvirt_la-uuid.o 
.libs/libvirt_la-qemu_driver.o .libs/libvirt_la-qemu_conf.o 
.libs/libvirt_la-openvz_conf.o .libs/libvirt_la-openvz_driver.o 
.libs/libvirt_la-lxc_driver.o .libs/libvirt_la-lxc_conf.o 
.libs/libvirt_la-lxc_container.o .libs/libvirt_la-nodeinfo.o 
.libs/libvirt_la-util.o .libs/libvirt_la-remote_protocol.o 
-Wl,--whole-archive ../gnulib/lib/.libs/libgnu.a 
-Wl,--no-whole-archive  
-L/mingw/lib /mingw/lib/libxml2.dll.a /mingw/lib/libgnutls.dll.a 
-L/home/bsanders/inst_libgcrypt-1.4.1/lib -lintl -lpthread 
/mingw/lib/libportablexdr.dll.a -lws2_32

Re: [libvirt] [PATCH]: Fix allocation of tapfds when starting qemu

2008-06-19 Thread Jim Meyering

Chris Lalancette [EMAIL PROTECTED] wrote:
 Jim Meyering wrote:
 diff --git a/src/util.c b/src/util.c
 index ad7683d..5e50ef2 100644
 --- a/src/util.c
 +++ b/src/util.c
 @@ -306,7 +306,7 @@ fread_file_lim (FILE *stream, size_t max_len, size_t 
 *length)
  if (alloc  size + BUFSIZ + 1)
  alloc = size + BUFSIZ + 1;

 -if (VIR_ALLOC_N(buf, alloc)  0) {
 +if (VIR_REALLOC_N(buf, alloc)  0) {
  save_errno = errno;
  break;
  }
 @@ -797,4 +797,3 @@ int virDiskNameToIndex(const char *name) {

  return idx;
  }

 Yep.  Good catch.  Confirmed by following your test procedure, and confirmed
 that this fixes the issue.

 ACK

Thanks for the quick review.
I've gone ahead and added a small test script to exercise the bug,
so the following is what I now expect to commit.

From d13e980b70194528a191ffb95333960d7b3d49fd Mon Sep 17 00:00:00 2001
From: Jim Meyering [EMAIL PROTECTED]
Date: Thu, 19 Jun 2008 13:41:23 +0200
Subject: [PATCH] virsh fails to read files larger than BUFSIZ bytes

* src/util.c (fread_file_lim): Use VIR_REALLOC_N, not VIR_ALLOC_N.
Bug introduced in d3470efcda15f59549ac0aaa76cd25df319c217b.
* tests/Makefile.am (test_scripts): Add read-bufsiz.
* tests/read-bufsiz: New test for the above.
---
 src/util.c|3 +--
 tests/Makefile.am |1 +
 tests/read-bufsiz |   43 +++
 3 files changed, 45 insertions(+), 2 deletions(-)
 create mode 100755 tests/read-bufsiz

diff --git a/src/util.c b/src/util.c
index ad7683d..5e50ef2 100644
--- a/src/util.c
+++ b/src/util.c
@@ -306,7 +306,7 @@ fread_file_lim (FILE *stream, size_t max_len, size_t 
*length)
 if (alloc  size + BUFSIZ + 1)
 alloc = size + BUFSIZ + 1;

-if (VIR_ALLOC_N(buf, alloc)  0) {
+if (VIR_REALLOC_N(buf, alloc)  0) {
 save_errno = errno;
 break;
 }
@@ -797,4 +797,3 @@ int virDiskNameToIndex(const char *name) {

 return idx;
 }
-
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 303388c..4021a39 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -47,6 +47,7 @@ noinst_PROGRAMS = xmlrpctest xml2sexprtest sexpr2xmltest 
virshtest conftest \
 test_scripts = \
daemon-conf \
int-overflow \
+   read-bufsiz \
read-non-seekable \
vcpupin

diff --git a/tests/read-bufsiz b/tests/read-bufsiz
new file mode 100755
index 000..3037452
--- /dev/null
+++ b/tests/read-bufsiz
@@ -0,0 +1,43 @@
+#!/bin/sh
+# ensure that reading a file larger than BUFSIZ works
+
+# Copyright (C) 2008 Free Software Foundation, Inc.
+
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see http://www.gnu.org/licenses/.
+
+if test $VERBOSE = yes; then
+  set -x
+  virsh --version
+fi
+
+. $srcdir/test-lib.sh
+
+fail=0
+
+# Output a valid definition, to be used as input.
+virsh -c test:///default dumpxml 1  xml || fail=1
+
+for i in before after; do
+  # The largest BUFSIZ I've seen is 128K.  This is slightly larger.
+  printf %132000s ' '  sp || fail=1
+  in=in-$i
+  # Append or prepend enough spaces to push the size over the limit:
+  ( test $i = before  cat sp xml || cat xml sp )  $in || fail=1
+
+  virsh --connect test:///default define $in  out || fail=1
+  printf Domain test defined from $in\n\n  exp || fail=1
+  compare out exp || fail=1
+done
+
+(exit $fail); exit $fail
--
1.5.6.rc3.23.gc3bdd

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

Re: [libvirt] [PATCH]: Fix allocation of tapfds when starting qemu

2008-06-19 Thread Daniel Veillard

On Thu, Jun 19, 2008 at 01:56:11PM +0200, Jim Meyering wrote:
 Chris Lalancette [EMAIL PROTECTED] wrote:
  Jim Meyering wrote:
  diff --git a/src/util.c b/src/util.c
  index ad7683d..5e50ef2 100644
  --- a/src/util.c
  +++ b/src/util.c
  @@ -306,7 +306,7 @@ fread_file_lim (FILE *stream, size_t max_len, size_t 
  *length)
   if (alloc  size + BUFSIZ + 1)
   alloc = size + BUFSIZ + 1;
 
  -if (VIR_ALLOC_N(buf, alloc)  0) {
  +if (VIR_REALLOC_N(buf, alloc)  0) {
   save_errno = errno;
   break;
   }
  @@ -797,4 +797,3 @@ int virDiskNameToIndex(const char *name) {
 
   return idx;
   }
 
  Yep.  Good catch.  Confirmed by following your test procedure, and confirmed
  that this fixes the issue.
 
  ACK
 
 Thanks for the quick review.
 I've gone ahead and added a small test script to exercise the bug,
 so the following is what I now expect to commit.

  yes please !
+1

  thanks !

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard  | virtualization library  http://libvirt.org/
[EMAIL PROTECTED]  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

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

[libvirt] Test packages for various fixes

2008-06-19 Thread Chris Lalancette

I've sent a build through koji that contains 0.4.3 + iSCSI fixes + VIR_ALLOC
fixes + tapfd fixes for Fedora 9.  It's available here, if you want to test:

http://koji.fedoraproject.org/koji/taskinfo?taskID=670309

As usual, if there are any bugs that you find, please report them here.

Chris Lalancette

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

Re: [libvirt] libvirt on mingw: undefined reference to htonl/ntohl

2008-06-19 Thread Brecht Sanders

Hi,
On my end I also had built libvirtmod.a, but without a DLL version of
this file I don't think it will be loadable as a Python module.
Or is there a way to load or link static libraries somehow in Python?
Brecht

P.S.: I didn't understand your spelling remark.

Atsushi SAKAI wrote:
 Hi, Brecht

 I can compile and generate .a file on python directory.
 Sorry for spelling (I am using Zen-kaku(2byte) character in your name.)

 Thanks
 Atsushi SAKAI


 Atsushi SAKAI [EMAIL PROTECTED] wrote:

   
 Hi, Breｃｈｔ

 I can make .a file(not .dll).
 With following instruction.

 ==1==
 Install 
 http://www.python.org/ftp/python/2.5.2/python-2.5.2.msi
 to /usr/local/(C:\msys\1.0\local)

 and copy to include file to /usr/include/python2.5
 and copy /usr/local/python.exe pythonw.exe to /usr/local/bin

 ==2==
 Install to /usr/local (C:\msys\1.0\local)
 http://ftp.gnome.org/pub/GNOME/binaries/win32/pygobject/2.14/pygobject-2.14.1-1.win32-py2.5.exe

 make and make install seems work fine.

 Thanks
 Atsushi SAKAI





 Atsushi SAKAI [EMAIL PROTECTED] wrote:

 
 Hi, Brecht

   
 Just out of curiosity, have you done anything with virsh or the DLL you 
 have built?
 
 Yes

 By the way, I am doing to build Python bingings on MinGW.
 But it will need to do tomorrow, since many compilation warnings.

 Thanks
 Atsushi SAKAI




 Brecht Sanders [EMAIL PROTECTED] wrote:

   
 Hi,
 I guesss I had got as far as you did.
 To Install Python on Windows you will need to download and install the 
 following:
 http://www.python.org/ftp/python/2.5.2/python-2.5.2.msi
 
 http://ftp.gnome.org/pub/GNOME/binaries/win32/pygobject/2.14/pygobject-2.14.1-1.win32-py2.5.exe
 
 http://ftp.gnome.org/pub/GNOME/binaries/win32/pycairo/1.4/pycairo-1.4.12-1.win32-py2.5.exe
 
 http://ftp.gnome.org/pub/GNOME/binaries/win32/pygtk/2.12/pygtk-2.12.1-2.win32-py2.5.exe
 Also, don't forget to set some environment variables:
 export PYDIR=/C/Prog/Python25
 export PYTHONHOME=$PYDIR
 export PYTHONPATH=$PYDIR/Lib/site-packages
 export PATH=$MINGWPREFIX:$MINGWPREFIX/bin:$PATH
 Just out of curiosity, have you done anything with virsh or the DLL you 
 have built?
 Regards,
 Brecht

 Atsushi SAKAI wrote:
 
 Hi, Bericht

 By your suggestion, I am recognizing python bindings are not created(on 
 my configuration).
 If you notice me to install python on MinGW, I will try to investigate it.

 My posting mail is follows(it does not create python library)
 https://www.redhat.com/archives/libvir-list/2008-June/msg00201.html
 It creates general library and virsh only.

 Thanks
 Atsushi SAKAI


 Brecht Sanders [EMAIL PROTECTED] wrote:

   
   
 No. Can you tell me where to find it?
 I also noticed that I only produced one DLL: libvirt-0.dll.
 No Python module DLL was built. Were you able to build this?

 Atsushi SAKAI wrote:
 
 
 Hi,

 Did you check my instruction for libvirt on MinGW?

 Thanks
 Atsushi SAKAI


 Brecht Sanders [EMAIL PROTECTED] wrote:

   
   
   
 Hi,
 Some time passed by and I thought I'd have another go at compiling 
 libvirt for win32 using MinGW/MSYS again.
 I tried to compile libvirt-0.4.3 and I got around most obstacles. Now 
 it 
 just seems I am stuck when it is trying to link.
 My search on google showed me that I am not the first one to see this 
 issue.
 Usually i means -lws2_32 is in the wrong place. However I tried moving 
 it around without luck.
 Also it doesn't make sense to me that only htonl and ntohl are 
 missing. 
 It appears anything else used from the winsock library is found during 
 linking.
 I feel we're very close to getting libvirt compiled on win32. Or do 
 you 
 know if anyone already succeeded?
 Regards
 Brecht Sanders

 gcc -shared  .libs/libvirt_la-libvirt.o .libs/libvirt_la-memory.o 
 .libs/libvirt_la-hash.o .libs/libvirt_la-test.o .libs/libvirt_la-buf.o 
 .libs/libvirt_la-qparams.o .libs/libvirt_la-capabilities.o 
 .libs/libvirt_la-xml.o .libs/libvirt_la-event.o 
 .libs/libvirt_la-xen_unified.o .libs/libvirt_la-xen_internal.o 
 .libs/libvirt_la-xs_internal.o .libs/libvirt_la-xend_internal.o 
 .libs/libvirt_la-stats_linux.o .libs/libvirt_la-sexpr.o 
 .libs/libvirt_la-virterror.o .libs/libvirt_la-proxy_internal.o 
 .libs/libvirt_la-conf.o .libs/libvirt_la-xm_internal.o 
 .libs/libvirt_la-remote_internal.o .libs/libvirt_la-bridge.o 
 .libs/libvirt_la-iptables.o .libs/libvirt_la-uuid.o 
 .libs/libvirt_la-qemu_driver.o .libs/libvirt_la-qemu_conf.o 
 .libs/libvirt_la-openvz_conf.o .libs/libvirt_la-openvz_driver.o 
 .libs/libvirt_la-lxc_driver.o .libs/libvirt_la-lxc_conf.o 
 .libs/libvirt_la-lxc_container.o .libs/libvirt_la-nodeinfo.o 
 .libs/libvirt_la-util.o .libs/libvirt_la-remote_protocol.o 
 -Wl,--whole-archive ../gnulib/lib/.libs/libgnu.a 
 -Wl,--no-whole-archive  
 -L/mingw/lib /mingw/lib/libxml2.dll.a /mingw/lib/libgnutls.dll.a 
 -L/home/bsanders/inst_libgcrypt-1.4.1/lib -lintl -lpthread 
 /mingw/lib/libportablexdr.dll.a

[libvirt] [PATCH] Fix XML escaping problem in the XM driver

2008-06-19 Thread Daniel Veillard

  Basically the XM driver when generating the XML config forgets to
escape things like filepaths allowing characters which are forbidden
as-is in XML instances to pass in the resulting config files which 
then are unusable.
  The patch also adds a new test checking the escaping is done
in a few critical places.

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard  | virtualization library  http://libvirt.org/
[EMAIL PROTECTED]  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/
Index: src/xm_internal.c
===
RCS file: /data/cvs/libxen/src/xm_internal.c,v
retrieving revision 1.82
diff -u -p -u -p -r1.82 xm_internal.c
--- src/xm_internal.c   10 Jun 2008 14:39:58 -  1.82
+++ src/xm_internal.c   19 Jun 2008 15:31:25 -
@@ -599,7 +599,7 @@ char *xenXMDomainFormatXML(virConnectPtr
 return (NULL);
 
 virBufferAddLit(buf, domain type='xen'\n);
-virBufferVSprintf(buf,   name%s/name\n, name);
+virBufferEscapeString(buf,   name%s/name\n, name);
 virUUIDFormat(uuid, uuidstr);
 virBufferVSprintf(buf,   uuid%s/uuid\n, uuidstr);
 
@@ -612,7 +612,7 @@ char *xenXMDomainFormatXML(virConnectPtr
 virBufferAddLit(buf,   os\n);
 virBufferAddLit(buf, typehvm/type\n);
 if (xenXMConfigGetString(conf, kernel, str) == 0)
-virBufferVSprintf(buf, loader%s/loader\n, str);
+virBufferEscapeString(buf, loader%s/loader\n, str);
 
 if (xenXMConfigGetString(conf, boot, boot)  0)
 boot = c;
@@ -639,15 +639,15 @@ char *xenXMDomainFormatXML(virConnectPtr
 } else {
 
 if (xenXMConfigGetString(conf, bootloader, str) == 0)
-virBufferVSprintf(buf,   bootloader%s/bootloader\n, str);
+virBufferEscapeString(buf,   bootloader%s/bootloader\n, 
str);
 if (xenXMConfigGetString(conf, bootargs, str) == 0)
 virBufferEscapeString(buf,   
bootloader_args%s/bootloader_args\n, str);
 if (xenXMConfigGetString(conf, kernel, str) == 0) {
 virBufferAddLit(buf,   os\n);
 virBufferAddLit(buf, typelinux/type\n);
-virBufferVSprintf(buf, kernel%s/kernel\n, str);
+virBufferEscapeString(buf, kernel%s/kernel\n, str);
 if (xenXMConfigGetString(conf, ramdisk, str) == 0)
-virBufferVSprintf(buf, initrd%s/initrd\n, str);
+virBufferEscapeString(buf, initrd%s/initrd\n, str);
 if (xenXMConfigGetString(conf, extra, str) == 0)
 virBufferEscapeString(buf, cmdline%s/cmdline\n, 
str);
 virBufferAddLit(buf,   /os\n);
@@ -714,7 +714,7 @@ char *xenXMDomainFormatXML(virConnectPtr
 
 if (hvm) {
 if (xenXMConfigGetString(conf, device_model, str) == 0)
-virBufferVSprintf(buf, emulator%s/emulator\n, str);
+virBufferEscapeString(buf, emulator%s/emulator\n, str);
 }
 
 list = virConfGetValue(conf, disk);
@@ -816,9 +816,12 @@ char *xenXMDomainFormatXML(virConnectPtr
 virBufferVSprintf(buf,   driver name='%s' 
type='%s'/\n, drvName, drvType);
 else
 virBufferVSprintf(buf,   driver name='%s'/\n, 
drvName);
-if (src[0])
-virBufferVSprintf(buf,   source %s='%s'/\n, block ? 
dev : file, src);
-virBufferVSprintf(buf,   target dev='%s' bus='%s'/\n, 
dev, bus);
+if (src[0]) {
+virBufferVSprintf(buf,   source %s=, block ? dev : 
file);
+   virBufferEscapeString(buf, '%s'/\n,  src);
+   }
+virBufferEscapeString(buf,   target dev='%s', dev);
+virBufferVSprintf(buf,  bus='%s'/\n, bus);
 if (STREQ(head, r) ||
 STREQ(head, ro))
 virBufferAddLit(buf,   readonly/\n);
@@ -836,7 +839,7 @@ char *xenXMDomainFormatXML(virConnectPtr
 if (xenXMConfigGetString(conf, cdrom, str) == 0) {
 virBufferAddLit(buf, disk type='file' device='cdrom'\n);
 virBufferAddLit(buf,   driver name='file'/\n);
-virBufferVSprintf(buf,   source file='%s'/\n, str);
+virBufferEscapeString(buf,   source file='%s'/\n, str);
 virBufferAddLit(buf,   target dev='hdc' bus='ide'/\n);
 virBufferAddLit(buf,   readonly/\n);
 virBufferAddLit(buf, /disk\n);
@@ -924,7 +927,7 @@ char *xenXMDomainFormatXML(virConnectPtr
 if (type == 1  bridge[0])
 virBufferVSprintf(buf,   source bridge='%s'/\n, 
bridge);
 if (script[0])
-virBufferVSprintf(buf,   script path='%s'/\n, script);
+virBufferEscapeString(buf,   script path='%s'/\n, 
script);
 if (ip[0])

[libvirt] [PATCH 0 of 3] LXC network interface support

2008-06-19 Thread Dan Smith

This set is actually authored by Dave Leskovec.  He is moving on to some other
work and I will be working this into the tree.  I have made a few changes
to this, mostly to allow this code to compile out if the proper kernel
and userspace support is not present.

I am submitting it as an RFC because the required kernel patches are not yet
upstream (even in -mm) and there are some missing userspace patches to
iproute2 as well.  I expect there to be quite a few comments and suggestions
about the veth.c patch, so I wanted to go ahead and get that started while
we wait for upstream to catch up.

Comments appreciated!

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

[libvirt] [PATCH 1 of 3] [LXC] Add functions to manage veth device pairs

2008-06-19 Thread Dan Smith

# HG changeset patch
# User Dave Leskovec [EMAIL PROTECTED]
# Date 1213891164 25200
# Node ID 386c067de8995028dd11f70602081c31682dd293
# Parent  8d2afc533c91c4796512e1e71c8283e86eafd18a
[LXC] Add functions to manage veth device pairs

This gives us the ability to create a veth pair so that we can move one
into the network namespace of an LXC container.

diff -r 8d2afc533c91 -r 386c067de899 configure.in
--- a/configure.in  Tue Jun 17 15:55:03 2008 +
+++ b/configure.in  Thu Jun 19 08:59:24 2008 -0700
@@ -301,6 +301,20 @@
 if test $with_qemu = yes ; then
   AC_CHECK_HEADERS([linux/param.h linux/sockios.h linux/if_bridge.h 
linux/if_tun.h],,
AC_MSG_ERROR([You must install kernel-headers in order to 
compile libvirt]))
+fi
+
+dnl
+dnl check for patched iproute2 for lxc network support
+dnl
+if test $with_lxc = yes ; then
+   AC_MSG_CHECKING([for NETNS support])
+   if ip link help 21 | grep -q netns; then
+ with_lxc_netns=yes
+ AC_DEFINE([HAVE_NETNS], [], [Kernel has NETNS support])
+   else
+ with_lxc_netns=no
+   fi
+   AC_MSG_RESULT($with_lxc_netns)
 fi
 
 dnl Need to test if pkg-config exists
diff -r 8d2afc533c91 -r 386c067de899 src/Makefile.am
--- a/src/Makefile.am   Tue Jun 17 15:55:03 2008 +
+++ b/src/Makefile.am   Thu Jun 19 08:59:24 2008 -0700
@@ -64,6 +64,7 @@
lxc_driver.c lxc_driver.h   \
lxc_conf.c lxc_conf.h   \
lxc_container.c lxc_container.h \
+   veth.c veth.h   \
 nodeinfo.h nodeinfo.c   \
util.c util.h
 
diff -r 8d2afc533c91 -r 386c067de899 src/veth.c
--- /dev/null   Thu Jan 01 00:00:00 1970 +
+++ b/src/veth.cThu Jun 19 08:59:24 2008 -0700
@@ -0,0 +1,247 @@
+/*
+ * Copyright IBM Corp. 2008
+ *
+ * veth.c: file description
+ *
+ * Authors:
+ *  David L. Leskovec dlesko at linux.vnet.ibm.com
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include config.h
+
+#ifdef HAVE_NETNS
+
+#include string.h
+
+#include veth.h
+#include internal.h
+#include memory.h
+#include util.h
+
+#define DEBUG(fmt,...) VIR_DEBUG(__FILE__, fmt, __VA_ARGS__)
+#define DEBUG0(msg) VIR_DEBUG(__FILE__, %s, msg)
+
+/* Functions */
+/**
+ * getFreeVethName:
+ * @veth: name for veth device (NULL to find first open)
+ * @maxLen: max length of veth name
+ * @startDev: device number to start at (x in vethx)
+ *
+ * Looks in /sys/class/net/ to find the first available veth device
+ * name.
+ *
+ * Returns 0 on success or -1 in case of error
+ */
+static int getFreeVethName(char *veth, int maxLen, int startDev)
+{
+int rc = -1;
+int devNum = startDev;
+char path[PATH_MAX];
+
+snprintf(path, PATH_MAX, /sys/class/net/veth%d/, devNum);
+while (virFileExists(path)) {
+++devNum;
+sprintf(path, /sys/class/net/veth%d/, devNum);
+}
+
+snprintf(veth, maxLen, veth%d, devNum);
+
+rc = devNum;
+
+return rc;
+}
+
+/**
+ * vethCreate:
+ * @veth1: name for one end of veth pair
+ * @veth1MaxLen: max length of veth1 name
+ * @veth2: name for one end of veth pair
+ * @veth2MaxLen: max length of veth1 name
+ *
+ * Creates a veth device pair using the ip command:
+ * ip link add veth1 type veth peer name veth2
+ * NOTE: If veth1 and veth2 names are not specified, ip will auto assign
+ *   names.  There seems to be two problems here -
+ *   1) There doesn't seem to be a way to determine the names of the
+ *  devices that it creates.  They show up in ip link show and
+ *  under /sys/class/net/ however there is no guarantee that they
+ *  are the devices that this process just created.
+ *   2) Once one of the veth devices is moved to another namespace, it
+ *  is no longer visible in the parent namespace.  This seems to
+ *  confuse the name assignment causing it to fail with File exists.
+ *   Because of these issues, this function currently forces the caller
+ *   to fully specify the veth device names.
+ *
+ * Returns 0 on success or -1 in case of error
+ */
+int vethCreate(char* veth1, int veth1MaxLen,
+   char* veth2, int veth2MaxLen)
+{
+int rc = -1;
+const char *argv[] =

[libvirt] [PATCH 2 of 3] [LXC] Add XML parsing of container network interfaces

2008-06-19 Thread Dan Smith

# HG changeset patch
# User Dave Leskovec [EMAIL PROTECTED]
# Date 1213891177 25200
# Node ID acf369a2543ad52b235ae8541c8ad05670e255bd
# Parent  386c067de8995028dd11f70602081c31682dd293
[LXC] Add XML parsing of container network interfaces.

diff -r 386c067de899 -r acf369a2543a src/lxc_conf.c
--- a/src/lxc_conf.cThu Jun 19 08:59:24 2008 -0700
+++ b/src/lxc_conf.cThu Jun 19 08:59:37 2008 -0700
@@ -70,6 +70,191 @@
 codeErrorMessage, errorMessage, NULL, 0, 0,
 codeErrorMessage, errorMessage);
 }
+
+#ifdef HAVE_NETNS
+/**
+ * lxcParseInterfaceXML:
+ * @conn: pointer to connection
+ * @nodePtr: pointer to xml node structure
+ * @vm: pointer to net definition structure to fill in
+ *
+ * Parses the XML for a network interface and places the configuration
+ * in the given structure.
+ *
+ * Returns 0 on success or -1 in case of error
+ */
+static int lxcParseInterfaceXML(virConnectPtr conn, xmlNodePtr nodePtr,
+lxc_net_def_t *netDef)
+{
+int rc = -1;
+xmlNodePtr cur;
+xmlChar *type = NULL;
+xmlChar *parentIfName = NULL;
+xmlChar *network = NULL;
+xmlChar *bridge = NULL;
+xmlChar *macaddr = NULL;
+
+netDef-type = LXC_NET_NETWORK;
+
+type = xmlGetProp(nodePtr, BAD_CAST type);
+if (type != NULL) {
+if (xmlStrEqual(type, BAD_CAST network)) {
+netDef-type = LXC_NET_NETWORK;
+}
+else if (xmlStrEqual(type, BAD_CAST bridge)) {
+netDef-type = LXC_NET_BRIDGE;
+}
+else {
+lxcError(conn, NULL, VIR_ERR_XML_ERROR,
+ _(invalid interface type: %s), type);
+goto error_out;
+}
+}
+
+cur = nodePtr-children;
+for (cur = nodePtr-children; cur != NULL; cur = cur-next) {
+if (cur-type == XML_ELEMENT_NODE) {
+DEBUG(cur-name: %s, (char*)(cur-name));
+if ((macaddr == NULL) 
+(xmlStrEqual(cur-name, BAD_CAST mac))) {
+macaddr = xmlGetProp(cur, BAD_CAST address);
+} else if ((network == NULL) 
+   (netDef-type == LXC_NET_NETWORK) 
+   (xmlStrEqual(cur-name, BAD_CAST source))) {
+network = xmlGetProp(cur, BAD_CAST network);
+parentIfName = xmlGetProp(cur, BAD_CAST dev);
+} else if ((bridge == NULL) 
+   (netDef-type == LXC_NET_BRIDGE) 
+   (xmlStrEqual(cur-name, BAD_CAST source))) {
+bridge = xmlGetProp(cur, BAD_CAST bridge);
+} else if ((parentIfName == NULL) 
+   (xmlStrEqual(cur-name, BAD_CAST target))) {
+parentIfName = xmlGetProp(cur, BAD_CAST dev);
+}
+}
+}
+
+if (netDef-type == LXC_NET_NETWORK) {
+if (network == NULL) {
+lxcError(conn, NULL, VIR_ERR_XML_ERROR,
+ _(No source 'network' attribute specified with 
interface type='network'/));
+goto error_out;
+}
+
+netDef-txName = strdup((char *)network);
+if (NULL == netDef-txName) {
+lxcError(conn, NULL, VIR_ERR_NO_MEMORY,
+ _(No storage for network name));
+goto error_out;
+}
+
+} else if (netDef-type == LXC_NET_BRIDGE) {
+if (bridge == NULL) {
+lxcError(conn, NULL, VIR_ERR_XML_ERROR,
+ _(No source 'bridge' attribute specified with 
interface type='bridge'/));
+goto error_out;
+}
+
+netDef-txName = strdup((char *)bridge);
+if (NULL == netDef-txName) {
+lxcError(conn, NULL, VIR_ERR_NO_MEMORY,
+ _(No storage for bridge name));
+goto error_out;
+}
+}
+
+if (parentIfName != NULL) {
+DEBUG(set netDef-parentVeth: %s, netDef-parentVeth);
+netDef-parentVeth = strdup((char *)parentIfName);
+if (NULL == netDef-parentVeth) {
+lxcError(conn, NULL, VIR_ERR_NO_MEMORY,
+ _(No storage for parent veth device name));
+goto error_out;
+}
+} else {
+netDef-parentVeth = NULL;
+DEBUG0(set netDef-parentVeth: NULL);
+}
+
+rc = 0;
+
+error_out:
+xmlFree(macaddr);
+macaddr = NULL;
+xmlFree(network);
+network = NULL;
+xmlFree(bridge);
+bridge = NULL;
+xmlFree(parentIfName);
+parentIfName = NULL;
+
+return rc;
+}
+
+/**
+ * lxcParseDomainInterfaces:
+ * @conn: pointer to connection
+ * @nets: on success, points to an list of net def structs
+ * @contextPtr: pointer to xml context
+ *
+ * Parses the domain network interfaces and returns the information in a list
+ *
+ * Returns 0 on success or -1 in case of error
+ */
+static int lxcParseDomainInterfaces(virConnectPtr conn,
+lxc_net_def_t **nets,
+

[libvirt] [PATCH 3 of 3] [LXC] Add setup/cleanup of container network interfaces

2008-06-19 Thread Dan Smith

# HG changeset patch
# User Dan Smith [EMAIL PROTECTED]
# Date 1213891185 25200
# Node ID cb780a7b3ad591f1a9392d6528218b3aa2c3483d
# Parent  acf369a2543ad52b235ae8541c8ad05670e255bd
[LXC] Add setup/cleanup of container network interfaces

diff -r acf369a2543a -r cb780a7b3ad5 src/lxc_conf.h
--- a/src/lxc_conf.hThu Jun 19 08:59:37 2008 -0700
+++ b/src/lxc_conf.hThu Jun 19 08:59:45 2008 -0700
@@ -35,6 +35,12 @@
 #define LXC_MAX_XML_LENGTH 16384
 #define LXC_MAX_ERROR_LEN 1024
 #define LXC_DOMAIN_TYPE lxc
+#define LXC_PARENT_SOCKET 0
+#define LXC_CONTAINER_SOCKET 1
+
+/* messages between parent and container */
+typedef char lxc_message_t;
+#define LXC_CONTINUE_MSG 'c'
 
 /* types of networks for containers */
 enum lxc_net_type {
@@ -96,6 +102,8 @@
 int parentTty;
 int containerTtyFd;
 char *containerTty;
+
+int sockpair[2];
 
 lxc_vm_def_t *def;
 
diff -r acf369a2543a -r cb780a7b3ad5 src/lxc_container.c
--- a/src/lxc_container.c   Thu Jun 19 08:59:37 2008 -0700
+++ b/src/lxc_container.c   Thu Jun 19 08:59:45 2008 -0700
@@ -36,6 +36,7 @@
 #include lxc_conf.h
 #include util.h
 #include memory.h
+#include veth.h
 
 #define DEBUG(fmt,...) VIR_DEBUG(__FILE__, fmt, __VA_ARGS__)
 #define DEBUG0(msg) VIR_DEBUG(__FILE__, %s, msg)
@@ -159,6 +160,74 @@
 }
 
 /**
+ * lxcWaitForContinue:
+ * @vm: Pointer to vm structure
+ *
+ * This function will wait for the container continue message from the
+ * parent process.  It will send this message on the socket pair stored in
+ * the vm structure once it has completed the post clone container setup.
+ *
+ * Returns 0 on success or -1 in case of error
+ */
+static int lxcWaitForContinue(lxc_vm_t *vm)
+{
+int rc = -1;
+lxc_message_t msg;
+int readLen = 0;
+
+readLen = saferead(vm-sockpair[LXC_CONTAINER_SOCKET], msg, sizeof(msg));
+if (readLen != sizeof(msg)) {
+lxcError(NULL, NULL, VIR_ERR_INTERNAL_ERROR,
+ _(Failed to read the container continue message: %s),
+ strerror(errno));
+goto error_out;
+}
+
+DEBUG0(Received container continue message);
+
+close(vm-sockpair[LXC_PARENT_SOCKET]);
+vm-sockpair[LXC_PARENT_SOCKET] = -1;
+close(vm-sockpair[LXC_CONTAINER_SOCKET]);
+vm-sockpair[LXC_CONTAINER_SOCKET] = -1;
+
+rc = 0;
+
+error_out:
+return rc;
+}
+
+#ifdef HAVE_NETNS
+/**
+ * lxcEnableInterfaces:
+ * @vm: Pointer to vm structure
+ *
+ * This function will enable the interfaces for this container.
+ *
+ * Returns 0 on success or -1 in case of error
+ */
+static int lxcEnableInterfaces(lxc_vm_t *vm)
+{
+int rc = -1;
+lxc_net_def_t *net = vm-def-nets;
+int i = 0;
+
+for (i = 0; net; net = net-next) {
+DEBUG(Enabling %s, net-containerVeth);
+rc =  vethInterfaceUpOrDown(net-containerVeth, 1);
+if (0 != rc) {
+goto error_out;
+}
+}
+
+/* enable lo device */
+rc =  vethInterfaceUpOrDown(lo, 1);
+
+error_out:
+return rc;
+}
+#endif /* HAVE_NETNS */
+
+/**
  * lxcChild:
  * @argv: Pointer to container arguments
  *
@@ -210,6 +279,18 @@
 goto cleanup;
 }
 
+/* Wait for interface devices to show up */
+if (0 != (rc = lxcWaitForContinue(vm))) {
+goto cleanup;
+}
+
+#ifdef HAVE_NETNS
+/* enable interfaces */
+if (0 != (rc = lxcEnableInterfaces(vm))) {
+goto cleanup;
+}
+#endif
+
 rc = lxcExecWithTty(vm);
 /* this function will only return if an error occured */
 
diff -r acf369a2543a -r cb780a7b3ad5 src/lxc_driver.c
--- a/src/lxc_driver.c  Thu Jun 19 08:59:37 2008 -0700
+++ b/src/lxc_driver.c  Thu Jun 19 08:59:45 2008 -0700
@@ -44,6 +44,9 @@
 #include memory.h
 #include util.h
 #include memory.h
+#include bridge.h
+#include qemu_conf.h
+#include veth.h
 
 /* debug macros */
 #define DEBUG(fmt,...) VIR_DEBUG(__FILE__, fmt, __VA_ARGS__)
@@ -66,6 +69,9 @@
 #ifndef CLONE_NEWIPC
 #define CLONE_NEWIPC  0x0800
 #endif
+#ifndef CLONE_NEWNET
+#define CLONE_NEWNET  0x4000 /* New network namespace */
+#endif
 
 static int lxcStartup(void);
 static int lxcShutdown(void);
@@ -81,6 +87,9 @@
 {
 int rc = 0;
 int flags = CLONE_NEWPID|CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWUSER|
+#ifdef HAVE_NETNS
+CLONE_NEWNET|
+#endif
 CLONE_NEWIPC|SIGCHLD;
 int cpid;
 char *childStack;
@@ -237,6 +246,9 @@
 static int lxcNumDomains(virConnectPtr conn)
 {
 lxc_driver_t *driver = (lxc_driver_t *)conn-privateData;
+
+DEBUG(driver: %p network: %p, conn-privateData, 
conn-networkPrivateData);
+
 return driver-nactivevms;
 }
 
@@ -384,6 +396,197 @@
 return lxcGenerateXML(dom-conn, driver, vm, vm-def);
 }
 
+#ifdef HAVE_NETNS
+/**
+ * lxcSetupInterfaces:
+ * @conn: pointer to connection
+ * @vm: pointer to virtual machine structure
+ *
+ * Sets up the container interfaces by creating the veth device pairs and
+ * attaching the parent end to the appropriate bridge.  The container end
+ * will moved into the

Re: [libvirt] [PATCH 1 of 3] [LXC] Add functions to manage veth device pairs

2008-06-19 Thread Daniel Veillard

On Thu, Jun 19, 2008 at 08:59:52AM -0700, Dan Smith wrote:
 # HG changeset patch
 # User Dave Leskovec [EMAIL PROTECTED]
 # Date 1213891164 25200
 # Node ID 386c067de8995028dd11f70602081c31682dd293
 # Parent  8d2afc533c91c4796512e1e71c8283e86eafd18a
 [LXC] Add functions to manage veth device pairs
 
 This gives us the ability to create a veth pair so that we can move one
 into the network namespace of an LXC container.

  Basically it's executing ip commands, so the real code changes are outside
of libvirt.

 diff -r 8d2afc533c91 -r 386c067de899 configure.in
 --- a/configure.inTue Jun 17 15:55:03 2008 +
 +++ b/configure.inThu Jun 19 08:59:24 2008 -0700
 @@ -301,6 +301,20 @@
  if test $with_qemu = yes ; then
AC_CHECK_HEADERS([linux/param.h linux/sockios.h linux/if_bridge.h 
 linux/if_tun.h],,
 AC_MSG_ERROR([You must install kernel-headers in order to 
 compile libvirt]))
 +fi
 +
 +dnl
 +dnl check for patched iproute2 for lxc network support
 +dnl
 +if test $with_lxc = yes ; then
 +   AC_MSG_CHECKING([for NETNS support])
 +   if ip link help 21 | grep -q netns; then
 + with_lxc_netns=yes
 + AC_DEFINE([HAVE_NETNS], [], [Kernel has NETNS support])
 +   else
 + with_lxc_netns=no
 +   fi
 +   AC_MSG_RESULT($with_lxc_netns)
  fi

 Hum, it's not only a kernel feature, it looks more like a dependancy on
iproute, maybe that can be checked at runtime when initializing the lxc 
module, no ?

[...]
 +static int getFreeVethName(char *veth, int maxLen, int startDev)
 +{
 +int rc = -1;
 +int devNum = startDev;
 +char path[PATH_MAX];
 +
 +snprintf(path, PATH_MAX, /sys/class/net/veth%d/, devNum);
 +while (virFileExists(path)) {
 +++devNum;
 +sprintf(path, /sys/class/net/veth%d/, devNum);

  use snprintf there too

 +}
 +
 +snprintf(veth, maxLen, veth%d, devNum);
 +
 +rc = devNum;
 +
 +return rc;
 +}
 +
 +/**
 + * vethCreate:
 + * @veth1: name for one end of veth pair
 + * @veth1MaxLen: max length of veth1 name
 + * @veth2: name for one end of veth pair
 + * @veth2MaxLen: max length of veth1 name
 + *
 + * Creates a veth device pair using the ip command:
 + * ip link add veth1 type veth peer name veth2
 + * NOTE: If veth1 and veth2 names are not specified, ip will auto assign
 + *   names.  There seems to be two problems here -
 + *   1) There doesn't seem to be a way to determine the names of the
 + *  devices that it creates.  They show up in ip link show and
 + *  under /sys/class/net/ however there is no guarantee that they
 + *  are the devices that this process just created.
 + *   2) Once one of the veth devices is moved to another namespace, it
 + *  is no longer visible in the parent namespace.  This seems to
 + *  confuse the name assignment causing it to fail with File exists.
 + *   Because of these issues, this function currently forces the caller
 + *   to fully specify the veth device names.
 + *
 + * Returns 0 on success or -1 in case of error
 + */
 +int vethCreate(char* veth1, int veth1MaxLen,
 +   char* veth2, int veth2MaxLen)
 +{
 +int rc = -1;
 +const char *argv[] = {

I think Jim insists on having const char const * [], but I bet he will explain
this better than me :-)

 +ip, link, add, veth1, type, veth, peer, name, veth2, 
 NULL
 +};
[...]
 +/**
 + * moveInterfaceToNetNs:
 + * @interface: name of device
 + * @pidInNs: PID of process in target net namespace
 + *
 + * Moves the given device into the target net namespace specified by the 
 given
 + * pid using this command:
 + * ip link set interface netns pidInNs
 + *
 + * Returns 0 on success or -1 in case of error
 + */
 +int moveInterfaceToNetNs(const char* interface, int pidInNs)
 +{
 +int rc;
 +/* offset of the pid field in the following args */
 +const int pidArgvOffset = 5;
 +const char *argv[] = {
 +ip, link, set, interface, netns, NULL, NULL
 +};
 +int cmdResult;
 +int len;
 +
 +if (NULL == interface) {
 +goto error_out;
 +}
 +
 +if (0 != VIR_ALLOC_N(argv[pidArgvOffset], (sizeof(int) * 3) + 1)) {
 +goto error_out;
 +}

   Hum, here i don't understand, if argv is defined as local stack data,
I find a bit confusing to use it in the argument for VIR_ALLOC_N. I would
use an intermediate local variable to make this cleaner/ easier to read.

 +len = snprintf(argv[pidArgvOffset], (sizeof(int) * 3) + 1, %d, 
 pidInNs);

  yeah I'm getting very confused by that code :-)

 +if (len = (sizeof(int) * 3) + 1) {
 +goto cleanup;
 +}
 +
 +rc = virRun(NULL, (char**)argv, cmdResult);
 +
 +if (0 == rc) {
 +   rc = cmdResult;
 +}
 +
 +cleanup:
 +VIR_FREE(argv[pidArgvOffset]);
 +
 +error_out:
 +return rc;
 +}
 +
 +#endif /* HAVE_NETNS */
 +
 diff -r 8d2afc533c91 -r 386c067de899 src/veth.h
 --- /dev/null Thu Jan 01 00:00:00 1970 +
 +++ b/src/veth.h  Thu

Re: [libvirt] [PATCH 1 of 3] [LXC] Add functions to manage veth device pairs

2008-06-19 Thread Dan Smith

DV Hum, it's not only a kernel feature, it looks more like a
DV dependancy on iproute, maybe that can be checked at runtime when
DV initializing the lxc module, no ?

I suppose I could actually let it fail when it tries to do the actual
move.  Would you rather a specific test during the define stage to
reject the interface if the non-netns 'ip' command is found?

 +if (0 != VIR_ALLOC_N(argv[pidArgvOffset], (sizeof(int) * 3) + 1)) {
 +goto error_out;
 +}

DVHum, here i don't understand, if argv is defined as local stack data,
DV I find a bit confusing to use it in the argument for VIR_ALLOC_N. I would
DV use an intermediate local variable to make this cleaner/ easier to read.

 +len = snprintf(argv[pidArgvOffset], (sizeof(int) * 3) + 1, %d, 
 pidInNs);

DV   yeah I'm getting very confused by that code :-)

Agreed, I'll fix it up :)

DV   Oh can you use

DV /*
DV  * veth.h:  a proper file description :-) 
DV  *
DV  * Copyright IBM Corp. 2008
DV  *
DV  * See COPYING.LIB for the License of this software
DV  *
DV  * Authors:
DV  *  David L. Leskovec dlesko at linux.vnet.ibm.com
DV  */

DV as the header template for the two new files to match the other files.
DV COPYING.LIB is of course LGPL 2.1

Okay, I'll change it.

Thanks!

-- 
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]


pgpS5wIMskw77.pgp
Description: PGP signature
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 1 of 3] [LXC] Add functions to manage veth device pairs

2008-06-19 Thread Dan Smith

DS # HG changeset patch
DS # User Dave Leskovec [EMAIL PROTECTED]
DS # Date 1213891164 25200
DS # Node ID 386c067de8995028dd11f70602081c31682dd293
DS # Parent  8d2afc533c91c4796512e1e71c8283e86eafd18a
DS [LXC] Add functions to manage veth device pairs

My apologies for the HG headers.  I forgot the --plain when I sent it
out...

-- 
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]


pgpQ4fsElwxWG.pgp
Description: PGP signature
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[patch] python binding on mingw-make Re: [libvirt] libvirt on mingw: undefined reference to htonl/ntohl

2008-06-19 Thread Atsushi SAKAI

Hi, Brecht

How about apply this patch.
(dll.a is created.)
But need to dig into the code.
(many errors are appeared.)

Attached patch should be applied after
https://www.redhat.com/archives/libvir-list/2008-June/msg00196.html
(the patch is waiting for Dan review)
Instruction should be in
==Step1==
https://www.redhat.com/archives/libvir-list/2008-June/msg00201.html
==Step2==
https://www.redhat.com/archives/libvir-list/2008-June/msg00221.html

PS issue is internationalization of language issue.
Please neglect.
(ASCII[A-Z] can also write in 2-byte code)

Thanks
Atsushi SAKAI

Brecht Sanders [EMAIL PROTECTED] wrote:

Hi,
On my end I also had built libvirtmod.a, but without a DLL version of
this file I don't think it will be loadable as a Python module.
Or is there a way to load or link static libraries somehow in Python?
Brecht

P.S.: I didn't understand your spelling remark.

Atsushi SAKAI wrote:
Hi, Brecht

I can compile and generate .a file on python directory.
Sorry for spelling (I am using Zen-kaku(2byte) character in your name.)

Thanks
Atsushi SAKAI

Atsushi SAKAI [EMAIL PROTECTED] wrote:

Hi, Breｃｈｔ

I can make .a file(not .dll).
With following instruction.

==1==
Install
http://www.python.org/ftp/python/2.5.2/python-2.5.2.msi
to /usr/local/(C:\msys\1.0\local)

and copy to include file to /usr/include/python2.5
and copy /usr/local/python.exe pythonw.exe to /usr/local/bin

==2==
Install to /usr/local (C:\msys\1.0\local)
http://ftp.gnome.org/pub/GNOME/binaries/win32/pygobject/2.14/pygobject-2.14.1-1.win32-py2.5.exe

make and make install seems work fine.

Thanks
Atsushi SAKAI

Atsushi SAKAI [EMAIL PROTECTED] wrote:

Hi, Brecht

Just out of curiosity, have you done anything with virsh or the DLL you
have built?

Yes

By the way, I am doing to build Python bingings on MinGW.
But it will need to do tomorrow, since many compilation warnings.

Thanks
Atsushi SAKAI

Brecht Sanders [EMAIL PROTECTED] wrote:

Hi,
I guesss I had got as far as you did.
To Install Python on Windows you will need to download and install the
following:
http://www.python.org/ftp/python/2.5.2/python-2.5.2.msi

http://ftp.gnome.org/pub/GNOME/binaries/win32/pygobject/2.14/pygobject-2.14.1-1.win32-py2.5.exe

http://ftp.gnome.org/pub/GNOME/binaries/win32/pycairo/1.4/pycairo-1.4.12-1.win32-py2.5.exe

http://ftp.gnome.org/pub/GNOME/binaries/win32/pygtk/2.12/pygtk-2.12.1-2.win32-py2.5.exe
Also, don't forget to set some environment variables:
export PYDIR=/C/Prog/Python25
export PYTHONHOME=$PYDIR
export PYTHONPATH=$PYDIR/Lib/site-packages
export PATH=$MINGWPREFIX:$MINGWPREFIX/bin:$PATH
Just out of curiosity, have you done anything with virsh or the DLL you
have built?
Regards,
Brecht

Atsushi SAKAI wrote:

Hi, Bericht

By your suggestion, I am recognizing python bindings are not created(on
my configuration).
If you notice me to install python on MinGW, I will try to investigate
it.

My posting mail is follows(it does not create python library)
https://www.redhat.com/archives/libvir-list/2008-June/msg00201.html
It creates general library and virsh only.

Thanks
Atsushi SAKAI

Brecht Sanders [EMAIL PROTECTED] wrote:

No. Can you tell me where to find it?
I also noticed that I only produced one DLL: libvirt-0.dll.
No Python module DLL was built. Were you able to build this?

Atsushi SAKAI wrote:

Hi,

Did you check my instruction for libvirt on MinGW?

Thanks
Atsushi SAKAI

Brecht Sanders [EMAIL PROTECTED] wrote:

Hi,
Some time passed by and I thought I'd have another go at compiling
libvirt for win32 using MinGW/MSYS again.
I tried to compile libvirt-0.4.3 and I got around most obstacles.
Now it
just seems I am stuck when it is trying to link.
My search on google showed me that I am not the first one to see
this issue.
Usually i means -lws2_32 is in the wrong place. However I tried
moving
it around without luck.
Also it doesn't make sense to me that only htonl and ntohl are
missing.
It appears anything else used from the winsock library is found
during
linking.
I feel we're very close to getting libvirt compiled on win32. Or do
you
know if anyone already succeeded?
Regards
Brecht Sanders

gcc -shared .libs/libvirt_la-libvirt.o .libs/libvirt_la-memory.o
.libs/libvirt_la-hash.o .libs/libvirt_la-test.o
.libs/libvirt_la-buf.o
.libs/libvirt_la-qparams.o .libs/libvirt_la-capabilities.o
.libs/libvirt_la-xml.o .libs/libvirt_la-event.o
.libs/libvirt_la-xen_unified.o .libs/libvirt_la-xen_internal.o
.libs/libvirt_la-xs_internal.o .libs/libvirt_la-xend_internal.o
.libs/libvirt_la-stats_linux.o

Re: [libvirt] libvirt on mingw: undefined reference to htonl/ntohl

Re: [libvirt] How does libvirt access kvm infomation?

Re: [libvirt] How does libvirt access kvm infomation?

Re: [libvirt] libvirt on mingw: undefined reference to htonl/ntohl

[libvirt] [PATCH]: Fix VIR_ALLOC_N for 0 byte arrays

Re: [libvirt] [PATCH]: fix ruby-libvirt bindings when virConnectNum* returns 0

Re: [libvirt] [PATCH]: Fix VIR_ALLOC_N for 0 byte arrays

Re: [libvirt] [PATCH]: Fix VIR_ALLOC_N for 0 byte arrays

[libvirt] [PATCH]: Fix allocation of tapfds when starting qemu

Re: [libvirt] [PATCH]: Fix allocation of tapfds when starting qemu

Re: [libvirt] [PATCH]: Fix allocation of tapfds when starting qemu

Re: [libvirt] [PATCH]: Fix allocation of tapfds when starting qemu

Re: [libvirt] [PATCH]: Fix allocation of tapfds when starting qemu

Re: [libvirt] [PATCH]: Fix VIR_ALLOC_N for 0 byte arrays

Re: [libvirt] libvirt on mingw: undefined reference to htonl/ntohl

Re: [libvirt] libvirt on mingw: undefined reference to htonl/ntohl

Re: [libvirt] [PATCH]: Fix allocation of tapfds when starting qemu

Re: [libvirt] [PATCH]: Fix allocation of tapfds when starting qemu

[libvirt] Test packages for various fixes

Re: [libvirt] libvirt on mingw: undefined reference to htonl/ntohl

[libvirt] [PATCH] Fix XML escaping problem in the XM driver

[libvirt] [PATCH 0 of 3] LXC network interface support

[libvirt] [PATCH 1 of 3] [LXC] Add functions to manage veth device pairs

[libvirt] [PATCH 2 of 3] [LXC] Add XML parsing of container network interfaces

[libvirt] [PATCH 3 of 3] [LXC] Add setup/cleanup of container network interfaces

Re: [libvirt] [PATCH 1 of 3] [LXC] Add functions to manage veth device pairs

Re: [libvirt] [PATCH 1 of 3] [LXC] Add functions to manage veth device pairs

Re: [libvirt] [PATCH 1 of 3] [LXC] Add functions to manage veth device pairs

[patch] python binding on mingw-make Re: [libvirt] libvirt on mingw: undefined reference to htonl/ntohl

29 matches

Site Navigation

Mail list logo

Footer information