Lack of macvlan/macvtap support

[rgershkovich]

Hello,

At the moment fog-libvirt knows nothing about macvlan/macvtap interfaces: https://libvirt.org/formatnetwork.html#examplesDirect

It assumes, that the defined network should have a bridge_name:

def network_to_attributes(net)
          return if net.nil?
          {
            :uuid        => net.uuid,
            :name        => net.name,
            :bridge_name => net.bridge_name
          }
        end

macvtap doesn't have this parameter. So, even when macvtap is not actually used by running VMs, the fact that it's defined in libvirt on its own breaks fog-libvirt.

It would be very nice to have different networking models support. As an example, we are currently unable to create VMs in Foreman on supervisors with macvlan because of this issue.

Thank you for your time.

[plribeiro3000]

Hello @rgershkovich . Thank you for submitting this issue. Would you be up to open a PR adding it?

[rgershkovich]

@plribeiro3000, tried to dig in the issue yesterday. I found out that libvirt api (which is called in this piece via ruby-libvirt) is very modest in terms of available methods: https://libvirt.org/ruby/api/Libvirt/Network.html#method-i-bridge_name

It's not possible to easily figure out which forward parameters the libvirt network uses via this api. I see 2 options here: make bridge_name optional in network_to_attributes, or call net.xml_desc directly to scrap forward mode params from xml. Then some logic could be applied, e.g., if there is dev=ethX near mode="bridge", bridge_name should be optional (macvlan/macvtap mode), otherwise - not.

Can't say that I like these suggestions... Do you find any of these options acceptable, or maybe there is a better way?

[plribeiro3000]

Hmmm. Not sure if i have all the context but i believe your first suggestion would be the way to go. We do some check and based on it we do send the attribute or not. Makes sense?

[bmagistro]

This seems to also apply to passthrough interfaces and may be related to #24 (at least with the trace there) We got hit by this after the upgrade we did of foreman/puppet. As a total hack, I was able to a) remove the "bridge_name" or b) set it to the uuid as a work around.

[github-actions[bot]]

This issue has been marked inactive and will be closed if no further activity occurs.