Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Domain XML] Add more functions to the network part #1703

Closed
ofuro opened this issue Dec 28, 2022 · 3 comments · Fixed by #1739
Closed

[Domain XML] Add more functions to the network part #1703

ofuro opened this issue Dec 28, 2022 · 3 comments · Fixed by #1739

Comments

@ofuro
Copy link

ofuro commented Dec 28, 2022

The main problem come from Libvirt itself on MacOS:
#https://gitlab.com/libvirt/libvirt/-/issues/75

This is an old issue, might never be "fixed", implemented.

As a workaround, I wanted to leverage MacOS vmnet framework with virsh to define the network.
For vmnet I found a useful repository from Lima (also referenced in the libvirt ticket):
socket_vmnet

I used the vagrant-libvirt available options for mgmt network:
libvirt.management_network_name = 'vagrant-mgmt'
libvirt.management_network_device = 'bridge100'
libvirt.management_network_mode = 'bridge'
libvirt.management_network_keep = true

There is plenty of options for private_network and public_network which refer to the network XML.

But only two option for the domain XML regarding the network.
nic_model_type

Previous mention of domain XML Network spec:

    DEBUG create_network_interfaces: Attaching Network Device with XML:
    <interface type="network">
        <alias name="ua-net-0"></alias>
        <source network="vagrant-mgmt"></source>
        <target dev="vnet0"></target>
        <model type="virtio-net-pci"></model>
        <driver></driver>
    </interface>

The target dev is wrong, the name is vmenet0.

Domain XML to be started:

DEBUG start_domain: Starting Domain with XML:
....
....
<interface type='network'>
      <mac address='52:54:00:16:26:24'/>
      <source network='vagrant-mgmt'/>
      <model type='virtio-net-pci'/>
      <alias name='ua-net-0'/>
      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
</interface>
....
....

This piece of XML is the auto-generated network part of the domain. Which only the source network and model type come from my config.

This, of course end up with an error:
ERROR warden: Error occurred: Call to virDomainCreateWithFlags failed: Unable to create TAP devices on this platform: Function not implemented

For the solution:
Add more options for the network domain, to have more flexibility in domain network tweaking.
domain-specific-options
Especially in my case :

Another option that would be interesting to implement is SLIRP:
https://libvirt.org/formatdomain.html#userspace-slirp-stack

So, being able to modify the <interface type=' '/> in the domain XML.

@electrofelix
Copy link
Contributor

Essentially this is the same issue as #1701, in that there needs to be an option management_iface_name to align with the same option for private and public interfaces.

It might be a while before I can get to this (hols and other things), but it's absolutely reasonable to have it implemented. It should be possible to follow the existing code in order to add the required option, if you feel comfortable modifying the ruby code.

@ofuro
Copy link
Author

ofuro commented Dec 28, 2022

#1701 (comment)

As you mentioned a rename might be nice.

In my case it is different, I would need something like :
management_target_device

Which should override the the domain XML section <target dev="vnet0"></target> file created (this setting would not go into the network XML at all).
So I would be able to use my existing TAP vmenet0 which is already created.

In my error:
TAP creation
It happen because libvirt try to create the TAP vnet0

I do not do much ruby, but if I have some time I will look at it.

Thank you for this plugin, that's good work.

@electrofelix
Copy link
Contributor

I believe this is fixed by #1739 in that setting does control the network management device name used by the domain attached. I've just pushed a new bugfix release for this on top of 0.12.0 as I realised I forgot to include it in that release. I don't know if this will definitely work on MacOS, but at least the ability to set the option is now there.

For now I'm going to close it with the assumption that the latest release should allow getting past this particular issue.

You may also find #1205 (comment) to be of interest and may want to add some of your solution onto that issue as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants