2012/4/6 Daniel Veillard :
> On Thu, Apr 05, 2012 at 06:44:35PM +0200, Stefan Bader wrote:
>> This causes an implicit vkbd device to be added which takes
>> 6min to finally fail being initialized in the guest.
>>
>> http://lists.xen.org/archives/html/xen-devel/2012-04/msg00409.html
>>
>> Signed-off
This patch allows to config block device for container.
the disk node is used to point out source device and target device
source device is the device path in host,
and target device is the device name in container.
such as
Unfortunately it's no use to config readonly in disk node
On Thu, Apr 05, 2012 at 10:24:49PM -0600, Eric Blake wrote:
> Leak introduced in commit 0436d32. If we allocate an actions array,
> but fail early enough to never consume it with the qemu monitor
> transaction call, we leaked memory.
>
> But our semantics of making the transaction command free th
On Thu, Apr 05, 2012 at 06:44:35PM +0200, Stefan Bader wrote:
> This causes an implicit vkbd device to be added which takes
> 6min to finally fail being initialized in the guest.
>
> http://lists.xen.org/archives/html/xen-devel/2012-04/msg00409.html
>
> Signed-off-by: Stefan Bader
> ---
> src/x
v1 was here:
https://www.redhat.com/archives/libvir-list/2012-April/msg00068.html
changes from v1: Paolo has updated the qemu side of things, and built
a scratch image for RHEL that I was able to test with for the new
semantics. I was actually able to successfully run two different
block copy job
The new block copy storage migration sequence requires both the
'drive-mirror' action in 'transaction' (present if the 'drive-mirror'
standalone monitor command also exists) and the 'drive-reopen' monitor
command (it would be nice if that were also part of a 'transaction',
but the initial qemu impl
This new API provides additional flexibility over what can be
crammed on top of virDomainBlockRebase (namely, the ability to
specify an arbitrary destination format, for things like copying
qcow2 into qed without having to pre-create the destination), at
the expense that it cannot be backported wit
Minimal patch to wire up all the pieces in the previous patches
to actually enable a block copy job. By minimal, I mean that
qemu creates the file, SELinux must be disabled, a lock manager
is not informed, and the audit logs aren't updated. But those
will be added as improvements in future patche
Almost trivial; the trick was dealing with the fact that we're
stuck with 'unsigned long bandwidth' due to earlier design
decisions.
* src/remote/remote_protocol.x (remote_domain_block_copy_args):
New struct.
* src/remote/remote_driver.c (remote_driver): Use it.
* src/rpc/gendispatch.pl (name_to_P
RHEL-only
drive-mirror and drive-reopen are still under upstream qemu
discussion; as a result, RHEL decided to backport things under
a downstream name. Accommodate this alternate spelling. I
don't think it's worth trying to support both spellings at once.
* src/qemu/qemu_monitor_json.c (qemuMon
Handle the new type of block copy event and info. Of course,
this patch does nothing until a later patch actually allows the
creation/abort of a block copy job.
* src/qemu/qemu_monitor_json.c (qemuMonitorJSONHandleBlockJobImpl)
(qemuMonitorJSONGetBlockJobInfoOne): Translate new job type.
* src/qe
QUESTION: should we parse and ignore on input, rather than
rejecting it? By rejecting it, I can't add a unit test, since the
unit test framework currently doesn't expose a way to trigger
internal parsing.
In order to track a block copy job across libvirtd restarts, we
need to save internal XML t
For now, disk migration via block copy job is not implemented. But
when we do implement it, we have to deal with the fact that qemu does
not provide an easy way to re-start a qemu process with mirroring
still intact (it _might_ be possible by using qemu -S then an
initial 'drive-mirror' with disk
Rather than further overloading 'blockpull', I decided to create a
new virsh command to expose the new flags of virDomainBlockRebase.
Someday, I'd also like to make blockpull and blockcopy have a
synchronous mode, which blocks until the event happens or Ctrl-C
is pressed, as well as a --verbose fl
Expose the full abilities of virDomainBlockCopy.
* tools/virsh.c (blockJobImpl): Add --format option for block copy.
* tools/virsh.pod (blockcopy): Document this.
---
tools/virsh.c | 25 -
tools/virsh.pod | 10 +-
2 files changed, 25 insertions(+), 10 deletio
In my testing, I was able to provoke an odd block pull failure:
$ virsh blockpull dom vda --bandwidth 1
error: Requested operation is not valid: No active operation on device:
drive-virtio-disk0
merely by using gdb to artifically wait to do the block job set speed
until after the pull had al
This patch introduces a new block job, useful for live storage
migration using pre-copy streaming.
Using a live VM with the backing chain:
base <- snap1 <- snap2
as the starting point, we have:
- virDomainBlockRebase(dom, disk, "/path/to/copy", 0,
VIR_DOMAIN_BLOCK_REBASE_COPY)
creates /path
From: Adam Litke
Without the VIR_DOMAIN_BLOCK_JOB_ABORT_ASYNC flag, libvirt will internally poll
using qemu's "query-block-jobs" API and will not return until the operation has
been completed. API users are advised that this operation is unbounded and
further interaction with the domain during t
This is the bare minimum to end a copy job (of course, until a
later patch adds the ability to start a copy job, this patch
doesn't do much in isolation; I've just split the patches to
ease the review).
This patch intentionally avoids SELinux, lock manager, and audit
actions, saving that for a lat
From: Adam Litke
Qemu has changed the semantics of the "block_job_cancel" API. The original
qed implementation (pretty much only backported to RHEL 6.2 qemu) was
synchronous (ie. upon command completion, the operation was guaranteed to
be completely stopped). With the new semantics going into q
On 04/05/2012 08:22 PM, Eric Blake wrote:
> gcc 4.7 warns about uninitialized struct members
>
> * tests/testutilsqemu.c (testQemuCapsInit): Populate new members.
> * tests/viruritest.c (mymain): Likewise.
> ---
>
> Another warning cleanup, worth pushing at the same time as whichever
> solution w
Leak introduced in commit 0436d32. If we allocate an actions array,
but fail early enough to never consume it with the qemu monitor
transaction call, we leaked memory.
But our semantics of making the transaction command free the caller's
memory is awkward; avoiding the memory leak requires making
On 04/05/2012 09:42 PM, Daniel Veillard wrote:
> On Thu, Apr 05, 2012 at 08:22:51PM -0600, Eric Blake wrote:
>> gcc 4.7 warns about uninitialized struct members
>>
>> * tests/testutilsqemu.c (testQemuCapsInit): Populate new members.
>> * tests/viruritest.c (mymain): Likewise.
>> ---
>>
>> Another w
On 04/05/2012 09:20 PM, Daniel Veillard wrote:
> On Thu, Apr 05, 2012 at 05:13:24PM -0600, Eric Blake wrote:
>> From: Laine Stump
>>
>> When building on Fedora 17 (which uses gcc 4.7.0) with -O0 in CFLAGS,
>> three of the tests failed to compile.
>>
> ACK,
Thanks; pushed.
--
Eric Blake ebl
On Thu, Apr 05, 2012 at 04:01:03PM -0600, Eric Blake wrote:
> Leak introduced in commit 0436d32. If we allocate an actions array,
> but fail early enough to never consume it with the qemu monitor
> transaction call, we leaked memory.
>
> But our semantics of making the transaction command free th
On Thu, Apr 05, 2012 at 08:22:51PM -0600, Eric Blake wrote:
> gcc 4.7 warns about uninitialized struct members
>
> * tests/testutilsqemu.c (testQemuCapsInit): Populate new members.
> * tests/viruritest.c (mymain): Likewise.
> ---
>
> Another warning cleanup, worth pushing at the same time as whic
On Thu, Apr 05, 2012 at 05:13:24PM -0600, Eric Blake wrote:
> From: Laine Stump
>
> When building on Fedora 17 (which uses gcc 4.7.0) with -O0 in CFLAGS,
> three of the tests failed to compile.
>
> cputest.c and qemuxml2argvtest.c had non-static structs defined
> inside the macro that was being
gcc 4.7 warns about uninitialized struct members
* tests/testutilsqemu.c (testQemuCapsInit): Populate new members.
* tests/viruritest.c (mymain): Likewise.
---
Another warning cleanup, worth pushing at the same time as whichever
solution we pick for the large stack size.
tests/testutilsqemu.c |
From: Laine Stump
When building on Fedora 17 (which uses gcc 4.7.0) with -O0 in CFLAGS,
three of the tests failed to compile.
cputest.c and qemuxml2argvtest.c had non-static structs defined
inside the macro that was being repeatedly invoked. Due to some so-far
unidentified change in gcc, the sta
Leak introduced in commit 0436d32. If we allocate an actions array,
but fail early enough to never consume it with the qemu monitor
transaction call, we leaked memory.
But our semantics of making the transaction command free the caller's
memory is awkward; avoiding the memory leak requires making
On 04/05/2012 01:34 PM, Laine Stump wrote:
> On 04/05/2012 03:16 PM, Eric Blake wrote:
>> Leak introduced in commit 0436d32. If we allocate an actions array,
>> but fail early enough to never consume it with the qemu monitor
>> transaction call, we leaked memory.
>>
>> * src/qemu/qemu_driver.c (qe
On 04/05/2012 02:31 PM, Laine Stump wrote:
> When building on Fedora 17 (which uses gcc 4.7.0) with -O0 in CFLAGS,
> three of the tests failed to compile.
>
> cputest.c and qemuxml2argvtest.c had non-static structs defined
> inside the macro that was being repeatedly invoked. Due to some so-far
>
When building on Fedora 17 (which uses gcc 4.7.0) with -O0 in CFLAGS,
three of the tests failed to compile.
cputest.c and qemuxml2argvtest.c had non-static structs defined
inside the macro that was being repeatedly invoked. Due to some so-far
unidentified change in gcc, the stack space used by var
On 04/05/2012 03:16 PM, Eric Blake wrote:
> Leak introduced in commit 0436d32. If we allocate an actions array,
> but fail early enough to never consume it with the qemu monitor
> transaction call, we leaked memory.
>
> * src/qemu/qemu_driver.c (qemuDomainSnapshotCreateDiskActive):
> Free actions
Leak introduced in commit 0436d32. If we allocate an actions array,
but fail early enough to never consume it with the qemu monitor
transaction call, we leaked memory.
* src/qemu/qemu_driver.c (qemuDomainSnapshotCreateDiskActive):
Free actions array on failure.
---
src/qemu/qemu_driver.c |2
This causes an implicit vkbd device to be added which takes
6min to finally fail being initialized in the guest.
http://lists.xen.org/archives/html/xen-devel/2012-04/msg00409.html
Signed-off-by: Stefan Bader
---
src/xenxs/xen_sxpr.c | 11 ---
src/xenxs/xen_xm.c |2 +-
2 files ch
On 04/05/2012 09:52 AM, Guido Günther wrote:
> This got dropped with 300e60e15b22387dda41ed5985a9ebadfd86dd25
Good catch.
> +TEST_PARSE("test://f...@example.com", "test", "example.com", 0, NULL,
> NULL, NULL, "foo", NULL);
and thanks for adding the test case that proves it.
ACK.
--
Eric
This got dropped with 300e60e15b22387dda41ed5985a9ebadfd86dd25
Cheers,
-- Guido
---
src/util/viruri.c |5 -
tests/viruritest.c | 24 +---
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/src/util/viruri.c b/src/util/viruri.c
index 2c6de51..a41f345 1
On 04/05/2012 07:58 PM, Peter Krempa wrote:
This test case checks if the console connection code works in a safe way
that the connection don't get messed up.
---
Diff to v1:
-- removed semicolons at the end of statements (the C language left some habits
:D)
-- added call to usage function (I tho
On 04/05/2012 07:58 PM, Peter Krempa wrote:
This helper exception helps with reporting test errors that don't
produce a libvirt exception. Eg. comparison of returned and expected
value fails although the api call succeeded.
---
Diff to v1:
-- moved the new exception to the exception module
exc
This helper exception helps with reporting test errors that don't
produce a libvirt exception. Eg. comparison of returned and expected
value fails although the api call succeeded.
---
Diff to v1:
-- moved the new exception to the exception module
exception.py |4
1 files changed, 4 inser
This test case checks if the console connection code works in a safe way
that the connection don't get messed up.
---
Diff to v1:
-- removed semicolons at the end of statements (the C language left some habits
:D)
-- added call to usage function (I thought it's called automaticaly. With this
this
On 04/05/2012 05:19 PM, Osier Yang wrote:
On 2012年04月05日 17:17, Alex Jia wrote:
Detected by valgrind. Leaks are introduced in commit b22eaa7.
* src/conf/domain_conf.c (virDomainDiskDefParseXML): fix memory leaks.
How to reproduce?
% make&& make -C tests check TESTS=qemuxml2argvtest
% cd test
On 2012年04月05日 17:17, Alex Jia wrote:
Detected by valgrind. Leaks are introduced in commit b22eaa7.
* src/conf/domain_conf.c (virDomainDiskDefParseXML): fix memory leaks.
How to reproduce?
% make&& make -C tests check TESTS=qemuxml2argvtest
% cd tests&& valgrind -v --leak-check=full ./qemuxm
Detected by valgrind. Leaks are introduced in commit b22eaa7.
* src/conf/domain_conf.c (virDomainDiskDefParseXML): fix memory leaks.
How to reproduce?
% make && make -C tests check TESTS=qemuxml2argvtest
% cd tests && valgrind -v --leak-check=full ./qemuxml2argvtest
actual result:
==2143== 12
On 04/05/2012 04:36 PM, Yaniv Hadad wrote:
Hi All,
I look for someone who have experience with the Java API.
My aim is to investigate hyper visors and their guest details like : os,
network , ran,vCPU and more...
Can some one have experience with that ??
Yaniv.
ww.redhat.com/mailman/listinfo/li
Hi All,
I look for someone who have experience with the Java API.
My aim is to investigate hyper visors and their guest details like : os,
network , ran,vCPU and more...
Can some one have experience with that ??
Yaniv.
On 2012年04月05日 15:32, Laine Stump wrote:
This bug resolves https://bugzilla.redhat.com/show_bug.cgi?id=810100
rpm builds for i686 were failing with a segfault in
networkxml2argvtest. Running under valgrind showed that a region of
memory was being referenced after it had been freed (as the result
On 04/04/2012 11:09 PM, Laine Stump wrote:
On 03/29/2012 08:14 AM, Martin Kletzander wrote:
So here are the things I would like to do definitely (the optional
things follow later on):
- fix hard-coded options into real options (e.g. commit 65449e)
Forgive me if I'm suggesting things that alre
Hello Laine,
On Thursday 05 April 2012 09:32:45 Laine Stump wrote:
> This bug resolves https://bugzilla.redhat.com/show_bug.cgi?id=810100
>
> rpm builds for i686 were failing with a segfault in
> networkxml2argvtest. Running under valgrind showed that a region of
> memory was being referenced afte
This bug resolves https://bugzilla.redhat.com/show_bug.cgi?id=810100
rpm builds for i686 were failing with a segfault in
networkxml2argvtest. Running under valgrind showed that a region of
memory was being referenced after it had been freed (as the result of
realloc - see the valgrind report in th
On Wed, Apr 04, 2012 at 01:47:59PM +0100, Daniel P. Berrange wrote:
> From: "Daniel P. Berrange"
>
> Every now & then, with parallel builds, we get a failure to
> validate hvsupport.html.in. I eventually noticed that this
> is because we get 2 instances of the generator running at
> once.
Gah
52 matches
Mail list logo
