date:20080619

[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

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

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  if the non-netns 'ip' command is found?

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

DV>Hum, 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 
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 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 2>&1 | 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:

[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 bridg

[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  'network' attribute specified with 
"));
+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  'bridge' attribute specified with 
"));
+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 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 2>&1 | 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 
+ *
+ * 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 
+
+#ifdef HAVE_NETNS
+
+#include 
+
+#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 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] 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, "\n");
-virBufferVSprintf(&buf, "  %s\n", name);
+virBufferEscapeString(&buf, "  %s\n", name);
 virUUIDFormat(uuid, uuidstr);
 virBufferVSprintf(&buf, "  %s\n", uuidstr);
 
@@ -612,7 +612,7 @@ char *xenXMDomainFormatXML(virConnectPtr
 virBufferAddLit(&buf, "  \n");
 virBufferAddLit(&buf, "hvm\n");
 if (xenXMConfigGetString(conf, "kernel", &str) == 0)
-virBufferVSprintf(&buf, "%s\n", str);
+virBufferEscapeString(&buf, "%s\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, "  %s\n", str);
+virBufferEscapeString(&buf, "  %s\n", 
str);
 if (xenXMConfigGetString(conf, "bootargs", &str) == 0)
 virBufferEscapeString(&buf, "  
%s\n", str);
 if (xenXMConfigGetString(conf, "kernel", &str) == 0) {
 virBufferAddLit(&buf, "  \n");
 virBufferAddLit(&buf, "linux\n");
-virBufferVSprintf(&buf, "%s\n", str);
+virBufferEscapeString(&buf, "%s\n", str);
 if (xenXMConfigGetString(conf, "ramdisk", &str) == 0)
-virBufferVSprintf(&buf, "%s\n", str);
+virBufferEscapeString(&buf, "%s\n", str);
 if (xenXMConfigGetString(conf, "extra", &str) == 0)
 virBufferEscapeString(&buf, "%s\n", 
str);
 virBufferAddLit(&buf, "  \n");
@@ -714,7 +714,7 @@ char *xenXMDomainFormatXML(virConnectPtr
 
 if (hvm) {
 if (xenXMConfigGetString(conf, "device_model", &str) == 0)
-virBufferVSprintf(&buf, "%s\n", str);
+virBufferEscapeString(&buf, "%s\n", str);
 }
 
 list = virConfGetValue(conf, "disk");
@@ -816,9 +816,12 @@ char *xenXMDomainFormatXML(virConnectPtr
 virBufferVSprintf(&buf, "  \n", drvName, drvType);
 else
 virBufferVSprintf(&buf, "  \n", 
drvName);
-if (src[0])
-virBufferVSprintf(&buf, "  \n", block ? 
"dev" : "file", src);
-virBufferVSprintf(&buf, "  \n", 
dev, bus);
+if (src[0]) {
+virBufferVSprintf(&buf, "  \n",  src);
+   }
+virBufferEscapeString(&buf, "  \n", bus);
 if (STREQ(head, "r") ||
 STREQ(head, "ro"))
 virBufferAddLit(&buf, "  \n");
@@ -836,7 +839,7 @@ char *xenXMDomainFormatXML(virConnectPtr
 if (xenXMConfigGetString(conf, "cdrom", &str) == 0) {
 virBufferAddLit(&buf, "\n");
 virBufferAddLit(&buf, "  \n");
-virBufferVSprintf(&buf, "  \n", str);
+virBufferEscapeString(&buf, "  \n", str);
 virBufferAddLit(&buf, "  \n");
 virBufferAddLit(&buf, "  \n");
 virBufferAddLit(&buf, "\n");
@@ -924,7 +927,7 @@ char *xenXMDomainFormatXML(virConnectPtr
 if (type == 1 && bridge[0])
 virBufferVSprintf(&buf, "  \n", 
bridge);
 if (script[0])
-virBufferVSprintf(&buf, "  \n", script);
+virBufferEscapeString(&buf, "  \n", 
script);
 if (ip[0])
 virBufferVSprintf(&buf, "  \n", ip);
 if (model[0])
@@ -1024,10 +1027,10 @@ char *xenXMDomainFormatXML(virConnectPtr
 virBufferVSprintf(&buf, " listen='%s'", vnclisten);
 }
 if (vncpasswd) {
-virBufferVSprintf(&buf, " passwd='%s'", vncpasswd);
+virBufferEscapeString(&buf, " passwd='%s'", vncpasswd);
 }
 if (keymap) {
-virBufferVSprintf(&buf, " keymap='%s'", keymap);
+virBufferEscapeString(&buf, " keymap='%s'", keymap);

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/libvir

[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] [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

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 .
+
+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] 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 
> > > >

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 
> > >>>

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

2008-06-19 Thread Daniel P. Berrange

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

Ahhh, so this is why it was only hitting oVirt - all my tests normally 
just had a single network interface.

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]: 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, 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 `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): 
>  un

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 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

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 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

[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 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

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 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

[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] 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 `/h

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 Atsushi SAKAI

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 `/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

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

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

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

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

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

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

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

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

[libvirt] Test packages for various fixes

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

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

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 VIR_ALLOC_N for 0 byte arrays

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

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

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

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

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

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

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

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

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

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

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

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

31 matches

Site Navigation

Mail list logo

Footer information