<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div>On Thu, 2016-01-21 at 18:42 &#43;0000, Nir Soffer wrote:</div>
<blockquote type="cite">
<pre>On Thu, Jan 21, 2016 at 2:54 PM, Pavel Gashev &lt;<a href="mailto:Pax@acronis.com">Pax@acronis.com</a>&gt; wrote:
<blockquote type="cite">Also there is no option in
oVirt web interface to use COW format on NFS storage domains.
</blockquote>

You can
1. create a small disk (1G)
2. create a snapshot
3. extend the disk go the final size

And you have nfs with cow format. The performance difference with one snapshot
should be small.
</pre>
</blockquote>
<div><br>
</div>
<div>
<div style="font-family: monospace;">Yes. And there are other workarounds:</div>
<div style="font-family: monospace;">1. Use some block (i.e. iSCSI) storage for creating a thin provisioned disk (which is COW) and then move it to required storage.</div>
<div style="font-family: monospace;">2. Keep an empty 1G COW disk and copy&#43;resize it when required.</div>
<div style="font-family: monospace;">3. Use ovirt-shell for creating disks.</div>
<div style="font-family: monospace;"><br>
</div>
<div style="font-family: monospace;">Unfortunately, these are not native ways. These are ways for a hacker. Plain user clicks &quot;New&quot; in &quot;Disks&quot; tab and selects &quot;Thin Provision&quot; allocation policy. It's hard to explain to users that the simplest and obvious way
 is wrong. I hope it's wrong only for MS NFS.</div>
</div>
<div><br>
</div>
<blockquote type="cite">
<pre><blockquote type="cite">5. Data corruption happens after 'Auto-generated for Live Storage Migration'
snapshot. So if you rollback the snapshot, you could see absolutely clean
filesystem.
</blockquote>

Can you try to create a live-snapshot on MS NFS? It seems that this is the
issue, not live storage migration.
</pre>
</blockquote>
<div><br>
</div>
<div>Live snapshots work very well on MS NFS. Creating and deleting works live without any issues. I did it many times. Please note that everything before the snapshot remains consistent. Data corruption occurs after the snapshot. So only non-snapshotted data
 is corrupted.</div>
<div><br>
</div>
<blockquote type="cite">
<pre>
Do you have qemu-guest-agent on the vm? Without qemu-guest-agent, file
systems on the guest will no be freezed during the snapshot, which may cause
inconsistent snapshot.
</pre>
</blockquote>
<div><br>
</div>
<div>I tried it with and without qemu-guest-agent. It doesn't depend.&nbsp;</div>
<div><br>
</div>
<blockquote type="cite">
<pre>
Can you reproduce this with virt-manager, or by creating a vm and taking
a snapshot using virsh?
</pre>
</blockquote>
<div><br>
</div>
<div>Sorry, I'm not sure how I can reproduce the issue using virsh.</div>
<div><br>
</div>
<blockquote type="cite">
<pre>

Please file a bug and attach:

- /var/log/vdsm/vdsm.log
- /var/log/messages
- /var/log/sanlock.log
- output of  nfsstat during the test, maybe run it every minute?</pre>
</blockquote>
<div><br>
</div>
<div>Ok, I will collect the logs and fill a bug.</div>
<div><br>
</div>
<div>Thanks</div>
<div><br>
</div>
<div><br>
</div>
</body>
</html>