From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59073) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCCx0-0007Jf-RA for qemu-devel@nongnu.org; Thu, 13 Sep 2012 13:11:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TCCwv-0006Oa-FU for qemu-devel@nongnu.org; Thu, 13 Sep 2012 13:11:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54294) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCCwv-0006OP-6Z for qemu-devel@nongnu.org; Thu, 13 Sep 2012 13:11:33 -0400 Message-ID: <505213BE.40503@redhat.com> Date: Thu, 13 Sep 2012 11:11:26 -0600 From: Eric Blake MIME-Version: 1.0 References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigC9CBD9665DA42A2E50CB3C68" Subject: Re: [Qemu-devel] Selective block migration (still on 0.13) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christian Theune Cc: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC9CBD9665DA42A2E50CB3C68 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 09/13/2012 08:58 AM, Christian Theune wrote: > I saw that 0.13 does have block migration available. However, looking a= t > the code, it's an "either or" situation: migrate all block devices or n= one. Migrating disks during live migration has proven to be hard to get right; the current code is moving towards a means of migrating disks independently from live migration, and using something like an NBD server to transfer the remaining portions that changed in between the disk migration and the actual live migration. But it's still a work in progress, so please give feedback to make sure that what we provide for qemu 1.3 is the correct approach. >=20 > In our case we have the root disks on iSCSI (through virtio-blk) and tw= o > additional local disks (for /tmp and swp). >=20 > Now, the iSCSI shouldn't be migrated but the local disks should. Should be possible with Paolo's patches for adding 'drive-mirror', where you use drive-mirror to migrate the disks you care about prior to the live migration. Mirror the overlay of the disks to shared storage, copy the backing file in the background, then do the migration with everything seeing shared overlays and consistent local backing files, then once the migration is complete, you can use block-stream or Jeff's proposed 'block-commit' to get the backing chain collapsed back down to something manageable. > Reading up in the current code, it doesn't look like this would be > feasable. Can someone prove me wrong? Please? :) Correct - this is still an area of active development, and qemu 1.2 isn't much better than 0.13. >=20 > Even the earlier discussion regarding live block copy which included a > reference to using libvirt sounds like it would have a problem > instrumenting the live migration correctly: how do you get the migratio= n > atomic if you need to copy the block devices independent of the VM > migration? Maybe, I'm missing something. I'm still trying to figure out the best way to have libvirt support disk migration in parallel with live migration in light of the interfaces being added to qemu 1.3. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enigC9CBD9665DA42A2E50CB3C68 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBCAAGBQJQUhO/AAoJEKeha0olJ0NqIFoH/REG2k2a6NgNoCgOq5ij+mFt X3poJ8TrQ8n/pJHIckoOEo3QkVsVAu+TwGFuS1Fb1zQVuFeqQah2qaZ26uWb9oM6 0ZqyRXgxzDQAZiOfTub/UNUXHDiRiF/i123T1iRUF8tE91jz17JOSnz8URC9WfDz rwA7NtHalhaT17fytOfQKEap5mQAh3l2Xw2lhVPC4ZJ/P322tART9Ou8RbOH33w5 LV8/tstjjTWRwz796tWup0hIzZu2EGOQr0ywnv4EGZZXyf2t6R7qTxPw0dfK2xrh hZMJPtqb/X7Hr/alTc128w/0/bbqNgN13iCTg6Yrbeme+xg3a8VZsZozS/grrQ0= =laMg -----END PGP SIGNATURE----- --------------enigC9CBD9665DA42A2E50CB3C68--