bbvirt - Online in de cloud

PROGRAMMA:

NAAM

bbvirt - Hotplug BitBabbler-apparaten in door libvirt beheerde domeinen

KORTE INHOUD

bbvirt actie [opties]

bbvirt hechten|DETACH apparaat [opties]

bbvirt alles bijvoegen|alles losmaken [domein] [opties]

PRODUCTBESCHRIJVING

De bbvirt programma is een poging om een ​​deel van de pijn weg te nemen van wat er op dit moment is
vereist om meerdere USB-apparaten te verdelen tussen de virtuele host- en gastmachines.
Hoewel er verschillende manieren zijn waarop dit kan worden geconfigureerd en beheerd, is er op dit moment geen enkele
van hen biedt eigenlijk op zichzelf een complete en samenhangende oplossing, ze vallen allemaal
op een significante en irritante manier tekort schieten. Het doel hier is om samen te werken
genoeg van die hacks om daadwerkelijk alle functionaliteit te krijgen die we nu willen, tot de
libvirt native ondersteuning hiervoor verbetert genoeg om het niet meer nodig te hebben.

Op dit moment gaat het hier om door libvirt beheerde virtuele QEMU/KVM-machines.

Wat do we willen?
Het ideale gedrag hier is vrij eenvoudig. Gegeven een willekeurig aantal BitBobbler
apparaten, zouden we ze moeten kunnen toewijzen aan de hostmachine of aan een gast-VM
erop rennen, en als we dat eenmaal doen, zouden ze zich moeten gedragen op de normale manier die van iedereen wordt verwacht
USB-apparaat.

- Als ze zijn aangesloten wanneer de gastmachine wordt gestart, moeten ze daardoor worden gezien
machine zoals ze zouden zijn door de host.

- Als ze worden aangesloten nadat de machine is gestart, moeten ze daarop worden aangesloten
machine zoals ze op de host zouden zijn.

- Als ze worden losgekoppeld terwijl de machine draait, moeten ze netjes worden verwijderd
het, zoals ze op de host zouden zijn.

Waarom kan niet we hebben het?
Op dit moment geeft libvirt ons twee manieren waarop we USB-apparaten van de host kunnen toewijzen aan een
gast domein.

- We kunnen ze toewijzen op basis van hun USB-leverancier en product-ID. Maar dat werkt alleen als er
is slechts een enkel apparaat van dat type in de host. Wat in de meeste vrij nutteloos is
de gevallen waar we hier om geven, waar de gastheer en elk van de gasten waarschijnlijk zullen zijn
hebben een of meer eigen BitBobbler-apparaten toegewezen gekregen.

- We kunnen ze toewijzen aan de hand van hun logische adres op de USB-bus. Maar dat is geen constante
die we statisch kunnen configureren voor het domein. Elke keer dat een apparaat is aangesloten, of
opnieuw aangesloten, of gereset, of de hostmachine opnieuw wordt opgestart, zal dat adres waarschijnlijk veranderen
omdat het dynamisch wordt toegewezen wanneer het apparaat op de bus wordt geïnventariseerd.

Er is een derde manier, maar deze is afhankelijk van het omzeilen van de normale libvirt-configuratie om te maken
direct gebruik van de QEMU-mogelijkheid om een ​​apparaat toe te wijzen op basis van zijn fysieke adres op de bus.
Dat is beter, maar nog steeds geen wondermiddel, omdat het op precies dezelfde manier afhankelijk is van pluggen
apparaten elke keer in precies dezelfde poorten (en als die poorten zijn opgesomd in
op dezelfde manier door de host bij elke herstart, wat ook niet gegarandeerd is). Het dwingt ook
ons om door andere hoepels te springen, omdat we dan extra complicaties nodig hebben om de
toegangsrechten van het apparaat handmatig buiten libvirt om, maar nog steeds in coördinatie
mee.

Het nog grotere falen, dat al deze methoden gemeen hebben, is dat ze allemaal afhankelijk zijn
het apparaat wordt al ingeplugd voordat de gast wordt gestart. Als het daarna wordt ingevoegd
de gast wordt gestart, of verwijderd en opnieuw aangesloten terwijl de gast draait, of als de host
bus of een hub botst waardoor er opnieuw verbinding wordt gemaakt, dan wordt het apparaat niet (opnieuw) aangesloten op de
gast. De enige manier om dit op te lossen als het gebeurt, is door het apparaat handmatig opnieuw te bevestigen met een
geheimzinnige bezwering in XML (die ervan uitgaat dat u het nieuwe adres van het apparaat kent), of
om de gast volledig uit te schakelen en opnieuw op te starten. Niet het toppunt van gebruiksvriendelijkheid
operatie die we hier zoeken.

Wat wel we do over ons het?
Er was enkele jaren geleden een patch ingediend bij libvirt die een apparaat mogelijk zou hebben gemaakt
gespecificeerd door zowel de USB-product-ID als het serienummer, maar dat kreeg wat push-
terug, en tot nu toe nog steeds niet stroomopwaarts toegepast. Dat zou een heel eind zijn gekomen
om dit zowel gemakkelijk als schoon te maken, zodat we ons alleen nog bezig hoeven te houden met het hotplug-aspect
met. We zullen de chagrijnige snark daarover achterlaten als een oefening voor de lezer ...

Een ander alternatief is dat we het vinden van het logische adres van het apparaat kunnen delegeren aan een hotplug
beheerder als udev(7). Dit is aantrekkelijk in die zin dat we weten wanneer het adres is
van een apparaat verandert en waarnaar het verandert, maar udev zelf is niet erg vriendelijk voor de
idee van lokale admin-aanpassing (hoewel het mogelijk is om te doen, lijkt het te krijgen
steeds sterker afgeraden) en het gebruik ervan vereist nog steeds wat externe lijm
vertaal zijn gebeurtenissen naar iets waar libvirt op kan reageren om de gast te configureren
machine.

De bbvirt programma biedt die lijm, en een gebruiksvriendelijke methode om welke toe te wijzen
apparaten horen bij welke gastdomeinen en een front-end die handmatig kan worden aangeroepen
of door andere door de beheerder gecontroleerde taken om snel en eenvoudig BitBabbler-apparaten toe te voegen of te verwijderen
vanaf een van de draaiende gastmachines.

Maar de beperking van deze aanpak is dat het niet gemakkelijk kan weten wanneer een gastmachine is
gestart waaraan apparaten moeten zijn toegevoegd die al zijn aangesloten. In theorie wij
zou ze kunnen toevoegen aan zijn persistente domeindefinitie, maar dat heeft zijn eigen problemen omdat
we kunnen alleen apparaten toevoegen op basis van hun kortstondige logische adres, en we kunnen niet garanderen dat we
worden gebeld om ze weer uit het domein te verwijderen wanneer dat adres ongeldig wordt
(zoals als de host plotseling wordt uitgeschakeld of anderszins niet netjes wordt afgesloten), dus wij
zou kunnen leiden tot veel verouderde vermeldingen die zich ophopen in de persistente domeinconfiguratie,
die later zou kunnen passen bij een heel ander apparaat dan waar we aan wilden koppelen
Het. Wat betekent dat totdat dat op de een of andere manier is opgelost, het alleen veilig is om ze toe te voegen aan een live gast
domein, zodat ze altijd weer worden verwijderd als het wordt gestopt, hoe dan ook
kwam uiteindelijk tot stilstand.

Het is duidelijk dat we nog een weg te gaan hebben om ons ideaal hier te bereiken.

Wat if we hit it Met *twee* hamers?
Er lijken maar twee manieren te zijn waarop we een melding kunnen krijgen dat er een gastmachine is
op dit moment gestart. De ene omvat het uitvoeren van nog een ander daemon-proces, wat voldoende zou zijn
weinig meer dan gewoon zitten wachten tot iemand een gast begint, zodat hij het ons kan vertellen
daarover. Maar dan zouden we nog iets anders moeten configureren, nog een ander proces
rennen, en nog meer problemen om uit te zoeken hoe we ervoor kunnen zorgen dat we geen race verliezen wanneer
de host wordt opgestart, tussen het ophalen van de eerste set apparaatgebeurtenissen, dat proces is
klaar en actief, en alle gasten die automatisch worden gestart bij het opstarten, beginnen daadwerkelijk.

De andere manier is om een ​​libvirt-haak te gebruiken. Wat op zijn beurt weer het probleem heeft van niet eigenlijk
waardoor we alle libvirt-functies ervan kunnen uitvoeren, wat we moeten doen om te koppelen
het apparaat naar de host. En waarvan we niet kunnen garanderen dat we die gewoon standaard kunnen installeren,
omdat er maar één zo'n hook op het systeem kan zijn, wat de lokale admin al kan
gebruiken...

Er is een derde manier, maar dat houdt in dat de lokale beheerder alle gasten moet starten
machines door een eigen wikkel, in plaats van via welk mechanisme dan ook dat ze al kennen
en gebruiken. Die niet schaalbaar is om andere USB-apparaten in dezelfde situatie te ondersteunen, waaronder
de vele manieren waarop dat een vreselijke oplossing zou zijn om mensen toe te brengen.

Maar er is een maas in de wet die we kunnen benutten. We kunnen de libvirt qemu hook gebruiken om een
gebeurtenis wijzigen voor udev, die op zijn beurt een beroep kan doen bbvirt op ongeveer dezelfde manier als dat zou doen
gebeuren als het apparaat echt hotplugged was, wat ons de extra indirecte laag geeft
dat moeten we veilig kunnen doen vanaf de haak. Rube Goldberg zou trots zijn, en
sommige stukken kunnen met de hand worden gemonteerd, maar als dit allemaal op zijn plaats is, kunnen we het hebben
iets dat lijkt op normale USB-functionaliteit in de gastmachines.

Het is niet mooi, maar het zal werken met waar we mee moeten werken.

Ok, voor slechts vertellen me WAAR naar hit het.
Om dit aan elkaar te rijgen, moet u voor het volgende zorgen:

- De udev(7) regels uit het bit-babbler-pakket zijn geïnstalleerd. Als je dit hebt geïnstalleerd
van de Debian-pakketten dat al zou moeten gebeuren. Als je dat niet hebt gedaan, moet je dat doen
installeer de regels die in debian/bit-babbler.udev van het bronpakket naar een
geschikte plaats op uw systeem (waarschijnlijk /etc/udev/rules d).

- De bbvirt(1) script is geïnstalleerd op een plaats waar het udev regels zullen het vinden. als jij
heeft dit niet geïnstalleerd vanuit de Debian-pakketten en het zit er ook niet in / Usr / bin, dan heb je nodig
om het te tweaken udev regels passen.

- De apparaten die u wilt gebruiken in gastmachines en de machines waarin u ze wilt gebruiken,
zijn gespecificeerd in de bbvirt configuratiebestand. De standaardlocatie daarvoor is
/etc/bit-babbelaar/vm.conf. Als u een ander bestand wilt gebruiken, moet u het doorgeven
locatie met de --config optie in het udev regels, en update het hook-script gebruik dat
bestand ook. De details van wat u in dat bestand kunt plaatsen, worden beschreven in de
CONFIGURATIE OPTIES sectie hieronder.

- Het libvirt hook-bestand is geïnstalleerd. Als al het bovenstaande is gedaan, zullen apparaten dat zijn
toegevoegd aan de actieve gastmachines als ze worden aangesloten terwijl de gast actief is.
Deze laatste stap zorgt ervoor dat apparaten die al zijn aangesloten, opnieuw worden toegevoegd
gestarte gasten ook (inclusief gasten die automatisch worden gestart wanneer de host
machine laarzen).

Totdat er een veilige manier is waarop we dit kunnen installeren zonder ermee in conflict te komen of het te overschrijven
een bestaande hook, zal iedereen deze stap handmatig moeten uitvoeren. Als je hebt geïnstalleerd
de Debian-pakketten, dan kan het voorbeeld van een hook-script dat we hiervoor hebben verstrekt, zijn
gevonden in /usr/share/doc/bit-babbler/examples/qemu-hook. Als je dat niet hebt gedaan, kan het worden gevonden
in libvirt/qemu-hook van het bronpakket.

U moet dat bestand installeren als /etc/libvirt/hooks/qemu, of voeg de inhoud samen met
het bestaan qemu bestand daar als je die hook al hebt ingesteld. Als dat bestand dat niet deed
eerder bestond, moet u opnieuw opstarten libvirtd(8) om het te laten beginnen met het te gebruiken.

Dat zou alle benodigde automatisering moeten dekken, maar u kunt ook apparaten koppelen en loskoppelen
ook handmatig te allen tijde. De details om dat te doen zullen in het volgende worden beschreven
sectie. Anders, met al het bovenstaande gedaan, is er geen andere reden om een ​​beroep te doen
bbvirt direct.

OPTIES

Er zijn twee primaire werkingsmodi voor bbvirt die worden geselecteerd door de initiaal
actie optie. Als de uit te voeren actie is hechten or DETACH dan maar een enkel apparaat
zal worden gehandeld, en welk apparaat dat moet zijn, moet expliciet worden gespecificeerd, zelfs als
er is op dat moment slechts één apparaat op de host aanwezig. Bij het aanroepen bbvirt handmatig,
de apparaat kan worden gespecificeerd door zijn serienummer, zijn logische adres op de bus (in de
formulier busnummer:devnum, gegeven als decimale gehele getallen), of het fysieke adres op de bus (in de
formulier busnummer-port[.haven ...]).

Als de uit te voeren actie is alles bijvoegen or alles losmaken, dan zijn de apparaten waarop moet worden gereageerd
geselecteerd door domein vereniging in plaats. Als een domein expliciet is gespecificeerd, dan alle
apparaten die in het configuratiebestand aan dat gastdomein zijn toegewezen, worden geactiveerd
op dezelfde manier alsof bbvirt werd voor elk van hen afzonderlijk ingeroepen met de
hechten or DETACH actie. Als Nee domein wordt verstrekt, dan alle geconfigureerde guest
domeinen zullen op deze manier worden aangepakt.

De volgende extra opties zijn beschikbaar:

-C, --config
Geef een alternatief configuratiebestand op om de apparaattoewijzingen uit te importeren.
Als het pad naar het bestand niet expliciet wordt opgegeven, wordt ernaar gezocht in
de /etc/bit-babbelaar map (met een .conf achtervoegsel).

-C, --verbinden=URI
Geef het Vers(1) verbinding URI gebruiken. Dit overschrijft een DOMAIN_URI reeks
voor het domein in het configuratiebestand. Als dat niet is ingesteld met een van deze
methoden dan de Vers standaard voor de gebruiker die wordt uitgevoerd bbvirt gebruikt.

-NS, --domein=naam
Geef het libvirt-domein op waarop moet worden gereageerd. Dit kan worden gebruikt om het apparaat te overschrijven
toewijzing uit het configuratiebestand wanneer bbvirt handmatig wordt aangeroepen, of om te handelen
op een apparaat of domein dat momenteel niet is opgegeven in het configuratiebestand.

-B, --busnummer=num
Geef het USB-busnummer op waarop het apparaat is aangesloten. Deze optie is meestal
gebruikt om te vermijden bbvirt nodig om dit op te zoeken als het al bekend is (zoals wanneer
het wordt genoemd vanuit een udev regel). Er is meestal niet veel reden om dit door te geven als
aanroepen bbvirt handmatig, omdat u het apparaat gewoon kunt specificeren door zijn logische of
fysiek adres in plaats daarvan.

-NS, --devgetal=num
Geef het USB-apparaatnummer op dat momenteel aan het apparaat is toegewezen. Samen met
het busnummer, dit vormt het logische adres van het apparaat. Deze optie is
meestal gebruikt om te vermijden bbvirt nodig om dit op te zoeken als het al bekend is (zoals
zoals wanneer het wordt aangeroepen vanuit een udev regel). Er is meestal niet veel reden om te slagen
dit bij aanroepen bbvirt handmatig, omdat u het apparaat gewoon kunt specificeren aan de hand van zijn
logisch adres in plaats daarvan.

-N, --oefening
Bevestig of ontkoppel geen apparaten, laat gewoon zien wat er zou worden geprobeerd als dit een
live rennen. Deze optie impliceert een minimaal niveau van --uitgebreid, maar de breedsprakigheid mag
verder worden verhoogd door die optie ook expliciet mee te geven.

-in, --uitgebreid
Maak meer lawaai over wat er echt aan de hand is. Het kan meerdere keren worden doorgegeven aan
vergroot de breedsprakigheid verder.

-?, --help
Toon een korte samenvatting van de beschikbare opties.

CONFIGURATIE OPTIES

De bbvirt configuratiebestand bevat variabeletoewijzingen met behulp van de slaan(1) schelp
syntaxis. Het is afkomstig van een shell-fragment, dus je zou in principe het
configuratie voor elk domein dynamisch, maar meestal een eenvoudige statische toewijzing
van apparaten naar domeinen is voldoende. Als je ervoor kiest om er code in uit te voeren, zou je heel erg moeten zijn
defensief over naamruimte voor andere variabelen die u gebruikt, of andere bijwerkingen die u heeft
zou kunnen veroorzaken. Er kan een willekeurig aantal gastdomeinen in worden geconfigureerd.

Voor elk gastdomein bepalen twee variabelen het gedrag van bbvirt:

DOMAIN_URI_domein=URI
Deze variabele is optioneel en stelt de Vers(1) verbinding URI gebruiken wanneer
het bevestigen of losmaken van apparaten van het gegeven domein. Indien de --aansluiten Optie is
expliciet doorgegeven aan bbvirt het overschrijft wat hier is ingesteld. Als de verbinding
URI niet is ingesteld met een van deze methoden, dan wordt het Vers standaard voor de gebruiker
lopend bbvirt zal worden gebruikt (wat normaal gesproken root zou zijn als het wordt uitgevoerd vanuit udev).

DOMAIN_RNG_domein=( apparaat serie- nummers ... )
Deze variabele is vereist als automatische doorgifte van apparaten naar een domein is
gewenst. Het is een bash-array, gevuld met een door spaties gescheiden lijst van alle
apparaatserienummers die u wilt toewijzen domein. Het is geen fout voor
apparaten die hier worden vermeld en die momenteel niet zijn aangesloten. Het is belangrijk om
zorg ervoor dat apparaten slechts aan één apparaat zijn toegewezen domein hoewel, en die apparaten
toegewezen aan gastdomeinen zal niet worden gebruikt door een zaad(1) instantie draait op de
gastheer (wat betekent de zaad configuratie moet worden doorgegeven aan een expliciete lijst van
de apparaten die het ook kan gebruiken).

Hier moet altijd het serienummer van het apparaat worden gebruikt. U kunt geen apparaat specificeren door
zijn logische of fysieke adres op de bus (zoals je op de meeste andere plaatsen waar
we nemen een apparaat-ID).

Gebruik bbvirt online met behulp van onworks.net-services