维护模式没在vCenter中生效¶
症状¶
主机已经置为维护模式,但在vCenter中还是活动的。
原因¶
CloudStack管理员用户界面使用日程中的主机维护模式。该模式与vCenter的维护模式无关。
解决方案¶
请使用vCenter将主机置为维护模式。
警告
NOTICE: THIS DOCUMENTATION SITE HAS BEEN SUPERSEDED.
For the current documentation site goto: http://docs.cloudstack.apache.org
为了方便诊断系统,CloudStack 管理服务器在目录/var/log/cloud/management/下记录了所有网站、中间层和数据库的活动。CloudStack 会记录各种出错信息。我们推荐使用下述命令从管理服务器日志中寻找有问题的输出日志:
注解
当复制和粘贴命令时,请确保没有多余的换行符,因为一些文档查看器可能会在复制时加上换行符。
grep -i -E 'exception|unable|fail|invalid|leak|warn|error' /var/log/cloudstack/management/management-server.log
CloudStack处理请求时会生成一个任务ID。如果您发现了日志中的某个错误,然后想调试该问题,您可以在管理服务器日志中grep这个任务ID。例如,假设您发现了以下的ERROR信息:
2010-10-04 13:49:32,595 ERROR [cloud.vm.UserVmManagerImpl] (Job-Executor-11:job-1076) Unable to find any host for [User|i-8-42-VM-untagged]
注意到任务ID是1076。你可以追踪返回事件的相近任务1076按照以下grep:
grep "job-1076)" management-server.log
主存储的已有数据丢失。该主存储是用iSCSI卷导出的一个Linux NFS服务器输出。
可能的原因是存储池之外的某个客户端挂载了该存储。如果发生了这种情况,LVM会被擦除,该卷上的所有数据都会丢失。
配置LUN输出时,通过指定子网掩码来限制可以访问存储的IP地址范围。例如:
echo “/export 192.168.1.0/24(rw,async,no_root_squash,no_subtree_check)” > /etc/exports
根据你的部署需求,调整如上参数。
请参考CloudStack安装指南的“辅助存储”章节中的导出过程。
虚拟路由器是运行着的,但主机失去连接。虚拟路由器不再按期望工作。
虚拟路由器丢失或宕机。
如果您确定虚拟路由器宕机了,或不再正常工作,请销毁它。您必须再建一个新的,此时备份路由器应保持运行(假定在使用冗余路由器配置的情况下)。
使用restartNetwork API(参数cleanup=false)重建丢失的虚拟路由器。关于冗余虚拟路由器的配置,请参考创建新的网络方案。
关于更多的API语法信息,参见API参考`http://cloudstack.apache.org/docs/api/ <http://cloudstack.apache.org/docs/api/>`_。
主机已经置为维护模式,但在vCenter中还是活动的。
CloudStack管理员用户界面使用日程中的主机维护模式。该模式与vCenter的维护模式无关。
请使用vCenter将主机置为维护模式。
当试图创建一个虚拟机,虚拟机将无法部署。
如果模板通过上传OVA文件创建,而OVA文件是使用vSphere Client创建的,可能OVA中包含ISO镜像。如果是的话,从模板部署虚拟机将失败。
移除ISO并重新上传模板。
这是VMware机器的已知问题。为防止并发修改,ESX主机会锁定特定的关键虚机文件和文件系统。有时,虚机关机时没有解锁这些文件。当虚机再次开机时,由于不能访问这些关键文件,虚机就不能启动。
修改网络的网络方案后,负载均衡规则不再生效。
负载均衡规则创建时使用的是包含外部负载均衡器,例如NetScaler的网络方案,后来改为使用CloudStack虚拟路由器的网络方案。
针对每条已有的负载均衡规则,在虚拟路由器上创建相同的防火墙规则,以便规则继续生效。
在下列故障排查步骤中检验你网络中出现的故障…
交换机上可以完成正确的配置VLAN通信。你可以辨别主机上的VLAN是否通讯通过提出标记接口,并在上述两个VLAN中使用ping命令。
在*host1 (kvm1)*上
kvm1 ~$ vconfig add eth0 64
kvm1 ~$ ifconfig eth0.64 1.2.3.4 netmask 255.255.255.0 up
kvm1 ~$ ping 1.2.3.5
在*host2 (kvm2)*上
kvm2 ~$ vconfig add eth0 64
kvm2 ~$ ifconfig eth0.64 1.2.3.5 netmask 255.255.255.0 up
kvm2 ~$ ping 1.2.3.4
如果ping不通,运行 *tcpdump(8)*在所有VLAN上检查丢失的数据包。最终,如果交换机配置失败,CloudStack网络将无法工作,所以在处理下一部前要确定物理网络设备的问题。
确保 流量标签 已经设置在域中。
流量标签需要在包括XenServer,KVM和VMwarel在内的所有类型的hypervisors设置。当你从*Add Zone Wizard*创建一个域时,你可以配置流量标签。
在一个已经存在的域总,你可以通过*Add Zone Wizard*修改流量标签。
列出正在使用的*CloudMonkey*
acs-manager ~$ cloudmonkey list traffictypes physicalnetworkid=41cb7ff6-8eb2-4630-b577-1da25e0e1145
count = 4
traffictype:
id = cd0915fe-a660-4a82-9df7-34aebf90003e
kvmnetworklabel = cloudbr0
physicalnetworkid = 41cb7ff6-8eb2-4630-b577-1da25e0e1145
traffictype = Guest
xennetworklabel = MGMT
========================================================
id = f5524b8f-6605-41e4-a982-81a356b2a196
kvmnetworklabel = cloudbr0
physicalnetworkid = 41cb7ff6-8eb2-4630-b577-1da25e0e1145
traffictype = Management
xennetworklabel = MGMT
========================================================
id = 266bad0e-7b68-4242-b3ad-f59739346cfd
kvmnetworklabel = cloudbr0
physicalnetworkid = 41cb7ff6-8eb2-4630-b577-1da25e0e1145
traffictype = Public
xennetworklabel = MGMT
========================================================
id = a2baad4f-7ce7-45a8-9caf-a0b9240adf04
kvmnetworklabel = cloudbr0
physicalnetworkid = 41cb7ff6-8eb2-4630-b577-1da25e0e1145
traffictype = Storage
xennetworklabel = MGMT
=========================================================
KVM流量标签要求被命名为*”cloudbr0”, *”cloudbr2”, “cloudbrN” 等而且响应桥必须在KVM主机上。如果你以其他名字命名标记/桥,CloudStack(至少是较早版本)将会忽略它。CloudStack不能再KVM主机上创建物理桥,你需要在向CloudStackt添加主机前 **before**创建它们。
kvm1 ~$ ifconfig cloudbr0
cloudbr0 Link encap:Ethernet HWaddr 00:0C:29:EF:7D:78
inet addr:192.168.44.22 Bcast:192.168.44.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:feef:7d78/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:92435 errors:0 dropped:0 overruns:0 frame:0
TX packets:50596 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:94985932 (90.5 MiB) TX bytes:61635793 (58.7 MiB)
虚拟路由,SSVM,CPVM *public*接口将被桥接到主机的物理接口上。在下例中, *cloudbr0*是公共接口,CloudStack将创建虚拟接口桥。这个虚拟接口到物理接口映射式CloudStack用设置在域中的流量标签自动设置的。如果你提供争取的设置,但仍不能在网络上工作,在下一步调试前检查下交换层的设备。你可以在虚拟,物理和桥设备上使用tcpdump证实流量。
kvm-host1 ~$ brctl show
bridge name bridge id STP enabled interfaces
breth0-64 8000.000c29ef7d78 no eth0.64
vnet2
cloud0 8000.fe00a9fe0219 no vnet0
cloudbr0 8000.000c29ef7d78 no eth0
vnet1
vnet3
virbr0 8000.5254008e321a yes virbr0-nic
xenserver1 ~$ brctl show
bridge name bridge id STP enabled interfaces
xapi0 0000.e2b76d0a1149 no vif1.0
xenbr0 0000.000c299b54dc no eth0
xapi1
vif1.1
vif1.2
在XenServer上预先创建标签。类似于KVM桥启动,流量标签必须在加入CloudStack的XenServer主机上提前创建。
xenserver1 ~$ xe network-list
uuid ( RO) : aaa-bbb-ccc-ddd
name-label ( RW): MGMT
name-description ( RW):
bridge ( RO): xenbr0
网络将会从SSVM和CPVM实例上默认获取。它们的公共IP也将会直接由网络ping通。请注意一下这些测试仅在交换机或者流量标签已被成功配置在你的环境中实现。如果你的 SSVM/CPVM可以连接到Internet, 它非常不同于虚拟路由器(VR)也可以连接到Internet,建议可能是交换时的问题或者是错误分配了流量标签。确定SSVM/CPVM的问题前请先调试VR问题。
root@s-1-VM:~# ping -c 3 google.com
PING google.com (74.125.236.164): 56 data bytes
64 bytes from 74.125.236.164: icmp_seq=0 ttl=55 time=26.932 ms
64 bytes from 74.125.236.164: icmp_seq=1 ttl=55 time=29.156 ms
64 bytes from 74.125.236.164: icmp_seq=2 ttl=55 time=25.000 ms
--- google.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 25.000/27.029/29.156/1.698 ms
root@v-2-VM:~# ping -c 3 google.com
PING google.com (74.125.236.164): 56 data bytes
64 bytes from 74.125.236.164: icmp_seq=0 ttl=55 time=32.125 ms
64 bytes from 74.125.236.164: icmp_seq=1 ttl=55 time=26.324 ms
64 bytes from 74.125.236.164: icmp_seq=2 ttl=55 time=37.001 ms
--- google.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 26.324/31.817/37.001/4.364 ms
除非有些Egress规则,Virtual Router(VR)也是不能到达Internet。Egress规则仅控制VR自身的通讯与否。
root@r-4-VM:~# ping -c 3 google.com
PING google.com (74.125.236.164): 56 data bytes
64 bytes from 74.125.236.164: icmp_seq=0 ttl=55 time=28.098 ms
64 bytes from 74.125.236.164: icmp_seq=1 ttl=55 time=34.785 ms
64 bytes from 74.125.236.164: icmp_seq=2 ttl=55 time=69.179 ms
--- google.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 28.098/44.021/69.179/17.998 ms
尽管如此,Virtual Router(VR) Source NAT Pulic IP地址除非有近似的Ingress规则在此,要么**WONT** 达到。你可以添加 Ingress rules under Network, Guest Network, IP Address, Firewall 设置页。
默认的VM Instances不能够连接Internet。添加Egress规则后可允许连接。
一些用户报告在SSVM,CPVM或者是Vir Router刷新IPTables规则(或改变路由)可以使Internet工作。这不是系统期望的行为并建议这样的网络设置是错误的。SSVM,CPVM或者是VR上没有要求IPtables/route改变。回去重新检查你所有的设置吧。
在海量的实例中,问题会出现在交换层,原因是L3的配置错误.
这些内容有Shanker Balan贡献,其原文发布在`Shapeblue’博客中<http://shankerbalan.net/blog/internet-not-working-on-cloudstack-vms/>`_