Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1235577 - [Docs] when importing VM via v2v integration one should not manipulate with the VM on VMware side in any way
[Docs] when importing VM via v2v integration one should not manipulate with t...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: Documentation (Show other bugs)
3.6.0
Unspecified Unspecified
medium Severity high
: ovirt-3.6.1
: 3.6.0
Assigned To: Megan Lewis
Tahlia Richardson
docs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-06-25 04:44 EDT by Nisim Simsolo
Modified: 2016-01-19 06:43 EST (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-19 06:43:23 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Docs
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nisim Simsolo 2015-06-25 04:44:08 EDT
Description of problem:
When running source VM during v2v import, data corruption can occur due to writing and copying disk concurrently.
In order to avoid it, RHEVm should rollback v2v import if source VM toggles from "down" to "up" state. 

Steps to Reproduce:
1. Open RHEVm UI import dialog, select source provider VM and start import.
2. During import process start source provider VM.

Actual results:
There is a risk for data corruption on imported VM.

Expected results:
RHEVm should recognize that source VM state changed from "down" to "up" state and rollback v2v import (delete VM, delete disks and clean related v2v jobs).

Additional info:
Comment 1 Michal Skrivanek 2015-06-26 06:56:37 EDT
it should be blocked for the duration of conversion
this is a bug
Comment 2 Arik 2015-06-26 13:24:33 EDT
(In reply to Michal Skrivanek from comment #1)
> it should be blocked for the duration of conversion
> this is a bug

Note that the VM is started in VMware.
In RHEL the VM is locked and cannot be started (unless engine is restarted, and I already opened a bug for that).
We can't lock the VM in VMware, so we should either poll it periodically to verify that the VM is still 'down' or test it at the end of the conversion, if we want to prevent the possible data curroption
Comment 3 Michal Skrivanek 2015-08-03 04:25:02 EDT
currently not exposed by libvirt API to vmware. - not possible to block on vmware side.
Documentation should be enough - just state that when importing VM via v2v integration one should not manipulate with the VM on VMware side in any way
Comment 5 Sandro Bonazzola 2015-10-26 08:46:54 EDT
this is an automated message. oVirt 3.6.0 RC3 has been released and GA is targeted to next week, Nov 4th 2015.
Please review this bug and if not a blocker, please postpone to a later release.
All bugs not postponed on GA release will be automatically re-targeted to

- 3.6.1 if severity >= high
- 4.0 if severity < high
Comment 6 Andrew Dahms 2015-11-26 18:32:04 EST
Assigning to Megan for review.

Megan - looks like we'll just need to add a note not to touch VMware VMs during import to the Admin Guide.

Note You need to log in before you can comment on or make changes to this bug.