Hi all,
Looking at the virsh man page (tools/virsh.pod), it's getting pretty
unwieldy and hard to grok for end users.
Wondering if it's worth breaking it up into sections?
Maybe something similar to how git structures their man pages?
ie.
man virsh
Giving an overview, the categories
* It appears that the udev event for HBA creation arrives before the
associated sysfs data is fully populated, resulting in bogus data
for the nodedev entry until the entry is refreshed. This problem is
particularly troublesome when creating NPIV vHBAs because it results
in libvirt failing
While investigating https://bugzilla.redhat.com/show_bug.cgi?id=597998 I
noticed that my nodedev-create operations were timing out more often than not.
This patch works around a race between udev generating a new device event and
the corresponding sysfs entries being populated. This behavior h
---
src/conf/node_device_conf.c |4 ++--
src/node_device/node_device_driver.c |3 ++-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c
index 7f2dac8..6583570 100644
--- a/src/conf/node_device_conf.c
+++ b/src/
Set nodeDeviceDestroy's return value correctly in failure cases and clarify the
error message generated when the parent device is not vport capable.
David Allan (1):
Fix device destroy return value
src/conf/node_device_conf.c |4 ++--
src/node_device/node_device_driver.c |3 +
On Mon, 2010-05-31 at 18:14 +0200, Jim Meyering wrote:
>
> Hi Stefan,
>
> Sorry, but my suggestion was incomplete. *endptr == '\0' indicates
> a valid conversion, too. That's what would happen if there's no byte
> at all (not even a trailing newline) after the PID. In addition, when
> virStrT
Picking up on a patch series that I had started a while ago:
https://www.redhat.com/archives/libvir-list/2010-April/msg01259.html
I finally have all the pieces in place for a successful run of
./autobuild.sh with a VPATH build. Now, we just have to remember
to run ./autobuild.sh more frequently.
The rule of thumb for generated files:
If they are distributed, they should be generated in $(srcdir);
otherwise, they should be built by the end user in $(builddir).
Since our .xml docs are built with python, and we want them
available even to end users that don't build with python, we
want them d
Try to avoid future regressions on the VPATH front.
* autobuild.sh: Uncomment VPATH use.
* .gitignore: Exclude build directory.
---
The only change from when this patch was first introduced
in v2 of the series is to call ../configure during the mingw build
of ./autobuild.sh.
.gitignore |1
Hello Arnaud,
On 05/12/2010 07:36 PM, Eric Blake wrote:
> On 04/27/2010 05:42 AM, Dev.Atom wrote:
>
> [Sorry for the delayed reply]
[and another delayed response]
>
>> Hi there,
>>
>> I'm trying to compile the libvirt from git (today).
>>
>> I use these configure parameters :
>>
>> ./configure
On Fedora 13 with sufficient mingw32-* packages installed, running
./autobuild.sh failed to cross-compile to mingw because
mingw32-pthreads installed a broken . With that
issue fixed, the build still failed due to use of O_SYNC.
Meanwhile, recent .spec.in changes got out of sync, and running
./au
On 06/02/2010 01:09 PM, David Allan wrote:
> * This patch adds the ability to make the filesystem for a filesystem
> pool during a pool build.
>
> ---
> include/libvirt/libvirt.h.in |6 +-
> include/libvirt/virterror.h |2 +
> src/Makefile.am |4 +
> src/li
On 06/02/2010 01:09 PM, David Allan wrote:
> Change per feedback from Dan B:
The configure.ac portion still has my ack. However,
> * Add libblkid dependency to libvirt.spec.in
> +++ b/libvirt.spec.in
> @@ -228,6 +228,11 @@ BuildRequires: util-linux
> # For showmount in FS driver (netfs discover
On 06/02/2010 01:26 PM, Jim Fehlig wrote:
> Eric Blake wrote:
>> * src/util/bitmap.c (virBitmapAlloc): Tighten sanity check.
>> ---
>>> Yes, you are right - especially since there is no grow operation
>>> :-). I should have returned NULL for size 0 request in the original
>>> version.
>>>
>>
On Wed, 02 Jun 2010 02:49:08 -0300
Eduardo Otubo wrote:
> Last year, Daniel Veillard was invited to talk about Libvirt. I was
> excited to see his lecture but ended up he couldn't come. This year, I
> volunteered myself to speak about the project on the event, DV said it
> was a great idea bec
Eric Blake wrote:
* src/util/bitmap.c (virBitmapAlloc): Tighten sanity check.
---
For that matter, should virBitmapAlloc(0) return NULL, instead of it's
current behavior of allocating an (empty) bitmap?
Yes, you are right - especially since there is no grow operation
:-). I shoul
Change per feedback from Dan B:
* Add libblkid dependency to libvirt.spec.in
---
configure.ac| 25 +
libvirt.spec.in |5 +
2 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index 36ba703..6923ce2 100644
--- a/configure
The following patches add the ability to format filesystem pools when the
appropriate flags are passed to pool build. As before, I have implemented two
new flags:
VIR_STORAGE_POOL_BUILD_NO_OVERWRITE causes the build to probe for an existing
pool of the requested type. The build operation form
* This patch adds the ability to make the filesystem for a filesystem
pool during a pool build.
The patch adds two new flags, no overwrite and overwrite, to control
when mkfs gets executed. By default, the patch preserves the
current behavior, i.e., if no flags are specified, pool build o
* src/util/bitmap.c (virBitmapAlloc): Tighten sanity check.
---
> > For that matter, should virBitmapAlloc(0) return NULL, instead of it's
> > current behavior of allocating an (empty) bitmap?
> >
>
> Yes, you are right - especially since there is no grow operation
> :-). I should have return
On 06/02/2010 08:55 AM, Cole Robinson wrote:
> If VM startup fails early enough (can't find a referenced USB device),
> libvirtd will crash trying to clear the VNC port bit, since port = 0,
> which overflows us out of the bitmap bounds.
>
> Fix this by being more defensive in the bitmap operations
On 06/01/2010 04:03 PM, Eric Blake wrote:
> On 06/01/2010 01:10 PM, Cole Robinson wrote:
>> If VM startup fails early enough (can't find a referenced USB device),
>> libvirtd will crash trying to clear the VNC port bit, since port = 0,
>> which overflows us out of the bitmap bounds.
>>
>> Fix this
If VM startup fails early enough (can't find a referenced USB device),
libvirtd will crash trying to clear the VNC port bit, since port = 0,
which overflows us out of the bitmap bounds.
Fix this by being more defensive in the bitmap operations, and only
clearing a previously set VNC port.
v2: Add
On 06/02/2010 05:34 AM, Daniel P. Berrange wrote:
> On Tue, Jun 01, 2010 at 03:10:19PM -0400, Cole Robinson wrote:
>> If VM startup fails early enough (can't find a referenced USB device),
>> libvirtd will crash trying to clear the VNC port bit, since port = 0,
>> which overflows us out of the bitm
On 06/01/2010 03:48 PM, Laine Stump wrote:
> On 06/01/2010 03:10 PM, Cole Robinson wrote:
>> Fedora bug https://bugzilla.redhat.com/show_bug.cgi?id=598272
>>
>> Some files under /sys/bus/usb/devices/ have the format 'usbX', where
>> X is the USB bus number. Use STRPREFIX to correctly parse the bus
On Tue, Jun 01, 2010 at 03:10:19PM -0400, Cole Robinson wrote:
> If VM startup fails early enough (can't find a referenced USB device),
> libvirtd will crash trying to clear the VNC port bit, since port = 0,
> which overflows us out of the bitmap bounds.
Why is port '0' in the first place ? Don't
26 matches
Mail list logo
