Bug 1719735
| Summary: | [downstream clone - 4.3.5] [RFE] Add by default a storage lease to HA VMs | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | RHV bug bot <rhv-bugzilla-bot> |
| Component: | ovirt-engine | Assignee: | Eyal Shenitzky <eshenitz> |
| Status: | CLOSED ERRATA | QA Contact: | Shir Fishbain <sfishbai> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.2.7 | CC: | aefrat, emarcus, eshenitz, lsurette, michal.skrivanek, mkalinin, rbarry, Rhev-m-bugs, sfishbai, srevivo, tnisan |
| Target Milestone: | ovirt-4.3.5 | Keywords: | FutureFeature, ZStream |
| Target Release: | 4.3.5 | Flags: | lsvaty:
testing_plan_complete-
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | ovirt-engine-4.3.5.1 | Doc Type: | Enhancement |
| Doc Text: |
In this release, a bootable Storage Domain is set as the default lease Storage Domain when HA is selected for a new Virtual Machine.
|
Story Points: | --- |
| Clone Of: | 1600059 | Environment: | |
| Last Closed: | 2019-08-12 11:53:28 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Storage | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1600059 | ||
| Bug Blocks: | |||
|
Description
RHV bug bot
2019-06-12 12:45:01 UTC
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 |