Bug 1579303
| Summary: | External VMs prevent placing host in maintenance mode | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Andy G <andyg1001> |
| Component: | BLL.Infra | Assignee: | Ravi Nori <rnori> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Pavol Brilla <pbrilla> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.2.3.5 | CC: | ahadas, bugs, lsvaty, michal.skrivanek, mperina |
| Target Milestone: | ovirt-4.2.6 | Flags: | rule-engine:
ovirt-4.2+
|
| Target Release: | 4.2.6 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | ovirt-engine-4.2.6 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-09-03 15:09:18 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Infra | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Andy G
2018-05-17 10:28:18 UTC
Also, the status of the external VMs are also properly reported -- they say they are paused even though they are not. I would be very happy if there were simply an option to ignore external VMs inside oVirt. Michale, how to convert extenal VMs into VMs managed by oVirt? No, we're displaying them with some information we're able to get from libvirt, but currently do not support any action on them. I think the best would be to ignore them on Maintenance flows since the responsibility on managing them is on the user, and they shouldn't block "our" oVirt flows. Even though obviously if you move your host to maintenance for kernel or qemu update it's going to die if you do not shut them down or migrate them beforehand. I, personally, would be very content with Michal's proposal. This would fit very nicely with how our servers operate. (In reply to Michal Skrivanek from comment #3) > No, we're displaying them with some information we're able to get from > libvirt, but currently do not support any action on them. I think the best > would be to ignore them on Maintenance flows since the responsibility on > managing them is on the user, and they shouldn't block "our" oVirt flows. > Even though obviously if you move your host to maintenance for kernel or > qemu update it's going to die if you do not shut them down or migrate them > beforehand. Makes sense, let's ignore external VMs when checking if host can be moved to maintenance (In reply to Michal Skrivanek from comment #3) > No, we're displaying them with some information we're able to get from > libvirt, but currently do not support any action on them. I think the best > would be to ignore them on Maintenance flows since the responsibility on > managing them is on the user, and they shouldn't block "our" oVirt flows. > Even though obviously if you move your host to maintenance for kernel or > qemu update it's going to die if you do not shut them down or migrate them > beforehand. Actually, we support some actions on external VMs [1]. One of them is migration - if the VM uses disks that are placed on shared storage that is available to multiple hosts, that migration could work. So now it comes down to what is the common use - finding ovirt/rhv-like VMs on those hosts that you can partially manage (you can't run them but you can migrate or shut them down) or use cases like this one that VMs were started using tools like virt-manager that our way of managing them is pretty limited. I wouldn't simply ignore those VMs as if those VMs can migrate, we should migrate them. I think that if we are not able to migrate them, it's fine to fail operations like put host to maintenance - assuming the user can shut the relevant VMs down to enable that operation. It would be nice to add some kind of filtering, either on the host-side or on the engine-side, to completely ignore some external VMs. If we are going to ignore them anyway, there's not much sense in adding them to the system. [1] https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/common/src/main/java/org/ovirt/engine/core/common/validation/VmActionByVmOriginTypeValidator.java#L13 (In reply to Arik from comment #6) > I wouldn't simply ignore those VMs as if those VMs can migrate, we should > migrate them. I think that if we are not able to migrate them, it's fine to > fail operations like put host to maintenance - assuming the user can shut > the relevant VMs down to enable that operation. > > It would be nice to add some kind of filtering, either on the host-side or > on the engine-side, to completely ignore some external VMs. If we are going > to ignore them anyway, there's not much sense in adding them to the system. The problem I have is that I have external VMs that must be able to remain running even when oVirt is put into maintenance mode. I would be happy with an option that simply filters certain (or in my case, all) external VMs out of the oVirt environment. tested on: Software Version:4.2.6.1_SNAPSHOT-89.g295078e.0.scratch.master.el7ev Base case: # engine-config -g MaintenanceVdsIgnoreExternalVms MaintenanceVdsIgnoreExternalVms: false version: general Host vhost2 cannot change into maintenance mode - not all Vms have been migrated successfully. Consider manual intervention: stopping/migrating Vms: external-RHEL (User: admin@internal-authz). Changed new variable to true: # engine-config -s MaintenanceVdsIgnoreExternalVms=true # engine-config -g MaintenanceVdsIgnoreExternalVms MaintenanceVdsIgnoreExternalVms: true version: general # systemctl restart ovirt-engine Host vhost2 was switched to Maintenance mode by admin@internal-authz. The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days |