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:
*** Bug 1131087 has been marked as a duplicate of this bug. ***
*** Bug 1133300 has been marked as a duplicate of this bug. ***
*** Bug 1358291 has been marked as a duplicate of this bug. ***
Maor, doesn't your work from 4.1 cover this?
(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.
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?
(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
Maor, given bug 1506484 which was fixed, do we still need this RFE? Is it related to DR in any way?
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
*** Bug 1593363 has been marked as a duplicate of this bug. ***
Eyal, how close are we to implementing this functionality?
(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?
No, there was nothing new added to the import flow
(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.
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 ?.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days