bbvirt - Online nel cloud

PROGRAMMA:

NOME

bbvirt - hotplug dispositivi BitBabbler in domini gestiti da libvirt

SINOSSI

bbvirt azione [Opzioni]

bbvirt allegare|DETACH dispositivo [Opzioni]

bbvirt attacca-tutto|stacca-tutto [dominio] [Opzioni]

DESCRIZIONE

I bbvirt programma è un tentativo di alleviare un po' il dolore di ciò che è attualmente
necessario per distribuire più dispositivi USB tra le macchine virtuali host e guest.
Sebbene ci siano diversi modi in cui questo può essere configurato e gestito, al momento nessuno
di loro in realtà forniscono da soli una soluzione completa e coerente, tutti cadono
al di sotto del segno in qualche modo significativo e fastidioso. L'obiettivo qui è quello di mettere insieme
abbastanza di quegli hack per ottenere effettivamente tutte le funzionalità che vogliamo ora, fino al
Il supporto nativo di libvirt per questo migliora abbastanza da non averne più bisogno.

Al momento si tratta di macchine virtuali QEMU/KVM gestite da libvirt.

Che do we volere?
Il comportamento ideale qui è piuttosto semplice. Dato un numero arbitrario di BitBabbler
dispositivi, dovremmo essere in grado di assegnarli alla macchina host o a una macchina virtuale ospite
in esecuzione su di esso, e una volta che lo facciamo dovrebbero comportarsi nel modo normale che ci si aspetta da qualsiasi
Dispositivo USB.

- Se sono collegati all'avvio della macchina ospite, dovrebbero essere visti da questo
macchina come sarebbero dall'host.

- Se sono collegati dopo che la macchina è stata avviata, dovrebbero essere collegati a caldo in quello
macchina come sarebbero sull'host.

- Se vengono scollegati mentre la macchina è in funzione, devono essere rimossi in modo pulito da
it, come sarebbero sull'host.

Perché non può we avere vero?
In questo momento, libvirt ci offre due modi in cui possiamo assegnare dispositivi USB dall'host a a
dominio ospite.

- Possiamo assegnarli tramite il fornitore USB e l'ID prodotto. Ma funziona solo quando c'è
è solo un singolo dispositivo di quel tipo nell'host. Che è abbastanza inutile nella maggior parte dei
i casi che ci interessano qui, in cui è probabile che l'ospite e ciascuno degli ospiti
avere uno o più dispositivi BitBabbler a loro assegnati.

- Possiamo assegnarli tramite il loro indirizzo logico sul bus USB. Ma non è una costante
che possiamo configurare staticamente per il dominio. Ogni volta che si collega un dispositivo, oppure
ricollegato o ripristinato o la macchina host viene riavviata, è probabile che l'indirizzo cambi
poiché viene allocato dinamicamente quando il dispositivo viene enumerato sul bus.

C'è un terzo modo, ma si basa sul bypassare la normale configurazione di libvirt per fare
uso diretto della capacità QEMU di assegnare un dispositivo tramite il suo indirizzo fisico sul bus.
Che è meglio, ma non è ancora una bacchetta magica poiché si basa sulla connessione esattamente allo stesso modo
dispositivi esattamente nelle stesse porte ogni volta (e avendo quelle porte enumerate in
allo stesso modo dall'host ad ogni riavvio, il che non è nemmeno garantito). Forza anche
noi per saltare attraverso altri cerchi, dal momento che abbiamo bisogno di ulteriori complicazioni per gestire il
permessi di accesso del dispositivo manualmente al di fuori di libvirt, ma ancora in coordinamento
con esso.

L'errore ancora più grande, che tutti questi metodi hanno in comune, è che dipendono tutti da
il dispositivo è già collegato prima dell'avvio del guest. Se viene inserito dopo
il guest viene avviato o rimosso e ricollegato mentre il guest è in esecuzione o se l'host
bus o un hub rimbalza causando una riconnessione, quindi il dispositivo non sarà (ri)collegato al
ospite. L'unico modo per risolvere il problema è ricollegare manualmente il dispositivo con un
incantesimo arcano in XML (che si basa sulla conoscenza del nuovo indirizzo del dispositivo), oppure
per spegnere completamente e riavviare il guest. Non l'apice della facilità d'uso
operazione che stiamo cercando qui.

Che può we do circa vero?
Alcuni anni fa è stata presentata una patch a libvirt che avrebbe consentito un dispositivo
essere specificato sia dal suo ID prodotto USB che dal suo numero di serie, ma questo ha avuto qualche spinta-
indietro, e finora non è stato ancora applicato a monte. Sarebbe andata molto lontano
per rendere questo sia facile che pulito, lasciandoci solo con l'aspetto hotplug da affrontare
insieme a. Lasceremo uno sarcasmo scontroso su questo come esercizio per il lettore...

Un'altra alternativa è delegare la ricerca dell'indirizzo logico del dispositivo a un hotplug
manager come udev(7). Questo è attraente nel senso che possiamo sapere quando l'indirizzo
di un dispositivo cambia e in cosa cambia, ma udev di per sé non è molto amichevole con il
idea di personalizzazione dell'amministratore locale (mentre è possibile farlo, sembra che stia ottenendo
sempre più fortemente sconsigliato) e il suo utilizzo richiede ancora un po' di colla esterna per
tradurre i suoi eventi in qualcosa su cui libvirt può agire per configurare il guest
macchina.

I bbvirt programma fornisce quella colla e un metodo intuitivo per assegnare quale
i dispositivi dovrebbero appartenere a quali domini guest e un front-end che può essere richiamato manualmente
o da altre attività controllate dall'amministratore per aggiungere o rimuovere rapidamente e facilmente dispositivi BitBabbler
da una qualsiasi delle macchine guest in esecuzione.

Ma il limite di questo approccio è che non può sapere facilmente quando è presente una macchina ospite
avviato che dovrebbe avere dispositivi già collegati aggiunti ad esso. In teoria noi
potrebbe aggiungerli alla sua definizione di dominio persistente, ma questo ha i suoi problemi perché
possiamo aggiungere dispositivi solo tramite il loro indirizzo logico effimero e non possiamo garantire che noi
verrà chiamato per rimuoverli di nuovo dal dominio quando quell'indirizzo diventa non valido
(come se l'host si spegne improvvisamente o non viene spento in modo pulito), quindi noi
potrebbe finire con molte voci obsolete che si accumulano nella configurazione del dominio persistente,
che potrebbe in seguito abbinare un dispositivo completamente diverso a quello a cui avremmo voluto collegare
esso. Il che significa che fino a quando non viene risolto in qualche modo, è solo sicuro aggiungerli a un ospite dal vivo
dominio, in modo che vengano sempre rimossi di nuovo quando viene interrotto, indipendentemente da come
finito per essere fermato.

Chiaramente abbiamo ancora molta strada da fare per raggiungere il nostro ideale qui.

Che if we colpire it con *Due* martelli?
Sembra che ci siano solo due modi in cui possiamo essere avvisati di una macchina ospite in corso
iniziato al momento. Uno prevede l'esecuzione di un altro processo demone, che andrebbe bene
poco più che stare seduti ad aspettare che qualcuno inizi un ospite in modo che possa dircelo
riguardo a questo. Ma poi avremmo un'altra cosa da configurare, un altro processo
correre, e ancora più problemi per capire come assicurarci di non perdere una gara quando
l'host viene avviato, tra l'ottenimento del set iniziale di eventi del dispositivo, il processo in corso
pronto e attivo e tutti i guest che verranno avviati automaticamente all'avvio effettivamente in fase di avvio.

L'altro modo è usare un hook libvirt. Che a sua volta ha il problema di non in realtà
permettendoci di eseguire qualsiasi funzione libvirt da esso, cosa che dobbiamo fare per allegare
il dispositivo all'host. E che non possiamo garantire che possiamo semplicemente installare per impostazione predefinita,
perché può esserci un solo hook di questo tipo nel sistema, che l'amministratore locale potrebbe già
usare...

C'è un terzo modo, ma ciò implicherebbe la richiesta all'amministratore locale di avviare tutti gli ospiti
macchine attraverso un nostro involucro, invece che tramite qualsiasi meccanismo che già conoscono
e uso. Che non è scalabile per supportare altri dispositivi USB nella stessa situazione, tra
i molti modi che sarebbe una soluzione orribile da infliggere alle persone.

Ma c'è una scappatoia che possiamo sfruttare. Possiamo usare l'hook libvirt qemu per attivare a
cambia evento per udev, che a sua volta può invocare bbvirt più o meno allo stesso modo in cui sarebbe
succede se il dispositivo è stato davvero collegato a caldo, il che ci dà un ulteriore livello di indiretto
dobbiamo essere in grado di farlo in sicurezza dal gancio. Rube Goldberg sarebbe orgoglioso, e
alcuni pezzi potrebbero richiedere l'assemblaggio manuale, ma con tutto questo a posto, possiamo avere
qualcosa di simile alla normale funzionalità USB nelle macchine guest.

Non è carino, ma funzionerà con ciò con cui dobbiamo lavorare.

Ok, ad appena dire me where a colpire esso.
Per mettere insieme questo, dovrai assicurarti quanto segue:

- Il udev(7) sono installate le regole del pacchetto bit-babbler. Se hai installato questo
dai pacchetti Debian che dovrebbe già essere fatto. Se non l'hai fatto, dovrai
installare le regole che si trovano in debian/bit-babbler.udev dal pacchetto sorgente ad a
posto adatto sul tuo sistema (probabilmente /etc/udev/rules.d).

- Il bbvirt(1) lo script è installato in un luogo in cui il udev le regole lo troveranno. Se tu
non l'ho installato dai pacchetti Debian e non è in / Usr / bin, allora avrai bisogno
modificare il udev regole per adattarsi.

- I dispositivi che desideri utilizzare nelle macchine ospiti e le macchine in cui desideri utilizzarli,
sono specificati nel bbvirt file di configurazione. La posizione predefinita per questo è
/etc/bit-babbler/vm.conf. Se desideri utilizzare un file diverso dovrai passare il suo
posizione con il --config opzione nel udev regole e aggiorna lo script hook usa quello
anche file. I dettagli di ciò che puoi inserire in quel file sono descritti in
CONFIGURAZIONE VERSIONI sezione sottostante.

- Il file hook libvirt è installato. Se viene fatto tutto quanto sopra, i dispositivi saranno
aggiunti ai computer guest in esecuzione se vengono collegati mentre il guest è in esecuzione.
Quest'ultimo passaggio garantisce che i dispositivi già collegati vengano aggiunti a quelli nuovi
ha avviato anche gli ospiti (che include gli ospiti che vengono avviati automaticamente quando l'host
stivali della macchina).

Fino a quando non ci sarà un modo sicuro per installarlo senza entrare in conflitto o sovrascrivere
un hook esistente, tutti dovranno eseguire questo passaggio manualmente. Se hai installato
i pacchetti Debian, quindi lo script hook di esempio che abbiamo fornito per questo può essere
trovato in /usr/share/doc/bit-babbler/examples/qemu-hook. Se non l'hai fatto può essere trovato
in libvirt/qemu-hook del pacchetto sorgente.

Dovrai installare quel file come /etc/libvirt/hooks/qemu, o unisci il suo contenuto con
l'esistente whoa file lì se hai già quel set di hook. Se quel file non lo ha fatto
esistere in precedenza, sarà necessario riavviare libvirtd(8) per farlo iniziare a usarlo.

Ciò dovrebbe coprire tutta l'automazione necessaria, ma puoi anche collegare e scollegare i dispositivi
anche manualmente in qualsiasi momento. I dettagli per farlo saranno descritti di seguito
sezione. Altrimenti, fatto tutto quanto sopra, non c'è altro motivo per dover invocare
bbvirt direttamente.

VERSIONI

Ci sono due modalità principali di funzionamento per bbvirt che sono selezionati dall'iniziale
opzione di azione. Se l'azione da eseguire è allegare or DETACH quindi un solo dispositivo
su cui si agisce e quale dispositivo dovrebbe essere specificato in modo esplicito, anche se
sull'host è presente un solo dispositivo alla volta. Quando si invoca bbvirt manualmente,
, il dispositivo può essere specificato dal suo numero di serie, dal suo indirizzo logico sul bus (nel
modulo busnum:devnum, dato come numeri interi decimali), o il suo indirizzo fisico sul bus (nel
modulo busnum-porto[.porta ...]).

Se l'azione da eseguire è attacca-tutto or stacca-tutto, allora i dispositivi su cui agire sono
selezionati da dominio associazione invece. Se un dominio è esplicitamente specificato, allora all
verranno attivati ​​i dispositivi assegnati a quel dominio ospite nel file di configurazione
su come se bbvirt è stato invocato per ciascuno di essi singolarmente con il
allegare or DETACH azione. se no dominio è fornito, quindi tutti i guest configurati
domini si agirà in questo modo.

Sono disponibili le seguenti opzioni aggiuntive:

-C, --config
Specificare un file di configurazione alternativo da cui importare le assegnazioni dei dispositivi.
Se il percorso del file non viene fornito esplicitamente, verrà cercato in
, il /etc/bit-babbler directory (con a .conf suffisso).

-C, --connetti=URI
specificare la vergognoso(1) connessione URI usare. Questo sovrascriverà a DOMINIO_URI set
per il dominio nel file di configurazione. Se non è impostato utilizzando uno di questi
metodi quindi il vergognoso predefinito per l'utente in esecuzione bbvirt verrà utilizzato.

-D, --dominio=Nome
Specificare il dominio libvirt su cui agire. Questo può essere usato per sovrascrivere il dispositivo
allocazione dal file di configurazione quando bbvirt viene invocato manualmente, o per agire
su un dispositivo o dominio che non è attualmente specificato nel file di configurazione.

-B, --busnum=num
Specificare il numero del bus USB a cui è collegato il dispositivo. Questa opzione è per lo più
usato per evitare bbvirt aver bisogno di cercarlo quando è già noto (come quando
si chiama da a udev regola). Di solito non c'è molto motivo per passare questo se
invocando bbvirt manualmente, poiché puoi semplicemente specificare il dispositivo tramite la sua logica o
indirizzo fisico invece.

-D, --devnum=num
Specificare il numero del dispositivo USB a cui è attualmente assegnato il dispositivo. Insieme a
il numero del bus, questo costituisce l'indirizzo logico del dispositivo. Questa opzione è
usato principalmente per evitare bbvirt bisogno di cercarlo quando è già noto (come
come quando viene chiamato da a udev regola). Di solito non c'è molto motivo per passare
questo se invocando bbvirt manualmente, poiché puoi semplicemente specificare il dispositivo tramite il suo
indirizzo logico invece.

-N, --funzionamento a secco
Non collegare o scollegare alcun dispositivo, mostra solo cosa verrebbe tentato se questo fosse un
corsa dal vivo. Questa opzione implica un livello minimo di --verboso, ma la verbosità può
essere ulteriormente incrementato passando anche esplicitamente a tale opzione.

-in, --verboso
Fai più rumore su ciò che sta realmente accadendo. Può essere passato più volte a
aumentare ulteriormente la verbosità.

-?, --Aiuto
Mostra un breve riepilogo delle opzioni disponibili.

CONFIGURAZIONE VERSIONI

I bbvirt il file di configurazione contiene assegnazioni di variabili utilizzando il bash(1) guscio
sintassi. Viene fornito come uno snippet di shell, quindi in linea di principio potresti costruire il
configurazione per ogni dominio in modo dinamico, ma più tipicamente una semplice assegnazione statica
di dispositivi ai domini sarà sufficiente. Se scegli di eseguire il codice in esso, dovresti essere molto
difensivo sullo spazio dei nomi di qualsiasi altra variabile che usi o di qualsiasi altro effetto collaterale che hai
potrebbe far accadere. Al suo interno può essere configurato un numero qualsiasi di domini guest.

Per ogni dominio ospite, due variabili controllano il comportamento di bbvirt:

DOMINIO_URI_dominio=URI
Questa variabile è facoltativa e imposta il vergognoso(1) connessione URI usare quando
attaccare o staccare dispositivi dal dato dominio. Se il --Collegare opzione è
passato esplicitamente a bbvirt sovrascriverà ciò che è impostato qui. Se la connessione
URI non è impostato utilizzando nessuno di questi metodi, allora il vergognoso predefinito per l'utente
running bbvirt verrà utilizzato (che normalmente sarebbe root se eseguito da udev).

DOMINIO_RNG_dominio=( dispositivo serial numeri ... )
Questa variabile è necessaria se il passthrough automatico dei dispositivi a un dominio è
desiderato. È un array bash, popolato con un elenco separato da spazi di tutti i
numeri di serie del dispositivo a cui si desidera assegnare dominio. Non è un errore per
dispositivi da elencare qui che non sono attualmente collegati. È importante
assicurarsi che i dispositivi siano assegnati solo a uno dominio però, e quei dispositivi
assegnati ai domini ospiti non verranno utilizzati da a seminato(1) istanza in esecuzione su
host (che significa il seminato configurazione deve essere passato un elenco esplicito di
anche i dispositivi che potrebbe utilizzare).

Il numero di serie del dispositivo deve essere sempre utilizzato qui. Non è possibile specificare un dispositivo tramite
il suo indirizzo logico o fisico sul bus (come puoi nella maggior parte degli altri posti dove
prendiamo un ID dispositivo).

Usa bbvirt online utilizzando i servizi onworks.net