Bug introduced by commit eda0fc7a.
---
src/qemu/qemu_command.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 01adf0d..5e0ca95 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -5345,13
On Tue, Feb 28, 2012 at 13:21:21 +, Daniel P. Berrange wrote:
On Tue, Feb 28, 2012 at 02:16:56PM +0100, Jiri Denemark wrote:
Bug introduced by commit eda0fc7a.
---
src/qemu/qemu_command.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/qemu
Hooks may now be used as filters.
---
daemon/libvirtd.c |6 +++---
src/lxc/lxc_driver.c|6 --
src/qemu/qemu_process.c | 12
src/util/hooks.c| 22 ++
src/util/hooks.h|2 +-
5 files changed, 34 insertions(+), 14
This hook is called during the Prepare phase on destination host and may
be used for changing domain XML.
---
docs/hooks.html.in| 35 +++
src/qemu/qemu_migration.c | 40
src/util/hooks.c |3 ++-
it
appropriately called during the Prepare phase the destination host may
filter incoming domain XMLs and change them to fit local environment.
For example, such hook may relocate disk images. The hook is not
allowed to make guest-visible changes to a domain XML.
Jiri Denemark (2):
hooks: Add support
On Tue, Feb 28, 2012 at 17:17:36 +0100, Michal Privoznik wrote:
On 28.02.2012 14:16, Jiri Denemark wrote:
Bug introduced by commit eda0fc7a.
---
src/qemu/qemu_command.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
ACK
Pushed, thanks.
Jirka
--
libvir-list
On Tue, Feb 28, 2012 at 17:04:29 -0700, Eric Blake wrote:
On 02/28/2012 02:49 PM, Jiri Denemark wrote:
This hook is called during the Prepare phase on destination host and may
be used for changing domain XML.
---
docs/hooks.html.in| 35 +++
src
On Fri, Feb 10, 2012 at 11:13:54 -0700, Eric Blake wrote:
On 02/10/2012 08:22 AM, Martin Kletzander wrote:
Just a cleanup of commit 32f881c6c42f94da70a3782fe20a058fe3dc39cc.
---
src/lxc/lxc_container.c | 17 +++--
1 files changed, 11 insertions(+), 6 deletions(-)
ACK.
I
On Fri, Feb 24, 2012 at 10:44:19 +0100, Martin Kletzander wrote:
In qemu there are 2 cpu models (cpu64-rhel5 and cpu64-rhel6) not
supported by libvirt. This patch adds the support with the flags
specifications from /usr/share/qemu-kvm/cpu-model/cpu-x86_64.conf
The only difference is that
Building virt-aa-helper with dtrace probes enabled, ldd complained about
undefined references:
./.libs/libvirt_util.a(libvirt_util_la-event_poll.o):(.note.stapsdt+0x24):
undefined reference to `libvirt_event_poll_purge_timeout_semaphore'
...
---
src/Makefile.am |3 +++
1 files changed, 3
A multi-threaded client with event loop may crash if one of its threads
closes a connection while event loop is in the middle of sending
keep-alive message (either request or response). The right place for it
is inside virNetClientIOEventLoop() between poll() and
virNetClientLock(). We should only
On Thu, Mar 01, 2012 at 08:45:20 -0700, Eric Blake wrote:
On 03/01/2012 08:12 AM, Jiri Denemark wrote:
Building virt-aa-helper with dtrace probes enabled, ldd complained about
undefined references:
./.libs/libvirt_util.a(libvirt_util_la-event_poll.o):(.note.stapsdt+0x24):
undefined
On Fri, Mar 02, 2012 at 16:12:16 -0700, Eric Blake wrote:
On 03/02/2012 01:49 PM, Jiri Denemark wrote:
A multi-threaded client with event loop may crash if one of its threads
closes a connection while event loop is in the middle of sending
keep-alive message (either request or response
No matter what cache mode is used, readonly disks are always safe wrt
migration. Shared disks are required to be readonly or to disable
host-side cache, which makes them safe as well.
---
src/qemu/qemu_migration.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git
On Mon, Mar 05, 2012 at 15:20:10 +0100, Michal Privoznik wrote:
On 05.03.2012 15:15, Jiri Denemark wrote:
No matter what cache mode is used, readonly disks are always safe wrt
migration. Shared disks are required to be readonly or to disable
host-side cache, which makes them safe as well
On Wed, Mar 07, 2012 at 19:26:25 -0300, Eduardo Habkost wrote:
Awesome. So, if Qemu and libvirt disagrees, libvirt will know that and
add the necessary flags? That was my main worry. If disagreement between
Qemu and libvirt is not a problem, it would make things much easier.
...but:
Is
On Fri, Mar 09, 2012 at 14:31:47 +0100, Martin Kletzander wrote:
We found few more AMD-specific features in cpu64-rhel* models that
made it impossible to start qemu guest on Intel host (with this
setting) even though qemu itself starts correctly with them.
This impacts one test, thus the fix
On Thu, Mar 08, 2012 at 08:11:24 -0700, Eric Blake wrote:
On 03/08/2012 08:02 AM, Martin Kletzander wrote:
We found few more AMD-specific features in cpu64-rhel* models that
made it impossible to start qemu guest on Intel host (with this
setting) even though qemu itself starts correctly
Hi.
On Fri, Mar 09, 2012 at 11:32:47 +, Stefan Hajnoczi wrote:
...
static __inline__ int platform_test_xfs_fd(int fd)
{
struct statfs buf;
if (fstatfs(fd, buf) 0)
return 0;
return (buf.f_type == 0x58465342); /* XFSB */
}
In other words,
On Thu, Mar 08, 2012 at 14:30:05 +0100, Michal Privoznik wrote:
If user hasn't supplied any tlsPort we default to setting it
to zero in our internal structure. However, when building command
line we test it against -1 which is obviously wrong.
---
src/qemu/qemu_command.c |2 +-
1 files
When host-model and host-passthrouh CPU modes were introduced, qemu
driver was properly modify to update guest CPU definition during
migration so that we use the right CPU at the destination. However,
similar treatment is needed for (managed)save and snapshots since they
need to save the exact CPU
On Mon, Mar 12, 2012 at 17:32:45 -0600, Eric Blake wrote:
On 03/12/2012 08:31 AM, Jiri Denemark wrote:
When host-model and host-passthrouh CPU modes were introduced, qemu
driver was properly modify to update guest CPU definition during
migration so that we use the right CPU
Destination daemon should not rely on the client or source daemon
(depending on the type of migration) to call Finish when migration
fails, because the client may crash before it can do so. The domain
prepared for incoming migration is set to be destroyed (and migration
job cleaned up) when
---
src/qemu/qemu_conf.h|5 --
src/qemu/qemu_driver.c |5 --
src/qemu/qemu_process.c | 107 ++
3 files changed, 24 insertions(+), 93 deletions(-)
diff --git a/src/qemu/qemu_conf.h b/src/qemu/qemu_conf.h
index a22ce0c..3306014 100644
---
Add support for registering cleanup callbacks to be run when a domain
transitions to shutoff state.
---
src/qemu/qemu_domain.c | 73 +++
src/qemu/qemu_domain.h | 15 +
src/qemu/qemu_process.c |2 +
3 files changed, 90 insertions(+), 0
in patches 2/5 and
5/5 which fix the issue using infrastructure set up by the other patches in
this series.
Jiri Denemark (5):
qemu: Add support for domain cleanup callbacks
qemu: Avoid dangling migration-in job on shutoff domains
qemu: Add connection close callbacks
qemu: Make autodestroy utilize
When a client which started non-p2p migration dies in a bad time, the
source libvirtd never clears the migration job and almost nothing can be
done with the domain without restarting the daemon. This patch makes use
of connection close callbacks and ensures that migration job is properly
discarded
Add support for registering arbitrary callback to be called for a domain
when a connection gets closed.
---
src/qemu/qemu_conf.c | 172
src/qemu/qemu_conf.h | 27
src/qemu/qemu_driver.c |5 ++
3 files changed, 204 insertions(+),
On Tue, Mar 20, 2012 at 15:56:39 -0600, Eric Blake wrote:
On 03/19/2012 10:18 AM, Jiri Denemark wrote:
Destination daemon should not rely on the client or source daemon
(depending on the type of migration) to call Finish when migration
fails, because the client may crash before it can do so
On Tue, Mar 20, 2012 at 16:33:49 -0600, Eric Blake wrote:
On 03/19/2012 10:19 AM, Jiri Denemark wrote:
When a client which started non-p2p migration dies in a bad time, the
source libvirtd never clears the migration job and almost nothing can be
done with the domain without restarting
This reverts commit 61f2b6ba5fdef0613d6351b99913b5ef468144ce and most of
commit d8916dc8e2f612ab3ce46f32c4bfeb0bd73f6007, which effectively
brings back commit ef1065cf5acad13767c054758cbe7f4e8af5d241 written by
Jim Fehlig:
The qemu migration speed default is 32MiB/s as defined in migration.c
/*
On Wed, Mar 21, 2012 at 08:40:23 -0600, Eric Blake wrote:
On 03/21/2012 08:11 AM, Jiri Denemark wrote:
This reverts commit 61f2b6ba5fdef0613d6351b99913b5ef468144ce and most of
commit d8916dc8e2f612ab3ce46f32c4bfeb0bd73f6007, which effectively
brings back commit
On Mon, Mar 19, 2012 at 17:18:55 +0100, Jiri Denemark wrote:
Libvirt daemon was not completely ready to lose a connection to the client
(may
even be source libvirtd) which is controling the migration. We might end up
with dangling migration jobs on both source and destination daemons. More
On Tue, Mar 20, 2012 at 15:29:37 -0600, Eric Blake wrote:
The oVirt developers have stated that the real reasons they want
to have qemu reuse existing volumes when creating a snapshot are:
1. the management framework is set up so that creation has to be
done from a central node for proper
On Sun, Mar 25, 2012 at 10:26:57 -0500, Anthony Liguori wrote:
On 03/25/2012 10:16 AM, Avi Kivity wrote:
On 03/25/2012 04:59 PM, Anthony Liguori wrote:
So how about:
1) Load ['@SYSCONFDIR@/qemu/qemu.cfg', '@SYSCONFDIR@/qemu/target-@ARCH@.cfg',
'@DATADIR@/system.cfg',
On Mon, Mar 26, 2012 at 15:42:58 +0100, Daniel P. Berrange wrote:
On my x86_64 host I have a pair of Quad core CPUs, each in a separate
NUMA node. The virsh capabilities
topology data reports this:
# virsh capabilities | xmllint --xpath /capabilities/host/cpu -
cpu
On Mon, Mar 26, 2012 at 16:11:08 +0100, Daniel P. Berrange wrote:
On Mon, Mar 26, 2012 at 05:08:05PM +0200, Jiri Denemark wrote:
On Mon, Mar 26, 2012 at 15:42:58 +0100, Daniel P. Berrange wrote:
So, the XML checker is mistaking 'sockets' as the total number of sockets,
rather than
This avoids possible deadlock of the qemu driver in case a domain is
begin migrated (in Begin phase) and unrelated connection to qemu driver
is closed at the right time.
I checked all callers of qemuDomainCheckEjectableMedia() and they are
calling this function with qemu driver locked.
---
On Tue, Mar 27, 2012 at 14:41:15 +0200, Michal Privoznik wrote:
On 27.03.2012 14:19, Jiri Denemark wrote:
This avoids possible deadlock of the qemu driver in case a domain is
begin migrated (in Begin phase) and unrelated connection to qemu driver
is closed at the right time.
I checked
On Tue, Mar 27, 2012 at 15:07:44 -0500, Doug Goldstein wrote:
My XML configs for my VM machines have it set to AMD Opteron G3s, but
libvirt is creating QEMU with a core2duo. This is not correct at all.
I've included the setup and config of one machine that does this. But
another machine that
On Fri, Mar 16, 2012 at 17:35:09 +0100, Michal Privoznik wrote:
If we issue guest command and GA is not running, the issuing thread
will block endlessly. We can check for GA presence by issuing
guest-sync with unique ID (timestamp). We don't want to issue real
command as even if GA is not
On Sat, Mar 31, 2012 at 21:35:50 -0400, Laine Stump wrote:
On 03/31/2012 07:56 AM, Daniel Veillard wrote:
I just made the second release candidate
ftp://libvirt.org/libvirt/libvirt-0.9.11-rc2.tar.gz
along with the rpms and tagged the git tree.
It seems to work okay in my limited
Originally, qemuDomainCheckEjectableMedia was entering monitor with qemu
driver lock. Commit 2067e31bf97667eab9f111b496f5e9a44e827c5b, which I
made to fix that, revealed another issue we had (but didn't notice it
since the driver was locked): we didn't set nested job when
On Mon, Apr 02, 2012 at 09:49:38 -0600, Eric Blake wrote:
On 04/02/2012 08:20 AM, Jiri Denemark wrote:
Originally, qemuDomainCheckEjectableMedia was entering monitor with qemu
driver lock. Commit 2067e31bf97667eab9f111b496f5e9a44e827c5b, which I
made to fix that, revealed another issue we
On Mon, Mar 26, 2012 at 17:39:59 +0200, Michal Privoznik wrote:
and add debug message when adding USB device
to the list of active devices.
---
src/qemu/qemu_hostdev.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
ACK
Jirka
--
libvir-list mailing list
On Mon, Mar 26, 2012 at 17:40:00 +0200, Michal Privoznik wrote:
To prevent assigning one USB device to two domains,
we keep a list of assigned USB devices. On domain
startup - qemuProcessStart() - we insert devices
used by domain into the list but remove them only
on detach-device. Devices
On Mon, Mar 26, 2012 at 17:40:01 +0200, Michal Privoznik wrote:
If the daemon is restarted it will loose list of active
s/loose/lose/
USB devices assigned to active domains. Therefore we need
to rebuild this list on qemuProcessReconnect().
---
src/qemu/qemu_hostdev.c | 40
On Wed, Apr 04, 2012 at 11:17:35 +0100, Daniel P. Berrange wrote:
From: Daniel P. Berrange berra...@redhat.com
* configure.ac: Set WITH_SYSCTL only on Linux hosts
* daemon/Makefile.am: Conditionalize install-sysctl using WITH_SYSCTL
Signed-off-by: Daniel P. Berrange berra...@redhat.com
On Wed, Apr 04, 2012 at 13:47:57 +0100, Daniel P. Berrange wrote:
From: Daniel P. Berrange berra...@redhat.com
linuxNodeInfoCPUPopulate is not built on Mingw32 so
should be in libvirt_linux.syms, not libvirt_private.syms
Signed-off-by: Daniel P. Berrange berra...@redhat.com
---
On Wed, Apr 04, 2012 at 13:47:58 +0100, Daniel P. Berrange wrote:
From: Daniel P. Berrange berra...@redhat.com
---
bootstrap.conf |1 +
po/POTFILES.in |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/bootstrap.conf b/bootstrap.conf
index c6f7fd9..c6620e5
On Wed, Apr 04, 2012 at 13:47:59 +0100, Daniel P. Berrange wrote:
From: Daniel P. Berrange berra...@redhat.com
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
On Fri, Apr 06, 2012 at 12:58:02 +0200, Michal Privoznik wrote:
We can tell qemuDomainSnapshotFSThaw if we want it to report errors or
not. However, if we don't want to and an error has been already set by
previous qemuReportError() we must keep copy of that error not just a
pointer to it.
On Wed, Dec 07, 2011 at 18:20:16 +, Daniel P. Berrange wrote:
On Wed, Dec 07, 2011 at 03:45:10PM +0100, Jiri Denemark wrote:
On Wed, Dec 07, 2011 at 14:30:10 +, Daniel P. Berrange wrote:
While investigating the RPC problems I've noticed that we have had a
huge performance
Without this, libvirtdconftest fails to build with fatal error:
daemon/libvirtd-config.h: No such file or directory
---
tests/Makefile.am |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 57358e9..c4d550f 100644
---
---
po/POTFILES.in |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/po/POTFILES.in b/po/POTFILES.in
index 5d5739a..4c49200 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -1,3 +1,4 @@
+daemon/libvirtd-config.c
daemon/libvirtd.c
daemon/qemu_dispatch.h
daemon/remote.c
As reported by Daniel Berrangé, we have a huge performance regression
for virDomainGetInfo() due to the change which makes virDomainEndJob()
save the XML status file every time it is called. Previous to that
change, 2000 calls to virDomainGetInfo() took ~2.5 seconds. After that
change, 2000 calls
In case an API fails with cannot acquire state change lock, searching
for the API that possibly forgot to end its job is not always easy.
Let's keep track of the job owner and print it out for easier
identification.
---
src/qemu/qemu_domain.c| 53
qemuDomainObjEnterMonitor{,WithDriver} should not be called from async
jobs, only EnterMonitorAsync variant is allowed.
---
src/qemu/qemu_domain.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 7f1f8ee..4dda2e0
On Mon, Apr 09, 2012 at 21:52:14 -0600, Eric Blake wrote:
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,
On Mon, Apr 09, 2012 at 21:52:14 -0600, Eric Blake wrote:
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,
On Mon, Apr 09, 2012 at 21:52:15 -0600, Eric Blake wrote:
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
On Mon, Apr 09, 2012 at 21:52:16 -0600, Eric Blake wrote:
QUESTION: should we parse and ignore mirror 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
On Mon, Apr 09, 2012 at 21:52:17 -0600, Eric Blake wrote:
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
On Mon, Apr 09, 2012 at 21:52:18 -0600, Eric Blake wrote:
As mentioned several commits ago when the capability bits were added,
the new block copy storage migration sequence requires both the
'drive-mirror' and 'drive-reopen' monitor commands.
As of this[1] qemu email, both commands have
On Mon, Apr 09, 2012 at 21:52:19 -0600, Eric Blake wrote:
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)
On Mon, Apr 09, 2012 at 21:52:20 -0600, Eric Blake wrote:
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).
Yeah, thanks for doing that.
On Mon, Apr 09, 2012 at 21:52:21 -0600, Eric Blake wrote:
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 (that is, no REUSE_EXT flag support yet),
SELinux must be disabled, a lock manager is
On Mon, Apr 09, 2012 at 21:52:22 -0600, Eric Blake wrote:
This copies some of the checks from snapshots regarding testing
when a file already exists. In the process, I noticed a missing
sanity check in snapshots: REUSE_EXT should require the destination
to already be present.
*
On Mon, Apr 09, 2012 at 21:52:23 -0600, Eric Blake wrote:
This copies heavily from qemuDomainSnapshotCreateSingleDiskActive(),
in order to set the SELinux label, obtain locking manager lease, and
audit the fact that we hand a new file over to qemu. Alas, releasing
the lease and label on
On Fri, Apr 13, 2012 at 14:59:32 -0600, Eric Blake wrote:
On 04/13/2012 02:45 PM, Jiri Denemark wrote:
On Mon, Apr 09, 2012 at 21:52:23 -0600, Eric Blake wrote:
This copies heavily from qemuDomainSnapshotCreateSingleDiskActive(),
in order to set the SELinux label, obtain locking manager
On Mon, Apr 09, 2012 at 21:52:25 -0600, Eric Blake wrote:
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
On Mon, Apr 09, 2012 at 21:52:26 -0600, Eric Blake wrote:
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 | 26 --
On Mon, Apr 09, 2012 at 21:52:27 -0600, Eric Blake wrote:
Almost trivial; the trick was dealing with the fact that we're
stuck with 'unsigned long bandwidth' due to earlier design
decisions. Also, prefer the correct flag names (although we
intentionally chose the _SHALLOW and _REUSE_EXT
On Fri, Apr 13, 2012 at 09:28:08 -0600, Eric Blake wrote:
On 04/13/2012 05:35 AM, Jiri Denemark wrote:
On Mon, Apr 09, 2012 at 21:52:17 -0600, Eric Blake wrote:
For now, disk migration via block copy job is not implemented. But
when we do implement it, we have to deal with the fact
On Fri, Apr 13, 2012 at 09:15:18 -0600, Eric Blake wrote:
On 04/13/2012 08:46 AM, Jiri Denemark wrote:
I guess I wasn't paying enough attention somewhere but why do we forbid
block
copy for persistent domains? I understand why we want to forbid certain
operations when block copy
On Fri, Apr 13, 2012 at 15:42:20 -0600, Eric Blake wrote:
On 04/13/2012 03:25 PM, Jiri Denemark wrote:
On Mon, Apr 09, 2012 at 21:52:25 -0600, Eric Blake wrote:
This new API provides additional flexibility over what can be
crammed on top of virDomainBlockRebase (namely, the ability
On Mon, Apr 16, 2012 at 17:28:10 -0600, Eric Blake wrote:
On 04/13/2012 09:15 AM, Eric Blake wrote:
On 04/13/2012 08:46 AM, Jiri Denemark wrote:
On Mon, Apr 09, 2012 at 21:52:21 -0600, Eric Blake wrote:
Minimal patch to wire up all the pieces in the previous patches
to actually enable
On Mon, Apr 16, 2012 at 21:21:54 -0600, Eric Blake wrote:
On 04/16/2012 08:29 AM, Jiri Denemark wrote:
/**
+ * virDomainBlockCopy:
+ * @dom: pointer to domain object
+ * @disk: path to the block device, or device shorthand
+ * @dest: path to the copy destination
+ * @format: format
On Mon, Apr 16, 2012 at 23:05:52 -0600, Eric Blake wrote:
No semantic change.
* tools/virsh.c: Fix some spacing issues, {} usage, long lines,
and redundant ().
---
v5: new patch, factored out from comments on other patches
tools/virsh.c | 197
On Mon, Apr 16, 2012 at 23:05:53 -0600, Eric Blake wrote:
Most of our errors complaining about an inability to support a
particular action due to qemu limitations used CONFIG_UNSUPPORTED,
but we had a few outliers. Reported by Jiri Denemark.
* src/qemu/qemu_command.c (qemuBuildDriveDevStr
On Mon, Apr 16, 2012 at 23:05:54 -0600, Eric Blake wrote:
I'm tired of shell-scripting to wait for completion of a block pull,
when virsh can be taught to do the same. I couldn't quite reuse
vshWatchJob, as this is not a case of a long-running command where
a second thread must be used to
On Tue, Apr 17, 2012 at 11:13:53 -0600, Eric Blake wrote:
On 04/17/2012 07:15 AM, Jiri Denemark wrote:
On Mon, Apr 16, 2012 at 23:05:54 -0600, Eric Blake wrote:
I'm tired of shell-scripting to wait for completion of a block pull,
when virsh can be taught to do the same. I couldn't quite
On Mon, Apr 16, 2012 at 23:05:55 -0600, Eric Blake wrote:
This patch introduces a new block job, useful for live storage
migration using pre-copy streaming. Justification for including
this under virDomainBlockRebase rather than adding a new command
includes: 1) there are now two possible
On Mon, Apr 16, 2012 at 23:05:56 -0600, Eric Blake wrote:
Rather than further overloading 'blockpull', I decided to create a
new virsh command to expose the new flags of virDomainBlockRebase.
Blocking until the command completes naturally is pointless, since
the block copy job is intended to
On Mon, Apr 16, 2012 at 23:05:57 -0600, Eric Blake wrote:
In order to track a block copy job across libvirtd restarts, we
need to save internal XML that tracks the name of the file
holding the mirror. Displaying this name in dumpxml might also
be useful to the user, even if we don't yet have
On Wed, Apr 18, 2012 at 15:19:53 +0200, Peter Krempa wrote:
This patch modifies the CPU comparrison function to report the
incompatibilities in more detail to ease identification of problems.
* src/cpu/cpu.h:
cpuGuestData(): Add argument to return detailed error message.
*
On Wed, Apr 18, 2012 at 17:02:35 -0300, Eduardo Habkost wrote:
This is the first try of the new -no-user-config option.
Patches 1 to 3 just move some code around, patch 4 just adds the new option
without adding any new config file. Patch 5 finally creates a /usr/share/qemu
/cpus-x86_64.conf
On Mon, Apr 16, 2012 at 23:05:58 -0600, Eric Blake wrote:
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
On Mon, Apr 16, 2012 at 23:06:00 -0600, Eric Blake wrote:
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. And we'd really love to
have an event without having to poll for the
On Mon, Apr 16, 2012 at 23:06:01 -0600, Eric Blake wrote:
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
On Mon, Apr 16, 2012 at 23:06:03 -0600, Eric Blake wrote:
In qemu, it is possible to call 'migrate_set_speed' prior to
'migrate', and therefore ensure a constant throttling through the
entire migration. However, this is not possible with
'block-job-set-speed', which fails if a job is not
On Mon, Apr 16, 2012 at 23:06:02 -0600, Eric Blake wrote:
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 (that is, no REUSE_EXT flag support yet),
SELinux must be disabled, a lock manager is
On Mon, Apr 16, 2012 at 23:06:05 -0600, Eric Blake wrote:
This copies heavily from qemuDomainSnapshotCreateSingleDiskActive(),
in order to set the SELinux label, obtain locking manager lease, and
audit the fact that we hand a new file over to qemu. Alas, releasing
the lease and label on
On Mon, Apr 16, 2012 at 23:06:04 -0600, Eric Blake wrote:
This copies some of the checks from snapshots regarding testing
when a file already exists. In the process, I noticed snapshots
had hard-to-read logic, as well as a missing sanity check:
REUSE_EXT should require the destination to
On Tue, Apr 24, 2012 at 16:56:37 +0200, Peter Krempa wrote:
The docs for virConnectSetKeepAlive() advertise that this function
should be able to disable keepalives on negative or zero interval time.
This patch removes the check that prohibited this and adds code to
disable keepalives on
Once qemu monitor reports migration has completed, we just closed our
end of the pipe and let migration tunnel die. This generated bogus error
in case we did so before the thread saw EOF on the pipe and migration
was aborted even though it was in fact successful.
With this patch we first wake up
In some cases (spotted with broken connection during tunneled migration)
we were overwriting the original error with worse or even misleading
errors generated when we were cleaning up after failed migration.
---
src/qemu/qemu_migration.c | 20
1 files changed, 20
All bugs fixed by the following patches were spotted while testing
tunnelled migration. However, the first three of them may also be hit in
other scenarios.
Jiri Denemark (4):
qemu: Preserve original error during migration
rpc: Discard non-blocking calls only when necessary
qemu: Fix
When QEMU reported failed or canceled migration, we correctly detected
it but didn't really consider it as an error condition and migration
protocol just went on. Luckily, some of the subsequent steps eventually
failed end we reported an (unrelated and mostly random) error back to
the caller.
---
Currently, non-blocking calls are either sent immediately or discarded
in case sending would block. This was implemented based on the
assumption that the non-blocking keepalive call is not needed as there
are other calls in the queue which would keep the connection alive.
However, if those calls
1 - 100 of 7240 matches
Mail list logo
