Bug 883871 - [RESTAPI] Disk move action missing.
Summary: [RESTAPI] Disk move action missing.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-restapi
Version: 3.1.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: 3.2.0
Assignee: Daniel Erez
QA Contact: Jakub Libosvar
URL:
Whiteboard: storage
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-05 13:21 UTC by Ondra Machacek
Modified: 2019-09-12 07:47 UTC (History)
11 users (show)

Fixed In Version: SF9
Doc Type: Enhancement
Doc Text:
The Move VM command ('/api/vms/{vm:id}/move|rel=move') has been deprecated. Moving a virtual machine disk now uses the POST command: POST /api/vms/xxx/disks/yyy/move <action> <storage_domain id="zzz"/> </action>
Clone Of:
Environment:
Last Closed: 2013-06-10 21:26:10 UTC
oVirt Team: Storage
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 903275 0 unspecified CLOSED Deprecate Move VM 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 956661 0 unspecified CLOSED [RESTAPI] Add support for moving floating disks. 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHSA-2013:0888 0 normal SHIPPED_LIVE Moderate: Red Hat Enterprise Virtualization Manager 3.2 update 2013-06-11 00:55:41 UTC
oVirt gerrit 10676 0 None None None Never
oVirt gerrit 12147 0 None None None Never

Internal Links: 903275 956661

Description Ondra Machacek 2012-12-05 13:21:29 UTC
Description of problem:
There is no way how to move floating disk via API.

Version-Release number of selected component (if applicable):
rhevm-restapi-3.1.0-32.el6ev

How reproducible:
always

Steps to Reproduce:
1. /api/disks/id/move
  
Actual results:
HTTP 404

Expected results:
Disk move action.

Additional info:

Comment 1 Jakub Libosvar 2012-12-06 16:24:06 UTC
Since it's blocking automatic storage live migration tests, adding a TestBlocker. There is no move action in /api/vms/{vm:id}/disks/{disk:id} as well. Now I'm not sure about the FutureFeature.

Comment 3 Michael Pasternak 2012-12-06 16:45:58 UTC
(In reply to comment #1)
> Since it's blocking automatic storage live migration tests, adding a
> TestBlocker. There is no move action in /api/vms/{vm:id}/disks/{disk:id} as
> well. Now I'm not sure about the FutureFeature.

move is combination of copy+delete, why can't you use this workaround instead?

Comment 4 Ayal Baron 2012-12-26 10:42:45 UTC
(In reply to comment #3)
> (In reply to comment #1)
> > Since it's blocking automatic storage live migration tests, adding a
> > TestBlocker. There is no move action in /api/vms/{vm:id}/disks/{disk:id} as
> > well. Now I'm not sure about the FutureFeature.
> 
> move is combination of copy+delete, why can't you use this workaround
> instead?

because we're also talking about live storage migration here and copy does not initiate that.

Comment 5 Daniel Erez 2013-01-06 08:21:15 UTC
patch sent:
http://gerrit.ovirt.org/#/c/10676/

implemented as:
POST /api/vms/xxx/disks/yyy/move
<action>
    <storage_domain id="zzz"/>
</action>

Comment 6 Michael Pasternak 2013-01-06 08:58:46 UTC
is there a use-case for moving template's disks as well?

Comment 7 Daniel Erez 2013-01-06 10:16:59 UTC
(In reply to comment #6)
> is there a use-case for moving template's disks as well?

Currently, the engine only supports moving vm's disks or floating disks.

Comment 8 Ondra Machacek 2013-01-09 15:00:15 UTC
(In reply to comment #6)
> is there a use-case for moving template's disks as well?

(In reply to comment #7)
> (In reply to comment #6)
> > is there a use-case for moving template's disks as well?
> 
> Currently, the engine only supports moving vm's disks or floating disks.

Clearing needinfo.

Comment 9 Jakub Libosvar 2013-01-25 14:57:55 UTC
Any ETA when the patch will make it to downstream and new build for QE consumption? It's blocking us of making new tests.

Comment 10 Michael Pasternak 2013-01-27 07:06:43 UTC
(In reply to comment #9)
> Any ETA when the patch will make it to downstream and new build for QE
> consumption? It's blocking us of making new tests.

next build.

Comment 11 Jakub Libosvar 2013-02-18 08:25:06 UTC
Url defined in doc exists in rhevm-3.2.0-7.el6ev.noarch and works if virtual machine is down. But moveDisk fails in case machine is up and running (storage live migration) with error in candoaction that Storage domain doesn't exist:

2013-02-18 08:21:15,718 INFO  [org.ovirt.engine.core.bll.MoveDisksCommand] (ajp-/127.0.0.1:8702-20) [298bfbb6] Running command: MoveDisksCommand internal: false. Entities affected :  ID: cab7c93b-78dd-4103-9d5a-c772480b7b5a Type: Disk
2013-02-18 08:21:15,743 INFO  [org.ovirt.engine.core.bll.lsm.LiveMigrateVmDisksCommand] (ajp-/127.0.0.1:8702-20) [298bfbb6] Lock Acquired to object EngineLock [exclusiveLocks= key: e03733a0-23aa-4c47-8bc6-c8deb2ba0228 value: VM
, sharedLocks= ]
2013-02-18 08:21:15,765 WARN  [org.ovirt.engine.core.bll.lsm.LiveMigrateVmDisksCommand] (ajp-/127.0.0.1:8702-20) [298bfbb6] CanDoAction of action LiveMigrateVmDisks failed. Reasons:VAR__ACTION__MOVE,VAR__TYPE__VM_DISK,ACTION_TYPE_FAILED_STORAGE_DOMAIN_NOT_EXIST
2013-02-18 08:21:15,765 INFO  [org.ovirt.engine.core.bll.lsm.LiveMigrateVmDisksCommand] (ajp-/127.0.0.1:8702-20) [298bfbb6] Lock freed to object EngineLock [exclusiveLocks= key: e03733a0-23aa-4c47-8bc6-c8deb2ba0228 value: VM
, sharedLocks= ]
2013-02-18 08:21:15,767 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (ajp-/127.0.0.1:8702-20) Operation Failed: [Cannot move Virtual Machine Disk. Storage Domain doesn't exist.]

url:
/api/vms/e03733a0-23aa-4c47-8bc6-c8deb2ba0228/disks/10bda735-b4c8-4129-bdfc-60b623ebcd4b/move 

body:
<action>
    <async>false</async>
    <grace_period>
        <expiry>10</expiry>
    </grace_period>
    <storage_domain href="/api/storagedomains/43ae270f-f733-4bdb-93c6-6a3b089d180c" id="43ae270f-f733-4bdb-93c6-6a3b089d180c">
        <name>iscsi_1</name>
        <link href="/api/storagedomains/43ae270f-f733-4bdb-93c6-6a3b089d180c/permissions" rel="permissions"/>
        <type>data</type>
        <master>false</master>
        <storage>
            <type>iscsi</type>
            <volume_group id="VVleeE-oYfI-KqV5-zi9l-lgyl-lnxO-32CVsD">
                <logical_unit id="36006048c78acaa6eac8ebc05bf73dee1">
                    <address>10.34.63.200</address>
                    <port>3260</port>
                    <target>iqn.1992-05.com.emc:ckm001201002300000-5-vnxe</target>
                    <serial>SEMC_Celerra_EMC-Celerra-iSCSI-VLU-fs74_T5_LUN3_CKM00120100230</serial>
                    <vendor_id>EMC</vendor_id>
                    <product_id>Celerra</product_id>
                    <lun_mapping>3</lun_mapping>
                    <portal>10.34.63.200:3260,1</portal>
                    <size>214748364800</size>
                    <paths>0</paths>
                    <volume_group_id>VVleeE-oYfI-KqV5-zi9l-lgyl-lnxO-32CVsD</volume_group_id>
                    <storage_domain_id>43ae270f-f733-4bdb-93c6-6a3b089d180c</storage_domain_id>
                </logical_unit>
            </volume_group>
        </storage>
        <available>202937204736</available>
        <used>10737418240</used>
        <committed>25769803776</committed>
        <storage_format>v3</storage_format>
    </storage_domain>
</action>

/api/storagedomains/43ae270f-f733-4bdb-93c6-6a3b089d180 shows correctly target storage domain.

Comment 13 Jakub Libosvar 2013-03-14 12:51:28 UTC
Verified rhevm-3.2.0-10.14.beta1.el6ev.noarch

Comment 14 errata-xmlrpc 2013-06-10 21:26:10 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-0888.html


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