On 04/21/2011 10:24 AM, Daniel P. Berrange wrote:
On Thu, Apr 21, 2011 at 09:33:42AM -0400, Stefan Berger wrote:
On 04/21/2011 07:43 AM, Daniel P. Berrange wrote:
On Thu, Apr 21, 2011 at 07:37:30AM -0400, Stefan Berger wrote:
and simply doesn't start the VM. After this function is called all
s
Support changes of disks by MODIFY_CONFIG for qemu.
This patch includes patches for qemu's disk to support
virDomainAt(De)tachDeviceFlags with VIR_DOMAIN_DEVICE_MODIFY_CONFIG.
Other devices can be added inrecemtaly.
Signed-off-by: KAMEZAWA Hiroyuki
Changelog: v11->v12
- rebased. (qemud... ->
Support update of disks by MODIFY_CONFIG
This patch includes changes for qemu's disk to support
virDomainUpdateDeviceFlags() with VIR_DOMAIN_DEVICE_MODIFY_CONFIG.
This patch adds support for CDROM/foppy disk types.
Signed-off-by: KAMEZAWA Hiroyuki
Changelog: v11->v12
- rebased.(qemud->qemu)
Rebased ont the latest git tree, which makes this work easier.
This series adds support for attach/detach/update disks of domain config.
==
This patch adds functions for modify domain's persistent definition.
To do error recovery in easy way, we use a copy of vmdef and update it.
The whole sequen
> -Original Message-
> From: Stefan Berger [mailto:stef...@linux.vnet.ibm.com]
> Sent: Thursday, April 21, 2011 6:34 AM
> To: Daniel P. Berrange
> Cc: Christian Benvenuti (benve); ebl...@redhat.com; la...@laine.org;
> chr...@redhat.com; libvir-list@redhat.com; David Wang (dwang2); Roopa
> P
On Thu, 21 Apr 2011 14:27:23 -0600
Eric Blake wrote:
> On 04/21/2011 01:23 AM, KAMEZAWA Hiroyuki wrote:
> > clean up At(De)tachDeviceFlags() for consolidation.
> >
> > qemudDomainAttachDeviceFlags()/qemudDomainDetachFlags()/
> > qemudDomainUpdateDeviceFlags() has similar logics and copied codes.
On Thu, 21 Apr 2011 13:19:29 -0600
Eric Blake wrote:
> On 04/21/2011 01:22 AM, KAMEZAWA Hiroyuki wrote:
> >
> > Centralize device modification in the more flexible APIs, to allow future
> > honoring of additional flags. Explicitly reject the
> > VIR_DOMAIN_DEVICE_MODIFY_FORCE flag on attach/de
On Thu, 21 Apr 2011 12:54:14 -0600
Eric Blake wrote:
> I'm assuming you meant for this to go to libvir-list rather than
> libvirt-users; all my subsequent mails will swap the list reply.
>
Ouchthanks.
-Kame
> On 04/21/2011 01:19 AM, KAMEZAWA Hiroyuki wrote:
> >
> > Here is v11. Fixed com
On 04/21/2011 10:32 AM, Daniel P. Berrange wrote:
> * src/remote/remote_protocol.x: Define wire protocol for migration
> protocol v3
> * daemon/remote.c: Server side dispatch
> * src/remote/remote_driver.c: Client side serialization
> * src/remote/remote_protocol.c, src/remote/remote_protocol.h,
On 04/21/2011 10:32 AM, Daniel P. Berrange wrote:
> Migration just seems togo from bad to worse. We already had to
s/togo/to go/
>
> This patch attempts to introduce a version 3 that uses the
> improved 5 step sequence
>
> * Src: Begin
> - Generate XML to pass to dst
> - G
* .gnulib: Update to latest for passfd fixes.
* bootstrap.conf (gnulib_modules): Add passfd.
* src/util/util.c (virFileOpenAs): Simplify.
---
Now that the mingw side of passfd is fixed in gnulib, I can
resubmit this patch.
v2: update .gnulib, no other changes
.gnulib |2 +-
bootstra
On 04/21/2011 01:23 AM, KAMEZAWA Hiroyuki wrote:
> clean up At(De)tachDeviceFlags() for consolidation.
>
> qemudDomainAttachDeviceFlags()/qemudDomainDetachFlags()/
> qemudDomainUpdateDeviceFlags() has similar logics and copied codes.
>
> This patch series tries to unify them to use shared code wh
On 04/21/2011 01:22 AM, KAMEZAWA Hiroyuki wrote:
>
> Centralize device modification in the more flexible APIs, to allow future
> honoring of additional flags. Explicitly reject the
> VIR_DOMAIN_DEVICE_MODIFY_FORCE flag on attach/detach.
>
> Based on Eric Blake's work.
>
> From: Eric Blake
> S
I'm assuming you meant for this to go to libvir-list rather than
libvirt-users; all my subsequent mails will swap the list reply.
On 04/21/2011 01:19 AM, KAMEZAWA Hiroyuki wrote:
>
> Here is v11. Fixed comments/bugs and updated against the latest libvirt.git.
>
> Changes v10->v11:
> - fixed co
> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Thursday, April 21, 2011 5:02 AM
> To: Christian Benvenuti (benve)
> Cc: ebl...@redhat.com; stef...@linux.vnet.ibm.com; la...@laine.org;
> chr...@redhat.com; libvir-list@redhat.com; David Wang (dwang2); Roo
> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Thursday, April 21, 2011 4:44 AM
> To: Stefan Berger
> Cc: Christian Benvenuti (benve); ebl...@redhat.com; la...@laine.org;
> chr...@redhat.com; libvir-list@redhat.com; David Wang (dwang2); Roopa
> Prabhu (
On 04/21/2011 10:32 AM, Daniel P. Berrange wrote:
> assert() is forbidden in libvirt code, and these two cases would
> in fact never execute due to earlier error checks.
>
> * src/libvirt.c: Remove assert() usage
> ---
> src/libvirt.c |3 ---
> 1 files changed, 0 insertions(+), 3 deletions(-)
Cancelling the QEMU migration may cause QEMU to flush pending
data on the migration socket. This may in turn block QEMU if
nothing reads from the other end of the socket. Closing the
socket before cancelling QEMU migration avoids this possible
deadlock.
* src/qemu/qemu_migration.c: Close sockets b
The 'nbytes' variable was not re-initialized to the
buffer size on each iteration of the tunnelled migration
loop. While saferead() will ensure a full read, except
on EOF, it is clearer to use the real buffer size
* src/qemu/qemu_migration.c: Always read full buffer of data
---
src/qemu/qemu_migr
Rewrite the doTunnelSendAll method so that it will process
job signals, and periodically ask QEMU for updated job status
* src/qemu/qemu_migration.c: Honour job signals/status during
tunnelled migration
---
src/qemu/qemu_migration.c | 72 +---
1 files c
The qemuMigrationWaitForCompletion method contains a loop which
repeatedly queries QEMU to check migration progress, and also
processes job signals (pause, setspeed, setbandwidth, cancel).
The tunnelled migration loop does not currently support this
functionality, but should. Refactor the code to
When failing to marshall an XDR message, include the
full program/version/status/proc/type info, to allow
easier debugging & diagnosis of the problem.
* src/remote/remote_driver.c: Improve error when marshalling
fails
---
src/remote/remote_driver.c | 12 +---
1 files changed, 9 insert
The v2 migration protocol was accidentally missing out the
finish step, when prepare succeeded, but returned an invalid
URI
* src/libvirt.c: Teardown VM if prepare returns invalid URI
---
src/libvirt.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/li
Merge the doNonTunnelMigrate2 and doTunnelMigrate2 methods
into one doPeer2PeerMigrate2 method, since they are substantially
the same. With the introduction of v3 migration, this will be
even more important, to avoid massive code duplication.
* src/qemu/qemu_migration.c: Merge tunnel & non-tunnel
Extend the QEMU migration cookie structure to allow information
about the destination host graphics setup to be passed by to
the source host. This will enable seamless migration of any
connected graphics clients
* src/qemu/qemu_migration.c: Add graphics info to migration
cookies
* daemon/libvirt
* src/remote/remote_protocol.x: Define wire protocol for migration
protocol v3
* daemon/remote.c: Server side dispatch
* src/remote/remote_driver.c: Client side serialization
* src/remote/remote_protocol.c, src/remote/remote_protocol.h,
daemon/remote_dispatch_args.h, daemon/remote_dispatch_prot
Use the graphics information from the QEMU migration cookie to
issue a 'client_migrate_info' monitor command to QEMU. This causes
the SPICE client to automatically reconnect to the target host
when migration completes
* src/qemu/qemu_migration.c: Set data for SPICE client relocation
before start
The migration protocol has support for a 'cookie' parameter which
is an opaque array of bytes as far as libvirt is concerned. Drivers
may use this for passing around arbitrary extra data they might
need during migration. The QEMU driver needs todo a few things:
- Pass hostname/uuid to allow stric
To facilitate the introduction of the v3 migration protocol,
the doTunnelMigrate method is refactored into two pieces. One
piece is intended to mirror the flow of virDomainMigrateVersion2,
while the other is the helper for setting up sockets and processing
the data.
Previously socket setup would b
virStreamSend already sets an error message, so don't
overwrite it
* src/qemu/qemu_migration.c: Remove bogus error report
---
src/qemu/qemu_migration.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index 39b3749..47
Implement the v3 migration protocol, which has two extra
steps, 'begin' on the source host and 'confirm' on the
source host. All other methods also gain both input and
output cookies to allow bi-directional data passing at
all stages.
The QEMU peer2peer migration method gains another impl
to provi
This is an major update to
http://www.redhat.com/archives/libvir-list/2011-February/msg00257.html
In this update
- Bug fixes from previous review
- Remove assert() usage
- Introduce SPICE graphics relocation
- Refactoring of peer2peer & tunnelled migration code
- Support for v3 migration
assert() is forbidden in libvirt code, and these two cases would
in fact never execute due to earlier error checks.
* src/libvirt.c: Remove assert() usage
---
src/libvirt.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/src/libvirt.c b/src/libvirt.c
index 10c3cdf..d369
Migration just seems togo from bad to worse. We already had to
introduce a second migration protocol when adding the QEMU driver,
since the one from Xen was insufficiently flexible to cope with
passing the data the QEMU driver required.
It turns out that this protocol still has some flaws that we
On 04/21/2011 09:27 AM, Michal Privoznik wrote:
> Up to now we missed parser for cpuinfo on x390(x) machines. Those machines
> have only 1 thread, core, socket. What is missing is information about
> CPU frequency.
> ---
> src/nodeinfo.c | 29 +++--
> 1 files changed, 27
On 04/21/2011 09:05 AM, Daniel P. Berrange wrote:
> The two ends of the pipe used for feeding QEMU tunnelled
> migration data were interchanged, so QEMU got given the
> "write" end instead of the "read" end.
>
> The qemuMigrationPrepareTunnel method was also immediately
> closing the "write" end o
Up to now we missed parser for cpuinfo on x390(x) machines. Those machines
have only 1 thread, core, socket. What is missing is information about
CPU frequency.
---
src/nodeinfo.c | 29 +++--
1 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/src/nodeinfo.c b
The two ends of the pipe used for feeding QEMU tunnelled
migration data were interchanged, so QEMU got given the
"write" end instead of the "read" end.
The qemuMigrationPrepareTunnel method was also immediately
closing the "write" end of the pipe, so the stream failed
to actually write anything.
ARRAY_CARDINALITY is typed as size_t, not long; this matters on 32-bit
platforms:
hashtest.c: In function 'testHashRemoveForEach':
hashtest.c:114: error: format '%lu' expects type 'long unsigned int', but
argument 4 has type 'unsigned int' [-Wformat]
* tests/hashtest.c (testHashRemoveForEach): U
On Thu, Apr 21, 2011 at 09:33:42AM -0400, Stefan Berger wrote:
> On 04/21/2011 07:43 AM, Daniel P. Berrange wrote:
> >On Thu, Apr 21, 2011 at 07:37:30AM -0400, Stefan Berger wrote:
> >>
> >>and simply doesn't start the VM. After this function is called all
> >>sockets are closed and the communicati
On 04/21/2011 07:43 AM, Daniel P. Berrange wrote:
On Thu, Apr 21, 2011 at 07:37:30AM -0400, Stefan Berger wrote:
and simply doesn't start the VM. After this function is called all
sockets are closed and the communication with the source host is
cut. I don't think it allows for fall-back at this
On Thu, Apr 21, 2011 at 06:40:58 -0600, Eric Blake wrote:
> On 04/21/2011 06:21 AM, Jiri Denemark wrote:
> > Remove the artificial minimum of 4096 KB for guest memory. It's drivers'
> > job to set the limit if needed.
> > ---
> > src/libvirt.c |6 +++---
> > 1 files changed, 3 insertions(+), 3
On Wed, Apr 20, 2011 at 07:06:33AM -0600, Eric Blake wrote:
> On 04/20/2011 05:13 AM, Jason Krieg wrote:
> > that was my first guess but it does not work the remote monitor socket
> > does not show up
> >
> > libvirt is running as root so it should not be a permission problem
> >
> > qemuMonitorO
On 04/21/2011 06:21 AM, Jiri Denemark wrote:
> Remove the artificial minimum of 4096 KB for guest memory. It's drivers'
> job to set the limit if needed.
> ---
> src/libvirt.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
ACK.
--
Eric Blake ebl...@redhat.com+1-801-349-
Remove the artificial minimum of 4096 KB for guest memory. It's drivers'
job to set the limit if needed.
---
src/libvirt.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/libvirt.c b/src/libvirt.c
index 9e6784b..10c3cdf 100644
--- a/src/libvirt.c
+++ b/src/libvirt
On Wed, Apr 20, 2011 at 04:28:12PM -0500, Christian Benvenuti (benve) wrote:
> Daniel,
> I looked at the patch-set you sent out on the 2/9/11
>
> [libvirt] [PATCH 0/6] Introduce a new migration protocol
> to QEMU driver
> http://www.mail-archive.com/libvir-list@redhat
On Wed, Apr 20, 2011 at 10:38:40PM -0500, Christian Benvenuti (benve) wrote:
> > On 04/20/2011 05:28 PM, Christian Benvenuti (benve) wrote:
> > > Daniel,
> > >I looked at the patch-set you sent out on the 2/9/11
> > >
> > >[libvirt] [PATCH 0/6] Introduce a new migration protocol
> > >
On Thu, Apr 21, 2011 at 07:37:30AM -0400, Stefan Berger wrote:
> On 04/20/2011 11:38 PM, Christian Benvenuti (benve) wrote:
> >>On 04/20/2011 05:28 PM, Christian Benvenuti (benve) wrote:
> >>>Daniel,
> >>>I looked at the patch-set you sent out on the 2/9/11
> >>>
> >>>[libvirt] [PATCH 0/6]
On 04/20/2011 11:38 PM, Christian Benvenuti (benve) wrote:
On 04/20/2011 05:28 PM, Christian Benvenuti (benve) wrote:
Daniel,
I looked at the patch-set you sent out on the 2/9/11
[libvirt] [PATCH 0/6] Introduce a new migration protocol
to QEMU driver
http:/
> I assume that 2 associations with the same profile are possible with
> 802.1Qbg and Qbh.
According to the IEEE standard, it is possible to have a transient
period during which you have two associations and therefore
standard-compliant implementations are supposed to be able to handle
it.
/Chris
> On 04/20/2011 05:28 PM, Christian Benvenuti (benve) wrote:
> > Daniel,
> >I looked at the patch-set you sent out on the 2/9/11
> >
> >[libvirt] [PATCH 0/6] Introduce a new migration protocol
> > to QEMU driver
> >http://www.mail-archive.com/libvir-list@redhat.
51 matches
Mail list logo
