Bug 1108904 - [RFE] Support register of cloned VM or register extra disks to an existing VM/Tempalte in the setup [NEEDINFO]
Summary: [RFE] Support register of cloned VM or register extra disks to an existing VM...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: RFEs
Version: ---
Hardware: Unspecified
OS: Unspecified
unspecified
low vote
Target Milestone: ---
: ---
Assignee: Rob Young
QA Contact: Avihai
URL:
Whiteboard:
: 1131087 1133300 1358291 1593363 (view as bug list)
Depends On:
Blocks: 1381254
TreeView+ depends on / blocked
 
Reported: 2014-06-12 19:30 UTC by Maor
Modified: 2020-11-17 13:04 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
: 1381254 (view as bug list)
Environment:
Last Closed: 2020-08-19 13:19:31 UTC
oVirt Team: Storage
bzlotnik: needinfo-
mkalinin: needinfo? (kshukla)
ylavi: planning_ack?
ylavi: devel_ack?
ylavi: testing_ack?


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1132709 1 None None None 2021-10-05 11:34:42 UTC
Red Hat Knowledge Base (Solution) 1411133 0 None None None 2018-09-02 18:10:56 UTC

Internal Links: 1132709

Description Maor 2014-06-12 19:30:35 UTC
Description of problem:
Support register a VM which is already exists in the setup with clone.
The feature should support, the following:
* Register a VM with partial disks (only on the existing Storage domains).
* Register the remaining disks to the existing VM in the setup (While there was no change in the VM)
* Register a new VM (cloned) while there is already the same VM in the setup, only with part of the disks, which are not existed in the existing VM
* Register a template with part of the storage domains.
* Register the remaining disks to an existing template.



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Maor 2014-09-03 17:55:29 UTC
*** Bug 1131087 has been marked as a duplicate of this bug. ***

Comment 2 Maor 2014-09-16 08:06:20 UTC
*** Bug 1133300 has been marked as a duplicate of this bug. ***

Comment 3 Maor 2016-11-15 00:15:32 UTC
*** Bug 1358291 has been marked as a duplicate of this bug. ***

Comment 4 Allon Mureinik 2017-01-31 12:38:26 UTC
Maor, doesn't your work from 4.1 cover this?

Comment 5 Maor 2017-01-31 16:14:29 UTC
(In reply to Maor from comment #0)
> Description of problem:
> Support register a VM which is already exists in the setup with clone.
> The feature should support, the following:
> * Register a VM with partial disks (only on the existing Storage domains).

Supported using partial import flag through REST

> * Register the remaining disks to the existing VM in the setup (While there
> was no change in the VM)

Not supported

> * Register a new VM (cloned) while there is already the same VM in the
> setup, only with part of the disks, which are not existed in the existing VM

Not supported

> * Register a template with part of the storage domains.

Supported using partial import flag through REST

> * Register the remaining disks to an existing template.

* For copied disks that will be added after the Template is imported - the user should still use the copy operation of the disk since the user will need to choose a quota, although there will not be any copy operation only a DB operation

* I'm not sure about additional disks that will be added by new imported storage domains, IINM it is not supported but I will take a look at it.

Comment 6 Marina Kalinin 2017-10-30 19:17:15 UTC
Yaniv / Maor,

I have a customer looking for the following DR scenario and I think this RFE is exactly what that customer needs.
Please confirm or let me know if I should open another one:

- Maintain 2 Data Centers, one PROD, one DR.
- In each DC have exact same VM running, have local OS disk, specific DNS and FQDN settings to each environment. I.e. each VM has the OS disk, which is not protected in DR.
- The App Disk is the one that needs to be protected.
- App disk resides on the App SD, which is constantly sync-ed on the storage side to another SD.
- In case of disaster recovery, the customer would like to take that replicated App SD and attach the disk, that is associated with existing VM in Prod site, and attach it to the VM in the DR site. 

It is possible to do it today, but importing the disk only via rest API for unregistered disk, but sounds like it is not the right way to do it. Just because it will break internal RHV logic. For instance, what if the customers later tries to import that VM to that environment?

How to implement it? 
Maybe in import UI for disk allow to disassociate a disk from a VM and once done, update the VM that it does not have that disk anymore?

Bottom line - does that qualifies for this RFE or needs a new one?

Comment 7 Marina Kalinin 2017-10-31 14:40:23 UTC
(In reply to Marina from comment #6)
> Yaniv / Maor,
> 
> I have a customer looking for the following DR scenario and I think this RFE
> is exactly what that customer needs.
> Please confirm or let me know if I should open another one:
> 
> - Maintain 2 Data Centers, one PROD, one DR.
> - In each DC have exact same VM running, have local OS disk, specific DNS
> and FQDN settings to each environment. I.e. each VM has the OS disk, which
> is not protected in DR.
> - The App Disk is the one that needs to be protected.
> - App disk resides on the App SD, which is constantly sync-ed on the storage
> side to another SD.
> - In case of disaster recovery, the customer would like to take that
> replicated App SD and attach the disk, that is associated with existing VM
> in Prod site, and attach it to the VM in the DR site. 
> 
> It is possible to do it today, but importing the disk only via rest API for
> unregistered disk, but sounds like it is not the right way to do it. Just
> because it will break internal RHV logic. For instance, what if the
> customers later tries to import that VM to that environment?
> 
> How to implement it? 
> Maybe in import UI for disk allow to disassociate a disk from a VM and once
> done, update the VM that it does not have that disk anymore?
> 
> Bottom line - does that qualifies for this RFE or needs a new one?

Ok, this RFE is slightly different.
I updated another RFE to address this request:
https://bugzilla.redhat.com/show_bug.cgi?id=1506484#c5

Comment 8 Tal Nisan 2018-05-21 09:09:14 UTC
Maor, given bug 1506484 which was fixed, do we still need this RFE? Is it related to DR in any way?

Comment 9 Maor 2018-05-21 11:32:06 UTC
It is not related directly to the DR support.
This RFE indicates different scenarios (See comment 5), it could be that part of them are less relevant, if you think so we can close this RFE

Comment 10 Maor 2018-09-02 18:10:56 UTC
*** Bug 1593363 has been marked as a duplicate of this bug. ***

Comment 12 Tal Nisan 2019-11-19 14:20:55 UTC
Eyal, how close are we to implementing this functionality?

Comment 13 Eyal Shenitzky 2019-11-24 08:09:20 UTC
(In reply to Tal Nisan from comment #12)
> Eyal, how close are we to implementing this functionality?

We don't have the support for import disks which are part of entities (VMs/Templates) without import the whole entity
and we should think if we want to support it (not supported in export domain for example).

I am not sure if Benny's work not covers the option to import a VM/Template from Data domain as 'clone'.
Benny, is this flow optional now?

Comment 14 Benny Zlotnik 2019-11-24 08:18:26 UTC
No, there was nothing new added to the import flow

Comment 15 Eyal Shenitzky 2019-11-24 08:25:29 UTC
(In reply to Benny Zlotnik from comment #14)
> No, there was nothing new added to the import flow

So this option doesn't exist and we should think if we need it since registering an entity is only a database operation that doesn't 
require any other operation.

'Clone' entity will require to change the entities IDs to prevent duplication in case the entity already exists.

Comment 16 RHEL Program Management 2020-06-16 11:51:37 UTC
This request has been proposed for two releases. This is invalid flag usage. The ovirt-future release flag has been cleared. If you wish to change the release flag, you must clear one release flag and then set the other release flag to ?.


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