On Wed, Jan 06, 2010 at 09:55:23PM +0100, Jim Meyering wrote:
Daniel Veillard wrote:
On Wed, Jan 06, 2010 at 12:46:11PM +0100, Jim Meyering wrote:
As the log says, once we've dereferenced it,
there's no point in comparing to NULL.
From 463eaf1027a154e71839a67eca85b3ada8b817ff Mon Sep
Daniel P. Berrange wrote:
On Wed, Jan 06, 2010 at 09:55:23PM +0100, Jim Meyering wrote:
Daniel Veillard wrote:
On Wed, Jan 06, 2010 at 12:46:11PM +0100, Jim Meyering wrote:
As the log says, once we've dereferenced it,
there's no point in comparing to NULL.
From
On Thu, Jan 07, 2010 at 09:37:57AM +0100, Jim Meyering wrote:
Daniel P. Berrange wrote:
Considering that this is in the daemon and that bad things
have been known to happen via NULL derefs, some would
argue that an assertion failure is preferable.
No, this code is the client side of the
On 06/01/10 18:56, Nikola Ciprich wrote:
I've had similar trouble with old bios images. Once I replaced them with
those built with qemu-kvm, things started working...
I've using the packages from virt-preview so I've got whatever BIOS
images are being packaged. I've experimented some more
On Thu, Jan 07, 2010 at 11:03:23AM +0100, Daniel Veillard wrote:
On Thu, Jan 07, 2010 at 09:37:57AM +0100, Jim Meyering wrote:
However, the point is still valid, so I'll wait for confirmation.
This is still about defensive coding, i.e., ensuring that
maintenance doesn't violate
On Thu, Jan 07, 2010 at 10:08:33AM +, Tom Hughes wrote:
On 06/01/10 18:56, Nikola Ciprich wrote:
I've had similar trouble with old bios images. Once I replaced them with
those built with qemu-kvm, things started working...
I've using the packages from virt-preview so I've got whatever
2010/1/7 Prashant Wakchaure prashant.wakcha...@gmail.com:
Is anybody know how to connect libvirt to VirtualBox remotely
--
Thanks Regards,
Prashant Wakchaure
See http://www.libvirt.org/drvvbox.html for some example remote URIs
for VirtualBox and see http://www.libvirt.org/remote.html
2010/1/5 Jim Meyering j...@meyering.net:
obvious typo:
From 6f0810192dc6d9b223f2f973812fd787f398576c Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Tue, 5 Jan 2010 15:48:42 +0100
Subject: [PATCH] network/bridge_driver.c: avoid potential NULL-dereference
*
Matthias Bolte wrote:
diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c
...
- if (argv) {
+ if (*argv) {
...
ACK.
Thanks. Pushed.
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
The -mem-prealloc flag should be used when using large pages
This ensures qemu tries to allocate all required memory immediately,
rather than when first used. The latter mode will crash qemu
if hugepages aren't available when accessed, while the former
should gracefully fallback to non-hugepages.
On 01/07/2010 01:03 AM, Dustin Xiong wrote:
I sloved the problem. I modify the libvirt /src/qemu_conf.c. Add the arch
ia64 into the
static const struct qemu_arch_info const arch_info_hvm[] = {}
as berrange said. So the libvirt passing -M ia64.
But the kvm binary only experts '-M
On Thu, Jan 07, 2010 at 02:53:20PM +0100, Daniel Veillard wrote:
The -mem-prealloc flag should be used when using large pages
This ensures qemu tries to allocate all required memory immediately,
rather than when first used. The latter mode will crash qemu
if hugepages aren't available when
Laine Stump noticed a failure to build with --disable-shared
and found that removing the unconditional -shared option in
python/Makefile.am would fix it.
The change below reverts 8838ee39ab1c2bb7fffe93bfda220692664e8be6,
so Diego, if your goal (with the reverted change) was more than to
avoid
Il giorno gio, 07/01/2010 alle 21.14 +0100, Jim Meyering ha scritto:
The change below reverts 8838ee39ab1c2bb7fffe93bfda220692664e8be6,
so Diego, if your goal (with the reverted change) was more than to
avoid seemingly-unnecessary work, please tell us what it was.
Well, to put it simply:
Jim Fehlig wrote:
Daniel Veillard wrote:
On Wed, Dec 23, 2009 at 10:59:09AM -0700, Jim Fehlig wrote:
xen-unstable c/s 20685 changed the domctl interface, adding a field to
xen_domctl_getdomaininfo structure. This additional field causes stack
corruption in libvirt.
Diego Elio “Flameeyes” Pettenò wrote:
Il giorno gio, 07/01/2010 alle 21.14 +0100, Jim Meyering ha scritto:
The change below reverts 8838ee39ab1c2bb7fffe93bfda220692664e8be6,
so Diego, if your goal (with the reverted change) was more than to
avoid seemingly-unnecessary work, please tell us
On Thu, Jan 07, 2010 at 09:19:17PM +0100, Diego Elio ???Flameeyes??? Petten?
wrote:
Il giorno gio, 07/01/2010 alle 21.14 +0100, Jim Meyering ha scritto:
The change below reverts 8838ee39ab1c2bb7fffe93bfda220692664e8be6,
so Diego, if your goal (with the reverted change) was more than to
Il giorno gio, 07/01/2010 alle 21.29 +0100, Jim Meyering ha scritto:
But --disable-shared is useful, and your change broke it.
On the usefulness of that I have generally a lot to say, but that's
another topic.
As such, I can't see how you would be using --disable-shared.
Very simple:
On Thu, Jan 07, 2010 at 08:36:25PM +, Daniel P. Berrange wrote:
On Thu, Jan 07, 2010 at 09:19:17PM +0100, Diego Elio ???Flameeyes??? Petten?
wrote:
Il giorno gio, 07/01/2010 alle 21.14 +0100, Jim Meyering ha scritto:
The change below reverts
Il giorno gio, 07/01/2010 alle 22.23 +0100, Daniel Veillard ha scritto:
I assume Jim want to keep --disable-shared as a convenient way to
force libtool to generated binaries statically linked which is easier
when dealing with gdb. If that's the case what would be nice is to be
able to
Diego Elio “Flameeyes” Pettenò wrote:
Il giorno gio, 07/01/2010 alle 21.29 +0100, Jim Meyering ha scritto:
But --disable-shared is useful, and your change broke it.
On the usefulness of that I have generally a lot to say, but that's
another topic.
As such, I can't see how you would be
Il giorno gio, 07/01/2010 alle 23.03 +0100, Jim Meyering ha scritto:
So your change forced all other users of --disable-shared
to also configure with --without-python, but did not inform them
of the new constraint. BTW, it also rendered build instructions
in the FAQ invalid.
I don't want
---
HACKING |6 +++---
docs/FAQ.html.in|2 +-
docs/bugs.html.in |6 +++---
docs/contact.html.in|4 ++--
docs/deployment.html.in |4 ++--
docs/hacking.html.in|6 +++---
src/Makefile.am |2 +-
7 files changed, 15
Date: Thu, 7 Jan 2010 09:15:32 -0500
From: crobi...@redhat.com
To: x_k_...@hotmail.com
CC: berra...@redhat.com; libvirt-l...@redhat.com
Subject: Re: [libvirt] [virt-tools-list] Questions about virt-manager running
on Arch of Itanium 64
On 01/07/2010 01:03 AM, Dustin Xiong wrote:
Similar to virExecWithHook, but waits for child to exit. Useful for
doing things like setuid after the fork but before the exec.
---
src/util/util.c | 25 ++---
src/util/util.h |3 +++
2 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/src/util/util.c
I'm planning to use these to fix the problems with creating storage
volumes on root-squashing NFS servers, but since they may be of
general utility I thought I'd throw them out for comments beforehand -
it something different would make them more generally useful, better
to change it now than
These functions create a new file or directory with the given
uid/gid. If the flag VIR_FILE_CREATE_AS_UID is given, they do this by
forking a new process, calling setuid/setgid in the new process, and
then creating the file. This is better than simply calling open then
fchown, because in the
Please review.
-Original Message-
From: Iyer, Shyam
Sent: Monday, December 28, 2009 2:53 PM
To: libvir-list@redhat.com
Cc: Bellad, Sudhir; Domsch, Matt; KM, Paniraja; dal...@redhat.com
Subject: [Patch v0.5] iSCSI Multi-IQN (Libvirt Support)
This patch set realizes the multi-IQN
28 matches
Mail list logo
