We need to import libvirt managed VMs into oVirt without restarting the VM. Workarounds and external scripts are welcome. Pausing and saving the VM state for later restoring inside oVirt is ok. Comments and ideas to implement this feature are very appreciated.
what kind of import are you looking for? we do have "external VM" concept which allows us to control some basic functionality (start, stop, migrate) but doesn't allow to edit properties, etc. For "proper" import we would need to do a full conversion potentially changing some of the devices...and that would require a restart
(In reply to Michal Skrivanek from comment #1) > what kind of import are you looking for? We have libvirt VMs running on oVirt hosts and want to be able to control them from Engine. > we do have "external VM" concept which allows us to control some basic > functionality (start, stop, migrate) but doesn't allow to edit properties, > etc. Sounds good. How can we get oVirt to detect those external VMs? It seems this is not being done by default.
BTW, external libvirtd VMs (not handled by oVirt) are shutting down when vdsmd is restarted and I guess/hope this can be avoided by adding the VMs as "external VMs" into oVirt. I found the "externalVMList" patch [1] and was able list the external VMs via vdsClient, but I don't see any option or docs telling how to import them into Engine (the "Import Virtual Machine" dialog is only showing "VMWare", "Export Domain" and "OVA" sources). Are this features available in 3.6? [1] : https://gerrit.ovirt.org/#/c/33309/
(In reply to Christopher Pereira from comment #3) > BTW, external libvirtd VMs (not handled by oVirt) are shutting down when > vdsmd is restarted and I guess/hope this can be avoided by adding the VMs as > "external VMs" into oVirt. Please ignore this last comment. I found and solved this particular problem: https://bugzilla.redhat.com/show_bug.cgi?id=1279248 Anyway, we have dozens of VMs in production which were originally created via oVirt, but are currently managed via libvirt (outside oVirt) because of different issues (all reported, some solved). We would like to import them back to oVirt with minimum downtime.
postponing to future version, based on capacity and prioritization.
(In reply to Michal Skrivanek from comment #1) > we do have "external VM" concept which allows us to control some basic > functionality (start, stop, migrate) but doesn't allow to edit properties, > etc. Are libvirt VMs being detected as "external VM"? Doesn't seem to work on 3.6 at least.
(In reply to Christopher Pereira from comment #6) > (In reply to Michal Skrivanek from comment #1) > > > we do have "external VM" concept which allows us to control some basic > > functionality (start, stop, migrate) but doesn't allow to edit properties, > > etc. > > Are libvirt VMs being detected as "external VM"? > Doesn't seem to work on 3.6 at least. bz 1302427 merged upstream and it will be in 4.0
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
This request has been proposed for two releases. This is invalid flag usage. The ovirt-future release flag has been cleared. If you wish to change the release flag, you must clear one release flag and then set the other release flag to ?.
There was some initial confusion here, this is NOT bug 1302427, this one requests import of live running VMs which is out of scope of bug 1302427. Hence moving back to unassigned state
We have not touched this RFE for a long time and do not have the capacity to handle it right now. Deferring for the time being.