Dotaz: Virtuální server chvíli komuniuje, pak má stejnou MAC adresu

[palardd]

Mám tady takový zapeklitý problém. Guest má si změní MAC adresu sám na stejnou jako Host...

KVM. Guest a Host Linux.

Jakmile se z Host připojím přes ssh na Guest, po čase (minuty) se spojení rozpojí na konsoli hosta mám v arp -n stejnou MAC adresu pro 192.168.1.22 a 192.168.1.23. Takže, když se znova pokouším připojit do Guest (23), prakticky mě do přihlásí zpět do Host...

Popis konfigurace:

• Host 192.168.1.22 je server, funguje se SMB jak NAS
• Guest je 192.168.1.23, Linux Ubuntu. Stejný hardware. Guest funguje. Vidím konsolu, mohu s ním pracovat normálně, komunikace z guest ven super, bez problémů.
• Guest 192.168.1.23 Host 192.168.1.22
• První ssh z nějakého jiného stroje na Guest (23) je OK, v pohodě, nic se nerozpojí, ssh funguje
• Jakmile se z Guest ale odpojím a zkusím znovu, připojím se na Host nikoliv Guest, přestože se připojuji na IP adresu (23). MAC adresy jsou najendou bohužel stejné.

networkctl status br0
● 19: br0
 Link File: /lib/systemd/network/99-default.link
 Network File: /run/systemd/network/10-netplan-br0.network
 Type: ether
 State: routable (configured)
 Driver: bridge
 HW Address: 52:21:c5:53:6d:6f
 Address: 192.168.1.23
 fe80::5021:c5ff:fe53:6d6f
 Gateway: 192.168.1.1
 DNS: 192.168.1.1

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: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
 link/ether 48:5b:39:25:ae:ae brd ff:ff:ff:ff:ff:ff
 inet 192.168.1.22/24 brd 192.168.1.255 scope global enp4s0
 valid_lft forever preferred_lft forever
19: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
 link/ether 52:21:c5:53:6d:6f brd ff:ff:ff:ff:ff:ff
 inet 192.168.1.23/24 brd 192.168.1.255 scope global br0
 valid_lft forever preferred_lft forever
 inet6 fe80::5021:c5ff:fe53:6d6f/64 scope link
 valid_lft forever preferred_lft forever

 

---

---

Odpovědi

[Aleš Kapica]

Co kdybys tady místo IPv4 adres raději napsal, jak vypadá konfigurace síťových zařízení toho virtuálu?

[palardd]

host IP

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: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP mode DEFAULT group default qlen 1000
link/ether 48:5b:39:25:ae:ae brd ff:ff:ff:ff:ff:ff
29: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 52:21:c5:53:6d:6f brd ff:ff:ff:ff:ff:ff

host /etc/netplan/00-installer-config.yaml



network: version: 2
renderer: networkd
ethernets:
enp4s0:
dhcp4: no
dhcp6: no
addresses:
- 192.168.1.22/24
gateway4: 192.168.1.1
nameservers:
addresses: [192.168.1.1]
bridges:
br0:
interfaces: [enp4s0]
dhcp4: no
dhcp6: no
addresses:
- 192.168.1.23/24
gateway4: 192.168.1.1
nameservers:
addresses: [192.168.1.1]
parameters:
stp: true
forward-delay: 4

[Aleš Kapica]

Evidentně si nerozumíme.

Host, neboli hostitel má nějaké hw vybavení. A to má nějakou MAC adresu (48:5b:39:25:ae:ae).

Ovšem guest, virtualizovaný přes KVM musí mít na svém síťovém rozhraní nadefinovanou také nějakou MAC adresu. Pokud si ji nenastavíš sám, tak se o její vygenerování stará to přes co to spouštíš. Každopádně, když si na hostiteli vypíšeš proces, tak zjistíš jak tam tu síť máš vlastně nastavenou. Takhle nějak to třeba vypadá u mých strojů, jenže já nepoužívám bastl typu libvirt ale vlastní skript kvm, takže to u tebe bude vypadat určitě jinak. Ale v zásadě platí, že natavení MAC adresy virtuálu by mělo vypadat podobně. U mne je rozdíl především v tom, že nepoužívám bridge, ale openvswitch. Což je jednodušší a míň problematické.

# ps -efww | grep qemu
root     10691     1  4  2019 ?        28-13:00:51 qemu-system-x86_64 -daemonize -machine accel=kvm -name stroj -cpu kvm64 -smp cpus=2 -M pc-q35-2.6 -m 4096 -spice port=1234,password=xYz123 -vnc :3,password -qmp telnet:localhost:12345,server,nowait -monitor telnet:localhost:15678,server,nowait -device virtio-scsi-pci -drive file=rbd:onepool/piko:id=libvirt:key=AQBCW4RWZN7EBRAAKNx6v8upPJw98S1/UdG6pQ==:auth_supported=cephx;none:mon_host=host,if=none,index=0,id=ceph.0,cache=none,media=disk,format=raw -device scsi-hd,drive=ceph.0 -netdev tap,id=tap.0,ifname=interni-stroj,script=/etc/openvswitch/ovs-ifup,downscript=/etc/openvswitch/ovs-ifdown -device virtio-net-pci,mac=be:be:be:00:12:34,netdev=tap.0 -netdev tap,id=tap.1,ifname=main-stroj-1,script=/etc/openvswitch/ovs-ifup,downscript=/etc/openvswitch/ovs-ifdown -device virtio-net-pci,mac=be:be:be:01:12:34,netdev=tap.1 -serial file:/var/log/stroj.serial

Třeba ti pomůže v orientaci moje manuálová stránka KVM (konfigurace sítě)

[palardd]

Děkuji za referenci na manuál. Nerozumíme si proto, že jsem se ptal, jak je možné, že se mi MAC adresy po čase sjednotí. Ostatní věci myslím jsem schopen "pobrat" Kde může být chyba?

[Aleš Kapica]

To je dané tím jakou máš konfiguraci toho virtuálu. Když o ní nic nevíme, těžko ti poradíme. Každopádně jak napsal trekker o kus níže – máš tam něco nastavené blbě.

[trekker.dk]

Sice neznám ten udělátor, který na tu síť používáte, ale tohle všechno je výpis z hostitele?

host IP

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: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP mode DEFAULT group default qlen 1000
link/ether 48:5b:39:25:ae:ae brd ff:ff:ff:ff:ff:ff
29: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 52:21:c5:53:6d:6f brd ff:ff:ff:ff:ff:ff

host /etc/netplan/00-installer-config.yaml



network: version: 2
renderer: networkd
ethernets:
enp4s0:
dhcp4: no
dhcp6: no
addresses:
- 192.168.1.22/24
gateway4: 192.168.1.1
nameservers:
addresses: [192.168.1.1]
bridges:
br0:
interfaces: [enp4s0]
dhcp4: no
dhcp6: no
addresses:
- 192.168.1.23/24
gateway4: 192.168.1.1
nameservers:
addresses: [192.168.1.1]
parameters:
stp: true
forward-delay: 4

Jestli to tak je - a podle toho networkctl nahoře to fakt vypadá, že jo - tak máte v hostiteli na síťovce enp4s0 IP adresu 192.168.1.22 a tu síťovku máte zároveň jako port bridge br0, který má svoji IP adresu 192.168.1.23. Pokud to tak je, tak není otázka, jaktože se vám ssh na druhý pokus připojuje k hostiteli, ale jaktože se vám vůbec daří připojit do toho hosta.

Máte to přinejmenším hodně divně (skoro by se chtělo říct, že to máte blbě ) Pokoušel jste se dělat něco speciálního? Nebo chcete jenom to, aby host byl zapojený ve stejné síti jako hostitel? Pokud vám stačí toto, tak se to dělá jinak:

• fyzická síťovka zůstane bez IP adresy a jen se přiřadí jako port toho bridge.
• Bridge dostane IP adresu hostitele.
• Pro virtuál se vytvoří virtuální síťovka - typicky TAP - a taky se vřadí jako port do toho bridge
• Na straně hostitele to TAP rozhraní taky nemá žádnou IP adresu
• Hypervizor si to TAP rozhraní vezme a prezentuje jej hostu jako nějaký (virtuální) hardware
• IP adresa hosta se nastaví v něm - v jeho operačním systému

Důvod, proč jsou MAC adresy stejné, je to, že pokud si nenastavíte jinak (a se systemd mám pocit, že musíte ještě něco někde přepnout), tak se adresa bridge mění podle nejnižší MAC adresy ze všech portů toho bridge. Ale to každopádně není příčinou vašeho problému.

Jinak s tím odkazovaným návodem bych byl opatrný, jestli jste začátečník, tak vás to akorát zmate

[Aleš Kapica]

Rozhodně zmate tebe, protože uvažuješ jinak. Psal jsem ho v době, kdy jsem si sám potřeboval udělat jasno.

Moje zkušenost je taková, že pokud začátečník není líný a věnuje alespoň trochu času aby se nejprve podíval co kdo o tom napsal, tak zmatený není. Zmatený je jen ten, kdo zásadně nečte dokumentaci.

Kdyby sem dotyčný uvedl s jakými paremtry mu běží to qemu, tak bychom byli hned o kus chytřejší. Přinejmenším by z toho bylo jasné přes co toho guesta spouští. Je totiž možné že se některé parametry nastavují až dodatečně přes monitorovací či qmp konzoli, jenže těžko ho nasměrovat, když není jasná ani tak banální věc, jestli spouští to qemu přímo, nebo přes libvirt.

[trekker.dk]

Moje zkušenost je taková, že pokud začátečník není líný a věnuje alespoň trochu času aby se nejprve podíval co kdo o tom napsal, tak zmatený není.

Nicméně pokud začátečník začne vaším návodem, bude zmatený ještě víc než předtím. Ta vaše wiki je nepřehledná, půlka věcí je obsolete, ovšem na těch vysvětlujete principy. Prostě klasický poznámkový blok typu "jak jsem to tenkrát dělal já", nikoliv materiál pro učení.

[Aleš Kapica]

Není to tutoriál. Šlo mi o to ukázat rozdíly a tam se toho zase tak moc nezměnilo.

Každopádně tenhle dotaz nevyřešíme, dokud tazatel neudělá to co jsem psal výše. Nebo máš snad pocit, že i tak banální věc jako je vypsání procesu je matoucí?

[ET]

Nechte bys na test vytvorit dalsiho/novyho guesta (idealne ne-ubuntu), jestli se bude chovat stejne? Dalo by se tim castecne vyloucit, jestli je to guest-specific problem

[Aleš Kapica]

Odpovím si sám. Pro bridgovane řešení je toto nastavení špatně.

Rozhraní br0 je samozřejmě primární, takže to mám mít IP adresu Hosta Guest si své IP rozhraní nastavuje uvnitř sebe a na venek chodí přes br0 Takže správně má být:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp4s0:
      dhcp4: no
      dhcp6: no

  bridges:
    br0:
      interfaces: [enp4s0]
      dhcp4: no
      dhcp6: no
      addresses:
        - 192.168.1.22/24
      gateway4: 192.168.1.1
      nameservers:
        addresses: [192.168.1.1]
      parameters:
        stp: true
        forward-delay: 4

[trekker.dk]

Odpovím si sám.

Sám, den poté, co jsem vám to samé napsal

[Aleš Kapica]

Tak o to snad nejde, ne? Důležité je, že přišel na to jak to má vyřešit.