OpenStack的基本操作与使用经验_专栏

一，基本操作

openstack network list openstack image list openstack flavor list nova boot --availability-zone nova::pod2-com --image cirros --nic net-id=5642c805-6249-41f6-bc4b-c37be2726993 --flavor e0ce542a-4580-4e1d-9696-89dd8390007 vm1

nova:: pod2-com 为计算节点主机名

--image cirros为镜像的名称

--nic指定网络

--flavor指定实例类型

vm1为虚机名称

二，关于日志定位

Nova（控制节点）
/var/log/nova/*

nova-api.log：用户与OpenStack交互及OpenStack组件间交互的消息相关日志
nova-scheduler.log：有关调度的，分配任务给节点以及消息队列的相关日志
nova-conductor.log：负责数据库的访问权限控制，避免nova-compute直接访问
nova-manage.log：运行nova-manage命令时产生的日志
nova-console.log：关于nova-console的VNC服务的详细信息
nova-consoleauth.log：关于nova-console服务的验证细节
nova-placement-api.log：统一资源管理接口
nova-novncproxy.log：提供vnc访问功能
按功能划分其主要组件有：
（1）虚拟机管理： nova-api、nova-compute、nova-scheduler
（2）虚拟机VNC及日志管理： nova-console、nova-consoleauth
（3）数据库管理： nova-conductor
（4）安全管理： nova-consoleauth、nova-cert
Nova（计算节点）
/var/log/nova/compute.log 虚拟机实例在启动和运行中产生的日志
Neutron（网络节点）
/var/log/neutron/*
dhcp-agent.log：关于dhcp-agent的日志
l3-agent.log：与l3代理及其功能相关的日志
metadata-agent.log：通过neutron代理给Nova元数据服务的相关日志
openvswitch-agent.log：与openvswitch相关操作的日志项，在具体实现OpenStack网络时，如果使用了不同的插件，就会有相应的日志文件名
Neutron（控制节点）
/var/log/neutron/*
openvswitch-agent.log：与openvswitch相关操作的日志项，在具体实现OpenStack网络时，如果使用了不同的插件，就会有相应的日志文件名（networking-odl-alert.log）
server.log：与Neutron API服务相关的日志
glance
/var/log/glance/*
api.log：Glance API相关的日志
registry.log：Glance registry服务相关的日志
keystone
/var/log/keystone/*
keystone.log：份认证Keystone服务的日志
libvirtd
/var/log/libvirt/(qemu里的日志很重要！！)
dashboard
/var/log/httpd/

三，抓包定位

虚机ip地址学习、ping等网络问题时的定位方法，需要以下几个步骤：
先抓包确认具体的丢包点

OVS实现抓包工具，ovs-tcpdump（建议配合wireshark来分析报文）。其用法和tcpdump一样
使用ovs-tcpdump需要安装对应的python模块：
$ yum install python-openvswitch
例如：
ovs-tcpdump -i eth0 -w test.pcap
ovs-tcpdump -i eth0 -vv
再根据丢包点，按照下面方法确认丢包原因；
查看虚机接入端口状态
$ ovs-ofctl show br-int -Oopenflow13
如果端口的state状态LINK_DOWN，表示端口状态为DOWN，要检查虚机是否正常接入。
查看端口是否存在丢包
ovs-ofctl dump-ports br-int -Oopenflow13
查看流表是否正常
$ ovs-ofctl dump-flows br-int -Oopenflow13
跟踪特定报文
例如跟踪如端口为100,源MAC c6:79:2c:ed:b9:ae目的MAC 62:fd:8e:74:84:c7的报文。
$ovs-appctl ofproto/trace br-int in_port=100,dl_src=c6:79:2c:ed:b9:ae,dl_dst=62:fd:8e:74:84:c7 –generate

四，其它错误

A> Openflow连不上控制器

◆解决办法：

ovs openflow协议默认是openflow1.4,要设置成13

设备上先要of协议才能连接到控制器

ovs-vsctl set bridge br-int protocols=OpenFlow13

ovs-vsctl set bridge br-ex protocols=OpenFlow13

B> OVS OVSDB控制器连不上

centos默认防火墙的原因，确认firewalld和iptables都是停止状态或者去掉屏蔽所有连接的表项

C> OVS和控制器断开连接后流表丢失问题

ovs-vsctl add-br br-int --set bridge br-int datapath_type=netdev fail_mode=secure protocols=OpenFlow13

D> Ovs配置不能下发（找不到主机）

◆错误信息：

◆解决办法：

/etc/sudoers下面secure_path少了/usr/local/bin，使得nova-compute执行nova-rootwrap后识别不到/usr/local/bin下的应用，而ovs通过代码编译后，默认是安装在/usr/local/bin下的，/etc/sudoers加入/usr/local/bin可解决该问题，修改/etc/sudoers后要重启nova-compute

E> qemu相关错误（找不到主机）

◆错误信息：

libvirtError: 内部错误：qemu unexpectedly closed the monitor: 2020-07-27T03:35:43.584801Z qemu-kvm: -chardev socket,id=charnet0,path=/usr/local/var/run/openvswitch/vhu3fa2d364-e8,server: Failed to bind socket to /usr/local/var/run/openvswitch/vhu3fa2d364-e8: Permission denied

◆解决办法：

虚机为libvirt-qemu用户创建，对应端口的sock为root创建，这里参考华为的文档，修改libvirt启动虚机的权限（/etc/libvirt/qemu.conf user和group均改为root），网上还有另外一种修改sock创建的用户的方法未实验成果，暂放弃。计算节点/etc/libvirt/qemu.conf（重启libvirtd，chown root:kvm /dev/kvm）vnc_listen = "0.0.0.0"user = "root"group = "root"security_driver = "none"

F> 控制节点没有发现计算节点

◆解决办法：（查看计算节点服务是否开启）

查看tail -f /var/log/nova/nova-compute.log

systemctl status openstack-nova-compute.service

发现未开启，进行开启

systemctl start openstack-nova-compute.service