Virtulizáció PCI PASSTHROUGH-val

 ( biokill | 2016. szeptember 8., csütörtök - 10:48 )

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)

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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/

A bhyve is tudja a PPT-t :-) (Tekintsd feliratkozásnak, ha nagyon nem akarsz BSD-zni.)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

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?

Igen, az lenne a cél. Első körben valami kevésbé izmos GPU-t beledobnék amit találok a polcon. Ha elindul a GTA, akkor örülök :D Akkor már nagy valószínűséggel megy majd a szoftver is, amiről eddig semmi infó sincs :D

En hangkartyat adtam at egy Slackware-t futtato guest-nek, es az is jol ment.


Sic Transit Gloria Mundi

En pci-os parhuzamos portot amin egy hardwarekulcs figyelt. Tokeletesen mukodott.

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 :)

Ez igen bíztató, köszi! :)
Proxmox fórumon most találtam is rá konfot, blacklistre kell tenni akkor a kártyát.

+1, vfio-pci-jal van leválasztva és átadva a diszkrét kártya a Windows 10-et futtató guest domain-nek nálam, hibátlanul megy (a fizikai Gentoo a hoston boldog az integrálttal)
------------------------
{0} ok boto
boto ?

Úgy látom a Proxmox-on is megy: https://pve.proxmox.com/wiki/Pci_passthrough
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Köszi, ezt megtaláltam én is. Bizakodó vagyok, csak kíváncsi lettem volna hogy valakinek ment-e személyesen. De már írták hogy Qemu+KVM-el igen, szóval akkor Proxmoxon is mennie kell nagyon nagy valószínűséggel rendesen.

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.

Köszönöm, arról foglalmam sem volt hogy az ORA is Xen alapú. Hyper-V-t kizárnám a licensz költségek miatt (valószínűleg nem lesz Win a gépeken, sem fizikai sem virtuális formában), így akkor marad a KVM és a XEN. Szerintem mindekettőt kipróbálom pár napig.

"Hyper-V-t kizárnám a licensz költségek miatt"

A Hyper-V Server ingyenes, ebben a környezetben egyéb, költséget okozó függősége sincs.

Üdv,
Marci
A Microsoftnál dolgozom.

Ott a pont ;)

Köszi. Ezt nem is gondoltam volna, azt hittem hogy 1. kell egy windows amire felteszem programként, 2. fizetős szerver változata van :)

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.

Akár egy idelinkelt külön szálban is, de írhatnál a bhyve-os nyűgökről. Engem érdekel.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

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 :)

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.

VMware-hez tuti kell, CPU+chipset+BIOS.

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-using-Ubuntu-14-04-KVM-585/

Köszönöm szépen a leírásod igen hasznos volt, pont az ilyen gyakorlati tapasztalatok érdekeltek. Mert látszólag tényleg mindenki tudja (Proxmox is), aztán lehet hogy mégse... Pedig a Proxmox is Quemu+KVM. Szerencsére lesz egy kis időm kipróbálni az alternatívákat.

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 hyperv flag-ek használtak nálad bármit is?

illetve,ha már írtad a zfs+bhyve kombót, esetleg nincs kedved küldeni egy teszt eredményt ide?
https://github.com/chyves/chyves/issues/3

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.

egyre nagyobb katyvasz lesz az NVDIA+QEMU páros
https://github.com/sk1080/nvidia-kvm-patcher

Mostanában azon gondolkozom,hogy a következő kártya már AMD/ATI lesz, ezt se gondoltam volna pár hónappal ezelőtt...

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öszönöm a sok ontopic hozzászólást és leírást! Remélem mihamarabb megjön a gép és kedvemre tesztelhetek! :)

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.

Még egy link, ha már az archlinux wiki-t említjük (tényleg az egyik legjobb wiki a neten):

https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF

HP ESXi 5.5-tel nekem stabilan ment az lsi 9211-8i, HD6450 es usb controller passthrought-val. HP ML310e Gen8 volt az alap E3-as Xeon-nal. AiRLAC ahogy mondja, vmware ala tamogatott vas kell.

É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. nincs 6.5-ös vSphere
2. 2 processorral is ingyenes a hypervisor (8 vcpu/vm a limit)
3. vCenter nem kell hozzá

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)

Egy jó ideje már nincs hw limit emlékeim szerint.
6.0u2-nél pedig már hoston fut egy webclient, tehát böngészővel eléred, ha jól tudom azon nincs ilyen limitáció.

Próbáltam azt a Technical Preview esxui vib-et is, majd biztos jó lesz egyszer, ha elkészül, de az még messze van.

Március(6.0u2) óta nem TP, hanem hivatalosan támogatott és szállított eszköz.

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.

Tehát akkor egy free licensszes ESXi-vel is meg lehet oldani (Dell T7600 Worsktation lesz 2 X Xeon E5-2670 tehát összesen 16 fizikai mag) vSphere Clienttel és nem kell a vCenter?
Mert emiatt a kettő miatt zárnám ki az ESXi-t... (CPU limit + VCenter kell = Free nem játszik)

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 :)

sub

sub

Tetsztetős! :)

:)

Ezzel a lime-tech unRAID-el olyan egyszerűnek tűnik a dolog... Bár én csak 2 fős témában gondolkodom...De azért tartok tőle, hogy pont nálam lesz valami kritikus anomália...

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.

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?