Hardware upgrade [Intel -> AMD] icm ESXI 5 & ZFSGURU

[Vuurvoske]

Hoi allemaal,

Ik heb een redelijk complexe vraag waar ik vooraf een duidelijk beeld wil schetsen alvorens ik het ga uitvoeren.

Ik heb op dit moment de volgende situatie draaien:

Hardware:

#	Product	Prijs	Subtotaal
1	Intel Pentium G620 Boxed	€ 56,-	€ 56,-
1	Asus P8P67-M PRO (3.0)	€ 0,-	€ 0,-
1	Club3D GeForce GT 440	€ 0,-	€ 0,-
1	Samsung Spinpoint F3 HD103SJ, 1TB	€ 290,65	€ 290,65
5	Western Digital Green WD20EARX, 2TB	€ 79,99	€ 399,95
1	Cooler Master Silencio 550	€ 59,29	€ 59,29
1	Intel Gigabit CT Desktop Adapter	€ 23,20	€ 23,20
1	Kingston KVR1333D3N9/8G	€ 42,16	€ 42,16
1	Kingston ValueRAM KVR1333D3N9K2/8G	€ 59,90	€ 59,90
1	Recom RC-PE0DB580	€ 0,-	€ 0,-
Bekijk collectie Importeer producten		Totaal	€ 931,15

VMware esxi 5.1 met 3 virtuele machines:
- Ubuntu (download)
- Windows 7 (beheer machine)
- ZFSguru (opslag -> RAID5 (5x2TB)

Het grootste issue ligt bij de opzet van zfsguru, De harde schijven zitten direct op het moederbord en zijn fake weggeschreven middels de volgende handleiding:

http://vm-help.com/esx40i/SATA_RDMs.php (Kopje creating physical RDM)

Stel nu dat ik upgrade naar een AMD set:

- AMD Phenom II X4 955BE
- Bijbehorend AM3 mobo

Wat voor problemen zou dit kunnen opleveren voor de zfsguru setup? Ik heb al een keer een dikke crash / lossgehad van mijn data en ik heb weinig zin om dat nog eens mee te maken.

Alvast super bedankt voor jullie hulp / uitleg.

[CH4OS]

Ik denk niet dat het veel problemen gaat opleveren (voor de host an sich zelfs niets!). Enige waar je rekening mee moet houden, nu ik zo rondlees op het web is de virtuele hardware die de VM heeft en die de host bieden kan. Volgens mij wordt er op AMD namelijk een andere netwerkkaart gevritualiseerd dan met Intel. Hoe dat zit als je een extra PCI(e) netwerkkaart hebt geïnstalleerd weet ik niet. Hetzelfde geldt natuurlijk voor de harddisk controller die gevirtualiseerd wordt.

EDIT:
Via dit filmpje wordt een VM van een Intel based machine gemigreerd naar een AMD-based machine, binnen 2 minuten. Het kán dus echter gebruiken ze opties die ik in ieder geval níet heb binnen ESXi 5.1.

Op ServerFault wordt erover gesproken dat als je de hosts down haalt (en dus niet live migreert) dat er dan geen problemen zouden mogen zijn.

[ Voor 37% gewijzigd door CH4OS op 20-05-2013 21:31 ]

[Vuurvoske]

Bedankt voor de filmpjes, ik zal ze vanavond bekijken.

Ik maak me ook niet zo´n zorgen over de virtuele machines an sich, het gaat mij specifiek om de ZFSGURU VM. Deze heeft namelijk de schijven doorgelust. Als het goed is heb ik dalijk passthrough ondersteuning en zou ik dus de harde schijven direct kunnen toewijzen ipv wat ik eerst deed.

Wat zouden de complicaties kunnen zijn bij het veranderen van hardware? En dat ik dalijk ipv softwarematig doorwijs, de schijven in esxi zelf doorwijs ivm de nieuwe passthrough ondersteuning?

[Verwijderd]

Ik ben zelf zeer sceptisch over virtualisatie + ZFS. Er zijn veel problemen waar je tegenaan kunt lopen. Bij ESXi + RDM is bekend dat de geëmuleerde LSI-controller oudere firmware presenteert aan de guest VM. Dat levert problemen op met FreeBSD 9.1 (9.0 juist weer niet).

Uitschakelen van MSI/MSI-X interrupts is iets wat kan helpen. Maar door alle problemen met ESXi + FreeBSD ben ik erg huiverig voor dit soort setups. Veelal geldt: of het werkt prima voor je, of je hebt er veel problemen mee. Feit blijft dat je een extra laag tussen ZFS en de disks in plaatst, en dat is een potentiëel risico ook voor de integriteit van je data.

Om die reden vind ik een iets conservatievere setup met twee systemen veel beter. Eén dedicated ZFS box zonder virtualisatie, en één ESXi box die via ethernet zijn storage betrekt van de ZFS server. Dit heeft wel als nadeel dat je beperkt bent tot 1 gigabit (of 10gigabit als je veel geld over hebt). InfiniBand kan in dit geval misschien ook interessant zijn.

Virtualisatie vind ik eigenlijk pas in de kinderschoenen staan, vooral als het gaat om de guest directe controle geven over de hardware. Over 10 jaar zal dat vast en zeker allemaal veel beter werken, maar op dit moment blijf ik sceptisch over dit soort opstellingen. Je maakt het zaakje erg complex en complexiteit is vaak heel vervelend bij het uitsluiten van problemen. Juist voor je storage wil je dat eigenlijk niet.

Zelf kijk ik dan ook erg uit naar Xen en BHyVe. Daarbij kan FreeBSD zelf de hypervisor spelen terwijl ZFS dus directe toegang heeft tot de hardware. Met Xen als dom0 (host) zou je dan een mooie setup kunnen bouwen. Probleem: dom0 werkt nu nog niet voor FreeBSD, en BHyVe is nog in beginstadium van ontwikkeling. Maar dom0 wordt aan gewerkt voor FreeBSD 10 en BHyVe komen ook positieve geluiden zo nu en dan. Kortom, over een jaar of twee zal dit allemaal goed bruikbaar worden is mijn hoop. Tot die tijd moet je zorgvuldige afwegingen maken.

Het is ook maar hoeveel prioriteit je hecht aan je virtualisatie guests. Als het simpel spul is kun je eventueel ook VirtualBox overwegen. Dat is een veel minder goed virtualisatieproduct, en je moet wat dingen tunen om het stabiel te krijgen. Maar in elk geval voor de integriteit van je data lijkt mij dat een betere oplossing. Dat gezegd, ik kan prima begrijpen dat je de ESXi-route wilt biljven behouden. Het biedt op papier namelijk wel veel voordelen. Maar ik zou daarbij willen aanmerken dat het maken van een 'Plan B' geen slecht advies zou zijn, voor het geval dat je toch problemen krijgt met ESXi.

[Vuurvoske]

Ik heb flink nagedacht en er voor gekozen om stapsgewijs de hardware te upgraden. Met als eerst de processor van G620 naar I5 3330 (socket 1155).
De processor heb ik ingebouwd, en zfsguru werkt meteen. Echter willen mijn 2x linux (12.04LTS, headless) machines niet starten. Ik bedacht me toen om de optie 'upgrade virtual hardware' aan te zetten. Echter deze is nu al ruim 45mins bezig. Is dit normaal?

[ItsValium]

Verwijderd schreef op dinsdag 21 mei 2013 @ 19:53:
...

Hier ben ik het grotendeels mee eens, behalve in het geval je gebruik kan maken van vt-d. Dan lus de effectieve hardwarecontroller door naar de VM ipv gevirtualiseerde hardware aan te bieden aan de betreffende VM. Als je dan van host wisselt en natuurlijk kiest voor een nieuwe host met ook de genoemde vt-d dan zou het naadloos moeten werken.