Zjištění stavu síťového adaptéru v QEMU

[LacconePanda]

Chci moc, když chci zjistit stav  linky virtuálního síťového adaptéru v qemu VM (na proxmoxu)? Může jít o víc typů : e1000,virtio adaptér. Začal jsem tím, že jsem nenašel getter-ekvivalent příkazu set_link net0 on/off

AI mi honosně poradila opět qm monitor příkaz 'info network' a já to sežral s navijákem,ale dal jsem ji to sežrat, že mi poradila kravinu tím že jsem ji vpálil copypaste výstupu info network s oběma příkazama on i off.
Ona uznala ,že výstupy jsou identické, tak mě vytrolila ještě radou vyčenichat to příkazem qm config VMID přítomností link_down=0|1 v parametru net0. Tomi bylo divné, volba disconnect je jen pro LXC v GUI . Sice je zmiňovaná i v chapter pro QEMU VM.Vtip je v tom, že opět ani h***. Skutečně. Na konfig to nehrabe, vypadá to, že nejde o runtime paramtr.

Třetí rada AI se nesla v podobném gardu:

Kód: [Vybrat]

  cat /sys/class/net/*166*/operstate | xargs echo
up up up unknown
#(qm monitor 166;  set link net0 jinak ; Ctrl+D)
 cat /sys/class/net/*166*/operstate | xargs echo
up up up unknown

Tak já mám pocit na spiknutí..... že konspirátoři proxmoxu udělal vše pro to aby nešlo zjistit stav linky z hypervizoura.



CHCI RADU ve které zadám číselné ID VM a název adaptéru (net0).

[Reklama]

[panpanika]

Kód: [Vybrat]

qm config $VMID | grep $INTERFACEje to normalne v dokumentaci, mozna by ses mel na robota vykaslat kdyz te tolik netesi a proste si ji precist, ale nechci ti do toho kecat

[LacconePanda]

právě že Do té dokumentace jsem se díval .
https://HOST/pve-docs/chapter-qm.html
Do které ses díval ty? Na kterém místě "to" našel?

 Krobotovi jsem se uchýlil protože jsem nepřišel na způsob jak zjistit stav adaptéru podobně jednoduše jako set_link net0 hodnota. A zase jsem se od robota odchýlil,když jsem zjistil ,že mě vláčí za nos. (cat /*/operstate  nevykazuje rozdílný obsah) a info network jakbysmet je stejný jako přeskopírák.

Jenže k čemu mi je dokumentace a rada , když výstup je identický?
qm config 166| grep net0
net0: virtio=BC:24:16:BB:97:16,bridge=vmbr0,firewall=1
#při on i off

Dokonce slovíčko down tam není nikde.

[panpanika]

mam

Kód: [Vybrat]

Virtual Environment 9.2.11

Kód: [Vybrat]

Linux proxmox-delllab 7.0.14-15-pve #1 SMP PREEMPT_DYNAMIC PMX 7.0.14-15 (2026-08-26T14:21Z) x86_64
udelam

Kód: [Vybrat]

qm config 103 | grep net0dostanu

Kód: [Vybrat]

net0: virtio=BC:24:11:74:CA:30,bridge=vmbr0,link_down=0,tag=3kdyz je adapter disconnected dostanu

Kód: [Vybrat]

net0: virtio=BC:24:11:74:CA:30,bridge=vmbr0,link_down=1,tag=3
vm s firewall on

Kód: [Vybrat]

et0: virtio=BC:24:11:E7:20:A7,bridge=vmbr0,firewall=1,tag=3ten samy s firewall off

Kód: [Vybrat]

net0: virtio=BC:24:11:E7:20:A7,bridge=vmbr0,tag=3
dokumentaci mam z https://pve.proxmox.com/pve-docs/qm.1.html#cli_qm_config
a https://pve.proxmox.com/pve-docs/pve-admin-guide.html#qm_configuration

promin mel jsem ti dat i muj cely vystup z prikazu pro porovnani, sam si to do poznamek davam.
pro uplnost kompletni vystup u mne

Kód: [Vybrat]

agent: 1
boot: order=scsi0;ide0
cores: 4
cpu: host
ide0: none,media=cdrom
memory: 8192
meta: creation-qemu=10.1.2,ctime=1776671000
name: nixos-vmstart
net0: virtio=BC:24:11:E7:20:A7,bridge=vmbr0,tag=3
numa: 0
onboot: 1
ostype: l26
scsi0: local-zfs:vm-102-disk-0,iothread=1,size=64G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=d7418538-a086-4dae-899e-e5b67ccb5fc7
sockets: 1
vmgenid: c1b357b2-b7b7-4558-bf0f-41525148b134
vestim z kristalovy koule - mas na guestovi kde to menis qemu agenta? pripadne pouzivas virtio sitovku jako ja? to muze byt rozdil, ja mam a nektery veci se propisujou az pri vypnuti/resetu vm a proto nevidis kdyz zmenis v gui link_down / disconnected?

[LacconePanda]

Kde ty v GUI vidíš / můžeš menit stav link_down? Píšeš o tom na konci postu. Já mohu měnit link state jen pro LXC("Disconnected" checkbox)  .

Jakám způsobem disconnectuješ rozhraní, když na řádku net0 máš dokonce link_down v obou případech? Já v žádném. dokonce jsem zkoušel qm config  166 --current.

Mám 9.1.6, virtio síťovku a guest tools nemám:Summary:Guest Agent not running. Napadá mě že to by mohl být důvod, že někde v GUI je tlačítko pro link state, které je mi ukryté,
Hlavně mě je divné, proč  by pro čtení link state (kéž by existoval příkaz get_link) byl nutný guest agent (jak možná naznačuješ), když pro zápis(set_link) není nutný. Navíc jde o operaci "zvnějšku"  guesta . Je to nezávislé na stavu ve správci adaptérů   Zakázat/Povolit

PS: set_link net0; je neplatný příkaz

PS: jde ti spustit nějakým způsobem z shellu proxmoxu příkaz XYZ pro qm monitor takzvaně jedním tahem? Něco jako oneliner.  Třeba kdybych ho chtěl spustit ze skriptu. Mě se to nedaří. ten příkaz qm monitor se nedá přesvědčit, aby nějak akceptoval příkaz do stdin a nějak trvá na tom, že tam musí být zadán interaktivně. Tím myslím jako napsat příkaz XYZ do web gui  - VM - Monitor do jednořádkového toho inputu a jeho provedení. Ale přes shell automatizovaně..
Něco jako
 echo xyz | qm monitor 123
 echo xyz > /dev/char/10:116 / /run/qemu-server/116.*  (něco jiného z find / -maxdepth 4 -iname "*196*" |grep -v disk)

[Reklama]

[panpanika]

ja to delam nad VM a ty na kontejnerem, v tom muze byt rozdil. kontejnery jsem na Proxmoxu nikdy nedelal, resim to az uvnitr VM.

pro VM to vidim tam kde pridavam virtualni sitovku (linkuju to z dropboxu tak snad to protece)


anebo z cli (myslim z konzole ne z monitor rozhrani, aby nedoslo k mejlce)

Kód: [Vybrat]

qm set 102 --net0 virtio=BC:24:11:E7:20:A7,bridge=vmbr0,tag=3,link_down=1pripadne

Kód: [Vybrat]

qm set 102 --net0 virtio=BC:24:11:E7:20:A7,bridge=vmbr0,tag=3,link_down=0na coz dostanu

Kód: [Vybrat]

update VM 102: -net0 virtio=BC:24:11:E7:20:A7,bridge=vmbr0,tag=3,link_down=0
monitor rozhrani nepouzivam tam ti neumim pomoc. kazdopadne z toho co jsem nacetl monitor je interaktivni rozhrani, pokud to chces skriptovat tak urcite skrz qm.

jeste jsem si vzpomnel ze mam jednu legacy appliance migrovanou jeste z ESXI (CUCM stary) takze tam mam vmxnet3 a zadny guest tools a funguje to stejne. takze tam problem asi spis nebude.

zase trochu vestim ale jestli chces do guesta psat pismenka tak to se dela takhle (coz delam do legacy CUCM co si stezuje ze nebezi na ESXI a chce odmacknout dialog )

Kód: [Vybrat]

qm sendkey ${vmid} ${key}

[LacconePanda]

To se podivuji, že až teď píšeš, že pracuješ s CT=LXC ... To pak je jiná vesnice (jak už mi bylo divnéz toho že to vidíš v GUI) přitom příkaz pct tu doteď nezazněl (za to qm vždy = mimikry) a není se divit, že si nerozumíme.


K tomu dodatku, věštíš špatně. Zrovna ses trefil do příkazu sendkey, který shodou okolností existuje ve variantě proxmox příkazu "qm sendkey" a zároveň   uvnitř Monitoru(záložka Monitor vybraného VM) přímo příkaz "sendkey". Já ale chci na dálku nebo skriptem spustit nějaký příkaz přímo do toho Monitoru.

Jako příklad info network.
Představoval bych si:
echo 196 | qm monitor 196 | grep -P ifname.+?,
Jenže se spustí qm monitor 196 bez žádného vstupu a čeká na příkazy



A zároveň poslat výstup daného commandu do pípy... To se ale blbě dělá, když znásilní /přivlastní si shell

[panpanika]

Jako příklad info network.
Představoval bych si:
echo 196 | qm monitor 196 | grep -P ifname.+?,

co by to melo udelat, jaky by mel byt vystup?

podivujes se zcela spravne protoze to spatne ctes. tys tu vytahl kontejnery a ja ti napsal ze je na proxmoxu nepouzivam... davam sem prikazy co fungujou jen nad VMkama, je to napsany i v ty dokumentaci kterou jsem ti nalinkoval.
na obrazku co ti posilam je VMko. podivej se o 3 radky nad zakrouzkovany Hardware je tam napsany "Virtual Machine".
mozna by ses na to mel vyspat a zacit zejtra s odpocatou hlavou, kazdej ma nekdy slabsi den, ja je mivam cim dal tim casteji

[panpanika]

jeste dilek do skladacky ze strany VM / qemu agenta to zjistis takhle

Kód: [Vybrat]

qm guest cmd 102 network-get-interfaces
a dostanes tohle pokud zapojeny virtio mas

Kód: [Vybrat]

[
   {
      "hardware-address" : "00:00:00:00:00:00",
      "ip-addresses" : [
         {
            "ip-address" : "127.0.0.1",
            "ip-address-type" : "ipv4",
            "prefix" : 8
         },
         {
            "ip-address" : "::1",
            "ip-address-type" : "ipv6",
            "prefix" : 128
         }
      ],
      "name" : "lo",
      "statistics" : {
         "rx-bytes" : 182520,
         "rx-dropped" : 0,
         "rx-errs" : 0,
         "rx-packets" : 2005,
         "tx-bytes" : 182520,
         "tx-dropped" : 0,
         "tx-errs" : 0,
         "tx-packets" : 2005
      }
   },
   {
      "hardware-address" : "bc:24:11:e7:20:a7",
      "ip-addresses" : [
         {
            "ip-address" : "10.1.3.103",
            "ip-address-type" : "ipv4",
            "prefix" : 24
         },
         {
            "ip-address" : "fe80::be24:11ff:fee7:20a7",
            "ip-address-type" : "ipv6",
            "prefix" : 64
         }
      ],
      "name" : "ens18",
      "statistics" : {
         "rx-bytes" : 12986709,
         "rx-dropped" : 2,
         "rx-errs" : 0,
         "rx-packets" : 162564,
         "tx-bytes" : 66463,
         "tx-dropped" : 26,
         "tx-errs" : 0,
         "tx-packets" : 763
      }
   }
]



a tohle pokud nemas

Kód: [Vybrat]

[
   {
      "hardware-address" : "00:00:00:00:00:00",
      "ip-addresses" : [
         {
            "ip-address" : "127.0.0.1",
            "ip-address-type" : "ipv4",
            "prefix" : 8
         },
         {
            "ip-address" : "::1",
            "ip-address-type" : "ipv6",
            "prefix" : 128
         }
      ],
      "name" : "lo",
      "statistics" : {
         "rx-bytes" : 182520,
         "rx-dropped" : 0,
         "rx-errs" : 0,
         "rx-packets" : 2005,
         "tx-bytes" : 182520,
         "tx-dropped" : 0,
         "tx-errs" : 0,
         "tx-packets" : 2005
      }
   },
   {
      "hardware-address" : "bc:24:11:e7:20:a7",
      "name" : "ens18"
   }
]


[LacconePanda]

Vzbuzujete ve mě paniku pane. Já celou dobu řeším VM.
Já v těch výpisech vidím jediný  rozdíl který z nich značí vytažený virtio kabel a který zapojený:
Zkusím věštit a znamená chybějcí JSON property statistics, že kabel je vypojen?

Jenže řešení nefunguje bez guest agenta!
Od začátku threadu středobod dotazu byl, jestli existuje nějaký protipól příkazu  set_link net0 hodnota , který (taky!!)nepotřebuje agenta a mohl by se jmenovat třeba get_link net0 nebo info_link_štátus net0


Síťové rozhraní může mít ip adresu i když je kabel nepřipojen (VM může být i Windows, Haiku, novomenteOS)



Příkaz monitor:

Příkaz  by měl udělat přesně to samé jako když provedu sekvenci
- spustím příkaz "qm monitor 166" # parametr je  VMID
- v něm konečně milostivě spustím příkaz "196" # to byl překlep / zavádějící, příkaz 196 neexistuje. Ale libovolný příkaz z výstupu příkazu "help", třeba "mouse_button 4"  ENter, za ním "info name" Enter
-Následované Ctrl+D - protože jak jinak se dostat z toho vězení  "qm>"

Takže

Kód: [Vybrat]

echo  echo -rn "mouse_button 4\ninfo uuid\n\0" |base64 > pepa.txt by měl programeticky  = na dálku = ne-interaktivně kliknout myší ve VM 166, a vrátit uuid mašiny a výsledek base-64 zakodovaný uložit do pepa.txt

Jenže je tam ta překážka že ve skutečnosti to takhle nefunguje, ten příkaz qm monitor nechce fungovat  tímhle způsobem, že mu do STDIN nasypu příkazy a jeho výstup si vyzvednu v STDOUT.

[František Ryšánek]

K původnímu dotazu: Koukl jsem na to zběžně u sebe na Proxmoxu 9, provozuju zatím jenom tlusté VM (nikoli LXC) a řekl bych, že ten link state prostě není propojený zevnitř ven.

Zkusil jsem brctl show. To mi ukáže, jak jsou venkovní rozhraní tap<vm_id>i<int_number> přiřazena virtuálním bridgům. Příklad jména rozhraní: tap123i0 . Tato TAP rozhraní hlásí v hostitelském PVE nějaký link state. Ukazuje ho např. ifconfig nebo ethtool, mii-tool nepřekvapivě jenom vyplázne jazyk. A ten status je vždycky "up". Teda zkoušel jsem to uvnitř VM jenom ve vindózech: dal jsem na rozhraní "disable", ale zvenčí TAP interface v PVE dál hlásí "up". Potkal jsem v internetech sporadické zmínky, že někomu tento link-state-passthrough v QEMU fungoval... inu mně na virtio síťovce v Proxmoxu 9 ve VM nefunguje. On by to na rušnějším PVE mohl být dost hukot, dmesg by bylo plné "link up, link down" od TAP rozhraní. Mimochodem tyhle per-VM vnější TAP rozhraní se vytvářejí při startu VM a zanikají při ukončení=vypnutí VM. Pokud je VM vypnutý, hledal byste jeho TAP ve výpisu "brctl show" marně.

Pár odstředivých poznámek, exponenciálně off topic:

Standardně je v PVE vytvořen jenom defaultní bridge vmbr0, do kterého koukají všechny virtuály svými "tap" rozhraními. Malá nuance: pokud v konfiguraci síťového rozhraní VMka povolíte "firewall", je mezi tap123i0 a bridge vmbr0 v hostitelském PVE vřazena ještě dvojice virtuálních rozhraní, mezi kterými zřejmě číhá firewall - a aby to šlo zpřevodovat, je tam navrch ještě maličký dedicated bridge mezi dvěma porty... Podle mého hlavním účelem toho firewallu je NAT. Pokud v daném kontextu sítě není nouze o IP adresy (v prostředí privátní sítě není problém), podle mého není třeba nechávat ten firewall na TAP rozhraních zapnutý.
 
Ten velký globální bridge (vmbr0) forwarduje nastojato VLAN tagy, takže si VMko může vzít tag jaký chce, a otagovaný traffic prostě jenom propadne na venkovní fyzický VLAN trunk celého PVE. Tag je konfiguračním atributem VM v Proxmoxu, nalepuje ho QEMU. Uvnitř ve VM se virtio-net-pci tváří jako fyzická síťovka, o venkovním tagu nemá potuchy.