bbvirt - Online na nuvem

PROGRAMA:

NOME

bbvirt - hotplug dispositivos BitBabbler em domínios gerenciados libvirt

SINOPSE

bbvirt açao [opções]

bbvirt anexar|desanexar dispositivo [opções]

bbvirt anexar tudo|separar tudo [domínio] [opções]

DESCRIÇÃO

A bbvirt programa é uma tentativa de tirar um pouco da dor do que é atualmente
necessário para distribuir vários dispositivos USB entre as máquinas virtuais host e convidadas.
Embora existam várias maneiras pelas quais isso pode ser configurado e gerenciado, no momento nenhum
deles realmente fornecem uma solução completa e coerente por conta própria, todos eles caem
aquém do alvo de alguma forma significativa e irritante. O objetivo aqui é juntar as peças
o suficiente desses hacks para realmente obter todas as funcionalidades que queremos agora, até que o
O suporte nativo libvirt para isso melhora o suficiente para não precisar mais dele.

No momento, trata-se de máquinas virtuais QEMU / KVM gerenciadas por libvirt.

O Quê do we quer?
O comportamento ideal aqui é muito simples. Dado algum número arbitrário de BitBabbler
dispositivos, devemos ser capazes de atribuí-los à máquina host ou a uma VM
executando nele, e uma vez que fizermos isso, eles devem se comportar da maneira normal esperada de qualquer
Dispositivo USB.

- Se eles estiverem conectados quando a máquina do convidado for iniciada, eles devem ser vistos por aquele
máquina como seriam pelo host.

- Se eles forem conectados depois que a máquina for ligada, eles devem ser conectados a quente nessa
máquina como estariam no host.

- Se eles forem desconectados enquanto a máquina estiver funcionando, eles devem ser removidos de forma limpa
isso, como estariam no host.

Sua marca não pode we isso?
No momento, a libvirt nos oferece duas maneiras de atribuir dispositivos USB do host a um
domínio de convidado.

- Podemos atribuí-los por seu fornecedor USB e ID do produto. Mas isso só funciona quando há
é apenas um único dispositivo desse tipo no host. O que é bastante inútil na maioria das
os casos que nos interessam aqui, onde o anfitrião e cada um dos convidados são susceptíveis de
têm um ou mais dispositivos BitBabbler próprios atribuídos a eles.

- Podemos atribuí-los por seu endereço lógico no barramento USB. Mas isso não é uma constante
que podemos configurar estaticamente para o domínio. Cada vez que um dispositivo é conectado, ou
reconfigurado ou redefinido, ou a máquina host é reinicializada, esse endereço provavelmente mudará
uma vez que é alocado dinamicamente quando o dispositivo é enumerado no barramento.

Existe uma terceira maneira, mas ela depende de contornar a configuração normal da libvirt para fazer
uso direto da capacidade do QEMU de atribuir um dispositivo por seu endereço físico no barramento.
O que é melhor, mas ainda não é uma fórmula mágica, pois depende da conexão exatamente da mesma
dispositivos exatamente nas mesmas portas todas as vezes (e em ter essas portas enumeradas em
da mesma forma pelo host em cada reinicialização, o que também não é garantido). Também força
temos de saltar por outros obstáculos, uma vez que precisamos de complicações adicionais para gerenciar o
permissões de acesso do dispositivo manualmente fora da libvirt, mas ainda em coordenação
com isto.

A falha ainda maior, que todos esses métodos têm em comum, é que todos dependem de
o dispositivo já está sendo conectado antes de o convidado ser iniciado. Se for inserido após
o convidado é iniciado, ou removido e conectado novamente enquanto o convidado está em execução, ou se o host
barramento ou um hub salta causando uma reconexão, então o dispositivo não será (re) anexado ao
hóspede. A única maneira de consertar isso, se isso acontecer, é reanexar manualmente o dispositivo com um
encantamento arcano em XML (que depende de você saber o novo endereço do dispositivo), ou
para desligar completamente e reiniciar o convidado. Não é o auge da facilidade de uso
operação que procuramos aqui.

O Quê pode we do sobre isso?
Houve um patch enviado para libvirt alguns anos atrás, que teria permitido um dispositivo
a ser especificado por seu ID de produto USB e seu número de série, mas isso teve algum push-
de volta, e até agora ainda não foi aplicado a montante. Isso teria percorrido um longo caminho
para tornar isso fácil e limpo, deixando-nos apenas com o aspecto do hotplug para lidar
com. Vamos deixar comentários mal-humorados sobre isso como um exercício para o leitor ...

Outra alternativa é delegar a localização do endereço lógico do dispositivo a um hotplug
gerente gosta udev(7). Isso é atraente no sentido de que podemos saber quando o endereço
de um dispositivo muda e para o que ele muda, mas udev em si não é muito amigável com o
ideia de personalização do administrador local (embora seja possível fazer, parece estar
cada vez mais fortemente desencorajado) e usá-lo ainda requer alguma cola externa para
traduzir seus eventos em algo em que a libvirt possa atuar para configurar o convidado
máquina.

A bbvirt programa fornece essa cola, e um método amigável para atribuir quais
os dispositivos devem pertencer a quais domínios de convidado e um front end que pode ser invocado manualmente
ou por outras tarefas controladas pelo administrador para adicionar ou remover dispositivos BitBabbler de forma rápida e fácil
de qualquer uma das máquinas convidadas em execução.

Mas a limitação dessa abordagem é que ela não pode saber facilmente quando uma máquina convidada está
iniciado, que deve ter dispositivos que já estão conectados adicionados a ele. Em teoria nós
poderia adicioná-los à sua definição de domínio persistente, mas isso tem seus próprios problemas porque
só podemos adicionar dispositivos por seus endereços lógicos efêmeros, e não podemos garantir que
será chamado para removê-los do domínio novamente quando o endereço se tornar inválido
(como se o host fosse desligado repentinamente ou de outra forma não fosse desligado corretamente), então nós
pode acabar com muitas entradas obsoletas se acumulando na configuração de domínio persistente,
que poderia mais tarde combinar algum dispositivo completamente diferente ao que queríamos anexado
isto. O que significa que até que de alguma forma seja corrigido, só é seguro adicioná-los a um convidado ao vivo
domínio, para que sempre sejam removidos novamente quando for interrompido, não importa como
acabou sendo interrompido.

É claro que ainda temos um caminho a percorrer para chegar ao nosso ideal aqui.

O Quê if we acertar it com *dois* martelos?
Parece haver apenas duas maneiras de sermos notificados de uma máquina convidada sendo
começou no presente. Um envolve a execução de outro processo daemon, o que faria
pouco mais do que ficar sentado esperando que alguém comece um convidado para que ele possa nos dizer
sobre isso. Mas então teríamos mais uma coisa para configurar, mais um processo
correndo, e ainda mais problemas em descobrir como garantir que não perdemos uma corrida quando
o host é inicializado, entre a obtenção do conjunto inicial de eventos do dispositivo, sendo esse processo
pronto e ativo, e todos os convidados que serão inicializados automaticamente na inicialização, realmente iniciando.

A outra maneira é usar um gancho libvirt. Que por sua vez tem o problema de não realmente
permitindo-nos executar quaisquer funções libvirt a partir dele, o que precisamos fazer a fim de anexar
o dispositivo para o host. E não podemos garantir que podemos apenas instalar por padrão,
porque só pode haver um gancho no sistema, que o administrador local já pode
estar usando ...

Existe uma terceira maneira, mas isso envolveria exigir que o administrador local inicie todos os convidados
máquinas por meio de um invólucro próprio, em vez de por meio de qualquer mecanismo que eles já conheçam
E use. Que não pode ser escalado para suportar outros dispositivos USB na mesma situação, entre
as muitas maneiras que seriam uma solução horrível de infligir às pessoas.

Mas existe uma lacuna que podemos explorar. Podemos usar o gancho libvirt qemu para acionar um
mudar evento para udev, que por sua vez pode invocar bbvirt da mesma forma que seria
acontecer se o dispositivo tiver realmente hotplug, o que nos dá uma camada extra de indireção
precisamos ser capazes de fazer isso com segurança no gancho. Rube Goldberg ficaria orgulhoso, e
algumas das peças podem exigir montagem à mão, mas com tudo isso no lugar, podemos ter
algo semelhante à funcionalidade USB normal nas máquinas convidadas.

Não é bonito, mas vai funcionar com o que tivermos de trabalhar.

ok, apenas por dizer me onde para acertar .
Para encadear isso, você precisará garantir todos os seguintes itens:

- O udev(7) as regras do pacote bit-babbler são instaladas. Se você instalou este
dos pacotes Debian que já deveriam estar prontos. Se você não fez isso, você precisará
instale as regras que são encontradas em debian / bit-babbler.udev do pacote fonte para um
lugar adequado em seu sistema (provavelmente /etc/udev/rules.d).

- O bbvirt(1) o script é instalado em um local onde o udev as regras o encontrarão. Se você
não instalei isso dos pacotes Debian, e não está em / usr / bin, então você precisará
ajustar o udev regras para se adequar.

- Os dispositivos que você deseja usar nas máquinas convidadas e as máquinas nas quais deseja usá-los,
são especificados no bbvirt arquivo de configuração. O local padrão para isso é
/etc/bit-babbler/vm.conf. Se você deseja usar um arquivo diferente, você precisará passar seu
localização com o --config opção no udev regras e atualizar o script de gancho para usar esse
arquivo também. Os detalhes do que você pode colocar nesse arquivo são descritos no
CONFIGURAÇÃO OPÇÕES seção abaixo.

- O arquivo de gancho libvirt está instalado. Se tudo acima for feito, os dispositivos serão
adicionado às máquinas convidadas em execução se elas forem conectadas enquanto o convidado está em execução.
Esta última etapa garante que os dispositivos que já estão conectados serão adicionados ao novo
convidados iniciados também (o que inclui convidados que são iniciados automaticamente quando o host
inicialização da máquina).

Até que haja uma maneira segura de podermos instalar isso sem entrar em conflito com ou sobrescrever
um gancho existente, todos precisarão fazer essa etapa manualmente. Se você instalou
os pacotes Debian, então o script de gancho de exemplo que fornecemos para isso pode ser
encontrado em / usr / share / doc / bit-babbler / examples / qemu-hook. Se não, pode ser encontrado
in libvirt / qemu-hook do pacote fonte.

Você precisará instalar esse arquivo como / etc / libvirt / hooks / qemu, ou mesclar seu conteúdo com
o existente qemu arquivo lá se você já tiver esse gancho definido. Se esse arquivo não
existiam anteriormente, você precisará reiniciar libvirtd(8) para começar a usá-lo.

Isso deve cobrir toda a automação necessária, mas você também pode conectar e desconectar dispositivos
manualmente a qualquer momento também. Os detalhes de como fazer isso serão descritos a seguir
seção. Caso contrário, com tudo o que foi dito acima, não há outra razão para precisar invocar
bbvirt diretamente.

OPÇÕES

Existem dois modos principais de operação para bbvirt que são selecionados pela inicial
opção de ação. Se a ação a ser executada é anexar or desanexar então apenas um único dispositivo
terá ação, e qual dispositivo deve ser especificado explicitamente, mesmo que
há apenas um dispositivo presente no host no momento. Ao invocar bbvirt manualmente,
que o dispositivo pode ser especificado por seu número de série, seu endereço lógico no barramento (no
formulário ônibus:devnum, dados como inteiros decimais), ou seu endereço físico no barramento (no
formulário ônibus-porta[.porta ...]).

Se a ação a ser executada é anexar tudo or separar tudo, então o (s) dispositivo (s) para agir são
selecionado por domínio associação em vez disso. Se um domínio é explicitamente especificado, então todos
os dispositivos atribuídos a esse domínio convidado no arquivo de configuração serão acionados
em cima da mesma maneira como se bbvirt foi invocado para cada um deles individualmente com o
anexar or desanexar açao. Se não domínio é fornecido, então todos os convidados configurados
domínios serão tratados desta forma.

As seguintes opções adicionais estão disponíveis:

-C, --config
Especifique um arquivo de configuração alternativo para importar as atribuições do dispositivo.
Se o caminho para o arquivo não for fornecido explicitamente, ele será procurado em
que o / etc / bit-tagarela diretório (com um .conf sufixo).

-c, --connect =URI
Especifique o Virsh(1) conexão URI usar. Isso substituirá um DOMAIN_URI conjunto
para o domínio no arquivo de configuração. Se isso não for definido usando nenhum destes
métodos, então o Virsh padrão para o usuário em execução bbvirt será usada.

-D, --domain =nome
Especifique o domínio libvirt sobre o qual agir. Isso pode ser usado para substituir o dispositivo
alocação do arquivo de configuração quando bbvirt é invocado manualmente ou para agir
em um dispositivo ou domínio que não está atualmente especificado no arquivo de configuração.

-b, --busnum =Números
Especifique o número do barramento USB ao qual o dispositivo está conectado. Esta opção é principalmente
usado para evitar bbvirt precisar pesquisar isso quando já for conhecido (como quando
é chamado de um udev regra). Normalmente não há muitos motivos para aprovar isso se
invocando bbvirt manualmente, uma vez que você pode apenas especificar o dispositivo por sua lógica ou
endereço físico em vez disso.

-d, --devnum =Números
Especifique o número do dispositivo USB ao qual o dispositivo está atualmente atribuído. Junto com
o número do barramento, forma o endereço lógico do dispositivo. Esta opção é
usado principalmente para evitar bbvirt precisar procurar isso quando já é conhecido (tal
como quando é chamado de um udev regra). Normalmente não há muitos motivos para passar
isso se invocando bbvirt manualmente, já que você pode apenas especificar o dispositivo por seu
endereço lógico em vez disso.

-n, --funcionamento a seco
Não conecte ou desconecte nenhum dispositivo, apenas mostre o que seria tentado se fosse um
correr ao vivo. Esta opção implica um nível mínimo de --verbose, mas a verbosidade pode
ser aumentado ainda mais, passando essa opção explicitamente.

-dentro, --verbose
Faça mais barulho sobre o que realmente está acontecendo. Pode ser passado várias vezes para
aumentar a verbosidade ainda mais.

- ?, --Socorro
Mostra um breve resumo das opções disponíveis.

CONFIGURAÇÃO OPÇÕES

A bbvirt arquivo de configuração contém atribuições de variáveis ​​usando o bater(1) concha
sintaxe. É originado como um snippet de shell, portanto, você pode, a princípio, construir o
configuração para cada domínio dinamicamente, mas normalmente uma simples atribuição estática
de dispositivos para domínios será suficiente. Se você optar por executar o código nele, você deve ser muito
defensivo sobre namespacing quaisquer outras variáveis ​​que você usa, ou quaisquer outros efeitos colaterais que você
pode fazer acontecer. Qualquer número de domínios de convidado pode ser configurado nele.

Para cada domínio de convidado, duas variáveis ​​controlam o comportamento de bbvirt:

DOMAIN_URI_domínio=URI
Esta variável é opcional e define o Virsh(1) conexão URI usar quando
anexar ou desanexar dispositivos do domínio. Se o --conectar opção
explicitamente passado para bbvirt ele substituirá o que está definido aqui. Se a conexão
URI não é definido usando nenhum desses métodos, então o Virsh padrão para o usuário
corrida bbvirt será usado (que normalmente seria o root se executado a partir de udev).

DOMAIN_RNG_domínio=( dispositivo serial números ... )
Esta variável é necessária se a passagem automática de dispositivos para um domínio for
desejado. É uma matriz bash, preenchida com uma lista separada por espaços de todos os
números de série do dispositivo que você deseja atribuir domínio. Não é um erro para
dispositivos a serem listados aqui que não estão conectados no momento. É importante
certifique-se de que os dispositivos são atribuídos apenas a um domínio embora, e que dispositivos
atribuídos a domínios convidados não serão usados ​​por um semear(1) instância em execução no
hospedeiro (o que significa o semear a configuração precisa receber uma lista explícita de
os dispositivos que ele pode usar também).

O número de série do dispositivo sempre deve ser usado aqui. Você não pode especificar um dispositivo por
seu endereço lógico ou físico no ônibus (como você pode na maioria dos outros lugares onde
pegamos um ID do dispositivo).

Use bbvirt online usando serviços onworks.net