virDirCreate also previously returned 0 on success and errno on
failure. This makes it fit the recommended convention of returning 0
on success, -errno (ie a negative number) on failure.
---
src/storage/storage_backend_fs.c |8
src/util/util.c | 32 +
One error exit in virStorageBackendCreateBlockFrom was setting the
return value to errno. The convention for volume build functions is to
return 0 on success or -1 on failure. Not only was it not necessary to
set the return value (it defaults to -1, and is set to 0 when
everything has been successf
virFileOperation previously returned 0 on success, or the value of
errno on failure. Although there are other functions in libvirt that
use this convention, the preferred (and more common) convention is to
return 0 on success and -errno (or simply -1 in some cases) on
failure. This way the check fo
These patches started out as a more "correct" fix for the patch
https://www.redhat.com/archives/libvir-list/2010-July/msg00257.html
(and they supercede that patch).
Daniel Berrange suggested that it would be better to switch the
function virFileOperation over to use the preferred convention o
Previously virStorageBackendCopyToFD would simply return -1 on
error. This made the error return from one of its callers inconsistent
(createRawFileOpHook is supposed to return -errno, but if
virStorageBackendCopyToFD failed, createRawFileOpHook would just
return -1). Since there is a useful errno
Dear all,
Im trying to connet to libvirtd on my local machine, but i only can contact
as root user.
When i run virsh command as root user, all works as expected:
[r...@localhost libvirt]# virsh list
Id Name State
--
When i try to run virsh as use
On 07/19/2010 03:24 PM, Chris Lalancette wrote:
On 07/08/10 - 11:39:07AM, Chris Lalancette wrote:
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.
ping, an
On 07/19/2010 05:08 PM, Laine Stump wrote:
> Originally the storage volume files were opened with O_DSYNC to make
> sure they were flushed to disk immediately. It turned out that this
> was extremely slow in some cases, so the O_DSYNC was removed in favor
> of just calling fsync() after all the dat
On 07/19/2010 05:08 PM, Laine Stump wrote:
> A missing set of braces around an error condition caused us to skip
> zero'ing out the remainder of a new volume file if the new volume was
> longer than the original (the goto was supposed to be taken only in
> the case of error, but was always being ta
Originally the storage volume files were opened with O_DSYNC to make
sure they were flushed to disk immediately. It turned out that this
was extremely slow in some cases, so the O_DSYNC was removed in favor
of just calling fsync() after all the data had been written. However,
this call to fsync was
A missing set of braces around an error condition caused us to skip
zero'ing out the remainder of a new volume file if the new volume was
longer than the original (the goto was supposed to be taken only in
the case of error, but was always being taken).
---
src/storage/storage_backend.c |3 ++-
Both of these problems can occur only if a new storage volume is
created by copying it from an existing volume. The first is a problem
if the new volume is longer than the old (the new volume won't be
zero-filled at the end), and the second happens if the new and old
volumes are the same length (f
On 07/16/10 - 09:38:10AM, Chris Lalancette wrote:
> If you try to execute two concurrent migrations p2p
> from A->B and B->A, the two libvirtd's will deadlock
> trying to perform the migrations. The reason for this is
> that in p2p migration, the libvirtd's are responsible for
> making the RPC Pre
On 07/07/10 - 05:35:39PM, Chris Lalancette wrote:
> After playing around with virsh setmaxmem for a bit,
> I ran into some surprising behavior; if a hypervisor does
> not support the virDomainSetMaxMemory() API, but the value
> specified for setmaxmem is less than the current amount
> of memory in
On 07/08/10 - 11:39:07AM, Chris Lalancette wrote:
> 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.
ping, any reviews here?
>
> Signed-off-by: Chris L
On Mon, Jul 19, 2010 at 09:58:35PM +0300, Dan Kenigsberg wrote:
> On Mon, Jul 19, 2010 at 02:40:40PM +0200, Jiri Denemark wrote:
> > > > By specifying element in CPU requirements a guest can be
> > > > restricted to run only on CPUs by a given vendor. Host CPU vendor is
> > > > also specified in c
On 07/17/10 - 06:08:17PM, Matthias Bolte wrote:
> 2010/7/8 Chris Lalancette :
> > Otherwise you can get bogus "unknown error" printouts on
> > subsequent commands.
> >
> > Signed-off-by: Chris Lalancette
> > ---
> > tools/virsh.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
On Mon, Jul 19, 2010 at 02:40:40PM +0200, Jiri Denemark wrote:
> > > By specifying element in CPU requirements a guest can be
> > > restricted to run only on CPUs by a given vendor. Host CPU vendor is
> > > also specified in capabilities XML.
> > >
> > > The vendor is checked when migrating a gue
On 07/17/10 - 06:08:03PM, Matthias Bolte wrote:
> 2010/7/8 Chris Lalancette :
> > 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 w
On 07/17/10 - 09:30:29PM, Jaromír Červenka wrote:
> Good evening,
>
> could anybody explain me this, please?
>
> divinus:~ # virsh
> error: cannot recv data: : Connection reset by peer
> error: failed to connect to the hypervisor
> divinus:~ #
>
> I am trying to imlement Chris's ruby-libvirt to
On Mon, Jul 19, 2010 at 01:26:10AM +0200, Matthias Bolte wrote:
> Add a pointer to the primary context of a connection and use it in all
> driver functions that don't dependent on the context type. This includes
> almost all functions that deal with a virDomianPtr. Therefore, using
> a vpx:// conne
On Wed, Jul 14, 2010 at 03:44:54PM -0400, Cole Robinson wrote:
> targetType only tracks the actual format we are parsing.
> TYPE_DEFAULT is the typical serial/parallel format, NONE is for the
> device which prints nothing.
>
> Signed-off-by: Cole Robinson
> ---
> src/conf/domain_conf.c | 108
On Wed, Jul 14, 2010 at 03:44:56PM -0400, Cole Robinson wrote:
> Enable specifying a virtio console device with:
>
>
>
>
What purpose does the 'name' field serve here ? It is used for
virtio serial devices to format the
/dev/virtio-serial/arbitrary.virtio.serial.port.name
device node in th
On Wed, Jul 14, 2010 at 03:44:55PM -0400, Cole Robinson wrote:
> Change console handling to a proper device list, as done for other
> character devices. Even though certain drivers can actually handle multiple
> consoles, for now just maintain existing behavior where possible.
>
> Signed-off-by: C
On Wed, Jul 14, 2010 at 03:44:52PM -0400, Cole Robinson wrote:
>
> Signed-off-by: Cole Robinson
> ---
> docs/formatdomain.html.in | 12
> 1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
> index 4cca67f..b569
On Wed, Jul 14, 2010 at 03:44:53PM -0400, Cole Robinson wrote:
> There is actually a difference between the character device type (serial,
> parallel, channel, ...) and the target type (virtio, guestfwd). Currently
> they are awkwardly conflated.
>
> Start to pull them apart by renaming targetType
On 07/17/10 - 06:07:30PM, Matthias Bolte wrote:
> 2010/7/8 Chris Lalancette :
> > 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
On 07/15/2010 01:27 PM, Fernando Carvalho wrote:
> I'm having trouble setting virtual network.
> The debug log is the following:
>
> --XML dump of the network I'm trying to set--
>
> virsh # net-dumpxml net0
>
> net0
> bb909289-700a-87f8-c075-910209d1a2e3
>
>
>
>
>
>
On 07/17/10 - 06:07:00PM, Matthias Bolte wrote:
> For example this one. I tested it with and without this patch.
>
> Without this patch we get
>
> virsh # snapshot-create test1 this-file-does-not-exist.xml
> error: Failed to open file 'this-file-does-not-exist.xml': No such
> file or directory
>
On Mon, Jul 19, 2010 at 03:01:29PM +0200, Harald Dunkel wrote:
> I did an upgrade to libvirt-0.8.2 today. Using this new
> version the problem seems to be gone. I would guess you
> started your test with 0.8.2, too?
>
> Many thanx for your help.
>
>
> Regards
>
> Harri
Harri,
Glad it's workin
I did an upgrade to libvirt-0.8.2 today. Using this new
version the problem seems to be gone. I would guess you
started your test with 0.8.2, too?
Many thanx for your help.
Regards
Harri
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
> > By specifying element in CPU requirements a guest can be
> > restricted to run only on CPUs by a given vendor. Host CPU vendor is
> > also specified in capabilities XML.
> >
> > The vendor is checked when migrating a guest but it's not forced, i.e.,
> > a guest configured without element can
On Sat, Jul 17, 2010 at 06:07:30PM +0200, Matthias Bolte wrote:
> 2010/7/8 Chris Lalancette :
> > 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
> > majori
33 matches
Mail list logo
