我正在尝试启动Xen VM,但是我得到了以下错误:
Error: Device 2049 (vbd) could not be connected. Hotplug scripts not working.
这是什么意思?
dom0是CentOS,客户操作系统是Debian。我使用的网络接口是:
vif = [ 'mac=00:16:3e:3e:53:5f, bridge=xenbr0', 'mac=00:16:3e:18:16:e5, bridge=xenbr1' ]
客户操作系统的根文件系统被设置为从dom0通过NFS挂载,这适用于同一主机上的其他来宾OSs。交换(和/var
)是从本地LVM逻辑卷挂载的。
更新我的错误。我没有正确地编写配置,也没有正确地设置文件系统。我能够看到/var/log/xen/xen-hotplug.log
访问错误的设备。
发布于 2009-08-10 04:00:17
是我的错。我没有正确地编写配置,也没有正确地设置文件系统。我能够查看/var/log/xen/xen-hotplug.log来查看它是否访问了错误的设备。
发布于 2009-07-15 02:08:57
检查一下你有没有/etc/udev/rules.d/xen-backend.rules
。文件可以用数字作为前缀,也可以不以数字作为前缀。
如果没有,请检查是否有/etc/udev/xen-backend.rules
,并创建一个从该链接到/etc/udev/rules.d/xen-backend.rules
的符号链接。
我在Gentoo 3.3 dom0中看到过这种情况,而不是CentOS。但我怀疑修复方法会是相同的或类似的。
Xen构建脚本调用命令udevinfo -V
来确定安装在机器上的udev的版本。udevinfo
实用程序在一段时间前为了udevadm
而贬值。在最近发布的udev中,旧的实用程序已经被完全删除。
构建脚本使用所述获得的udev版本来确定需要执行哪些安装步骤。如果它找不到/匹配udev版本,那么它就不会安装所需的udev规则。由于没有udevinfo
,这就是正在发生的事情。
现在可能是因为你不想降低udev的评级。所以剩下两种解决方案。
您可以检查您的包分发服务器是否修复了此问题。例如,它在Xen 4.4中根据这只虫子在Gentoo上固定。
或者,您可以暂时绕过它,欺骗它udevinfo
仍然存在,并以它所期望的方式行事。我们可以通过脚本编写/代理新的udevadm
命令来做到这一点:
# echo -e '#!/bin/bash\n/sbin/udevadm info $1' > /usr/bin/udevinfo
# chmod +x /usr/bin/udevinfo
*** Install Xen ***
# rm /usr/bin/udevinfo
这会让它再起作用的。但从长远来看,你仍然需要解决这个问题。
https://serverfault.com/questions/40947
复制相似问题