bbvirt - 云端在线

程序：

您的姓名

bbvirt - 将 BitBabbler 设备热插拔到 libvirt 管理的域中

概要

虚拟机 行动 [选项]

虚拟机 连接|DETACH 设备 [选项]

虚拟机 附加所有|全部分离 [域[选项]

商品描述

虚拟机 计划试图从目前的情况中消除一些痛苦
需要在主机和来宾虚拟机之间分配多个 USB 设备。
虽然有多种方式可以配置和管理它，但目前没有
它们中的实际上自己提供了一个完整且连贯的解决方案，它们都落入了
以某种重要且令人讨厌的方式达不到目标。 这里的目的是拼凑起来
足够的这些黑客实际上获得了我们现在想要的所有功能，直到
libvirt 对此的本机支持已足够改进，不再需要它。

目前这涉及到 libvirt 管理的 QEMU/KVM 虚拟机。

什么是 do we 想？
这里的理想行为非常简单。 给定一些任意数量的 BitBabbler
设备，我们应该能够将它们分配给主机或来宾 VM
运行它，一旦我们这样做，它们应该以任何预期的正常方式运行
USB设备。

- 如果他们在来宾机器启动时插入，他们应该被看到
机器就像主机一样。

- 如果它们是在机器启动后插入的，它们应该是热插入的
机器就像他们在主机上一样。

- 如果在机器运行时拔下它们，则应将它们干净地从
它，就像他们在主机上一样。

为什么 不能 we 已可以选用 它？
现在，libvirt 为我们提供了两种方法，我们可以将 USB 设备从主机分配到
来宾域。

- 我们可以通过他们的 USB 供应商和产品 ID 分配它们。 但这只有在有的时候才有效
只是主机中该类型的单个设备。 这在大多数情况下是非常无用的
我们在这里关心的案例，这里的主人和每一位客人都有可能
分配给它们自己的一个或多个 BitBabbler 设备。

- 我们可以通过它们在 USB 总线上的逻辑地址来分配它们。 但这不是一个常数
我们可以为域静态配置。 每次插入设备时，或
重新插入，或重置，或主机重新启动，该地址可能会更改
因为它是在总线上枚举设备时动态分配的。

还有第三种方法，但它依赖于绕过正常的 libvirt 配置来使
直接使用 QEMU 的能力，通过设备在总线上的物理地址来分配设备。
哪个更好，但仍然不是灵丹妙药，因为它依赖于完全相同的插入
设备每次都进入完全相同的端口（并且在将这些端口枚举到
主机在每次重新启动时采用相同的方式，这也不能保证）。 这也迫使
我们跳过其他圈套，因为我们需要额外的复杂性来管理
在 libvirt 之外手动访问设备的权限，但仍在协调中
用它。

更大的失败，所有这些方法都有一个共同点，就是它们都依赖于
在来宾启动之前，设备已经插入。 如果插入后
来宾已启动，或在来宾运行时移除并重新插入，或者如果主机
总线或集线器反弹导致重新连接，则设备将不会（重新）连接到
客人。 如果发生这种情况，唯一的解决方法是手动重新连接设备
XML 中的神秘咒语（这取决于您知道设备的新地址），或
完全关闭电源并重新启动来宾。 不是用户友好的顶峰
我们在这里寻找的操作。

什么是 能够 we do 关于 它？
几年前有一个补丁提交给 libvirt，它可以允许一个设备
由其 USB 产品 ID 和序列号指定，但这得到了一些推动 -
回来了，到目前为止还没有被应用到上游。 那会有很长的路要走
使这既简单又干净，让我们只需要处理热插拔方面
和。 我们将留下脾气暴躁的讽刺作为读者的练习......

另一种选择是我们可以将查找设备的逻辑地址委托给热插拔
经理喜欢 乌德夫(7). 这很有吸引力，因为我们可以知道地址何时
设备的变化及其变化，但是 乌德夫 本身不是很友好
本地管理员自定义的想法（虽然可以做到，但似乎越来越
越来越强烈不鼓励）并且使用它仍然需要一些外部胶水
将其事件转换为 libvirt 可以用来配置来宾的东西
机。

虚拟机 程序提供了这种胶水，以及一种用户友好的方法来分配哪个
设备应该属于哪些来宾域，以及一个可以手动调用的前端
或由其他管理员控制的任务来快速轻松地添加或删除 BitBabbler 设备
来自任何正在运行的客户机。

但是这种方法的局限性在于它不能轻易知道来宾机器何时处于
已启动，其中应添加已插入的设备。 理论上我们
可以将它们添加到其持久域定义中，但这有其自身的问题，因为
我们只能通过它们的临时逻辑地址添加设备，我们不能保证我们
当该地址无效时，将被调用以再次将它们从域中删除
（例如，如果主机突然断电或没有完全关闭），所以我们
最终可能会在持久域配置中积累许多陈旧的条目，
稍后可以将一些完全不同的设备与我们想要连接的设备相匹配
它。 这意味着在以某种方式修复之前，将它们添加到实时访客是安全的
域，以便它们在停止时总是会再次被删除，无论它如何
最终被阻止。

显然，我们还有一段路要走，才能达到我们的理想。

什么是 if we 击中 it *二* 锤子？
似乎只有两种方法可以通知我们来宾机器正在运行
目前开始。 一个涉及运行另一个守护进程，它会做
不仅仅是坐在那里等待有人邀请客人，这样它才能告诉我们
关于那个。 但是接下来我们还有另一件事要配置，还有另一个过程
跑步，还有更多的问题是弄清楚如何确保我们不会在比赛中输掉比赛
主机被引导，在获取初始设备事件集之间，该进程被
准备好并处于活动状态，以及将在启动时自动启动的任何来宾实际启动。

另一种方法是使用 libvirt 钩子。 这反过来又存在实际上不是的问题
允许我们从中运行任何 libvirt 函数，我们需要这样做才能附加
设备到主机。 我们不能保证我们可以默认安装，
因为系统上只能有一个这样的钩子，本地管理员可能已经
正在使用...

还有第三种方法，但这将涉及要求本地管理员启动所有来宾
机器通过我们自己的包装器，而不是通过他们已经知道的任何机制
和使用。 在相同情况下无法扩展以支持其他 USB 设备，其中
对人们施加的许多方式都是可怕的解决方案。

但是有一个漏洞我们可以利用。 我们可以使用 libvirt qemu 钩子来触发
更改事件 乌德夫，这可以反过来调用 虚拟机 以同样的方式
如果设备确实是热插拔的，就会发生这种情况，这为我们提供了额外的间接层
我们需要能够从钩子上安全地做到这一点。 鲁布·戈德堡会很自豪，而且
一些部件可能需要手工组装，但是有了所有这些，我们就可以拥有
类似于来宾计算机中的正常 USB 功能的东西。

它并不漂亮，但它可以与我们必须使用的东西一起使用。

好吧， 只是 展示 me 哪里 至 击中 它。
要将这些串在一起，您需要确保满足以下所有条件：

- 该 乌德夫(7) 安装了 bit-babbler 包中的规则。 如果你安装了这个
来自应该已经完成​​的 Debian 软件包。 如果你没有，你将需要
安装在中找到的规则 debian/bit-babbler.udev 从源包到
系统上合适的位置（可能是 /etc/udev/rules.d).

- 该 虚拟机(1) 脚本安装在 乌德夫 规则会找到它。 如果你
没有从 Debian 软件包安装它，它不在 / usr / bin，那么你需要
调整 乌德夫 规则以适应。

- 您希望在访客机器中使用的设备，以及您希望在其中使用它们的机器，
被指定在 虚拟机 配置文件。 默认位置是
/etc/bit-babler/vm.conf. 如果你想使用不同的文件，你需要传递它的
位置与 --配置 在选项 乌德夫 规则，并更新钩子脚本使用
文件也是。 您可以放入该文件的详细信息在
配置 配置 以下部分。

- 安装了 libvirt 挂钩文件。 如果以上所有都完成，那么设备将被
如果在来宾运行时插入它们，则添加到正在运行的来宾计算机中。
最后一步确保已经插入的设备将被添加到新的
也启动了来宾（包括在主机启动时自动启动的来宾）
机靴）。

直到有一些安全的方法我们可以安装它而不会与它发生冲突或覆盖
一个现有的钩子，每个人都需要手动完成这一步。 如果你已经安装
Debian 软件包，那么我们为此提供的示例钩子脚本可以是
在发现 /usr/share/doc/bit-babbler/examples/qemu-hook. 如果你没有它可以被发现
in libvirt/qemu 钩子 源包。

您需要将该文件安装为 /etc/libvirt/钩子/qemu，或将其内容与
现有的 哇 如果您已经设置了该挂钩，请在此处提交文件。 如果那个文件没有
以前存在，您将需要重新启动 虚拟机(8) 让它开始使用它。

这应该涵盖所有需要的自动化，但您也可以连接和分离设备
也可以随时手动。 这样做的细节将在下面描述
部分。 否则，完成上述所有操作后，就没有其他理由需要调用了
虚拟机 直。

配置

有两种主要的操作模式 虚拟机 由初始选择
动作选项。 如果要执行的操作是 连接 or DETACH 那么只有一个设备
将被操作，并且必须明确指定应该使用哪个设备，即使
当时主机上只有一个设备。 调用时 虚拟机 手动
此 设备 可以通过它的序列号、它在总线上的逻辑地址（在
申请 总线号:开发号，以十进制整数给出），或其在总线上的物理地址（在
申请 总线号-端口[。港口 ...]）。

如果要执行的操作是 附加所有 or 全部分离，那么要操作的设备是
被选择 域 协会代替。 如果一个 域 明确指定，那么所有
在配置文件中分配给该来宾域的设备将被执行
就好像 虚拟机 为他们中的每一个单独调用
连接 or DETACH 行动。 如果不 域 提供，然后所有配置的客人
域将以这种方式进行操作。

以下附加选项可用：

-C， --配置
指定要从中导入设备分配的备用配置文件。
如果未明确提供文件路径，则将在
此 /etc/比特喋喋不休 目录（带有 .conf 后缀）。

-C， --连接=的URI
指定 维尔什(1) 连接 的URI 使用。 这将覆盖一个 域_URI 集
对于配置文件中的域。 如果未使用其中任何一个进行设置
方法然后 维尔什 用户运行的默认值 虚拟机 将被使用。

-D, --域=姓名
指定要操作的 libvirt 域。 这可用于覆盖设备
从配置文件分配时 虚拟机 手动调用，或采取行动
在当前未在配置文件中指定的设备或域上。

-b, --总线编号=NUM
指定设备连接到的 USB 总线编号。 这个选项主要是
用来避免 虚拟机 当它已知时需要查找它（例如当
它是从一个 乌德夫 规则）。 通常没有太多理由通过这个，如果
调用 虚拟机 手动，因为您可以仅通过其逻辑或
物理地址代替。

-d, --devnum=NUM
指定设备当前分配的 USB 设备编号。 和...一起
总线号，这构成了设备的逻辑地址。 这个选项是
主要用于避免 虚拟机 当它已知时需要查找它（例如
当它被调用时 乌德夫 规则）。 通常没有太多理由通过
这如果调用 虚拟机 手动，因为您可以通过其指定设备
逻辑地址代替。

-n, --试运行
不要连接或分离任何设备，只需显示如果这是一个
直播。 此选项意味着最低级别的 --详细，但冗长可能
通过显式传递该选项进一步增加。

-v， --详细
对正在发生的事情制造更多噪音。 它可以多次传递给
进一步增加冗长。

-？， - 帮帮我
显示可用选项的简要摘要。

配置 配置

虚拟机 配置文件包含使用 打坏(1) 外壳
句法。 它是作为一个 shell 片段来源的，所以原则上你可以构建
每个域的动态配置，但最典型的是简单的静态分配
域的设备就足够了。 如果你选择在其中运行代码，你应该非常
防御命名空间您使用的任何其他变量，或您使用的任何其他副作用
可能导致发生。 可以在其中配置任意数量的来宾域。

对于每个来宾域，两个变量控制着 虚拟机:

域_URI_域=的URI
此变量是可选的，并设置 维尔什(1) 连接 的URI 使用的时候
从给定的设备上连接或分离设备 域。 如果 - 连接 选项是
明确传递给 虚拟机 它将覆盖这里设置的内容。 如果连接
的URI 未使用这些方法中的任何一种进行设置，则 维尔什 用户默认
运行 虚拟机 将被使用（如果从 乌德夫).

域_RNG_域=( 设备 串行 数字 ... )
如果设备到域的自动传递是必需的，则此变量是必需的
想要的。 它是一个 bash 数组，填充了一个空格分隔的列表，其中包含所有
要分配给的设备序列号 域. 这不是错误
此处列出的当前未插入的设备。重要的是
确保设备只分配给一个 域 不过，那个设备
分配给来宾域的用户将不会使用 播种(1) 实例运行在
主机（这意味着 播种 配置需要传递一个明确的列表
它也可能使用的设备）。

此处必须始终使用设备序列号。 您不能通过以下方式指定设备
它在总线上的逻辑或物理地址（就像在大多数其他地方一样）
我们获取设备 ID）。

使用 onworks.net 服务在线使用 bbvirt