On 07/08/2010 07:33 AM, Chris Lalancette wrote:
snip
If you use these commands, and something breaks, you get to
+keep both pieces.
Heh, I like the humour, but am wondering if we should do this.
I don't think we have the man pages translated yet (but we should).
This kind of can be difficult
On Thu, Jul 08, 2010 at 03:53:06AM +0900, Ryota Ozaki wrote:
On Thu, Jul 8, 2010 at 3:31 AM, Ryota Ozaki ozaki.ry...@gmail.com wrote:
On Thu, Jul 8, 2010 at 2:40 AM, Daniel Veillard veill...@redhat.com wrote:
On Thu, Jul 08, 2010 at 01:55:23AM +0900, Ryota Ozaki wrote:
Unfortunately the
A missing return statement in the python binding meant that
the callers could not get the callback ID, and thus not be
able to unregister event callbacks
* python/libvirt-override-virConnect.py: Add missing return
statement
---
python/libvirt-override-virConnect.py |1 +
1 files changed, 1
On Fri, Jul 02, 2010 at 09:58:17AM +1000, Justin Clift wrote:
---
Daniel, how's this as a first go?
It's just your content converted to HTML in the same style as the other
pages, with the occasional typo fix. If this is workable, then I'll create
another patch after this to hook it into
On Thu, Jul 8, 2010 at 6:26 PM, Daniel P. Berrange berra...@redhat.com wrote:
On Thu, Jul 08, 2010 at 03:53:06AM +0900, Ryota Ozaki wrote:
On Thu, Jul 8, 2010 at 3:31 AM, Ryota Ozaki ozaki.ry...@gmail.com wrote:
On Thu, Jul 8, 2010 at 2:40 AM, Daniel Veillard veill...@redhat.com
wrote:
On
dispatch.c requires stdio.h (and stdarg.h), however, currently
dispatch.c implicitly relys on rpc/xdr.h to include stdio.h.
If rpc/xdr.h unxpectedly does not include stdio.h, the compilation
of dispatch.c fails.
This can happen, for example, when portablexdr is installed
under /usr/local; because
On Wed, Jul 07, 2010 at 04:43:17PM -0400, Chris Lalancette wrote:
Signed-off-by: Chris Lalancette clala...@redhat.com
---
tools/virsh.c | 55
+++
tools/virsh.pod |6 ++
2 files changed, 61 insertions(+), 0 deletions(-)
ACK,
Couldn't find any Java API or even any function in libvirt documentation:
http://libvirt.org/html/libvirt-libvirt.html
In case there is no API present can someone please point how this can be
achieved using existing Java APIs to get the same behavior as virt-clone?
Thanks,
-Ganesh
--
libvir-list
A missing return statement in the python binding meant that
the callers could not get the callback ID, and thus not be
able to unregister event callbacks
* python/libvirt-override-virConnect.py: Add missing return
statement
---
python/libvirt-override-virConnect.py |1 +
1 files
On 07/08/10 - 02:04:12PM, Daniel Veillard wrote:
On Wed, Jul 07, 2010 at 04:43:17PM -0400, Chris Lalancette wrote:
Signed-off-by: Chris Lalancette clala...@redhat.com
---
tools/virsh.c | 55
+++
tools/virsh.pod |6 ++
2
dispatch.c requires stdio.h (and stdarg.h), however, currently
dispatch.c implicitly relys on rpc/xdr.h to include stdio.h.
If rpc/xdr.h unxpectedly does not include stdio.h, the compilation
of dispatch.c fails.
This can happen, for example, when portablexdr is installed
under /usr/local;
On 07/08/10 - 05:58:52PM, Justin Clift wrote:
On 07/08/2010 07:33 AM, Chris Lalancette wrote:
snip
If you use these commands, and something breaks, you get to
+keep both pieces.
Heh, I like the humour, but am wondering if we should do this.
I don't think we have the man pages translated
On Thu, Jul 08, 2010 at 05:37:21PM +0530, Ganesh Pagade wrote:
Couldn't find any Java API or even any function in libvirt documentation:
http://libvirt.org/html/libvirt-libvirt.html
In case there is no API present can someone please point how this can be
achieved using existing Java APIs to
On 07/08/2010 11:35 PM, Richard W.M. Jones wrote:
On Thu, Jul 08, 2010 at 05:37:21PM +0530, Ganesh Pagade wrote:
Couldn't find any Java API or even any function in libvirt documentation:
http://libvirt.org/html/libvirt-libvirt.html
In case there is no API present can someone please point how
The virsh command setmem takes as input a number that
should represent an unsigned long number of kilobytes. Fix
cmdSetmem to properly parse this as an unsigned long instead
of an int.
Signed-off-by: Chris Lalancette clala...@redhat.com
---
tools/virsh.c | 30 ++
1
Hi Daniel,
The guest can be successfully migrated, but it will spend very very long time,
and I will retest the bug based on you and Jiri suggestion, thanks.
Regards,
Alex
- Original Message -
From: Daniel P. Berrange berra...@redhat.com
To: Alex Jia a...@redhat.com
Cc:
Hi there!
Since our cloud system that is currently under development, might need it, I've
tested libvirt
domain hooks but unfortunately failed. I've tried the following scenario:
1. create the hook directory...
# mkdir /etc/libvirt/hook
# chmod 755 /etc/libvirt/hook
2. ... or maybe hooks?
#
From: Justin Clift jus...@salasaga.org
Gracious thanks to Chris Lalancette for helping knock the description
section into shape.
This addresses BZ #595350
https://bugzilla.redhat.com/show_bug.cgi?id=595350
---
daemon/Makefile.am | 40 +++-
daemon/libvirtd.pod.in | 168
This patch series is related to a discussion Eric Blake and I had a couple
of months back[1]. It essentially revamps the way that virsh does error
reporting so that errors from more calls are properly reported.
More details are in each individual patch.
[1]
On Thu, Jul 08, 2010 at 06:49:25PM +, Csom Gyula wrote:
Hi there!
Since our cloud system that is currently under development, might need it,
I've tested libvirt
domain hooks but unfortunately failed. I've tried the following scenario:
1. create the hook directory...
# mkdir
vshMalloc and friends always exit() on allocation failure,
so there is no reason to do checking for NULL in the code
that uses it.
Signed-off-by: Chris Lalancette clala...@redhat.com
---
tools/virsh.c | 38 +-
1 files changed, 1 insertions(+), 37
This helper calls virFileReadAll(), and then outputs a
proper error if it fails for whatever reason.
Signed-off-by: Chris Lalancette clala...@redhat.com
---
tools/virsh.c | 65
1 files changed, 37 insertions(+), 28 deletions(-)
diff
Nobody was using it anyway.
Signed-off-by: Chris Lalancette clala...@redhat.com
---
tools/virsh.c | 270 -
1 files changed, 134 insertions(+), 136 deletions(-)
diff --git a/tools/virsh.c b/tools/virsh.c
index 1f33256..ee55a20 100644
---
With the change to make vshError() responsible for printing
all errors, there were some places in the code that would no
longer properly print errors. The good news is that the vast
majority of virsh was already printing errors, so this patch
just cleans up the rest of the users to make them
The virsh option error reporting was not being used
consistently; some commands would spit out errors on
missing required options while others would just silently fail.
However, vshCommandOptString knows which ones are required
and which ones aren't, so make it spit out an error where
appropriate.
Signed-off-by: Chris Lalancette clala...@redhat.com
---
tools/virsh.c | 29 -
1 files changed, 0 insertions(+), 29 deletions(-)
diff --git a/tools/virsh.c b/tools/virsh.c
index d539fbc..c1451d8 100644
--- a/tools/virsh.c
+++ b/tools/virsh.c
@@ -227,9 +227,6 @@
Otherwise you can get bogus unknown error printouts on
subsequent commands.
Signed-off-by: Chris Lalancette clala...@redhat.com
---
tools/virsh.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tools/virsh.c b/tools/virsh.c
index 6a22071..6b7580b 100644
---
With the current virsh code, error reporting is a bit fragile
because the reporting is decoupled from the place where the
error occurred. There are two places where this can be a problem:
1) In utility functions that don't properly dispatch errors
like the main API functions do. In this case,
On 07/09/10 - 05:20:27AM, Justin Clift wrote:
From: Justin Clift jus...@salasaga.org
Gracious thanks to Chris Lalancette for helping knock the description
section into shape.
This addresses BZ #595350
https://bugzilla.redhat.com/show_bug.cgi?id=595350
It looks pretty good to me; a
Hi!
Thank you very much for your response! It was the version... you pointed at.
I was testing on my home coputer... that is on Ubuntu it has libvirt v.0.7.
Fortunately our real environment (Debian) has libvirt v.0.8.
Cheers,
Gyula
Feladó: Daniel
On 07/09/2010 06:14 AM, Chris Lalancette wrote:
snip
While this is fun and tricky, I'm not 100% convinced that we should do this.
I would think we would want the same manpage regardless of what options are
compiled in. While it could be a bit confusing in that options are listed
in the manpage
I had a look at the problem of finding the devices representing the
partitions of a block device, and it's a messy problem. There are a
lot of different conventions that are used depending on what kind of
device is partitioned. The following patch seems like a promising
approach, but before I
There are many naming conventions for partitions associated with a
block device. Some of the major ones are:
/dev/foo - /dev/foo1
/dev/foo1 - /dev/foo1p1
/dev/mapper/foo - /dev/mapper/foop1
/dev/disk/by-path/foo - /dev/disk/by-path/foo-part1
The universe of possible conventions isn't clear.
33 matches
Mail list logo
