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