[ovirt-users] Using Microsoft NFS server as storage domain

[Pavel Gashev]

Nir,

On Fri, 2016-01-22 at 20:47 +0000, Nir Soffer wrote:
> On Fri, Jan 22, 2016 at 5:15 PM, Pavel Gashev <Pax at acronis.com>
> wrote:
> > I've tried to reproduce the mirroring of active layer:
> > 
> > 1. Create two thin template provisioned VMs from the same template
> > on different storages.
> > 2. Start VM1
> > 3. virsh blockcopy VM1 vda /rhev/data
> > -center/...path.to.disk.of.VM2.. --wait --verbose --reuse-external 
> > --shallow
> > 4. virsh blockjob VM1 vda --abort --pivot
> > 5. Shutdown VM1
> > 6. Start VM2. Boot in recovery mode and check filesystem.
> > 
> > I did try this a dozen times. Everything works fine. No data
> > corruption.
> 
> If you take same vm, and do a live storage migration in ovirt, the
> file system is
> corrupted after the migration?

Yes. And I've reproduced the issue:

1. Create a VM on MS NFS
2. Start VM
3. Create a disk-only snapshot
4. virsh blockcopy VM1 /some/file --wait --verbose --reuse-external    
--shallow
5. virsh blockjob VM1 vda --abort --pivot
6. Shutdown VM
7. Copy the /some/file back to
   /rhev/data-center/..the.latest.snapshot.of.VM..
8. Start VM and check filesystem

In other words, creating a snapshot is important step for reproducing
the issue. 

> What is the guest os? did you try with more then one?

Guest OS is W2K12. I was unable to reproduce the issue with Linux.

> The next step is to open a bug with the logs I requested in my last
> message. Please mark the bug
> as urgent.

https://bugzilla.redhat.com/show_bug.cgi?id=1301713

> I'm adding Kevin (from qemu) and Eric (from libvirt), hopefully they
> can tell if the virsh flow is
> indeed identical to what ovirt does, and what should be the next step
> for debugging this.
> 
> Ovirt is using blockCopy if available (should be available everywhere
> for some time), or fallback
> to blockRebase. Do you see this warning?
> 
>     blockCopy not supported, using blockRebase

No such warning. There is 'Replicating drive vda to <disk...' 
Please find vdsm.log attached to the bug report.

Thanks