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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
