9:35 a.m.
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(a)redhat.com>
> To: "daggs" <daggs(a)gmx.com>
> Cc: users(a)lists.libvirt.org
> 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 :|
>
>