Hi Sebastian, That's the case, at least with Libvirt 1.1.1 and Qemu 1.0 & 1.5 and live block-migration, yes. I know the storage migration code has moved a lot in Qemu, but I'm not sure if this basic issue has been addressed or if we simply need to somehow tell Qemu to use a different (de-coupled) storage and VM migration method. Appreciate any insights on this! Cheers, On 20 March 2014 00:05, Sebastien Han <sebastien.han@xxxxxxxxxxxx> wrote: > Hi Blair, > > Hum so the problem is: > > While block-migrating a VM with local ephemeral storage (VM disk is a file under /var/lib/nova/instances/) the RBD volume attached to the instance gets copied also? > > Am I correct? > > –––– > Sébastien Han > Cloud Engineer > > "Always give 100%. Unless you're giving blood.” > > Phone: +33 (0)1 49 70 99 72 > Mail: sebastien.han@xxxxxxxxxxxx > Address : 11 bis, rue Roquépine - 75008 Paris > Web : www.enovance.com - Twitter : @enovance > > On 19 Mar 2014, at 13:57, Blair Bethwaite <blair.bethwaite@xxxxxxxxx> wrote: > >> Hi Sebastian, >> >> As you seem to favor this configuration too, and are very knowledgeable in these areas, I wonder if you have found an answer to my question about block-migration with attached volumes? >> >> Best regards, >> ~Blair >> >> >> On 18 March 2014 09:08, Blair Bethwaite <blair.bethwaite@xxxxxxxxx> wrote: >> Message: 20 >> Date: Mon, 17 Mar 2014 16:05:17 +0100 >> From: Sebastien Han <sebastien.han@xxxxxxxxxxxx> >> To: "Don Talton (dotalton)" <dotalton@xxxxxxxxx> >> Cc: "ceph-users@xxxxxxxxxxxxxx" <ceph-users@xxxxxxxxxxxxxx> >> Subject: Re: [ceph-users] qemu non-shared storage migration of nova >> instances? >> Message-ID: <86ED699A-DE8B-4864-860F-E324A6F11CC5@xxxxxxxxxxxx> >> Content-Type: text/plain; charset="windows-1252" >> >> Hi, >> >> I use the following live migration flags: VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE,VIR_MIGRATE_PERSIST_DEST >> It deletes the libvirt.xml and re-creates it on the other side. >> >> We use this setup (local direct-attached ephemeral storage and Ceph for persistent volumes) in a production OpenStack cloud. The biggest problem (which I think is still present with newer Qemu&Libvirt, though we are on 1.0 and 1.1.1 respectively at the moment) with this is that live-block-migrations copy all block device contents from source to destination... i.e., even volumes get transferred in a ridiculous sequence of "source hypervisor reads blocks from storage cluster -> source hypervisor streams blocks to destination hypervisor -> destination hypervisor writes blocks back to the storage cluster". >> >> Is that something others have run into and found workarounds for? >> >> -- >> Cheers, >> ~Blairo >> >> >> >> -- >> Cheers, >> ~Blairo > -- Cheers, ~Blairo -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
