<div dir="ltr"><div><div>Hi Martin,<br><br></div>in the meantime, I've found a solution which I consider at least acceptable:<br><br></div><div>1. create zfs snapshot of domain disk (/dev/zstore/test-volume)</div><div><br></div><div>2. save original XML domain definition <br></div><div><br>3. create snapshot in libvirt like this:<br>virsh snapshot-create --xmlfile snap.xml --disk-only --no-metadata test-domain<br>snap.xml:<br><domainsnapshot><br>  <disks><br>    <disk name='/dev/zstore/test-volume'<wbr>><br>      <source file='/tmp/test-volume.qcow2'/<wbr>><br>    </disk><br>  </disks><br></domainsnapshot><br><br></div><div>This creates overlay qcow snapshot on top of my base ZFS volume<br><br></div><div>3. Transfer ZFS volume (with last snapshot) to remote host<br><br></div><div>4. Run live migration with setting XML from step 1 as <span class="m_4219621850565719916gmail-pl-smi">DestXML and </span><span class="m_4219621850565719916gmail-pl-smi">PersistXML</span> parameter and with VIR_MIGRATE_NON_SHARED_INC flag<br><br></div><div>This creates domain without snapshot on the remote host and migrates only data from qcow overlay and commits them to the ZFS base volume.<br><br></div><div>What I don't like about this, is that I need to create and care about qcow image.<br><br></div><div>The best solution for me would be to only create dirty block map in qemu (block-dirty-bitmap-add) in step 3 and then migrate just changed blocks without creating qcow snapshot.<br><br></div><div>Do you think it would be possible to implement it like this?<br><br></div><div>S pozdravom / Best regards<br></div><div>Daniel Kucera<br></div><div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-04-28 11:03 GMT+02:00 Martin Kletzander <span dir="ltr"><<a href="mailto:mkletzan@redhat.com" target="_blank">mkletzan@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Apr 04, 2017 at 12:04:42PM +0200, Daniel Kučera wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
</blockquote>
<br>
Hi,<br>
<br>
I caught your mail in my Spam folder for some reason, maybe the same<br>
happened for others.  I don't have that deep knowledge of the snapshots,<br>
but I'm replying so that if someone else has it in Spam and they have<br>
more insight, they can reply.<div><div class="m_4219621850565719916h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm using ZFS on Linux block volumes as my VM storage and want to do live<br>
migrations between hypervisors.<br>
<br>
If I create ZFS snapshot of used volume on source host, send it do<br>
destination host (zfs send/recv) and then run live migration with<br>
VIR_MIGRATE_NON_SHARED_DISK<br>
flag, the migration works OK.<br>
<br>
But this procedure copies the whole disk twice which is a huge downside.<br>
<br>
The best solution would be, if libvirt could send the incremental data<br>
since last snapshot itself but this feature is not there (AFAIK).<br>
<br>
So I am thinking about a workaround:<br>
1. Create snapshot using: "virsh snapshot-create --xmlfile snap.xml<br>
--disk-only --no-metadata test-domain" which will start writing snapshot<br>
data into temporary qcow2 file<br>
<br>
<domainsnapshot><br>
 <disks><br>
   <disk name='/dev/zstore/test-volume'<wbr>><br>
     <source file='/tmp/test-volume.qcow2'/<wbr>><br>
   </disk><br>
 </disks><br>
</domainsnapshot><br>
<br>
<br>
2. Create snapshot of backing ZFS volume and send it to destination host.<br>
3. Migrate the domain<br>
<br>
Currently, in step 3 I need to create empty qcow snapshot file on the<br>
destination host, otherwise the migration fails with: "Operation not<br>
supported: pre-creation of storage targets for incremental storage<br>
migration is not supported"<br>
<br>
</blockquote>
<br></div></div>
So apart from this it does exactly what you want, right?<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My question is: Is it possible to do live migration with blockcommit<br>
operation? If not, would it be hard to implement?<br>
<br>
I imagine it like I would start migration with some special parameter (e.g.<br>
VIR_MIGRATE_NON_SHARED_INC_COM<wbr>MIT) which would only migrate data from qcow<br>
snapshot to destination storage.<br>
<br>
This would ensure the disk consistency and avoid useless whole disk copy.<br>
<br>
</blockquote>
<br></span>
What would be the difference compared to what you are doing now (plus a<br>
block commit)?  VIR_MIGRATE_NON_SHARED_INC should already migrate only<br>
the topmost disk of the whole chain.<br>
<br>
Of course lot can be added to the project, but I, for one, am not *that*<br>
welcoming with regards to things that are meant for pretty narrow use<br>
case while at the same time they are doable already, using libvirt's API.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Or do you have any other idea how to solve this?<br>
<br>
BR.<br>
Daniel Kucera.<br>
</blockquote>
<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
______________________________<wbr>_________________<br>
libvirt-users mailing list<br>
<a href="mailto:libvirt-users@redhat.com" target="_blank">libvirt-users@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/libvirt-users" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/libvirt-users</a><br>
</blockquote>
</blockquote></div><br></div></div>