[QEMU KVM] Host-guest en guest-guest network

[tim427]

Ik heb geruime tijd een Ubuntu Servertje met KVM draaien zonder problemen (lekker stabiel en snel).

De fysieke server heeft twee NIC's van Intel, waarbij 1 gebruikt wordt puur voor de fysieke server en de tweede voor netwerk connectivity voor de VM's. Dit gebeurt d.m.v. een "macvtap" op eth1 met als source mode "VEPA".

Dit werkt allemaal prachtig, de VM's krijgen netjes een IP adres van de router (elders in het netwerk) en de performance is goed. Vanaf het netwerk zijn de VM's goed bereikbaar en vice versa.

Maar nu wil ik vanaf de VM's andere VM's kunnen benaderen en ook de fysieke server zelf. Nu weet ik dat "macvtap" de netwerk pakketjes op een relatief laag niveau injecteert op de netwerk-stack van de fysieke server en dit dus niet standaard mogelijk is.

Het probleem is op te lossen door een "internal virtual network" te maken, maar het liefst benader ik alle VM's en hosts met het IP adres dat verkregen is vanaf het echte netwerk, zodat ook DNS werkt/overeenkomt.

Iemand tips/tricks? Misschien een "virtual network" maken zonder DHCP met een bridge naar het echte netwerk (lees: geen NAT)? Als ik dat probeer (bridged met een Physical device) krijg ik de volgende error: "Error creating virtual network: XML error: route forwarding requested, but no IP address provided for network 'internet'"

Suggesties?

[gekkie]

bridgen met openvswitch ipv de standaard linux bridge ?
gebruik het zelf met Xen:
- passthrough van wifi + fysieke nict naar een VM met openwrt dat routing en dhcp regelt
- openwrt VM en andere VM's hebben allemaal een virtuele nic op openvswitch bridge

[ Voor 64% gewijzigd door gekkie op 09-04-2015 23:58 ]

[johnkeates]

Gebruik gewoon een Linux Bridge en VirtIO? Of als je extra cool wil doen een OpenVSwitch?

Een netwerk zelf heeft niks met IP adressen of subnets ofzo te maken, een virtueel netwerk ook niet.

gekkie schreef op donderdag 09 april 2015 @ 23:54:
bridgen met openvswitch ipv de standaard linux bridge ?

Dit maakt geen verschil qua bridging. De Linux Bridge doet precies hetzelfde met intern verkeer als de vswitch: het verlaat het systeem nooit als de source MAC en dest MAC op dezelfde bridge zitten.

[ Voor 49% gewijzigd door johnkeates op 09-04-2015 23:55 ]

[gekkie]

johnkeates schreef op donderdag 09 april 2015 @ 23:54:
Dit maakt geen verschil qua bridging. De Linux Bridge doet precies hetzelfde met intern verkeer als de vswitch: het verlaat het systeem nooit als de source MAC en dest MAC op dezelfde bridge zitten.

Behalve dat ik om de een of andere reden (die ik nog niet weet) dhcp niet werkend kreeg met standaard linux bridging .. met openvswitch werkte het direct. Had ook verwacht dat het op allebei zou moeten kunnen werken.

[tim427]

Nog eventjes ter verduidelijking:


Alle machines hebben een 80.x.x.x adres (vanaf internet bereikbaar) met een bijbehorende DNS verwijzing (vm01.domain.tld).

workstation01.domain.tld kan dus node01 en vm0[1-3] prima bereiken.

Alleen van node01 naar vm0[1-3], of de vm's onderling kunnen elkaar niet pingen. Dit klinkt in mijn oren best gek, aangezien alle machines op hetzelfde subnet zitten. Men (lees: ik) zou verwachten dat dit net als losse machines via de echte hardware switched (wolkje) zou gaan.

Op internet heb ik gevonden dat de netwerk packages van de VM's direct geïnjecteerd worden op de fysieke netwerkkaart. Om die reden snap ik niet dat alles door de echte switch wordt afgehandeld...

Als ik alle vibr[0-3] interfaces zou vervangen met een bridge (bridge-utils/openvswitch) kunnen ze dan wel met elkaar praten? Of geldt dit alleen voor de VM's onderling?

Volgens mij is dit helaas niet op te lossen met static routes op node01, omdat de package injection op een lager niveau zit.

[CAPSLOCK2000]

Alle VMs samen met de fysieke NIC in een bridge zetten zou moeten doen wat je wil.

De foutmelding die je krijgt begrijp ik niet. Ik zou eens kijken naar het verwijderen van het ip-adres van je NIC en/of het toekennen van een IP-adres aan de bridge.

[tim427]

De IP condiguratie op eth1 was inderdaad overbodig, maar heeft niet die foutmelding kunnen voorkomen.

Heb nu het volgende geprobeerd: Een bridge met daarbij eth1 en een "virtueel network" van KVM.

Als ik via DHCP de IP configuratie wil laten regelen voor zowel br0 danwel een VM in het virbr2, krijgen ze beide geen DHCP response. Zou wel moeten werken toch?

tim@node01:~$ sudo ovs-vsctl show
61bbcfb9-4c2d-42ef-9dd6-b49eb400eb00
    Bridge "br0"
        Port "br0"
            Interface "br0"
                type: internal
        Port "virbr2"
            Interface "virbr2"
        Port "eth1"
            Interface "eth1"
    ovs_version: "2.0.2"

[Thralas]

Euh, je kunt die macvtap interfaces gewoon op source mode 'bridge' ipv 'VEPA' zetten als het goed is?

Dat doet wat je wilt, zonder zelf te hoeven sleutelen aan bridges..

[tim427]

@Thralas, had ik al geprobeerd maar lijkt geen verschil te maken.

Damm.. Lijkt nu wel te werken!

Thanks iedereen voor het meedenken!

[ Voor 38% gewijzigd door tim427 op 10-04-2015 12:00 ]

[tim427]

Kleine update/Note to myself:

De reden waarom het voorheen niet werkte: eth1 had ook een IP-adres, na verwijderen van die netwerkconfig werkt het bridgen

[Kees]

tim427 schreef op woensdag 15 april 2015 @ 16:28:
Kleine update/Note to myself:

De reden waarom het voorheen niet werkte: eth1 had ook een IP-adres, na verwijderen van die netwerkconfig werkt het bridgen

Klopt, maar dat IP kun je vervolgens wel aan br0 hangen.

[Hero of Time]

En is ook hoe je in dit soort situaties het hoort te configureren om je fysieke NIC te kunnen gebruiken. Heb al vaak genoeg mensen hun eth? zien configureren terwijl het een slave was van een bridge. En maar klagen dat het zo slecht werkt.

[tim427]

Weer wat geleerd toch?

IP condig op eth1 was ook nergens voor nodig...