[Sammelthread] Proxmox Stammtisch

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hat Jemand von euch mal Ubuntu mit Spice ans laufen gebracht? Also so richtig mit resolution audjustment? Bei mir passt sich die Auflösung nämlich trotz installiertem qxl driver und spice-vdagent nicht an. Ich hab auch schon versucht den qxl Treiber in aktueller Version selbst zu compilen. Das hat mich leider auch nicht viel weiter gebracht, jetzt zuckt das Bild zwar jedes mal kurz nachdem ich die Fenstergröße des virt-viewers ändere aber das wars dann auch schon.
 
Hallo,

habe erst meine ersten Erfahrungen im Umgang mit Proxmox VE 3.4 machen dürfen.

Bei der Installation eines Windows Systems wird u.a. empfohlen, den Block-Geräte-Treiber IDE gegen einen VirtIO-Treiber auszutauschen.

Leider ist mir das bislang noch nicht gelungen.

Was bereits unternommen wurde:

1. Eine VM erstellt mit einem VirtIO-Bus für eine Festplatte
2. Eine Netzkarte vom Typ VirtIO
3. Bei der Installation von Windows 7 wurde der Geräte-Treiber Virtstor ausgewählt, worauf erfolgreich auf die Festplatte zugegriffen werden konnte.
4. Nach der Installation von Windows 7 den Balloon-Server und Balloon-Treiber installiert

Dennoch wird im Geräte-Manager bei den Festplatten ein Intel SB PCI-Bus-Master-IDE-Controller angezeigt.
Nur als Laufwerk wird ein Red Hat VirtIO SCSI Disk Device angezeigt.

Auf der VirtIO-CD sind noch weitere Geräte-Treiber vorhanden. Wie diese installiert werden sollen, habe ich noch nicht herausfinden können:

- pvpanic
- netkvm
- qemupciserial
- qxl
- viorng
- vioscsi
- vioserial

Des weiteren ist eine vfd-Datei auf der CD enthalten, die irgendwie im Proxmox Server integriert werden soll.

Vielleicht kann mir jemand hier den einen oder anderen Hinweis geben?
 
Zuletzt bearbeitet:
Und wo ist jetzt eigentlich das Problem? Hast du noch irgendwelche unbekannten Geräte im Gerätemanager?
Wenn du ein virt. CD-Rom dran hast, ist natürlich auch ein IDE Treiber geladen. Der Viostor ist ein SCSI-Treiber, den findest du unter "Storage Controller" im Gerätemanager.

cu
 
Hallo pumuckel,

genau danach habe ich gesucht... vielen Dank für den Hinweis. :-))

@Hauptgefreiter:
Das Problem ist, dass das System bei Festplattenzugriffen nach wie vor zu lange braucht, um Dateien zu schreiben bzw. zu lesen. Im Ressourcen-Monitor kann man dies genau beobachten. Da dauert z.B. eine Installation von einem Programm etwa 300% länger, als wenn es direkt (auf der gleichen Maschine) installiert wird.

Vor Proxmox lief auf der gleichen Hardware Windows 7 mit VirtualBox als Host und diverse andere VMs als Gast. VirtualBox bringt fertige Gasterweiterungen mit, so dass die Zugriffe dennoch performant ablaufen.

Durch die langen Zugriffszeiten entstehen bei diversen Anwendungen unnötigerweise so mancher Time-Out-Fehler bzw. IO-Fehler.
 
Zuletzt bearbeitet:
Ich hätte mal eine allgemeine Frage: kann man mehrere Proxmox-Installationen zentral verwalten ohne gleich einen Cluster anzulegen?
 
hmm. nein das geht so nicht. die weboberfläche zeigt dir nur geclusterte installationen an, soweit ich das in erinnerung habe.
 
Nur mal so am Rande, die Proxmox 4b2 läuft bei mir wirklich super, toll ist auch die LXC Unterstützung. Vor kurzem wurde auch ArchLinux hinzugefügt, es läuft alles sehr gut!
 
haben sie die Bugs bei VT_D nun gelöst ?

die beta war ja schlimm :)
 
Zuletzt bearbeitet:
Nutze die Beta Privat seit 6 Wochen läuft super soweit. VT-D habe ich noch nicht getestet.Warte noch auf meinen Sophos-AP und mit der UTM VM werde ich dann die LAN Ports direkt durchreichen.
Dauert aber noch.
 
Sind die Sicherheitsprobleme bei LXC inzwischen geloest? Mein letzter stand ist noch das es einfacher ist aus dem Container auszubrechen als bei OpenVZ.
 
haben sie die Bugs bei VT_D nun gelöst ?

die beta war ja schlimm :)

wenn Du die Reboot Probleme mit durchgereichten Controller meinst... - ja. Hatte mich dort im Forum gemeldet und es wurde prompt eine neue Komponente bereitgestellt.

- - - Updated - - -

Sind die Sicherheitsprobleme bei LXC inzwischen geloest? Mein letzter stand ist noch das es einfacher ist aus dem Container auszubrechen als bei OpenVZ.

Woher stammt die Info? Ich nutze LXC noch nicht, möchte aber meine 2 Linux VMs darauf umstellen.
 
Das habe ich immer mal in foren gelesen wo fragen zu verschiedenen container techniken aufkamen. Ist aber schon ein paar jahre her und kann inzwischen schon ganz anders aus sehen....
 
Das habe ich immer mal in foren gelesen wo fragen zu verschiedenen container techniken aufkamen. Ist aber schon ein paar jahre her und kann inzwischen schon ganz anders aus sehen....

außer in BSD Jails (und sogar da, aber sehr schwer) ist es auch jetzt noch möglich die Rechte von VMs oder Containern zu eskallieren (in allen inkl ESXi) ... ist schwerer, aber geht

viele "umgehen" sowas durch verschachtelung ala virtualization + SELinux + sVirt ... libvirt on RHEL/Fedora/CentOS (hat aber für mich nix mehr mit sinnvoller Virtualisierung zu tun, sondern nur für Consumer rented Vms)

... wobei wir beim Thema sind ... Proxmox nutzte eh nur für low to mid security, dafür ist es aber top und hier ist sicherlich keiner, der wirklich High security Lösungen nutzt (zu denen hättest du ohne feste und hinterlegte IP/Mac (per vpn) + Key + 2 Factor nichtmal den Basiszugriff ^^ und höhere Ebenen bekommen dann nen one time key jedesmal bei Nutzung für je 10-60 Minuten)
 
Zuletzt bearbeitet:
Ist es denn irgendwie möglich die Disk eines (LXC)-Containers in Proxmox zu vergrößern oder eine 2. Disk hinzuzufügen?

Danke!
 
Hallo zusammen,

Seit Jahren habe ich Proxmox im Einsatz und bin sehr zufrieden. Letzte Woche habe ich den PVE Server auf ZFS umgestellt und den Raid Kontroller (LSI 9750-4i) ausgebaut um 4 weitere Platten zu nutzen die ich hier noch liegen hatte.
Zur Zeit habe ich 4 x 1 TB Seagate Constellation ES.3 (ST1000NM0033) und 4 x 1TB Constellation ES (ST1000NM0011) als Mirror an einem M1015 HBA im IT Mode im Pool am laufen.
Leider geht mir der Platz langsam aus. Meine Frage: Kann ich die 8 Platten in eine RaidZ2 betreiben oder macht es Sinn hier 2 vdev RaidZ1 in einem Pool zu packen?
Hintergrund der Frage ist die unterschiedliche Cache Größe der Festplatten und ob das mit ZFS überhaupt eine Auswirkung hat und auch im Hinblick auf Performance ob es hier Unterschiede zwischen den verschiedenen RaidZ Levels in Verbindung mit Virtualisierung gibt.
 
Der Plattencache ist in Relation zum ZFS Arc Cache unbedeutend, das kann man ignorieren.
Wichtiger ist der Unterschied zwischen den Raid-Levels was iops angeht also wieviel kleine Lese/ Schreiboperationen pro Sekunde verarbeitet werden können.

Eine einzelne Platte kann mehrere Hundert IOs pro Sekunde verarbeiten. Macht man ein Striped Raid wie Raid 5/6 oder Z1/Z2/Z3 so verbessert sich zwar die sequentielle Leistung des Arrays, nicht aber die Anzahl der IOs die verarbeitet werden können. Das liegt daran dass für jedes einzelne IO alle Platten positioniert werden müssen.

Werden mehrere Arrays/vdevs benutzt, skaliert das mit der Anzahl der vdevs. Ein Raid 50 oder 2 x Z1 hat also die doppelte iops einer einzelnen Platten. Daher wird ein Pool aus möglichst vielen Mirror vdevs die bestmögliche iops bereitstellen. Da beim Lesen von beiden Mirrors gleichzeitig gelesen wird, ist die Lese-iops nochmal doppelt so hoch.

Als VM datastore macht daher ein Multi-Raid 1 Pool mit Platten am meisten Sinn (es sei denn man nimmt gute SSDs, die haben nämlich pro SSD > 10000 iops selbst unter Last)
 
Zuletzt bearbeitet:
Vielen Dank gea!

hab jetzt ein Pool aus 2 RaidZ vdevs erstellt. Das sollte vom Platz her erstmal reichen. Die Performance werde ich noch beobachten. Ich habe noch SSDs rumliegen. Wenn es Sinn macht werde ich ZIL und/oder L2arc einrichten.
Rein aus Neugier: Würde napp-it unter Proxmox 3.4 laufen? (Debian 7.8)

Gruß
 
Napp-it (aber nur ZFS Management) läuft unter Debian.
Der Installer setzt aber ein nacktes Debian vorraus. Ich vermute mal, dass man im Installer die Installation von ZFS erst auskommentieren muss.
 
Hallo zusammen,

als zufriedener FreeNAS Benutzer, der sich hin und wieder volle Virtualisierung wünscht um mal ernsthaft mit einem anderem OS zu arbeiten, überlege ich gerade von FreeNAS auf Proxmox zu wechseln und dabei FreeNAS in einer (K)VM laufen zu lassen. Ich nutze seit einigen Jahren FreeNAS auf einem HP N54L MicroServer und möchte mir nun ohnehin einen etwas potenteren Server als den N54L aufbauen (mehr RAM, bessere CPU). Mit der KVM-Virtualisierung hätte ich dann auch die Möglichkeit mal ein richtiges Linux oder Windows laufen zu lassen (vielleicht kann ich damit sogar das Windows vom Laptop verbannen, was wir nur wg. Elster brauchen).

Da Virtualisierung und Proxmox Neuland für mich ist (ich habe ein wenig Erfahrung mit VirtualBox, BSD-Jails und Containern), wollte ich meine Ideen hier mal vorstellen, um zu sehen, ob es sinnvoll ist oder es bessere Möglichkeiten gibt das umzusetzen.

Wie schon gesagt, möchte ich FreeNAS in einer VM laufen lassen und dieser möglichst direkten Zugriff auf die Storage Platten geben (d.h. auch ZFS wird von FreeNAS gemacht und das Proxmox-ZFS nicht genutzt). Wie reiche ich am besten die Platten an die VM durch? Soweit ich es verstanden habe muss ich das als "LVM-Group with local backing" einrichten? Geht das dann so, dass ich die ZFS-Platten auch in einen anderen Rechner stecken kann auf dem FreeNAS direkt läuft und sie direkt funktionieren, auch wenn das kein Proxomox System ist? Oder muss ich dazu den SATA-Controller per "PCI passthrough" exclusiv an die VM weiter reichen? Wie stark ist der Performance-Verlust durch die "LVM-Group with local backing" gegenüber direktem SATA-Zugriff?

Für andere VMs (Linux, Windows) würde aus diesem FreeNAS-ZFS-Pool ein iSCSI-Target als Storage freigeben. Ist das sinnvoll? Wie stark ist hier der Preformance-Verlust, wenn alles auf dem gleichen Blech läuft (ich hoffe die Daten werden dabei nicht erst über den Ethernet-Switch geleitet, da nur weil die VMs unterschiedliche IP-Adressen haben, denn sie liegen ja am gleichen Ethernet-Interface).

Zur Hardware: es soll ein HP ProLiant ML10 mit G3240 Prozessor werden, 32GB RAM, 3x4 TB Platten für den Pool, 1 SSD als Bootplatte für Proxmox, evtl. spätere Aufrüstung auf Xeon, falls VT-d benötigt / sinnvoll ist oder mehr Performance gebraucht wird.

Wichtig wäre mir, dass die Performance des virtualisierten FreeNAS nicht schlechter wird als nativ auf dem N54L, der ja nur halb so viel RAM und weniger CPU-Power hat... Evtl. werde ich dann einige BSD-Jail Appliances auf Basis eines Linux-Containers umsetzen, vorerst sollte aber alles auf FreeNAS Basis weiter laufen.

Momentan habe ich FreeNAS direkt auf einem N54L MicroServer laufen, der dann nur noch als Cold-Standby und für Backups benutzt werden soll. Von FreeNAS möchte ich vorerst nicht weg, weil ich einige gut funktionierende Jails in Benutzung habe, außerdem gefällt mir die Möglichkeit der ZFS-Synchronisation zum alten Server für Backup-Zwecke.

Vielen Dank für Eure Hilfe, Meinungen und Tipps!

Gruß
 
@luckyspiff

Kleine Erfahrung meinerseits.Mit Proxmox kann man die HD direkt durchreichen.Keine Tricks mit LVM etc. /dev/sdX wird einfach durchgereicht und sieht in der VM aus wie auf dem Host.
Ich habe 2 8TB Platten an die VM durchgereicht und kann locker mit 120+ MB/s von HD auf HD kopieren.
Das ist natürlich nicht so gut wie Controller mit pass-through, reicht aber wenn die CPU genug Power hat.
Ich würde Wetten das man damit auch dein ZFS Pool durchreichen kann.Mit Verlusten in der Performance solltest du aber rechnen.
Aber die Idee per iscsi Freigabe weitere VM´s anzubinden kann nicht der Hit werden.Latenz/Bandbreite dürfte da massiv nach unten gehen.
Und wenn du das vorhast dann nur mit Controller durchreiche an die Storage VM.
 
Zuletzt bearbeitet:
Kleine Erfahrung meinerseits.Mit Proxmox kann man die HD direkt durchreichen.Keine Tricks mit LVM etc. /dev/sdX wird einfach durchgereicht und sieht in der VM aus wie auf dem Host.
Ich habe 2 8TB Platten an die VM durchgereicht und kann locker mit 120+ MB/s von HD auf HD kopieren.
Das ist natürlich nicht so gut wie Controller mit pass-through, reicht aber wenn die CPU genug Power hat.
Ich würde Wetten das man damit auch dein ZFS Pool durchreichen kann.Mit Verlusten in der Performance solltest du aber rechnen.
Aber die Idee per iscsi Freigabe weitere VM´s anzubinden kann nicht der Hit werden.Latenz/Bandbreite dürfte da massiv nach unten gehen.
Und wenn du das vorhast dann nur mit Controller durchreiche an die Storage VM.

Danke für das Feedback, das ist sehr hilfreich!

Was muss man denn genau tun um ein Device durchzureichen, ich hab diesbezüglich keine Doku gefunden, insb. hier steht nichts dergleichen: https://pve.proxmox.com/wiki/Storage_Model? Es werden ja sicher nicht alle Raw-Devices grundsätzlich an alle Gast-VMs durchgereicht, das wäre ja viel zu gefährlich.

Ohne den LVM-Umweg wird vermutlich auch so Kram wie SMART-Überwachung aus dem Guest-FreeNAS funktionieren?!?

Dass die iSCSI-Targets für andere VMs Performance kosten, denke ich mir, wobei ich doch hoffe die Daten werden nicht tatsächlich physisch über das Ethernetkabel an den Switch geschickt, der sie dann ans gleiche Interface zurück schickt, nur weil die beiden VMs unterschiedliche IP-Adressen auf dem gleichen Netz-Interface haben? Das wird doch hoffentlich von einer Stelle im Netzwerk-Code des Host-Systems umgeleitet, bevor es an irgendwelche Ethernet-Chips geschickt wird?!

Der Grund, warum ich das so machen möchte liegt darin, dass ich so weniger Aufwand mit der Migration der Services habe, die ich momentan in diversen Jails unter FreeNAS laufen habe. Prinzipiell würde ich ja das ZFS von Proxmox nutzen, ich weiß nur nicht, ob es ebenso stabil ist wie FreeNAS und ob ich meine Jail-Appliances so einfach in einem Proxmox-Container zum laufen bekomme. Außerdem wäre mit meinem vorhandenem FreeNAS Server eine Backup-Möglichkeit vorhanden, die ich mit FreeNAS Mitteln durchführen kann.
 
Das durchreichen der HD´s geht nicht über die WebGUI.

Du muss in der Datei /etc/pve/qemuserver/(VMID).conf erledigt werden. So siehts bei mir aus.

sata0: /dev/disk/by-label/bigone,cache=writeback,size=8001562156544
sata1: /dev/disk/by-label/bigtwo,cache=writeback,size=8001562156544

Ich reiche direkt die Partition durch /dev/sdb1 und /dev/sdc1.Kannst aber auch direkt /dev/sdb etc eintragen.Besser ist aber UUID.
 
wer hier BSD mit Linux vergleicht dem sein gesagt:

BSD ist (leider) noch die Mutter der Stabilität und Entwicklung ... grad im bezug auf Sicherheit und Storage

Proxmox ist jedoch eines der besten Systeme um es in Linux umzusetzen

für die 0815 Noob Frage: nutzt Freenas mit IXSystems Hardware :)

zum passthrue tut sich grad mit 4.0 Beta viel (Deb 8.x) ... ich warte auf die stable händeringend da:

https://www.youtube.com/watch?v=6S8ABoHfzco

https://www.youtube.com/watch?v=vO-aqg0LxeI
 
Zuletzt bearbeitet:
Hi, also wenn du Dein NAS virtualisieren willst, dann empfehle ich Dir dringend das ganze mit PCI-Passthrough zu machen und dann ausgibig zu testen! Ich setze Proxmox nun auch schon ein paar Jahre ein und bin ganz zufrieden damit. Bei mir läuft Nas4Free in einer VM mit durchgereichtem OnBoard-Controller. Das kann funktionieren, muss aber nicht, deshalb einrichten und testen und zwar unter Voll-Last! Und benutze am besten ein Board mit ECC RAM.
Ich selbst möchte eigentlich weg von dieser Passthrough-Geschichte, warum? Es ist einfach eine zusätzliche Fehlerquelle. Gerade nach Kernel-Updates hab ich immer ein fllaues Gefühl ob alles weiterhin fehlerfrei läuft. Da Proxmox inzwischen ZFS direkt unterstützt, werde ich, wenn mal wieder Zeit vorhanden, den Nas4Free Pool direkt unter Proxmox einbinden. Das ZFS Management erfolgt dann eben per Konsole, wobei das echt kein Akt ist, zumindest wenn man nix exotisches macht. Um die restlichen NAS Funktionen (Freigaben SMB/AFP/DNLA) weiterhin übers Webinterface managen zu können, werde ich das Dataset unter Proxmox per NFS freigeben und in meiner NAS4Free VM mounten - im Test hat das zumindest mal funktioniert :)
 
Es gibt mehrere Gründe für mich FreeNAS weiter zu nutzen:
1. hat es sich bewährt und eigentlich immer funktioniert
2. Hab ich ein paar Jails laufen, die ich sonst auf Linux-Container oder -VMs migrieren muss
3. Inkrementelle Backups auf meinen alten Server (ok, ein Skript was mit "zfs send" inkrementell reliziert kriege ich wohl auch noch ohne GUI hin)
4. Könnte ich die ZFS-Platten bei Ausfall des Haupt-Servers dann einfach in den alten Server stecken (so sie nicht LVM "verseucht" sind)

Ich denke ich werde zunächst mal probehalber ZFS nativ auf Proxmox ausprobieren und dann über eine komplette Migration von FreeNAS weg nachdenken, von den Anwendungen, die ich auf BSD-Jails laufen habe (Logitech Media Server), gibt es die meisten ohnehin nativ für Linux, ist nur ein wenig Bastelei die Daten zu mirieren und die Endgeräte anzupassen, das hätte ich mir gerne gespart.
 
Ich habe nach über einer Woche meine zwei ZFS-Pools fertig erstellt. Der eine ist für den Hauptserver bestimmt, der andere kommt in den Microserver als Backup.
Beide Systeme sollen auf Proxmox laufen (mit der Einschränkung, dass mein Gen7-Microserver kein KVM kann).

Jetzt würde ich gerne die SSD, auf der Proxmox installiert wird, auch als ZFS cache (l2arc) nutzen. Leider wird bei der Proxmox-Installation immer LVM verwendet. Auch wenn ich mit gparted davor meine Partitionen mit /dev/sda1 für Boot (10GB, ext4), /dev/sda2 für swap (8GB, linux-swap) und /dev/sda3 für den ZFS-Cache (100GB, unformatted) anlege, wird das immer überschrieben. Ich finde keine Option, bestehende Partitionen zu verwenden.

Kennt hier jemand einen Trick, oder soll ich einfach "Debian 8 minimal" installieren und dann die Proxmox 4 beta von über die repositories draufspielen?
 

Danke trendco, dort hatte ich schon geschaut. Ich habe es nun auch mit hdsize=20 versucht, aber es wird immer ein LVM über die ganze SSD erstellt. Ich kann leider keine weitere SSD einbauen, da jeweils alle 6 SATA Ports belegt sind. 1xSSD und 5xHDD im Raidz. Ich würde nur gerne den ungenutzten Platz auf der Boot-SSD als ZFS-Cache nutzen.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh