+++ This bug is a downstream clone. The original bug is: +++ +++ bug 1600059 +++ ====================================================================== Description of problem: New VMs are currently created without storage lease, despite this is an important integrity feature. The lack of it put at risks VMs that for some other situations would have been protected with lease enabled. Not having it enabled by default is a huge loss for the product and for the customers. Version-Release number of selected component (if applicable): RHV 4.2.latest How reproducible: Always Steps to Reproduce: 1. Create VM 2. Check VM lease Actual results: is missing Expected results: By default RHV should create a VM lease on the storage domain of the boot disk Additional info: Request from Yaniv Lavi in rhv-prio-list: http://post-office.corp.redhat.com/archives/rhev-prio-list/2018-June/msg00053.html (Originally by Andrea Perotti)
to clarify the bug description - the consideration is only for HA VMs. Regular VMs will still not use the lease mechanism (Originally by michal.skrivanek)
The risk that described above is also relevant for an existing VM that is updated to be HA VM. The fix for this RFE should solve this option too. (Originally by Eyal Shenitzky)
After giving it another thought, I believe that this default behavior should take place only when the user creating/updating a VM to HA via the UI. We should avoid this behavior when using the REST and keep it as is (we count that the user is knowing what he is doing when using the REST-API). So I think the solution will be much simpler, just changing the default value of the lease SD in the UI from 'No VM lease' to one of the VM's disks storage domains. (Originally by Eyal Shenitzky)
people will eventually complain, they always do when we do something in UI only. The patch comments are relatively small, and the correct handling on update VM needs to be happen anyway for UI too. We can change behavior in new cluster level so it wouldn't affect existing setups. OTOH it's not a big deal if there's indeed some complication with that. Maybe with a clear note in REST API docs it's ok... (Originally by michal.skrivanek)
Creating or updating a VM to HA will create a lease as default behavior from the UI, for REST we will leave it as is now as the change is not visible as in the UI and will practically force the user to have a VM lease when creating an HA VM (Originally by Tal Nisan)
(In reply to Tal Nisan from comment #6) > Creating or updating a VM to HA will create a lease as default behavior from > the UI, for REST we will leave it as is now as the change is not visible as > in the UI and will practically force the user to have a VM lease when > creating an HA VM Setting a lease by default when updating a VM to be HA is problematic. We cannot distinguish between the two options: 1) The VM set as HA and doesn't have a lease 2) The user removed the lease from the HA VM Therefore the solution will be setting a VM lease by default only for new HA VMs. (Originally by Eyal Shenitzky)
Verified When setting a VM lease on the storage domain that contains the VM bootable disk, the HA sets by default ovirt-engine-4.3.5.1-0.1.el7.noarch vdsm-4.30.20-1.el7ev.x86_64
Hi Eyal - here is the suggested Doc Text for this enhancement: In this release, a bootable Storage Domain is set as the default lease Storage Domain when HA is selected for a new Virtual Machine.
Sounds ok to me
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. https://access.redhat.com/errata/RHEA-2019:2431