> Sent: Monday, October 28, 2024 at 4:35 PM > From: "Laine Stump" <laine@xxxxxxxxxx> > To: "daggs" <daggs@xxxxxxx>, berrange@xxxxxxxxxx > Cc: users@xxxxxxxxxxxxxxxxx > Subject: Re: reconfiguring a two vms bridge to two vms + the host with proper iface naming > > 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. you are correct, my bad > > >> 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), correct again.... > 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). not sure I follow, the bridge has no physical ethernet, it has 3 taps. tap0 for vm1, tap1 for vm2 and vnet0 for the host which I create and attach to the bridge using the commands stated in the original mail. but vnet0 is reporting No Carrier > > >> > >> > >> 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 :| > >> > >> > > > >
