bbvirt - En ligne dans le Cloud

PROGRAMME:

Nom

bbvirt - intégration à chaud des périphériques BitBabbler dans les domaines gérés par libvirt

SYNOPSIS

bbvirt action [Options]

bbvirt joindre|détacher dispositif [Options]

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

DESCRIPTION

Le bbvirt Le programme est une tentative d'atténuer une partie de la douleur causée par la situation actuelle.
nécessaire pour distribuer plusieurs périphériques USB entre les machines virtuelles hôte et invitée.
Bien qu'il existe plusieurs façons de configurer et de gérer cela, à l'heure actuelle, aucune
d'entre eux fournissent effectivement une solution complète et cohérente par eux-mêmes, tous tombent
en deçà de la réalité, de manière significative et agaçante. L'objectif ici est de reconstituer
suffisamment de ces hacks pour obtenir réellement 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.

Organisateur Ce que 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
en cours d'exécution, et une fois que nous l'aurons fait, 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 devraient être vus par celle-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 celle-ci
machine comme ils le seraient sur l'hôte.

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

Pourquoi Choisir ne peut pas we avons il?
À l'heure actuelle, libvirt nous offre 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 identifiant produit. Mais cela ne fonctionne que s'il y a
Il n'y a qu'un seul périphérique de ce type dans l'hôte. Ce qui est plutôt inutile dans la plupart des cas.
les cas qui nous intéressent ici, où l'hôte et chacun des invités sont susceptibles de
avoir un ou plusieurs appareils BitBabbler qui leur sont propres et qui leur sont attribués.

- On peut les assigner 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é,
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 le périphérique est énuméré sur le bus.

Il existe une troisième méthode, mais elle consiste à contourner la configuration normale de libvirt pour
utilisation directe de la capacité de QEMU à attribuer un périphérique par son adresse physique sur le bus.
Ce qui est mieux, mais ce n'est toujours pas une solution miracle car cela repose sur le branchement exactement de la même manière
périphériques dans exactement les mêmes ports à chaque fois (et en ayant 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). Cela force également
nous obliger à franchir d'autres obstacles, car nous avons alors besoin de complications supplémentaires pour gérer le
accéder aux autorisations de l'appareil manuellement en dehors de libvirt, mais toujours en coordination
avec elle.

Le défaut 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 rebranché pendant que l'invité est en cours d'exécution, ou si l'hôte
bus ou un hub rebondit provoquant une reconnexion, alors l'appareil ne sera pas (re)connecté au
invité. La seule façon de résoudre ce problème si cela se produit est de rattacher manuellement l'appareil avec un
incantation arcanique en XML (qui repose sur la connaissance de la nouvelle adresse de l'appareil), ou
pour éteindre et redémarrer complètement l'invité. Ce n'est pas le summum de la convivialité.
opération que nous recherchons ici.

Organisateur Ce que Vous pouvez we do à propos il?
Il y a quelques années, un correctif a été soumis à libvirt qui aurait permis à un appareil
être spécifié à la fois par son identifiant de produit USB et son numéro de série, mais cela a été poussé
et n'a toujours pas été appliquée en amont. Cela aurait été très utile.
pour rendre cela à la fois simple et propre, ne nous laissant que l'aspect hotplug à gérer
avec. Nous laisserons au lecteur le soin de s'exprimer avec un air grincheux à ce sujet...

Une autre alternative est de déléguer la recherche de l'adresse logique du périphérique à un hotplug
gestionnaire comme udev(7). Ceci est intéressant dans le sens où nous pouvons savoir quand l'adresse
d'un appareil change et ce qu'il change, mais udev elle-même n'est pas très amicale envers les
idée de personnalisation de l'administration locale (bien que cela soit possible, cela semble devenir
de plus en plus fortement déconseillé) 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.

Le bbvirt Le programme fournit cette colle et une méthode conviviale pour attribuer laquelle
les appareils doivent appartenir à quels domaines invités et un frontal qui peut être invoqué manuellement
ou par d'autres tâches contrôlées par l'administrateur pour ajouter ou supprimer rapidement et facilement des périphériques BitBabbler
à partir de n'importe quelle machine invitée 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 en cours d'exécution.
démarré, auquel devraient être ajoutés les appareils déjà branché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 périphériques que par leur adresse logique éphémère, et nous ne pouvons pas garantir que nous
seront appelés 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 arrêté proprement), donc nous
pourrait aboutir à 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 celui que nous souhaitions y attacher
Cela signifie que tant que ce problème n'est pas résolu, il est prudent de les ajouter à un invité en direct.
domaine, de sorte qu'ils seront toujours supprimés à nouveau lorsqu'il est arrêté, quelle que soit la manière dont il
a fini par être arrêté.

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

Organisateur Ce que if we frapper it avec *deux* marteaux ?
Il semble qu'il n'y ait que deux façons d'être averti qu'une machine invitée est en cours de restauration.
commencé à l'heure actuelle. L'une consiste à exécuter un autre processus démon, ce qui
un peu plus que simplement rester assis à attendre que quelqu'un lance un invité pour qu'il puisse nous le dire
À ce sujet. Mais il nous faudrait alors encore une chose à configurer, encore un autre processus.
courir, et encore plus de problèmes pour savoir comment s'assurer de ne pas perdre une course lorsque
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 démarreront réellement.

L'autre méthode consiste à utiliser un hook libvirt. Ce qui présente le problème de ne pas réellement
nous permettant d'exécuter toutes les fonctions libvirt à partir de celui-ci, ce que nous devons faire pour attacher
l'appareil à l'hôte. Et nous ne pouvons pas garantir que nous pourrons l'installer par défaut.
car il ne peut y avoir qu'un seul hook de ce type sur le système, que l'administrateur local peut déjà posséder
utiliser ...

Il existe une troisième voie, mais cela impliquerait de demander à l'administrateur local de démarrer tous les invités.
machines via un wrapper qui nous est propre, au lieu de passer par un mécanisme qu'ils connaissent déjà
et son utilisation. Ce qui ne permet pas de prendre en charge d'autres périphériques USB dans la même situation, notamment
les nombreuses manières dont cela constituerait une solution horrible à infliger aux gens.

Mais il existe une faille que nous pouvons exploiter. Nous pouvons utiliser le hook libvirt qemu pour déclencher une
changer l'événement pour udev, qui peut à son tour invoquer bbvirt de la même manière que cela
se produire si l'appareil a été réellement branché à chaud, ce qui nous donne la couche supplémentaire d'indirection
Nous devons pouvoir le faire en toute sécurité, même en étant à l'abri. Rube Goldberg serait fier, et
certaines pièces peuvent nécessiter un assemblage manuel, mais avec tout cela en place, nous pouvons avoir
quelque chose ressemblant à 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 où à frapper le
Pour mettre tout cela en place, vous devrez 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 paquet,
des paquets Debian, ce qui aurait dû être fait. Si ce n'est pas le cas, vous devrez
installer les règles qui se trouvent dans debian/bit-babbler.udev du paquet source vers 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 vous
je n'ai pas installé cela à partir des paquets Debian, et ce n'est pas dans / usr / bin, alors vous aurez besoin
pour peaufiner le udev règles adaptées.

- Les périphériques que vous souhaitez utiliser sur 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 est
/etc/bit-babbler/vm.conf. Si vous souhaitez utiliser un fichier différent, vous devrez transmettre son
emplacement avec le --config option dans la udev règles et mettre à jour le script hook utilisé
fichier également. 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 est fait, les périphériques seront
ajouté aux machines invitées en cours d'exécution si elles sont branchées pendant que l'invité est en cours d'exécution.
Cette dernière étape garantit que les appareils déjà branchés seront ajoutés aux nouveaux
les invités démarrés également (ce qui inclut les invités qui sont démarrés automatiquement lorsque l'hôte
démarrage de la machine).

Jusqu'à ce qu'il existe un moyen sûr d'installer ceci sans entrer en conflit ou écraser
un hook existant, chacun devra effectuer 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/exemples/qemu-hook. Si vous ne l'avez pas fait, vous pouvez le retrouver
in libvirt/qemu-hook du paquet source.

Vous devrez installer ce fichier comme /etc/libvirt/hooks/qemu, ou fusionner son contenu avec
l'existant qemu si vous avez déjà configuré ce hook. Si ce fichier ne l'a pas déjà configuré,
existaient auparavant, 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 appareils
Vous pouvez également le faire manuellement à tout moment. Les détails de cette opération seront décrits ci-après.
section. Autrement, avec tout ce qui précède fait, il n'y a aucune autre raison de devoir invoquer
bbvirt .

OPTIONS

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

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

Les options supplémentaires suivantes sont disponibles :

-Ç, --config
Spécifiez un fichier de configuration alternatif à partir duquel importer les affectations de périphériques.
Si le chemin d'accès au fichier n'est pas fourni explicitement, il sera 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 ce paramètre n'est pas défini à l'aide de l'une de ces options,
méthodes puis le Virsh par défaut pour l'utilisateur exécutant bbvirt sera utilisé.

-RÉ, --domaine=nom
Spécifiez le domaine libvirt sur lequel agir. Ceci peut être utilisé pour remplacer le périphérique.
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, --busnum=num
Spécifiez le numéro du bus USB auquel le périphérique est connecté. Cette option est généralement utilisée.
utilisé pour éviter bbvirt avoir besoin de rechercher cela alors que c'est déjà connu (par exemple lorsque
on l'appelle d'après un udev règle). Il n'y a généralement pas beaucoup de raisons de passer cette étape si
invoquer bbvirt manuellement, car vous pouvez simplement spécifier le périphérique par son nom logique ou
adresse physique à la place.

-ré, --devnum=num
Spécifiez le numéro de périphérique USB actuellement attribué au périphérique. Avec
le numéro de bus, qui constitue l'adresse logique du périphérique. Cette option est
principalement utilisé pour éviter bbvirt avoir besoin de chercher cela alors que c'est déjà connu (comme
comme lorsqu'il est appelé depuis un udev règle). Il n'y a généralement pas beaucoup de raisons de passer
ceci si invoquant bbvirt manuellement, car vous pouvez simplement spécifier l'appareil par son
adresse logique à la place.

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

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

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

CONFIGURATION OPTIONS

Le bbvirt Le fichier de configuration contient des affectations de variables à l'aide de bash(1) coquille
syntaxe. Il s'agit d'un extrait de code shell, vous pouvez donc en principe construire le
configuration pour chaque domaine de manière dynamique, mais le plus souvent une simple affectation statique
des appareils aux domaines suffira. Si vous choisissez d'y exécuter du code, soyez très prudent.
sur la défensive concernant l'espace de noms de toutes les autres variables que vous utilisez, ou de tout autre effet secondaire que vous
Cela pourrait se produire. Il est possible de configurer un nombre illimité de domaines invités.

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

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

DOMAINE_RNG_domaine=( dispositif en série numéros ... )
Cette variable est requise si le transfert automatique des périphériques vers un domaine est
souhaité. Il s'agit d'un tableau bash, rempli d'une liste séparée par des espaces de tous les
numéros de série des appareils que vous souhaitez attribuer domaineCe 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 attribué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 exécutée sur le
hôte (ce qui signifie le ensemencé la configuration doit recevoir une liste explicite de
les appareils qu'il peut également utiliser).

Le numéro de série de l'appareil doit toujours être utilisé ici. Vous ne pouvez pas spécifier un appareil par
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 avec les services onworks.net