Virtualizációval kapcsolatos interoperabilitási megállapodást kötött a Red Hat és a Microsoft

AlmaLinux, CentOS, Fedora, Red Hat, Rocky Linux

A Red Hat és a Microsoft bejelentették, hogy az erős ügyfél oldali igényre válaszként megállapodási szerződést kötnek, amelynek értelmében javítják a virtualizációs termékeik közti interoperabilitást. Mindkét cég vállalta, hogy csatlakozik a másik fél virtualizációs/certifikációs programjához és technikai támogatással látják el egymás szervervirtualizációs ügyfeleit.

A megállapodás főbb pontjai:

  • a Red Hat érvényesíteni fogja / jóvá fogja hagyni a Windows Server 2003 SP2, Windows 2000 Server SP4 és Windows Server 2008 guest-eket a Red Hat Enterprise virtualizációs tecnológiákon
  • a Microsoft érvényesíteni fogja / jóvá fogja hagyni a Red Hat Enterprise Linux 5.2 és 5.3 guest-eket a Windows Server 2008 Hyper-V (összes verzió) és Microsoft Hyper-V Server 2008 termékeken
  • miután a két vállalat befejezte a teszteket, az érvényes támogatási szerződéssel rendelkező ügyfelek együttműködő technikai támogatást kapnak a Microsoft-tól és a Red Hat-tól
  • a tervek szerint a két vállalat jövőbeli termékei is érvényesítésre kerülnek ennek a megegyezének az értelmében
  • ez a megegyezés nem tartalmaz szabadalmi vagy nyílt forrás licenceléssel kapcsolatos elemeket
  • a megegyezéseknek a bevizsgálás/certifikáció díjain túl nincs anyagi záradéka, pontja

A részletek itt olvashatók.

( Yorirou | 2009. 02. 17., k – 20:32 )

Most akkor a boycottnovell után lesz boycottredhat is?

"PHP's coding style pulls common elements from C++, Java, PERL, Python, BASIC, Assembly, Dragonspeak, and Microsoft Office Excel."

ezt megirta a groklaw is. az o interpretaciojukban ez egy teljesen jo megallapodas, ahol a redhat megmutatta, hogy kell korrekt paktumot kotni a microsoft-tal. en egyetertek, mivel itt nincs szabadalmi megallapodas, es nem kotnek szabalmi kulonalkut, amivel gyengitenek az osszes tobi opensource szallito poziociojat a sajat rovidtavu erdekeik kiszolgalasaert cserebe (lasd meg Open Invention Network).

- Use the Source Luke ! -

( turul16 v | 2009. 02. 18., sze – 06:47 )

Nem sirnek, ha para/full virtulizaciot tamogato technikak ugyanazt az imaget tudnak hasznalni.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

+1
És a virtuális gép a valóságba is rendelkezne a hordozhatóság előnyével, nem csak papíron. Gyakorlatilag az összes virtualizáció a fizikai gép processzorának típusát mutatja befele a virtuális gép felé is. Namost ha telepítesz pl. egy XP-t egy core2duo-n, hiába viszed át az imaget egy amd-re, úgy elhal kékhalállal, hogy öröm nézni (tapasztalat). A windows nehezen viseli ha fontos hardvert kirántanak/lecserélnek alóla.
[Szerk] Ezzel azt akartam mondani, hogy jó lenne, ha lehetne választani processzortípust ugyanúgy ahogy pl. hálókártyát, amit behazud a virtuális gépnek (pl. P4, Core2duo, Core2quad, Amd, Amd X2 szerintem elég is lenne...).
--
Discover It - Have a lot of fun!

Amennyire értek a népszerű virtalizációs megoldásokhoz, azok a CPU-t _NEM_ emulálják. Azt adják a guestnek, ami a gépben van. Ha tetszőleges CPU-t adnának, vagy egy általános, virtuális CPU-t, úgy annak működését is emulálni kellene. Ez igen jelentős teljesítménycsökkenéssel oldható csak meg.
Amúgy nem új dolog, vannak ilyenek, lásd a különböző nyolc bites gépek emulátorait. Lényeges viszont, hogy ezeket a nyolcbites CPU-kat nagyságrendekkel erősebb gépeken lehetséges úgy emulálni, hogy a teljesítményük elérje a valódi processzorokét.
Másik megoldás, hogy emuláció helyett valódi processzort használnak, amely egy bővítőkártyán foglal helyet. Így lehetett a régi, PPC processzoros Apple gépeken Windowst futtatni mint guestet. De ez, az extra hardware igény miatt, elég drága megoldás.

Ave, Saabi.

Amennyire értek a népszerű virtalizációs megoldásokhoz, azok a CPU-t _NEM_ emulálják
Igen, pont erről beszélek, és ez a "problémám". Ezáltal nem lesz a virtuális gép igazán hordozható.
Nemcsak a működését, hanem az utasításkészletet, illetve az emulált processzor által ismert, azonban a fizikai által nem ismert utasításokat implementálni/átfordítani kell, ami nem kis munka és fejlesztés... De ha ez megvalósul, akkor tényleg mindegy lenne, hogy milyen fizikai hardveren fut, ez lenne az igazi hordozhatóság.
--
Discover It - Have a lot of fun!

Nem tudom mennyi esetből szűrted mindezt le, de az én tapasztalatom azt mutatja, hogy a processzor típus miatt NINCS probléma a vm-ek portolhatóságával. Tehát biztosan nem a processzor miatt szált el neked az XP-d.

VMware estén csak VMotion-t nem lehet ilyenkor használni, tehát a nem kompatibilitás futás közbeni áthelyezés esetén igaz, de leállítva és másik procin elindítva nincs ilyen probléma.

Sokkal inkább a windows butasága okozza a nem hordozhatóságot, ugyanis abba szokott inkább belefagyni, ha a diszkvezérlőt cserélik alatta.... Ez az ami változhatt a virtualizációs technikák, de még egy gyártón belül is (pl VMware esetében lehet ide-s vagy SCSI diszket/vezérlőt is adni egy vm alá)

Hozzátenném, hogy más oprendszereket ez sem zavaraja ennyire.

Azt hogy a procit miért nem virtualizálják, már leírták előtttem...

Tehát biztosan nem a processzor miatt szált el

Óvakodjunk a "biztosan" szó használatától, ha egy mondattal előtte "az én tapasztalatom" szerepel.

Hozzátenném, hogy más oprendszereket ez sem zavaraja ennyire.

Sőt, más oprendszereknél még a 64 bites kernel is képes futni a 32 bites architektúrán, nem?

Igazad van, túl lazán fogalmaztam ;)

Az 'én tapasztalatom' elég sok esetet lefed, csak erre értettem...

Nyilván, a 64 bites kernel nem fog menni 32 bitesen, mindegy hogy MS, vagy Linux, vagy más.

Hogy tiszázzuk a virtualizáció vs processzor témát:

A fenti félreértést tisztázandó, 64bites kernel csak 64 bites vason bootol, sőőt más architektúrára is ugyan ez érvényes :) A továbbiak azonos architektúrán belül értendőek:

A processzor általában nem virtuális eszköz, a vm is pont azt látja, ami valójában alatta van. Lehet azonban maszkolni bizonyos képességeket/utasításkészleteket, ezzel növelve a köztük lévő kompatibilitás mértékét ám ezek csak online áthelyezéskor (pl VMotion) okoznának problémát és most tudtommal nem arról beszélünk...

Mivel a processzor 'driver' a kernelben lakik és nélküle ugye nem is lehetne továbblépni, ezért ez boot során látja, hogy miket tud az adott proci, és ezek után használni is engedi ezeket a fícsöröket az alkalmazások számára.

Amint leállítod, és bootolsz egy másik (azonos architektúrájú) processzoron, akkor megint tudni fogja a kernel, hogy az új proci mit tud, és ezzeket elérhetővé is teszi az alkalmazások számára. Tehát csak attól hogy új (de a kernel által támogatott) procira kerül egy vm, még nem fog kékhalálozni.

Ha ténylegesen a proci miatt hasal el, akkor az már a boot során kiderül, de ezesetben az a kernel egyébként sem menne azon a procin... Olyat én még nem láttam, hogy egy oprendszer feltelepül mindkét procira, de ha egyikre telepíted az nem vihető át a másikra (amire egyébként feltelepülne) - erre utaltam a 'biztosan nem az a baj' kifejezéssel.

64bites kernel csak 64 bites vason bootol, sőőt más architektúrára is ugyan ez érvényes :)
De egy 32bites kernel vagy egy 16bites dos ugyanúgy indul egy 64bites procin is :)

Ha ténylegesen a proci miatt hasal el, akkor az már a boot során kiderül, de ezesetben az a kernel egyébként sem menne azon a procin... Olyat én még nem láttam, hogy egy oprendszer feltelepül mindkét procira, de ha egyikre telepíted az nem vihető át a másikra (amire egyébként feltelepülne)
Pedig így van... A windowsnál ez valami nagy baromság, ugyanis az alapvető hardverekről az információt telepítéskor detektálja, beírja registrybe, és azt olvassa be, aszerint kezeli.
--
Discover It - Have a lot of fun!

Mivel a processzor 'driver' a kernelben lakik és nélküle ugye nem is lehetne továbblépni, ezért ez boot során látja, hogy miket tud az adott proci, és ezek után használni is engedi ezeket a fícsöröket az alkalmazások számára.

Feltudnád sorolni akkor pl. Linux esetén ezeket a processzor 'drivereket', hogy hol helyezkednek el és mi alapján töltődnek be run-time? ;)

Amint leállítod, és bootolsz egy másik (azonos architektúrájú) processzoron, akkor megint tudni fogja a kernel, hogy az új proci mit tud, és ezzeket elérhetővé is teszi az alkalmazások számára.

Kivéve, ha már el se jut odáig, mert maga a kernel próbálna olyan utasításokat végrehajtani bootkor, amelyeket az adott processzor nem képes értelmezni.

Értsd mire gondolok:

CONFIG_MK8 alapján fordított Linux kernel egyáltalán nem biztos, hogy bootolni és normálisan futni fog egy Intel Core2 processzoron (és vice versa), mert eleve a C fordító az AMD-s CPU-ra optimalizálta (-march=k8) a kernel kódját.

És itt aztán nem fogja a Linux kernel detektálni induláskor, hogy hopsz másik CPU-n futok, mint amire a saját kódom fordítva lett... Persze lehetne, csak nem tudna vele mit kezdeni. Ezek a konfig paraméterek nem olyanok, amelyeket te modulba, 'driverbe' fordíthatsz, aztán majd a userland init után betöltődik az adott típusnak megfelelően. Nyilván ha valami generic processzor optimalizáció van kiválasztva (pl. CONFIG_M386, ami sima -march=i386-ot jelenti), akkor lehet hurcolni 386-kompatibilis gépek között a kernelt és működni is fog (disztribúciók ezt is csinálják, illetve most már inkább 686-al a legtöbb), csak maga a kernel ettől még nem fog semmiféle 'drivert' betölteni, amelynek köszönhetően az ő saját kódja mégis az adott típusra optimalizáltan fog futni majd menet közben. Az alkalmazások persze már kitudják használni az adott processzor előnyeit, csak az már egy másik téma.

Windows adott esetben akár azért sem működhet, mert a telepítő az adott HAL-t állítja be telepítéskor és áthelyezve másik gépre, ott az nem lesz megfelelő. Pl. felkerül egy ACPI Multiprocessor PC-re, aztán át lesz mozgatva egy MPS Uniprocessor PC-re. Ilyen esetben nem fogja automatikusan kiválasztani a másik HAL-t... Persze virtualizációnál nem feltétlenül ez lesz a probléma, de ott is előfordulhat, ha különböző VM termékek között történik a mozgatás és másmilyen architektúrát virtualizál a kettő (pl. az egyik acpi a másik non-acpi, vagy az egyik apic a másik csak pic, stb.).

ugyanis abba szokott inkább belefagyni, ha a diszkvezérlőt cserélik alatta....
Meg alaplap+processzor. Itt nyilván nem egy más típusúra való váltásra gondolok (pl. egy E6300 -> E7200, de még celeron/p4 is belefér sztem), hanem AMD->Intel. Hasonlóan alaplapnál pl. egy NForce->ICH váltás is igencsak megfekteti, nemcsak a hdd vezérlő változása miatt. Ugyanakkor egy ICH9->ICH10 váltást nagy valószínűséggel észre se vesz.

Való igaz, más rendszerrel nincs ennyi baj, egy linux pl. majdnem biztos hogy elindul, másnem döglassan egy ide_generic-kel, de ott már tudod kalapálni :).
--
Discover It - Have a lot of fun!

Az a baj, hogy ahhoz, hogy másik processzort adj meg egy virtuáls gépnek, ahhoz a host gép processzora által nem végrehajtható utasításokat emulálni kell. Van ilyen megoldás, pl. a qemu. Kqemu nélkül minden utasítást átfordít a fizikai processzorra, függetlenül attól, hogy a procid támogatja-e az adott utasítást, vagy nem. Ebből következik, hogy a kqemu megmondja a qemu-nak, hogy ne fordítgassa az utasításokat, hanem csak adja át egy az egybe a processzornak, ezáltal gyorsítva a guest os futásán. Ennek viszont az a hátránya, hogy azok az utasítások, amiket a procid nem tud, nem lesznek engedélyezve.
Ha láttál már qemu-t, akkor azt is tudod, hogy iszonyatosan lassú, még kqemuval is. Ez szerintem azért van, mert alapértelmezés szerint fordítgatnia kell az utasításokat, és ha aláteszed a kqemu-t, akkor sem lehet minden kódot megkerülni.

A virtualbox, vmware pedig alapból úgy működik, ahogy a qemu+kqemu, ezért szépen ki lehetett optimalizálni. Ezért futnak gyorsan.

Hozzáteszem, nem értek hozzá, lehetnek hibák a gondolatmenetben. :)

> hiába viszed át az imaget egy amd-re

http://www.hwsw.hu/hirek/37401/amd_red_hat_elo_virtualizacio_live_migra…

A demonstrációban egy kétutas, négymagos Intel Xeon processzorokra épülő szerveren futó virtuális gépet mozgattak át négymagos AMD Opteron chipeket alkalmazó gépre, annak leállítása nélkül -- közben folyamatosan videót játszott le. Ezt követően a virtuális gépet az AMD legújabb Shanghai processzorára migrálták. Ez az első alkalom, hogy a nyilvánosság előtt bemutattak ehhez fogható képességet.