Description of problem: As the export domain is going to be deprecated. We should make it easier to move the entire VMs from one data SD to another SD. Currently Disks has to be marked for each VM in the subtab Disks. This means that the VMs can be migrated only one by one which can be time consuming. It also only allow move, but not copy. Which may not be convenient. Another option is to use The Tab Disks and copy the Disks based on the "Assigned to" field. This can be a bit inconvenient if there are too many disks. It would be more convenient if the operation could be triggered from the VM tab in the same way as the "Export" button currently work for the export domain.
what would be the gaps after bug 1049604 and bug 1319524 are implemented?
Bug 1319524 will for sure help, but it depends on the implementation. If it is click, clone, destination SD then yes.
Also, why is cloning the VM with collapse no good enough?
(In reply to Yaniv Lavi (Dary) from comment #3) > Also, why is cloning the VM with collapse no good enough? Because cloning will clone only on the same storage domain. Why same storage domain is not a good option? Because what if we want to keep the VM in this environment as well? Please see this KCS, that will show you the difference between the old flow and new flow, and we can see how much more complicated and not intuitive the new flow is: https://access.redhat.com/solutions/3172561 I totally second Roman's request to have a simple one click operation here: Copy/Move/Export VM to another storage domain. And if we want to maintain the functionality of copying only several disks out of multiple, we can add an addition checkbox list. Right now the procedure is simply unacceptable.
So for Copy, a clone is just fine from my PoV. Moving Disks, you still want to be able to move them in a single step. But I could imagine the following "bulk move" processes: - Evacuate a Storage Domain (Move all Disks to a different Storage Domain). This should be done in the Storage Tab - Move all disks from a VM to a different SD This should be done in the VM Tabs (maybe the Disk Subtab, being able to select multiple disks to be moved at once). Thoughts?
This sounds also quite confusing to me. I think the right answer here is bug 1049604 and bug 1319524 (e.g. 1: pick VM, download OVA. 2: pick OVA, upload to any environment).
Hm, maybe I misunderstood the request, but as I see it, the ask is not really export/import, but moving VMs between different Storage Domains (which are all available on one RHV-M). So the typical tasks, I can imagine would be: 1. Move all disk of a VM from one SD to another 2. Evacuate a Storage Domain (for destroying it afterwards, but pertaining all the disks 3. The Usecase described in https://access.redhat.com/solutions/3172561 So what functionality would we need: 1. Clone a VM, but have all disks in a different Storage Domain than the Original (aka Copy a VM to another Storage Domain) 2. Evacuate a Storage Domain (either selecting desired target SD(s) or leaving it to the engine) 3. Move all Disks from one VM to a different SD. @Roman, Marina. Does this match your request?
(In reply to Martin Tessun from comment #8) > Hm, maybe I misunderstood the request, but as I see it, the ask is not > really export/import, but moving VMs between different Storage Domains > (which are all available on one RHV-M). > > So the typical tasks, I can imagine would be: > 1. Move all disk of a VM from one SD to another > 2. Evacuate a Storage Domain (for destroying it afterwards, but pertaining > all the disks > 3. The Usecase described in https://access.redhat.com/solutions/3172561 > > So what functionality would we need: > 1. Clone a VM, but have all disks in a different Storage Domain than the > Original (aka Copy a VM to another Storage Domain) Yes - add an option to copy VM disks from VMs tab. It can be done from CloneVM dialogue, by providing a list of disks to copy (checkbox) + list of destination storage domains (list). > 2. Evacuate a Storage Domain (either selecting desired target SD(s) or > leaving it to the engine) ack. love it. > 3. Move all Disks from one VM to a different SD. Yes. The idea here was to combine 1 and 3. For simplicity. I am wondering if 1 and 3 can/should still be combined. Or adding another operation on VMs tab would be better: "Move", along with "Clone", "Create", "Run Once" etc. > > @Roman, Marina. Does this match your request? Leaving needinfo on Roman too.
(In reply to Marina from comment #9) > (In reply to Martin Tessun from comment #8) > > Hm, maybe I misunderstood the request, but as I see it, the ask is not > > really export/import, but moving VMs between different Storage Domains > > (which are all available on one RHV-M). > > > > So the typical tasks, I can imagine would be: > > 1. Move all disk of a VM from one SD to another > > 2. Evacuate a Storage Domain (for destroying it afterwards, but pertaining > > all the disks > > 3. The Usecase described in https://access.redhat.com/solutions/3172561 > > > > So what functionality would we need: > > 1. Clone a VM, but have all disks in a different Storage Domain than the > > Original (aka Copy a VM to another Storage Domain) > Yes - add an option to copy VM disks from VMs tab. It can be done from > CloneVM dialogue, by providing a list of disks to copy (checkbox) + list of > destination storage domains (list). Yes but the dialog is only visible if you are clone from a snapshot. If you clone the VM directly you cannot specify anything apart of the clone name. > > 2. Evacuate a Storage Domain (either selecting desired target SD(s) or > > leaving it to the engine) > ack. love it. ack > > 3. Move all Disks from one VM to a different SD. > Yes. > The idea here was to combine 1 and 3. For simplicity. > I am wondering if 1 and 3 can/should still be combined. Or adding another > operation on VMs tab would be better: "Move", along with "Clone", "Create", > "Run Once" etc. That was the idea. A button sililar to the "export" one in the current solution. > > > > @Roman, Marina. Does this match your request? > Leaving needinfo on Roman too.
If the everything is in the same DC, you can move disks, etc. easily, no? If they are not, then OVA download-upload should help as well. What else is missing?
(In reply to Yaniv Kaul from comment #11) > If the everything is in the same DC, you can move disks, etc. easily, no? > If they are not, then OVA download-upload should help as well. > What else is missing? The export domain use case of cloning to another SD for migration of template/VM.
(In reply to Roman Hodain from comment #0) > Description of problem: > As the export domain is going to be deprecated. We should make it easier to > move the entire VMs from one data SD to another SD. > > Currently Disks has to be marked for each VM in the subtab Disks. This means > that the VMs can be migrated only one by one which can be time consuming. It > also only allow move, but not copy. Which may not be convenient. > > Another option is to use The Tab Disks and copy the Disks based on the > "Assigned to" field. This can be a bit inconvenient if there are too many > disks. > > It would be more convenient if the operation could be triggered from the VM > tab in the same way as the "Export" button currently work for the export > domain. In 4.2 you'll be able to download an OVA of a VM. While not optimal (no real need to really wrap a VM in an OVA for this) it does answer the use case.
Should we start design work on it?
I believe, Storage team is working on this already and Benny is assigned to it. So I am moving to the storage team.
Engine 4.4.0-0.13.master.el7 version has ovirt-engine-ui-extensions-1.0.10-1 when it should be 1.0.11-1.
(In reply to Evelina Shames from comment #27) > Engine 4.4.0-0.13.master.el7 version has ovirt-engine-ui-extensions-1.0.10-1 > when it should be 1.0.11-1. this has changed in the meantime...
Verified on engine-4.4.0-0.25.master.el8ev.
What is the documentation for this procedure? Since this new procedure should be easier, would be great to have the new procedure documented. BZ#1700905 documents the current, cumbersome procedure where we need to move every single disk. So we need something else after this RFE is implemented. I do not see any documentation bug attached to this one.
I just created bug 1829916 for documenting this. What is the actual procedure now?
I just created bug 1829916 for documenting this.
This bugzilla is included in oVirt 4.4.0 release, published on May 20th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.0 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days