bbvirt - Online en la nube

PROGRAMA:

NOMBRE

bbvirt - hotplug dispositivos BitBabbler en dominios administrados libvirt

SINOPSIS

bbvirt DE ACTUAR! [opciones]

bbvirt adjuntar|despegar dispositivo [opciones]

bbvirt adjuntar todo|separar todo [dominio] [opciones]

DESCRIPCIÓN

El bbvirt El programa es un intento de aliviar parte del dolor de lo que está actualmente
necesario para distribuir varios dispositivos USB entre el host y las máquinas virtuales invitadas.
Si bien hay varias formas de configurar y administrar esto, en la actualidad ninguna
de ellos realmente proporcionan una solución completa y coherente por sí mismos, todos ellos caen
por debajo de la marca de alguna manera significativa y molesta. El objetivo aquí es reconstruir
suficientes de esos trucos para obtener toda la funcionalidad que queremos ahora, hasta que
El soporte nativo de libvirt para esto mejora lo suficiente como para no necesitarlo más.

En la actualidad, se trata de máquinas virtuales QEMU / KVM administradas por libvirt.

¿ do we ¿querer?
El comportamiento ideal aquí es bastante simple. Dado un número arbitrario de BitBabbler
dispositivos, deberíamos poder asignarlos a la máquina host oa una VM invitada
ejecutándose en él, y una vez que lo hagamos, deberían comportarse de la manera normal que se espera de cualquier
Dispositivo USB.

- Si están enchufados cuando se inicia la máquina invitada, deberían ser vistos por ese
máquina como lo haría el anfitrión.

- Si están enchufados después de que se enciende la máquina, deben conectarse en caliente a ese
máquina como estarían en el host.

- Si se desenchufan mientras la máquina está en funcionamiento, deben retirarse limpiamente de
eso, como estarían en el anfitrión.

¿Por qué no puedes we tienen que?
En este momento, libvirt nos ofrece dos formas de asignar dispositivos USB desde el host a un
dominio invitado.

- Podemos asignarlos por su proveedor de USB e ID de producto. Pero eso solo funciona cuando hay
es solo un dispositivo de ese tipo en el host. Lo cual es bastante inútil en la mayoría de
los casos que nos interesan aquí, donde es probable que el anfitrión y cada uno de los invitados
tener uno o más dispositivos BitBabbler propios asignados.

- Podemos asignarlos por su dirección lógica en el bus USB. Pero eso no es una constante
que podemos configurar estáticamente para el dominio. Cada vez que se conecta un dispositivo, o
desconectado o reiniciado, o la máquina host se reinicia, es probable que esa dirección cambie
ya que se asigna dinámicamente cuando el dispositivo se enumera en el bus.

Hay una tercera forma, pero se basa en omitir la configuración normal de libvirt para hacer
uso directo de la capacidad de QEMU para asignar un dispositivo por su dirección física en el bus.
Cuál es mejor, pero aún no es una fórmula mágica, ya que se basa en conectar exactamente lo mismo
dispositivos en exactamente los mismos puertos cada vez (y al tener esos puertos enumerados en
de la misma manera por parte del host en cada reinicio, lo que tampoco está garantizado). También obliga
nosotros para saltar a través de otros aros, ya que entonces necesitamos una complicación adicional para manejar el
acceder a los permisos del dispositivo manualmente fuera de libvirt, pero aún en coordinación
con ella.

La falla aún mayor, que todos esos métodos tienen en común, es que todos dependen de
el dispositivo ya está enchufado antes de que se inicie el invitado. Si se inserta después
el invitado se inicia, o se quita y se vuelve a conectar mientras el invitado se está ejecutando, o si el host
bus o un hub rebota causando una reconexión, entonces el dispositivo no será (re) conectado al
huésped. La única forma de solucionarlo, si sucede, es volver a conectar manualmente el dispositivo con un
encantamiento arcano en XML (que se basa en que conozca la nueva dirección del dispositivo), o
para apagar completamente y reiniciar el invitado. No es el pináculo de la facilidad de uso
operación que estamos buscando aquí.

¿ podemos we do Sobre Nosotros que?
Hubo un parche enviado a libvirt hace algunos años que habría permitido que un dispositivo
ser especificado tanto por su ID de producto USB como por su número de serie, pero eso recibió algunos empujones
atrás, y hasta ahora todavía no se ha aplicado upstream. Eso habría recorrido un largo camino
para hacer esto fácil y limpio, dejándonos solo con el aspecto de conexión en caliente para lidiar
con. Dejaremos un gruñido gruñón sobre eso como un ejercicio para el lector ...

Otra alternativa es que podemos delegar la búsqueda de la dirección lógica del dispositivo en un hotplug.
gerente como udev(7). Esto es atractivo en el sentido de que podemos saber cuándo la dirección
de un dispositivo cambia y a qué cambia, pero udev en sí mismo no es muy amigable con el
idea de la personalización del administrador local (si bien es posible hacerlo, parece estar obteniendo
cada vez más fuertemente desaconsejado) y su uso todavía requiere un poco de pegamento externo para
traducir sus eventos en algo sobre lo que libvirt pueda actuar para configurar el invitado
maquina

El bbvirt El programa proporciona ese pegamento y un método fácil de usar para asignar qué
los dispositivos deben pertenecer a qué dominios invitados y una interfaz que se pueda invocar manualmente
o por otras tareas controladas por el administrador para agregar o eliminar rápida y fácilmente dispositivos BitBabbler
desde cualquiera de las máquinas invitadas en ejecución.

Pero la limitación que tiene este enfoque es que no puede saber fácilmente cuándo una máquina invitada está
iniciado, que debería tener dispositivos que ya están enchufados agregados. En teoria nosotros
podría agregarlos a su definición de dominio persistente, pero eso tiene sus propios problemas porque
solo podemos agregar dispositivos por su dirección lógica efímera, y no podemos garantizar que
será llamado para eliminarlos del dominio nuevamente cuando esa dirección deje de ser válida
(como si el host se apaga repentinamente o no se apaga limpiamente), por lo que
podría terminar con muchas entradas obsoletas que se acumulan en la configuración del dominio persistente,
que luego podría hacer coincidir algún dispositivo completamente diferente a lo que queríamos adjuntar a
eso. Lo que significa que hasta que se solucione de alguna manera, solo es seguro agregarlos a un invitado en vivo
dominio, de modo que siempre se eliminarán de nuevo cuando se detenga, sin importar cómo
terminó siendo detenido.

Claramente, todavía nos queda mucho camino por recorrer para llegar a nuestro ideal aquí.

¿ if we hit it *dos* martillos?
Parece que solo hay dos formas en que podemos recibir notificaciones de una máquina invitada
iniciado en la actualidad. Uno implica ejecutar otro proceso demonio, lo que haría
poco más que sentarse esperando a que alguien inicie un invitado para que nos diga
sobre eso. Pero luego tendríamos otra cosa que configurar, otro proceso más
corriendo, y aún más problemas para descubrir cómo asegurarnos de no perder una carrera cuando
el host se inicia, entre obtener el conjunto inicial de eventos del dispositivo, ese proceso se
listo y activo, y todos los invitados que se iniciarán automáticamente en el inicio.

La otra forma es usar un gancho libvirt. Lo que a su vez tiene el problema de no
permitiéndonos ejecutar cualquier función libvirt desde él, lo que debemos hacer para adjuntar
el dispositivo al host. Y que no podemos garantizar que podamos instalar de forma predeterminada,
porque solo puede haber un gancho de este tipo en el sistema, que el administrador local ya puede
estar usando ...

Hay una tercera forma, pero eso implicaría requerir que el administrador local inicie todos los
máquinas a través de una envoltura propia, en lugar de a través de cualquier mecanismo que ya conozcan
y use. Que no se escala para admitir otros dispositivos USB en la misma situación, entre
las muchas formas en que sería una horrible solución infligir a la gente.

Pero hay una laguna que podemos aprovechar. Podemos usar el gancho libvirt qemu para activar un
cambio de evento para udev, que a su vez puede invocar bbvirt de la misma manera que lo haría
sucedería si el dispositivo estaba realmente conectado en caliente, lo que nos da una capa adicional de indirección
necesitamos poder hacer eso de forma segura desde el gancho. Rube Goldberg estaría orgulloso y
algunas de las piezas pueden requerir ensamblaje a mano, pero con todo esto en su lugar, podemos tener
algo parecido a la funcionalidad USB normal en las máquinas invitadas.

No es bonito, pero funcionará con lo que tenemos que trabajar.

ok, solo les digas me donde a hit él.
Para unir esto, deberá asegurarse de todo lo siguiente:

El udev(7) Se instalan las reglas del paquete bit-babbler. Si instaló este
de los paquetes Debian que ya deberían estar hechos. Si no lo hizo, necesitará
instalar las reglas que se encuentran en debian / bit-babbler.udev desde el paquete fuente a un
lugar adecuado en su sistema (probablemente /etc/udev/rules.d).

El bbvirt(1) el script está instalado en un lugar donde el udev las reglas lo encontrarán. Si tu
no instaló esto desde los paquetes de Debian, y no está en / usr / bin, entonces necesitarás
para ajustar la udev reglas para adaptarse.

- Los dispositivos que desea usar en las máquinas invitadas y las máquinas en las que desea usarlos,
se especifican en el bbvirt archivo de configuración. La ubicación predeterminada para eso es
/etc/bit-babbler/vm.conf. Si desea utilizar un archivo diferente, deberá pasar su
ubicación con el --config opción en el udev reglas, y actualice el script de gancho use eso
archivo también. Los detalles de lo que puede poner en ese archivo se describen en el
CONFIGURACIÓN CAMPUS sección a continuación.

- El archivo de enlace libvirt está instalado. Si se hace todo lo anterior, los dispositivos se
agregado a las máquinas invitadas en ejecución si se conectan mientras se ejecuta el invitado.
Este último paso asegura que los dispositivos que ya están enchufados se agregarán a los
invitados también (que incluye invitados que se inician automáticamente cuando el anfitrión
botas de la máquina).

Hasta que exista alguna forma segura de que podamos instalar esto sin entrar en conflicto con o sobrescribir
un gancho existente, todos deberán realizar este paso manualmente. Si ha instalado
los paquetes de Debian, entonces el script de gancho de ejemplo que hemos proporcionado para esto puede ser
encontrado en / usr / share / doc / bit-babbler / examples / qemu-hook. Si no lo hiciste, se puede encontrar
in libvirt / qemu-hook del paquete fuente.

Deberá instalar ese archivo como / etc / libvirt / hooks / qemuo fusionar su contenido con
la existencia qemu archivo allí si ya tiene ese gancho. Si ese archivo no
existía previamente, deberá reiniciar biblioteca(8) para que comience a usarlo.

Eso debería cubrir toda la automatización necesaria, pero también puede conectar y desconectar dispositivos
manualmente en cualquier momento también. Los detalles de hacer eso se describirán a continuación.
sección. De lo contrario, con todo lo anterior hecho, no hay otra razón para necesitar invocar
bbvirt .

CAMPUS

Hay dos modos principales de funcionamiento para bbvirt que son seleccionados por la inicial
opción de acción. Si la acción a realizar es adjuntar or despegar entonces solo un dispositivo
se actuará sobre él, y qué dispositivo debe especificarse explícitamente, incluso si
solo hay un dispositivo presente en el host a la vez. Al invocar bbvirt a mano,
las dispositivo puede especificarse por su número de serie, su dirección lógica en el bus (en el
formulario número de bus:número de desarrollo, dado como enteros decimales), o su dirección física en el bus (en el
formulario número de bus-Puerto[.Puerto ...]).

Si la acción a realizar es adjuntar todo or separar todo, entonces los dispositivos sobre los que actuar son
seleccionado por dominio asociación en su lugar. Si un dominio se especifica explícitamente, entonces todo
Los dispositivos que están asignados a ese dominio invitado en el archivo de configuración se actuarán
sobre de la misma manera que si bbvirt fue invocado para cada uno de ellos individualmente con el
adjuntar or despegar acción. Si no dominio se proporciona, entonces todos los invitados configurados
Se actuará sobre los dominios de esta forma.

Están disponibles las siguientes opciones adicionales:

-VS, --config
Especifique un archivo de configuración alternativo desde el que importar las asignaciones de dispositivos.
Si la ruta al archivo no se proporciona explícitamente, se buscará en
las / etc / bit-babbler directorio (con un .conf sufijo).

-C, --connect =URI
Especifica el Virsh(1) conexión URI usar. Esto anulará un DOMINIO_URI set
para el dominio en el archivo de configuración. Si eso no se establece usando cualquiera de estos
métodos entonces el Virsh predeterminado para el usuario que ejecuta bbvirt se utilizará.

-RE, --dominio =nombre
Especifique el dominio libvirt sobre el que actuar. Esto puede usarse para anular el dispositivo
asignación del archivo de configuración cuando bbvirt se invoca manualmente, o para actuar
en un dispositivo o dominio que no está especificado actualmente en el archivo de configuración.

-B, --busnum =número
Especifique el número de bus USB al que está conectado el dispositivo. Esta opción es principalmente
solía evitar bbvirt necesita buscar esto cuando ya se sabe (como cuando
se llama desde un udev regla). Por lo general, no hay muchas razones para aprobar esto si
invocando bbvirt manualmente, ya que puede especificar el dispositivo por su lógica o
dirección física en su lugar.

-D, --devnum =número
Especifique el número de dispositivo USB que el dispositivo está asignado actualmente. Juntos con
el número de bus, esto forma la dirección lógica del dispositivo. Esta opcion es
mayormente utilizado para evitar bbvirt necesidad de buscar esto cuando ya se sabe (como
como cuando se llama desde un udev regla). Por lo general, no hay muchas razones para aprobar
esto si invocando bbvirt manualmente, ya que puede especificar el dispositivo por su
dirección lógica en su lugar.

-norte, - corrida en seco
No conecte ni desconecte ningún dispositivo, solo muestre lo que se intentaría si fuera un
correr en vivo. Esta opción implica un nivel mínimo de --verboso, pero la verbosidad puede
aumentarse aún más pasando también esa opción explícitamente.

-v, --verboso
Haga más ruido sobre lo que realmente está sucediendo. Puede pasarse varias veces a
aumentar aún más la verbosidad.

- ?, --ayuda
Muestra un breve resumen de las opciones disponibles.

CONFIGURACIÓN CAMPUS

El bbvirt El archivo de configuración contiene asignaciones de variables utilizando el golpear(1) caparazón
sintaxis. Se obtiene como un fragmento de shell, por lo que, en principio, podría construir el
configuración para cada dominio de forma dinámica, pero por lo general una simple asignación estática
de dispositivos a dominios será suficiente. Si elige ejecutar código en él, debe ser muy
a la defensiva sobre el espacio de nombres de cualquier otra variable que use, o cualquier otro efecto secundario que
podría causar que suceda. En él se puede configurar cualquier número de dominios invitados.

Para cada dominio invitado, dos variables controlan el comportamiento de bbvirt:

DOMINIO_URI_dominio=URI
Esta variable es opcional y establece el Virsh(1) conexión URI para usar cuando
conectar o desconectar dispositivos de la determinada dominio. Si el --conectar opción es
pasado explícitamente a bbvirt anulará lo que se establezca aquí. Si la conexión
URI no se establece con ninguno de estos métodos, entonces el Virsh predeterminado para el usuario
correr bbvirt se utilizará (que normalmente sería root si se ejecuta desde udev).

DOMINIO_RNG_dominio=( dispositivo de serie números ... )
Esta variable es necesaria si el paso automático de dispositivos a un dominio es
deseado. Es una matriz bash, poblada con una lista separada por espacios de todos los
números de serie del dispositivo que desea asignar dominio. No es un error para
dispositivos que se enumeran aquí y que no están conectados actualmente. Es importante
Asegúrese de que los dispositivos solo estén asignados a uno dominio aunque, y que los dispositivos
asignados a dominios invitados no serán utilizados por un semilla(1) instancia que se ejecuta en el
anfitrión (que significa el semilla la configuración debe pasar una lista explícita de
los dispositivos que puede utilizar también).

El número de serie del dispositivo siempre debe usarse aquí. No puede especificar un dispositivo
su dirección lógica o física en el autobús (como puede hacer en la mayoría de los otros lugares donde
tomamos un ID de dispositivo).

Use bbvirt en línea usando los servicios de onworks.net