Lack of macvlan/macvtap support about fog-libvirt HOT 5 CLOSED

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

from fog-libvirt.

@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?

from fog-libvirt.

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?

from fog-libvirt.

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.

from fog-libvirt.

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

from fog-libvirt.