[libvirt-users] Live migration with non-shared ZFS volume

[Martin Kletzander]

On Tue, Apr 04, 2017 at 12:04:42PM +0200, Daniel Kučera wrote:
>Hi all,
>

Hi,

I caught your mail in my Spam folder for some reason, maybe the same
happened for others.  I don't have that deep knowledge of the snapshots,
but I'm replying so that if someone else has it in Spam and they have
more insight, they can reply.

>I'm using ZFS on Linux block volumes as my VM storage and want to do live
>migrations between hypervisors.
>
>If I create ZFS snapshot of used volume on source host, send it do
>destination host (zfs send/recv) and then run live migration with
>VIR_MIGRATE_NON_SHARED_DISK
>flag, the migration works OK.
>
>But this procedure copies the whole disk twice which is a huge downside.
>
>The best solution would be, if libvirt could send the incremental data
>since last snapshot itself but this feature is not there (AFAIK).
>
>So I am thinking about a workaround:
>1. Create snapshot using: "virsh snapshot-create --xmlfile snap.xml
>--disk-only --no-metadata test-domain" which will start writing snapshot
>data into temporary qcow2 file
>
><domainsnapshot>
>  <disks>
>    <disk name='/dev/zstore/test-volume'>
>      <source file='/tmp/test-volume.qcow2'/>
>    </disk>
>  </disks>
></domainsnapshot>
>
>
>2. Create snapshot of backing ZFS volume and send it to destination host.
>3. Migrate the domain
>
>Currently, in step 3 I need to create empty qcow snapshot file on the
>destination host, otherwise the migration fails with: "Operation not
>supported: pre-creation of storage targets for incremental storage
>migration is not supported"
>

So apart from this it does exactly what you want, right?

>My question is: Is it possible to do live migration with blockcommit
>operation? If not, would it be hard to implement?
>
>I imagine it like I would start migration with some special parameter (e.g.
>VIR_MIGRATE_NON_SHARED_INC_COMMIT) which would only migrate data from qcow
>snapshot to destination storage.
>
>This would ensure the disk consistency and avoid useless whole disk copy.
>

What would be the difference compared to what you are doing now (plus a
block commit)?  VIR_MIGRATE_NON_SHARED_INC should already migrate only
the topmost disk of the whole chain.

Of course lot can be added to the project, but I, for one, am not *that*
welcoming with regards to things that are meant for pretty narrow use
case while at the same time they are doable already, using libvirt's API.

>Or do you have any other idea how to solve this?
>
>BR.
>Daniel Kucera.

>_______________________________________________
>libvirt-users mailing list
>libvirt-users at redhat.com
>https://www.redhat.com/mailman/listinfo/libvirt-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20170428/73bbd794/attachment.sig>