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

Bug 896554

Summary: live storage migration - cannot move vm in up status
Product: Red Hat Enterprise Virtualization Manager Reporter: Jakub Libosvar <jlibosva>
Component: ovirt-engineAssignee: Ayal Baron <abaron>
Status: CLOSED WONTFIX QA Contact: Haim <hateya>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 3.2.0CC: acanan, acathrow, amureini, dyasny, iheim, lpeer, mpastern, Rhev-m-bugs, yeylon, ykaul
Target Milestone: ---Keywords: TestBlocker, Triaged, ZStream
Target Release: 3.2.0   
Hardware: x86_64   
OS: Linux   
Whiteboard: storage
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-01-23 16:55:35 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Engine log none

Description Jakub Libosvar 2013-01-17 14:26:31 UTC
Created attachment 680225 [details]
Engine log

Description of problem:
Disks cannot be moved to another storage domain while vm is running and move vm is sent via API

2013-01-17 15:12:40,305 WARN  [org.ovirt.engine.core.bll.MoveVmCommand] (ajp-/127.0.0.1:8702-15) [1345de24] CanDoAction of action MoveVm failed. Reasons:VAR__ACTION__MOVE,VAR__TYPE__VM,ACTION_TYPE_FAILED_VM_IS_NOT_DOWN
2013-01-17 15:12:40,323 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (ajp-/127.0.0.1:8702-15) Operation Failed: [Cannot move VM. At least one of the VMs is not down.]


Version-Release number of selected component (if applicable):
rhevm-3.2.0-4.el6ev.noarch

How reproducible:
Always

Steps to Reproduce:
1. Have two data domains
2. Start VM
3. Move vm to second domain
  
Actual results:
Forbidden

Expected results:
Succeeds

Additional info:
It is not the regression, happens in rhevm-3.1.0-41.el6ev.noarch as well.

Comment 2 Allon Mureinik 2013-01-23 09:47:11 UTC
The way I see it, MoveVM is a dead concept, only left there for backwards compatibility. The correct verb to use /should/ be MoveDisk.

Of course, if we continue to support MoveVM it should be able to live migrate, but I'd much rather just remove it altogether.

PMs/Michael, you input would be appreciated.

Comment 3 Michael Pasternak 2013-01-23 11:52:30 UTC
(In reply to comment #2)
> The way I see it, MoveVM is a dead concept, only left there for backwards
> compatibility. The correct verb to use /should/ be MoveDisk.
> 
> Of course, if we continue to support MoveVM it should be able to live
> migrate, but I'd much rather just remove it altogether.
> 
> PMs/Michael, you input would be appreciated.

correct, MoveVM is deprecated, MoveDisk should be used instead,
also Jakub, why do you think MoveDisk/MoveVM should succeed while VM is
running? afaics this is pretty complex use-case,

ayal?

Comment 4 Michael Pasternak 2013-01-23 11:54:01 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > The way I see it, MoveVM is a dead concept, only left there for backwards
> > compatibility. The correct verb to use /should/ be MoveDisk.
> > 
> > Of course, if we continue to support MoveVM it should be able to live
> > migrate, but I'd much rather just remove it altogether.
> > 
> > PMs/Michael, you input would be appreciated.
> 
> correct, MoveVM is deprecated, MoveDisk should be used instead,
> also Jakub, why do you think MoveDisk/MoveVM should succeed while VM is
> running? afaics this is pretty complex use-case,
> 
> ayal?

ah, missed the subject "live storage migration", obviously i'm not up to date
with storage features

Comment 5 Allon Mureinik 2013-01-23 14:15:18 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > The way I see it, MoveVM is a dead concept, only left there for backwards
> > compatibility. The correct verb to use /should/ be MoveDisk.
> > 
> > Of course, if we continue to support MoveVM it should be able to live
> > migrate, but I'd much rather just remove it altogether.
> > 
> > PMs/Michael, you input would be appreciated.
> 
> correct, MoveVM is deprecated, MoveDisk should be used instead,
Michael, sorry for nagging, but I want to be 100% sure - does this mean we can simply drop support for MoveVM altogether?

Comment 6 Michael Pasternak 2013-01-23 14:27:43 UTC
(In reply to comment #5)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > The way I see it, MoveVM is a dead concept, only left there for backwards
> > > compatibility. The correct verb to use /should/ be MoveDisk.
> > > 
> > > Of course, if we continue to support MoveVM it should be able to live
> > > migrate, but I'd much rather just remove it altogether.
> > > 
> > > PMs/Michael, you input would be appreciated.
> > 
> > correct, MoveVM is deprecated, MoveDisk should be used instead,
> Michael, sorry for nagging, but I want to be 100% sure - does this mean we
> can simply drop support for MoveVM altogether?

no we can't, in sake of backward compatibility we have to keep it at least four versions after we publicly deprecate it, (and we deprecated it at 3.2 by implementing #883871).

Comment 7 Allon Mureinik 2013-01-23 16:45:48 UTC
Michael - thanks.

Implementing this is a large and risky change, which I don't really want to handle in 3.2's timeframe.
Proposing postpone to 3.3, need to be discussed with PM/QA reps.

Comment 8 RHEL Program Management 2013-01-23 16:55:35 UTC
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

Comment 9 Ayal Baron 2013-01-23 21:34:41 UTC
(In reply to comment #7)
> Michael - thanks.
> 
> Implementing this is a large and risky change, which I don't really want to
> handle in 3.2's timeframe.
> Proposing postpone to 3.3, need to be discussed with PM/QA reps.

MoveVM is deprecated so no point in adding functionality to it.