Wild VMs from non-ONE host are missing name

We’re running a test with an OpenNebula cluster (6.4.0) to see if this might be something to migrate our current KVM setup to. The OpenNebula cluster is running fine. We can create, delete, start, stop new VMs like a charm.
The next step is to see if we can import VMs from our current KVM (non OpenNebula) setup.
I have created an OS user (oneadmin) with SSH access which is part of the kvm and libvirt groups, so that it can talk to libvirt via virsh.
Once I have added the host to OpenNebula (either using Sunstone or via CLI), the host shows up and it reports that there are 3 WILD VMs found, but when I go to the Wild tab in Sunstone, no VMs show up. When using the commandline (onehost show) it does show 3 WILD VMs, but they are without name and only carry the UUID/IMPORT_ID:


NAME                                                      IMPORT_ID  CPU     MEMORY
8f44ebfd-b59a-49c6-a8c9-f1e01e                                    -    -          -
9a5c2d6f-8acf-4c9d-8749-4ea495                                    -    -          -
95383a60-8890-45cb-a8f2-877684                                    -    -          -

I have copied the KVM monitoring script (kvm.rb) that tries to fetch the information and have added a print of the wilds_info data:

dom = DomainList
p dom.wilds_info

This runs fine, and prints all information, including the VM_NAME, properly:

oneadmin@importhost:~$ ./kvm.rb 

I’m currently running out of ideas why OpenNebula refuses to see the WILD VMs, so I’m hoping somebody here can give some help

I have found that in /var/tmp/one/im/kvm-probes.d/host/system/wild_vm.rb there is a call to DomainList.info. When I change this to DomainList.wilds_info instead, the Wild VM’s show up!

#    puts DomainList.info
    puts DomainList.wilds_info
rescue StandardError => e
    STDERR.puts e.message

Is this a known bug or am I doing something obviously wrong here?

At least now I can continue into looking into migrating these Wild VMs into OpenNebula.

The bug was reported and fixed on 6.4.1.

In order to continue importing the VMs, you can follow this section of the documentation. Keep in mind that imported VMs will have limited functionality compared to native OpenNebula VMs and ideally, you should import the disks to the datastore and generate an equivalent VM Template linking such disks.