Description of problem: I have an oVirt host installed on top of CentOS which also has some additional VMs installed on it which are not managed by oVirt. I have just upgraded my host and engine to 4.2 from 4.1 and now I am seeing my additional VMs appearing in the list along with the ones managed by oVirt. These additional VMs are marked "external-<vm name>" and all actions on them from the ovirt-engine web portal come back as "This VM is not managed by the engine." (e.g. when I try to start or stop the VM). This is fine, I previously managed these through virt-manager and am very happy to continue to do so. The problem is, now, that I cannot place the host into Maintenance mode because it tells me "Error while executing action: The following Hosts have running VMs and cannot be switched to maintenance mode: ovirt-host". Previously this wasn't a problem since it only checked for VMs running inside the oVirt umbrella and not these external VMs. Is there any way to solve this because it is really not possible to always close down all the external VMs just to put the host into maintenance mode. It is also not possible to migrate these external VMs to other server hardware. Alternatively, is there any way to downgrade back to oVirt 4.1 until the problem is fixed?
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