From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35781) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XFNFh-000259-Ki for qemu-devel@nongnu.org; Thu, 07 Aug 2014 08:57:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XFNFd-0004tq-76 for qemu-devel@nongnu.org; Thu, 07 Aug 2014 08:57:05 -0400 Received: from static.92.5.9.176.clients.your-server.de ([176.9.5.92]:48554 helo=mail.hallyn.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XFNFc-0004tJ-U7 for qemu-devel@nongnu.org; Thu, 07 Aug 2014 08:57:01 -0400 Date: Thu, 7 Aug 2014 14:56:59 +0200 From: "Serge E. Hallyn" Message-ID: <20140807125659.GA4619@mail.hallyn.com> References: <1406920333-8297-1-git-send-email-alex@alex.org.uk> <20140807025046.GB18303@ubuntumail> <6AF1AF51-36D9-4939-9184-AA555A043AFE@alex.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <6AF1AF51-36D9-4939-9184-AA555A043AFE@alex.org.uk> Subject: Re: [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh Cc: Ryan Harper , Serge Hallyn , "quintela@redhat.com" , Libvirt , Serge Hallyn , Alexander Graf , "qemu-devel@nongnu.org" , "Michael S. Tsirkin" , Cole Robinson , Amit Shah , Bruce Rogers , Andreas =?iso-8859-1?Q?F=E4rber?= , "Serge E. Hallyn" Quoting Alex Bligh (alex@alex.org.uk): > Serge, >=20 > On 7 Aug 2014, at 03:50, Serge Hallyn wrote: >=20 > > 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. >=20 > Are you using exactly the same arguments by hand and with libvirt? >=20 > 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: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D LC_ALL=3DC PATH=3D/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/= bin QEMU_AUDIO_DRV=3Dnone /usr/bin/kvm -name cirros -S -global virtio-net-p= ci.romfile=3Dpxe-virtio.rom.12.04 -machine pc-1.0-qemu-kvm,accel=3Dkvm,usb= =3Doff -m 512 -realtime mlock=3Doff -smp 1,sockets=3D1,cores=3D1,threads=3D= 1 -uuid 2542c328-6842-33ef-d30e-866c3f3189a8 -no-user-config -nodefaults -c= hardev socket,id=3Dcharmonitor,path=3D/var/lib/libvirt/qemu/cirros.monitor,= server,nowait -mon chardev=3Dcharmonitor,id=3Dmonitor,mode=3Dcontrol -rtc b= ase=3Dutc -no-shutdown -no-acpi -boot strict=3Don -device piix3-usb-uhci,id= =3Dusb,bus=3Dpci.0,addr=3D0x1.0x2 -drive file=3D/var/lib/libvirt/images/cir= ros.img,if=3Dnone,id=3Ddrive-ide0-0-0,format=3Draw -device ide-hd,bus=3Dide= =2E0,unit=3D0,drive=3Ddrive-ide0-0-0,id=3Dide0-0-0,bootindex=3D1 -netdev ta= p,fd=3D26,id=3Dhostnet0 -device virtio-net-pci,netdev=3Dhostnet0,id=3Dnet0,= mac=3D52:54:00:be:d8:99,bus=3Dpci.0,addr=3D0x3 -chardev pty,id=3Dcharserial= 0 -device isa-serial,chardev=3Dcharserial0,id=3Dserial0 -vnc 127.0.0.1:0 -d= evice cirrus-vga,id=3Dvideo0,bus=3Dpci.0,addr=3D0x2 -device AC97,id=3Dsound= 0,bus=3Dpci.0,addr=3D0x4 -incoming fd:23 -device virtio-balloon-pci,id=3Dba= lloon0,bus=3Dpci.0,addr=3D0x5 -msg timestamp=3Don 2014-08-07 12:51:02.400+0000: 1539: debug : virFileClose:99 : Closed fd 25 2014-08-07 12:51:02.401+0000: 1539: debug : virFileClose:99 : Closed fd 31 2014-08-07 12:51:02.401+0000: 1539: debug : virFileClose:99 : Closed fd 3 2014-08-07 12:51:02.401+0000: 1540: debug : virExec:616 : Run hook 0x7f25cb= 17bca0 0x7f25d3aedf20 2014-08-07 12:51:02.401+0000: 1540: debug : qemuProcessHook:2719 : Obtainin= g domain lock 2014-08-07 12:51:02.401+0000: 1540: debug : virDomainLockProcessStart:175 := plugin=3D0x7f25c4170290 dom=3D0x7f25c4186510 paused=3D1 fd=3D0x7f25d3aedb44 2014-08-07 12:51:02.401+0000: 1540: debug : virDomainLockManagerNew:133 : p= lugin=3D0x7f25c4170290 dom=3D0x7f25c4186510 withResources=3D1 2014-08-07 12:51:02.401+0000: 1540: debug : virLockManagerPluginGetDriver:2= 81 : plugin=3D0x7f25c4170290 2014-08-07 12:51:02.401+0000: 1540: debug : virLockManagerNew:305 : driver= =3D0x7f25da723580 type=3D0 nparams=3D5 params=3D0x7f25d3aeda30 flags=3D0 2014-08-07 12:51:02.401+0000: 1540: debug : virLockManagerLogParams:98 : = key=3Duuid type=3Duuid value=3D2542c328-6842-33ef-d30e-866c3f3189a8 2014-08-07 12:51:02.401+0000: 1540: debug : virLockManagerLogParams:91 : = key=3Dname type=3Dstring value=3Dcirros 2014-08-07 12:51:02.401+0000: 1540: debug : virLockManagerLogParams:79 : = key=3Did type=3Duint value=3D2 2014-08-07 12:51:02.401+0000: 1540: debug : virLockManagerLogParams:79 : = key=3Dpid type=3Duint value=3D1540 2014-08-07 12:51:02.401+0000: 1540: debug : virLockManagerLogParams:94 : = key=3Duri type=3Dcstring value=3Dqemu:///system 2014-08-07 12:51:02.401+0000: 1540: debug : virDomainLockManagerNew:145 : A= dding leases 2014-08-07 12:51:02.401+0000: 1540: debug : virDomainLockManagerNew:150 : A= dding disks 2014-08-07 12:51:02.401+0000: 1540: debug : virDomainLockManagerAddDisk:91 = : Add disk /var/lib/libvirt/images/cirros.img 2014-08-07 12:51:02.401+0000: 1540: debug : virLockManagerAddResource:332 := lock=3D0x7f25c417b080 type=3D0 name=3D/var/lib/libvirt/images/cirros.img n= params=3D0 params=3D(nil) flags=3D0 2014-08-07 12:51:02.401+0000: 1540: debug : virLockManagerAcquire:350 : loc= k=3D0x7f25c417b080 state=3D'' flags=3D3 action=3D0 fd=3D0x7f25d3aedb44 2014-08-07 12:51:02.401+0000: 1540: debug : virLockManagerFree:387 : lock= =3D0x7f25c417b080 2014-08-07 12:51:02.401+0000: 1540: debug : virObjectUnref:259 : OBJECT_UNR= EF: obj=3D0x7f25c415e620 2014-08-07 12:51:02.401+0000: 1540: debug : qemuProcessHook:2746 : Hook com= plete ret=3D0 2014-08-07 12:51:02.401+0000: 1540: debug : virExec:618 : Done hook 0 2014-08-07 12:51:02.401+0000: 1540: debug : virExec:638 : Setting child App= Armor profile to libvirt-2542c328-6842-33ef-d30e-866c3f3189a8 2014-08-07 12:51:02.402+0000: 1540: debug : virExec:655 : Setting child uid= :gid to 107:113 with caps 0 2014-08-07 12:51:02.402+0000: 1540: debug : virCommandHandshakeChild:358 : = Notifying parent for handshake start on 28 2014-08-07 12:51:02.402+0000: 1540: debug : virCommandHandshakeChild:366 : = Waiting on parent for handshake complete on 29 libvirt: error : libvirtd quit during handshake: Input/output error 2014-08-07 12:51:02.424+0000: shutting down =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Perhaps the key is here: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2014-08-07 12:51:02.416+0000: 1119: debug : virEventPollDispatchHandles:508= : EVENT_POLL_DISPATCH_HANDLE: watch=3D7 events=3D1 2014-08-07 12:51:02.416+0000: 1119: debug : udevEventHandleCallback:1585 : = udev action: 'add' 2014-08-07 12:51:02.416+0000: 1119: debug : udevGetDeviceProperty:125 : ude= v reports device 'rx-0' does not have property 'DRIVER' 2014-08-07 12:51:02.416+0000: 1119: debug : udevGetDeviceProperty:143 : Fou= nd property key 'SUBSYSTEM' value 'queues' for device with sysname 'rx-0' 2014-08-07 12:51:02.416+0000: 1119: debug : udevGetDeviceType:1279 : Could = not determine device type for device with sysfs name 'rx-0' 2014-08-07 12:51:02.416+0000: 1119: debug : udevAddOneDevice:1454 : Discard= ing device -1 0x7f25dcb40e80 /sys/devices/virtual/net/vnet0/queues/rx-0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 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. >=20 > 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. No no, the qcow2 corruption is nothing to do with the migration itself. I'm testing migration between two vms on my laptop which are using qcow2 snapshots for rootfs, and those are the ones getting the corruption. This is https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1319578 https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1315162 and https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1292234 which i could never reproduce before. -serge