Virtualbox automatisch 2.Netzwerkdevice (bridge) und Group vboxdrmipc?

[thunder11]

EDIT:
Der Stein des Anstoßes war, dass inxi zwei Netzwerk Devices glaubte zu finden.
(am Schluss dieses Postes).
Daraus ergab sich der jetzt abgetrennte Thread:

Hab mir das mal in einer VM installiert. Wen es interessiert, mal ein Paar Daten:
Interessant: Man kann 3 Fenstermanager wählen:

Die Einstellungen erschlagen einen förmlich

Nun ja jede Menge zum Spielen.
Drehende Würfel für die Arbeitsflächen hatte ich schon lange nicht mehr

Code: Alles auswählen

thunder@kanotix:~$ inxi -Fx
System:
  Host: kanotix Kernel: 6.6.13+bpo-amd64 arch: x86_64 bits: 64 compiler: gcc
    v: 12.2.0 Desktop: LXDE v: 0.10.1 Distro: Kanotix slowfire-nightly
    Slowfire64 240419a LXDE
Machine:
  Type: Virtualbox System: innotek GmbH product: VirtualBox v: 1.2
    serial: <superuser required>
  Mobo: Oracle model: VirtualBox v: 1.2 serial: <superuser required>
    BIOS: innotek GmbH v: VirtualBox date: 12/01/2006
CPU:
  Info: quad core model: Intel Core i9-9900 bits: 64 type: MCP
    arch: Coffee Lake rev: D cache: L1: 256 KiB L2: 1024 KiB L3: 64 MiB
  Speed (MHz): avg: 3096 min/max: N/A cores: 1: 3096 2: 3096 3: 3096 4: 3096
    bogomips: 24768
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
  Device-1: VMware SVGA II Adapter driver: vmwgfx v: 2.20.0.0 bus-ID: 00:02.0
  Display: x11 server: X.Org v: 1.21.1.7 driver: X: loaded: vmware
    unloaded: fbdev,modesetting,vesa dri: vmwgfx gpu: vmwgfx
    resolution: 2880x1800~60Hz
  API: OpenGL v: 4.1 Mesa 22.3.6 renderer: SVGA3D; build: RELEASE; LLVM;
    direct-render: Yes
Audio:
  Device-1: Intel 82801AA AC97 Audio vendor: Dell driver: snd_intel8x0
    v: kernel bus-ID: 00:05.0
  API: ALSA v: k6.6.13+bpo-amd64 status: kernel-api
  Server-1: PipeWire v: 0.3.65 status: active
Network:
  Device-1: Intel 82540EM Gigabit Ethernet driver: e1000 v: kernel port: d020
    bus-ID: 00:03.0
  IF: enp0s3 state: up speed: 1000 Mbps duplex: full mac: 08:00:27:da:37:59
  Device-2: Intel 82371AB/EB/MB PIIX4 ACPI type: network bridge
    driver: piix4_smbus v: N/A port: N/A bus-ID: 00:07.0
Drives:
  Local Storage: total: 20 GiB used: 6.93 GiB (34.7%)
  ID-1: /dev/sda vendor: VirtualBox model: VBOX HARDDISK size: 20 GiB
Partition:
  ID-1: / size: 18.55 GiB used: 6.93 GiB (37.4%) fs: ext4 dev: /dev/sda1
Swap:
  Alert: No swap data was found.
Sensors:
  Src: /sys Message: No sensor data found in /sys/class/hwmon.
Info:
  Processes: 216 Uptime: 5m Memory: 3.83 GiB used: 1.3 GiB (34.0%)
  Init: systemd target: graphical (5) Compilers: gcc: 12.2.0 Packages: 1741
  Shell: Bash v: 5.2.15 inxi: 3.3.26
thunder@kanotix:~$ 

Sehe gerade dass ich da 2 Netzwerk - Devices habe:

Code: Alles auswählen

Network:
  Device-1: Intel 82540EM Gigabit Ethernet driver: e1000 v: kernel port: d020
    bus-ID: 00:03.0
  IF: enp0s3 state: up speed: 1000 Mbps duplex: full mac: 08:00:27:da:37:59
  Device-2: Intel 82371AB/EB/MB PIIX4 ACPI type: network bridge
    driver: piix4_smbus v: N/A port: N/A bus-ID: 00:07.0

Wo kommen die denn her ?? Ich habe nur NAT im Manager gewählt, und keinen Bridge
Forschungsbedarf

[Livingston]

Wo kommen die denn her ?? Ich habe nur NAT im Manager gewählt, und keinen Bridge

Hängt von Deiner VM ab. Da mag sowas wie ein virtuelles Bridge-Device drankleben. Einstellungen wie NAT oder Bridge in der VM behandeln ja eigentlich nur die Logik, mit der der übergeordnete Host angesprochen wird. Du wirst jetzt wahrscheinlich auch auf Host-Seite ein TUN/TAP-Device haben, das u.U. ebenfalls über eine (virtuelle) Bridge gekoppelt ist.

[thunder11]

Hängt von Deiner VM ab. Da mag sowas wie ein virtuelles Bridge-Device drankleben. Einstellungen wie NAT oder Bridge in der VM behandeln ja eigentlich nur die Logik, mit der der übergeordnete Host angesprochen wird. Du wirst jetzt wahrscheinlich auch auf Host-Seite ein TUN/TAP-Device haben, das u.U. ebenfalls über eine (virtuelle) Bridge gekoppelt ist.

Nee - da ist nix, sonst wäre mir das schon mal aufgefallen. Habe aber in anderen VM's (Debian) jetzt nachgeschaut:
Da ist es auch so. Verstehe ich irgendwie nicht.
Im Host ist davon Nichts zu sehen:

Ich stelle bei allen VM's grundsätzlich NAT ein, weil ich nicht will, das die miteinander oder mit dem
Host quatschen können. Wenn das wirklich mal sein soll, wird eine Bridge eingestellt.
Siehe:
https://www.thomas-krenn.com/de/wiki/Ne ... VirtualBox

[Livingston]

Bin mir nicht sicher, ob inxi auch für virtuelle Devices geeignet ist.
Versuch's doch mal auf beiden Seiten mit

Code: Alles auswählen

$ ip link

und

Code: Alles auswählen

$ ip route

[thunder11]

Alles sehr seltsam. Mit ip wird dieses Device nicht gefunden:

Code: Alles auswählen

thunder@kanotix:~$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 08:00:27:da:37:59 brd ff:ff:ff:ff:ff:ff

Code: Alles auswählen

thunder@kanotix:~$ ip route
default via 10.0.2.2 dev enp0s3 proto dhcp src 10.0.2.15 metric 100 
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15 metric 100

Code: Alles auswählen

thunder@kanotix:~$ 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 noprefixroute 
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:da:37:59 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic noprefixroute enp0s3
       valid_lft 86377sec preferred_lft 86377sec
    inet6 fe80::5525:df44:17b7:474a/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Code: Alles auswählen

thunder@kanotix:~$ inxi -Nxx
Network:
  Device-1: Intel 82540EM Gigabit Ethernet driver: e1000 v: kernel port: d020
    bus-ID: 00:03.0 chip-ID: 8086:100e
  Device-2: Intel 82371AB/EB/MB PIIX4 ACPI type: network bridge
    driver: piix4_smbus v: N/A port: N/A bus-ID: 00:07.0 chip-ID: 8086:7113

Was mir aufgefallen ist: es gibt anscheinend eine neue Gruppe im Guest nach Installation der Additions:

Code: Alles auswählen

thunder@kanotix:~$ cat /etc/group|grep vb
vboxsf:x:995:thunder
vboxdrmipc:x:994:

im journal ist zu "bridge" nur das zu finden:

Code: Alles auswählen

thunder@kanotix:~$ journalctl -b|gep bridge
bash: gep: Kommando nicht gefunden.
thunder@kanotix:~$ journalctl -b|grep bridge
Apr 21 14:39:57 kanotix kernel: PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
Apr 21 14:39:57 kanotix kernel: PCI: Using E820 reservations for host bridge windows
Apr 21 14:39:57 kanotix kernel: acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended configuration space under this bridge
Apr 21 14:39:57 kanotix kernel: PCI host bridge to bus 0000:00
Apr 21 14:39:57 kanotix kernel: pci 0000:00:02.0: vgaarb: bridge control possible

Hab mal nach vboxdrmipc bei Oracle gesucht:
Fundstelle:
https://www.virtualbox.org/manual/ch04. ... ions-linux
Abs. 4.2.2.3. Graphics and Mouse Integration
Dort steht für mich unverständliches:

VBoxDRMClient runs as a root process and is a bridge between the host and the guest's vmwgfx driver. This means that VBoxDRMClient listens to screen resize hints from the host and forwards them to the vmwgfx driver. This enables guest screen resize functionality to be available before the user has performed a graphical login.

In order to perform Desktop Environment specific actions, such as setting the primary screen in a multimonitor setup, a Desktop Environment helper is used. Once the user has performed a graphical login operation, the helper daemon starts with user session scope and attempts to connect to VBoxDRMClient using an IPC connection. When VBoxDRMClient has received a corresponding command from the host, it is forwarded to the helper daemon over IPC and the action is then performed.

Hat das vielleicht etwas mit der "Bridge" zu tun, die Inxi zu erkennen glaubt ?

[Livingston]

Es wäre immer noch interessant, was auf der Host-Seite passiert. Wenn in Kanotix irgendwas emuliert wird, ist das ja schön und gut. Aber interessant ist ja, wie sich die VM auf der anderen Seite verknotet. Dazu wären die Angaben von ip l und ip r recht nützlich.

[thunder11]

Wenn in Kanotix irgendwas emuliert wird, ist das ja schön und gut. Aber interessant ist ja, wie sich die VM auf der anderen Seite verknotet. Dazu wären die Angaben von ip l und ip r recht nützlich.

Sorry hatte ich vergessen, da das im Host wie immer ist (guest läuft):

Code: Alles auswählen

thunder@XFCE:~$ ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 70:85:c2:ff:1d:d5 brd ff:ff:ff:ff:ff:ff
    altname enp0s31f6

Code: Alles auswählen

thunder@XFCE:~$ ip r
default via 192.168.0.1 dev eno1 proto dhcp src 192.168.0.40 metric 100 
192.168.0.0/24 dev eno1 proto kernel scope link src 192.168.0.40 metric 100 

[detix]

gelöscht, passt hier nicht mehr ...

[thunder11]

Warum eigentlich in einer VM installieren?
Es ist ein ISO und kann als Live-CD einfach per grub gestartet werden,

1: weil so keine Arbeit
2: noch einfacher geht es - wenn das will - per grml-rescueboot

Normalerweise installiere ich so was auch nicht, sondern schaue mal drüber und gut.

Die Frage war aber: Woher kommt dieses 2. Netzwerk- Device (bridge) im Guest
und was ist diese neue Gruppe "vboxdrmipc" bewirkt.

Edit:
Vielleicht sollte das mal doch abgetrennt werden weil das ja nichts mehr mit Kanotix zu tun hat, sondern allgemein mit Virtualbox
Wäre sinnvoll, ab hier: viewtopic.php?t=189497#p1359972
Titel: Virtualbox automatisch 2.Netzwerkdevice (bridge) und Group vboxdrmipc ?

ADMINISTRATOREN

[detix]

gelöscht, passt hier nicht mehr ...

[TRex]

Vielleicht sollte das mal doch abgetrennt werden weil das ja nichts mehr mit Kanotix zu tun hat, sondern allgemein mit Virtualbox

Bin zwar kein Admin, aber die Wunschfee für heute.

[thunder11]

Vielen Dank an die falsch titulierte Wunschfee

Im Eingangspost hatte ich das geschrieben

Sehe gerade dass ich da 2 Netzwerk - Devices habe:

Code: Alles auswählen

Network:
  Device-1: Intel 82540EM Gigabit Ethernet driver: e1000 v: kernel port: d020
    bus-ID: 00:03.0
  IF: enp0s3 state: up speed: 1000 Mbps duplex: full mac: 08:00:27:da:37:59
  Device-2: Intel 82371AB/EB/MB PIIX4 ACPI type: network bridge
    driver: piix4_smbus v: N/A port: N/A bus-ID: 00:07.0

Wo kommen die denn her ?? Ich habe nur NAT im Manager gewählt, und keinen Bridge
Forschungsbedarf

Nun bin ich etwas weiter gekommnen:
https://en.wikipedia.org/wiki/PIIX schreibt (Ich verstehe nur Bahnhof) :

PCI IDE ISA Xcelerator (PIIX), also known as Intel 82371, is a family of Intel southbridge microchips employed in some Intel chipsets. x86 virtualization implementations often support emulations of various PIIX-based chipsets.
Versions
[.....]
PIIX4

The PIIX4 introduced ACPI support, an improved IDE controller with Ultra DMA/33 or ATA-4 support and an integrated a MC146818 style RTC and CMOS controller. It was used with the 430TX and the 440LX Balboa northbridges. The PIIX4E updated the ACPI support. It was mainly used in 440BX and 440GX chipsets but 440EX, 440ZX, and 450NX chipsets also employed it. The mobile version was used in 440BX and 440ZX-M chipsets.

The following variations existed:

82371AB (PIIX4) Base
82371EB (PIIX4E) Enhanced
82371MB (PIIX4M) Mobile

[....]

Etwas weiter unten steht noch:

Related
Tick–tock model Process–architecture–optimization model Intel GPUs GMA Intel HD, UHD, and Iris Graphics Xe Arc PCHs SCHs ICHs PIIXs Stratix Codenames Larrabee

Demnach ist es wohl keine Schnittstelle, die als Netzwerk-Device genannt werden sollte.

Aber verstehen tue ich das nicht so richtig.

Interessant wäre ja noch ob das bei anderen in Virtualbox auftritt, die auch Intel Prozessoren
als Host laufen haben. Bei mir ist das jetzt in allen VM's vorhanden. Und ich bin mir (ziemlich)
sicher, dass dies erst vor kurzem ergänzt worden ist.

Genauso unsicher bin ich mir, ob irgend ein Handlungsbedarf bezüglich der Gruppe vboxdrmipc besteht:
https://www.virtualbox.org/manual/ch04. ... ions-linux

dort steht in Abschnitt 4.2.2.3. Graphics and Mouse Integration
was dazu. Muss ich nun dieser Gruppe betreten oder nicht ?

[Livingston]

Ich hab mal ein wenig nach dem ominösen Gerät gegraben. Gesucht habe ich einerseits nach "Intel 82371AB/EB/MB PIIX4" und nach der Vendor/Device-Kennung "8086:7113". Es handelt sich anscheinend um eine uralte Chipsatz-Komponente (PIIX4). Dabei stellt sich dann die Frage, was eigentlich genau mit "Bridge" gemeint ist. "Bridge" gibt es auch im Zusammenhang mit Bus-Systemen (z.B. I²C), die Chipsatz-Komponenten miteinander verkleben.
Lässt sich vielleicht damit erklären, dass VirtualBox den antiken PIIX4-Chipsatz emuliert und die Bestandteile nicht korrekt deklariert, was dann anschließend vom Kernel entsprechend falsch interpretiert wird. Mit anderen Worte: Das ist gar kein Netzwerk-Gerät.
Alles nur Vermutungen. Wahrscheinlich sollte man es mit einem österreichischen Ausspruch behandeln: "Noch nicht mal ignorieren"

EDIT: Ein paar Ungenauigkeiten begradigt