(This probably seems like overanalysis of a simple problem. That's what
I'm best at ;-)
Due to oversight, the function virInterfaceLookupByMACString() can only
return a single interface, but it's possible that a host may have more
than one interface with the same MAC. Since the API had already
I found this while looking for examples of using
virNodeDeviceGetXMLDesc(). AFAIK, *all* of the *GetXMLDesc() functions
return a newly allocated chunk of memory that is owned by the caller,
who must free it when they're done...
---
src/virsh.c | 10 +-
1 files changed, 9 insertions(+),
Fix some minor grammer (and one other) nits in comments that end up in
generated API reference documentation. No functional/binary differences.
---
src/libvirt.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/src/libvirt.c b/src/libvirt.c
index ca
On 09/28/2009 11:30 AM, Daniel Veillard wrote:
The virXPath... function take extra care to preserve the XPath context
node (ctxt->node) but in the case of virXPathString and virXPathBoolean
they forgot to do this on the error path. This patch fixes this and
move all ctxt->node = relnode instuct
On 09/28/2009 11:30 AM, Daniel Veillard wrote:
The virXPath... function take extra care to preserve the XPath context
node (ctxt->node) but in the case of virXPathString and virXPathBoolean
they forgot to do this on the error path. This patch fixes this and
move all ctxt->node = relnode instuct
On 09/28/2009 06:39 PM, Laine Stump wrote:
On 09/28/2009 11:30 AM, Daniel Veillard wrote:
The virXPath... function take extra care to preserve the XPath context
node (ctxt->node) but in the case of virXPathString and virXPathBoolean
they forgot to do this on the error path. This patch fi
This was causing subsequent calls to virXPathxxx() to fail, since
ctxt->node was left pointing at the dhcp node, rather than the
protocol node. Previously this had gone unnoticed, as the dhcp node
was the only thing parsed under ip, if it was there.
---
src/conf/interface_conf.c |3 +++
1 file
Fix some minor grammer (and one other) nits in comments that end up in
generated API reference documentation. No functional/binary differences.
---
src/libvirt.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/src/libvirt.c b/src/libvirt.c
index ca
This wasn't the file I meant to send!
On 09/29/2009 03:58 PM, Laine Stump wrote:
Fix some minor grammer (and one other) nits in comments that end up in
generated API reference documentation. No functional/binary differences.
[...]
--
Libvir-list mailing list
Libvir-list@redhat.com
From: root
This patch adds the flag VIR_INTERFACE_XML_INACTIVE to
virInterfaceGetXMLDesc's flags. When it is *not* set (the default),
the live interface info will be returned in the XML. in particular,
the IP address(es) and netmask(s) will be retrieved by querying the
device directly, rather tha
On 09/29/2009 04:02 PM, Laine Stump wrote:
From: root
Note that I accidentally did the local commit as root, and didn't notice
it until now. If this patch gets committed, please change the From: first.
This patch adds the flag VIR_INTERFACE_XML_INACTIVE to
virInterfaceGetXMLD
On 10/02/2009 07:16 AM, Daniel P. Berrange wrote:
Even without that bug we constantly see changes which cause the
re-generation of this file - eg when commiting new APIs like
Chris' migration ones people always forget to manually re-generate
the XML file before commiting. Or when fixing typos in
This patch updates the xml parsing and formatting, and the associated
virInterfaceDef data structure to support IPv6, along the way adding
support for multiple protocols per interface, and multiple IP
addresses per protocol.
Note that netcf appears to not accept defining both ipv4 and ipv6 on
the
On 10/04/2009 10:58 PM, Laine Stump wrote:
This patch updates the xml parsing and formatting, and the associated
virInterfaceDef data structure to support IPv6, along the way adding
support for multiple protocols per interface, and multiple IP
addresses per protocol.
Note that netcf appears to
On 10/05/2009 07:02 AM, Daniel P. Berrange wrote:
On Tue, Sep 29, 2009 at 04:02:30PM -0400, Laine Stump wrote:
From: root
This patch adds the flag VIR_INTERFACE_XML_INACTIVE to
virInterfaceGetXMLDesc's flags. When it is *not* set (the default),
the live interface info will be return
On 10/05/2009 06:06 PM, David Lutterkort wrote:
On Sun, 2009-10-04 at 22:58 -0400, Laine Stump wrote:
Note that netcf appears to not accept defining both ipv4 and ipv6 on
the same interface, and still can't report live config of IPv6 (or
multiple IPv4 addresses), so the usefulness of
On 10/06/2009 05:13 AM, Daniel P. Berrange wrote:
On Mon, Oct 05, 2009 at 02:34:05PM -0700, David Lutterkort wrote:
On Mon, 2009-10-05 at 17:34 +0100, Daniel P. Berrange wrote:
With the domain XML format, we did have a few abortive attempts at
indicating in the live XML, whether an at
On 10/06/2009 10:13 AM, Daniel P. Berrange wrote:
This was a bug in the original patch, corrected by this set of patches:
https://fedorahosted.org/pipermail/netcf-devel/2009-September/000280.html
Once those patches are applied, only the IP (v4) addresses currently on
the device are returned (
On 10/06/2009 01:36 PM, David Lutterkort wrote:
On Tue, 2009-10-06 at 10:13 +0100, Daniel P. Berrange wrote:
The live XML should *always* say what the inteface is doing right
now.
And from the rest of this exchange, I think the word 'only' should be
added to that sentence. In other wo
This is similar to the (now deprecated) patches I sent on 9/28 and
10/04, but without the unpopular "source" attribute in the ip address.
You can successfully build libvirt if you have the latest release of
netcf installed, but you'll need to get the netcf source, apply the
patches in the thread
From: root
This patch adds the flag VIR_INTERFACE_XML_INACTIVE to
virInterfaceGetXMLDesc's flags. When it is*not* set (the default), the
live interface info will be returned in the XML (in particular, the IP
address(es) and netmask(s) will be retrieved by querying the interface
directly, rather t
This patch updates the xml parsing and formatting, and the associated
virInterfaceDef data structure to support IPv6, along the way adding
support for multiple protocols per interface, and multiple IP
addresses per protocol.
---
src/conf/interface_conf.c | 295 ++--
(Yes, you read the subject correctly - 3 of 2!)
The minimal XML returned from ncf_if_xml_state() doesn't contain these
attributes, and it was preventing it from passing through the
parse/format step (making my patches from earlier today unusable).
Because adding an "UNSPECIFIED" value to the enum
On 10/08/2009 06:25 AM, Daniel P. Berrange wrote:
On Wed, Oct 07, 2009 at 10:05:40AM -0400, Laine Stump wrote:
From: root
This patch adds the flag VIR_INTERFACE_XML_INACTIVE to
virInterfaceGetXMLDesc's flags. When it is*not* set (the default), the
live interface info will be return
On 10/08/2009 06:14 AM, Daniel P. Berrange wrote:
On Wed, Oct 07, 2009 at 05:04:40PM -0400, Laine Stump wrote:
(Yes, you read the subject correctly - 3 of 2!)
The minimal XML returned from ncf_if_xml_state() doesn't contain these
attributes, and it was preventing it from passing th
If virBufferEscapeString is called on a buffer that has 0 bytes of
space, a size of -1 will be passed to snprintf, resulting in a
segmentation fault. This patch checks for 0 space, and grows the
buffer if needed prior to determining size.
I discovered this when I accidentally made virBufferEscapeS
On 10/15/2009 06:03 AM, Chris Lalancette wrote:
Good catch. The hardcode of 100 threw me at first, but I see that we
appropriately grow the buffer as needed in the loop below, so I think this
works.
I thought of trying to make a better guess, but when I saw that
virBufferVSprintf just use
There are places where an interface will not have a mac address, and netcf
returns this as a NULL pointer rather than a pointer to an empty string.
Rather than checking for this all over the place in libvirt, just save it
in the virInterface object as an empty string.
---
src/datatypes.c |7 ++
On 10/21/2009 06:19 AM, Daniel Veillard wrote:
On Mon, Oct 19, 2009 at 04:41:52PM -0400, Laine Stump wrote:
There are places where an interface will not have a mac address, and netcf
returns this as a NULL pointer rather than a pointer to an empty string.
Rather than checking for this all
The related patch is now available on the netcf-devel mailing list,
making it possible to review this set ;-)
On 10/16/2009 10:56 AM, la...@laine.org wrote:
This is the 2nd iteration of this patchset incorporating danpb's
suggestions. Along with a couple other minor things, the type attribute
On 10/22/2009 03:05 PM, Cole Robinson wrote:
Looks like the patch was mangled. Just pasting the patch into your
client probably won't be sufficient. I'd recommend git format-patch and
git send-email, or just attach the patch file.
Actually, I found out earlier today that when a patch is se
(AHA! Just figured out how to get a patch sent as an attached file into
the reply when using Thunderbird - 1) make sure Thunderbird is
configured to display text attachments inline, 2) select everything in
the original message (with ctrl-A), *then* 3) hit the reply button)
On 10/22/2009 10:46
On 10/22/2009 03:38 PM, Daniel P. Berrange wrote:
On Thu, Oct 22, 2009 at 03:33:37PM -0400, Laine Stump wrote:
On 10/22/2009 03:05 PM, Cole Robinson wrote:
Looks like the patch was mangled. Just pasting the patch into your
client probably won't be sufficient. I'd recommend
(How's this?)
This patch updates the xml parsing and formatting, and the associated
virInterfaceDef data structure to support IPv6, along the way adding
support for multiple protocols per interface, and multiple IP
addresses per protocol.
---
src/conf/interface_conf.c | 295 +
If ncf_init() fails, it takes responsibility to call ncf_close() when
appropriate. Having libvirt call it results in a double close, which
ends up segv'ing.
---
src/interface/netcf_driver.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/src/interface/netcf_driver.c b/s
On 10/27/2009 10:28 AM, David Lutterkort wrote:
On Tue, 2009-10-27 at 14:23 +, David Lutterkort wrote:
On Fri, 2009-10-23 at 20:31 +0100, Daniel P. Berrange wrote:
On Fri, Oct 23, 2009 at 03:13:17PM -0400, Laine Stump wrote:
If ncf_init() fails, it takes responsibility
On 10/27/2009 01:47 PM, Kaitlin Rupert wrote:
It looks like specifying an address of [::1] instead of ::1 will work.
However, that seems like a bug. The bracket syntax is specific to
qemu, which means the user needs to have prior knowledge of this.
Not exactly specific to qemu. Many other pro
When testing all the different possibilities of interfaces with the
new netcf release + my latest libvirt patches (ACKed, but not yet
committed), I came across some problems, addressed by the following
two patches.
The first patch is for a bug that crept in due to a last minute change
suggested i
---
src/conf/interface_conf.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/src/conf/interface_conf.c b/src/conf/interface_conf.c
index 7cb71ed..fc18eba 100644
--- a/src/conf/interface_conf.c
+++ b/src/conf/interface_conf.c
@@ -309,10 +309,11 @@ virInterface
This is necessary because netcf does not yet know how to get this
information from the kernel, so the live config XML doesn't contain
it, leading to errors when passing it through the current libvirt parsers.
---
src/conf/interface_conf.c | 86 ++--
1 file
On 10/28/2009 10:35 AM, Daniel Veillard wrote:
On Thu, Oct 22, 2009 at 04:42:20PM -0400, Laine Stump wrote:
+/*
+ * Helpers to extract the IP arrays from the virSocketAddrPtr
+ * That part is the less portable of the module
+ */
+typedef unsigned char virIPv4Addr[4];
+typedef virIPv4Addr
On 10/28/2009 07:06 AM, Daniel Veillard wrote:
On Fri, Oct 23, 2009 at 01:31:19PM -0400, Laine Stump wrote:
diff --git a/src/conf/interface_conf.c b/src/conf/interface_conf.c
index d46f7ac..7cb71ed 100644
--- a/src/conf/interface_conf.c
+++ b/src/conf/interface_conf.c
@@ -53,9 +53,31
On 10/29/2009 02:53 AM, Laine Stump wrote:
On 10/28/2009 07:06 AM, Daniel Veillard wrote:
On Fri, Oct 23, 2009 at 01:31:19PM -0400, Laine Stump wrote:
Hum, we don't check there that an ipv6/4 protocol is not defined
multiple time. Maybe this could be slightly refactored to s
This is the only update to the patchset already sent. All other problems
were either in netcf code, or will be cleaned up later.
A patch has been sent to netcf-devel which, when applied, allows make
check of libvirt plus the patch series to complete with no errors.
There is still one issue, affec
With the patches I sent to netcf-devel last night, along with lutter's
(or DV's, take your pick ;-) netcf patch to eliminate the segfault, my
patches for reporting interface info now pass make check with no errors.
I believe lutter will be making a netcf release tomorrow or so, after he
gets ba
On 11/02/2009 09:12 AM, Daniel P. Berrange wrote:
On Mon, Nov 02, 2009 at 08:44:26AM -0500, Laine Stump wrote:
I haven't been able to find a source of this information yet and, while
it may be useful, I don't see it as necessary. Once again I'm proposing
that we make these
I'm a bit behind the curve, but...
On 11/02/2009 05:57 AM, Matthew Booth wrote:
---
src/libvirt_private.syms |3 ++
src/util/network.c | 88 +-
src/util/network.h |6 +++
3 files changed, 96 insertions(+), 1 deletions(-)
dif
Lack of one of these in the live xml output was causing the parse to fail.
---
src/conf/interface_conf.c | 35 +--
1 files changed, 13 insertions(+), 22 deletions(-)
diff --git a/src/conf/interface_conf.c b/src/conf/interface_conf.c
index 31af957..31abf12 100644
0.1.3 will build everything, but causes a segfault.
---
configure.in|2 +-
libvirt.spec.in |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.in b/configure.in
index 7ad1a90..cd8bb95 100644
--- a/configure.in
+++ b/configure.in
@@ -33,7 +33,7 @@ GNUTLS_REQU
virStorageBackendFileSystemDelete was incorrectly calling unlink() in
an attempt to remove a directory. It should be calling rmdir()
instead. (remove() would also work, but could potentially succeed on a
non-empty pool if the pool was a symlink to somewhere else).
---
src/storage/storage_backend_f
---
src/conf/interface_conf.c | 32 +---
1 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/src/conf/interface_conf.c b/src/conf/interface_conf.c
index ca82208..d7821e7 100644
--- a/src/conf/interface_conf.c
+++ b/src/conf/interface_conf.c
@@ -557,28 +55
The first two patches make minor additions to the parsing/formatting.
The 3rd is a bit more intrusive, as it switches from using
virInterfaceBareDef for subordinate interfaces to recursively using a
full virInterfaceDef (but with guaranteed closure due to limiting the
type of subordinate interface
---
src/conf/interface_conf.c | 11 +++
src/conf/interface_conf.h |1 +
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/conf/interface_conf.c b/src/conf/interface_conf.c
index 3c99027..ca82208 100644
--- a/src/conf/interface_conf.c
+++ b/src/conf/interface_conf.c
@
The RNG now supports IPv6 and bonds attached to bridges, along with
some other minor tweaks. All test files from netcf have been copied to
the test directory and added to the xml2xml and schema tests (and they
all pass, of course ;-)
---
docs/schemas/interface.rng | 316
This was accomplished in xml parsing by doing away with the
stripped-down virInterfaceBareDef object, and just always using
virInterfaceDef, but with restrictions in certain places (eg, the type
of subordinate interface allowed in parsing depends on the parent
interface).
xml formatting was simila
To help with lutter's network configuration project, I'm looking at
adding API functions to libvirt which are essentially pass-throughs to
netcf library APIs called by libvirtd. Can someone point me to good
examples of APIs that are not hypervisor driver-dependent (and possibly
not host OS-depe
On 03/11/2009 09:55 AM, Daniel P. Berrange wrote:
- Application connects to libvirt (virConnectOpen()
- in src/libvirt.c we activate a hypervisor driver based on the
URI given. If successful, we then try to activate a number of
secondary drivers (eg virtual network, storage, node device)
(Oops, I originally sent this with the wrong return address, which
probably caused it to be silently swallowed...)
To get started integrating libnetcf support into libvirt, the attached
libvirt.h diff has a first attempt at the public API that will hook up
to libnetcf on the libvirtd side. I s
To get started integrating libnetcf support into libvirt, the attached
libvirt.h diff has a first attempt at the public API that will hook up
to libnetcf on the libvirtd side. I started out with the virNetwork*
API, and modified/removed as seemed appropriate.
A few points worth mentioning:
vi
To summarize (correct anything I've gotten wrong):
1) Supporting transient interfaces would be nice, but would require too
much re-implementation of ifup-type scripts in our code (and for every
platorm), so it is out of scope. danpb thinks at least being able to
query transient interfaces (tho
On 03/30/2009 08:09 AM, Chris Lalancette wrote:
All,
This is a small series to cleanup the internal driver initializers. The
drivers were using an annoying combination of C-99 style initialization and
old-style (C89?) initialization. On top of that, the indentation on some of
these was wac
I'm now trying to write the test driver for the interface config driver
that I'm putting into libvirt. For comparison I'm using the network
driver. My understanding so far is that it calls the functions in the
real driver to construct network objects and manipulate them, then just
doesn't call
On 04/07/2009 11:16 AM, Cole Robinson wrote:
As an example of how the driver will likely be used, think of supporting
the interface APIs in virt-manager. As a developer, it would be nice to
use the test driver to ensure that all the UI updating as interfaces go
up and down, appear and disappear,
On 04/07/2009 11:35 AM, Daniel P. Berrange wrote:
On Tue, Apr 07, 2009 at 10:39:22AM -0400, Laine Stump wrote:
I'm now trying to write the test driver for the interface config driver
that I'm putting into libvirt. For comparison I'm using the network
driver. My understanding
On 04/09/2009 11:26 AM, Daniel P. Berrange wrote:
There should be XML parsing & formatting routines in libvirt because
not everything is going to use netcf, and the test driver shouldn't
depend on it. Even for drivers using netcf, libvirt will also have
to potentially augment info returned from
On 04/10/2009 06:47 AM, Daniel P. Berrange wrote:
On Thu, Apr 09, 2009 at 02:21:20PM -0400, Laine Stump wrote:
So, in the interest of getting the most useful stuff into the code in
the shortest time, here is a proposed schedule of what to do when. All
of these things will be done before the
I'm looking through the network driver, and see the "state" driver
registered. Several other drivers also register a state driver. What is
this used for? It looks like it's handling a startup/shutdown at a more
basic level than then open/close in the network (storage/qemu/etc)
driver itself. Is
On 04/14/2009 10:42 AM, Hugh O. Brock wrote:
I don't see any compelling reason why we absolutely must have
this ready for next release. I prefer to wait until the code is
more developed than rushing to meet an unneccessary artificial
date. I know this is listed as a Fedora 12 feature, but ther
On 04/27/2009 08:28 AM, Daniel Veillard wrote:
Hum, I noticed recently that some packages change the make output to
just print something like the following when compiling a C module:
CC module.c
instead of the now 3-4 lines of compiler flags, which make spotting
warnings way easier. Maybe th
I just noticed in datatypes.c that the
vir(Network|StoragePool|StorageVol)FreeName destructors call the public
API vir*Free() functions rather than the local virUnref*(). vir*Free()
all clear any errors, which seems like it might not be the right thing
to do (eg, if we're cleaning out the hasht
Something like this?
Do you think that the virUnref*() functions should continue to error out
if the conn is invalid? Or should they maybe just refrain from grabbing
the conn mutex, but still decrement the ref count and release the object
when necessary?
(P.S. Is this patch mail formatted correct
These 5 patches contain the public virInterface*() API definition, the
local plumbing, and the RPC glue. The test driver and real driver are
still TBI, but having this in will allow other people to work on related
stuff.
Other things still needed:
python/java bindings
cli commands in virsh
I'm s
From: Laine Stump
---
include/libvirt/libvirt.h| 84 ++
include/libvirt/libvirt.h.in | 84 ++
2 files changed, 168 insertions(+), 0 deletions(-)
diff --git a/include/libvirt/libvirt.h b/include/libvirt
From: Laine Stump
---
include/libvirt/libvirt.h| 18 ++
include/libvirt/libvirt.h.in | 18 ++
include/libvirt/virterror.h |4 +
src/datatypes.h | 25 ++
src/driver.h | 60
src/libvirt.c| 695
---
qemud/remote.c | 235
qemud/remote_dispatch_args.h |8 +
qemud/remote_dispatch_prototypes.h | 63 +++
qemud/remote_dispatch_ret.h|6 +
qemud/remote_dispatch_table.h | 50 +
qemud/remote_protocol.c|
---
src/libvirt_public.syms | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/src/libvirt_public.syms b/src/libvirt_public.syms
index b8f9128..cd369cb 100644
--- a/src/libvirt_public.syms
+++ b/src/libvirt_public.syms
@@ -264,4 +264,24 @@ LIBVIRT_0.6.3 {
From: Laine Stump
---
configure.in| 35 ---
src/Makefile.am |5 +
2 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/configure.in b/configure.in
index 1cdb64c..4ce4342 100644
--- a/configure.in
+++ b/configure.in
@@ -28,6 +28,7
On 05/11/2009 06:35 AM, Daniel P. Berrange wrote:
On Fri, May 08, 2009 at 01:52:24PM -0400, Laine Stump wrote:
From: Laine Stump
---
include/libvirt/libvirt.h| 18 ++
include/libvirt/libvirt.h.in | 18 ++
include/libvirt/virterror.h |4 +
src/datatypes.h | 25
On 05/13/2009 07:29 AM, Daniel Veillard wrote:
On Wed, May 13, 2009 at 10:57:13AM +0100, Daniel P. Berrange wrote:
On Wed, May 13, 2009 at 11:46:58AM +0200, Daniel Veillard wrote:
On Mon, May 11, 2009 at 03:29:42PM -0400, Laine Stump wrote:
Yes, tun interfaces too. Since this is
---
src/libvirt_public.syms | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/src/libvirt_public.syms b/src/libvirt_public.syms
index b8f9128..cd369cb 100644
--- a/src/libvirt_public.syms
+++ b/src/libvirt_public.syms
@@ -264,4 +264,24 @@ LIBVIRT_0.6.3 {
From: Laine Stump
---
configure.in| 35 ---
src/Makefile.am |5 +
2 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/configure.in b/configure.in
index 1cdb64c..4ce4342 100644
--- a/configure.in
+++ b/configure.in
@@ -28,6 +28,7
From: Laine Stump
---
include/libvirt/libvirt.h| 84 ++
include/libvirt/libvirt.h.in | 84 ++
2 files changed, 168 insertions(+), 0 deletions(-)
diff --git a/include/libvirt/libvirt.h b/include/libvirt
These patches are based on those I sent last week (the public
virInterface*() API definition, the local plumbing, and the RPC glue),
but with suggestions incorporated:
1) MAC address is always used in null-terminated ASCII string
format. This eliminates any potential problems with extra long
From: Laine Stump
---
include/libvirt/libvirt.h| 18 ++
include/libvirt/libvirt.h.in | 18 ++
include/libvirt/virterror.h |4 +
src/datatypes.h | 25 ++
src/driver.h | 60
src/libvirt.c| 695
---
qemud/remote.c | 235
qemud/remote_dispatch_args.h |8 +
qemud/remote_dispatch_prototypes.h | 63 +++
qemud/remote_dispatch_ret.h|6 +
qemud/remote_dispatch_table.h | 50 +
qemud/remote_protocol.c|
On 05/18/2009 04:21 PM, Farkas Levente wrote:
why these mail send to libvir-l...@laine.org?
this breaks all mail filters...:-(
Sorry, that was a rushed mistype on my part that I tried to fix by just
bouncing the mail rather than regenerating it; I hadn't considered that
people might be u
MY APOLOGIES! Yesterday I accidentally sent the old patchset rather
than the corrected set. This time it's right.
These patches are based on those I sent last week (the public
virInterface*() API definition, the local plumbing, and the RPC glue),
but with suggestions incorporated:
1) MAC address
From: Laine Stump
---
include/libvirt/virterror.h |4 +
src/datatypes.h | 25 ++
src/driver.h| 60 +
src/libvirt.c | 607 +++
src/virterror.c | 21 ++
5 files changed, 717 insertions
---
src/libvirt_public.syms | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/src/libvirt_public.syms b/src/libvirt_public.syms
index 0ea130f..9ad73f3 100644
--- a/src/libvirt_public.syms
+++ b/src/libvirt_public.syms
@@ -264,6 +264,24 @@ LIBVIRT_0.6.3 {
---
qemud/remote.c | 235
qemud/remote_dispatch_args.h |8 +
qemud/remote_dispatch_prototypes.h | 63 +++
qemud/remote_dispatch_ret.h|6 +
qemud/remote_dispatch_table.h | 45 +
qemud/remote_protocol.c|
From: Laine Stump
---
include/libvirt/libvirt.h| 50 ++
include/libvirt/libvirt.h.in | 50 ++
2 files changed, 100 insertions(+), 0 deletions(-)
diff --git a/include/libvirt/libvirt.h b/include/libvirt
From: Laine Stump
---
configure.in| 35 ---
src/Makefile.am |5 +
2 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/configure.in b/configure.in
index 8116fc8..420232a 100644
--- a/configure.in
+++ b/configure.in
@@ -28,6 +28,7
Here you go. I anticipated that would happen, but then forgot to check
for it after I rebased.
---
src/libvirt_public.syms | 19 +--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/src/libvirt_public.syms b/src/libvirt_public.syms
index 0ea130f..3ad5065 100644
-
On 05/21/2009 03:49 AM, Daniel Veillard wrote:
On Wed, May 20, 2009 at 05:45:36PM +0100, Daniel P. Berrange wrote:
We forgot that adding the virInterface APIs would break the build of the
python bindings. Here is the patch to wire up the code generator for
the new APIs. This is actually surpr
On 05/20/2009 10:35 AM, Daniel Veillard wrote:
Now can you double check src/libvirt_private.syms in case more are
missing ?
Ah, I hadn't seen that file - I was basing my work on a few other sets
of patches, and they didn't modify that file, so it fell under my radar.
Should virUnrefInterfac
On 05/28/2009 12:37 PM, Daniel P. Berrange wrote:
On Win32/mingw32 the name 'interface' is #defined to the COM_interface
struct. Needless to say, libvirt thus fails to build in spectacular ways.
ACK!!! (That's the Bill the Cat "Yuck!" kind, not the open source "Looks
good, okay." kind ;-)
I think this is complete (can't really try it out until the test
driver is running), but have a few questions about it:
1) Does the command set look complete?
2) Do you agree with the naming (using "if-", and following the
libvirt convention for if-create/if-destroy, rather than the fedora
On 06/15/2009 03:26 PM, Daniel P. Berrange wrote:
On Fri, Jun 12, 2009 at 10:25:19AM -0400, Laine Stump wrote:
I think this is complete (can't really try it out until the test
driver is running), but have a few questions about it:
1) Does the command set look complete?
2) Do you agree
I've already been working on incorporating physical host interface
configuration into libvirt by way of using libnetcf on the backend. It's
becoming apparent that, in addition to modifying and reporting the
current configuration of interfaces, libvirt users also want to query
current status of
On 06/18/2009 01:53 PM, David Lutterkort wrote:
On Thu, 2009-06-18 at 18:06 +0100, Daniel P. Berrange wrote:
On Thu, Jun 18, 2009 at 04:06:40PM +0200, Daniel Veillard wrote:
We should allow standalone IPv4 and IPv6, or both. Each could either
use DHCP or allow one or more IP address
1 - 100 of 6271 matches
Mail list logo
