Description of problem: HCI DR solution is based on the concept that only data disks are replicated and system disks are not. Currently if some of the VM's disks are not replicated the import of the VM fails. Since some of the disks have snapshots, they can not be imported as floating disks. To allow the DR to works we need to force import of a VM from a storage domain, even if some of its disks are not accessible. Version-Release number of selected component (if applicable): 4.0 How reproducible: Always Steps to Reproduce: 1. Import a VM from storage domain with partial disks. Actual results: Fails Expected results: Should allow to force import. Additional info:
As I understood after talking with Yaniv, we want to be able to register VMs even if part of the storage domains does not exist in the engine (were not imported yet). The behavior is that the user will be able to check a force check box, and the VM will be imported only with the disks that are exist. I got a few questions, I will be happy if you can shed light on: 1) Do we want this behavior to reflect also on then export domain? 2) Do we still want to force import an unregistered VM if the storage domain does exists but the disk doesn't (Currently this behavior is blocked also for import VM)? 3) Do we want to support this also for Templates? The reason I ask is what if the user will import a partial Template with partial disks, and then the user will add another storage domain and try to import a VM based on that Template. This will block the VM to imported since part of the VM disks that are on the latest imported storage domain will not have a relate disk of the template. 4) We need to check what will happen if we will have a snapshot containing disks from missing storage domains, I think that the appropriate behavior will be to re-create those OVFs and remove the missing disks from the snapshot's OVF.
(In reply to Maor from comment #1) > As I understood after talking with Yaniv, we want to be able to register VMs > even if part of the storage domains does not exist in the engine (were not > imported yet). > > The behavior is that the user will be able to check a force check box, and > the VM will be imported only with the disks that are exist. > > I got a few questions, I will be happy if you can shed light on: > 1) Do we want this behavior to reflect also on then export domain? I believe no since this is specific for the HCI DR and they don't use export domain for this. > > 2) Do we still want to force import an unregistered VM if the storage domain > does exists but the disk doesn't (Currently this behavior is blocked also > for import VM)? The HCI will always have a data disk present to import with. Keep it simple and do what is easier, either way is fine. > > 3) Do we want to support this also for Templates? > The reason I ask is what if the user will import a partial Template with > partial disks, and then the user will add another storage domain and try to > import a VM based on that Template. > This will block the VM to imported since part of the VM disks that are on > the latest imported storage domain will not have a relate disk of the > template. Sahina? > > 4) We need to check what will happen if we will have a snapshot containing > disks from missing storage domains, I think that the appropriate behavior > will be to re-create those OVFs and remove the missing disks from the > snapshot's OVF. +1
(In reply to Yaniv Dary from comment #2) > (In reply to Maor from comment #1) > > As I understood after talking with Yaniv, we want to be able to register VMs > > even if part of the storage domains does not exist in the engine (were not > > imported yet). > > > > The behavior is that the user will be able to check a force check box, and > > the VM will be imported only with the disks that are exist. In the DR scenario, a gluster volume is backed up and imported in a new instance of RHV. This gluster volume has the data disk, but not the OS disks of VMs. The OVF_STORE present on the storage domain contains the metadata information of the VMs. We want a way to import the data disks and attach it to another running VM in the new instance. Is this possible with the proposed flow of importing VM? > > > > I got a few questions, I will be happy if you can shed light on: > > 1) Do we want this behavior to reflect also on then export domain? > > I believe no since this is specific for the HCI DR and they don't use export > domain for this. Right. No. > > > > > 2) Do we still want to force import an unregistered VM if the storage domain > > does exists but the disk doesn't (Currently this behavior is blocked also > > for import VM)? > > The HCI will always have a data disk present to import with. > Keep it simple and do what is easier, either way is fine. I'm not sure I understand what an unregistered VM is. Does the flow I mention above answer the question? > > > > > 3) Do we want to support this also for Templates? > > The reason I ask is what if the user will import a partial Template with > > partial disks, and then the user will add another storage domain and try to > > import a VM based on that Template. > > This will block the VM to imported since part of the VM disks that are on > > the latest imported storage domain will not have a relate disk of the > > template. > > Sahina? I think we don't need to support templates - atleast in the use case that I described above. > > > > > 4) We need to check what will happen if we will have a snapshot containing > > disks from missing storage domains, I think that the appropriate behavior > > will be to re-create those OVFs and remove the missing disks from the > > snapshot's OVF. > > +1
(In reply to Sahina Bose from comment #3) > (In reply to Yaniv Dary from comment #2) > > (In reply to Maor from comment #1) > > > As I understood after talking with Yaniv, we want to be able to register VMs > > > even if part of the storage domains does not exist in the engine (were not > > > imported yet). > > > > > > The behavior is that the user will be able to check a force check box, and > > > the VM will be imported only with the disks that are exist. > > In the DR scenario, a gluster volume is backed up and imported in a new > instance of RHV. This gluster volume has the data disk, but not the OS disks > of VMs. The OVF_STORE present on the storage domain contains the metadata > information of the VMs. We want a way to import the data disks and attach it > to another running VM in the new instance. Is this possible with the > proposed flow of importing VM? Hi Sahina, The flow we were thinking of is to allow importing unregistered VMs with partial disks to the engine. We currently don't support register floating disks with snapshots. The end result would be a VM with only data disks but you won't be able to attach those disks to a new VM but you can attach an additional system disk to the imported VM. I think that this would be a better solution since you will maintain the VM details and won't need to create a new VM. Does that fit your solution?
(In reply to Maor from comment #4) > (In reply to Sahina Bose from comment #3) > > (In reply to Yaniv Dary from comment #2) > > > (In reply to Maor from comment #1) > > > > As I understood after talking with Yaniv, we want to be able to register VMs > > > > even if part of the storage domains does not exist in the engine (were not > > > > imported yet). > > > > > > > > The behavior is that the user will be able to check a force check box, and > > > > the VM will be imported only with the disks that are exist. > > > > In the DR scenario, a gluster volume is backed up and imported in a new > > instance of RHV. This gluster volume has the data disk, but not the OS disks > > of VMs. The OVF_STORE present on the storage domain contains the metadata > > information of the VMs. We want a way to import the data disks and attach it > > to another running VM in the new instance. Is this possible with the > > proposed flow of importing VM? > > > Hi Sahina, > > The flow we were thinking of is to allow importing unregistered VMs with > partial disks to the engine. > We currently don't support register floating disks with snapshots. > The end result would be a VM with only data disks but you won't be able to > attach those disks to a new VM but you can attach an additional system disk > to the imported VM. > I think that this would be a better solution since you will maintain the VM > details and won't need to create a new VM. > Does that fit your solution? BTW, do you require the UI for this solution or the API should be enough?
(In reply to Maor from comment #4) > (In reply to Sahina Bose from comment #3) > > (In reply to Yaniv Dary from comment #2) > > > (In reply to Maor from comment #1) > > > > As I understood after talking with Yaniv, we want to be able to register VMs > > > > even if part of the storage domains does not exist in the engine (were not > > > > imported yet). > > > > > > > > The behavior is that the user will be able to check a force check box, and > > > > the VM will be imported only with the disks that are exist. > > > > In the DR scenario, a gluster volume is backed up and imported in a new > > instance of RHV. This gluster volume has the data disk, but not the OS disks > > of VMs. The OVF_STORE present on the storage domain contains the metadata > > information of the VMs. We want a way to import the data disks and attach it > > to another running VM in the new instance. Is this possible with the > > proposed flow of importing VM? > > > Hi Sahina, > > The flow we were thinking of is to allow importing unregistered VMs with > partial disks to the engine. > We currently don't support register floating disks with snapshots. > The end result would be a VM with only data disks but you won't be able to > attach those disks to a new VM but you can attach an additional system disk > to the imported VM. In the flow that we had proposed, the new VM is recreated from a template. In this case, is there a similar way where the additional system disk can be cloned from an existing one and attached to the imported VM? If so, this should work for us. > I think that this would be a better solution since you will maintain the VM > details and won't need to create a new VM. > Does that fit your solution? >BTW, do you require the UI for this solution or the API should be enough? And yes, UI will be good to have
Updating the bug after a meeting with Sahina over the phone: We have decided that since supporting floating disks with snapshots will be a major change for the upcoming version we aim to support registering VMs with partial disks for now.
Sahina, After the VMs will be registered successfully, are you planning to move or copy the disks from one storage to another? Just want to be sure that oVirt will support the whole scenario you plan. I know for sure that move operation will work well and keep the volume chain with all its snapshots after the move.
Sahina, How crucial it is that the allow_partial_import flag will be also in the GUI? I'm asking since it seems that the dialog of the register is pretty loaded. The REST seems to work well for now, you can checkout the patches and see if that works for the customer use case. This is the following REST command to import a partial unregistered VM (Same goes for Template) POST /api/storagedomains/xxxxxxx-xxxx-xxxx-xxxxxx/vms/xxxxxxx-xxxx-xxxx-xxxxxx/register HTTP/1.1 Accept: application/xml Content-type: application/xml <action> <cluster id='bf5a9e9e-5b52-4b0d-aeba-4ee4493f1072'></cluster> <allow_partial_import>true</allow_partial_import> </action>
Let me first test out the flow via REST before we check on the UI
(In reply to Sahina Bose from comment #10) > Let me first test out the flow via REST before we check on the UI I don't see us adding UI to this later since we have FF coming up. Please decide if it's needed and describe the use case. If you don't have one, we will not be doing anything until 4.2.
The fix for this issue should be included in oVirt 4.1.0 beta 1 released on December 1st. If not included please move back to modified.
(In reply to Yaniv Dary from comment #11) > (In reply to Sahina Bose from comment #10) > > Let me first test out the flow via REST before we check on the UI > > I don't see us adding UI to this later since we have FF coming up. > Please decide if it's needed and describe the use case. If you don't have > one, we will not be doing anything until 4.2. Ok, the API is fine for 4.1
Sahina, can you verify this bug based on the DR script testing?
Yes - changing QE contact to Sas to cover as part of DR workflow
Tested with RHV 4.1.1-6. When the geo-replicated glusterfs storage domain is imported in the another RHV instance, the partial disks and templates could be registered