Re: reconfiguring a two vms bridge to two vms + the host with proper iface naming

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/24/24 12:47 PM, daggs via Users wrote:


Sent: Thursday, October 24, 2024 at 7:43 PM
From: "Daniel P. Berrangé" <berrange@xxxxxxxxxx>
To: "daggs" <daggs@xxxxxxx>
Cc: users@xxxxxxxxxxxxxxxxx
Subject: Re: reconfiguring a two vms bridge to  two vms + the host with proper iface naming

On Thu, Oct 24, 2024 at 06:18:26PM +0200, daggs via Users wrote:
Greetings,

I have two vms (vm1 and vm2) connected via a bridge named br1.
libvirt creates two taps, tap0 and tap1

I'm trying to rename them to some thing more meaningful for starts.
I assume that I cannot use vnet-vm1 or vnet-vm2 so I decided to configure it like this:
vm1:
   <interface type='bridge'>
     <source bridge='br1'/>
     <target dev='vnet1'/>
   </interface>

vm2:
   <interface type='bridge'>
     <source bridge='br1'/>
     <target dev='vnet2'/>
   </interface>

but when start the vms, the iface names are still tap1 and tap2. am I doing something wrong?

I didn't think libvirt created devices with 'tapXXX' naming,

The one place this isn't true is for guests started with unprivileged libvirt; it uses the qemu-bridge-helper to create the tap device and connect it to the bridge, and uses names of the form "tapX". So I'm fairly certain that daggs is running the guests as a normal user, not as root.

all our
generated names should be 'vnetXXX', and we reserve 'vnet' as a prefix
for our own use and will thus discard any such name if the user specifies
it in the XML.

Beyond that, when running guests in non-privileged mode, libvirt has no control over the tap device name under any vircumstances, and so the target dev name would be ignored no matter what it was. In the end this all means that you can't control what name the tap devices have (and it shouldn't matter other than cosmetic)


As for connecting the bridge device to the *host's* IP stack (which I *think* you alluded to in the subject line), that must be done outside of libvirt in the host's network config, essentially just move the IP configuration from the physical ethernet you want attached to the bridge, over to the bridge itself (removing it from the physical device).



With regards,
Daniel
this is my output:
utils-server:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
     inet 127.0.0.1/8 scope host lo
        valid_lft forever preferred_lft forever
     inet6 ::1/128 scope host proto kernel_lo
        valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
     link/ether 52:54:00:ab:30:dc brd ff:ff:ff:ff:ff:ff
8: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
     link/ether 52:54:00:6b:1b:92 brd ff:ff:ff:ff:ff:ff
10: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br1 state UNKNOWN group default qlen 1000
     link/ether fe:7f:ea:04:9d:97 brd ff:ff:ff:ff:ff:ff
     inet6 fe80::fc7f:eaff:fe04:9d97/64 scope link proto kernel_ll
        valid_lft forever preferred_lft forever
11: tap1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br1 state UNKNOWN group default qlen 1000
     link/ether fe:47:d8:75:ce:ee brd ff:ff:ff:ff:ff:ff
     inet6 fe80::fc47:d8ff:fe75:ceee/64 scope link proto kernel_ll
        valid_lft forever preferred_lft forever



--
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|







[Index of Archives]     [Virt Tools]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux