Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1235577

Summary:	[Docs] when importing VM via v2v integration one should not manipulate with the VM on VMware side in any way
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Nisim Simsolo <nsimsolo>
Component:	Documentation	Assignee:	Megan Lewis <melewis>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Tahlia Richardson <trichard>
Severity:	high	Docs Contact:
Priority:	medium
Version:	3.6.0	CC:	adahms, ecohen, gklein, istein, lbopf, lpeer, lsurette, mgoldboi, michal.skrivanek, nsimsolo, rbalakri, rhev-docs, Rhev-m-bugs, yeylon, ylavi
Target Milestone:	ovirt-3.6.1
Target Release:	3.6.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	docs
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-01-19 11:43:23 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Docs	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Nisim Simsolo 2015-06-25 08:44:08 UTC

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 10:56:37 UTC

it should be blocked for the duration of conversion
this is a bug

Comment 2 Arik 2015-06-26 17:24:33 UTC

(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 08:25:02 UTC

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 12:46:54 UTC

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 23:32:04 UTC

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.

Comment 9 Lucy Bopf 2016-01-19 11:43:23 UTC

This content is now live on the Customer Portal here:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6-Beta/html-single/Virtual_Machine_Management_Guide/index.html#Importing_a_Virtual_Machine_from_a_VMware_Provider

Closing.