警告

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

CloudStack代理服务器在 `/var/log/cloudstack/agent/`记录了它的活动。

在导出主存储时的数据丢失

症状

主存储的已有数据丢失。该主存储是用iSCSI卷导出的一个Linux NFS服务器输出。

原因

可能的原因是存储池之外的某个客户端挂载了该存储。如果发生了这种情况,LVM会被擦除,该卷上的所有数据都会丢失。

解决方案

配置LUN输出时,通过指定子网掩码来限制可以访问存储的IP地址范围。例如:

echo “/export 192.168.1.0/24(rw,async,no_root_squash,no_subtree_check)” > /etc/exports

根据你的部署需求,调整如上参数。

更多信息

请参考CloudStack安装指南的“辅助存储”章节中的导出过程。

恢复丢失的虚拟路由器

症状

虚拟路由器是运行着的,但主机失去连接。虚拟路由器不再按期望工作。

原因

虚拟路由器丢失或宕机。

解决方案

如果您确定虚拟路由器宕机了,或不再正常工作,请销毁它。您必须再建一个新的,此时备份路由器应保持运行(假定在使用冗余路由器配置的情况下)。

  • 强制停止虚拟路由器。请使用带参数forced=true的stopRouter API执行该步。
  • 在销毁虚拟路由器之前,请确保备份路由器正常运行。否则用户的网络连接将中断。
  • 使用destroyRouter API销毁该虚拟路由器。

使用restartNetwork API(参数cleanup=false)重建丢失的虚拟路由器。关于冗余虚拟路由器的配置,请参考创建新的网络方案。

关于更多的API语法信息,参见API参考`http://cloudstack.apache.org/docs/api/ <http://cloudstack.apache.org/docs/api/>`_。

维护模式没在vCenter中生效

症状

主机已经置为维护模式,但在vCenter中还是活动的。

原因

CloudStack管理员用户界面使用日程中的主机维护模式。该模式与vCenter的维护模式无关。

解决方案

请使用vCenter将主机置为维护模式。

无法从上传的vSphere模板部署虚拟机

症状

当试图创建一个虚拟机,虚拟机将无法部署。

原因

如果模板通过上传OVA文件创建,而OVA文件是使用vSphere Client创建的,可能OVA中包含ISO镜像。如果是的话,从模板部署虚拟机将失败。

解决方案

移除ISO并重新上传模板。

无法启动VMware的虚机

症状

虚机不能启动。可能出现以下错误:

  • 不能打开交换文件
  • 不能访问文件,因为文件被锁定
  • 不能访问虚机配置

原因

这是VMware机器的已知问题。为防止并发修改,ESX主机会锁定特定的关键虚机文件和文件系统。有时,虚机关机时没有解锁这些文件。当虚机再次开机时,由于不能访问这些关键文件,虚机就不能启动。

解决方案

参见:

VMware Knowledge Base Article

改变网络方案后负载均衡规则失效

症状

修改网络的网络方案后,负载均衡规则不再生效。

原因

负载均衡规则创建时使用的是包含外部负载均衡器,例如NetScaler的网络方案,后来改为使用CloudStack虚拟路由器的网络方案。

解决方案

针对每条已有的负载均衡规则,在虚拟路由器上创建相同的防火墙规则,以便规则继续生效。

故障排查网络传输

在下列故障排查步骤中检验你网络中出现的故障…

故障排查步骤

  1. 交换机上可以完成正确的配置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网络将无法工作,所以在处理下一部前要确定物理网络设备的问题。

  2. 确保 流量标签 已经设置在域中。

    流量标签需要在包括XenServer,KVM和VMwarel在内的所有类型的hypervisors设置。当你从*Add Zone Wizard*创建一个域时,你可以配置流量标签。

    _images/networking-zone-traffic-labels.png

    在一个已经存在的域总,你可以通过*Add Zone Wizard*修改流量标签。

    _images/networking-infra-traffic-labels.png

    列出正在使用的*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
    =========================================================
    
  3. 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)
    
  4. 虚拟路由,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
    
  5. 在XenServer上预先创建标签。类似于KVM桥启动,流量标签必须在加入CloudStack的XenServer主机上提前创建。

    xenserver1 ~$ xe network-list
    uuid ( RO)                : aaa-bbb-ccc-ddd
              name-label ( RW): MGMT
        name-description ( RW):
                  bridge ( RO): xenbr0
    
  6. 网络将会从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
    
  7. 除非有些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
    
  8. 尽管如此,Virtual Router(VR) Source NAT Pulic IP地址除非有近似的Ingress规则在此,要么**WONT** 达到。你可以添加 Ingress rules under Network, Guest Network, IP Address, Firewall 设置页。

    _images/networking-ingress-rule.png
  9. 默认的VM Instances不能够连接Internet。添加Egress规则后可允许连接。

    _images/networking-egress-rule.png
  10. 一些用户报告在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/>`_