bbvirt - En ligne dans le Cloud

PROGRAMME:

Nom

bbvirt - connecte à chaud les appareils BitBabbler aux domaines gérés par libvirt

SYNOPSIS

bbvirt action [Options]

bbvirt joindre|détacher dispositif [Options]

bbvirt attachez-tout|détacher-tout [domaine] [Options]

DESCRIPTION

La bbvirt est une tentative de soulager une partie de la douleur de ce qui est actuellement
requis pour distribuer plusieurs périphériques USB entre les machines virtuelles hôte et invité.
Bien qu'il existe plusieurs manières de configurer et de gérer cela, à l'heure actuelle aucune
d'entre eux fournissent en fait une solution complète et cohérente à eux seuls, tous tombent
court de la marque d'une manière significative et ennuyeuse. Le but ici est de reconstituer
assez de ces hacks pour obtenir toutes les fonctionnalités que nous voulons maintenant, jusqu'à ce que le
Le support natif de libvirt pour cela s'améliore suffisamment pour ne plus en avoir besoin.

À l'heure actuelle, cela concerne les machines virtuelles QEMU/KVM gérées par libvirt.

Quoi do we vouloir?
Le comportement idéal ici est assez simple. Étant donné un nombre arbitraire de BitBabbler
périphériques, nous devrions pouvoir les attribuer soit à la machine hôte, soit à une machine virtuelle invitée
fonctionner dessus, et une fois que nous faisons cela, ils devraient se comporter de la manière normale attendue de tout
Périphérique USB.

- S'ils sont branchés au démarrage de la machine invitée, ils doivent être vus par celui-ci.
machine comme ils le seraient par l'hôte.

- S'ils sont branchés après le démarrage de la machine, ils doivent être branchés à chaud sur ce
machine comme ils le seraient sur l'hôte.

- S'ils sont débranchés pendant le fonctionnement de la machine, ils doivent être retirés proprement du
comme ils le seraient sur l'hôte.

Constat ne peut pas we avons il?
À l'heure actuelle, libvirt nous donne deux façons d'attribuer des périphériques USB de l'hôte à un
domaine invité.

- Nous pouvons les attribuer par leur fournisseur USB et leur ID de produit. Mais cela ne fonctionne que lorsqu'il y a
n'est qu'un seul périphérique de ce type dans l'hôte. Ce qui est assez inutile dans la plupart des
les cas qui nous tiennent à cœur ici, où l'hôte et chacun des invités sont susceptibles de
ont un ou plusieurs appareils BitBabbler qui leur sont attribués.

- On peut les affecter par leur adresse logique sur le bus USB. Mais ce n'est pas une constante
que nous pouvons configurer statiquement pour le domaine. Chaque fois qu'un appareil est branché, ou
rebranché, ou réinitialisé, ou la machine hôte est redémarrée, cette adresse est susceptible de changer
car il est alloué dynamiquement lorsque l'équipement est énuméré sur le bus.

Il existe une troisième voie, mais elle consiste à contourner la configuration normale de libvirt pour faire
utilisation directe de la capacité QEMU d'affecter un équipement par son adresse physique sur le bus.
Ce qui est mieux, mais ce n'est toujours pas une solution miracle puisqu'il s'agit de brancher exactement le même
appareils dans exactement les mêmes ports à chaque fois (et sur avoir ces ports énumérés dans
de la même manière par l'hôte à chaque redémarrage, ce qui n'est pas garanti non plus). Il oblige aussi
nous sauter à travers d'autres cerceaux, car nous avons alors besoin de complications supplémentaires pour gérer le
les autorisations d'accès de l'appareil manuellement en dehors de libvirt, mais toujours en coordination
avec elle.

L'échec encore plus grand, que toutes ces méthodes ont en commun, est qu'elles dépendent toutes de
l'appareil étant déjà branché avant le démarrage de l'invité. S'il est inséré après
l'invité est démarré, ou supprimé et reconnecté pendant que l'invité est en cours d'exécution, ou si l'hôte
bus ou un concentrateur rebondit provoquant une reconnexion, alors l'appareil ne sera pas (re)connecté au
invité. La seule façon de résoudre ce problème est de rattacher manuellement l'appareil avec un
incantation des arcanes en XML (qui repose sur la connaissance de la nouvelle adresse de l'appareil), ou
pour éteindre complètement et redémarrer l'invité. Pas le summum de la convivialité
opération que nous recherchons ici.

Quoi vous we do à propos il?
Il y a quelques années, il y a eu un correctif soumis à libvirt qui aurait permis à un appareil
être spécifié à la fois par son ID de produit USB et son numéro de série, mais cela a eu un certain push-
en arrière, et n'a toujours pas été appliqué en amont à ce jour. ça aurait fait du chemin
pour rendre cela à la fois facile et propre, ne nous laissant que l'aspect hotplug à traiter
avec. Nous laisserons un snark grincheux à ce sujet comme exercice pour le lecteur …

Une autre alternative est que nous pouvons déléguer la recherche de l'adresse logique de l'appareil à un hotplug
gestionnaire comme udev(7). Ceci est attrayant dans le sens où l'on peut savoir quand l'adresse
d'un appareil change et ce qu'il change, mais udev lui-même n'est pas très amical avec le
idée de personnalisation de l'administrateur local (bien qu'il soit possible de le faire, cela semble devenir
de plus en plus fortement déconseillée) et son utilisation nécessite encore de la colle externe pour
traduire ses événements en quelque chose sur lequel libvirt peut agir pour configurer l'invité
machine.

La bbvirt programme fournit cette colle, et une méthode conviviale d'assignation qui
les appareils doivent appartenir à quels domaines invités et un frontal qui peut être appelé manuellement
ou par d'autres tâches contrôlées par l'administrateur pour ajouter ou supprimer rapidement et facilement des appareils BitBabbler
à partir de l'une des machines invitées en cours d'exécution.

Mais la limitation de cette approche est qu'elle ne peut pas facilement savoir quand une machine invitée est
démarré qui devrait avoir des périphériques déjà branchés ajoutés. En théorie, nous
pourrait les ajouter à sa définition de domaine persistant, mais cela a ses propres problèmes car
nous ne pouvons ajouter des appareils que par leur adresse logique éphémère, et nous ne pouvons garantir que nous
sera appelé pour les supprimer à nouveau du domaine lorsque cette adresse deviendra invalide
(comme si l'hôte est soudainement éteint ou s'il n'est pas éteint proprement), nous
pourrait se retrouver avec de nombreuses entrées obsolètes s'accumulant dans la configuration du domaine persistant,
qui pourrait plus tard correspondre à un appareil complètement différent de ce que nous voulions attacher à
ce. Ce qui signifie que jusqu'à ce que cela soit résolu, il n'est prudent de les ajouter qu'à un invité en direct.
domaine, de sorte qu'ils seront toujours supprimés à nouveau lorsqu'il est arrêté, peu importe comment il
a fini par s'arrêter.

Il est clair que nous avons encore du chemin à parcourir pour atteindre notre idéal ici.

Quoi if we frapper it avec *deux* marteaux ?
Il semble qu'il n'y ait que deux façons pour nous d'être avertis d'une machine invitée
commencé à l'heure actuelle. L'une implique l'exécution d'un autre processus démon, ce qui ferait
un peu plus que de simplement s'asseoir en attendant que quelqu'un commence un invité pour qu'il puisse nous dire
à propos de ça. Mais alors nous aurions encore une autre chose à configurer, encore un autre processus
courir, et encore plus de problèmes pour trouver comment nous assurer de ne pas perdre une course quand
l'hôte est démarré, entre l'obtention de l'ensemble initial d'événements de périphérique, ce processus étant
prêt et actif, et tous les invités qui seront démarrés automatiquement au démarrage en cours de démarrage.

L'autre méthode consiste à utiliser un hook libvirt. Ce qui à son tour a le problème de ne pas réellement
nous permettant d'exécuter n'importe quelle fonction libvirt à partir de celui-ci, ce que nous devons faire pour attacher
l'appareil à l'hôte. Et que nous ne pouvons garantir que nous pouvons simplement installer par défaut,
car il ne peut y avoir qu'un seul crochet de ce type sur le système, que l'administrateur local peut déjà
utiliser...

Il existe une troisième voie, mais cela impliquerait d'exiger de l'administrateur local qu'il démarre tous les invités
machines à travers un emballage qui nous est propre, au lieu de via n'importe quel mécanisme qu'ils connaissent déjà
et utilise. Qui ne s'adapte pas pour prendre en charge d'autres périphériques USB dans la même situation, parmi
les nombreuses façons qui seraient une solution horrible à infliger aux gens.

Mais il y a une faille que nous pouvons exploiter. Nous pouvons utiliser le hook libvirt qemu pour déclencher un
changer l'événement pour udev, qui peut à son tour invoquer bbvirt de la même manière que le ferait
se produire si l'appareil était vraiment branché à chaud, ce qui nous donne la couche supplémentaire d'indirection
nous devons être en mesure de le faire en toute sécurité à partir du crochet. Rube Goldberg serait fier, et
certaines pièces peuvent nécessiter un assemblage à la main, mais avec tout cela en place, nous pouvons avoir
quelque chose qui ressemble à une fonctionnalité USB normale dans les machines invitées.

Ce n'est pas joli, mais cela fonctionnera avec ce avec quoi nous devons travailler.

D'accord, juste dire me De à frapper le
Pour enchaîner ces éléments, vous devez vous assurer de tous les éléments suivants :

- Le udev(7) les règles du paquet bit-babbler sont installées. Si vous avez installé ce
des paquets Debian qui devraient déjà être faits. Si vous ne l'avez pas fait, vous devrez
installer les règles qui se trouvent dans debian/bit-babbler.udev du paquet source à un
endroit approprié sur votre système (probablement /etc/udev/rules.d).

- Le bbvirt(1) le script est installé à un endroit où le udev les règles le trouveront. Si tu
ne l'a pas installé à partir des paquets Debian, et ce n'est pas dans / usr / bin, alors vous aurez besoin
pour peaufiner le udev des règles adaptées.

- Les appareils que vous souhaitez utiliser dans les machines invitées, et les machines sur lesquelles vous souhaitez les utiliser,
sont spécifiés dans le bbvirt fichier de configuration. L'emplacement par défaut pour cela est
/etc/bit-babbler/vm.conf. Si vous souhaitez utiliser un fichier différent, vous devrez passer son
emplacement avec le --config option dans la udev règles et mettre à jour le script hook
fichier aussi. Les détails de ce que vous pouvez mettre dans ce fichier sont décrits dans le
CONFIGURATION OPTIONS section ci-dessous.

- Le fichier hook libvirt est installé. Si tout ce qui précède est fait, alors les appareils seront
ajoutés aux machines invitées en cours d'exécution s'ils sont branchés pendant l'exécution de l'invité.
Cette dernière étape garantit que les appareils déjà branchés seront ajoutés aux nouveaux
invités démarrés également (ce qui inclut les invités qui sont démarrés automatiquement lorsque l'hôte
démarrages de la machine).

Jusqu'à ce qu'il existe un moyen sûr, nous pouvons l'installer sans entrer en conflit ni écraser
un hook existant, tout le monde devra faire cette étape manuellement. Si vous avez installé
les paquets Debian, alors l'exemple de script hook que nous avons fourni pour cela peut être
trouvé dans /usr/share/doc/bit-babbler/examples/qemu-hook. Si vous ne l'avez pas fait, il peut être trouvé
in libvirt/qemu-hook du paquet source.

Vous devrez installer ce fichier en tant que /etc/libvirt/hooks/qemu, ou fusionner son contenu avec
l'existant qemu fichier là-bas si vous avez déjà ce crochet. Si ce fichier n'a pas
existent déjà, vous devrez redémarrer libvirtd(8) pour commencer à l'utiliser.

Cela devrait couvrir toute l'automatisation nécessaire, mais vous pouvez également attacher et détacher des périphériques
manuellement à tout moment aussi. Les détails pour faire cela seront décrits dans ce qui suit
section. Sinon, avec tout ce qui précède fait, il n'y a aucune autre raison d'avoir besoin d'invoquer
bbvirt directement.

OPTIONS

Il existe deux principaux modes de fonctionnement pour bbvirt qui sont sélectionnés par le premier
possibilité d'action. Si l'action à effectuer est joindre or détacher alors un seul appareil
sera actionné, et quel appareil qui devrait être doit être spécifié explicitement, même si
il n'y a qu'un seul périphérique présent sur l'hôte à la fois. Lors de l'invocation bbvirt manuellement,
le dispositif peut être spécifié par son numéro de série, son adresse logique sur le bus (dans le
formulaire numéro de bus:numéro dev, donnée sous forme d'entiers décimaux), ou son adresse physique sur le bus (dans le
formulaire numéro de bus-port[.Port ...]).

Si l'action à effectuer est attachez-tout or détacher-tout, alors le ou les appareils sur lesquels agir sont
choisi par domaine association à la place. Si un domaine est explicitement spécifié, alors tout
les appareils qui sont affectés à ce domaine invité dans le fichier de configuration seront traités
sur de la même manière que si bbvirt a été invoqué pour chacun d'eux individuellement avec le
joindre or détacher action. Sinon domaine est fourni, alors tous les invités configurés
domaines seront traités de cette manière.

Les options supplémentaires suivantes sont disponibles :

-Ç, --config
Spécifiez un autre fichier de configuration à partir duquel importer les affectations de périphériques.
Si le chemin d'accès au fichier n'est pas fourni explicitement, il sera alors recherché dans
le /etc/bit-babbler répertoire (avec un .conf suffixe).

-c, --connect=URI
Spécifie le Virsh(1) connexion URI utiliser. Cela remplacera un DOMAINE_URI set
pour le domaine dans le fichier de configuration. Si cela n'est pas défini à l'aide de l'un de ces
méthodes puis le Virsh par défaut pour l'utilisateur en cours d'exécution bbvirt sera utilisé.

-RÉ, --domaine=prénom
Spécifiez le domaine libvirt sur lequel agir. Cela peut être utilisé pour remplacer l'appareil
allocation à partir du fichier de configuration lorsque bbvirt est invoqué manuellement, ou pour agir
sur un périphérique ou un domaine qui n'est pas actuellement spécifié dans le fichier de configuration.

-b, --numbus=num
Spécifiez le numéro de bus USB auquel le périphérique est connecté. Cette option est principalement
utilisé pour éviter bbvirt besoin de rechercher cela lorsqu'il est déjà connu (comme lorsque
il est appelé d'un udev régner). Il n'y a généralement pas beaucoup de raisons de l'adopter si
invoquer bbvirt manuellement, puisque vous pouvez simplement spécifier le périphérique par sa logique ou
adresse physique à la place.

-ré, --numéro=num
Spécifiez le numéro de périphérique USB auquel le périphérique est actuellement attribué. Ensemble avec
le numéro de bus, il constitue l'adresse logique de l'appareil. Cette option est
surtout utilisé pour éviter bbvirt besoin de rechercher cela lorsqu'il est déjà connu (comme
comme lorsqu'il est appelé d'un udev régner). Il n'y a généralement pas beaucoup de raisons de passer
ceci si vous invoquez bbvirt manuellement, puisque vous pouvez simplement spécifier le périphérique par son
adresse logique à la place.

-n, - à sec
N'attachez ou ne détachez aucun appareil, montrez simplement ce qui serait tenté s'il s'agissait d'un
course en direct. Cette option implique un niveau minimal de --verbeux, mais la verbosité peut
être encore augmentée en passant également cette option explicitement.

-dans, --verbeux
Faites plus de bruit sur ce qui se passe réellement. Il peut être transmis plusieurs fois à
augmenter encore la verbosité.

- ?, --Aidez-moi
Affiche un bref résumé des options disponibles.

CONFIGURATION OPTIONS

La bbvirt fichier de configuration contient des affectations de variables utilisant le bash(1) coquille
syntaxe. Il provient d'un extrait de shell, vous pouvez donc en principe construire le
configuration dynamique pour chaque domaine, mais le plus souvent une simple affectation statique
de périphériques aux domaines suffira. Si vous choisissez d'y exécuter du code, vous devriez être très
défensif au sujet de l'espacement des noms de toute autre variable que vous utilisez ou de tout autre effet secondaire que vous
pourrait provoquer. N'importe quel nombre de domaines invités peut y être configuré.

Pour chaque domaine invité, deux variables contrôlent le comportement de bbvirt:

DOMAINE_URI_domaine=URI
Cette variable est facultative et définit le Virsh(1) connexion URI à utiliser quand
attacher ou détacher des dispositifs du domaine. Si l' --relier option est
explicitement transmis à bbvirt il remplacera ce qui est défini ici. Si la connexion
URI n'est défini à l'aide de l'une ou l'autre de ces méthodes, le Virsh par défaut pour l'utilisateur
pour le running bbvirt sera utilisé (qui serait normalement root s'il est exécuté depuis udev).

DOMAINE_RNG_domaine=( dispositif en série numéros )
Cette variable est requise si le transfert automatique des appareils vers un domaine est
voulu. C'est un tableau bash, rempli d'une liste séparée par des espaces de tous les
les numéros de série de l'appareil auxquels vous souhaitez attribuer domaine. Ce n'est pas une erreur pour
appareils à lister ici qui ne sont pas actuellement branchés. Il est important de
s'assurer que les appareils ne sont affectés qu'à un seul domaine cependant, et que les appareils
attribués aux domaines invités ne seront pas utilisés par un ensemencé(1) instance s'exécutant sur le
hôte (ce qui signifie que le ensemencé configuration doit être passée une liste explicite de
les appareils qu'il peut utiliser aussi).

Le numéro de série de l'appareil doit toujours être utilisé ici. Vous ne pouvez pas spécifier un appareil en
son adresse logique ou physique sur le bus (comme vous pouvez le faire dans la plupart des autres endroits où
nous prenons un identifiant d'appareil).

Utilisez bbvirt en ligne en utilisant les services onworks.net