Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Gastdrivers voor VirtualBox gaan deel uitmaken van Linux-kernel

De volgende versie van de Linux-kernel, 4.16, integreert de gastdrivers voor VirtualBox. Daarmee vervalt de noodzaak om deze nog handmatig te installeren om verdere integratie te verkrijgen bij het gebruik van een virtual machine.

Phoronix schrijft dat de 'vboxguest'-driver deel gaat uitmaken van de 4.16-kernel. Dat is het gevolg van het werk van Hans de Goede van Red Hat. De driver maakt het gebruik van verschillende functies mogelijk die het gast-OS in de vm verder integreren met de host.

In een bericht op de Linux-kernelmailinglijst schrijft De Goede dat er door de toevoeging van de driver onder meer ondersteuning komt voor knippen en plakken tussen host en gast, voor seamless mode en voor OpenGL pass-through.

Phoronix merkt op dat de optie voor gedeelde folders mogelijk nog niet op tijd klaar is voor release samen met de 4.16-kernel, waardoor deze mogelijk later komt.

Ubuntu in VBox

Door

Nieuwsredacteur

111 Linkedin Google+

Submitter: NerdChick

Reacties (111)

Wijzig sortering
Nog meer bloatware in de toch al veel te zware kernel 😐

Stel dat ik nu Xen wil gebruiken .. of geen VM draai......
Ik neem aan dat deze drivers gewoon als modules beschikbaar die je on-demand laadt en anders niet, net als zo'n beetje iedere andere driver op ieder andere modern OS. Zo werkt het nu al en ik neem aan dat ze dat niet veranderen.

[Reactie gewijzigd door CAPSLOCK2000 op 17 januari 2018 13:02]

Het zullen modules zijn die alleen wordt geladen als ze nodig zijn. Standaard heef de kernel op RedHat/Centos al meer dan 2400 modules dus een paar erbij maakt niet zoveel uit. Als je ze niet wilt kan je ze blacklisten. b.v. in /etc/modprobe.d/blacklist.conf
Dit dus, al die mensen hierboven die mopperen dat de kernel bloated wordt, snappen het blijkbaar niet.
Modules worden (mits ze in de distro zo gecompileerd worden) geladen in je initrd fase, waarna je er direct plezier van hebt, *mits* ze nodig zijn. Prima oplossing, want er is niets van de VBoxGuestAdditions nodig om te booten, dus lekker async laden.
Als je weet hoe de Linux kernel werkt dan is speelt dit probleem niet.

De kernel heeft een aantal essentiële drivers die altijd geladen worden en voor de rest wordt op basis van hardware id’s de juiste modules(drivers) ingeladen. Alles wat niet tijdens de boot of naderhand aangevraagd wordt, wordt niet ingeladen. Er dus geen enkel risico.

Mocht je toevallig een Linux doos tot je beschikking hebben, dan kun je met lsmod in de terminal bekijken welke huidige modules zijn geladen :)
Dan bouw je toch zelf de kernel? Als jij het zo erg vind dat de kernel zo bloated is moet je er ook de moeite voor nemen om zelf een baseline custom linux kernel te maken. Zo moeilijk is het niet om modules wel of niet mee te nemen :)

[Reactie gewijzigd door NotCYF op 17 januari 2018 16:04]

dan compile je een kernel zonder deze drivers?
Dan compileer je een custom kernel die geen Virtualbox ondersteuning heeft.

Dat is de kracht van Linux en open-source. Je kan een kernel bouwen die alleen maar ondersteuning heeft voor de hardware van jouw machine.

[Reactie gewijzigd door ArtGod op 17 januari 2018 11:50]

Maar hoezo dan? Een kernel die je niet zelf samenstelt en voor generiek gebruik bedoelde is bevat toch sowieso spul wat je niet strict gesproken nodig hebt? Ondersteuning voor hardware die je niet hebt bijvoorbeeld? Zomaar een afslag. Als je zo met stroomlijning bezig bent dat je in de stress raakt van wat overbodige componenten ben je sowieso al bezig met custom kernels en vermoedelijk custom distributies.

De toevoeging van de ondersteuning voor een virtualisatietechniek is overigens ook niet nieuw want ook VMware zit ook reeds enige tijd ingebakken: http://webwereld.nl/softw...evat-interfacecode-vmware
Ergens is het dus gewoon logisch dat ook de opensource oplossing dit niveau van implementatie krijgt.

Met die overvloed aan hardwarecapaciteit in het gemiddelde systeem snap ik sowieso de stress niet van een extra module die slechts wat marginale schijfruimte wegknabbeld. Je kan dat allemaal in aparte kernels gaan stoppen die onder andere noemers releasen en twee MB besparen in een aantal gevallen of je kan gewoon één kernel maken die alles doet en het lekker simpel houden voor iedereen ten koste van een een beetje schijfruimte die niemand gaat missen behalve de minimalisten die er naar zoeken.

[Reactie gewijzigd door Koffiebarbaar op 17 januari 2018 13:08]

Je kan dat allemaal in aparte kernels gaan stoppen die onder andere noemers releasen
En dat gebeurd ook. Zo heeft Ubuntu verschillende varianten van dezelfde kernel versie in zijn repositories met daarin specifieke optimalisaties voor bijvoorbeeld Xen, Azure en andere (cloud) hypervisors. Daarnaast bieden ze al sinds jaar en dag een "lowlatency" versie van de Linux kernel aan, wat gewoon de standaard kernel is met een andere scheduler.

Wat ik bedoel te zeggen is dat dankzij het feit dat de Linux kernel open source is, hij dus vrijelijk door iedereen kan worden aangepast naar verschillende behoeftes. De verantwoordelijk daarvoor ligt echter zoals @ArtGod al verondersteld bij de gebruiker zelf en daarnaast zijn er distributies die dit als extra service leveren.
Custom kernel != custom distribution. Je kan prima een custom kernel maken en draaien onder een standaard Ubuntu distro.

Voor een enkele PC is die paar MB RAM en schijfruimte niet het probleem, maar als jij een datacenter draait met tig virtuele machines dan maakt dat zeker uit. Ook kost het opstart tijd want er moet toch een hardware probe gedaan worden.
Custom kernel != custom distribution. Je kan prima een custom kernel maken en draaien onder een standaard Ubuntu distro.
Ik zeg volgens mij helemaal nergens dat die twee hetzelfde zijn?
Maar je bent wel een beetje raar bezig als je nerveus wordt van een "zware" kernel en je je custom gestroomlijnde superstrakke mileubewuste hipster kernel dan gewoon in Ubuntu steekt. ;)
Voor een enkele PC is die paar MB RAM en schijfruimte niet het probleem, maar als jij een datacenter draait met tig virtuele machines dan maakt dat zeker uit. Ook kost het opstart tijd want er moet toch een hardware probe gedaan worden.
Modules die niet gebruikt worden worden niet geladen, dus RAM niet.
Als je vandaag de dag nog visualiseert op een manier waar je ook de kernel meevirtualiseert (in plaats van dat virtualiseren in containervorm doet waardoor de host kernel gebruikt wordt) moet je denk ik sowieso goed kijken naar wat je aan het doen bent want volgens mij is dat in veel gevallen helemaal niet meer nodig..
Als je wel een miljoenmiljard machines hebt die persé helemaal geisoleerd moeten zijn EN helemaal van top tot teen gevisualiseerd moeten worden is ook die overhead niet zo stressvol als het goed is, en zo wel is het allicht de moeite waard om daar dus zelf een kernel voor samen te stellen.
Dat een generieke kernel release geen rekening houd met zo'n super specifieke use-case lijk me niet heel gek. Met of zonder virtualbox guest addons wil je dan aan de slag met kernel.

[Reactie gewijzigd door Koffiebarbaar op 17 januari 2018 13:29]

Ook kost het opstart tijd want er moet toch een hardware probe gedaan worden.
Dan weet jij niet hoe modules geladen worden. Denk je echt dat de kernel voor alle drivers (modules) gaat kijken of hun hardware toevallig aanwezig is? Dan ben je een uur bezig met opstarten, want er is nogal wat hardware gemaakt in de afgelopen decennia. Er wordt gescand op aanwezige hardware en ieder stukje hardware heeft een eigen ID (bv de PCI ID's in "lspci -n"). Vervolgens wordt er een driver geladen die bij dat ID hoort. Iedere module heeft namelijk een lijst met bijbehorende device ID's (te zien in "modinfo <naam>") die in de modmap opgeslagen worden.
Als je niet op virtualbox draait, vindt de kernel dus geen virtualbox device ID's en zal ie nooit een poging doen die drivers te laden. Meer dan een rondslingerend bestand op je disk is het dan dus niet.
Dus je hebt liever dat er initieel niets wordt ondersteund en je zelf moet gaan uitvogelen wat je precies nodig hebt, dan dat het zekere voor het onzekere wordt genomen en gewoon alles wordt ondersteund? Want waarom zou de kernel standaard AMD CPU's ondersteunen als je alleen maar Intel hebt? En dan neem je eens een AMD en dan, oh, oeps, sorry, dat werkt niet, want er is geen support voor, dat moet je eerst zelf nog even aangeven. Heb je nu even een week de tijd om alles uit te zoeken wat je nou precies aan en uit moet zetten om van Intel naar AMD support te gaan? En dan daarna 2 uur geduld om de boel opnieuw te compileren.

Nee, laat het maar lekker allemaal standaard ondersteund worden. Wie er echt interesse in heeft kan zich er meer in verdiepen en een eigen kernel bakken speciaal gericht op zijn/haar specifieke hardwareconfiguratie.
En het gros van de Intel gebruikers heeft geen klap aan AMD support en andersom, net als het gros van de nVidia GPU bezitters niets heeft aan die van AMD en Intel en alle oudere kaarten en die in servers gebruikt worden. En zo zijn er nog bakken meer zaken die er standaard in zit waar 'het gross' niets aan heeft.
Je moest eens weten hoeveel modules er vandaag op een standaard kale distro worden meegeleverd die maar door een fractie van de gebruikers actief worden ingeladen terwijl er meergebruikte modules zijn die vandaag niet worden meegeleverd. De vbox guest drivers worden door redelijk wat mensen gebruikt en het blijft soms sukkellen om ze geladen te krijgen.
Ja, want de huidige kernel bevat natuurlijk alleen maar meuk die jij specifiek nodig hebt.....

En zelf wat doen voor een gratis OS... Of doneer jij genoeg dat ze voor jou speciaal compilen?
Maar jij hebt er toch geen last van? De kernel wordt enkele MBs groter, maar tis allemaal load on demand meuk. Persoonlijk zou ik zeggen gooi het in de package managers, maar wie ben ik.
Enkele MB's? Enkele kB's zul je bedoelen. De meeste modules zijn heel klein. De virtio gpu driver (zegmaar de kvm tegenhanger van de virtualbox video driver) is ongeveer 126kb.
dan zie ik het hele probleem niet.
Dat was vroeger inderdaad de leus. Linux was zo veel sneller en efficienter omdat de hardware toen nog rete traag was, weinig geheugen beschikbaar was, waardoor je dus distro's als Gentoo e.d. kreeg waar een hele 'optimization' community achter zat die allemaal zaten te klooien met compiler flags, om maar dat enkele procentje meer snelheid te kunnen krijgen voor significante instabiliteit van hun gecompileerde software. Gelukkig zijn systemen hedendaags zo snel dat je er geen drol meer van merkt.

http://funroll-loops.teurasporsaat.org/

Grappig was het wel, moet ik zeggen :P

[Reactie gewijzigd door Marctraider op 17 januari 2018 15:48]

Het is wel bloatware omdat lang niet alle kernels op VirtualBox draaien, en daarmee deze drivers niet nodig hebben.

Je hoeft ze niet te compileren, en ik hoop dat er wel aparte kernel packages komen voor VM's op VirtualBox zodat je zelf kunt kiezen. Het zal wel als module gecompileerd worden waardoor het niet standaard geladen wordt, maar toch... er staan al zoveel drivers in welke je lang niet allemaal nodig hebt.
er staan al zoveel drivers in welke je lang niet allemaal nodig hebt.
Dat is juist een sterk punt van Linux. Veel oude hardware heb ik een tweede leven gegeven omdat het (recente) Linux kan draaien.

Je ziet voor de kernel dat het framework voor drivers en 'subdrivers' zodanig wordt ingericht dat het toevoegen van hardware een eenmalige actie is. De overhead om oud spul te blijven ondersteunen wordt daarmee gereduceerd tot het minimum. Voor het werk is er dus weinig behoefte om drivers/ondersteuning te schrappen. Zoals eerder genoemd wordt een kernel module pas geladen als deze nodig is. Dat beetje schijfruimte voor ongebruikte modules (in de praktijk vaak <100 KB per module) die meegeleverd worden in een standaard Linuxdistributie kan iedereen wel missen, en het maakt de distributie veelzijdiger. Al ga je specialistisch aan de slag dan kan je altijd nog besluiten om bepaalde modules niet mee te compileren.

Een interessant boek voor jou en iedereen die zelf de teugels in handen willen houden is hier te vinden. Het is gratis en best wel uitgebreid, net als de Linux kernel, maar ik vertrouw erop dat het wel gaat lukken om de goudkorrels eruit te halen. ;)

[Reactie gewijzigd door The Zep Man op 17 januari 2018 12:46]

LFS heb ik lang geleden een keer gedaan. Prachtig project, maar wel bewerkelijk en niet te onderhouden ;) Wel leerzaam.

Ik zou best wat zien in enige segmentatie van de kernels - afhankelijk van het type hardware (of door de gebruiker gekozen) een kernel draaien geschikt voor in een VM, op oude hardware of juist op nieuwe hardware.

Veel last heb je natuurlijk niet van honderden / duizenden modules die je niet gebruikt maar het is wel bloat die je niet nodig hebt. Net zo min als dat ik echt last heb van Candy Crush in Windows 10, maar het heeft daar niets te zoeken, dus heb ik het er liever niet.
LFS heb ik lang geleden een keer gedaan. Prachtig project, maar wel bewerkelijk en niet te onderhouden ;) Wel leerzaam.
Bedankt dat je mijn punt bevestigt, want dat is hetzelfde punt dat je kan maken over het onderhouden van verschillende kernels/distributies.
Ik zou best wat zien in enige segmentatie van de kernels - afhankelijk van het type hardware (of door de gebruiker gekozen) een kernel draaien geschikt voor in een VM, op oude hardware of juist op nieuwe hardware.
Die keuze die heb je. Er is niets mis mee dat de standaardkernel van de meeste distributies op de meeste hardware draait. Al bevalt dat je niet dan kan je het (vaak zelfs geassisteerd/geautomatiseerd) zelf compileren.
Veel last heb je natuurlijk niet van honderden / duizenden modules die je niet gebruikt maar het is wel bloat die je niet nodig hebt.
Bloat zie ik als ongewenste software die een significante invloed heeft op de prestaties/capaciteiten van een systeem. Voor mij vallen ongebruikte kernel modules hier niet onder. Ik heb liever dat ze er voor de zekerheid er wel bij zitten. Als ik compileer kost dat mij misschien 1/10e seconde om een ongewenste module mee te compileren en het kost wat ruimte in de distributie en opslag, maar daar leef ik wel mee (en vele anderen).

De kracht van Linux is juist dat het een enkele kernel is. Distributies configureren de kernel en staan verdere specialisatie toe. Al heb je een specialistische kernel nodig omdat een algemene kernel niet werkt, dan heb je zeer waarschijnlijk ook een specialistische distributie nodig. Daar zou ik eerst een keuze in maken. Algemene distributies (Debian Linux, Arch Linux, etc.) moeten algemeen blijven om vanaf een enkel installatiemedium zo flexibel mogelijk inzetbaar te zijn.

[Reactie gewijzigd door The Zep Man op 17 januari 2018 13:26]

Bedankt dat je mijn punt bevestigt, want dat is hetzelfde punt dat je kan maken over het onderhouden van verschillende kernels/distributies.
Elke kernelupdate zelf moeten downloaden, configureren en compileren is alweer een heel ander verhaal dan eenmalig een andere kernel package kiezen en deze door de package manager laten beheren. Daar zijn ook build farms voor bij de distributies. Ik heb tijdenlang Gentoo gedraaid, hierbij compileer je alles ook van source en mag je ook zelf je kernel compileren, maar is het wél onderhoudbaar dankzij de hulp van de briljante package manager.
Bloat zie ik als ongewenste software die een significante invloed heeft op de prestaties/capaciteiten van een systeem. Voor mij vallen ongebruikte kernel modules hier niet onder. Ik heb liever dat ze er voor de zekerheid er wel bij zitten. Als ik compileer kost dat mij misschien 1/10e seconde om een ongewenste module mee te compileren en het kost wat ruimte in de distributie en opslag, maar daar leef ik wel mee (en vele anderen).
Bloat is voor mij gewoon ongewenste (onnodige) features en software. Een zekere mate van bloat is onvermijdelijk maar er zijn wel grenzen. Ik vind specifieke drivers voor een virtualisatieplatform wel wat ver gaan. Het installeren via een losse package ging altijd prima, ik heb zelf nooit deze drivers hoeven te bouwen / installeren op mijn VirtualBox VM's.
De kracht van Linux is juist dat het een enkele kernel is. Distributies configureren de kernel en staan verdere specialisatie toe. Al heb je een specialistische kernel nodig omdat een algemene kernel niet werkt, dan heb je zeer waarschijnlijk ook een specialistische distributie nodig. Daar zou ik eerst een keuze in maken. Algemene distributies (Debian Linux, Arch Linux, etc.) moeten algemeen blijven om vanaf een enkel installatiemedium zo flexibel mogelijk inzetbaar te zijn.
Het installatiemedium kan best alles bevatten, maar de uiteindelijk geïnstalleerde kernel zou best wat meer op je systeem toegespitst kunnen zijn. De boot-partitie groeit en groeit maar door dit soort zaken.

Ik zal er niet wakker van liggen maar vind het absoluut niet nodig dat dit standaard in elke kernel zit. Los daarvan is het natuurlijk prima als het in de kernel source opgenomen wordt, dat maakt de toekomst zekerder aangezien de kernel developers de compatibiliteit van modules bewaken. Dat betekent nog niet dat alle drivers standaard in de kernel packages moeten zitten. En gelukkig zitten ze dat ook niet allemaal.

[Reactie gewijzigd door MadEgg op 17 januari 2018 15:07]

Ik zou best wat zien in enige segmentatie van de kernels - afhankelijk van het type hardware (of door de gebruiker gekozen) een kernel draaien geschikt voor in een VM, op oude hardware of juist op nieuwe hardware.
Wat voor verschillen zou je willen zien tussen die segmenten?
Wat zou een kernel voor oude/nieuwe/virtuele hardware wel of niet moeten bevatten?
Bepaalde drivers wel of niet laden kan al, daar zijn geen aanpassingen aan de kernel voor nodig.

Ooit hadden we Linux-kernels voor systemen met veel geheugen, en systemen met weinig geheugen, alsmede systemen met een enkele CPU(-core) of meerdere CPU's. Op een gegeven moment is men daar mee gestopt omdat nieuwere algoritmes goed omgaan met alle situaties.
Das zijn alle Intel drivers in mijn kernel dus ook bloatware, aangezien ik full AMD heb....
Drivers zijn load on demand, en die enkele MBs die ze kosten, ach, daar lig ik niet echt wakker om. Zou ik dat wel doen, dan compileer ik mijn eigen kernel wel.

Maar aan alle tegenstand te zien, zou iemand een eigen distro moeten maken ;) Fork Debian, of beter Deviaun en haal daar de vm drivers uit!
Lang niet alle kernels draaien op de chipset die jij hebt, dus is dat ook bloatware?
Het is wel bloatware omdat lang niet alle kernels op VirtualBox draaien, en daarmee deze drivers niet nodig hebben.

Je hoeft ze niet te compileren, en ik hoop dat er wel aparte kernel packages komen voor VM's op VirtualBox zodat je zelf kunt kiezen. Het zal wel als module gecompileerd worden waardoor het niet standaard geladen wordt, maar toch... er staan al zoveel drivers in welke je lang niet allemaal nodig hebt.
Waar heb je last van? Praktisch gezien is het grootste bezwaar dat het wat schuifruimte kost. Op de meeste systemen gaat die paar MB echt geen verschil maken.

In theorie zou het nog een beveiligingsprobleem kunnen opleveren, maar als een aanvaller al zo ver is dat er drivers geladen kunnen worden dan heb je een groter probleem.
als ik een VM draai onder vbox installeer ik zelf die guest additions wel
Dit zijn niet de guest extensions waar binary blobs voor USB en een hoop andere rotzooi in zit, maar code voor betere aansturing van het virtuele scherm en de muis, wat direct een hoop extra features mogelijk maakt die in de VM-host software zit ingebakken. Niet meer dan logisch dat dit nu in de mainline kernel gaat komen gezien dit niet anders is met de KVM virtio drivers, of die van Hyper-V.

En daarnaast als voordeel dat de code van fatsoenlijke kwaliteit moet zijn voordat deze uberhaupt de kernel in mogen, dat is maar de vraag bij de losse vbox-guest-agent.

[Reactie gewijzigd door SirNobax op 17 januari 2018 12:41]

Installeer je ook zelf de toetsenborddriver voor je fysieke systemen?

Ik denk dat het "all-inclusive, one size fits all" model prima werkt voor een general purpose OS. Als je speciale behoeftes hebt waardoor je last hebt van die toevoegingen kun je ze er eenvoudig uithalen. Als je in een vakgebied werkt waar dat relevant is heb je ook wel de handigheid om zelf een kernel te compileren.
Ik kan me niet herinneren dat de Linux kernel een opt-in model had, eerder een opt-out. De meeste moderne distro's hadden de drivers sowieso al aan boord.
Hij bedoeld dat het bloatware is als het standaard in de kernel zit, wat een normale linuxgebruiker of servers aan deze ondersteuning? Niets. Simpele oplossing is echter de kernel zonder te compileren, problem solved.
Ik zou apart kernels moeten gaan compileren om iets wat ongewenst is eruit te gaan slopen.
Zoveel misinformatie... Dit zit niet in de kernel en heeft geen invloed op een niet-VirtualBox systeem anders dan dat het enkele KB gebruikt op de harde schijf. Het wordt niet eens in het geheugen geladen. Qua dat denk ik dat je meer winst zal krijgen door je 'minimalistische woede' op andere softwareproducten te richten. :P

[Reactie gewijzigd door The Zep Man op 17 januari 2018 12:49]

De andere kant is dat we linux-build met speciale vm-kernel gaan bouwen. Is dat waar we heen willen?
Mijn persoonlijke opvatting is dat alles zo 'simpel' mogelijk moet blijven (voor de simpele gebruiker), dan kunnen de 'experts' zelf een kernel zonder bs. Uiteindelijk zal een light-distro deze functies toch uit de kernel slopen om op die oude laptops met 1 1ghz core en 500mb te blijven draaien.
Tja, dat is al sinds het begin zo.
Je krijgt een redelijk generieke kernel, met drivers voor veel gebruikte hardware.
Wil je iets bijzonders, of wil je je kernel minimaliseren? Dan compileer je hem zelf.

Maar is tegenwoordig niet het meeste als module gecompileerd voor Linux? Als je een driver dan niet nodig hebt, dan laadt je systeem hem niet in, en is er dus niets aan de hand.
Niet de vboxguest module laden?
non issue. Er zitten gegarandeerd drivers voor hardware die je niet hebt in de kernel. Meestal in de vorm van een module die gewoon niet geladen wordt.
Load on demand. Jouw kernel wordt hierdoor niet trager, alleen ietsjes groter.....
In de begindagen van Slackware (misschien nog steeds wel) was dat inderdaad het geval. Je bootte naar de shell met minimale hardwaresupport en voor de rest moest je het zelf maar bekijken... wil je bepaalde kernelmodules erbij hebben? Dan compileer je die maar lekker zelf. Wil je updaten? Compileer je maar lekker zelf. Nieuwe compiler nodig? Dan compileer je die maar lekker ze.... eh... :)
Mmm... Hoewel dit de gebruiksvriendelijkheid zeker ten goede zal komen... is dit iets dat je in de kernel zou willen? Ik veronderstel dat dit ook alleen maar werkt met VirtualBox en niet met VMware, Hyper-V, etc.?
VMWare en Hyper-V hebben al eigen drivers in de Linux-kernel.
In dat geval; waarom doen we moeilijk/waarom zit dit er niet al jaren in?
Ik weet het niet zeker, maar ik meen dat er twee redenen zijn.
De eerste is dat VirtualBox begon als een closed-source product. De ontwikkelaars wilden hun drivers dus helemaal niet in de publiek beschikbare kernel, die waren alleen voor hun betalende klanten. Later is VirtualBox van licentie veranderd waardoor het geen probleem meer is.
Verder meen ik dat de eerste versies van deze drivers nogal ingrijpend waren en ook andere delen van de kernel aanpaste. Het wordt niet wenselijk geacht om zo'n veranderingen eenzijdig door te voeren. Het is de bedoeling dat je alle aanpassingen in losse delen opsplitst en die bespreekt met de relevante kernelteams. Dat kan veel tijd kosten bij ingrijpende veranderingen.
Vaak is het bij dit soort projecten ook zo dat ze hun eigen programmeerstijl hanteren, bijvoorbeeld de huisstijl van de ontwikkelaar. Als zo'n driver deel wordt van de mainline kernel moet de stijl worden aangepast. Dat kan ook voor vertraging zorgen, geen idee of dat hier van toepassing is.
Ten slotte moet je bereid zijn om je werk te onderhouden als je deel wordt van de kernel. Sommige projecten zijn daar nog niet klaar voor, bijvoorbeeld omdat hun werk nog te snel verandert om het lange tijd te ondersteunen. Die kiezen er dan voor om buiten de kernel te blijven. Wederom weet ik niet of dat hier van toepassing is. Oracle staat niet echt bekend om z'n vrijgevigheid, mogelijk speelt dat een rol.
Eindelijk (werd een beetje vervelend om telkens bij elke nieuwe update weer die virtuele disk erin te rammen).. Al gebruik ik al een tijdje geen VirtualBox meer. Het is zeer gebruiksvriendelijk, en naar mijn mening meer Plug 'N Play dan bijvoorbeeld Hyper-V en VMWare.

Bij Hyper-V (wat ik eigenlijk alleen maar gebruik) is het af en toe nogal gaar - en weet niet of dat een driverprobleempje is - maar heb zo nu en dan op onverklaarbare wijze last van VM's die ik niet in fullscreen kan runnen, terwijl ik wel de nodige toetsencombinaties en instellingen heb geprobeerd :+.

[Reactie gewijzigd door AnonymousWP op 17 januari 2018 11:47]

Vrijwel alle distros gebruiken open-vm-tools voor VMware. Die gaat gewoon in je OS update rondje mee.
Gelukkig zijn er meer manieren om een Linux VM te draaien dan in een enterprise omgeving. Zo gebruik ik op mijn werk Macbook VirtualBox voor een Windows en een Linux guest. Het is namelijk gratis in tegenstelling tot VMware Workstation of Parallels en werkt net zo goed.
VMware is ook gratis voor niet commercieel gebruik.
Mijn virtualbox laat m'n Ubuntu steeds crashen na de laatste update van vorige week. Weer met kvm begonnen, is wel een stuk trager viel mij op.
Ik snap niet dat ze virtualbox drivers in de kernel gaan integreren, je hebt toch al KVM om virtual machines te draaien. Volgens mij draaien de meeste bedrijven die een virtual enironment draaien onder Linux KVM of RHEV.
Dat is het Linux-model. Iedereen mag drivers leveren. Zolang anderen geen last hebben van jouw driver is alles welkom. Het doet er niet toe hoe groot of klein de markt is, dat speelt geen rol. Als jij een driver voor je waterkoker hebt geschreven dan zal Linus die met liefde opnemen zolang de code aan alle regels voldoet.
Zolang iemand de moeite wil doen om de code te onderhouden zodat anderen er geen last van hebben mag de code de kernel in.
Let op waar je het over hebt. Je noemt KVM, dat is de hypervisor. Dit bericht gaat specifiek over de Guest Tools, iets wat je gebruikt binnen de VM, niet om een VM te draaien.
Het klopt dat er ook KVM guest zaken in de kernel zit, maar dat is net zo het geval voor Xen. Je opmerking zou net zo goed voor KVM kunnen gelden, aangezien Xen eerder was.

Wat de VirtualBox Guest Tools voornamelijk doen, is interessant voor desktop gebruik. Servers draaien zonder GUI, dus wat heb je dan aan een hogere resolutie en OpenGL? ;)
Dit zijn de drivers voor de guestOS-en.
Dus niet een Linux-host, maar een Linux-installatie in de VM.
Klinkt heel mooi. Ik heb vroeger de handleiding op het VB forum geschreven hoe men de tools in Linux kan installeren via de ISO. Jammer dat Shared Folders er niet direct in zal zitten, maar de eerste stappen zijn geweldig om te horen. Scheelt zo veel werk voor mensen die verwachten dat het 'gewoon werkt'.

Wat ook een voordeel is wanneer het in de kernel zit, is dat het dan als algemene functie werkt en geen versie specifieke zaken zal bevatten. Bij veel distro's zitten de tools ook in de repo maar die lopen uiteindelijk enorm achter. Dit kan voor rare problemen zorgen of er blijven security bugs open staan omdat backporten niet te doen is (om die reden zitten de tools en VirtualBox zelf ook niet meer in Debian Stable).
Ik zit mensen hier klagen over de grootte van de kernel. Als die dan toch echt te groot is dan compileer je de kernel toch zelf? Kan zelfs zonder initrd indien gewenst. Zo heb ik een kernel voor m'n laptop met alles wat ik nodig heb en die is zo'n 7MB en kan nog kleiner als het moet. Is snel en lost het hele probleem qua grootte en onoverzichtelijke modules op :)
hans was/is in loondienst bij redhat, toffe kerel! erg gericht op licentie/voorwaarden, en maakt zich hard voor opensource software en standaarden. zorgt dat de downloads (os) geen foutieve games/textures etc. bevatten welke rechten aan kleven. ken er weinig die zo fanatiek zijn als hij :+
Wat een boel mensen zeuren over bloat zeg. Het is gewoon een extra kernel module, je *hoeft* hem niet te laden hoor. Zal default ook niet geladen worden lijkt me. Als er een nieuwe netwerk kaart ondersteund wordt gaan mensen toch ook niet klagen over bloat?

Op dit item kan niet meer gereageerd worden.


Call of Duty: Black Ops 4 HTC U12+ dual sim LG W7 Google Pixel 3 XL OnePlus 6 Battlefield V Samsung Galaxy S9 Dual Sim Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V. © 1998 - 2018 Hosting door True

*