Was habt ihr für Arbeits-PCs/Laptops?
-
Software ist bei uns quasi dem Entwickler überlassen. Viele verwenden Eclipse, viele Visual Studio, ein paar XCode. Vermutlich noch 1-2 weitere die von ein paar ganz wenigen verwendet werden.
OS ist ebenso wahlfrei, Windows, OS X oder irgend ne Linux Distro.
Ich verwende Visual Studio, weil ich es schon lange kenne und halbwegs angenehm finde. Linux Builds probiere ich mit GCC über "Bash on Ubuntu on Windows" aus. Das geht ganz gut. Nicht wirklich schnell, aber erträglich. Und ich muss nicht blöd rum-syncen oder mit VM Shared Folders rummachen.
VM brauche ich dadurch meistens keine. Die meisten Entwickler die mit Linux arbeiten haben allerdings ne Windows VM wo dann Visual Studio drauf ist, damit sie Windows Builds machen können (und ggf. debuggen).
Für AIX, Solaris, Linux PPC etc. haben wir Maschinen wo sich jeder Entwickler einloggen kann (Ad-Hoc Tests, Debuggen etc.) bzw. über fertige Scripts Remote-Build auf diesen Systemen ausführen kann.
Und wenn sehr spezifische VMs (spezielle OS Versionen) benötigt werden haben wir für x86 Zeugs noch OpenNebula wo man sich relativ unkompliziert und vor allem schnell was zusammenklicken kann. Für die "Exoten" ist was Ähnliches in Planung.
schlepptopp schrieb:
Benutzt ihr VMs? Irgendwie schreckt mich bei den etwas die langsame I/O ab - macht ja eigentlich den SSD-Vorteil fast wieder zunichte.
Was man so liest, und was sich mit meiner (begrenzten) Erfahrung deckt, ist die IO Performance bei Hyper-V sehr gut -- zumindest wenn man "fat" provisionierte VHDX verwendet (=*nicht* dynamisch). Dafür ist die "Integration" halt Kacke wenn man z.B. Linux als Gast verwendet. Also so Sachen wie Shared-Clipboard ... tjo, Pech, geht halt nicht. (Windows Gäste hauen aber echt super hin.)
VirtualBox scheint dagegen wirklich recht lahm zu sein was IO angeht.
-
hustbaer schrieb:
schlepptopp schrieb:
Benutzt ihr VMs? Irgendwie schreckt mich bei den etwas die langsame I/O ab - macht ja eigentlich den SSD-Vorteil fast wieder zunichte.
Was man so liest, und was sich mit meiner (begrenzten) Erfahrung deckt, ist die IO Performance bei Hyper-V sehr gut -- zumindest wenn man "fat" provisionierte VHDX verwendet (=*nicht* dynamisch). Dafür ist die "Integration" halt Kacke wenn man z.B. Linux als Gast verwendet. Also so Sachen wie Shared-Clipboard ... tjo, Pech, geht halt nicht. (Windows Gäste hauen aber echt super hin.)
VirtualBox scheint dagegen wirklich recht lahm zu sein was IO angeht.
Dafür gibt's doch die IOMMU-Virtualisierungsfunktion in Hardware (Kurz VT-d).
Wozu soll man also noch in Software virtualisieren, wenn es die CPU viel performanter kann?VirtualBox oder Co braucht man dann nur noch als Klebstoff dazwischen.
-
Tobiking2 schrieb:
Da vergehen am Anfang des Tages schon mal 15-20 Minuten bis man loslegen kann.
Kannst du nicht den Rechner in den Ruhezustand (bzw. Energiesparmodus) versetzen (anstatt komplett runterzufahren)? Habe ich bei meinem letzten Rechner auch immer so gemacht (nur wenn dann wieder ein Windows-Update mit Neustart anstand, hatte ich mal wieder eine längere Frühstückspause...).
-
Xeon E5-1560 v3 / 3,5 Ghz
64 GB RAM
1x SSD 1TB
1x SSD 500GB
GF GTX 970
2x 24'' FullHDProzessorkerne idlen oft darum, aber Graka koennte schon noch besser sein.
-
Hardwarevirtualiser schrieb:
Dafür gibt's doch die IOMMU-Virtualisierungsfunktion in Hardware (Kurz VT-d).
Wozu soll man also noch in Software virtualisieren, wenn es die CPU viel performanter kann?VirtualBox oder Co braucht man dann nur noch als Klebstoff dazwischen.
Mit "IO" hab' ich hauptsächlich (local) Disk IO mit virtual HDD Files (VHD, VMDX, ...) gemeint.
Da muss der Hypervisor Zugriffe auf die virtuelle HDD/SSD des Gastsystems in Zugriffe auf ein virtual HDD File übersetzen. Speziell bei dynamisch wachsenden virtual HDD Files ist das sehr aufwendig.Das ist wesentlich mehr als nur "Kleber" zwischen zwei Hardwareteilen.
Soweit ich weiss kann dir eine IOMMU dabei nicht mal helfen - die hilft nur wenn Hardware 1:1 an ein Gast-System "weitergereicht" wird. Diesen Teil des Problems löst man bei Disk IO sehr gut durch spezielle Treiber. Die plaudern dann über spezielle Interfaces "direkt" mit dem Hypervisor. Was quasi den ganzen Overhead der simulierten Hardware entfernt.
-
hustbaer schrieb:
Hardwarevirtualiser schrieb:
Dafür gibt's doch die IOMMU-Virtualisierungsfunktion in Hardware (Kurz VT-d).
Wozu soll man also noch in Software virtualisieren, wenn es die CPU viel performanter kann?VirtualBox oder Co braucht man dann nur noch als Klebstoff dazwischen.
Mit "IO" hab' ich hauptsächlich (local) Disk IO mit virtual HDD Files (VHD, VMDX, ...) gemeint.
Da muss der Hypervisor Zugriffe auf die virtuelle HDD/SSD des Gastsystems in Zugriffe auf ein virtual HDD File übersetzen. Speziell bei dynamisch wachsenden virtual HDD Files ist das sehr aufwendig.Das ist wesentlich mehr als nur "Kleber" zwischen zwei Hardwareteilen.
Soweit ich weiss kann dir eine IOMMU dabei nicht mal helfen - die hilft nur wenn Hardware 1:1 an ein Gast-System "weitergereicht" wird. Diesen Teil des Problems löst man bei Disk IO sehr gut durch spezielle Treiber. Die plaudern dann über spezielle Interfaces "direkt" mit dem Hypervisor. Was quasi den ganzen Overhead der simulierten Hardware entfernt.
Mit IOMMU kannst du eine Hardware, z.B. ein Festplattencontroller direkt an das Gastsystem weiterreichen und das kann dann darauf natürlich direkt, also raw zugreifen.
Wo ist da jetzt die Performancehürde?
-
Hardwarevirtualisierer schrieb:
Mit IOMMU kannst du eine Hardware, z.B. ein Festplattencontroller direkt an das Gastsystem weiterreichen und das kann dann darauf natürlich direkt, also raw zugreifen.
Wo ist da jetzt die Performancehürde?Klar kann man das, hab ich ja geschrieben. Tut man bloss nicht, weil es nicht praktikabel ist. Du willst nicht pro VM einen eigenen SATA Controller + eigene SSD einbauen. Du willst das über virtual Disk Files machen. Und da hilft dir die IOMMU nicht, und genau da ist dann das Performanceproblem. Oder eben auch nicht (bzw. kaum), wenn man paravirtualisierte Treiber + preallocated virtual Disk Files verwendet.
Klar, du kannst sinnfreie realitätsfremde Beispiele bringen und dann behaupten dass es dabei keine Performanceeinbussen gibt. Die Behauptung mag dann stimmen, nur ist sie halt eben sinnfrei und realitätsfremd.
-
Man könnte die Datenträger auch via iSCSI einbinden und die Datenträger direkt auf dem Hostrechner verwalten, auf dem auch die VM ausgeführt werden.
-
Klar. Aber wozu? Meinst du dass das schneller ist als über nen paravirtualisierte Treiber?
Was funktionieren kann ist wenn man über iSCSI geht, die virtuellen Disks aber von einem echten iSCSI Storage verwalten lässt. Nur dann braucht man - vorausgesetzt es gibt mehr als nur 1-2 Entwickler die das machen wollen - ne richtig dicke Netzwerkinfrastruktur und nen ebenso dicken iSCSI Storage.
-
hustbaer schrieb:
Klar. Aber wozu? Meinst du dass das schneller ist als über nen paravirtualisierte Treiber?
Was funktionieren kann ist wenn man über iSCSI geht, die virtuellen Disks aber von einem echten iSCSI Storage verwalten lässt. Nur dann braucht man - vorausgesetzt es gibt mehr als nur 1-2 Entwickler die das machen wollen - ne richtig dicke Netzwerkinfrastruktur und nen ebenso dicken iSCSI Storage.Die Disks sind nicht virtualisiert, sondern echte Platten, die per iSCSI in die VM eingebunden werden.
Eine Netzwerkinfrastruktur brauchst du da auch nicht, das Zeug läuft über ein virtualisiertes Netz auf dem gleichen Rechner. Also maximale Bandbreite.
-
Womit wir wieder bei sinnfrei wären. Ich will nicht eine SSD/HDD pro VM in meinem Rechner haben.
Und selbst wenn, wäre direkter Zugriff auf diese via paravirtualisiertem Treiber sicher schneller als wenn man sinnlos über iSCSI geht.Ich weiss aber ehrlich gesagt nicht worüber wir hier eigentlich diskutieren. Worum gehts? Ist doch alles vollkommen realitätsfremd.
