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