Virtualisierung auf HP ProLiant N54L ESXi/Virtualbox

[Rockrohr]

Hallo zusammen,
ich habe mir ein kleines Projekt vorgenommen und bräuchte da ein wenig Infos ob mein vorhaben durch zu führen ist bzw. wie ich dies am besten realisiere.

Hardware:
HP ProLiant N54L
CPU: 2,2GHz Dualcore Turion
RAM: 2GB (wird ggf. erweitert)
NIC: onboard
HDD1: 32GB SSD SanDisk ReadyCache
HDD2: 2TB WD
HDD3: 2TB Samsung
HDD4: 3TB WD RED
HDD5: 3TB WD RED
Netzeil: FSP Fortron 150W

BIOS-Mod wird aufgespielt

--------------------------

KEIN RAID!!!

--------------------------

Ich möchte vier von einander unabhängige System Virtuallisieren.
1. Openmediavault (NAS): soll die SMB/CIFS bzw. NFS Freigaben verwalten bzw. weitere aufgaben erledigen
2. Debian Wheezy Minimal oder Ubuntu Server: mit Plex-Mediaserver und TV-Headend als PVR (soll einen Sundtek DVB-C USB-Tuner verwenden). Der Tuner hat eine Netzwerk Funktion damit man diesen als Virtuellen Tuner ein binden könnte, falls das durchreichen nicht funktioniert.
3. Debian Wheezy Minimal oder Ubuntu Server: mit Sabnzbd/Transmission
4. Debian Wheezy Minimal oder Ubuntu Server: zum rum spielen.

---------------------------

Openmediavault soll auf alle Festplatten und ihren Inhalt Zugriff haben (lesen/schreiben)
TV-Headend soll ausschließlich Aufnahmen tätigen, diese sollen Openmediavault verfügbar gemacht werden/sein (inkl. lese/schreiben rechte)
Sabnzbd/Transission soll seine Daten ebenfalls Openmediavault verfügbar machen (inkl. lese/schreibe rechte)

---------------------------

Resourcenverteilung:
- Openmediavault: 1 CPU / 1GB RAM
- Plex/TV-Headend: 2 CPU / 2GB RAM
- Sabnzbd/Transmission: 2 CPU / 1GB RAM
- Spielwiese: 1 CPU (50%) / 256MB RAM

----------------------------

Nun stellt sich mir die Frage wie ich das auf die Beine Stelle.
Als Basis habe ich den VM Hypervisor ESXi oder eine Debian Minimal mit Virtualbox ins Auge gefasst.

Wie man sieht ist die Anzahl der virtuellen CPUs nicht gleich der physikalischen, ebenso der virtuelle RAM.
Aus Erfahrung weis ich, dass wenn alles unter einem System läuft, 2 bis 4GB RAM völlig ausreicht und ein Dualcore ebenfalls alles bewältigen kann.

Ist es problemlos möglich mehr virtuelle CPUs bzw. RAM zu zuweisen als physisch vorhanden und wenn ja, kann sowohl der ESXi als auch Virtualbox damit umgehen bzw. die Last entsprechend verteilen.

Ist das überhaupt mit der Hardware bzw. Software realisieren!?

Wie ihr seht stellen sich mir sehr viele fragen . . . .

Freue mich über über jeden Input . . .

Danke im voraus

 

[fdsonne]

Machbar ist das schon, du brauchst aber definitiv mehr RAM...
Sprich du solltest minimum den RAM steckend haben, den die VMs zusammen wollen. PLUS etwas Reserve und natürlich das, was das Hostsystem selbst noch frisst. Beim ESXi 5.x sind das gut und gerne 1-2GB, die da sinnvoll sind.

Du kannst natürlich auch den RAM massiv überbuchen, man sollte dabei aber erwähnen, das heutige Windows und Linux Systeme idR Mechanismen verwenden, die das lokale Storage im RAM cachen -> sprich die Dinger belegen den ihnen zugewiesenen RAM idR voll oder sehr stark. -> hast du zu wenig physischen RAM stecken, wird es extremst langsam.


Bei der CPU ist das simple zuteilen in die VMs da eher kein Problem -> da die CPU Last nur dort anliegt, wenn auch wirklich eine Software oder ein Thread CPU Rechenzeit haben will. Liegt keine Last in den VMs an, idlt der Spaß und die physische CPU ist somit auch nicht oder nahezu nicht belastet


Was das Vorhaben selbst angeht, ich denke schon das du das mit ESXi hinbekommst. Zur VirtualBox kann ich nix sagen, nutze ich nicht...
Du müsstest einzig am besten vorher sicher stellen, das du A) die HDDs irgendwie an die Openmediavault VM durchgereicht bekommst -> entweder via "RDM" oder direkt den Storage Controller. (bei letzterem ist es nötig, das ein zweiter Controller existiert, der wiederum eine HDD/SSD steckend hat, wo die Konfigfiles für die VMs liegen)
Eine der HDDs wirst du aber definitiv nicht durchreichen können. Denn die VMs müssen ja ebenso irgendwo liegen und die ESXi Install muss auch irgendwo drauf

Das nächste Problem, was zu klären wäre ist die USB TV Karte -> potentiell ist es möglich, jegliche USB Geräte in die VM zu reichen. Man sollte aber den Speed mal durchtesten ob das langt (hier geht potentiell Bandbreite verloren) -> denkbar wäre ebenso, den kompletten USB Controller in die VM zu reichen, sofern der N54L Passthrought unterstützt.

Der Zugriff der anderen VMs auf das lokale Storage würden dann intern via virtuellem Switch erfolgen und somit auch recht fix gehen.

 

[Rockrohr]

Das hört sich erstmal viel versprechend an.

Dann würde ich den RAM auf 8GB erweitern, damit sollte ich erstmal auf der sicheren Seite sein.

Was das durchreichen des USB-Tuners angeht, werde ich wohl mal testen müssen.

Was den Controller für die HDDs angeht, gehe ich davon aus, dass alles SATA-Anschüsse über einen Controller realisiert sind (muss ich mal nach lesen). Falls nicht, würde ich ESXi auf einen Stick installieren und die VMs auf der SSD ablegen.

Jetzt noch eine weitere Frage.
Ich habe aktuell auf jeder der großen HDDs Daten. Gehe ich recht in der Annahme, dass diese nicht direkt von den VMs gelesen werden können, bzw. dass ich die HDDs evtl. komplett formatieren muss um sie voll nutzen zu können.

Da ich mit ESXi noch komplett unerfahren bin, wird es noch interessant ob ich das mit den virtuellen switchen hin bekomme
Aber man lernt nie aus . . .

EDIT:
Kann ich ein und die selbe HDD an mehrere VMs durchreichen!? Warscheinlich nicht oder, denn sonst könnte man den virtuellen switch weg lassen

 

[fdsonne]

den vSwitch benötigst du so oder so. Denn er ist das Bindeglied zwischen physischer Netzwerkkarte und der virtuellen Netzwerkkarte in der/den VMs. Sprich du klingst die virtuelle NIC an den vSwitch und auf der anderen Seite die physische NIC ebenso an den vSwitch -> und stellst somit erst die Verbindung her.

Zur HDD, nein das geht imho nicht. Also entweder A) via Passthrough den kompletten Storage Controller an eine VM durchreichen (dann wird aber ein zweiter Controller benötigt, der die Konfigfiles für die VMs selbst beherbergt), B) "RDM" nutzen um einzelne HDDs direkt an eine VM zu mappen (was wenn ich das richtig in Erinnerung habe auch mit schon bestehenden Daten klappt -> sofern das OS mit der Partition was anfangen kann) oder C) eben die simple Methode über VMDK Files nutzen. Die ersten beiden Versionen reichen halt direkt die Devices weiter -> beim dritten hast du den Vorteil, das der ESXi den Zugriff auf die HDD behällt und du somit eine HDD mit mehreren VMDK Files für mehrere VMs betreiben kannst. Bei letzterem muss die HDD aber definitiv mit VMFS als Filesystem formatiert werden.

 

[LichtiF]

NxxL können kein Passthrough von Hardware als gehen nur B oder C

 

[Rockrohr]

@ fdsonne

Danke für die ausführlich Beschreibung. Das mit den Switch ist nun klar, hatte fälschlicher weise angenommen es hätte was mit den HDDs zu tun.
Was die HDD geschichte angeht, werde ich also mal gucken müssen ob ich das über B) oder C) realisiere. RDM sollte klappen, da alle systeme Debian oder Ubuntu sind und mit EXT4 umgehen können.

@ LichtiF

danke für die Info, dass klärt schon mal eine haupt Frage

--------

Gibt es zwischen RDM und VDMKs einen Performance unterschied, gibt es da Erfahrungswerte!?

 

[fdsonne]

der dürfte wenn überhaupt vorhanden eher minimal sein

 

[Rockrohr]

super

Server ist gestern eingetroffen, ich mache gerade die beiden 3TB Platten frei bzw sichere die Daten und werde dann mal mit RDM testen . . .

Soweit schon mal vielen Dank für die Infos

Es werden sicherlich noch ein paar Fragen aufkommen

EDIT:

Jetzt hab doch wohl glatt übersehen, dass min. 4GB RAM für die 5.5 Version bereit stehen müssen . . . argh . . .

Naja die 8GB sind bereits geordert und solten bald eintreffen . . .

 

[s0me0ne]

Hoi Rockrohr,

und wie weit bist du mit deinem Projekt? Habe mir gestern auch einen n54l geordert und möchte mein System ähnlich aufbauen wie du.

Viele Grüße

 

[oberfranke]

Servus,

würde mich auch über einen aktuellen Stand informieren wollen..

 

[Rockrohr]

Moin.
Sry
Habs gerade erst gelesen.
Hab mich für DSM (xpenology) entschieden.