a jinak jo, ip adresu bys mel mit na bridge, ne na slave iface

na starsich verzich proxmoxu nebyl myslim NAT nativne pustenej, novy nevim

se podivej do konzole esli je:

iptables -L
iptable -L -t nat

CHOROBA: díky za radu, snažím se přijít spíš na to co mám špatně. Někde jsem se dočetl, že nemám mít IP adresu na interface ale na vmbr, přijde mi trochu kostrbaté to upravovat tímhle příkazem. Ten proxmox přece musí umět připojit VM k internetu bez toho abych tam editoval tyhle věci? Nebo se pletu?

ABE: technicky vzato je tam oboji, viz

update-alternatives --config iptables

-legacy jsou iptables, -nft nftables ; pro ip6tables treba menit analogicky

Nenahradily v 10 iptables za nftables ?

a podivej se elsi mas povolenej forwardnig , coz asi proxmox ma
sudo sysctl -w net.ipv4.ip_forward=1

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Ahoj, rozjel jsem si proxmox na debianu 10 buster, vytvořil jsem virtuál a nedaří se mi jej připojit k netu. Virtalizace dostává IP z dhcp server, v proxmoxu jsem vytvořil bridge a dal mu statickou adresu z rozsahu lokálního (stejný rozsah jako dhcp server).

na virtuálu se mi vitvořil inteface, kterýmu jsem dal také pevnou IPku (protože z dhcp si nelízal) a jako výchozí bránu mu nastavil stejnou jako ma dhcp rozsah.

Jediný kam se dopingám je ten bridge ale tím to končí. Poradíte pls jak by to teda mělo správně fungovat? Mám přidat nějakou statickou routu na ten bridge nebo na tu virtualizaci?

díky'

RAINBOF: plus freexian dela updaty - neoficiální extended LTS (ale dela ho ten samý člověk co dosud dělal oficiální extended LTS)

MCKIDNEY: na Q35? ten je v novejch distrech (qemu 4+) imho uz by default
jdu zkusit fedoru 30 server (centos ma nejake problemy uz po instalaci)

KLEINZACH: Predpokladam ze jsi zmenil chipset v QEMU? Me bezi grafika na 99% load. jak pri mem loadu tak pri burnu. F29 a F30

KLEINZACH: u tohodle si osobne myslim, ze bude spis problem v tom, ze NECO nedoda dostatecne rychle data do grafiky, proto ztracis vykon. a to neco asi bude ICH9 virtualni chipset, grafika - passthrough, ramka - qemu si ukousne, procak - da se rict passthrough.

CHOROBA: jj - mam problem ze pri pci passthrough ztracim tretinu vykonu na gpu a uz se v tom placam druhej mesic. qemu argumenty jsem uz skoro vyloucil, zbejvaj jeste experimenty typu message signalling. devel verze (z gitu cca pred mesicem) qemu to dela taky, vyloucil jsem i guest os (win8, win10 se chovaji cca stejne). takze ted sem chtel vyloucit host os

SPIKE411: Oki, tak prosím slušně, ať to tady má nějakou úroveň. Kouknu se na staší posty, chtěl někdo něco na titulní stranu nebo ma homepage?

DELVIT: Pardon, s tím jsem začal já.

KLEINZACH: slušně, ano? Jinak rozdám ovoce na uklidněnou.

jo ty myslis na domaci smatlani a gameseni.:) tak to nevim, sem mel na tom svym premalovanym ubuntu njaky edge repo, ale to uplne nebylo ono, tgze sem si testovaci qemu vybuildil ze zdrojaku

KLEINZACH: Neříkals. Stejně jako že zkoušíš live systém. Wi-Fi taky nebejvá jedinej způsob připojení.

A spíš než to kompilovat bych se nejdřív podíval do RPM Fusion, pokud to z licenčních důvodů (nějaký Broadcom?) nemůže být ve Fedora repo.

Ty ovladače, který chceš kompilovat, jsi tam taky musel nějak stáhnout / dostat.

CHOROBA: dle uvahy 'redhat vyviji qemu, mohlo by tam byt odladenejsi nez jinde'. mam momentalne majaro a potrebuju vyzkouset neco jinyho, jestli je moje buga manjaro specificka nebo je to nezavisly na distru. proxmox sem jenom zahlid na netu, mozna zkusim

SPIKE411: rikam, ze (kurva) nemam pristup k tomu repu. musim nejdriv zkompilovat ovladace. na tom live cd jsem balicek zatim nenasel.