I have a long-running OpenNebula setup, which I have upgraded from 6.10 to 7.2 few days ago. Between these versions, the ebtables VNM which I used on my VNets has been deprecated and disappeared. So I changed all my VNets from ebtables to bridge. This allowed me and my users to instantiate new VMs. But they are unable to deploy previously undeployed VMs using these VNets, because the information that they use the ebtables VNM is probably stored somewhere inside the VM config. So even though the VNet itself uses the bridge VNM, trying to deploy an existing VM fails while trying to execute non-existing remotes/vnm/ebtables/pre script.
How can I convert the existing VMs from ebtables to bridge?
As a band-aid, I created a symlink ebtables -> bridge in remotes/vnm, increased the VERSION number and ran onehost sync.
May you check with onevm show --all VM_ID if there is any ebtables related info on the VMs?
In that case, can you check if a onevm updateconf VM_ID allows you to modify the related params?
In the meantime, the symlink should be a valid workaround
@brunorro - onevm updateconf does not update the NIC configuration. onevm nic-update $vm_id $nic_index is supposed to do it. However, I ran it for my machine which has VN_MAD=ebtables, edited s/ebtables/bridge/, but when I saved the text and exit the text editor, nothing happened, and subsequent onevm show --all and onevm nic-update still have VN_MAD=ebtables.
According to onevm man-page, running nic-update should re-plug the NIC inside the VM, but in dmesg from inside of the VM, no hotplug event is received.
EDIT: I discovered CONTEXT_ALLOW_ETH_UPDATES option in oned.conf, but even when set to YES (and restarting oned) it behaves the same.
Any other ideas how to get rid of no-longer present VN_MAD? Thanks!