Virtualizáció

Sziasztok,

a kovetkezo problemaval szembesultem, segitsegeteket kerem:

van 2db azonos 64bites IBM szerverem Xeon procikkal, melyekre Ubuntu 8.04.1 64bit ment fel, a disztribben talalhato 3.2-es XEN hypervisorral.
egy DRBD-s clustert akarok osszehozni vele, a drbd kesz, jol mukodik.
domU-nak egy szinten 8.04 ubuntut hasznaltam, eloszor egy 32 bites verziot, majd egy 64 bitest.

amikor kiadom az "xm migrate vm01 node2 --live" parancsot, vi. migrald at a vm01-et a 2-es node-ra, a kovetkezo tortenik:

32 bites domU-ban: bizonyos halozati funkciok megbenulnak, a top szerint a CPU 99.9% minden processhez.
mintha megallna az ido a domU-ban, lebenul a halozat, nem megy a ping, stb. (pl 10 mpig futtatva a pinget ezt kapom:
1 packet send, 1 packet received, 0% packet loss, de a maradek 9 csomag mar ki sem megy.

64 bites domU-ban: a jelenseg ugyanez, annyi kulonbseggel, hogy a top szerint a CPU oszlopban vegig "nan" kifejezes lathato, de szinten nem mukodik a halozat.

mind a 3 gepen (2xdom0 es domU) az orak szinkronban jarnak (NTPDATE+NTP)

meg 1 erdekesseg, nem tudom, ez szamit-e:
ha az 1-es nodeon inditom el a DomU-t, es atmigralom a 2-esre, akkor leall a domU, de ha visszamigralom, akkor mukodik ujra.
illetve, ha a 2esen inditom el,akkor mukodik, es ha atmigralom az 1-esre,akkor is, de ujra visszamigralas utan ujra megall.

ennyit tudtam kihamozni eddig, google nem adott ertelmes infot.

segitsegetek elore is koszonom
Zs.

Debian Project News levelet olvasgatva akadt meg a szemem az alabbin:
"The following packages were added to the unstable Debian archive
recently ([42]among others):
...
* [71]linux-image-2.6-xen-amd64 -- Linux 2.6 image on AMD64, oldstyle
Xen support"

Amit nemigazan ertek h miert oldstyle? A xen-linux-system-2.6.26-1-xen-amd lenne a "newstyle"?
Egyaltalan mi a kulonbseg a ketto kozt? Van lenyegi elteres vagy most ez hogy van?

SLED10 es hoston w2k-t telepitenek halozati serverrol Vmware 6.0.2 re de nem hajlando bootolni. A virtualis gepet masik geprol viszont tudom pingelni. Masik ugyanilyen konfiguracio pedig siman bootol es azonnal telepul.

Hello!

Kinek van mar tapasztalata a cimben szereplo temaval?
DomU-knak kellene megoldanom 2. interface 802.1q vlan-al szeparalt reszeit kiosztani akar ugy h domU-ban beallitva a vlanokat, akar ugy h dom0-ban vlanok felhuzasa es azok bridge-elese guest-eknek. Egyenlore egyiket se sikerult elernem, probaltam 3.0 es 3.2-es xen-el is de minden esetben csak magat az interface-t sikerult atadnom a guest-nek ugy h mukodjon is, vlanokat mar sehogy se.
Kinek hogy sikerult ezt megoldani vagy mi kell hozza?

Elore is koszi!

egy webportál átalakítása kapcsán felmerült virtuális gép használatának a bevezetése. az ok, a régi webportált fejlesztő rendszergazda már nem dolgozik a cégnél, és hátrahagyott egy eléggé gány kódból álló php rendszert. ügyeletesen túlterheli az új nagyobb server erőforrásait is, például amikor backupolja az anyagot, eléggé szerencsétlen módon. mysql loadja ilyenkor az egekbe szökik, pedig a feladat ezt nem tenné szükségessé. jelenleg szerencsésebbnek tűnik egy teljesen új webportál felállítása, de a régire is szükség van folyamatosan. amíg nem sikerül befoltozni az összes hibát a régi rendszeren, illetve portolni az abban található összes adatot és funkciót az újra, párhuzamosan kellene működnie a kettőnek. a legjobb megoldás az lehetne, ha a régi rendszer egy virtuális gépre költözne, még az új stabil webportál közvetlenül a host rendszeren menne. azonban biztosítani kell, hogy a régi rendszer a ne tudja felemészteni a host összes erőforrását. a guest gépek ram memóriáját a legtöbb virtuális gép keretek között tudja tartani. a processzor időt melyik virtualizátor tudja hasonló módon adott keretek között tartani? valami radikálisabb megoldásra gondoltam, mint a virtualizátor program nice szintjének az állítgatása. konkréten meghatározott mips, vagy a host procidejének a meghatározott maximális %a.
xen, vmware, virtualbox, qemu, openvz, kvm stb. melyik erre a legalkalmasabb?

AMD64es host rendszeren lehet e 32bites x86 guest rendszereket használni? mennyire megbízható egy ilyen megoldás? van e teljesítménybeli veszteség amd64 host és x86 guest esetében, x86 host és guest rendszerhez képest?

az egyre emelkedő villanyárakra tekintettel változtatnék egy jelenlegi kisebb soho hálózaton. most egy ipcop tűzfal mögött találhatóak a gépek. az ipcop egy pentium2es IBM gépen lakik, a red, green, orange és blue zónák mindegyike használatban van. green, munkaállomások; orange, server; blue, wifi; red az internet. ezeket költöznének egy intel atom alapú kis fogyasztású pcre.
ezen az atom alapú pcn egy linux alapú host rendszer lenne, 3db software raid5 HDDvel, rajta két virtuális gép,
#1 virtuális gép látná el a tűzfal szerepét. ide költözne az ipcop.
#2 virtuálos gép a serverfunkciókat látná el. ide költözne a jelenlegi server, eddigi feladatai kiegészülnének fileserver szolgáltatással.

így a munkaállomásokból kikerülhetnének a winchesterek, csökkentve a fogyasztást és növelve az adatbiztonságot. az eddig 24 órában működő p4 server és p2 firewall pc helyett csak egy kis fogyasztású atom pc maradna.
kérdések,
mennyie biztonságos egy virtuális gépen futó firewall rendszer? maga az ipcop persze secure, de alááshatja e a host OS a biztonságot? az ipcop hardened rendszer, de a host os valószínűleg nem lesz az. sajnos eltűntek a rendesen karbantartott hardened linux disztribek.
a jelenleg kapható atom alaplapokon csak 2sata csatlakozó van, és csak 1 pci. így a softraid5 3 winchesteréből csak 2 lehet sata, a harmadik pata kell legyen. mennyit ront ez az együttes teljesítményükön?
az egyetlen pci csatlakozóba egy 1gbites ethernet kártyát kell tenni, hogy a fileserver feladatokat normális sebességgel el tudja látni a munkaállomások felé. az ipcop orange interface csak virtuálisan kapcsolódik a server guesthez, de még így is marad további 3 interface és csak egy 100as ethernet van integrálva az alaplapra. ezért a többi 2 ethernet kapcsolatra csak usb ethernet kártyákat lehet használni. ezek az usb ethernetek mennyire megbízhatóak?
van értelme linux helyett más host OSt haszálni?

VMWare termékekkel több ízben ráfutottam már erre a hibára, de nem találok semmi értelmes tippet a kivédéséhez:

Most épp egy Workstation 6.5-öt használok Intrepid-en, de korábban más VMWare termékekkel is előfordult, hogy egyszer csak elvész az egérkurzorom a VM-en (xp) belül, és hiába próbálom Ctrl-Alt-tal elhagyni a VM grafikus felületét, nem lehet sehová kattintani. Sajnos az egész X-et újra kell indítani, hogy újra használható legyen az egér. Ez elég bosszantó...

Valaki találkozott már ezzel, és esetleg tud vmi ötletet hogyan lehet javítani?

vista hostra telepitettem a vmware-player-2.5.0 verziojat. a neten generaltam vmx allomanyt es telepitettem a kubuntu 8.10-es valtozatat. a problemam az hogy grafikus feluleten egerkattintaskor az egermutato ~100 pixelel a mutato melle kattint. talalkozott valaki mar ezzel a problemaval? probaltam felrakni az open-vm-tool csomagot, probaltam generalni es szerkeszteni az xorg.conf-ot (alaphelyzetben ures), probaltam vnc-n keresztul ralepni a vmware kepernyojere, probaltam a googlebol kisajtolni a valaszt de tovabbra sem mukodik megfeleloen. egy mukodo gep xorg.conf-ja erdekelne

Sziasztok!

Nemrégiben felapplikáltam a gépemre az Ubuntu Ibex-et, és VirtualBox-on felpakoltam egy egyelőre funkcionálisan megfelelően működő M$ Win XP-t, Guest Additions-t telepítettem hozzá, és így lényegében majdnem jó.

Amit viszont szeretnék, de nincs: jó lenne, ha ez az egész a tty6-on futna (indítanám én ott, de: ), méghozzá úgy, hogy a tty7-en futó X erőforrásait használja. (startx után feltételezem, nem okozna gondot a futtatás, csak memória és processzoridő szűkében vagyok így is, nem szeretnék fölöslegesen két X-et futtatni, gondolom, érthető.) Kényelmes lenne alt+ctrl+F6--F7 váltás a "két os között". Ötlet ennek megvalósítására? Elakadtam.

Hálás köszönettel:

blackrose, BRI, http://brimmortal.extra.hu/blog