Re: [ovirt-users] Using Microsoft NFS server as storage domain
On Mon, Jan 25, 2016 at 9:20 PM, Pavel Gashev <Pax(a)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(a)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