Re: Problème d'interface de type bridge qui ne répond pas aux VM VirtualBox

Liste des GroupesRevenir à fcol configuration 
Sujet : Re: Problème d'interface de type bridge qui ne répond pas aux VM VirtualBox
De : flaf (at) *nospam* me.invalid (François Lafont)
Groupes : fr.comp.os.linux.configuration
Date : 18. Aug 2022, 00:05:11
Autres entêtes
Organisation : Guest of ProXad - France
Message-ID : <62fd6618$0$9152$426a74cc@news.free.fr>
References : 1 2
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Bonsoir,
On 8/17/22 23:02, Pascal Hambourg wrote:

Probablement. A ma connaissance l'état de liaison d'un pont est lié à celui de ses "ports". Quel est l'état des interfaces pontées côté hôte ?
Et bien justement, avec Virtualbox, ça a toujours été un peu un mystère
pour moi, mais des commandes comme "ip l" ou "ip a" n'affichent jamais
aucune des interfaces pontées. Je ne sais même pas comment elles sont
définies d'ailleurs. Je serais intéressé d'avoir une explication là
dessus d'ailleurs : comment on peut afficher les interfaces pontées
que doit forcément créer Virtualbox lorsque que ses VM démarrent ?
Par exemple sur ma Ubuntu 20.04 où tout fonctionne et où j'ai en ce
moment même une VM UP et accessible (je me ssh dessus), j'ai ceci :
------------------------------------------------------------
$ 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
        valid_lft forever preferred_lft forever
2: enp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
     link/ether b0:22:7a:ff:9d:bf brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
     link/ether a4:97:b1:5f:db:6b brd ff:ff:ff:ff:ff:ff
     inet 192.168.0.138/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp2s0
        valid_lft 83342sec preferred_lft 83342sec
     inet6 fe80::25d:bcad:5217:40e0/64 scope link noprefixroute
        valid_lft forever preferred_lft forever
4: br-virt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
     link/ether 3e:eb:3a:4f:82:ac brd ff:ff:ff:ff:ff:ff
     inet 10.111.222.1/24 scope global br-virt
        valid_lft forever preferred_lft forever
     inet6 fe80::3ceb:3aff:fe4f:82ac/64 scope link
        valid_lft forever preferred_lft forever
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
     link/ether 02:42:ec:2b:8f:41 brd ff:ff:ff:ff:ff:ff
     inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
        valid_lft forever preferred_lft forever
$ sudo bridge link show
$ # n'affiche rien.
$ sudo brctl show
bridge name bridge id STP enabled interfaces
br-virt 8000.000000000000 no
docker0 8000.0242ec2b8f41 no
------------------------------------------------------------
D'après la dernière commande, aucune interface pontée sur br-virt,
alors que pourtant j'arrive à me ssh en ce moment même sur une VM
qui est UP et, d'après la GUI de Virtualbox, qui est bien bridgée
sur br-virt. Comment c'est possible ?
Et sur ma Ubuntu 22.04 où ça ne marche pas, c'est la même chose,
je n'ai trouvé aucune commande qui m'affiche le début d'une
interface pontée sur br-virt :
------------------------------------------------------------
$ 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
        valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
     link/ether 00:1b:21:dd:0b:a8 brd ff:ff:ff:ff:ff:ff
     inet 192.168.0.1/24 brd 192.168.0.255 scope global dynamic noprefixroute eth0
        valid_lft 85307sec preferred_lft 85307sec
     inet6 fe80::21b:21ff:fedd:ba8/64 scope link noprefixroute
        valid_lft forever preferred_lft forever
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
     link/ether 00:1b:21:dd:0b:a9 brd ff:ff:ff:ff:ff:ff
4: eth3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
     link/ether 18:60:24:a5:78:4a brd ff:ff:ff:ff:ff:ff
     altname enp2s0
     altname eno2
5: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
     link/ether 18:60:24:a5:78:49 brd ff:ff:ff:ff:ff:ff
     altname enp0s31f6
6: br-virt: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
     link/ether 9a:aa:18:5f:0f:ee brd ff:ff:ff:ff:ff:ff
     inet 10.111.222.1/24 scope global br-virt
        valid_lft forever preferred_lft forever
7: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
     link/ether 02:42:93:0e:6f:4c brd ff:ff:ff:ff:ff:ff
     inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
        valid_lft forever preferred_lft forever
$ sudo bridge link show
$ # n'affiche rien.
$ sudo brctl show
bridge name bridge id STP enabled interfaces
br-virt 8000.9aaa185f0fee no
docker0 8000.0242930e6f4c no
------------------------------------------------------------
Rien non plus. Avec Virtualbox, on a l'impression que les interfaces
sont cachées. Pourtant je me disais qu'avec la commande "ip" aucune
interface ne pouvait nous échapper, car il faut bien que le noyau
Linux soit au courant qu'une interface est créée, non ?
Du coup, malheureusement ça ne donne pas vraiment d'info...

Date Sujet#  Auteur
17 Aug 22 * Problème d'interface de type bridge qui ne répond pas aux VM VirtualBox17François Lafont
17 Aug 22 `* Re: Problème d'interface de type bridge qui ne répond pas aux VM VirtualBox16Pascal Hambourg
18 Aug 22  `* Re: Problème d'interface de type bridge qui ne répond pas aux VM VirtualBox15François Lafont
18 Aug 22   +* Re: Problème d'interface de type bridge qui ne répond pas aux VM VirtualBox13Pascal Hambourg
18 Aug 22   i`* Re: Problème d'interface de type bridge qui ne répond pas aux VM VirtualBox12François Lafont
18 Aug 22   i +* Re: Problème d'interface de type bridge qui ne répond pas aux VM VirtualBox4François Lafont
18 Aug 22   i i`* Re: Problème d'interface de type bridge qui ne répond pas aux VM VirtualBox3Marc SCHAEFER
18 Aug 22   i i `* Re: Problème d'interface de type bridge qui ne répond pas aux VM VirtualBox2flaf flaf
18 Aug 22   i i  `- Re: Problème d'interface de type bridge qui ne répond pas aux VM VirtualBox1Marc SCHAEFER
19 Aug 22   i `* Re: Problème d'interface de type bridge qui ne répond pas aux VM VirtualBox7Pascal Hambourg
19 Aug 22   i  `* Re: Problème d'interface de type bridge qui ne répond pas aux VM VirtualBox6flaf
19 Aug 22   i   +* Re: Problème d'interface de type bridge qui ne répond pas aux VM VirtualBox4Pascal Hambourg
19 Aug 22   i   i`* Re: Problème d'interface de type bridge qui ne répond pas aux VM VirtualBox3flaf
19 Aug 22   i   i `* Re: Problème d'interface de type bridge qui ne répond pas aux VM VirtualBox2Pascal Hambourg
19 Aug 22   i   i  `- Re: Problème d'interface de type bridge qui ne répond pas aux VM VirtualBox1flaf
19 Aug 22   i   `- Re: Problème d'interface de type bridge qui ne répond pas aux VM VirtualBox1Pascal Hambourg
18 Aug 22   `- Re: Problème d'interface de type bridge qui ne répond pas aux VM VirtualBox1Marc SCHAEFER

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal