使用oVirt过程中遇到的一系列坑及如何填
本文列出了在使用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/[email protected]/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/[email protected]/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’
[[email protected] ~]# 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
[[email protected] ~]#
[[email protected] ~]# 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
[[email protected] ~]#
这个文件有30GB，那么是什么呢？就是virtual disk. 它的权限写明了是vdsm和kvm都可以读写的，但是却还是打不开。这似乎只能说明做操作的进程不是vdsm用户，也不是kvm组成员。这个问题又是和上面的问题相同的根源。
于是再去查看系统中的vdsm进程和service：
[[email protected] ~]# 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
[[email protected] ~]# 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
[[email protected] ~]# 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更新