Virtualisatie home server en router

[B2]

Naar aanleiding van Het grote thuis-virtualisatie topic leek het mij interessant om wat verder te gaan met mijn server en virtualisatie daarvan.

Het concept voor met name het virtualiseren van je router/firewall wat CAPSLOCK2000 heeft omschreven in zijn post spreekt mij erg aan en zou ik ook willen implementeren op mijn server. Één om mn kennis te verbreden en twee omdat het gewoon leuk is om te doen
Wat ik kort van CAPSLOCK2000 begrijp is dat de fysieke nic's op de kvm host geen ip adres krijgen, maar hij het adres toepast op de bridges in de guests, en via dhcp de virtuele nic's een adres geeft.

Om dit moment heb ik de volgende configuratie. Een extra Intel NIC is besteld.
Mijn machine is nu ook een kvm host, met 2 vm's om wat te spelen. Hierbij maak ik gebruik van een bridge om de vm's van netwerkconnectiviteit te voorzien, de ip's worden uitgedeeld door mn router.

#	Product
1	Toshiba MK2552GSX, 250GB
1	Western Digital Caviar Green WD20EARX, 2TB
1	Scythe Samurai ZZ
1	Noctua NF-B9, 92mm
1	Intel Core i3 2100
1	Mini-box picoPSU 120 + 84W Adapter Power Kit
1	Kingston ValueRAM KVR1333D3N9K2/8G
1	Intel Desktop Board DH67CF (B3)

Ik wil de verschillende taken die de server nu uitvoert gaan verdelen over vm's.

Virtuele machines

OS/Appliance	Functie
backup	Time Capsule via netatalk voor mn Mac's
dnsserver	Bind
firewall	tevens virtuele router, OpenVPN
jumphost	via SSH vanaf buiten bereikbaar
media	forked-daapd
webserver	Apache+toeters&bellen

Ik zou de storage centraal willen regelen en aanbieden aan de vm's. Hiervoor zit ik te denken om de 2TB disk of partities daarvan vanaf de kvm host als iscsi device aan te bieden aan de vm's en hierover heen gfs2 te draaien.
Als ik het zo bekijk zou de fysieke wan interface alleen bekend moeten zijn bij de router/firewall vm, middels port forwarding kan ik dan services van andere vm's benaderbaar maken vanaf internet.

Wat zijn jullie ideeen hierover?

[CAPSLOCK2000]

Laat ik nog wat uitwijden over mijn setup. Logisch gezien is het heel simpel:

[internet (eth0)]
|
[firewall] - [lan (eth1)]
|
[dmz (eth2)]

Een (virtuele) router/firewall met 3 (virtuele) nics dus. Op het host systeem zijn die te zien als vnet0, vnet1 en vnet2. Op het host systeem heb ik drie bridges, br0, br1 en br2. Iedere bridge bevat 1 virtuele nic. Tevens bevatten br0 en br1 ook een fysieke nic. Deze internet-nic (eth0) heeft geen eigen ip-adres. Ik draai een dhcp-client op de virtuele eth0 die een IP krijgt van mijn provider.

Laat ik het illustreren met een tripje van internet naar mijn LAN:
[internet] ->
[host-eth0] - [host-br0] - [host-vnet0] ->
[firewall-eth0]-[firewall-eth1]] ->
[host-vnet1] - [host-br1] - [host-eth1] ->
[lan]

De fysieke eth0 heeft dus geen eigen ip maar dient zuiver als verbinding naar de VM.
De fysieke eth1 heeft wel een eigen IP dat ik gebruik om die host te kunnen benaderen.
eth2/br2 is voor mijn DMZ en daar zitten uitsluitend virtuele machines in en heeft geen relatie met een fysiek nic. Die VM's kunnen dus niet direct met de buitenwereld praten maar moeten eerst langs mijn firewall.

Eigenlijk is de hele setup nog wat ingewikkelder, ik heb namelijk geen eenvoudig LAN. In mijn LAN staat nog een router/switch/accesspoint waarop ik een aantal VLANS heb aangemaakt. Die komen allemaal binnen via eth1 en worden op de fysieke host uitgesplitst en via losse bridges aan de firewall aangeboden.
Dit (oa) om te voorkomen dat de vm-host bereikbaar is voor iedereen in mijn LAN. Als je bijvoorbeeld via mijn gasten-wifi naar de vm-host toe wil moet je eerst langs de firewall.

Performance is heel redelijk te noemen. Vanuit de firewall heb ik een IPv6 tunnel lopen. Als ik die belast met mijn volle 120mbit is 1 core van mijn CPU 95% bezig maar ik haal m'n volle snelheid wel.

Mijn hele netwerk is van IPv6 voorzien dus alle VMs zijn van buitenaf bereikbaar. Voor IPv4 gebruik ik NAT om externe poorten naar een bepaalde VM door te sturen.

Ik heb (net als jij) overwogen om via iSCSI block-devices aan te bieden maar ik wilde het vanuit een VM doen. Ik wil namelijk niet dat guests met de host kunnen communiceren.
De performance bleek echter vies tegen te vallen en was veel slechter dan ik verwachte. Het was echt onwerkbaar. Misschien is dat inmiddels verbeterd. Vanuit het host-systeem kun je sowieso wel betere IO-performance verwachten.
Ik heb er toen voor gekozen om mijn schijven op de host in LVM te stoppen en hieruit partities te maken voor de guests, dat werkt uitstekend.
Je keuze voor gfs2 snap ik niet. Wil je soms dat de VM's elkaar schijven kunnen lezen? Dat lijkt me geen goed idee. Je maakt VM's juist om ze van elkaar gescheiden te houden.

Ik wil je nog even waarschuwen voor IO. De harde-schijf is op iedere computer de bottleneck. Als je meerdere VM's op 1 HD draait wordt dat een steeds groter probleem. Jij hebt gekozen voor een langzame schijf (green = langzaam). Dat kan een probleem worden. Ik voorspel dat als je een backup draait de rest van je VM's er last van heeft (als je alleen 's nachts backupped hoeft dat geen probleem te zijn).
In eerste instantie had ik twee normale (niet green) HD's in mijn server. Dat ging best een tijd goed maar vroeg of laat ontstond er een "perfect storm" waardoor alles omviel (film unparren, backup draaien, updates pushen, beetje swappen). VM's moesten soms minuten lang wachten tot ze weer wat IO konden doen. (Ik draai wel dubbel zoveel VM's maar heb ook twee schijven).
Uiteindelijk heb ik een SSD gekocht. Iedere VM krijgt een paritie op de SSD voor z'n systeembestanden en een partitie op de draaischijven voor bulk-data.


Ik ken daapd niet maar iirc is het een DLNA-server. Ik wil ook DLNA draaien op mijn media-vm en afspelen op een media-pc die drie subnetten en een accesponit verder staat. Dat lukt me niet. Als ik het goed begrijp moet ik multicast routers installeren maar daar houdt mijn kennis een beetje op.

Owja, er zit 1 groot nadeel aan deze setup: als er iets mis gaat met je firewall of je vm-host dan is alles onbereikbaar.

[ Voor 3% gewijzigd door CAPSLOCK2000 op 15-11-2011 19:55 ]

[B2]

Ben inmiddels bezig met het opzetten. Loop tegen het volgende probleem aan. Heb nu twee bridges aangemaakt op mn host, br0 zonder ip adres, br1 met een handmatig intern adres.

Wanneer ik even test met br0 of deze een ip krijgt van mn provider gaat dat goed. Nu start ik een installatie van een guest en geef ik op dat eth0 in de guest dhcp moet doen. Alleen krijgt deze nu niet het adres van mn provider. Wat stel ik nog niet goed in? Waarschijnlijk doe ik iets nog niet goed bij het opzetten van de bridge?

[CAPSLOCK2000]

Doe eens een 'brctl show' en kijk of de vnet interface wel in de bridge zit.

Het kan zijn dat je provider het MAC-adres van je netwerkkaart controleert (bestaan die nog in Nederland?).

Die van mij doet dat in ieder geval om te bepalen welk IP-adres ik krijg. Ik wilde graag het IP-adres dat ik had behouden. Ik heb toen eerst de fysieke nic een ander MAC-adres gegeven. Vervolgens heb ik het oude mac-adres ingesteld op de nic van de VM. Hiermee kreeg ik netjes hetzelfde adres terug.

[B2]

Nee, UPC controleert niet, je krijgt op elk MAC adres een ander ip adres.
Brctl show geeft netjes aan dat vnet0 en em1 in br0 zitten en vnet1, em2 in br1. In de vm worden ze ook herkend als eth0 en eth1. Eth0 is de interface die aan br0 hangt.

Eth1 gaat goed, deze heeft een vast intern adres en kan communiceren met de overige machines in mn netwerk.

Trouwens, de inhoud van mijn config files

ifcfg-br0

code:

DEVICE=br0
ONBOOT=yes
TYPE=Bridge

ifcfg-em1

code:

DEVICE="em1"
ONBOOT=yes
TYPE=Ethernet
DEFROUTE=yes
BRIDGE=br0

[ Voor 22% gewijzigd door B2 op 16-11-2011 21:27 ]

[CAPSLOCK2000]

DEFROUTE=yes lijkt me fout, maar niet de oorzaak van je probleem.
(Je default route moet via je firewall gaan lopen, dus via br1.)

Kijk eens met tcpdump op br0 en em1 of je de DHCP-pakketjes van de guest kan zien.
Zit er misschien een firewall in de weg?

[B2]

Iptables firewalls heb ik beide geflushed. (de host en de guest dus).
Ik zie op de host wel de request aankomen, maar er komt geen reply terug vanaf UPC, of de request wordt niet afgeleverd bij UPC. Veel arp requests maar verder niks. Doe ik een dhclient op br0 krijg ik direct resultaat in tcpdump te zien.

Heb nog geprobeerd om een ander MAC adres op eth0 aan te nemen, maar dat geeft ook geen resultaat. Het lijkt wel alsof de request niet weggestuurd wordt oid

[ Voor 9% gewijzigd door B2 op 16-11-2011 22:55 ]

[B2]

Hmm dit is vreemd. Wanneer ik em1 aan mn interne netwerk hang krijgt eth0 in de vm wel een ip van mn interne dhcp server.

[CAPSLOCK2000]

Moet je misschien een bepaalde hostname meesturen? Dat wilde UPC vroeger iig wel.

[B2]

mhah volgens mij niet, welke andere pc of router ik ook rechtstreeks aan het lijntje hang, gaat prima. Ik zat zelf nog iets te denken met de meerdere mac adressen (fysiek em1-bridge-virtuele eth0) Misschien dat UPC dat niet helemaal lekker vind. Volgens mij is er met de setup van de bridge niks aan de hand omdat ik wel netjes een ip krijg vanaf mn eigen interne dhcp server.

[B2]

Helaas pindakaas maar ik krijg het niet aan de praat. Op de een of andere manier krijgt mn virtuele eth0 geen dhcp offer van de upc dhcp server. Als ik het lijntje aan mn eigen dhcp server hang wel, maar daar heb ik niks aan

[CAPSLOCK2000]

Installeer dhcpdump.
Maak een dump van een direct verzoek aan UPC (dus op eth0 van de host).
Maak ook een dump van een verzoek vanuit je VM.

Vergelijk ze, er moet een verschil zijn.

[B2]

Nou geen idee waar het aan gelegen heeft, maar heb de vm maar eens opnieuw opgebouwd en niks meer aan de hand. Krijg nu netjes een IP van UPC in de vm. De vm acteert al mooi als firewall en router.

Nu bezig met de rest. Sowieso is dit nog test, ik wil nog een ssd kopen om de vm's op te zetten. Ik denk dat IO inderdaad een probleem gaat worden op deze trage schijf.

Nu wil ik een vm opzetten om m'n data te ontsluiten. Ik heb met name veel xvid en x264 spul wat nu via nfs naar m'n AppleTV gaat. Dit komt via sftp of ftps (afhankelijk van de source) binnen. Eigenlijk wil de ftp server niet op dezelfde vm zetten en deze 'data' vm ook niet toegankelijk maken vanaf internet. Daarom zat ik te denken aan gfs2. De vm waar vsftpd en ssh voor sftp op draaien zou dan dus op hetzelfde LV of iscsi device schrijven als waar de data vm vanaf leest.

Of zou hier een betere oplossing voor zijn? Inderdaad heb je dan dat de vm's niet meer 100% gescheiden zijn.
Hetzelfde verhaal voor m'n DNLA server. Het liefst zet ik deze ook op een eigen vm.

Andere vraag nog : heb jij je vm's als images of op een aparte lv voor elke vm staan?

[ Voor 4% gewijzigd door B2 op 23-11-2011 12:03 ]

[CAPSLOCK2000]

Om met je laatste vraag te beginnen, ik gebruike aparte LVs voor iedere VM.

Ik snap niet waar je een FTP server voor gebruikt als je alleen maar download, je zal wel een client bedoelen.
Aangezien je al NFS gebuikt, zou ik het daar eens mee proberen.

Ik heb ook een 'media' VM van waaruit ik dingen download. Binnen die VM draait een NFS-server waar mijn clients gebruik van mogen maken.

Ik heb eerst overwogen om een aparte NFS-vm op te zetten en die door m'n media-vm te laten mounten maar mijn inschatting is dat het irritant veel overhead geeft. Ik heb het niet getest, misschien valt het reuze mee.
Hetzelfde bezwaar heb ik tegen iSCSI gebaseerde oplossingen. Voor iedere schrijf-actie moet je over je virtuele netwerk gaan en dat kost performance. gfs2 lijkt me ook niet bijzonder snel.

Maar ik zou zeggen, probeer het uit, het is zeker mogelijk en de moeite van het proberen waard.

DLNA staat bij mij even in de ijskast wegens te ingewikkeld in mijn netwerk.

[B2]

CAPSLOCK2000 schreef op woensdag 23 november 2011 @ 12:51:
Ik snap niet waar je een FTP server voor gebruikt als je alleen maar download, je zal wel een client bedoelen.
Aangezien je al NFS gebuikt, zou ik het daar eens mee proberen.

Nee ik gebruik echt vsftpd. Er wordt op deze machine niks gedownload als in de zin van usenet o.i.d. Alles wat binnen komt gaat via FXP van andere ftp server middels ftps of gescript via sftp.

Ik heb ook een 'media' VM van waaruit ik dingen download. Binnen die VM draait een NFS-server waar mijn clients gebruik van mogen maken.

Ik heb eerst overwogen om een aparte NFS-vm op te zetten en die door m'n media-vm te laten mounten maar mijn inschatting is dat het irritant veel overhead geeft. Ik heb het niet getest, misschien valt het reuze mee.
Hetzelfde bezwaar heb ik tegen iSCSI gebaseerde oplossingen. Voor iedere schrijf-actie moet je over je virtuele netwerk gaan en dat kost performance. gfs2 lijkt me ook niet bijzonder snel.

Ik ga eens even wat testen wat voor mij het beste gaat werken.