bbvirt - Online în cloud

PROGRAM:

NUME

bbvirt - conectați dispozitivele BitBabbler în domenii gestionate de libvirt

REZUMAT

bbvirt acțiune [Opțiuni]

bbvirt atașa|DETAȘEAZĂ dispozitiv [Opțiuni]

bbvirt atașează-toate|desprinde-toate [domeniu] [Opțiuni]

DESCRIERE

bbvirt programul este o încercare de a elimina o parte din durerea din ceea ce este în prezent
necesare pentru a distribui mai multe dispozitive USB între mașinile virtuale gazdă și invitate.
Deși există mai multe moduri în care acest lucru poate fi configurat și gestionat, în prezent niciunul
dintre ele oferă de fapt o soluție completă și coerentă pe cont propriu, toate cad
scurt de notă într-un mod semnificativ și enervant. Scopul aici este de a pune cap la cap
suficiente dintre acele hack-uri pentru a obține de fapt toată funcționalitatea pe care ni le dorim acum, până la
Suportul nativ libvirt pentru acest lucru se îmbunătățește suficient pentru a nu mai avea nevoie de el.

În prezent, aceasta se ocupă de mașinile virtuale QEMU/KVM gestionate de libvirt.

Ce do we vrei?
Comportamentul ideal aici este destul de simplu. Având în vedere un număr arbitrar de BitBabbler
dispozitivelor, ar trebui să le putem atribui fie mașinii gazdă, fie unei VM invitate
rulează pe el și, odată ce facem asta, ar trebui să se comporte în modul normal de așteptat de la oricare
Dispozitiv USB.

- Dacă sunt conectate la priză atunci când mașina oaspete este pornită, ar trebui să fie văzute de asta
mașină așa cum ar fi de către gazdă.

- Dacă sunt conectate după pornirea mașinii, ar trebui să fie conectate la aceasta
mașină așa cum ar fi pe gazdă.

- Dacă sunt scoase din priză în timp ce mașina funcționează, trebuie îndepărtate curat
asta, așa cum ar fi pe gazdă.

De ce nu se poate we avea aceasta?
În acest moment, libvirt ne oferă două moduri prin care putem aloca dispozitive USB de la gazdă la a
domeniu invitat.

- Le putem atribui prin furnizorul lor USB și ID-ul produsului. Dar asta funcționează doar când există
este doar un singur dispozitiv de acest tip în gazdă. Ceea ce este destul de inutil în majoritatea
cazurile la care ne pasă aici, unde sunt probabil gazda și fiecare dintre oaspeți
au unul sau mai multe dispozitive BitBabbler atribuite lor.

- Le putem atribui după adresa lor logică pe magistrala USB. Dar asta nu este o constantă
pe care le putem configura static pentru domeniu. De fiecare dată când un dispozitiv este conectat, sau
repornit, sau resetat, sau mașina gazdă este repornită, acea adresă este probabil să se schimbe
deoarece este alocat dinamic atunci când dispozitivul este enumerat pe magistrală.

Există o a treia cale, dar se bazează pe ocolirea configurației normale pentru libvirt
utilizarea directă a capacității QEMU de a atribui un dispozitiv după adresa fizică pe magistrală.
Ceea ce este mai bine, dar tot nu este un glonț magic, deoarece se bazează pe conectare exact la fel
dispozitivele în exact aceleași porturi de fiecare dată (și când aceste porturi sunt enumerate în
în același mod de către gazdă la fiecare repornire, ceea ce nu este garantat). De asemenea, forțează
noi să sărim prin alte cercuri, deoarece atunci avem nevoie de complicații suplimentare pentru a gestiona
permisiunile de acces ale dispozitivului manual în afara libvirt, dar încă în coordonare
cu ea.

Eșecul și mai mare, pe care toate aceste metode îl au în comun, este de care depind toate
dispozitivul fiind deja conectat înainte ca invitatul să fie pornit. Dacă se introduce după
invitatul este pornit, sau eliminat și reconectat în timp ce oaspetele rulează sau dacă gazda
magistrala sau un hub sare provocând o reconectare, atunci dispozitivul nu va fi (re)atașat la
oaspete. Singura modalitate de a remedia acest lucru, dacă se întâmplă, este să reatașați manual dispozitivul cu un
incantație arcană în XML (care se bazează pe cunoașterea noii adrese a dispozitivului) sau
pentru a opri complet și a reporni oaspetele. Nu punctul culminant al user-friendly
operația pe care o căutăm aici.

Ce poate să we do despre aceasta?
A fost un patch trimis la libvirt cu câțiva ani în urmă, care ar fi permis un dispozitiv
să fie specificat atât prin ID-ul produsului USB, cât și prin numărul de serie, dar asta a primit ceva push-
înapoi, și până acum nu a fost aplicat încă în amonte. Asta ar fi mers mult
pentru a face acest lucru atât ușor, cât și curat, lăsându-ne doar cu aspectul hotplug de rezolvat
cu. Vom lăsa o vorbă morocănosă despre asta ca un exercițiu pentru cititor...

O altă alternativă este că putem delega găsirea adresei logice a dispozitivului unui hotplug
manager ca udev(7). Acest lucru este atractiv în sensul că putem ști când adresa
a unui dispozitiv se schimbă și în ce se schimbă, dar udev în sine nu este foarte prietenos cu
ideea personalizării administratorului local (deși este posibil de făcut, se pare că va primi
din ce în ce mai puternic descurajat) și folosirea lui necesită încă ceva lipici extern pentru
traduce evenimentele sale în ceva asupra căruia libvirt poate acționa pentru a configura oaspetele
mașină.

bbvirt programul oferă acel adeziv și o metodă prietenoasă de a atribui care
Dispozitivele ar trebui să aparțină căror domenii invitate și un front end care poate fi invocat manual
sau prin alte sarcini controlate de administrator pentru a adăuga sau elimina rapid și ușor dispozitive BitBabbler
de la oricare dintre mașinile oaspeți care rulează.

Dar limitarea pe care o are această abordare este că nu poate ști cu ușurință când este o mașină oaspete
a început, care ar trebui să aibă dispozitive care sunt deja conectate adăugate. În teorie noi
le-ar putea adăuga la definiția de domeniu persistentă, dar asta are propriile sale probleme deoarece
putem adăuga dispozitive numai după adresa lor logică efemeră și nu putem garanta că noi
va fi apelat pentru a le elimina din nou din domeniu atunci când acea adresă devine invalidă
(ca dacă gazda este oprită brusc sau altfel nu este închisă curat), așa că noi
ar putea ajunge cu multe intrări învechite care se acumulează în configurația de domeniu persistentă,
care mai târziu ar putea potrivi un dispozitiv complet diferit cu ceea ce ne-am dorit să-l atașăm
aceasta. Ceea ce înseamnă că până când nu se rezolvă cumva, este doar sigur să le adaugi la un oaspete live
domeniu, astfel încât acestea să fie întotdeauna eliminate din nou atunci când este oprit, indiferent cum ar fi
a ajuns să fie oprit.

Este clar că mai avem ceva de parcurs pentru a ajunge la idealul nostru aici.

Ce if we lovit it cu *Două* ciocane?
Se pare că există doar două moduri prin care putem fi notificați despre existența unei mașini invitate
început în prezent. Unul implică rularea unui alt proces demon, ceea ce ar funcționa
puțin mai mult decât să stai în jur, așteptând ca cineva să înceapă un oaspete, ca să ne spună
despre asta. Dar atunci am avea încă un lucru de configurat, încă un proces
alergare și, totuși, mai multe probleme cu a afla cum să ne asigurăm că nu pierdem o cursă când
gazda este pornită, între obținerea setului inițial de evenimente de dispozitiv, acel proces fiind
gata și activă, iar toți invitații care vor fi porniți automat la pornirea pornirii efectiv.

Cealaltă modalitate este să utilizați un cârlig libvirt. Care, la rândul său, are problema de a nu de fapt
permițându-ne să rulăm orice funcții libvirt din acesta, ceea ce trebuie să facem pentru a atașa
dispozitivul către gazdă. Și pe care nu putem garanta că le putem instala în mod implicit,
deoarece poate exista un singur astfel de cârlig pe sistem, pe care administratorul local îl poate deja
sa folosesti...

Există o a treia modalitate, dar aceasta ar implica solicitarea administratorului local să înceapă toți oaspeții
mașinile printr-un ambalaj al nostru, în loc să fie prin orice mecanism pe care îl cunosc deja
si foloseste. Care nu se scalează pentru a suporta alte dispozitive USB în aceeași situație, printre
multele modalități care ar fi o soluție oribilă pentru a le aplica oamenilor.

Dar există o lacună pe care o putem exploata. Putem folosi cârligul libvirt qemu pentru a declanșa a
schimbare eveniment pentru udev, care la rândul său poate invoca bbvirt cam în același mod în care ar fi
se întâmplă dacă dispozitivul a fost cu adevărat conectat la cald, ceea ce ne oferă un strat suplimentar de indirect
trebuie să putem face asta în siguranță din cârlig. Rube Goldberg ar fi mândru și
unele dintre piese pot necesita asamblare manuală, dar cu toate acestea la locul lor, putem avea
ceva care seamănă cu funcționalitatea USB normală în mașinile invitate.

Nu este frumos, dar va funcționa cu ceea ce trebuie să lucrăm.

Ok, doar spune me Unde la lovit aceasta.
Pentru a le pune împreună, va trebui să vă asigurați de toate următoarele:

- Cu privire la udev(7) sunt instalate regulile din pachetul bit-babbler. Dacă ai instalat asta
din pachetele Debian care ar trebui deja făcute. Dacă nu ai făcut-o, va trebui
instalați regulile care se găsesc în debian/bit-babbler.udev de la pachetul sursă la a
loc potrivit pe sistemul dvs. (probabil /etc/udev/rules.d).

- Cu privire la bbvirt(1) scriptul este instalat într-un loc în care udev regulile o vor găsi. daca tu
nu a instalat acest lucru din pachetele Debian și nu este în / usr / bin, atunci vei avea nevoie
pentru a modifica udev reguli potrivite.

- Dispozitivele pe care doriți să le utilizați în mașinile invitate și mașinile în care doriți să le utilizați,
sunt specificate în bbvirt Fișier de configurare. Locația implicită pentru aceasta este
/etc/bit-babbler/vm.conf. Dacă doriți să utilizați un alt fișier, va trebui să îl transmiteți
locație cu --config opțiune în udev regulile și actualizați scriptul hook folosiți asta
dosar de asemenea. Detaliile despre ceea ce puteți pune în acel fișier sunt descrise în documentul
CONFIGURARE OPŢIUNI secțiunea de mai jos.

- Fișierul libvirt hook este instalat. Dacă toate cele de mai sus sunt făcute, atunci dispozitivele vor fi
adăugat la mașinile invitate care rulează dacă sunt conectate în timp ce oaspetele rulează.
Acest ultim pas asigură că dispozitivele care sunt deja conectate vor fi adăugate la noi
și oaspeții porniți (care include oaspeții care sunt porniți automat atunci când gazda
cizme de mașină).

Până când există o modalitate sigură de a putea instala acest lucru fără a intra în conflict sau a-l suprascrie
un cârlig existent, toată lumea va trebui să facă acest pas manual. Daca ai instalat
pachetele Debian, apoi exemplul de script hook pe care l-am furnizat pentru aceasta poate fi
gasit in /usr/share/doc/bit-babbler/examples/qemu-hook. Dacă nu ai făcut-o, poate fi găsit
in libvirt/qemu-hook a pachetului sursă.

Va trebui să instalați acel fișier ca /etc/libvirt/hooks/qemu, sau îmbina conținutul acestuia cu
existenta whoa dosar acolo dacă aveți deja acel cârlig setat. Dacă acel fișier nu a făcut-o
exista anterior, va trebui să reporniți libvirtd(8) pentru a-l face să înceapă să-l folosească.

Aceasta ar trebui să acopere toată automatizarea necesară, dar puteți, de asemenea, să atașați și să detașați dispozitivele
manual și în orice moment. Detaliile pentru a face acest lucru vor fi descrise în cele ce urmează
secțiune. În caz contrar, cu toate cele de mai sus făcute, nu există niciun alt motiv pentru a fi nevoie să invoci
bbvirt direct.

OPŢIUNI

Există două moduri principale de funcționare pentru bbvirt care sunt selectate după inițială
opțiunea de acțiune. Dacă acţiunea de efectuat este atașa or DETAȘEAZĂ atunci doar un singur dispozitiv
se va acționa asupra și care dispozitiv ar trebui să fie specificat în mod explicit, chiar dacă
există un singur dispozitiv prezent pe gazdă la momentul respectiv. La invocare bbvirt manual,
il dispozitiv poate fi specificat prin numărul său de serie, adresa sa logică pe magistrală (în
formă busnum:devnum, dat ca numere întregi zecimale), sau adresa sa fizică pe magistrală (în
formă busnum-port[.port ...]).

Dacă acţiunea de efectuat este atașează-toate or desprinde-toate, atunci dispozitivele asupra cărora trebuie să acționeze sunt
selectat de domeniu asociație în schimb. În cazul în care o domeniu este specificat în mod explicit, apoi toate
dispozitivele care sunt alocate acelui domeniu invitat în fișierul de configurare vor fi acționate
asupra în același mod ca și cum bbvirt a fost invocat pentru fiecare dintre ei individual cu
atașa or DETAȘEAZĂ acțiune. Daca nu domeniu este furnizat, apoi toți oaspeții configurați
domeniile vor fi acționate în acest fel.

Sunt disponibile următoarele opțiuni suplimentare:

-C, --config
Specificați un fișier de configurare alternativ din care să importați atribuirile dispozitivului.
Dacă calea către fișier nu este furnizată în mod explicit, atunci aceasta va fi căutată în
il /etc/bit-babbler director (cu a .conf sufix).

-c, --conecta=URI
Se specifică Virsh(1) conexiune URI a folosi. Aceasta va anula a DOMAIN_URI set
pentru domeniul din fișierul de configurare. Dacă nu este setat folosind niciuna dintre acestea
metode apoi cel Virsh implicit pentru utilizatorul care rulează bbvirt va fi folosit.

-D, --domeniu=nume
Specificați domeniul libvirt asupra căruia să acționați. Aceasta poate fi folosită pentru a anula dispozitivul
alocare din fișierul de configurare când bbvirt este invocat manual sau pentru a acționa
pe un dispozitiv sau domeniu care nu este specificat în prezent în fișierul de configurare.

-b, --busnum=o
Specificați numărul magistralei USB la care este atașat dispozitivul. Această opțiune este în mare parte
folosit pentru a evita bbvirt trebuie să caute acest lucru atunci când este deja cunoscut (cum ar fi când
se numeste de la a udev regulă). De obicei, nu există prea multe motive pentru a trece acest lucru dacă
invocante bbvirt manual, deoarece puteți specifica doar dispozitivul după logica sau
adresa fizică în schimb.

-d, --devnum=o
Specificați numărul dispozitivului USB căruia i-a fost atribuit în prezent dispozitivul. Impreuna cu
numărul magistralei, acesta formează adresa logică a dispozitivului. Această opțiune este
folosit mai ales pentru a evita bbvirt trebuie să caute acest lucru atunci când este deja cunoscut (cum ar fi
ca atunci când este chemat de la a udev regulă). De obicei nu există prea multe motive să treci
asta dacă se invocă bbvirt manual, deoarece puteți specifica doar dispozitivul după el
în schimb adresa logică.

-n, --funcție uscată
Nu atașați și nu detașați niciun dispozitiv, doar arătați ce s-ar încerca dacă ar fi un
alerga live. Această opțiune implică un nivel minim de --verbos, dar verbozitatea poate
să fie mărită în continuare prin trecerea în mod explicit a acestei opțiuni.

-v, --verbos
Faceți mai mult zgomot despre ceea ce se întâmplă cu adevărat. Poate fi transmis de mai multe ori către
crește și mai mult verbozitatea.

-?, --Ajutor
Afișați un scurt rezumat al opțiunilor disponibile.

CONFIGURARE OPŢIUNI

bbvirt fişierul de configurare conţine atribuiri de variabile utilizând pocni(1) coajă
sintaxă. Este obținut ca un fragment de shell, astfel încât, în principiu, puteți construi
configurație pentru fiecare domeniu în mod dinamic, dar de obicei o simplă atribuire statică
de dispozitive la domenii va fi suficient. Dacă alegeți să rulați cod în el, ar trebui să fiți foarte
defensiv cu privire la spația numelor oricăror alte variabile pe care le utilizați sau orice alte efecte secundare
ar putea cauza să se întâmple. În el poate fi configurat orice număr de domenii invitate.

Pentru fiecare domeniu invitat, două variabile controlează comportamentul bbvirt:

DOMAIN_URI_domeniu=URI
Această variabilă este opțională și setează Virsh(1) conexiune URI a folosi când
atașarea sau detașarea dispozitivelor de la dat domeniu. Dacă --conectați opțiunea este
transmis în mod explicit la bbvirt va trece peste ceea ce este setat aici. Dacă conexiunea
URI nu este setat folosind nici una dintre aceste metode, apoi Virsh implicit pentru utilizator
funcţionare bbvirt va fi folosit (care ar fi în mod normal root dacă rulează de la udev).

DOMAIN_RNG_domeniu=( dispozitiv de serie numere ... )
Această variabilă este necesară dacă trecerea automată a dispozitivelor către un domeniu este
dorit. Este o matrice bash, populată cu o listă separată de spații a tuturor
numerele de serie ale dispozitivului cărora doriți să le alocați domeniu. Nu este o eroare pt
dispozitivele care vor fi enumerate aici care nu sunt în prezent conectate. Este important să
asigurați-vă că dispozitivele sunt alocate doar unuia domeniu totuși, și că dispozitivele
atribuite domeniilor invitate nu vor fi utilizate de către a sămânțat(1) instanță care rulează pe
gazdă (care înseamnă sămânțat configurației trebuie să primească o listă explicită de
dispozitivele pe care le poate folosi).

Numărul de serie al dispozitivului trebuie utilizat întotdeauna aici. Nu puteți specifica un dispozitiv prin
adresa sa logică sau fizică din autobuz (cum poți în majoritatea altor locuri unde
luăm un ID de dispozitiv).

Utilizați bbvirt online folosind serviciile onworks.net