Cinder

VolumeDeviceNotFound

实例Hard Reboot后，出现VolumeDeviceNotFound的错误。

查看计算节点上，nova-compute的日志。

nova.compute.manager [req-1c2e36df-c5ff-49aa-9893-6046cd0cbfeb b29311c34edb4f179092e81cbee10682 8e4be2cb25084defb5a9f0128afd5291 - default default] [instance: d17a8b0f-759c-4f54-b265-64fc16986710] Cannot reboot instance: Volume device not found at .: os_brick.exception.VolumeDeviceNotFound: Volume device not found at .

解决方法

存储节点查看对应的物理设备是否被创建。

1
2
3

# f870fcdb-209c-4877-8de4-1b7683b98548是volume的ID。
lsblk | grep f870fcdb--209c--4877--8de4--1b7683b98548
ls /dev/cinder-volumes/volume-f870fcdb-209c-4877-8de4-1b7683b98548

在存储节点上查看iSCSI资源。

1	targetcli ls

得到下面的结果。

| o- iqn.2010-10.org.openstack:volume-f870fcdb-209c-4877-8de4-1b7683b98548 ............................................. [TPGs: 1]
| | o- tpg1 .......................................................................................... [no-gen-acls, auth per-acl]
| |   o- acls .......................................................................................................... [ACLs: 1]
| |   | o- iqn.2020-08.org.openanolis:8a5ea81155a ................................................... [1-way auth, Mapped LUNs: 0]
| |   o- luns .......................................................................................................... [LUNs: 0]
| |   o- portals .................................................................................................... [Portals: 1]
| |     o- 10.10.15.14:3260 ................................................................................................. [OK]

从上面的结果可以看到acls是正常的，但luns中没有数据。

新建backstores

targetcli \
/backstores/block create \ 
name=iqn.2010-10.org.openstack:volume-f870fcdb-209c-4877-8de4-1b7683b98548 \
dev=/dev/cinder-volumes/volume-f870fcdb-209c-4877-8de4-1b7683b98548

新建lun

targetcli \
/iscsi/iqn.2010-10.org.openstack:volume-f870fcdb-209c-4877-8de4-1b7683b98548/tpg1/luns \ 
create  \
/backstores/block/iqn.2010-10.org.openstack:volume-f870fcdb-209c-4877-8de4-1b7683b98548

也可以使用cinder-rtstool，更加方便。

1	cinder-rtstool create /backstores/block/iqn.2010-10.org.openstack:volume-f870fcdb-209c-4877-8de4-1b7683b98548

重设实例状态。

1	openstack server set --state active ce979e29-198d-498b-b2e3-c0cab6c82c98

重启实例。

1	openstack server reboot --hard ce979e29-198d-498b-b2e3-c0cab6c82c98

再次查看，已经正常。

| o- iqn.2010-10.org.openstack:volume-f870fcdb-209c-4877-8de4-1b7683b98548 ............................................. [TPGs: 1]
| | o- tpg1 .......................................................................................... [no-gen-acls, auth per-acl]
| |   o- acls .......................................................................................................... [ACLs: 1]
| |   | o- iqn.2020-08.org.openanolis:8a5ea81155a ................................................... [1-way auth, Mapped LUNs: 1]
| |   |   o- mapped_lun0 ................. [lun0 block/iqn.2010-10.org.openstack:volume-f870fcdb-209c-4877-8de4-1b7683b98548 (rw)]
| |   o- luns .......................................................................................................... [LUNs: 1]
| |   | o- lun0  [block/iqn.2010-10.org.openstack:volume-f870fcdb-209c-4877-8de4-1b7683b98548 (/dev/cinder-volumes/volume-f870fcdb-209c-4877-8de4-1b7683b98548) (default_tg_pt_gp)]

其他

volume删除后，存储节点的日志里会报错。

1
2

Jan 17 10:14:22 compute3 kernel: Unable to locate Target IQN: iqn.2010-10.org.openstack:volume-c6774132-65f2-47a0-a65b-9a5d06a4accb in Storage Node
Jan 17 10:14:22 compute3 kernel: iSCSI Login negotiation failed.

解决方法，到各个节点中执行iscsiadm命令

[root@compute2 ~] iscsiadm -m session -P 3 | grep c6774132
Target: iqn.2010-10.org.openstack:volume-c6774132-65f2-47a0-a65b-9a5d06a4accb (non-flash)

[root@compute2 ~] iscsiadm -m node -T iqn.2010-10.org.openstack:volume-c6774132-65f2-47a0-a65b-9a5d06a4accb -p 10.10.15.14:3260 --logout
Logging out of session [sid: 248, target: iqn.2010-10.org.openstack:volume-c6774132-65f2-47a0-a65b-9a5d06a4accb, portal: 10.10.15.14,3260]
Logout of [sid: 248, target: iqn.2010-10.org.openstack:volume-c6774132-65f2-47a0-a65b-9a5d06a4accb, portal: 10.10.15.14,3260] successful.

Image

镜像密码修改

使用guestfish

在计算节点（运行libvirtd服务的节点）上，使用guestfish命令。

1 2	# 安装依赖包 yum install -y libguestfs-tools

执行guestfish命令。

guestfish --rw -a CentOS-Stream-GenericCloud-9-x86_64.qcow2
> run
> list-filesystem
><fs> run
100% ⟦▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒⟧ 00:00
><fs>list-filesystems
/dev/sda1: xfs
><fs> mount /dev/sda1 /
><fs> vi /etc/cloud/cloud.cfg           # 编辑cloud-init的配置文件
><fs> vi /etc/ssh/sshd_config           # 编辑sshd服务的配置文件

/etc/cloud/cloud.cfg

# 打开root登录
disable_root: false
# 打开ssh 密码登录
ssh_pwauth: true
# 修改root密码。
# 注意：新版本cloud-ini的chpasswd中的list已经被users取代，可以通过指定type，改变密码的类型，默认是hash。
chpasswd:
   expire: false
   list: |
     root:centos

/etc/ssh/sshd_config

1 2	PermitRootLogin yes PasswordAuthentication yes

保存退出。

使用virt-customize

在计算节点（运行libvirtd服务的节点）上，安装依赖包。

1	yum install -y libguestfs-tools

使用virt-customize命令。

1	sudo virt-customize -a CentOS-Stream-GenericCloud-9-x86_64.qcow2 --root-password password:123456

如果出现下面的错误。

[   0.0] Examining the guest ...
virt-customize: error: libguestfs error: could not create appliance through
libvirt.

Try running qemu directly without libvirt using this environment variable:
export LIBGUESTFS_BACKEND=direct

Original error from libvirt: Cannot access storage file
'/root/CentOS-Stream-GenericCloud-9-x86_64.qcow2' (as uid:107, gid:107):
权限不够 [code=38 int1=13]

If reporting bugs, run virt-customize with debugging enabled and include
the complete output:

  virt-customize -v -x [...]

执行下面的操作，修改libvirtd的权限。

cat >> /etc/libvirt/qemu.conf << EOF
user = "root"
group = "root"
EOF
systemctl restart libvirtd.service

使用horizon

horizon界面支持用户在创建云主机时注入密码。

传送门

修改horizon的local_settings.py文件。

OPENSTACK_HYPERVISOR_FEATURES = {
    ...
    'can_set_password': False,
}

修改/etc/nova/nova.conf，kolla部署的nova修改/etc/kolla/nova-compute/nova.conf。

1 2	[libvirt] inject_password=true

重启horizon和nova-compute服务。

1	systemctl restart httpd nova-compute

查看horizon界面。

镜像上传

openstack image create --disk-format qcow2 \
--container-format bare --public \
--file ./CentOS-Stream-GenericCloud-9-x86_64.qcow2
CentOS-Stream-GenericCloud-9-x86_64

网络

DHCP

实例获取不到IP地址

首先排查是否是安全组的问题导致dhcp报文传递不过去，查看安全组已经打开UDP协议。
排查是否是由系统内部防火墙导致dhcp报文传递不出去，禁用防火墙后问题依然存在。
排查是否是系统内部服务导致dhcp没有发送discover报文，在系统内使用dhclient命令可以获取到IP。
排查dhclient没有启动的原因，发现dhclient应该由NetworkManager启动。NetworkManager之所以没有启动dhclient是因为系统内/etc/sysconfig/network-scripts/ifcfg-enp1s0的配置文件，NetworkManager会忽略/etc/sysconfig/network-scripts/下的网络设备导致会出现device not managed错误导致dhclient不启动，进而云主机拿不到IP地址。
解决方法，将/etc/sysconfig/network-scripts/ifcfg-enp1s0删除。

端口转发

基于浮动IP的端口转发

浮动IP端口转发使用户能够将TCP/UDP流量，从Port通过iptables的NAT功能，转发给浮动IP。

部署

在运行neutron-server的所有节点（网络节点）上，修改/etc/neutron/neutron.conf文件。

1 2	[DEFAULT] service_plugins = router,segments,port_forwarding

在运行neutron-l3-agent的所有节点上，修改/etc/neutron/l3_agent.ini。

1 2	[agent] extensions = port_forwarding

重启neutron-server和neutron-l3-agent服务。

1	systemctl restart neutron-server neutron-l3-agent

验证。

1	openstack extension list --network \| grep floating-ip-port-forwarding

操作

创建端口转发

openstack floating ip port forwarding create \
--internal-ip-address 10.100.0.1 \
--internal-protocol-port 8080
--external-protocol-port 9000
--port 36bcd62a-0860-4e22-bf8a-81f5052eff60 \
--protocol tcp \
825cc4f8-9a1c-4e46-b380-501ba0f9b08d

36bcd62a-0860-4e22-bf8a-81f5052eff60和825cc4f8-9a1c-4e46-b380-501ba0f9b08d分别是Port和浮动IP的ID。

原理

TODO

horizon

compressor.exceptions.OfflineGenerationError: You have offline compression enabled but key "9a5d87a23b1b5362cdee3cc104aa5c24c3a33cd113d8e4ac4dfbebd1edbd9efc" is missing from offline manifest. You may need to run "python manage.py compress".

1 2	python manage.py collectstatic python manage.py compress

其他

keepalived

多虚IP

使用kvm部署多台机器，使用keepalived和haproxy作为集群高可用。发现虚IP在多个节点上同时出现，怀疑keepalived配置出问题。

在多个节点上利用tcpdump抓包，vrrp包都能被抓到，但是似乎节点之间收不到vrrp包。

tcpdump -i any vrrp -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
11:30:09.452941 IP 10.12.21.128 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 10, authtype simple, intvl 1s, length 20
11:30:10.453144 IP 10.12.21.128 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 10, authtype simple, intvl 1s, length 20
11:30:11.453369 IP 10.12.21.128 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 10, authtype simple, intvl 1s, length 20

确保SElinux处于关闭状态。

cat /etc/selinux/config

SELINUX=disabled
SELINUXTYPE=targeted

检查防火墙是否关闭。

1
2
3

systemtcl status firewalld
systemctl stop firewalld
systemctl disable firewalld

查看iptables规则。

iptables -S

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

防火墙一切正常，怀疑是KVM虚拟机的网络问题导致VRRP不能被传输。KVM使用nat网络进行传输时没有问题，在使用macvtap网络会出现上述问题。

查看官方文档，kvm在使用macvtap驱动时，参数trustGuestRxFilters默认否，可能会修改从虚拟机出来的流量的MAC地址，导致网络不可达。

编辑虚拟机配置文件。

...
    <interface type='direct' trustGuestRxFilters='yes'>
      <mac address='52:54:00:a9:f7:5b'/>
      <source dev='ens9f0' mode='bridge'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </interface>
...

最后如果问题还是复现，将每台虚拟机对应的macvtap网卡设置成混杂模式。

ifconfig macvtap5 promisc

ifconfig macvtap5
macvtap5: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 1500
        inet6 fe80::5054:ff:fea9:f75b  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:a9:f7:5b  txqueuelen 500  (Ethernet)
        RX packets 27827  bytes 2287340 (2.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 16236  bytes 1122923 (1.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

OpenStack All In One

目录