使用oVirt过程中遇到的一系列坑及如何填

最新推荐文章于 2022-12-29 10:25:34 发布

执假以为真

最新推荐文章于 2022-12-29 10:25:34 发布

阅读量6.9k

点赞数 1

分类专栏： # 虚拟化文章标签： oVirt

本文链接：https://blog.csdn.net/nirendao/article/details/74780552

版权

虚拟化专栏收录该内容

22 篇文章 3 订阅

订阅专栏

本文列出了在使用oVirt的过程中遇到的一系列问题。其中第3部分（启动虚拟机安装OS）中遇到的问题可能是和我的环境相关，最后虽然都找到了解决办法，但是root cause还不清楚，有待将来深入到vdsm或qemu代码层面再去做研究。
所用oVirt为4.1.2.2版本。

在添加普通的CentOS 7.3 为主机的时候，遇到以下问题：

1.1 报错“extra/7/x86_64” 找不到
Root Cause: 未知，大约和DNS或yum repository有关
解决：编辑 /etc/sysconfig/network-scripts 下的主要的接口文件，在这里为：ifcfg-ovirtmgmt 或 ifcfg-eno1, 添加DNS1为8.8.8.8

1.2 网络无法连通
Root Cause：这是因为之前在该主机上设置过bridge br0
解决：

    brctl delif br0 <interfacename, e.g. eno1>
    ifdown ifcfg-br0   # 此时才能将此接口设为down
    brctl delbr br0    # 此时才能删除此bridge

1.3 YUM 安装失败
Root Cause：Installing Host的时候有116个步骤，其中的yum安装步骤有可能因为网络的原因而安装失败
解决：重新安装即可

上传虚拟机ISO文件失败：

    engine-iso-uploader upload -i <ISO domain name> <local ISO file path>

Root Cause: 在此例中，NFS Server是安装在了计算节点上，但是iptables配置文件里少开了一个端口 2049
解决： vim /etc/sysconfig/iptables 模仿 111 端口的配置方式，加上 2049 端口的配置

在第一次运行虚拟机（准备安装OS时）产生的错误

3.1 报错：Failed to bind socket to /var/lib/libvirt/qemu/channels/xxxxxxxx.com.redhat.rhevm.vdsm: Permission denied

解决方法：

chown -R root:root /var/lib/libvirt/qemu/channels/   # 原先是 vdsm:qemu

注：这种修改是从道理上看，是完全不正确的。从填完所有坑后的结果来看，也是不可理解的。因为做事的进程是vdsmd，它也是vdsm用户启动的，但是却要把文件权限改成root才能访问。

其他：
在 /etc/libvirt/qemu.conf , 有各种配置，包括了权限的配置

官方Bug：
https://bugzilla.redhat.com/show_bug.cgi?id=832011 （Closed但未解决）

3.2 报错：reds_init_ssl: Could not use private key file

解决方法-1：
编辑虚机，不使用SPICE协议，使用VNC协议

解决方法-2：

chmod a+r /etc/pki/vdsm/libvirt-spice/server-key.pem

注：这个解决办法和3.1的解决办法是类似的，要给文件添加了其他人都能读的权限后才不报错，但是做事的进程又是vdsmd，不可理解。

官方Bug：
https://bugzilla.redhat.com/show_bug.cgi?id=1003488 （Closed但未解决）
https://bugzilla.redhat.com/show_bug.cgi?id=1171397 （Closed但未解决）

Email Archive:
https://www.mail-archive.com/users@ovirt.org/msg31796.html
(提出了用strace分析问题，然后得出结论：chomd a+r server-key.pem)

3.3 报错： libvirtError: Could not open ‘/rhev/data-center/mnt/10.240.217.72:_export_iso/4f65e91e-5b6d-487d-ae2c-a9df50595bb5/images/11111111-1111-1111-1111-111111111111/ubuntu-16.04.1-desktop-amd64.iso’: Permission denied

别人遇到此问题后的解决办法：
https://lists.fedoraproject.org/archives/list/vdsm-devel@lists.fedorahosted.org/thread/VSWJYXPDO3S4KZG4H6KXUGFF26V34DOR/

semanage fcontext -a -t virt_image_t '/rhev/data-center/mnt/[^/]+';
semanage fcontext -a -t virt_image_t '/rhev/data-center/[-0-9a-f]+/[-0-9a-f]+';
restorecon -Rv /rhev

这里对SELinux的操作学到一手，另外，在自己实验的过程中还学到如何Disable SELinux：

vim /etc/selinux/config 
# SELinux=Disabled

但是别人的解决办法对我这边不生效，最终我这里的解决办法是：

chmod a+r /export/iso/4f65e91e-5b6d-487d-ae2c-a9df50595bb5/images/11111111-1111-1111-1111-111111111111/*

注意，这个报错里的 /rhev/data-center/mnt/10.240.217.72:_export_iso/4f65e91e-5b6d-487d-ae2c-a9df50595bb5/images/11111111-1111-1111-1111-111111111111/ubuntu-16.04.1-desktop-amd64.iso 其实就对应到 /export/iso/4f65e91e-5b6d-487d-ae2c-a9df50595bb5/images/11111111-1111-1111-1111-111111111111/* 而 /export/iso 是NFS Server里的配置的目录。

感觉像是用了既不是vdsm用户，也不是kvm Group的用户在跑vdsmd. 这个问题和3.1、3.2的问题是一个根源。

3.4 在解决了上面的问题之后，然后再去启动VM，就有如下的新的错误出现：

qemu-kvm: -drive file=/rhev/data-center/00000001-0001-0001-0001-000000000311/17edad64-7075-4bba-916d-4306605c017f/images/854c11eb-cd41-490e-999b-9963d386fed4/239c5537-074b-4d2f-b433-41f76c75b169,format=raw,if=none,id=drive-scsi0-0-0-0,serial=854c11eb-cd41-490e-999b-9963d386fed4,cache=none,werror=stop,rerror=stop,aio=threads: Could not open '/rhev/data-center/00000001-0001-0001-0001-000000000311/17edad64-7075-4bba-916d-4306605c017f/images/854c11eb-cd41-490e-999b-9963d386fed4/239c5537-074b-4d2f-b433-41f76c75b169': Permission denied (code=1) (vm:1222)

所以，去查看：’/rhev/data-center/00000001-0001-0001-0001-000000000311/17edad64-7075-4bba-916d-4306605c017f/images/854c11eb-cd41-490e-999b-9963d386fed4/239c5537-074b-4d2f-b433-41f76c75b169’

[root@localhost ~]# ls -l /rhev/data-center/00000001-0001-0001-0001-000000000311/17edad64-7075-4bba-916d-4306605c017f/images/854c11eb-cd41-490e-999b-9963d386fed4/
total 1028
-rw-rw---- 1 vdsm kvm 32212254720 Jul  5 16:51 239c5537-074b-4d2f-b433-41f76c75b169
-rw-rw---- 1 vdsm kvm     1048576 Jul  5 16:51 239c5537-074b-4d2f-b433-41f76c75b169.lease
-rw-rw-r-- 1 vdsm kvm         318 Jul  5 16:51 239c5537-074b-4d2f-b433-41f76c75b169.meta
[root@localhost ~]# 
[root@localhost ~]# file /rhev/data-center/00000001-0001-0001-0001-000000000311/17edad64-7075-4bba-916d-4306605c017f/images/854c11eb-cd41-490e-999b-9963d386fed4/239c5537-074b-4d2f-b433-41f76c75b169
/rhev/data-center/00000001-0001-0001-0001-000000000311/17edad64-7075-4bba-916d-4306605c017f/images/854c11eb-cd41-490e-999b-9963d386fed4/239c5537-074b-4d2f-b433-41f76c75b169: regular file, no read permission
[root@localhost ~]#

这个文件有30GB，那么是什么呢？就是virtual disk. 它的权限写明了是vdsm和kvm都可以读写的，但是却还是打不开。这似乎只能说明做操作的进程不是vdsm用户，也不是kvm组成员。这个问题又是和上面的问题相同的根源。

于是再去查看系统中的vdsm进程和service：

[root@localhost ~]# ps -elf | grep vdsm
4 S vdsm      1542     1  0  80   0 - 96267 poll_s Jul06 ?        00:00:07 /usr/bin/python /usr/bin/ovirt-imageio-daemon
4 S root      1553     1  0  75  -5 - 270911 poll_s Jul06 ?       00:00:01 /usr/bin/python2 /usr/share/vdsm/supervdsmServer --sockfile /var/run/vdsm/svdsm.sock
0 S vdsm      5643 27042  0  60 -20 - 95645 futex_ 11:18 ?        00:00:00 /usr/libexec/ioprocess --read-pipe-fd 45 --write-pipe-fd 43 --max-threads 10 --max-queued-requests 10
0 S vdsm      5650 27042  0  60 -20 - 95645 futex_ 11:18 ?        00:00:00 /usr/libexec/ioprocess --read-pipe-fd 52 --write-pipe-fd 50 --max-threads 10 --max-queued-requests 10
0 S vdsm      5658 27042  0  60 -20 - 95645 futex_ 11:18 ?        00:00:00 /usr/libexec/ioprocess --read-pipe-fd 61 --write-pipe-fd 60 --max-threads 10 --max-queued-requests 10
0 S vdsm      5665 27042  0  60 -20 - 95645 futex_ 11:18 ?        00:00:00 /usr/libexec/ioprocess --read-pipe-fd 69 --write-pipe-fd 68 --max-threads 10 --max-queued-requests 10
0 S root      5676  5452  0  80   0 - 28163 pipe_w 11:18 pts/1    00:00:00 grep --color=auto vdsm
4 S vdsm     27042     1  1  60 -20 - 1078956 poll_s Jul06 ?      00:14:54 /usr/bin/python2 /usr/share/vdsm/vdsm
4 S vdsm     27149     1  0  80   0 - 154770 poll_s Jul06 ?       00:02:03 python /usr/sbin/momd -c /etc/vdsm/mom.conf
0 S vdsm     27234 27042  0  60 -20 - 95652 futex_ Jul06 ?        00:00:10 /usr/libexec/ioprocess --read-pipe-fd 83 --write-pipe-fd 82 --max-threads 10 --max-queued-requests 10
0 S vdsm     27258 27042  0  60 -20 - 95645 futex_ Jul06 ?        00:00:05 /usr/libexec/ioprocess --read-pipe-fd 93 --write-pipe-fd 91 --max-threads 10 --max-queued-requests 10

[root@localhost ~]# systemctl -qa | grep vdsm
sys-devices-virtual-net-\x3bvdsmdummy\x3b.device    loaded    active   plugged   /sys/devices/virtual/net/;vdsmdummy;
sys-subsystem-net-devices-\x3bvdsmdummy\x3b.device  loaded    active   plugged   /sys/subsystem/net/devices/;vdsmdummy;
mom-vdsm.service                                    loaded    active   running   MOM instance configured for VDSM purposes
supervdsmd.service                                  loaded    active   running   Auxiliary vdsm service for running helper functions as root
vdsm-network-init.service                           loaded    active   exited    Virtual Desktop Server Manager network IP+link restoration
vdsm-network.service                                loaded    active   exited    Virtual Desktop Server Manager network restoration
vdsmd.service                                       loaded    active   running   Virtual Desktop Server Manager

[root@localhost ~]# systemctl status vdsmd
● vdsmd.service - Virtual Desktop Server Manager
Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2017-07-06 18:28:13 CST; 16h ago
Process: 26956 ExecStartPre=/usr/libexec/vdsm/vdsmd_init_common.sh --pre-start (code=exited, status=0/SUCCESS)
Main PID: 27042 (vdsm)

从以上结果可以看出，vdsm服务（27042）就是vdsm用户run起来的，其他只有一个 supervdsmServer 是 root 用户起的。所以这样还无法读写，就比较令人费解了。这个问题也是和上面的3.1、3.2、3.3的问题是相同的根源。

最终还是用workaround解决：

chmod a+rw /export/data/17edad64-7075-4bba-916d-4306605c017f/images/854c11eb-cd41-490e-999b-9963d386fed4/*

迁移失败

迁移失败，报错，不能迁移到相同的主机。
Root Cause: 两台主机的主机名都是 localhost.localdomain
解决：

hostname <new hostname>  # 修改内存中的主机名
vim /etc/hostname  # 永久修改主机名，但需重启，因做了上面那一步操作，就不用重启了。

另外，注意，修改 /etc/hosts 是不解决这个问题的。

2017.07.13更新

执假以为真

关注

1
点赞
踩
2

收藏

觉得还不错? 一键收藏
1
评论
使用oVirt过程中遇到的一系列坑及如何填

本文列出了在使用oVirt的过程中遇到的一系列问题。其中第3部分（启动虚拟机安装OS）中遇到的问题可能是和我的环境相关，最后虽然都找到了解决办法，但是root cause还不清楚，有待将来深入到vdsm或qemu代码层面再去做研究。所用oVirt为4.1.2.2版本。
复制链接

扫一扫