Re: [libvirt] [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
On 7 Aug 2014, at 20:26, Serge E. Hallyn se...@hallyn.com wrote: A-ha, acpi wasn't a problem. I actually had a general migration problem even when coming from other utopic hosts. With that fixed, I've got successful migration from qemu-kvm 1.0 in precise to a utopic host. That's good news. You might try the 2 patches here: https://github.com/abligh/qemu/tree/livemigrate-qemu-kvm-to-qemu-2.0.0-test-2 and see if you can get Precise to Trusty migration working (as well as Precise to Utopic) -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
Quoting Alex Bligh (a...@alex.org.uk): On 7 Aug 2014, at 20:26, Serge E. Hallyn se...@hallyn.com wrote: A-ha, acpi wasn't a problem. I actually had a general migration problem even when coming from other utopic hosts. With that fixed, I've got successful migration from qemu-kvm 1.0 in precise to a utopic host. That's good news. You might try the 2 patches here: https://github.com/abligh/qemu/tree/livemigrate-qemu-kvm-to-qemu-2.0.0-test-2 and see if you can get Precise to Trusty migration working (as well as Precise to Utopic) These have built at https://launchpad.net/~serge-hallyn/+archive/ubuntu/qemu-p-migration -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
Serge, On 7 Aug 2014, at 03:50, Serge Hallyn serge.hal...@ubuntu.com wrote: This worked for me when migrating by hand. I'm trying to make it work through libvirt, using the following patch. (So whether to have pc-1.0 be treated as qemu's or qemu-kvm's pc-1.0 is specifed using a boolean in /etc/libvirt/qemu.conf) Qemu starts with decent looking args, but for some reason the the migration is failing - still looking through the logfile to figure out why. Are you using exactly the same arguments by hand and with libvirt? Also, on reflection, given one of the changes between 1.0 and 2.0 is ACPI, I should probably have done some testing with an ACPI enabled image, rather than just cirros (which not ACPI enabled); any chance this is ACPI related? Now sadly my tests are being further slowed down by qcow corruption on my host, but I don't think that was the cause of my failure. Whilst getting the patch right in the first place I tend to cp from a known good image. Obviously once it works, qcow2 corruption should not happen. But failed migrations (with or without my patch) do appear to cause this relatively frequently. -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
Quoting Alex Bligh (a...@alex.org.uk): Serge, On 7 Aug 2014, at 03:50, Serge Hallyn serge.hal...@ubuntu.com wrote: This worked for me when migrating by hand. I'm trying to make it work through libvirt, using the following patch. (So whether to have pc-1.0 be treated as qemu's or qemu-kvm's pc-1.0 is specifed using a boolean in /etc/libvirt/qemu.conf) Qemu starts with decent looking args, but for some reason the the migration is failing - still looking through the logfile to figure out why. Are you using exactly the same arguments by hand and with libvirt? Also, on reflection, given one of the changes between 1.0 and 2.0 is ACPI, I should probably have done some testing with an ACPI enabled image, rather than just cirros (which not ACPI enabled); any chance this is ACPI related? Turning off acpi (well, commenting it out in the xml, which I'm assuming dtrt) doesn't help: === LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -name cirros -S -global virtio-net-pci.romfile=pxe-virtio.rom.12.04 -machine pc-1.0-qemu-kvm,accel=kvm,usb=off -m 512 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 2542c328-6842-33ef-d30e-866c3f3189a8 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/cirros.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -no-acpi -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/cirros.img,if=none,id=drive-ide0-0-0,format=raw -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=26,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:be:d8:99,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:0 -device cirrus-vga,id=! video0,bus=pci.0,addr=0x2 -device AC97,id=sound0,bus=pci.0,addr=0x4 -incoming fd:23 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on 2014-08-07 12:51:02.400+: 1539: debug : virFileClose:99 : Closed fd 25 2014-08-07 12:51:02.401+: 1539: debug : virFileClose:99 : Closed fd 31 2014-08-07 12:51:02.401+: 1539: debug : virFileClose:99 : Closed fd 3 2014-08-07 12:51:02.401+: 1540: debug : virExec:616 : Run hook 0x7f25cb17bca0 0x7f25d3aedf20 2014-08-07 12:51:02.401+: 1540: debug : qemuProcessHook:2719 : Obtaining domain lock 2014-08-07 12:51:02.401+: 1540: debug : virDomainLockProcessStart:175 : plugin=0x7f25c4170290 dom=0x7f25c4186510 paused=1 fd=0x7f25d3aedb44 2014-08-07 12:51:02.401+: 1540: debug : virDomainLockManagerNew:133 : plugin=0x7f25c4170290 dom=0x7f25c4186510 withResources=1 2014-08-07 12:51:02.401+: 1540: debug : virLockManagerPluginGetDriver:281 : plugin=0x7f25c4170290 2014-08-07 12:51:02.401+: 1540: debug : virLockManagerNew:305 : driver=0x7f25da723580 type=0 nparams=5 params=0x7f25d3aeda30 flags=0 2014-08-07 12:51:02.401+: 1540: debug : virLockManagerLogParams:98 : key=uuid type=uuid value=2542c328-6842-33ef-d30e-866c3f3189a8 2014-08-07 12:51:02.401+: 1540: debug : virLockManagerLogParams:91 : key=name type=string value=cirros 2014-08-07 12:51:02.401+: 1540: debug : virLockManagerLogParams:79 : key=id type=uint value=2 2014-08-07 12:51:02.401+: 1540: debug : virLockManagerLogParams:79 : key=pid type=uint value=1540 2014-08-07 12:51:02.401+: 1540: debug : virLockManagerLogParams:94 : key=uri type=cstring value=qemu:///system 2014-08-07 12:51:02.401+: 1540: debug : virDomainLockManagerNew:145 : Adding leases 2014-08-07 12:51:02.401+: 1540: debug : virDomainLockManagerNew:150 : Adding disks 2014-08-07 12:51:02.401+: 1540: debug : virDomainLockManagerAddDisk:91 : Add disk /var/lib/libvirt/images/cirros.img 2014-08-07 12:51:02.401+: 1540: debug : virLockManagerAddResource:332 : lock=0x7f25c417b080 type=0 name=/var/lib/libvirt/images/cirros.img nparams=0 params=(nil) flags=0 2014-08-07 12:51:02.401+: 1540: debug : virLockManagerAcquire:350 : lock=0x7f25c417b080 state='null' flags=3 action=0 fd=0x7f25d3aedb44 2014-08-07 12:51:02.401+: 1540: debug : virLockManagerFree:387 : lock=0x7f25c417b080 2014-08-07 12:51:02.401+: 1540: debug : virObjectUnref:259 : OBJECT_UNREF: obj=0x7f25c415e620 2014-08-07 12:51:02.401+: 1540: debug : qemuProcessHook:2746 : Hook complete ret=0 2014-08-07 12:51:02.401+: 1540: debug : virExec:618 : Done hook 0 2014-08-07 12:51:02.401+: 1540: debug : virExec:638 : Setting child AppArmor profile to libvirt-2542c328-6842-33ef-d30e-866c3f3189a8 2014-08-07 12:51:02.402+: 1540: debug : virExec:655 : Setting child uid:gid to 107:113 with caps 0 2014-08-07 12:51:02.402+: 1540: debug : virCommandHandshakeChild:358 : Notifying parent for handshake start on 28 2014-08-07 12:51:02.402+: 1540: debug
Re: [libvirt] [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
Quoting Alex Bligh (a...@alex.org.uk): Serge, On 7 Aug 2014, at 03:50, Serge Hallyn serge.hal...@ubuntu.com wrote: This worked for me when migrating by hand. I'm trying to make it work through libvirt, using the following patch. (So whether to have pc-1.0 be treated as qemu's or qemu-kvm's pc-1.0 is specifed using a boolean in /etc/libvirt/qemu.conf) Qemu starts with decent looking args, but for some reason the the migration is failing - still looking through the logfile to figure out why. Are you using exactly the same arguments by hand and with libvirt? Also, on reflection, given one of the changes between 1.0 and 2.0 is ACPI, I should probably have done some testing with an ACPI enabled image, rather than just cirros (which not ACPI enabled); any chance this is ACPI related? A-ha, acpi wasn't a problem. I actually had a general migration problem even when coming from other utopic hosts. With that fixed, I've got successful migration from qemu-kvm 1.0 in precise to a utopic host. -serge -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
On 4 Aug 2014, at 14:31, Michael S. Tsirkin m...@redhat.com wrote: On Fri, Aug 01, 2014 at 08:12:11PM +0100, Alex Bligh wrote: This patch series adds inbound migrate capability from qemu-kvm version 1.0. The main ideas are those set out in Cole Robinson's patch here: http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0001-Fix-migration-from-qemu-kvm.patch?h=f20 however, rather than patching statically (and breaking inbound migration on existing machine types), I have added a new machine type (pc-1.0-qemu-kvm) without affecting any other machine types. The existing pc-1.0 machine type is renamed to pc-1.0-qemu-git, with pc-1.0 becoming an alias for one or another, as selected by a configure option (defaulting to pc-1.0-qemu-git, IE no change). This requires 'hot patching' the VMStateDescription in a couple of places, which in turn is less than obvious as there may be (indeed are for i8259) derived classes. Whilst pretty nausea-inducing, this approach has the benefit of being entirely self-contained. Ow come on. Just add a flag and select the appropriate format based on it, using field_exists. I don't think it is that simple. All those things are initialised well before the command line is parsed. Unless I'm missing what you are saying? -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
On Mon, Aug 04, 2014 at 02:51:01PM +0100, Alex Bligh wrote: On 4 Aug 2014, at 14:31, Michael S. Tsirkin m...@redhat.com wrote: On Fri, Aug 01, 2014 at 08:12:11PM +0100, Alex Bligh wrote: This patch series adds inbound migrate capability from qemu-kvm version 1.0. The main ideas are those set out in Cole Robinson's patch here: http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0001-Fix-migration-from-qemu-kvm.patch?h=f20 however, rather than patching statically (and breaking inbound migration on existing machine types), I have added a new machine type (pc-1.0-qemu-kvm) without affecting any other machine types. The existing pc-1.0 machine type is renamed to pc-1.0-qemu-git, with pc-1.0 becoming an alias for one or another, as selected by a configure option (defaulting to pc-1.0-qemu-git, IE no change). This requires 'hot patching' the VMStateDescription in a couple of places, which in turn is less than obvious as there may be (indeed are for i8259) derived classes. Whilst pretty nausea-inducing, this approach has the benefit of being entirely self-contained. Ow come on. Just add a flag and select the appropriate format based on it, using field_exists. I don't think it is that simple. All those things are initialised well before the command line is parsed. You initialize both and select the correct one at migration time. Unless I'm missing what you are saying? I think you are: check how vmstate_test_use_acpi_pci_hotplug and vmstate_test_no_use_acpi_pci_hotplug are used in vmstate_acpi. -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
Michael, On 4 Aug 2014, at 15:26, Michael S. Tsirkin m...@redhat.com wrote: Unless I'm missing what you are saying? I think you are: check how vmstate_test_use_acpi_pci_hotplug and vmstate_test_no_use_acpi_pci_hotplug are used in vmstate_acpi. I /think/ you are talking about using the VMSTATE_FOO_TEST macros. These are capable of modifying fields within the VMStateDescription of the relevant object. However, the PIIX4 change modifies the minimum_version_id (outside fields); I don't quite see how that would work. Can you help here? The i8254 change modifies a field which is marked with a minimum version to be a field with no versioning; I guess the route there would be a test function that (somehow) accesses the version of the inbound migration inside it, does the comparison manually, and returns 1 if EITHER the inbound version =3 or the compatibility thing is set. Is that what you meant? I'm rather new to this so you may have to lead me a little - apologies. I was trying to produce code which would be 'obviously correct' in the sense of not breaking the existing pc-1.0 migrations; if playing around with the existing vmstate fields is permissible then clearly I have a few more degrees of freedom. I did try modifying the objects live after the command line has been parsed; this doesn't work because the QOM inheritance memcpy's the structs for classes derived from i8254 etc. -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
On Mon, Aug 04, 2014 at 05:11:11PM +0100, Alex Bligh wrote: Michael, On 4 Aug 2014, at 15:26, Michael S. Tsirkin m...@redhat.com wrote: Unless I'm missing what you are saying? I think you are: check how vmstate_test_use_acpi_pci_hotplug and vmstate_test_no_use_acpi_pci_hotplug are used in vmstate_acpi. I /think/ you are talking about using the VMSTATE_FOO_TEST macros. These use field_exists internally. These are capable of modifying fields within the VMStateDescription of the relevant object. However, the PIIX4 change modifies the minimum_version_id (outside fields); I don't quite see how that would work. Can you help here? If you want to support lower version IDs, you can just decrease minimum_version_id. field_exists gets the version ID so you can parse different fields depending on the version. The i8254 change modifies a field which is marked with a minimum version to be a field with no versioning; I guess the route there would be a test function that (somehow) accesses the version of the inbound migration inside it, Yes, field_exists gets the version value so no problem here. does the comparison manually, and returns 1 if EITHER the inbound version =3 or the compatibility thing is set. Is that what you meant? I think so, yes. I'm rather new to this so you may have to lead me a little - apologies. I was trying to produce code which would be 'obviously correct' in the sense of not breaking the existing pc-1.0 migrations; if playing around with the existing vmstate fields is permissible then clearly I have a few more degrees of freedom. Yes I think is should be simple but not to the exclusion of maintainability. I did try modifying the objects live after the command line has been parsed; this doesn't work because the QOM inheritance memcpy's the structs for classes derived from i8254 etc. Right, just add a new flag for this thing. -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
Michael,
On 4 Aug 2014, at 17:22, Michael S. Tsirkin m...@redhat.com wrote:
These are capable of modifying fields within the
VMStateDescription of the relevant object.
However, the PIIX4 change modifies the minimum_version_id
(outside fields); I don't quite see how that would work.
Can you help here?
If you want to support lower version IDs,
you can just decrease minimum_version_id.
field_exists gets the version ID so you can
parse different fields depending on the
version.
The issue is that qemu-kvm 1.0 used version ID 2
but is actually sending a version 3 structure.
I don't think I can just reduce the minimum version
ID. As per the comment in the original patch from
Cole Robinson:
http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0001-Fix-migration-from-qemu-kvm.patch?h=f20
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -289,7 +289,13 @@ static int acpi_load_old(QEMUFile *f, void *opaque, int
version_id)
static const VMStateDescription vmstate_acpi = {
.name = piix4_pm,
.version_id = 3,
-.minimum_version_id = 3,
+/*
+ * qemu-kvm 1.2 uses qemu.git version 3 format, but advertised as 2.
+ * This allows incoming migration from qemu-kvm, but breaks incoming
+ * migration from qemu 1.3.
+ */
+//minimum_version_id = 3,
+.minimum_version_id = 2,
.minimum_version_id_old = 1,
.load_state_old = acpi_load_old,
.post_load = vmstate_acpi_post_load,
An inbound migration from qemu-1.0-git, qemu-1.1 or
qemu-1.2 will have version ID 2 and actually mean version
2; currently (i.e. with minimum_version_id = 3), these
use the minimum_version_id_old field (1) and
acpi_load_old routine.
If I decrease minimum_version_id to 2, as far as I can
tell this will break inbound migration from the 'good'
earlier versions, whilst fixing qemu-1.0-kvm (which uses
version 2 to mean version 3).
So as far as I can tell, the minimum version ID needs
to be dependent upon inbound machine type (or machine
parameters). By the time the command line is parsed,
these structures have already been built. That's why
I took the approach I did, but again I'm new to this
so may be missing something.
Or were you suggesting I introduced a
test_force_use_new_load_vm_state
type field into VMStateDescription so it can dynamically
choose not to use the load_state_old but rather to
use the new method, irrespective of the minimum version
mismatch?
--
Alex Bligh
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
On Mon, Aug 04, 2014 at 05:46:58PM +0100, Alex Bligh wrote:
Michael,
On 4 Aug 2014, at 17:22, Michael S. Tsirkin m...@redhat.com wrote:
These are capable of modifying fields within the
VMStateDescription of the relevant object.
However, the PIIX4 change modifies the minimum_version_id
(outside fields); I don't quite see how that would work.
Can you help here?
If you want to support lower version IDs,
you can just decrease minimum_version_id.
field_exists gets the version ID so you can
parse different fields depending on the
version.
The issue is that qemu-kvm 1.0 used version ID 2
but is actually sending a version 3 structure.
I don't think I can just reduce the minimum version
ID.
As per the comment in the original patch from
Cole Robinson:
http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0001-Fix-migration-from-qemu-kvm.patch?h=f20
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -289,7 +289,13 @@ static int acpi_load_old(QEMUFile *f, void *opaque, int
version_id)
static const VMStateDescription vmstate_acpi = {
.name = piix4_pm,
.version_id = 3,
-.minimum_version_id = 3,
+/*
+ * qemu-kvm 1.2 uses qemu.git version 3 format, but advertised as 2.
+ * This allows incoming migration from qemu-kvm, but breaks incoming
+ * migration from qemu 1.3.
+ */
+//minimum_version_id = 3,
+.minimum_version_id = 2,
.minimum_version_id_old = 1,
.load_state_old = acpi_load_old,
.post_load = vmstate_acpi_post_load,
An inbound migration from qemu-1.0-git, qemu-1.1 or
qemu-1.2 will have version ID 2 and actually mean version
2; currently (i.e. with minimum_version_id = 3), these
use the minimum_version_id_old field (1) and
acpi_load_old routine.
If I decrease minimum_version_id to 2, as far as I can
tell this will break inbound migration from the 'good'
earlier versions, whilst fixing qemu-1.0-kvm (which uses
version 2 to mean version 3).
So as far as I can tell, the minimum version ID needs
to be dependent upon inbound machine type (or machine
parameters). By the time the command line is parsed,
these structures have already been built. That's why
I took the approach I did, but again I'm new to this
so may be missing something.
Or were you suggesting I introduced a
test_force_use_new_load_vm_state
type field into VMStateDescription so it can dynamically
choose not to use the load_state_old but rather to
use the new method, irrespective of the minimum version
mismatch?
I was merely suggesting changing acpi_load_old to
detect the new flag and parse the qemu-kvm format.
--
Alex Bligh
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
On 4 Aug 2014, at 17:59, Michael S. Tsirkin m...@redhat.com wrote: I was merely suggesting changing acpi_load_old to detect the new flag and parse the qemu-kvm format. Oh OK - far simpler. If the machine is subsequently migrated to another qemu-2.x device, I take it that will still write out a proper version 3 object? -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
On Mon, Aug 04, 2014 at 06:08:05PM +0100, Alex Bligh wrote: On 4 Aug 2014, at 17:59, Michael S. Tsirkin m...@redhat.com wrote: I was merely suggesting changing acpi_load_old to detect the new flag and parse the qemu-kvm format. Oh OK - far simpler. If the machine is subsequently migrated to another qemu-2.x device, I take it that will still write out a proper version 3 object? I think so, yes. -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
