Virtulizáció PCI PASSTHROUGH-val

Virtualizáció

Sziasztok!

Kísérleti rendszer összeállítása előtt állok, konkrétumok nagyon nincsenek még, így általános a kérdés, nagyjából általános válaszokra is számítok :)
A feladat a következő lesz: adott egy HW 12 CPU 128GB memória, Dell Precision. Jelenleg csak kis office szerverként fog üzemelni, de később kerülhet rá egy két GPU igényes alkalmazás.
Az elejétől tervezem hogy virtualizációs platformot teszek rá, azonban a GPU alkalmazások miatt kelleni fog a PCI PASSTHROUGH.
Eddig ezzel sajnos nem volt tapasztalatom (kivéve amit meg sem említek: Virtual Box, stb. desktop megoldások)

Jelenleg használok pár gépen Proxmox-ot, elvileg ez is tudja.
Ami felmerült:
1. ESXi (én személy szerint nem szeretem, volt szerencsém a webes külön gépes managementjéhez is, szerintem amennyire drága annyira nem jó.)
2. Proxmox. Előny hogy csak a support fizetős, hátrány: nem tudom hogy ezzel működik-e megfelelően.
3. Oracle VM Server for x86. Előny: ahogy látom free, a support fizetős. Hátrány: egyelőre nem tudtam letölteni (hiába free, access denied az accountomban), nem ismerem egyáltalán, "külső management" felületet használ, akárcsak az ESXi.
4. XEN. Nincs tapasztalatom vele.

Tudom hogy nagyon általános a kérdés, de szerencsére időm lesz a kísérletezésre, szívesen kitapasztalnék egy új megoldást is. Nekem valamiért az Oracle szimpatikus, de a Proxmoxban jobbban otthon vagyok. Szívesen vennék pár hozzászólást a tapasztalataitokról a PCI Passthrogh terén.

(Persze felemerült az is, ha igazán komoly GPU igényes alkalmazás kell, akkor legyen a gép dedikáltan az övé, a többi kis office cuccot meg tegyük ki valami olcsó de redundáns vasra)

  • 4220 megtekintés

( htmm v | 2016. 09. 08., cs – 10:58 )

Lehet, hogy erdemes lenne megnezned a XenServert, az tud GPU passthrough-t is (es neked pont az kell), igaz nekem meg nem volt ra szuksegem.

--
http://blog.htmm.hu/

Volt már téma itt a hup-on évekkel e fórumtéma után. Akkor már volt sok remek howto, wiki leírás. "Hivatalos" út a drága szerver alaplap amit támogat pár kereskedelmi virtualizációs szoftver, pl vmware. Otthonra nem igazán éri meg. Számtalan home pc kategóriájú alaplap is megfelel, itt az egyetlen út a KVM. Kulcsszó IOMMU támogatás. Lista konfigurációk összeállításához: https://passthroughpo.st/vfio-increments/

Setup guide: https://gist.github.com/0chroma/ed9590f4c79daaeb482c2419f74ed897

Részletes wiki oldal a témában Arch wikin: https://wiki.archlinux.org/title/PCI_passthrough_via_OVMF

Ha a videókat kedveled: https://www.youtube.com/watch?v=3yhwJxWSqXI

https://www.youtube.com/watch?v=HXgQVAl4JB4

de azért ajánlom elolvasni az szöveges linkelt tartalmakat. 

Egy cikk a témában: https://www.erianna.com/amd-ryzen2-pci-passthrough-vfio-libvirt-ubuntu1…

Másik cikk a témában: https://www.heiko-sieger.info/running-windows-10-on-linux-using-kvm-wit…

amikor megtaláltam már megépítettem a saját vfio pc-met. Ez 2 éve volt, azóta teszi a dolgát. Szerintem azóta nem történt grandiózus változás, de érdemes időt szánni a mai friss cikkekre. Bár a fenti anyagok is elégségesek a témához. 

( wpeople v | 2016. 09. 08., cs – 12:10 )

Xen alatt tutira megy a PCI Passthru. Ugyan én NIC-et pass-oltam thru, nem GPU-t, de jól ment :-)

A cél az, hogy a VM (DomU) tudja használni a gépbe rakott kártya GPUját számolásra?

( kanalaslaci | 2016. 09. 08., cs – 12:26 )

Qemu KVM-el sikerült összehoznom. A host rendszerem debian, windows 7 64 bitet tettem guestnek. A gépben 2 GPU van, egy ATI illetve egy NVIDIA. Blacklistre kell tenni guesten használni kívánt GPU a kernel modulját, hogy ne töltse be alapból rendszer.
Guest Windows 7 rendszer alatt toltam végig a GTA V-t :)

Proxmox alatt én USB Passthrough-t használok, az rendben teszi a dolgát.

( •̀ᴗ•́)╭∩╮

"speciel a blockchain igenis hogy jó megoldás, ezért nagy erőkkel keressük hozzá a problémát"
"A picsat, az internet a porno es a macskas kepek tarolorandszere! : HJ"

Az élet ott kezdődik, amikor rájössz, hogy szart sem kell bizonyítanod senkinek

Ha meg akarod nevettetni Istent, készíts tervet!

( szekelyk | 2016. 09. 08., cs – 12:25 )

A 3. és 4. ugyanaz (az Oracle VM is Xen alapú), tehát a lista csökkent, hacsak nem nézed meg a Hyper-V és a KVM virtualizációs rendszereket is.

( nydn | 2016. 09. 08., cs – 14:12 )

QEMU-KVM-et használok Arch Linux-on VFIO driver-rel, a guest egy Windows 7 64bit Professional. Csak játékra használom Steam Big picture módban + Steam Controller is továbbadva, a kezdeti nyűgök után most már jól teljesen jól működik.
i5 4460
Asrock H87M Pro4
Nvidia GTX 750

Nálam az integrált gpu-t használja a host.

Illetve tesztelés alatt van FreeBSD 11, kiváltani az Arch Linux-ot. bhyve, PCI passthru, viszont ez nagyon nem akar összejönni egyelőre.

A PCI passthru még nagyon kezdeti állapotban van szerintem és sok a munka vele, de szerencsére foglalkoznak vele, bízom benne,hogy jövő ilyenkorra képes lesz kiváltani a linux host-ot. Olyan sokat még nem tudtam tesztelni, sajnos,amire eddig jutottam, azt itt el tudod olvasni: https://github.com/chyves/chyves/issues/3
Esetleg saját tapasztalatot is beküldhetnél :)

Ahogy hallottam, egyes játékok anti-cheatjei nem engedik a virtuális gépezést. A FreeBSD + bhyve meg nem erre való, hogy játékgépet virtualizálj, szerveres dolgokra van.

Bár ha csak játékra használod a gépet, tényleg lehet egy olcsó kulcsos Win10-zel jobban járnál. Tudom, nagy MS haterként ezt furcsa pont tőlem hallani, de ennél a fajta speciális felhasználásnál lehet értelme. Nálam is van egy ilyen asztali játékgép, pont ilyen Win10-zel (Pro, 64 bit, mi más), semmi más nem megy rajta, néha napján van megjáratva, csak játék (Steam, GOG Galaxy, stb. kliensekkel). Semmi munka, böngészés, semmi fontos/érzékeny adat tárolása, stb.. Lényegében PC formfactor játékkonzol (de kontroller helyett ragaszkodok a bill+egér kombóhoz), erre a felhasználásra elmegy a Dóz, kvázi firmware-ként használva, mármint pain in the ass, de kibírható, működik, ráadásul minden natív sebességgel fut, mivel nuku emuláció, 0 virtualizáció, minden másik gépen csakis Linux megy természetesen, szintén zenész, szintén Arch, évek óta. Néha játszok azokon is, natív és protonos játékokkal, amik nem olyan hardverigényesek, és elfutnak normálisan.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( LMoon | 2016. 09. 08., cs – 13:23 )

Régebben mintha CPU + chipset (VT-d v. IOMMU) támogatás is kellet volna a PCI Passthrogh -hoz. HW támogatással réges régen a XEN tudta.

( Dolpa | 2016. 09. 08., cs – 17:55 )

Hali,

Én tavaly nyáron döntöttem el, hogy az itthoni szervereket és a desktopot lecserélem 1 nagy szerverre és full virtualizálva használok mindent.
Az alap hozzá:

  • ASRock EP2C602-4L/D16
  • 2xXeon E5-2680
  • 64GB DDR3 ECC

Szerettem volna guestnek kiadni egy GTX 960-at, egy IMB M1015 HBA-t meg egy Qualcomm Atheros AR9485 WiFi kártyát.
A kezdeti lelkesedésem hamar alábbhagyott, amikor sorra akadályokba ütköztem és nem tudtam beüzemelni.

Amikkel próbálkoztam:

Citrix xenserver
Ezzel kezdtem, mert xent már régebben is használtam és volt vele tapasztalatom. Sajnos hiába voltak a leírások, neke sehohy sem jött össze a VGA kártya, de még a wifi sem.

MS Hyper-V
Ezen tök jól elindultak a linux és freebsd rendszerek is, de hiába próbáltam bármelyik kártyát is átadni a "Add-VMAssignableDevice -LocationPath "PCIROOT(0)#PCI(0200)#PCI(0000)" -VMName StorageServer", látszólag sikerült de mégsem tudta használni, illetve kiírt mindenféle csúnya dolgot, hogy ez hiába jó nem fog menni.

VMware 6.5
Ezzel hiába maszkoltam ki a megfelelő kártyákat, egyik oprendszer sem indult el PCI passthrough módban, csak a nagy sötétség fogadott konzolon.

Proxmox
Mivel ezt is régebb óta használom munkahelyen is, a PCI passthrough-hoz is volt értelmes leírás, ezért ezt is kipróbáltam. Itt sajnos szintén nem jött össze a dolog. Próbáltam Q35 meg FX440 chip készlettel is, BIOS és UEFI módban is, de a VGA csak nem akart életre kellni.

Natív Qemu/KVM
Mivel minden próbálkozásom kudarcba fulladt és a 3 kártya közül szinte egyik sem akart működni sehol sem, kezdtem feladni. De utolsó renényként hozzáláttam magam konfigolni qemu alatt. És csodák-csodájára sikerrel jártam Q35+UEFI alatt mindegyik kártya működött. A HBA-t a FreeNAS kapta meg, a wifi kártyát a PfSense, a VGA meg megy Winows 7/10/2016 server illetve Ubuntu alatt is.

2 Hónapja a GTX 960 kártya helyett szereztem egy Radeon RX 480-at. Na ekkor megint kezdőttek a gondok.
A windows elindult driver nélkül, de amit feltelepítettem a Criomsont fekete képernyő és fagyi. Mindenfélével próbálkoztam és jelenleg FX440+UEFI-vel megy. Az is lehet, hogy a korai driverek nem voltam százasok, de most azt kell mondjam, hogy a VGA szinte 99%-os teljesítménnyel megy a natív baremetal windowshoz képest.

Ezzel a kis történettel csak azt akartam szemlélteni, hogy látszólag a leírások alapján mennie kellene, de nagyon sok minden függ a hardvertől amiben használni szeretnéd és amit használnál. Ha MSI/MSI-X-et tud a kártya, akkor nagy esély van arra, hogy működjön. Persze kell hozzá a jó VT-d alaplap/CPU páros, megfelelő BIOS és jós sok próbálkozás. Lehet, hogy egyből fog menni de lehet, hogy sehogysem.

Mindenesetre sok szerencsét hozzá! Én jelenleg 8 szervert futtatok (linux/freebsd) + a desktop és teljesen meg vagyok elégedve a teljesítnénnyel.

ui: 1 éve használok rendszeresen freebsd-t és a benne lévő bhyve kezd egyre jobb lenni (már VNC szervert is tud konzolnak), tettem egy próbát vele, de sajnos egyik kártya sem indult el, főleg HW address/ROMBAR problémák voltak, de nem adom fel, mert jó volna natív ZFS+bhyve-ot futtatni.

Itt van pár link, amik nekem sokat segítettek:
https://bbs.archlinux.org/viewtopic.php?id=162768
https://wiki.archlinux.org/index.php/QEMU
https://www.pugetsystems.com/labs/articles/Multiheaded-NVIDIA-Gaming-us…

Hátha segít, beszúrom ide a qemu cmdline-t, amivel nekem pl. a win10 megy. Persze a hoston a megfelelő driver tiltások, meg vfio beállítások is kellenek ami a fenti linken le van írva.


$ qemu-system-x86_64 --version
QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.4), Copyright (c) 2003-2008 Fabrice Bellard

### create tap interface (vmbr0 is a bridge interface)
$ TAP0=$(sudo tunctl -u $(whoami) -t tap200010i0 -b)
$ sudo ip link set ${TAP0} up
$ sudo brctl addif vmbr0 ${TAP0}

$ qemu-system-x86_64 \
-enable-kvm -name w10,process=200010 \
-uuid 19116171-d1f5-4e97-81a0-4b57d16fbadf \
-machine pc,accel=kvm \
-cpu host,kvm=off,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vendor_id=madebydolpa \
-smp sockets=1,cores=8,threads=1 \
-m 16374 -mem-prealloc -balloon none \
-nodefaults -nodefconfig -no-user-config \
-rtc base=utc,clock=host,driftfix=none \
-boot order=c \
-vga none -nographic \
-k hu \
-serial none -parallel none \
-usb -usbdevice host:1ea7:2010 -usbdevice host:12cf:0186 \
-drive if=pflash,format=raw,unit=0,readonly,file=/usr/share/OVMF/OVMF_CODE.fd \
-drive if=pflash,format=raw,unit=1,file=/KVM/W10/OVMF_VARS.fd \
-chardev socket,id=charmonitor,path=/var/run/qemu-server/vm-200010-monitor.sock,server,nowait \
-mon chardev=charmonitor,id=monitor,mode=control \
-device vfio-pci,host=81:00.0,addr=09.0,multifunction=on \
-device vfio-pci,host=81:00.1,addr=09.1 \
-device vfio-pci,host=00:1a.0,addr=0a.0 \
-drive if=virtio,format=raw,discard=on,cache=none,aio=native,id=disk0,file=/dev/zvol/ssd480a/vm-200010-disk-1 \
-drive if=virtio,format=raw,discard=on,cache=none,aio=native,id=disk1,file=/dev/zvol/ssd480a/vm-200030-disk-2 \
-drive if=virtio,format=raw,discard=on,cache=none,aio=native,id=disk2,file=/dev/disk/by-id/ata-SAMSUNG_HD103SJ_S246J90Z712031 \
-netdev type=tap,id=hostnet0,ifname=tap200010i0,vhost=on,script=no,downscript=no \
-device virtio-net-pci,netdev=hostnet0,mac=00:16:3e:20:00:10 \
-msg timestamp=on

#### destroy tap interface
$ sudo brctl delif vmbr0 ${TAP0}
$ sudo ip link set ${TAP0} down
$ sudo tunctl -d ${TAP0}

A hyper-v flagek nálam CPU performanciában segítettek kicsit, főleg multithread programokban. De ami igazából sokat javított az a CPU pinning (taskset -ac 8-15, aztán taskset -p -c 8 $PidOfQEMUCPUThread0, taskset -p -c 9 $PidOfQEMUCPUThread1, stb ...).

Terveztem tenni egy próbát a 12.0-CURRENT-el, láttam jött pár újabb patch, szóval ha lesz időm kipróbálni, mindenképp írok oda.

Csak azért kérdeztem, mert én semmi különbséget nem láttam aközött,hogy használom, vagy sem, de amúgy köszi.

Ami azt illeti, az imént megint ki akartam próbálni, mert utoljára hónapokkal ezelőtt használtam és hátha változott valami. Igen, változott, az újabb nvidia drivereknél már nem működik a hv_vendor_id kapcsoló, és elszáll a gép, ha bármilyen hyper-v flag-et használok...

Azt én is tudtam, hogy nVidia-nak kell a vendorid flag, de azzal nekem még 2 hónapja ment egy GTX 960. Azóta már egy Radeon RX 480 van, az meg a Q35-el nem akart elindulni sehogy sem, most i440FX+UEFI-vel megy.

Én azt olvastam anno a hyper-v flagekkel kapcsolatban, hogy ezzel a guestet vágod át, és azt hiszi, hogy hyper-v alatt fut és így jobb teljesítmény ad. Nekem ezzel vol a legjob windows alatt.

Haha, nagyszerű, nem gondoltam volna, hogy a GPU assignment QEMU/KVM + VFIO + OVMF alapokon ide is begyűrűzik :)

Szóval, lássuk azt a parancssort: 

 -boot order=c \

OVMF-hez ne használj 

-boot order=...

opciót, helyette használd a 

-device xxxx,bootindex=N

device property-t.

Tovább: 


 -drive if=pflash,format=raw,unit=0,readonly,file=/usr/share/OVMF/OVMF_CODE.fd \
 -drive if=pflash,format=raw,unit=1,file=/KVM/W10/OVMF_VARS.fd \

Elképesztő; létezik felhasználó, aki tudja ezeket az opciókat helyesen használni :) Elismerésem, és köszönöm, visszatért a remény :)

Tovább: 


 -drive if=virtio,format=raw,discard=on,cache=none,aio=native,id=disk0,file=/dev/zvol/ssd480a/vm-200010-disk-1 \
 -drive if=virtio,format=raw,discard=on,cache=none,aio=native,id=disk1,file=/dev/zvol/ssd480a/vm-200030-disk-2 \
 -drive if=virtio,format=raw,discard=on,cache=none,aio=native,id=disk2,file=/dev/disk/by-id/ata-SAMSUNG_HD103SJ_S246J90Z712031 \

A múltkor ennek utánajártam. A 

discard=on

-nak ugye a "thin provisioning" a célja, vagyis hogy amikor a guest-ben letörölsz egy nagy file-t, akkor a felszabadított blokkok visszakerüljenek a host file-rendszerhez (vagy block device-hoz) szabad blokkokként. Ennek a host oldalon az a feltétele, hogy a block dev (vagy fs) maga is támogassa az UNMAP-et (ill. hole punching-ot; ext4, xfs pl.). Feltételezem, hogy a fent látható zvol (ZFS?) kötetek támogatnak UNMAP-et.

A guest oldalon pedig az a feltétele, hogy a guest OS valóban küldjön ilyen UNMAP (vagy IDE esetén, ha jól emlékszem) TRIM request-eket.

Na, a nagy helyzet az, hogy a Windows 7 kizárólag a Q35 AHCI controller-ével, IDE disk-en fog TRIM-et küldeni (a Windows 7 natív driver-ével), sehol máshol. (Szerk: ezt pontosítanom kell: nem vagyok egészen biztos benne, hogy az i440fx IDE controller-én nem fog TRIM-et küldeni. A legbiztosabb az, ha létrehozol, majd letörölsz egy több GB-s file-t a guest NTFS-en, közben pedig nézed a host-on az fs foglaltságát. Néhány 10 mp után legkésőbb vissza kell jönnie a blokkoknak.)

A Windows 8 és a Windows 10 pedig egyrészt az előbbi setup-ban, másrészt pedig virtio-scsi diszkeken (a virtio-win driver-rel) küld UNMAP-et. Virtio-block diszken nem működik az UNMAP, mert a virtio-block protokollba nem fér bele.

A parancssorra ez úgy fordul le, hogy csinálnod kell egy virtio-scsi-pci vezérlőt, amire a guest-oldali meghajtóidat scsi-hd típusú eszközökként rakod rá. Fontos, hogy a backend-nél az interfésznek (

if

) ebben az írásmódban, tehát amikor a backend (

-drive

) ill. frontend (

-device xxxx

) külön van megadva, 

none

-nak kell lennie. (Egyébként az 

if=virtio

egy shortcut arra, hogy 

-device virtio-blk-pci,id=diskN

.)

Vagyis: 


 -drive if=none,format=raw,discard=on,cache=none,aio=native,id=disk0,file=/dev/zvol/ssd480a/vm-200010-disk-1 \
 -drive if=none,format=raw,discard=on,cache=none,aio=native,id=disk1,file=/dev/zvol/ssd480a/vm-200030-disk-2 \
 -drive if=none,format=raw,discard=on,cache=none,aio=native,id=disk2,file=/dev/disk/by-id/ata-SAMSUNG_HD103SJ_S246J90Z712031 \
 -device virtio-scsi-pci,id=scsi0 \
 -device scsi-hd,drive=disk0,bus=scsi0.0,bootindex=0 \
 -device scsi-hd,drive=disk1,bus=scsi0.0 \
 -device scsi-hd,drive=disk2,bus=scsi0.0 \

Feltelepített Windows guest-et sohasem próbáltam még átröffenteni más típusú diszkre. Az egyik kollégám adott egy tippet, de sajnos Win10-re nem jó, azt mondja. Tehát ha nagyon fontos a discard, akkor érdemes újrahúznod a guest-et virtio-scsi rendszerdiszkre. (Az adatdiszkeken nyilván nem kell semmi adatot változtatni.)

A topic eredeti témájához még ezt a két linket hozzátenném:

Természetesen én is használok device assignment-et, egy GTX750-nel ill. egy i350-t2v2 NIC-kel (VF assignment). A libvirt-et ezerszer jobban komálom a nyers QEMU parancssornál, úgyhogy mint minden más hosszútávú guest-em, ezek is libvirt alatt vannak. Neked is ajánlom.

Forrás :)

Köszi a tippeket!

A -boot order=c azért van benne, mert a bootindex-et csak -device megadásnál lehet alkalmazni, és jelen esetben i440FX-el nekem csak a sima -drive if=virtio működött. Q35-nél nekem is rendes -device -drive páros van.

Igen a ZFS volume thin provisioning kapcsolóval lett létrehozva, ezért van discard=on. Még az elején én is Q35+virtio-scsi-pci kombót használtam, de aztán pár windows 10 disk teszt után úgy vettem észre, hogy a -device virtio-blk-pci jobban teljesít, főleg íráskor, SSD-re Sequential Write (Q= 32,T= 1) : 420.471 MB/s vs 238.772 MB/s. De azért majd teszek még egy próbát a virtio-scsi-pci-val mert szimpatikus volt. Ezek a kapcsolók azóta ott vannak.
Főleg még tavaly próbálkoztam sokat mindeféle kombóval, azóta nem volt időn újra elővenni. Örültem, hogy jól működik minden. Mostanában kezdtem el ismét foglalkozni ezekkel a dolgokkal új hardver miatt, de főleg a bhyve kapcsán.

Még egy eszembe jutott, hogy igazából azért váltottam UEFI-re, mert BIOS módban elindult ugyan a VGA, de egy esetleges guest STOP/START után már nem volt képe, újra kellett indítani a teljes hostot. Gondolom valami VGA reset hiányzott, vagy hasonló. UEFI-vel viszont nincs ilyen gond és a beállítások is hasznosak benne.

Én 6.5-el próbálkoztam, a másik gondom vele az volt, hogy csak 1 socket-ig ingyenes, és otthonra kicsit drága 2 processorral.
Vállalati környezetben jó (na azért vannak vele gondok), mert mi is azt használjuk a cégnél, de otthonra kicsit túlzásnak érzem, főleg vcenterrel együtt.

1. Igaz, 6.0-ra gondoltam.

2. Tavaly amikor én néztem a free licensz feltételeket még max 1 socketre emlékszem, lehet hogy azóta ez megváltozott.

3. A vcenter meg kell, mert a vastag kliens-ben nem lehet állítani jó pár dolgot az újabb VM machine type-nál. (Ezt írja is, amikor létrehozod a vmguest-et)

Semmi olyan feature nincs ami miatt kellene virtuális hw verzióból v8-nál nagyobb, azt pedig nyugodtan szerkesztheted direktbe vSphere kliensből. NEM kell vCenter és ránézésre nem nagyobb falat beállítani mint más megoldásoknál (van feljebb egy-két bikkfang azért ;) )

Ja, én szerkesztgettem kézzel is, még physical disk-et is sikerült hozzáadnom, de az VGA nem akart sehogy sem működni. Pedig volt pciPassthru0.maxMSIXvector, pciPassthru0.msiEnabled meg pciHole.start meg már a jó ég tudja mi mindennel próbálkoztam.

A neten sem találtam működő leírást, csak tippeket, hogy mit kellene beállítani.

Elméletben: igen :)

Ahogy nézem a cpu tud VT-d-t és a Dell technikai leírásban is említve vagyon mint fícsör, szóval uccu neki :).
Azért egy friss bios/firmare package legyen rajta.
Ha RAID-et akarsz akkor valami H200 vagy újabb hw raid kontroller kell neki, lehetőleg ami HCL-es.

6.0 kell hozzá a memória mérete miatt értelemszerűen.

Az evaluation verzió 60 napig minden funkcióhoz hozzáférést ad, utána a free licencszel mehetsz tovább
(vigyázat, a külső API-k nagy részét ez letiltja, szóval pl. mentésnél csak teljes VM-et fogsz tudni menteni, inkrementálist nem, stb)
Persze újra is húzhatod 59 naponként, van aki ezt csinálja automatizáltan :)

És ha már ott vagy én azért adnék egy lehetősége a vCenter Appliancenak is.
Legalább látod hogy mi merre, ne csak mindig a KVM meg társai, legyen egyszer a piacvezető is :P (*grabs popcorn*)

"ne csak mindig a KVM meg társai, legyen egyszer a piacvezető is :P (*grabs popcorn*)"
Ijjj lesz majd ebből szép szál itt! :D

Node. Kb. 3 éve volt szerencsém egy normálisabb projektben (4 szerver, mindegyikhez normális licensz az ESXi-hez + vCenter Appliance) kipróbálni az ESXi-t. (Ott mondjuk pont egyáltalán nem volt szempont a PCI Passth.) És hát sajnos nem nyűgözött le. Kényszerűségből a vCenter Appliance is az egyik vason futott, és hát már elvi szinten is jó lett volna ha az egy külön gépen fut. Szépen be lett állítva a live migration, stb. stb. de valahogy nekem nagyon nem volt szimpatikus az egész felfogás/beállítási felület, stb. (Talán a Flash b*szta ki a biztosítékot, nem tudom :D ). Szóval nem azt mondom hogy rossz, de nekem nem állt kézre, kicsit nyakatekertnek gondoltam.
Ugyanakkor a 60 napos játszadozás helyett a próbakor akkor már rögtön regelek egy free-t, hogy azt lássam úgy mit tud :)

trial-and-buy, szóval 30 napos próba letölthető és direktben nem is lehet megvenni, csak egyeztetéssel, hogy ne legyen inkompabilitás. Ezt olvastam az oldalon.
Eddig annyit láttam, hogy pendriveről fut és a különböző licensz típusok azt határozzák meg, hogy hány háttértár lehet alatta az indító pendriven kívül.

Nem tudom, hogy ki a célcsoportjuk. Gondolom szponzorálják a srác videocsatornáját, mert az ő szoftverükkel virtualizál.

( Dolpa | 2016. 09. 13., k – 16:53 )

Cégnél 3 szerveres cluster van EMC storage van mögötte. Azt már megszoktam a vCenterben, hogy minden túl van benne bonyolítva, de miért olyan rohadt lassú? Gyakran van timeout. Miért nincs a gui-ban egy boot order lehetőség? Miért kell ehhez a BIOS-ba belépni?

Nagyon offtopic, de:
Azért tűnhet túlbonyolítottnak, mert nem ezzel foglalkozol. A rengeteg funkció, beállítás elérését valahogy meg kell oldani, egyesek ezért frusztráltak, ha webclientet kell használniuk. Lassú. Igen, legtöbbször. Nem baj, a következő html5 lesz, ami az ipari trendekből kiindulva gyors lesz, viszont 3 vogon flotta elfér majd a képernyő kitöltetlen területein, annyi üres hely lesz rajta.
Boot order meg minek?