vmware hostod linuxon fut?
Írnak a doksiban valami Virtual network editorról - van ennek valami helyettesítője linux alatt? Vagy nyugodjak bele, hogy torkosborz kategóriába tartozik a linuxos hálózatkonfigurálás?

...

Valaki azt mondta, ne merjem a Debiant bugosnak nevezni...
Stabil verzió, apt-get update ; apt-get dist-upgrade szerint mindenből a legfrissebb van telepítve.

Xen-3.2.1 - végre sikerült bebootolni egy hvm domaint (úgy, hogy letiltottam rajta a hálózati kommunikációt, mert egyébként egy szó hibaüzenet sem jön ki belőle, de vagy el sem indul vagy még a boot előtt meghal, mindenesetre konzolnak olyankor nyoma sincs és az xm list kimenetében csak néhány mínusz jel virít a domain állapotát jelző mezőben).

Hurrá, akkor játsszunk vele egy kicsit: a bebootolt rendszer egy grml live cd. Karakteres módban működni látszik, csak pl. az mc képernyője szemetes lesz (vélhetőleg valami nincs rendben a képernyő frissítéssel).
Elindítom a grafikus felületét... igaz, elindul, de a xenwatch következetesen dob egy hátast ennek örömére:

# xenwatch
Desktop: Gnome
The program 'xenwatch' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
(Details: serial 36778 error_code 2 request_code 145 minor_code 3)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)

Ugyanez vncviewer-rel már majdnem jó, mert legalább megjelenik a konzol. Igaz, amint az egérhez érek:
# vncviewer
Connected to RFB server, using protocol version 3.8
No authentication needed
Authentication successful
Desktop name "Xen-grml"
VNC server default format:
32 bits per pixel.
Least significant byte first in each pixel.
True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Using default colormap which is TrueColor. Pixel format:
32 bits per pixel.
Least significant byte first in each pixel.
True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Same machine: preferring raw encoding
Rect too large: 96x768 at (1280, 0)

------------------
Készséggel elhiszem, hogy van ahol működik és stabilnak, bugmentesnek látszik, de ne csináljunk már úgy, mintha tökéletes lenne... mi a ...-t csináljak vele, ha nekem történetesen hvm konfigurációra van szükségem, grafikus felülettel?

...

Egyébként készséggel elhiszem, hogy nem a debian tehet róla (ha jól emlékszem, ez a hiba a vnc működésére lett visszavezetve), de amikor az ember rendszeresen ilyenekbe ütközik... Hát no comment. Ilyen szempontból lényegesen elégedettebb vagyok a MS szoftverekkel.

...

Nem. Bár a vga-nak két kimenete van.

...

Miután kikapcsoltam a bridged interface-t a konfigban, nekem is kb 30mp volt, mire működőképessé vált a grml karakteres felülete.

Gáz csak akkor van, ha ott X-re váltok. És hangsúlyozottan a friss grml live esetében (bár ez asszem telepítve is lehetne), mert az kicsit másképp működik, mint egy normál debian!
(valami framebufferes eszköz rémlik az X alatt, de nagyon rég néztem ilyen szempontból).
Lenny-re épül a Dom0, azon van a (hibás???) vncviewer, ami nem bírja a gyűrődést bizonyos esetekben. Már nem emlékszem pontosan, kissé álomkóros voltam, mikor abbahagytam a játszadozást, de mintha az xm new-val létrehozott guesten kiakadna, az xm create-tel elindított viszont működik normálisan...

Kíváncsiságból felraktam egy XP-t is, az kb. annyi idő alatt ment fel, mintha nem is virtuális gépben lenne és működik... pardon: elindul.

Ami még kiakasztott: van a Xen-nek is live cd-je, amivel lehet próbálgatni a rendszert, előre telepített virtuális gépekkel. Ez a desktop gépemen emlékeim szerint gond nélkül működött. Este még beraktam a notebookba úgy, hogy nem volt hálózatra (ethernetre) dugva a gép. Egyik virtuális konzolt sem tudtam elérni a virt-managerből, de hibaüzenet sem jött. Egyéb úton már nem próbáltam, mentem aludni.

...

xen0:~# xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 3529 2 r----- 129.1
grml 4 128 1 ------ 0.0
xp 2 263 1 -b---- 106.6

Kb. ez a jelenlegi állapot. Ebből a grml a ciki, mert amíg nem akarok hozzáadni egy network interface-t, addig működik. Amikor hozzáadok (akár konfig file-ban, akár utólag xm network-attach segítségével), totálkárossá válik. Mivel jelenleg a xend kezelésében van, nem tudom eltávolítani sem. Ha xm delete-tel próbálkozom, akkor az a baja, hogy nincs halted állapotban. Ha destroy-jal irtom ki, akkor ott marad a név, eltűnik mellőle az ID, de eltüntetni a rendszerből csak reboottal lehet. Az xm log-ban debug üzenet van rengeteg, de hibát nem látok.

Szerencsére annyira működik távolról is a virt-manager, hogy le tudtam kapcsolni (xm help-ben nem találtam hirtelen forced poweroff-t - gondolom, valahol van, mert valahogy a virt-manager is meg tudta csinálni)

---
Az már csak nüansznyi probléma, hogy míg az ubuntu-n ha elindítok egy vnserver-t, akkor gond nélkül rá tudok jelentkezni, ha ezen a debian-on (a Dom0-n) indítom, akkor egerészni tudok a vncviewer ablakban (windows-ról), de a billentyűzet megbolondul: a legtöbb billentyűre csak egy backslash a reakció. Közben kipróbáltam linuxos vncviewer alól is, ott is ez a helyzet. Mondjuk ezt okozhatja, hogy eltérő billentyűzet kiosztással működik a vncserver és a vncviewer (?) .
Megpróbáltam egér segítségével átállítani a debian desktopon a bill. kiosztást, de valamelyik gnome démon elhasalt.
Az eltérő kiosztás még lehet az én hibám, de hogy megdöglik a gnome-setup (?) démon, azt azért nem vállalnám magamra.

----

Szóval amikor anyázok itt szép csendben, hogy bughalmaz, akkor ilyesmikre gondolok.
Ezek a normál napi üzem során nem jönnek elő, mert ha egyszer elindult a környezet, akkor viszonylag ritkán cseszteti az ember és megvannak a kipróbált kerülőutak, ha másképp nem megy.

...

Billentyűzet probléma megoldva: másik vncserver kellett, mert a tightvncserver finoman szólva nem 100%-os, ahogy a fórumokat böngésztem.

...

Mert kissé beteg vagyok (egyéb esetekben meg lusta), a desktop gépem a lakás egyik végében, a laptopom és az ágyam a lakás másik végében.

---

network probléma megoldva (a'la bambano és tsai ) : szar a mintakonfig, az eth0 helyett a már elavult(???) és nem létező xenbr0-ra hivatkozik. Ha ezt átírom eth0-ra, akkor már megy a bridged networking. Mondjuk az még nem teljesen tiszta, hogy miért hívják eth0-nak a bridge eszközt... de ez valószínűleg a hiányos ismereteim következménye (én általában br0 v. hasonló névvel szoktam illetni)

"a'la ..." = ugye ki lehetett javítani, de ez nem magyarázat arra, hogy az elkefélt konfiggal miért fagy ki ennyire, szinte kipusztíthatatlanul a guest/domU ? Miért nem ismeri fel a xen, hogy rossz a konfig és kapcsolja ki a gépet? Bennem meg ez marad meg, hogy már megint szoptam valamivel, pedig nem kellett volna, ha...

[ Szerkesztve ]

...

És ha nem default beállításokkal használom a grml grafikus felületét, akkor a vncviewer sem döglik meg (tehát működőképessé tehető, de... lásd előző... )

...

Én ezt találtam, ebből raktam össze.

Konkrétan milyen grafikus felületre gondolsz?

Környezeti feltételek: vistáról minimális erőfeszítéssel, ingyenes klienssel elérhető legyen, és elfogadható sebességgel működjön. Mivel a vnc kliensre mindenképp szükség van, ha innen el akarom érni a konzolokat, tehát az már telepítve van... ráadásul az egyéb grafikus próbálkozásaim performanciája hagyott némi kívánnivalót maga után. (gondolok itt a lokális X szerverre)

...

Egyébként köszi a címet, van benne egy-két érdekesnek látszó apróság.

...

Ami az X-et illeti... végülis, ha nem akaszt ki túl sűrűn ez a vistára rakott vmware-be telepített ubuntu, akár még működhet is a dolog.
(eredetileg nem állt szándékomban megtartani, de egyelőre nem fogja vissza a rendszeremet olyan mértékben, hogy zavaró legyen)

...

Tudom, ez sem a debian hibája, mégis izgalmasan hangzik:

"this function is not supported by the hypervisor: virConnectNumOfDefinedNetworks"

Ezt egy egyébként működőképes hvm guestre kaptam, amikor a Virtual Machine Managerben megpróbáltam a kikapcsolt géphez hozzáadni egy disk image-t...

...

Az meg továbbra is érdekes, hogy vajon a xend miért nem bírja elviselni a /etc/init.d/xend restart parancsot. Úgy kifekteti a hálózatot, hogy a köv. rebootig nem tudom feléleszteni.

...

Lehet, hogy én keféltem el: benne maradt egy sor a xend-config-ban, amit a howtoforge-on talált leírás szerint commentbe kellett volna tenni.(valami '(network-script network-dummy)' ha igaz...) Miután azt kivettem, úgy tűnt, működik a stop/start.
Szóval jó-jó, hogy az ehhez hasonló megakadások a figyelmetlenségemből jönnek, de az ilyen reakcióitól valahogy a falnak tudnék menni...

Te tudod egyébként, hogy mit okoz ha a (network-script network-dummy) sor _és_ a (network-script network-bridge) egyszerre vannak jelen a konfigban?
Azon túl persze, hogy felakad a xend szeme egy restartnál... (szerk: itt most nem arra gondolok, hogy megkeresed doksiban vagy neten, mert az nekem is megy... )

[ Szerkesztve ]

...

Lehet... kis időre leálltam a játszadozással, fontosabb lett a fényképezőgépem.
Tegnap még annyit bírt csinálni a kis aranyos, hogy boot után nem volt elérhető egyetlen virtuális gép konzolja sem (vnc), miközben a netstat -lntu kimenetében ott volt, hogy rajta ül az 5900-as porton... Reboot és működött... éljen a stabilitás!

Ubuntun meg a virtualbox csinál olyan kedves vicceket, hogy a startupkor elindított virtuális gépek indításába 10-ből egyszer belefagy a VB és rebootig max. egy zombie állapotot tudok belőle kicsikarni.

[ Szerkesztve ]

...

Elméletileg mindegy a sorrend, gyakorlatilag jobb, ha először a windows-t rakod fel és csak utána a linuxot.
Kérdés, hogy mennyire akarod komolyan használni a linuxos rendszert?
Lehet, hogy első menetben érdemesebb felrakni vagy a MS saját virtualizációs szoftverét (régi neve VirtualPC volt, a win7 alatt futtathatóra nem emlékszem, de mintha valami más lenne) vagy egy VMware Playert és abba telepíteni a linuxot. Kevesebb a nyűg vele és nehezebb egy mellényúlással tönkretenni a windows-t.

szerk: arra azt hiszem, még mindig vigyázni kell, hogy a windows alatt ne dinamikus diszkként használd a diszkedet, mert azzal a linux nem boldogul, ha külön telepíted.

[ Szerkesztve ]

...

Nagyon alap debian (lenny)... hát nem akarok nagy hülyeséget mondani, de kb. 2GB-ra emlékszem + swap.
Vistát szinte biztosan tud indítani a grub, win7-ről nincs infom.

...

Megnéztem: 4GB-ban már egy gnome is elfért.

...

persze. Melyik verzió? Ha régi, akkor a /boot/grub/menu.lst file-ban a title kezdetű sorokat kell nézni.

...

Menüből nem tudom hogy lehet root jogot szerezni, nagyon ritkán használom ilyesmire a GUI-t.
Terminálból valami "sudo vi /boot/grub/menu.lst" - vi helyett talán van nano vagy mintha a gnome-os editort gedit-nek hívnák...
A KDE+hálózat kérdést passzolom.

...

????????????????????????? mi az, hogy "nem debianos"???

...

Hmmm... még nem is hallottam arról, hogy ubuntu nevű disztribúció létezik (tán nem is létezett), amikor sudo-t használtam.
Miért elwindows-osítás az, ha valaki nem root-ként használja a rendszerét?
Komolyan nem értelek.

...