* status of non-live migration of HVM with libvirt
@ 2019-01-04 15:57 Olaf Hering
2019-01-04 16:48 ` Olaf Hering
0 siblings, 1 reply; 9+ messages in thread
From: Olaf Hering @ 2019-01-04 15:57 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 426 bytes --]
With 'xl migrate' the migration is always live, while 'virsh migrate' will do an offline migration unless '--live' is used. Such non-live migration will break with HVM because the sending side does not seem to unlock the qcow2 image.
I wonder if its worth keeping (and fixing) the concept of an "offline migration", or if libvirt should be changed to either require '--live' or silently always do live migrations.
Olaf
[-- Attachment #1.2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: status of non-live migration of HVM with libvirt
2019-01-04 15:57 status of non-live migration of HVM with libvirt Olaf Hering
@ 2019-01-04 16:48 ` Olaf Hering
2019-01-07 10:07 ` Olaf Hering
0 siblings, 1 reply; 9+ messages in thread
From: Olaf Hering @ 2019-01-04 16:48 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 820 bytes --]
Am Fri, 4 Jan 2019 16:57:55 +0100
schrieb Olaf Hering <olaf@aepfle.de>:
> worth keeping (and fixing) the concept of an "offline migration"
And regarding the fix, it looks like qmp_xen_save_devices_state does not need the concept of "live". Just shutdown the blockdevices and be done with it?
+++ b/migration/savevm.c
@@ -2293,7 +2293,7 @@ void qmp_xen_save_devices_state(const char *filename, bool has_live, bool live,
* So call bdrv_inactivate_all (release locks) here to let the other
* side of the migration take controle of the images.
*/
- if (live && !saved_vm_running) {
+ if (!saved_vm_running) {
ret = bdrv_inactivate_all();
if (ret) {
error_setg(errp, "%s: bdrv_inactivate_all() failed (%d)",
Olaf
[-- Attachment #1.2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: status of non-live migration of HVM with libvirt
2019-01-04 16:48 ` Olaf Hering
@ 2019-01-07 10:07 ` Olaf Hering
2019-04-09 16:06 ` [Xen-devel] " Olaf Hering
2019-04-10 16:25 ` [Xen-devel] " Anthony PERARD
0 siblings, 2 replies; 9+ messages in thread
From: Olaf Hering @ 2019-01-07 10:07 UTC (permalink / raw)
To: xen-devel, Anthony PERARD
[-- Attachment #1.1: Type: text/plain, Size: 811 bytes --]
Am Fri, 4 Jan 2019 17:48:31 +0100
schrieb Olaf Hering <olaf@aepfle.de>:
> Am Fri, 4 Jan 2019 16:57:55 +0100
> schrieb Olaf Hering <olaf@aepfle.de>:
>
> > worth keeping (and fixing) the concept of an "offline migration"
>
> And regarding the fix, it looks like qmp_xen_save_devices_state does not need the concept of "live". Just shutdown the blockdevices and be done with it?
Anthony, it looks like 5d6c599fe1 ("migration, xen: Fix block image lock issue on live migration") went too far. Why does stopping the disks at the very end of the save/migrate process depend on "live"? During a migration the disks have to be released either way. During "xl save" the domU may continue to run, if '-c' was specified.
It seems the 'live' parameter for xen-save-devices-state is not needed.
Olaf
[-- Attachment #1.2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: status of non-live migration of HVM with libvirt
@ 2019-04-09 16:06 ` Olaf Hering
0 siblings, 0 replies; 9+ messages in thread
From: Olaf Hering @ 2019-04-09 16:06 UTC (permalink / raw)
To: xen-devel, Anthony PERARD
[-- Attachment #1.1: Type: text/plain, Size: 1010 bytes --]
Anthony,
looks like this fix missed qemu-4.0.
What is your opinion on this fix? I think there was zero reply...
Olaf
On Mon, Jan 07, Olaf Hering wrote:
> Am Fri, 4 Jan 2019 17:48:31 +0100
> schrieb Olaf Hering <olaf@aepfle.de>:
>
> > Am Fri, 4 Jan 2019 16:57:55 +0100
> > schrieb Olaf Hering <olaf@aepfle.de>:
> >
> > > worth keeping (and fixing) the concept of an "offline migration"
> >
> > And regarding the fix, it looks like qmp_xen_save_devices_state does not need the concept of "live". Just shutdown the blockdevices and be done with it?
>
> Anthony, it looks like 5d6c599fe1 ("migration, xen: Fix block image lock issue on live migration") went too far. Why does stopping the disks at the very end of the save/migrate process depend on "live"? During a migration the disks have to be released either way. During "xl save" the domU may continue to run, if '-c' was specified.
>
> It seems the 'live' parameter for xen-save-devices-state is not needed.
>
> Olaf
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [Xen-devel] status of non-live migration of HVM with libvirt
@ 2019-04-09 16:06 ` Olaf Hering
0 siblings, 0 replies; 9+ messages in thread
From: Olaf Hering @ 2019-04-09 16:06 UTC (permalink / raw)
To: xen-devel, Anthony PERARD
[-- Attachment #1.1: Type: text/plain, Size: 1010 bytes --]
Anthony,
looks like this fix missed qemu-4.0.
What is your opinion on this fix? I think there was zero reply...
Olaf
On Mon, Jan 07, Olaf Hering wrote:
> Am Fri, 4 Jan 2019 17:48:31 +0100
> schrieb Olaf Hering <olaf@aepfle.de>:
>
> > Am Fri, 4 Jan 2019 16:57:55 +0100
> > schrieb Olaf Hering <olaf@aepfle.de>:
> >
> > > worth keeping (and fixing) the concept of an "offline migration"
> >
> > And regarding the fix, it looks like qmp_xen_save_devices_state does not need the concept of "live". Just shutdown the blockdevices and be done with it?
>
> Anthony, it looks like 5d6c599fe1 ("migration, xen: Fix block image lock issue on live migration") went too far. Why does stopping the disks at the very end of the save/migrate process depend on "live"? During a migration the disks have to be released either way. During "xl save" the domU may continue to run, if '-c' was specified.
>
> It seems the 'live' parameter for xen-save-devices-state is not needed.
>
> Olaf
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: status of non-live migration of HVM with libvirt
@ 2019-04-10 16:25 ` Anthony PERARD
0 siblings, 0 replies; 9+ messages in thread
From: Anthony PERARD @ 2019-04-10 16:25 UTC (permalink / raw)
To: Olaf Hering; +Cc: xen-devel
On Mon, Jan 07, 2019 at 11:07:43AM +0100, Olaf Hering wrote:
> Am Fri, 4 Jan 2019 17:48:31 +0100
> schrieb Olaf Hering <olaf@aepfle.de>:
>
> > Am Fri, 4 Jan 2019 16:57:55 +0100
> > schrieb Olaf Hering <olaf@aepfle.de>:
> >
> > > worth keeping (and fixing) the concept of an "offline migration"
> >
> > And regarding the fix, it looks like qmp_xen_save_devices_state does not need the concept of "live". Just shutdown the blockdevices and be done with it?
>
> Anthony, it looks like 5d6c599fe1 ("migration, xen: Fix block image
> lock issue on live migration") went too far. Why does stopping the
> disks at the very end of the save/migrate process depend on "live"?
Because "Snapshots don't need to inactivate images", see:
https://lists.xenproject.org/archives/html/xen-devel/2017-10/msg02782.html
I had to add the `live' parameter to fix the lock issue.
> During a migration the disks have to be released either way. During "xl save" the domU may continue to run, if '-c' was specified.
xl save -c is a snapshot, right? There isn't a second QEMU process that
is going to read/write the same disk.
> It seems the 'live' parameter for xen-save-devices-state is not needed.
>
> Olaf
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [Xen-devel] status of non-live migration of HVM with libvirt
@ 2019-04-10 16:25 ` Anthony PERARD
0 siblings, 0 replies; 9+ messages in thread
From: Anthony PERARD @ 2019-04-10 16:25 UTC (permalink / raw)
To: Olaf Hering; +Cc: xen-devel
On Mon, Jan 07, 2019 at 11:07:43AM +0100, Olaf Hering wrote:
> Am Fri, 4 Jan 2019 17:48:31 +0100
> schrieb Olaf Hering <olaf@aepfle.de>:
>
> > Am Fri, 4 Jan 2019 16:57:55 +0100
> > schrieb Olaf Hering <olaf@aepfle.de>:
> >
> > > worth keeping (and fixing) the concept of an "offline migration"
> >
> > And regarding the fix, it looks like qmp_xen_save_devices_state does not need the concept of "live". Just shutdown the blockdevices and be done with it?
>
> Anthony, it looks like 5d6c599fe1 ("migration, xen: Fix block image
> lock issue on live migration") went too far. Why does stopping the
> disks at the very end of the save/migrate process depend on "live"?
Because "Snapshots don't need to inactivate images", see:
https://lists.xenproject.org/archives/html/xen-devel/2017-10/msg02782.html
I had to add the `live' parameter to fix the lock issue.
> During a migration the disks have to be released either way. During "xl save" the domU may continue to run, if '-c' was specified.
xl save -c is a snapshot, right? There isn't a second QEMU process that
is going to read/write the same disk.
> It seems the 'live' parameter for xen-save-devices-state is not needed.
>
> Olaf
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: status of non-live migration of HVM with libvirt
@ 2019-04-10 18:42 ` Olaf Hering
0 siblings, 0 replies; 9+ messages in thread
From: Olaf Hering @ 2019-04-10 18:42 UTC (permalink / raw)
To: Anthony PERARD; +Cc: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 344 bytes --]
Am Wed, 10 Apr 2019 17:25:04 +0100
schrieb Anthony PERARD <anthony.perard@citrix.com>:
> Because "Snapshots don't need to inactivate images", see:
> https://lists.xenproject.org/archives/html/xen-devel/2017-10/msg02782.html
>
> I had to add the `live' parameter to fix the lock issue.
Thanks, I will double check this part.
Olaf
[-- Attachment #1.2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-04-10 18:42 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-01-04 15:57 status of non-live migration of HVM with libvirt Olaf Hering
2019-01-04 16:48 ` Olaf Hering
2019-01-07 10:07 ` Olaf Hering
2019-04-09 16:06 ` Olaf Hering
2019-04-09 16:06 ` [Xen-devel] " Olaf Hering
2019-04-10 16:25 ` Anthony PERARD
2019-04-10 16:25 ` [Xen-devel] " Anthony PERARD
2019-04-10 18:42 ` Olaf Hering
2019-04-10 18:42 ` [Xen-devel] " Olaf Hering
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.