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

[Nir Soffer]

On Mon, Jan 25, 2016 at 9:20 PM, Pavel Gashev <Pax at acronis.com> wrote:
> 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

At this point, /some/file should be the top layer of the vm, instead of
the latest snapshot of the vm.

Can you add the output of qemu-img info /some/file?

> 6. Shutdown VM
> 7. Copy the /some/file back to
>    /rhev/data-center/..the.latest.snapshot.of.VM..

Can you add the output of qemu-img info on the lastest snapshot of the vm?

> 8. Start VM and check filesystem

What are the results of this check?

Can you answer this on the bug, so we have more information for libvirt and qemu
developers?

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

So this happens only when mirroring a volume that is a result of a live
snapshot, right?

>
>> 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.

W2K - Windows 2000?

>
>> 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