[Debian 4.0/AMD64] Qemu over SSH? en meer.

woensdag 6 juni 2007 18:19

vraag 2, ik kan hier eigenlijk niks naka nada over vinden maar werkt qemu eigenlijk ook over SSH?

Ja. Toevallig heb ik zaterdag op mijn Slackware servertje een QEMU debian systeempje gemaakt. Ik log vanaf mijn werkstation via SSH in op de server. Uiteraard wel met X-forwarding (evt. even testen door te kijken of het programma xclock wil draaien). Ik had in eerste instantie dezelfde SDL error als jij, maar toen bleek ik een keer su te hebben gebruikt en dan staat je DISPLAY variable niet goed.

2) DHCP (...) deze functie wil ik onderbrengen op een linux-server met automatische DNS-update zodat wanneer een computer genaamd "mybox" bijvoorbeeld een lease aanvraagd automatisch een DNS wordt aangemaakt/geupdate. ik moet hier nog een goede tutorial voor vinden maar ik weet dat het mogelijk is. ik draai mijn eigen .lan tld hier dus tips zijn welkom.

Je zou een kijkje in mijn slackware installatie documentatie kunnen kijken (in de secties DNS en DHCP). Volgens mij is dat precies wat je wilt.

Acties:

woensdag 6 juni 2007 21:37

The what goes where now?

Verwijderd schreef op woensdag 06 juni 2007 @ 11:03:
... van debian3.4 ...

Die bestaat niet

Woody is 3.0, Sarge is 3.1, en Etch is 4.0.

2) DHCP, ik gebruik semi-statische IP-addressen welke op basis van Mac-address worden uitgedeeld door mijn Linksys RV42 router. deze functie wil ik onderbrengen op een linux-server met automatische DNS-update zodat wanneer een computer genaamd "mybox" bijvoorbeeld een lease aanvraagd automatisch een DNS wordt aangemaakt/geupdate. ik moet hier nog een goede tutorial voor vinden maar ik weet dat het mogelijk is. ik draai mijn eigen .lan tld hier dus tips zijn welkom.

Programma's waar je iig naar kan kijken zijn (ISC) dhcpd, bind9, en dnsmasq. Ik draaide vroeger dhcpd + bind9, maar bind is niet triviaal om te configureren, en bind functioneerde af en toe niet goed (nooit achter gekomen waarom). Ik draai nu dhcpd + dnsmasq, wat uitstekend werkt. Dnsmasq is een stuk makkelijker te configureren.

Dnsmasq kan ook voor DHCP server spelen, en in dat geval kan hij ook die dhcp client hostname -> DNS domain name mapping uitvoeren. Misschien dat dit ook kan met dnsmasq + dhcpd, maar dat weet ik zo snel niet.

... en hoe om te gaan met swappen over het netwerk zou ik eigenlijk nog wat meer willen weten. ik kan hier geen echte tutorials over vinden. met name dat swap gebeuren kom ik eigenlijk telkens weer op het zelfde terug: it should't be done(weet ik maar ik vroeg of het kon?).

Voorzover ik het begrijp is het probleem dat de VM algoritmen in de kernel uitgaan van het bestaan van swap. Dat zou dan vooral vervelend gedrag kunnen veroorzaken op het moment dat de geheugendruk erg groot wordt.

Maar als je machines hebt met een vrij specieke functie (zoals HTPC), en die komen onder normale omstandigheden nooit geheugen tekort, dan zou het best kunnen dat je wegkomt zonder swap, dus dat is misschien de moeite van het proberen waard.

Mocht swap toch nodig zijn; swappen naar file over NFS kan volgensmij niet (maar je zou het kunnen proberen). Linux heeft wel support voor network block devices. Daarnaar swappen zou geen probleem moeten zijn, maar ik heb geen idee hoe je dat opzet (ook op de server...).

Als dat allemaal niet werkt en je hebt toch echt een beetje swap nodig (om VM lockups te voorkomen bijvoorbeeld), dan zou je nog kunnen overwegen om een kleine ramdisk aan te maken en daar swap op te zetten.

iemand ervaring met IPv6 en Qemu? tutorials en tips?

Ik neem aan dat Qemu gewoon een virtueel netwerkdevice aanbiedt aan het guest OS. Of het guest OS daar IPv6 over gaat praten zal Qemu - neem ik aan - worst wezen. Je moet alleen kijken hoe je het host OS dan alle routing/firewalling/NATting/VPNing die je in het guest OS doet goed doorstuurt, of zorgen dat het guest OS direct toegang heeft tot de netwerkkaart (om het host OS zoveel mogelijk te omzeilen). Maar ook in dat geval zou het gebruik van IPv6 niet uit moeten maken voor Qemu, lijkt mij.

al deze taken wil ik dus 'consolideren' zo als ze dat noemen. stabilitiet en functionaliteit is belangrijker dan performance en daarom dacht ik dat QEMU wel een goei kandidaat is om al dit moois te virtualizeren op 1 server bak. ik heb de Manual en FAQ al een paar keer goed doorgelezen, ook die van XEN en VMWARE trouwens, dus ik ben er klaar voor

Ik snap dat virtualisatie bepaalde voordelen biedt, maar je moet je ook realiseren dat je het jezelf enigszins ingewikkeld maakt op deze manier, zeker ivm de routing en dergelijke. Ik vraag me dus enigszins af of de voordelen wel opwegen tegen de nadelen.

Extra functionaliteit krijg je door virtualisatie niet (tenzij je guest OS migratie naar andere servers gaat gebruiken, maar ik neem aan dat dat hier niet van toepassing is). En al die taken zouden prima in één OS moeten kunnen plaatsvinden zonder dat dat elkaar bijt. Mocht je daar toch nog bang voor zijn, dan is het aanmaken van verschillende Debian installs in chroots misschien een handigere optie.

Daarnaast: Heb je dingen als Xen of UML of KVM overwogen? Die liggen meer op software-nivo qua virtualisatie, waardoor ze vaak sneller zijn. (disclaimer: ik heb weinig ervaring met al deze pakketten)

code:
1
2
3
4
5
6
7
(!) Direct/Util: opening '/dev/fb0' and '/dev/fb/0' failed
    --> No such file or directory
(!) DirectFB/FBDev: Error opening framebuffer device!
(!) DirectFB/FBDev: Use 'fbdev' option or set FRAMEBUFFER environment variable.
(!) DirectFB/Core: Could not initialize 'system' core!
    --> Initialization error!
Could not initialize SDL - exiting
en hier gaat het mis. Qemu of eigenlijk SDL klaagt dat er geen /dev/fb device is. een snelle blik met 'ls /dev/' leert mij inderdaad dat dit device niet bestaat. maar in de manual wordt er met geen wordt gerept over de framebuffer en ook google komt niet verder dan een koreaanse website waar zelfs ik niet uitkom.

Qemu wil een grafisch 'vlak' om de GUI en de output van het guest OS te tekenen. Aangezien je geen X11 hebt (ik neem aan dat je vanaf een Windows bak putty-t?) probeert Qemu (of eigenlijk SDL) de volgende mogelijkheid: framebuffer.

Framebuffer is een manier om relatief direct het een en ander naar de videokaart te tekenen, maar dit kan maar door één programma tegelijkertijd en alleen op de computer zelf. Het heeft wel iets weg van hoe je vroeger grafische programma's onder MS-DOS draaide (qua gebruik dan, technisch gezien zijn er dingen anders).

Bij mijn weten kan Qemu geen text-only output geven (maar misschien vergis ik me daarin). In dat geval zul je toch echt een grafische output methode nodig hebben die door SDL ondersteund wordt. Als weergeven op die machine zelf geen probleem is, dan zou je kunnen proberen de framebuffer kernel modules voor je videokaart te laden, en het nog eens te proberen.

Als je het remote wil, dan is X11 eigenlijk de enige optie. Aangenomen dat je Windows draait en dus geen X server hebt, zie ik de volgende mogelijkheden:

Een X server op je Windows bak installeren (bijvoorbeeld Xorg op cygwin)
Een Unix LiveCD booten op je Windows bak (bijvoorbeeld Ubuntu)
Een Unix virtualiseren op je Windows bak (mbv VMware ofzo)
Een X+VNC-server op je Debian bak draaien, waardoor je het geheel vanaf je Windows bak met een VNC client kunt bedienen

Acties:

Verwijderd

Topicstarter

bedankt voor je zeer hulpvolle uitleg en debian3.4 bestaat inderdaad niet, ik bedoelde debian3.1r4 oftewel sarge.

ik weet dat bind9 een kriem kan zijn om te configureren, ben zelf maar overgestapt op de webmin module waarmee het wel lukte maar daarmee kun je natuurlijk geen DHCP/DNS mapping doen. dnsmasq ken ik zo niet maar ik heb wel enige ervaring met powerdns, uit mijn windows tijdperk van enkele jaren geleden waarbij je gewoon de mysql backend kon updaten en klaar was je DNS update. ik denk dat ik de DHCP en DNS server toch gescheiden wil houden om flexibel te blijven dus ik zoek iets dat de DHCP status uitleest/dumpt en dan in de DNS invoert/update maar omdat ik nog nooit een DHCPd server onder linux heb ge-installeerd zal dat vast wel een interessant en leerzaam avontuur worden. eerst een machine regelen om een DHCPd op te installeeren.

zoals mischien al een beetje uitlekt in mijn startpost wil ik dus duidelijk modulair in de zin dat er geen verschil is tussen 10 losse machines en 10 gevirtualiseerde machines. paravirtualisatie is dus geen optie, naast dat het onodig complex is is de performance gain voor mij geen pre. full virtualisatie waarbij de guest dus geen weet heeft van zijn werkelijke hardware is volgensmij veel beter voor wat ik wil doen en dat is een virtueel datacenter creeren wat meer op soort blade systeem lijkt waarbij 1 of meer fysieke machines meerdere virtuele machines draaien die de werkelijke netwerk taken uitvoeren. perfecte scheiding tussen hardware en software waarbij 1 server 1 taak vervult en dat goed doet. UNIX filosofie op netwerk nivo zeg maar.

over IPv6 was ik niet helemaal zeker omdat ik niet precies wist of de virtualisatie op het IP of op het ethernet nivo gebeurde. als dit op het IP nivo gebeurde dan moet IPv6 dus naast IPv4 worden gevirtualiseert maar uit je post begrijp ik dan dat het op het ethernet nivo gebeurd en dan maakt het niet uit wat voor protocol er wordt gesproken.

wat betreft het aan mekaar knopen zat ik te denken aan bridgen. elke VM heeft 1 gevirtualiseerde ethernet kaart welke ik dus op de fysieke host wil bridgen zodat alle VM's op 1 brigde device met elkaar zijn verbonden en dan deze bridge weer bridgen met eth0 van de fysieke host zodat ze met de buitenwereld kunnen praten. ik heb dit al eens eerder gedaan met echte netwerkkaarten dus als het met gevirtualiseerde kaarten net zo werkt zie ik daar geen probleem. wat betreft de VPN/IPv6 VM wil ik een soort gelijke structuur maken waarbij elke VPN verbinding eerst aan mekaar wordt genoopt om zo to een grote VPN-hub te komen. deze te bridgen(en firewallen) met de gevirtualiseerde eth0 in de VM welke dan weer gebrigde it met de fysieke eth0 van de host. aangezien een IPv6-over-IPv4 tunnel vergelijkbaar is met een VPN-endpoint voorzie ik hier een zelfde structuur. de fysieke host beschikt over 2x Gigabit Lan waar nog een derde Gigabit Lan bij kan. dus bandwijdte zat. gebruik hier thuis uitsluitend Gigabit met veel realtek 8169 kaartjes op een LinkSys 24poort switch.

wat betreft het swappen of het netwerk is het inderdaad voor die piekmomenten. je zou zeggen dat niet zo moeilijk zou zijn. gewoon een netwerk-block-device mounten en swapfile op zetten maar om 1 of andere reden lijkt het wel ofdat nog nooit iemand op dat idee is gekomen. de enige post die ik heb kunnen vinden is van de kernel-mailing lijst uit 2003 waar iemand een patch aanbiedt om swap over NBD mogelijk te maken maar de reactie van 1 van de kernel-developers was: it shouldn't be done. geen uitleg verder niks. die tread was gewoon in een keer stil zo van de kernel-developer heeft gesproken.

terwijl dit voor kleine HTPC machines juist belangrijk is omdat die vaak met 256MB ram worden uitgerust en meestal zo rond de 190MB usage zitten met een sporadische piek naar 300MB ofzo wanneer je een programma opstart etc. met 256MB en geen swap ben je dan gewoon genaaid maar met een kleine langzame swap van 128MB zou je dan in ieder geval kunnen verderwerken zonder dat je apps worden gekilled omdat het systeem gewoon weg geen ruimte meer heeft. veel distro's zijn met 256MB niet meer te draaien zonder swap en omdat het vaak om oude omgebouwde PC's gaat wil/kan ik hier geen RAM voor kopen. 2x128MB SD-RAM op een 2 slots micro-atx mobo enzo. al is dit ook meer een theoretische vraag omdat nu alle HTPC's voorzien zijn van een eigen hdd.

een ramdisk helpt dan niet omdat je dan RAM omzet in swap en je netto dus dezelfde capiciteit hebt. kwa serverkant zou het ook niks moeten uitmaken. die ziet gewoon file I/O request van de NFS client. elke client krijgt zijn eigen dedicated plekje dus ook de swapfile is exclusief. maarja zonder iets van een tutorial of FAQ of howto blijft dit natuurlijk een test-case welke gewoon een kwestie van uitproberen is. eerst maar eens die gevirtualiseerde NFS server opzetten.

ik heb zelf eens wat verder gezocht naar DirectFB en het lijkt meer op een pixel-buffer dan een character-buffer welke dus direct in de framebuffer van de videokaart werkt. no way dat je dat over het netwerk kunt krijgen dus tenzij je kostbare buffer-reads gaat doen wat precies de low-overhead van DirectFB teniet doet.

aangezien het draaien van een volwaardige X-server geen optie is omdat ik het licht wil houden en de setup natuurlijk onafhankelijk van administatie machine moet kunnen draaien is VNC de enige oplossing. aangezien ik uitsluitend vanaf de terminal werk moet ik toegeven dat ik geen ervaring heb met VNC. van wat ik zo kan vinden kun je met Xvnc een X-server simuleren welke dus alleen via een VNC client kan worden uitgelezen alleen heb ik zo nog niks gevonden over hoe je Xvnc kunt gebruiken met QEMU. aangezien ik dus eigenlijk alleen een terminal interface nodig heb zou het wel erg krom zijn om een volwaardig X-Server met GDM, font-deamons en weet ik wat er nog meer voor geheugen slurpende troep meekomt om vervolgens alleen een stel text characters als pixels over het netwerk te sturen.

iemand enig idee hoe QEMU Xvnc als X-server kan gebruiken voor zijn output? en hoe ik Xvnc kan opzetten zodat enkel en alleen QEMU daar zijn pixels afdropt zonder een hele windows-manager te moeten draaien. en met meerdere instanties van QEMU? kan dat met een enkele Xvnc server?

ik google nog even verder, alvast bedankt voor enige nuttige reacties.

donderdag 7 juni 2007 00:36

Acties:

donderdag 7 juni 2007 01:11

Je kunt natuurlijk ook qemu draaien met de optie -nographic. Als je dan in je kernel config aangeeft dat de console naar de seriele poort wordt geschreven kun je op je console (waar je qemu opstartte) gewoon inloggen als was het een normale tty login.
Uiteraard moet je dan de qemu image wel eerst geinstalleerd hebben op een machine met X.
Komend weekend hoop ik het bovenstaande uit te proberen.

iemand enig idee hoe QEMU Xvnc als X-server kan gebruiken voor zijn output?

Uit de documentatie:

`-vnc display'
Normally, QEMU uses SDL to display the VGA output. With this option, you can have QEMU listen on VNC display display and redirect the VGA display over the VNC session. It is very useful to enable the usb tablet device when using this option (option `-usbdevice tablet'). When using the VNC display, you must use the `-k' option to set the keyboard layout if you are not using en-us. display may be in the form interface:d, in which case connections will only be allowed from interface on display d. Optionally, interface can be omitted. display can also be in the form unix:path where path is the location of a unix socket to listen for connections on.

Acties:

donderdag 7 juni 2007 01:14

The what goes where now?

Verwijderd schreef op woensdag 06 juni 2007 @ 21:37:
ik denk dat ik de DHCP en DNS server toch gescheiden wil houden om flexibel te blijven

Dat is voor mij ook de reden dat ik nog dhcpd draai naast dnsmasq (dat en het feit dat ik die client hostname -> domain name functionaliteit nu niet nodig heb).

zoals mischien al een beetje uitlekt in mijn startpost ...

Ok, in dat geval is volledige virtualisatie inderdaad misschien beter. Ikzelf zou waarschijnlijk nog steeds helemaal geen virtualisatie doen, maar ach

over IPv6 was ik niet helemaal zeker omdat ik niet precies wist of de virtualisatie op het IP of op het ethernet nivo gebeurde.

Volgens deze documentatie kan Qemu een ne2k netwerkkaart emuleren, dus dat zou betekenen dat je daarover gewoon ethernet praat.

wat betreft het aan mekaar knopen zat ik te denken aan bridgen.

Ahja, dat lijkt me wel een goed plan ja.

je zou zeggen dat niet zo moeilijk zou zijn. gewoon een netwerk-block-device mounten en swapfile op zetten maar om 1 of andere reden lijkt het wel ofdat nog nooit iemand op dat idee is gekomen. de enige post die ik heb kunnen vinden is van de kernel-mailing lijst uit 2003 waar iemand een patch aanbiedt om swap over NBD mogelijk te maken maar de reactie van 1 van de kernel-developers was: it shouldn't be done. geen uitleg verder niks.

Volgensmij gaan er nu drie dingen door elkaar:

NFS mounten, daarop een file aanmaken, en naar die file swappen
Network block device connecten, swap erop aanmaken, en gebruiken als swap
Network block device connecten, filesystem erop aanmaken, file erop aanmaken, naar die file swappen

Swappen naar file over NFS kan bij mijn weten niet. Ik dacht dat swappen naar NBD wel kon, maar dat lijkt dus problematischer te zijn dan ik dacht. Ik lees hier dat het wel mogelijk zou zijn, maar niet zonder een patch.

De reden dat swappen naar file over NFS niet mogelijk is, is bij mijn weten dat de Linux swap code voor een swapfile om de filesystem layer heen gaat, rechtstreeks naar de block layer. Dat werkt bij NFS niet, omdat daar geen block layer aan te pas komt (in het client systeem dan).

Waarom die andere opties, met een NBD, niet zouden werken weet ik niet.[/q]

een ramdisk helpt dan niet omdat je dan RAM omzet in swap en je netto dus dezelfde capiciteit hebt.

Ja, dat klopt, swap op een ramdisk zou alleen helpen als de kernel bij memory pressure over de zeik zou gaan (vanwege de aanname dat er swap is in de VM code). Ik weet niet precies hoe ver daar daadwerkelijk sprake van is trouwens, maar het zou zomaar kunnen.

kwa serverkant zou het ook niks moeten uitmaken. die ziet gewoon file I/O request van de NFS client.

Ik weet niet waar een Linux NBD mee verwacht te comminuceren... Is dat met een NFS server? Of een ander protocol?

ik heb zelf eens wat verder gezocht naar DirectFB en het lijkt meer op een pixel-buffer dan een character-buffer welke dus direct in de framebuffer van de videokaart werkt. no way dat je dat over het netwerk kunt krijgen dus tenzij je kostbare buffer-reads gaat doen wat precies de low-overhead van DirectFB teniet doet.

Dat is het linux fb gebeuren ook, een manier om toegang te krijgen tot de framebuffer van de videokaart (waar idd pixels in staan). DirectFB is overigens iets anders, dat is een wat hoger-nivo project wat bovenop de Linux fb layer draait.

aangezien het draaien van een volwaardige X-server geen optie is omdat ik het licht wil houden en de setup natuurlijk onafhankelijk van administatie machine moet kunnen draaien is VNC de enige oplossing.

Nouja, je zou nu een X server (lokaal of op je Windows machine) kunnen gebruiken voor de installatie, ik neem aan dat je later gewoon naar je guest OSses ssht.

van wat ik zo kan vinden kun je met Xvnc een X-server simuleren welke dus alleen via een VNC client kan worden uitgelezen

Dat klopt, afgezien van het feit dat je geen X server emuleert, maar dat Xvnc een X server is. Alleen eentje die toevallig geen muis/keyboard/videokaart aanstuurt, maar een VNC server.

alleen heb ik zo nog niks gevonden over hoe je Xvnc kunt gebruiken met QEMU.

X11 is in principe gewoon een client/server netwerkprotocol. Grafische applicatie (X clients) maken een verbinding met een "display programma" (X server).

Wat je dus moet doen is Xvnc starten, en dan Qemu wijsmaken dat hij met Xvnc moet verbinden. Dit gebeurt doorgaans met de DISPLAY variabele en/of de -display optie. Als Xvnc de eerste X server is op dat systeem, dan zou iets a la

DISPLAY=:0 qemu

moeten werken.

aangezien ik dus eigenlijk alleen een terminal interface nodig heb zou het wel erg krom zijn om een volwaardig X-Server met GDM, font-deamons en weet ik wat er nog meer voor geheugen slurpende troep meekomt om vervolgens alleen een stel text characters als pixels over het netwerk te sturen.

Ik zou zeggen: zoek anders eerst goed of qemu niet text-only kan draaien. Ik weet alleen niet of de Debian installer dan gaat werken, die heb ik tot nu toe altijd framebuffer zien gebruiken (dus zelf de letters tekenen, niet VGA tekst mode).

Then again, die installer werkt ook over een seriele poort, en da's echt text-only. Is dat geen optie? Qemu draaien zonder enige output (kan dat?), en dan de installer bedienen over Qemu's gevirtualiseerde seriele poort?

en hoe ik Xvnc kan opzetten zodat enkel en alleen QEMU daar zijn pixels afdropt zonder een hele windows-manager te moeten draaien.

Een window manager is wel aan te raden, zeker als je meerdere Qemu instances in één VNC sessie wil. Zonder window manager kun je niet eens je Qemu window(s) verplaatsen

Je kan iets relatief kleins als blackbox of fluxbox gebruiken. Of iets heel erg kleins als lwm (die is echt heel erg kaal).

en met meerdere instanties van QEMU? kan dat met een enkele Xvnc server?

Gewoon zorgen dat ze allemaal met die Xvnc verbinden.

edit:
spuit 11

ph0t0nix' VNC aanpak lijkt me trouwens handiger dan via Xvnc

Acties:

Verwijderd

Topicstarter

ik dacht dat je alleen bepaald debug waardes kunt uitlezen en niet een volwaardige tty krijgt. echter als dat zou werken zou dat het hele probleem oplossen. het probleem is niet zozeer X maar alles wat er bij meekomt. een kale X server die schale 20MB ram ineemt en 6 framebuffers houdt vande verschillende VM's zou ook al zeer acceptable zijn. ik heb wel een monitor die ik kan gebruiken tijdens installeeren.

ik zag die optie ook staan 'man qemu' maar ik moest heb echt 2 keer lezen want staat er nou dat qemu als vnc server dient? nee toch. ik denk dat ze doelen op het feit dat Xvnc, welke niet expliciet wordt genoemd, elke X-display automatisch mapt naar een VNC sessie. dus qemu verbindt met Xvnc en gaat aan de slag op bijvoorbeeld display :2 dan mapd Xvnc die meteen naar sessie :2. als je dan met een VNC client connect naar :2 kijk je meteen naar de juist display. teminste zo begreep ik het van de Xvnc website. maar in de QEMU manual wordt Xvnc niet 1 keer noemd terwijl er geen enkel andere project is wat SDL's X direct omzet naar VNC.

of doelen ze op een VNC driver in SDL ofzo zoals bijvoorbeeld GTK ook een DirectFB versie heeft om zonder X-server te kunnen werken maar dan met VNC i.p.v DirectFB. theoretisch zou het kunnen maar dat zou weer impliceeren dat QEMU of beter gezegd SDL als VNC server optreedt. overig zag ik ergens dat deze optie er pas sinds QEMU 0.9.0 inzit ofzo. erg vaag allemaal want de manual is van 0.8.0.

*waarom hebben ze letterlijk een dozijn hoofstukken over netwerk maar niet 1 over VNC terwijl de optie er duidelijk inzit. nouja het is laat. morgen nieuwe kans om hier mee verder te stoeien.

donderdag 7 juni 2007 01:26

Acties:

donderdag 7 juni 2007 09:37

The what goes where now?

Verwijderd schreef op donderdag 07 juni 2007 @ 01:14:
ik dacht dat je alleen bepaald debug waardes kunt uitlezen en niet een volwaardige tty krijgt.

Debug waardes van qemu, of van de Debian installer? Ik heb Debian al eens over een seriele poort geinstalleerd, dus het moet in prince mogelijk zijn. Al was dat inmiddels wel 2 versies terug en op Sparc, niet i386/x86-64.

het probleem is niet zozeer X maar alles wat er bij meekomt. een kale X server die schale 20MB ram ineemt en 6 framebuffers houdt vande verschillende VM's zou ook al zeer acceptable zijn. ik heb wel een monitor die ik kan gebruiken.

Je hebt ook niet zo heel veel nodig, zeker geen heel Gnome of KDE oid. Je hebt Xvnc nodig, en misschien xbase-clients. Die zullen allebei wat common X packages meeslepen, wat libs, en waarschijnlijk wat font dingen. De voornaamste last daarvan is diskspace (en mja ach, 50 MB ofzo?)

ik zag die optie ook staan 'man qemu' maar ik moest heb echt 2 keer lezen want staat er nou dat qemu als vnc server dient?

Zo lees ik het eigenlijk wel, dat maakt dat waarschijnlijk een handigere optie dan Xvnc

... terwijl er geen enkel andere project is wat SDL's X direct omzet naar VNC.

Het is voor de meeste andere programma's dan ook niet zo heel nuttig. Om Qemu op text-only remote bakken te draaien (geen zeldzame use case, lijkt me) is het handig.

of doelen ze op een VNC driver in SDL ofzo zoals bijvoorbeeld GTK ook een DirectFB versie heeft om zonder X-server te kunnen werken maar dan met VNC i.p.v DirectFB.

Als ik moet gokken, dan gok ik dat Qemu zijn grafische output of via SDL kan weergeven, of via een in gebouwde VNC server. Qemu -> SDL -> Xvnc lijkt me nogal omslachtig om in Qemu zelf te doen.

*waarom hebben ze letterlijk een dozijn hoofstukken over netwerk maar niet 1 over VNC terwijl de optie er duidelijk inzit.

Als het inderdaad een vrij recente optie is, dan is dat waarschijnlijk meteen de reden.

Acties:

Verwijderd

Ik zou sowieso eens kijken naar Vserver of KVM. Qemu emuleert nm een processor. Hierdoor gaat veel snelheid verloren. Als je alleen linux guest draaien zou ik voor para-virtualisatie gaan. Hierdoor worden systemcalls veel sneller uitgevoerd.

vrijdag 8 juni 2007 00:03

Acties:

Verwijderd

Topicstarter

Verwijderd schreef op donderdag 07 juni 2007 @ 09:37:
Ik zou sowieso eens kijken naar Vserver of KVM. Qemu emuleert nm een processor. Hierdoor gaat veel snelheid verloren. Als je alleen linux guest draaien zou ik voor para-virtualisatie gaan. Hierdoor worden systemcalls veel sneller uitgevoerd.

als je mijn TS had doorgelezen had je gezien dat snelheid niet een pre is maar scheiding tussen software en hardware wel. para-virtualisatie of chroot's zijn dus geen optie. er moet zeg maar geen verschill zijn tussen 10 losse server-dozen en 10 gevirtualiseerde server-dozen.

KVM is volgensmij slechts een Kernel interface om virtualisatie in de kernel makkelijker maken waardoor vooral para-virtualisatie een stuk makkelijker is te implementeren. Vserver werkt ook op het kernel-nivo en niet op hardware-nivo zoals qemu.

ik ben nu de how-to aan het doorlezen over hoe de seriele poort te gebruiken als tty zodat ik de -nographic option kan gebruiken en geen X of FB nodig heb. ik kom hier later nog op terug.

vrijdag 8 juni 2007 00:20

Acties:

smokalot

titel onder

Verwijderd schreef op woensdag 06 juni 2007 @ 11:03:
5) Netwerkboot server. ik heb hier een aantal zelf gebouwde HTPC's welke nu nog een eigen HD hebben maar eigenlijk wil ik ze over het netwerk laten starten. vooral over hoe je een NFS share per-computer opzet en hoe om te gaan met swappen over het netwerk zou ik eigenlijk nog wat meer willen weten. ik kan hier geen echte tutorials over vinden. met name dat swap gebeuren kom ik eigenlijk telkens weer op het zelfde terug: it should't be done(weet ik maar ik vroeg of het kon?).

zou het niet een oplossing zijn om een hele goedkope, kleine usb stick (of usb cardreader) op zo'n machine aan te sluiten om op te swappen?

It sounds like it could be either bad hardware or software

vrijdag 8 juni 2007 00:45

Acties:

Verwijderd

Topicstarter

smokalot schreef op vrijdag 08 juni 2007 @ 00:20:
[...]

zou het niet een oplossing zijn om een hele goedkope, kleine usb stick (of usb cardreader) op zo'n machine aan te sluiten om op te swappen?

dat kan, maar met de prijzen van HD's die onder de 40 euro liggen en USB sticks van nog geen 10 euro blijft het een optie. het probleem is niet zozeer dat ik geen HD heb om op te swappen of dat ze voor mij onbetaalbaar zijn. het is gewoon een beetje krom om een PC over het netwerk te booten, de kernel van het netwerk te laden, het filesysteem over het netwerk te mounten alleen om vervolgens je swapfile op een lokale HD/stick te zetten.

het idee van een disk-less client is juist dat je geen lokale opslag hebt. overigens naar wat gelezen te hebben over hoe de Linux 2.6 kernel swapt en hoe dat alleen over Block-devices gebeurt snap ik nu ook waarom de huidige Linux systeemen geen support meer bieden voor swapfile's en waarom je alleen een swappartitie kan gebruiken. best wel jammer eigenlijk omdat dit ook betekent dat je bijvoorbeeld niet zomaar je windows swapfile op een vfat partitie kun delen met een linux systeem in een dual-boot configuratie zonder die partitie elke keer te formatteeren van vfat naar swap en vica-versa.

vrijdag 8 juni 2007 03:10

Acties:

Verwijderd

Topicstarter

oke,

ik heb vesafb aan de praat en heb een monitor en keybord direct in de server geplugd. heb vga=317 toegevoegd aan mijn kernel boot argumenten in GRUB. 317 is 1024x768x16 modus. wordt je console ook meteen een stuk groter van(ben gewend om via SSH op 1600x1200 te werken met puttySSH).

dus ik denk, nou moet SDL wel kunnen werken, maar nee hoor, nu knalt die er uit met de one-liner:

code:

1	cannot initialize SDL -exiting

de DirectFB error is nu weg maar SDL werkt nog steeds niet. ook kan ik niet iets van een verbose optie vinden en zit nu dus echt vast.

'sudo apt-get install qemu' zegt dat ik de laaste versie heb en dat deze al is ge-installeerd. 'sudo apt-get install sdl' geeft dat er geen pakket is genaamd sdl, maar ik neem aan dat qemu, wat blijkbaar best hevig op SDL rust, dat dus meeneemt als dependicy. dus SDL zal er wel opstaan.

ik starte de VM met deze lijn(zo even uit mijn hoofd, heb natuurlijk geen copy&paste)):

code:

1	qemu-system-x86_64 -hda /data/qimages/web64.img -cdrom /home/docey/debian-40r0-amd64-netinst.iso -boot d -smp 1 -full-screen

ik heb het zonder en met -full-screen en -smp 1 geprobeert en ook via qemu en qemu-system-x86_64. ook heb ik -no-kqemu nog geprobeerd en de -d int optie verandt ook niks aan de output. deze schijnen allemaal pas na die SDL error van toepassing te zijn.

wat mis ik hier nog?

vrijdag 8 juni 2007 10:20

Acties:

smokalot

titel onder

Verwijderd schreef op vrijdag 08 juni 2007 @ 00:45:
[...]
dat kan, maar met de prijzen van HD's die onder de 40 euro liggen en USB sticks van nog geen 10 euro blijft het een optie. het probleem is niet zozeer dat ik geen HD heb om op te swappen of dat ze voor mij onbetaalbaar zijn. het is gewoon een beetje krom om een PC over het netwerk te booten, de kernel van het netwerk te laden, het filesysteem over het netwerk te mounten alleen om vervolgens je swapfile op een lokale HD/stick te zetten.

het idee van een disk-less client is juist dat je geen lokale opslag hebt.

mijn idee van een diskless client zou zijn dat het ding totaal geen lawaai maakt, en dat je het systeem centraal beheert, en dat blijft ook zo.

It sounds like it could be either bad hardware or software

vrijdag 8 juni 2007 10:59

Acties:

vrijdag 8 juni 2007 11:37

Volgens mij moet het allemaal redelijk simpel zijn. Zelf ben ik al een tijdje aan het experimenteren/werken met Qemu en KVM.

Als ik me niet vergis zou de volgende commandline qemu moeten starten op een geemuleerd VNC scherm:

code:

1	qemu-system-x86_64 -hda diskimg -vnc :0

Vervolgens kan je met een VNC client connecten aan je server IP. Let wel op, zodra je scherm resolutie veranderd zal opnieuw moeten verbinden, omdat VNC of Qemu dat niet netjes afhandeld.

Dan zou ik je ook nog aanraden om de kqemu kernel module te download en te compilen. (Mogelijk heb je dan ook nog een nieuwere qemu nodig.) Met kqemu zal je emulatie vele malen sneller draaien.

Het volgende voeg je dan toe aan je qemu commandline:

code:

1	-kernel-kqemu

Let op: Windows installatie vind mogelijk geen enkele vorm van versnelling fijn, en zal dus compleet zonder kqemu moeten worden gedaan. Linux werkt zonder problemen.

Om maximale snelheid uit een geemuleerde Windows te halen zal je trouwens ook nog de HAL moeten vervangen door de Standaard PC. ACPI vertraagt Windows onder qemu/kqemu enorm.

Nu zal de VNC sessie naar de hele wereld open staan. Dus een setje iptables regels is noodzakelijk. Waarschijnlijk zal je connecties naar poort 5900 compleet willen blokkeren, behalve vanaf interface "lo" (loopback). Dan kan je met ssh een verbinding opzetten:

code:

1	ssh -L 5900:localhost:5900 serverip

Dan kan je met VNC verbinden aan je workstation, ssh forward dan de verbinding naar je server.

[ Voor 2% gewijzigd door Andante op 08-06-2007 11:07 . Reden: Verwijderen overbodige opmerking ]

Acties:

vrijdag 8 juni 2007 13:36

Op de Qemu pagina van Alien Bob las ik het volgende:

QEMU uses SDL for it’s output (video as well as sound), and you need to run QEMU in an X Window session. There is an option to the qemu binary called -nographic that you can use to circumvent the X session requirement, but you still need the X and SDL libraries installed on your system. Typically, you would use -nographic for a virtual machine you’ve already installed previously, and that allows remote access through SSH, VNC or XDMP, and where you no longer need the virtual machine’s local console.

Dus blijkbaar moet je op de host toch in elk geval de X libraries geinstalleerd hebben. Ook al gebruik je de -nographic optie.

Acties:

vrijdag 8 juni 2007 20:13

Wat ph0t0nix zegt is correct.Ik heb even gekeken op de server die hier qemu draait en daar zijn de basis X11 libs en SDL geinstalleerd. Er is overigens geen XWindows geinstalleerd op die server. Het komt er op neer dat qemu is gelinkt tegen een aantal libs die noodzakelijk zijn. Onder andere SDL voor graphics primitives. Echter de grootte van deze libs is niet enorm en een xserver hoeft niet actief te zijn voor uitvoer via VNC. Als er interesse is voor een lijst van libs die hier geinstalleerd zijn, laat het even weten.

Acties:

Verwijderd

Topicstarter

het kan zijn dat die X11 libs inderdaad niet ge-installeerd zijn. echter in de manual staat dat Qemu terug valt op de framebuffer middles directFB welke weer vesafb aanstuurt bijvoorbeeld. wel vaag dat Qemu die X11 libs niet als dependicy opgeeft.

weet je zo even welke debian4.0 packetten ik hiervoor moet apt-get'en?

zaterdag 9 juni 2007 07:13

Acties:

zaterdag 9 juni 2007 21:29

Hier is een lijst met de packages uit Etch die op onze server staan. Waarschijnlijk mis ik hier nog een paar omdat ik alleen op x11 heb gezocht. Ook is het goed mogelijk dat Qemu zonder de x11 libs kan werken, echter ik compile zelf recente versies van Qemu, dus heb ik de volledige libs + dev nodig.Hier zijn de libs die ik op de server heb, rechtstreeks uit dpkg -l. Dit is trouwens ook AMD64.

Voor SDL heb ik:

code:

1
2
3

ii  libsdl1.2-dev                1.2.11-8                            Simple DirectMedia Layer development files
ii  libsdl1.2debian              1.2.11-8                            Simple DirectMedia Layer
ii  libsdl1.2debian-alsa         1.2.11-8                            Simple DirectMedia Layer (with X11 and ALSA

Voor X11:

code:

ii  libx11-6                     1.0.3-7                             X11 client-side library
ii  libx11-data                  1.0.3-7                             X11 client-side library
ii  libx11-dev                   1.0.3-7                             X11 client-side library (development headers
ii  libxau-dev                   1.0.1-2                             X11 authorisation library (development heade
ii  libxau6                      1.0.1-2                             X11 authorisation library
ii  libxdmcp-dev                 1.0.1-2                             X11 authorisation library (development heade
ii  libxdmcp6                    1.0.1-2                             X11 Display Manager Control Protocol library
ii  libxext-dev                  1.0.1-2                             X11 miscellaneous extensions library (develo
ii  libxext6                     1.0.1-2                             X11 miscellaneous extension library
ii  libxpm4                      3.5.5-2                             X11 pixmap library
ii  libxxf86vm1                  1.0.1-2                             X11 XFree86 video mode extension library
ii  x11-common                   7.1.0-16                            X Window System (X.Org) infrastructure
ii  x11proto-core-dev            7.0.7-2                             X11 core wire protocol and auxiliary headers
ii  x11proto-input-dev           1.3.2-4                             X11 Input extension wire protocol
ii  x11proto-kb-dev              1.0.3-2                             X11 XKB extension wire protocol
ii  x11proto-xext-dev            7.0.2-5                             X11 various extension wire protocol

Het kan zijn dat je dan nog een aantal dependencies mist. Ook heb je waarschijnlijk teveel aan libs staan met alle libs hierboven.

Ik zou proberen eerst de SDL libs te apt-getten en daarna pas dingen als x11-common en libx11-6 te installeren.

En mogelijk gaat het met DirectFB niet lukken, bij mij is de keymap altijd volledig overhoop. Probeer het volgende:

code:

1	qemu-system-x86_64 -hda hdimage -vnc :0

En connect met een VNC client aan het IP van je server. Natuurlijk alleen als je geen SDL fouten meer krijgt.

Ik hoop dat dit je problemen oplost.

Acties:

Verwijderd

Topicstarter

volgensmij waren het inderdaad de X11 libs die ontbraken. qemu start nu teminste.

echter kan ik nog steeds niet goed connecten op vnc server die qemu opzet. ik heb verschillende opties in zowel UltraVNC als RealVNC geprobeerd maar het is of "connection refused" of "socket timedout" of "connection corrupt", etc. onder sommige settings crasht zelfs qemu met een segmentation fault.

echter als ik de -S optie toevoeg, dat is dat qemu eerst wacht. krijg ik wel een connectie en zie ik de qemu monitor met versie nummer enzo. alleen hij reageert niet op 'c' of welke keys dan ook. compleet frozen.

ik ga zometeen als het wat is afgekoeld nog eens direct met monitor en muis proberen want ik heb de display alleen nodig tijdens het installeeren. de rest gaat daarna via SSH alleen als ik de bridge verkloot kan ik die monitor nog wel eens nodig hebben, dus het is ook meer voor het geval dat.

*ik moet mij denk ik een paar daagjes terug trekken uit de ORG-25 DPC omdat mijn opteron's tegen de 60C graden aanlopen met dit weer. nieuwe koeling is onderweg maar totdan ./dnetc -shutdown

maandag 11 juni 2007 17:09

Acties:

woensdag 13 juni 2007 02:31

The what goes where now?

(Deels mosterd na de maaltijd:

)

Verwijderd schreef op vrijdag 08 juni 2007 @ 00:45:
overigens naar wat gelezen te hebben over hoe de Linux 2.6 kernel swapt en hoe dat alleen over Block-devices gebeurt snap ik nu ook waarom de huidige Linux systeemen geen support meer bieden voor swapfile's en waarom je alleen een swappartitie kan gebruiken.

Huh? Swapfiles werken nog gewoon hoor.

Alleen (zoals ik eerder ook al zei): bij mijn weten neemt de Linux swap code bij het gebruik van swapfiles een shortcut door de filesystem layer, direct naar de block layer. Daardoor werken alleen swapfiles die op een (toegankelijk) block device staan. Naar files op NFS kan om die reden niet geswapt worden, de kernel ziet alleen het filesystem, geen onderliggend block device.

(Waarom swappen naar NBD niet werkt weet ik niet)

Verwijderd schreef op vrijdag 08 juni 2007 @ 03:10:
dus ik denk, nou moet SDL wel kunnen werken, maar nee hoor, nu knalt die er uit met de one-liner:
code:
1
 cannot initialize SDL -exiting

Mogelijk heeft de SDL die op je systeem staat (stond...) geen support voor framebuffer output. Kijk eens welke SDL je hebt met

dpkg -l | grep 'libsdl1.2debian'

Voor framebuffer output heb je libsdl1.2debian-all nodig (de overige versies hebben alleen X11 output).

ph0t0nix schreef op vrijdag 08 juni 2007 @ 11:37:
Op de Qemu pagina van Alien Bob las ik het volgende:
Dus blijkbaar moet je op de host toch in elk geval de X libraries geinstalleerd hebben. Ook al gebruik je de -nographic optie.

Je moet de libraries hebben waar Qemu tegen gelinkt is, of je die nu gebruikt of niet. Als Qemu zonder SDL support gelinkt is (geen idee of dat mogelijk is), dan heb je geen SDL of X11 libs nodig.

Als je Qemu met SDL support gelinkt is, en je SDL is zonder X11 gelinkt (onwaarschijnlijk, maar het kan), dan heb je wel SDL nodig, maar geen X11 libs nodig. Als je SDL met X11 libs gelinkt is, dan heb je die ook nodig.

Maar alle libs die nodig zijn om Qemu uberhaupt te starten worden gewoon door apt mee-geinstalleerd. Extra X11 dingen zouden echt alleen maar nodig moeten zijn als je ook daadwerkelijk de X11 output gebruikt.

Verwijderd schreef op vrijdag 08 juni 2007 @ 20:13:
echter in de manual staat dat Qemu terug valt op de framebuffer middles directFB welke weer vesafb aanstuurt bijvoorbeeld.

Nee, niet DirectFB. DirectFB is een compleet ander project dat leuke GUI dingen doet bovenop Linux' framebuffer.

Overigens is het niet Qemu die terugvalt, maar SDL (mits die framebuffer output support heeft, zie boven)

wel vaag dat Qemu die X11 libs niet als dependicy opgeeft.

Qemu heeft niks met X11 te maken, Qemu praat alleen met SDL (of zijn interne VNC server).

Acties:

Verwijderd

Topicstarter

mischien moet je ook nog eens mij laaste post lezen: qemu start nu wel.

ik gebruik trouwens de .deb's die in de stable repo's van debian4.0 staan. dus waar tegen debian qemu linkt weet ik niet maar ik neem aan dat ze dus tegen X11 linken want toen ik de X11 libs genoemd door Andante (uitgezonder de dev packetten) apt-getten starte qemu zonder ook maar 1 error of warning(behalve kqemu dan).

probleem zit hem dus in dat zodra ik connect met realVNC of UltraVNC ik ofwel geen connectie krijg of qemu crashed. alleen als ik de -S optie toevoeg krijg ik wel een connectie maar kan ik de virtualisatie niet starten.

iemand een idee? welke VNC setting's gebruiken jullie?

woensdag 13 juni 2007 08:15

Acties:

woensdag 13 juni 2007 19:00

Eerlijk gezegd denk ik dat het verstandig is om zelf een stabiele versie van qemu (0.9.0) te downloaden en te compilen. Want er zijn flink wat veranderingen in de code aangebracht ook mbt VNC. Zelf gebruik ik krdc met standaard instellingen. Het is niet bijzonder moeilijk, enige punt is dat je de dev pakketten op je systeem moet hebben.

Acties:

woensdag 13 juni 2007 22:59

The what goes where now?

Verwijderd schreef op woensdag 13 juni 2007 @ 02:31:
mischien moet je ook nog eens mij laaste post lezen: qemu start nu wel.

Die heb ik gelezen (zie ook de eerste regel van mijn post), ik probeer alleen uit te leggen hoe het zit, zodat je snapt waarom dingen gebeuren.

dus waar tegen debian qemu linkt weet ik niet maar ik neem aan dat ze dus tegen X11 linken

Dat is simpelweg niet zo. Nogmaals, Qemu linkt tegen SDL, niet tegen X11:

code:

[marcelm@anything ~]$ ldd /usr/bin/qemu              
        linux-gate.so.1 =>  (0xffffe000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7fbf000)
        librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7fb6000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7fa2000)
        libasound.so.2 => /usr/lib/libasound.so.2 (0xb7ee1000)
        libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0xb7e30000)
        libncurses.so.5 => /lib/libncurses.so.5 (0xb7dee000)
        libutil.so.1 => /lib/tls/i686/cmov/libutil.so.1 (0xb7dea000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7cb9000)
        /lib/ld-linux.so.2 (0xb7feb000)
        libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7ca7000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7ca3000)
        libdirectfb-0.9.so.25 => /usr/lib/libdirectfb-0.9.so.25 (0xb7c4b000)
        libfusion-0.9.so.25 => /usr/lib/libfusion-0.9.so.25 (0xb7c45000)
        libdirect-0.9.so.25 => /usr/lib/libdirect-0.9.so.25 (0xb7c36000)
        libvga.so.1 => /usr/lib/libvga.so.1 (0xb7bd6000)

Hier werkt het dan ook prima met alleen maar libsdl1.2debian-alsa, en geen enkel X11 package.

iemand een idee? welke VNC setting's gebruiken jullie?

Ik start qemu met:

qemu -vnc 0 -cdrom bla.iso -hda bla.img -boot d

En ik connect met xvnc4viewer (VNC client van RealVNC):

xvnc4viewer anything:0

Acties: