Bug 1235577 - [Docs] when importing VM via v2v integration one should not manipulate with the VM on VMware side in any way
Summary: [Docs] when importing VM via v2v integration one should not manipulate with t...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: Documentation
Version: 3.6.0
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: ovirt-3.6.1
: 3.6.0
Assignee: Megan Lewis
QA Contact: Tahlia Richardson
URL:
Whiteboard: docs
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-06-25 08:44 UTC by Nisim Simsolo
Modified: 2016-01-19 11:43 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-01-19 11:43:23 UTC
oVirt Team: Docs
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 952703 1 None None None 2021-05-01 16:29:36 UTC

Internal Links: 952703

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.


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