Budapesti Műszaki és Gazdaságtudományi Egyetem
Villamosmérnöki és Informatikai Kar Méréstechnika és Információs Rendszerek Tanszék
I/O virtualizációs módszerek Házi feladat Virtualizációs technológiák és alkalmazásaik c. tárgyból
Készítette Ferencz Bálint (BIDE)
Budapest,
Tartalomjegyzék . Bevezetés
.. ..
Motiváció . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtualizáció múltja és jelene . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. A periféria-virtualizáció típusai
.. .. .. ..
Emuláció . . . . . . . . . . . . . . Paravirtualizáció . . . . . . . . . . - közvetlen hozzárendelés . . . . -több közvetlen hozzárendelés []
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. Tapasztalatok - közvetlen hozzárendelés esetén
.. Mérési elrendezés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Mérési eredmények . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Konklúzió
F Függelék
1. Bevezetés Napjainkban az x platform virtualizációs környezetek egyre nagyobb részt hasítanak ki az informatikai infrastruktúrák piacából. A virtualizáció segítségével az erőforrások rugalmasan oszthatóak ki a konkrét funkciókat megvalósító szovereket fuató vendégkörnyezetek közt. A CPU, és a RAM biztosításán felül szükséges a rendszerbe illeszte egyéb perifériák minél kisebb költségű kiosztása a virtualizált rendszerek közö. A házi feladatban bemutatom azokat a feltételeket, melyek megléte szükséges a periféria-virtualizáció megvalósításához, kifejtem a modern periféria virtualizációs megoldások működési alapelvét, valamint egy tesztrendszer segítségével demonstrálom annak egyszerű elérhetőségét, valamint néhány mérést is elvégzek a virtualizált perifériák teljesítményének kiértékelésére.
1.1. Motiváció Az egyetemi tanulmányaim során önálló laborok, TDK-k, szakdolgozat és a diplomaterv készítése során a fő érdeklődési területem az Ethernet alapú óraszinkronizáció megvalósítása volt Linux környezetben. Ehhez szükségem volt egy olyan fejlesztői környezetre, mely elősegíti az egyszerű távoli fejlesztést, rugalmasan konfigurálható a hozzáilleszte aktív hálózati adapterek tekintetében, valamint egyszerűvé teszi a hibakeresést a kernel driverek fejlesztése közben. A felmerült igények legkézenfekvőbb megoldása egy virtuális fejlesztői rendszer felállítása volt, ahol a modern periféria-virtualizációs megoldások segítségével a virtuális gépeken pontosan ugyanazokhoz az erőforrásokhoz fértem hozzá a hálózati adaptereken, mintha azt normál környezetben végeztem volna, valamint az esetleges hibás kódsorok által okozo kernel panicok elhárítása is nagymértékben leegyszerűsödö (fizikai hozzáférés nélkül ez nem virtualizált környezetben sok fejfájást okozo). A házi feladat forrásainak feldolgozása során behatóbban megismerkedtem ennek a szolgáltatásnak a működésével (különösen az Intel által szállíto megoldással), ezáltal jobban meg tudom becsülni az ebben a környezetben jelentkező mérési bizonytalanságokat.
1.2. Virtualizáció múltja és jelene Az -as években már léteztek olyan számítástechnikai rendszerek, melyek az erőforrások hatékony kihasználása mia több környezet párhuzamos fuatását teék lehetővé. Popek és Goldberg a -es években formalizálta azt a virtualizációs kritériumrendszert, mely teljesítésével a valós életben használható virtualizált rendszereket készíthetünk []: . Ekvivalencia. Egy virtuális gép számára a fizikaival teljesen azonos környezetet kell biztosítani.
. Biztonság. A VMM¹-nek a virtualizált erőforrások fele teljes rendelkezéssel kell bírnia. . Teljesítmény. Az utasítások nagy részének a VMM beavatkozása nélkül kell futnia. Az első és második kritériumoknak természetesen minden virtualizált architektúrán teljesülniük kell, azonban x alapú rendszereken ez sokáig a harmadik kritérium rovására ment. A VMWare és a Connectix² cégek x platformra már a kilencvenes években szállítoak platform virtualizációs megoldásokat, de megemlítendőek a Bochs és QEMU szoverek is, melyek teljes x emulációt kínáltak, nem csupán x gazda architektúrán. Az előbbi cégek termékei bináris transzláció módszerével oldoák meg a vendég környezetek teljes virtualizációját, ennek segítségével a teljesítményveszteséget aránylag alacsony szinten lehet tartani (cserében csak x gazda architektúrán futnak). --ban a két legnagyobb IA- architektúrájú mikroprocesszorokat gyártó cég (az Intel és AMD) piacra dobta azon megoldásait (VT-x és AMD-V), melyek segítségével a három feltételnek egyszerre tehetünk eleget (lásd []). Ezen technológiák bevezetésével azonban még nem minden igényre sikerült kielégítő választ adni, hiszen a PCI-Express buszra felfűzö perifériák még mindig nem kerülheek közvetlen kiosztásra a virtuális gépeknek, csak szoveres emuláción, vagy paravirtualizáción keresztül. Erre nyújtoak megoldást a fentebb említe gyártók a -es AMD-Vi és VT-d I/O virtualizációs technológiájukkal, mely a processzor részéről megoldoa perifériákhoz tartozó memóriatérkép biztonságos, és nagy teljesítményű transzlációját a guest gépek felé (az algoritmus kifejtése megtalálató i: [] []). -ben a PCI-SIG szabványosítoa a PCI-Express csatolón kommunikáló eszközök virtualizációját megvalósító interfészkészletet, ennek hatására a gyártók elkezdheék felkészíteni a hardvereiket a több guestnek történő alacsony költségű párhuzamos kiajánlásra.
2. A periféria-virtualizáció típusai 2.1. Emuláció A perifériák emulációja szinte minden hypervisor sajátja, hiszen például a hálózat, vagy diszk hozzáférést ilyen módon lehetséges operációs rendszer és hardverüggetlen módon megvalósítani. Ennél a módszernél a VMM kezel minden periféria hozzáférést, ami azt jelenti, hogy egyrészt egy a vendég OS számára látható virtuális perifériát kell nyújtania, valamint minden perifériát érintő rendszerhívást el kell kapnia, és fordítania a valós hardver/vendég OS felé. Ez azt is jelenti, hogy a hypervisornak a virtuális eszköz melle egy virtuális megszakításkezelőt is implementálnia kell, és ezt kell a vendég gép felé IT forrásként nyújtania. A megoldás nagy előnye, hogy hardverüggetlenséget biztosít, tehát ahol fuatható a vendég OS-t hostoló hypervisor, o a vendég gép is módosítás nélkül fuatható. Ezen felül a másik ¹Virtual Machine Monitor, de gyakran hivatkozunk rá a hypervisor elnevezéssel is ²Ezt a céget a Microso felvásárolta a saját VirtualPC, majd Hyper-V platformjának fejlesztése vége
fő előnye az, hogy egyetlen fizikai hardverelemet több virtuális gép felé és képesek lehetünk kiajánlani. Az előbb említe NIC, IDE/SATA/SCSI diszk alrendszerek kezelése tipikusan az átlag felhasználók számára ezzel a módszerrel szoko megvalósulni. A fő hátrány természetesen a létrejö teljesítményveszteség a hardverelemek komple emulációjának köszönhetően. Az emulációt (I/O trap, emulált IT kontroller) komplex kódokkal lehetséges megvalósítani, ez növeli az erőforrásigényt []. Emulációra jó gyakorlati példa a VMWare virtualizációs környezetek által nyújto e hálózati csatolók működése.
2.2. Paravirtualizáció A paravirtualizált környezetek lényege általánosságban az, hogy a virtualizált operációs rendszer valamilyen módon módosítva van annak érdekében, hogy a virtuális környezetből ne a ”nem létező” hardvert címezzük meg, hanem a VMM által nyújto felületen keresztül valósítsuk meg a kívánt működést. A megszakításvezérlő és virtuális periféria emuláció helyet a paravirtualizált eszközmeghajó által nyújto absztrakt interfészek segítségével kommunikál a vendég OS az őt kiszolgáló VMM-mel, és a hypervisorban történik meg a periféria tényleges felprogramozása, az adatainak beolvasása, kiírása. A megoldás előnye, hogy a hordozhatóság igen kiváló azon esetekben, amikor a fuató hypervisorok ugyanazon programozási felületen keresztül nyújtják a szolgáltatásaikat. A fizikai eszközzel kapcsolatos interakció teljes mértékben el van rejtve a hypervisor rétegben, az emuláció alapú megközelítéshez hasonlóan. Az emulációhoz hasonlóan i is egyszerűen (szover alapon) megoldható egyetlen fizikai erőforrás több vendég gép számára történő allokációja. Nagy hátrány, hogy az ehhez szükséges módosíto drivereket el kell készíteni minden egyes fuatni kívánt vendég OS alá. Belátható, hogy emia nem teljesen operációsrendszer-üggetlen a megoldás, előre fel kell készülnünk a fuatni kívánt vendég OS-ek típusára, azokhoz drivert kell szállítanunk. Paravirtualizációra jó gyakorlati példa a VMWare rendszereken alkalmazo VMXNET hálózati adapterek használata.
2.3. 1-1 közvetlen hozzárendelés Ahhoz, hogy a hypervisor szerepét a perifériaelérésben csökkentsük, és ezáltal az elérhető teljesítményt maximalizálhassuk, célszerű a fizikai eszközt közvetlenül a vendég OS-nek átadnunk. Az átadás során a hypervisornak nem szükséges az átado eszköz meghajtójával rendelkeznie, feladata csupán a host hardver felprogramozására terjed ki. Ahhoz, hogy ezt biztonságosan megtehessük, az alábbi feltételeknek kell teljesülniük: . A fuató CPU/buszvezérlőnek támogatnia kell valamely IOMMU szolgáltatást (pl. AMDVi, Intel VT-d).
1. ábra: Közvetlen hozzárendelés blokkdiagramja Ethernet csatolók esetén [1]
. A gazda hypervisor környezetnek rendelkeznie kell IOMMU támogatással, hiszen ennek a felprogramozása a VMM feladata. . A vendég operációs rendszer részéről semmilyen extra támogatás nem szükségeltetik, számára a periféria transzparens módon jelenik meg, így a normál meghajtók segítségével működtetheti az eszközt. A megoldásnak árnyoldalai is vannak. Egyrészt a hordozhatóság csorbát szenved, hiszen a célgépen pontosan ugyazon típusú hardvernek kell rendelkezésre állnia, mint a forrás környezetben. Ha ez nem teljesül, a vendég környezet újrakonfiguráció nélkül nem tudja ellátni feladatát. A másik nagy probléma a közvetlen hozzárendeléssel kapcsolatos: a gazdagépen fellelhető fizikai hardverek számosságáig vagyunk csak képesek a perifériákat kiosztani, ezáltal a romló periféria kihasználtság melle egyéb érdekes helyzetekbe is kerülhetünk — ilyen például az, hogy ha több VM számára is nagyteljesítményű storage elérést kell biztosítanunk, és csak azért kell duplikálnunk a teljes hardvert, mert az egyes VM-eknek csak dedikáltan lehetséges kiosztani őket. Belátható, hogy az ökölszabályként alkalmazo VM / processzormag összeállításban egy magos gazdagépen futó darab VM dedikált kiszolgálásához szükséges fizikai port erősen túlzó igény, így nem minden esetben érdemes így nekilátnunk az alacsony késleltetést, nagy sávszélességet igénylő megoldások összeállításához. I fontos megjegyeznünk, hogy a hozzárendelés egy PCI-Express buszon levő eszköz egyetlen funkciójára vonatkozik csupán, tehát például egy négyportos hálózati adapteren nem szükséges egyetlen
port hozzárendelése mia lemondanunk a másik háromról, azok üggetlenül bekerülhetnek a hypervisor kezelése alá (lásd . fejezet).
2.4. 1-több közvetlen hozzárendelés [1] A periféria virtualizációs megoldások közül a két világ (paravirtualizált vs. direkt hozzárendelt) legjobb tulajdonságait egyesíti az a hozzárendelési típus, ahol egyetlen fizikai eszközt ajánlhatunk ki több vendég gép számára úgy, hogy a hypervisor minimális módon (célszerűen csak az eszköz felprogramozásakor) avatkozzon be a guest I/O műveletekbe. Ennek biztosításához szükséges . a kiajánlani kívánt periféria hardveres támogatása, . és a alkalmazni kívánt vendég operációs rendszer ala virtuális driverek megléte. Az -több hozzárendelés segítségével a mostanság divatba jövő gigabites Ethernet csatolók erőforrásait szabványos módon oszthatjuk fel több VM közö. Általánosságban elmondható, hogy gigabites nyers hálózati sávszélességre a feladatok nagyon kis százalékának van szüksége, viszont pl. VM felé elosztva ezt az erőforrást még mindig gigabites sávszélességekre tehetünk szert! Ezt a működési módot x architektúrán a PCI-SIG által definiált SR-IOV³ szabványon keresztül valósítja meg a rendszer. A rendszer blokkdiagramján (. ábra) látható, hogy a hardver két részre van osztva: . a fizikai hardvert jelképező Physical Function-ra (PF ), . valamint a szétosztandó erőforrásokat jelképező Virtual Function-okra (VF ). A virtuális gépek számára a fizikai eszköz több, egymástól üggetlen eszközként jelenik meg, melyeket egy minimális funkcionalitású VF drivereken keresztül kezelhetünk. Ezen meghajtókban csupán az eszközhöz köthető legszükségesebb funkciók vannak implementálva, így például hálózati vezérlőknél a csomagküldés/fogadás parancsai. Az eszköz felprogramozásához szükséges a hardver teljes regiszterkészletét ismerni, ezt valósítja meg a Physical Function meghajtója. A PF-hez tartozik például a link státusz kezelése, vagy az átviteli sebesség beállítása Ethernet csatolók esetén. Jól megterveze perifériák esetén a hardvert lehetséges megoszto módon kezelni, tehát bizonyos erőforrásait VF -enként kiosztani, másokat pedig a hagyományos emulált módon a vendég gépek rendelkezésére bocsájtani. Az ábrán jól látható, hogy a teljesítményproblémákat okozó switchelés a szoverből teljes mértékben átkerült a hardverbe (amennyiben nem kívánunk emulált hardvereket kiosztani), így az egymástól üggetlen I/O kéréseket a periféria autonóm módon képes ütemezni, ezzel növelve a közös továbbító médium kihasználtságát []. ³Single Root I/O Virtualization
2. ábra: SR-IOV blokkdiagram Ethernet csatolók esetén [1]
3. Tapasztalatok 1-1 közvetlen hozzárendelés esetén A motivációmban leírt indokok arra sarkalltak, hogy egy kicsit részletesebben is dokumentáljam a direkt hardver hozzárendelésben szerze tapasztalataimat. A féléves szóbeli beszámolómban még arról beszéltem, hogy SR-IOV-vel kapcsolatos méréseket végzek a házi feladat keretein belül, azonban sajnos kiderült, hogy az Intel nem támogatja azt VMWare környezetben az GbE adapterein, csupán azok gigabites változatain []. Mivel nekem nem állt rendelkezésre sem gigabites Ethernet csatoló, sem alternatív virtualizációs gazdagép — ahol pl. Linux alól hostolva tudtam volna méréseket végezni—, ezért ezektől a mérésekről sajnos kénytelen voltam elállni. Az általam használt rendszer egy Intel Nehalem architektúrára épülő HP ProLiant ML G volt, melyben Intel gigabites hálózati csatolók kerültek elhelyezésre tesztelési célokból. Mivel a processzor, és a BIOS, valamint a feltelepíte VMWare ESXi . hypervisor is támogaa direkt hozzárendelést (DirectPath I/O marketingnéven), ezért az (erősen unintuitív módon) megvalósítható volt. Ennek menete a következő: először meg kell keresnünk a VSphere-ben az Advanced Seings lapot, ahol kilistázva láthatjuk az aktuálisan bekapcsolt közvetlen hozzárendelésre kész eszközöket (. ábra). Amennyiben nem látjuk i a kívánt eszközt az ’Edit…’ gombra kaintva kiválaszthatjuk azt a lehetséges eszközök listájából, és a rendszer teljes rebootját követően átadhatóvá válnak a virtuális gépek számára (. ábra). A guestek beállításai közö látható az összes erőforrás, többek közt a PCI deviceként láthatóak a tesztelni kívánt hálózati adapterek is. Az is megfigyelhető, hogy a rendszer már tartalmaz más hálózati csatolót, ezek közül az
3. ábra: 1. lépés – a direkt hozzárendelés lekérdezése
egyik a rendszer menedzsmentjére szolgál, valamint a tesztek kedvéért adtam hozzá még két eszközt — ez a mérni kívánt Ethernet csatoló egy a hypervisor által kezelt portja (egyszer emulált, másszor paravirtualizált eszközmeghajtókkal). Az F.. felsorolásban látható, hogy a guest operációs rendszer számára milyen módon jelenik meg az emulált, a paravirtualizált, valamint a direkt módon átado hálózati adapter. Ezt az információs az lspci -v parancs kiadásával lehet lekérni az operációs rendszertől, én a helytakarékosság vége csupán a hálózati vezérlők adatait másoltam be a üggelékbe. A memóriatartományok a Memory at kezdetű sorokban találhatóak, a virtuális rendszerbuszon betöltö helyük pedig a Physical Slot kezdetű sorokban. A virtualizált memóriacímek természetesen teljes mértékben eltérnek az F.. listában található hypervisor által láto logikai címektől. A hypervisor logikai címtérképét az SSH-n történő bejelentkezés után a ’\proc\bus\pci\devices’ fájl listázásával lehet megismerni. Ebben a fájlban is rászűrtem a releváns információkra, valamint # jellel jeleztem a megértést segítő kommenteket. A vesszőkkel tagolt táblázat az alábbi formában értelmezendő: . Az első oszlop a root port sorszáma, . a második oszlop az eszköz száma, valamint a rajta található aleszközök sorszáma egybeírva, . a harmadik oszlop egybeírva tartalmazza a gyártó és periféria ID-kat, . a negyedik oszlop a hypervisor által használt megszakításcímeket mutatja,
. a következő oszlopok a memóriába mappelt I/O címeket tartalmazzák, . végül az utolsó oszlop mutatja, hogy van-e az eszközhöz betöltö eszközmeghajtó. Példaképpen a . táblázat bemutat egy hozzárendelést: Host Guest
BAR0 0xfa700000 0xd3100000
BAR1 0xfa6fc000 0xd3004000
IRQ 0x78 19
1. táblázat: Guest-host címösszerendelés a 06:00 ID-jű eszköznél
Az automatikus megszakítás és memóriacímtranszlációt a memóriavezérlő végzi el a vendég OS és a VMM számára transzparens módon []. A vendég OS számára a hardver minden funkciója teljes mértékben elérhető, leszámítva a Virtual Machine Device eue-kat, melyek segítségével a hypervisor képes lenne több VM-nek kiosztani egyetlen erőforrást. Ennek privilégiumbeli okai vannak, a guest OS nem látja a processzor minden képességét, és többek közt nem is tudja felprogramozni a virtuális processzort véde DMA működésre (VT-d), hiszen a processzor–memóriavezérlő párosnak ezen erőforrásai nincsenek duplikálva, azokat csak a root hypervisorban lehetséges elérni.
4. ábra: 2. lépés – a direkt hozzárendelés engedélyezése
5. ábra: 3. lépés – a direkt hozzárendelés beállítása
3.1. Mérési elrendezés A mérési elrendezést az . ábra szemlélteti. mitpc37 iperf
Tanszéki hálózat (Internet)
Kernel
Menedzsment NIC
VM hálózat
PCI Express Menedzsment NIC
PCI Express
i350 NIC
Linksys 1GbE switch
m0n0wall
iperf ping I350 NIC Ubuntu 12.04 VM 1 Gb/s Ethernet kapcsolat 100 Mb/s Ethernet kapcsolat
Hypervisor (ESXi 5.1.0)
Összeköttetések
weasel
6. ábra: A mérési elrendezés
A mérések során a iperf forgalom generátor segítségével TCP és UDP adatforgalmat generáltam emulált, paravirtualizált és DirectPath metóduson keresztül kiajánlo hálózati csatolókon, majd megmértem az elérhető maximális sávszélességet. A mérések során mindhárom típusú hálózati csatoló az i valamely portjának egy virtualizált formája volt — a kártyán két csatlakozót kötöem a switchbe, ezek közül az egyik dedikáltan volt a VM-nek kiajánlva, a másik portot pedig emulált és paravirtualizált módon bocsájtoam a virtuális gép rendelkezésére (i remekül megfigyelhető a megoldás rugalmassága!). Az újabb ESXi változatok felajánlják a VMXNET-on keresztül csatlakoztato eszközök automatikus DirectPath csatlakoztatását, azonban ez a mérések során nem történt meg, ismeretlen okból⁴. A guest VM-ben az iperf kliens futo az alábbi beállításokkal: . TCP kapcsolat esetén: iperf -c 192.168.1.111 . UDP kapcsolat esetén: iperf -c 192.168.1.111 -u -b 1000M A mitpc számítógépen az iperf szerverként futo az alábbi beállításokkal: . TCP kapcsolat esetén: iperf -s -B 192.168.1.111 . UDP kapcsolat esetén: iperf -s -B 192.168.1.111 -u ⁴Ennek feltétele többek közt, hogy a guest teljes memóratartománya fenn legyen tartva a guestnek, és ne történjen memory ballooning, hiszen ez korruptálhatná a DMA átviteleket!
3.2. Mérési eredmények A mérések során az alábbi eredmények adódtak: iperf UDP [MBit/s] iperf UDP elvesze [db] iperf TCP [MBit/s]
Emulált (eth3) 808 1 59,7
Paravirtualizált (eth0) 808 1 55,3
DirectPath (eth4) 810 1 340
2. táblázat: Mérési eredmények
Ezen mérési elrendezés nem volt alkalmas arra, hogy a rendszer szűk keresztmetszeteit felmérje, ez látható az iperf UDP sávszélesség eredményeinél. A csomagalapú átvitel esetén az átviteli sebesség a hibahatáron belül megegyeze, ami várható volt, a gép alacsony terheltsége mia. A VMWare szoveres switchelési és emulációs/paravirtualizációs megoldása ennyire egyszerű esetben felveszi a versenyt a tisztán hardver alapú megoldásokkal. Az elvesze csomagok száma szinten -hoz közelíte a mérések során (az iperf esetében megszoko, hogy az utolsó csomagot elveszenek jelzi, ez nem a mérési rendszer hibája). TCP kapcsolat esetében már jobban kijön a pusztán hardveres megoldás előnye. A méréseket öt alkalommal lefuatva a fenti eredményekből jól látszódik, hogy az i-be építe hardveres TCP offloading nagyjából ötször jobban teljesít, mint ahogy azt a számítógép központi processzora számítja. Elméletileg a VMXNET-as paravirtualizált adapter is rendelkezik ezen képességgel, de látható, hogy sokkal rosszabb eredményt ért el a mérések során.
4. Konklúzió A dokumentumban röviden összefoglaltam az x I/O virtualizáció state of the art technológiáit. Bemutaam egy működő alkalmazási példát, ahol röviden körüljártam a beállítási lehetőségeket, valamint példával illusztráltam az automatikus DMA/IRQ fordítást.
Hivatkozások [] Intel® LAN Access Division, “PCI-SIG SR-IOV Primer”, Tech. Rep., Intel Corp., . [] Dániel Darvas and Gergő Horányi, “Intel és AMD technológiák a hardveres virtualizáció megvalósítására”, Házi feladat, . [] Tamás Garaczi, “Intel VT-d (IOMMU) technológia részleteinek megismerése”, Házi feladat, . [] D. Abramson, J. Jackson, S. Muthrasanallur, G. Neiger, G. Regnier, R. Sankaran, I. Schoinas, R. Uhlig, B. Vembu, and J. Wiegert, “Intel® Virtualization Technology for Directed I/O”, Intel® Virtualization Technology, vol. , no. , .
[] Brian Johnson, “No SR-IOV support in igb under ESXi ”, on Twier, .
F Függelék F.1. kód: Az Ethernet csatolók kioszto erőforrásai a vendég OS-ben 02:00.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) (rev 01) Subsystem: VMware PRO/1000 MT Single Port Adapter Physical Slot: 32 Flags: bus master , 66MHz, medium devsel , latency 0, IRQ 18 Memory at d1020000 (64-bit, non-prefetchable) [size=128K] Memory at d1000000 (64-bit, non-prefetchable) [size=64K] I/O ports at 2000 [size=64] [virtual] Expansion ROM at dc400000 [disabled] [size=64K] Capabilities: [dc] Power Management version 2 Capabilities: [e4] PCI-X non-bridge device Kernel driver in use: e1000 Kernel modules: e1000 03:00.0 Ethernet controller: Intel Corporation Device 1533 (rev 01) Subsystem: Intel Corporation Device 0001 Physical Slot: 160 Flags: bus master , fast devsel , latency 64, IRQ 18 Memory at d2800000 (32-bit, non-prefetchable) [size=8M] Memory at d2400000 (32-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable - Count=1/1 Maskable+ 64bit+ Capabilities: [70] MSI-X: Enable+ Count=5 Masked Capabilities: [a0] Express Endpoint , MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number a0-36-9f-ff-ff-0c-71-c6 Capabilities: [1a0] Transaction Processing Hints Kernel driver in use: igb Kernel modules: igb 0b:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) Subsystem: Intel Corporation Ethernet Server Adapter I350-T4 Physical Slot: 192 Flags: bus master , fast devsel , latency 64, IRQ 19 Memory at d3100000 (32-bit, non-prefetchable) [size=1M] Memory at d3004000 (32-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable - Count=1/1 Maskable+ 64bit+ Capabilities: [70] MSI-X: Enable+ Count=10 MaskedCapabilities: [a0] Express Endpoint , MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number a0-36-9f-ff-ff-00-86-a8 Capabilities: [150] Alternative Routing -ID Interpretation (ARI) Capabilities: [160] Single Root I/O Virtualization (SR-IOV) Capabilities: [1a0] Transaction Processing Hints Capabilities: [1c0] Latency Tolerance Reporting Capabilities: [1d0] Access Control Services Kernel driver in use: igb Kernel modules: igb 13:00.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01) Subsystem: VMware VMXNET3 Ethernet Controller Physical Slot: 224 Flags: bus master , fast devsel , latency 0, IRQ 16
Memory at d3205000 (32-bit, non-prefetchable) [size=4K] Memory at d3204000 (32-bit, non-prefetchable) [size=4K] Memory at d3202000 (32-bit, non-prefetchable) [size=8K] I/O ports at 6000 [size=16] [virtual] Expansion ROM at dcc00000 [disabled] [size=64K] Capabilities: [40] Power Management version 3 Capabilities: [48] Express Endpoint , MSI 00 Capabilities: [84] MSI: Enable - Count=1/1 Maskable - 64bit+ Capabilities: [9c] MSI-X: Enable+ Count=25 MaskedCapabilities: [100] Device Serial Number ff-29-0c-00-49-2b-b6-fe Kernel driver in use: vmxnet3 Kernel modules: vmxnet3
F.2. kód: Az Ethernet csatolók kioszto erőforrásai a hypervisor-ban #i350 - DirectPath 0000, 0600, 80861521, 78, fa700000 , 0, 0, fa6fc000 , 0, 0, fa600000 , 100000, 0, 0, 4000, 0, 0, 80000 #i350 - vmnic 0000, 0601, 80861521, 88, fa500000 , 0, 0, fa6f8000 , 0, 0, 0, 100000, 0, 0, 4000, 0, 0, 0, igb #i350 - DirectPath 0000, 0602, 80861521, 98, fa400000 , 0, 0, fa6f4000 , 0, 0, 0, 100000, 0, 0, 4000, 0, 0, 0 #i350 - vmnic 0000, 0603, 80861521, a0, fa300000 , 0, 0, fa6f0000 , 0, 0, 0, 100000, 0, 0, 4000, 0, 0, 0, igb #i210 - DirectPath 0000, 0700, 80861533, 70, fb000000 , 0, 0, fbefc000 , 0, 0, fa800000 , 800000, 0, 0, 4000, 0, 0, 800000
