source/adminguide/locale/zh_CN/LC_MESSAGES/troubleshooting.mo (15 lines of code) (raw):
�� D < \ \ Y ] l � 7 $ S \ � � U : � ~ � % 2 ; � n � R � G � � G
* � 4 � � � �
� p � � 8 � � � p � ' N v i � � q � � / � P * ` - � � T � � P X � y �
d � � O H # � � � � } � %! �! �! " . $" * S" 3 ~" �" , �" 2 �" = +# 7 i# � �# � P$ �$ � �$ � s% H' ` Q( 0 �( B �( o &) B �) �) { �) $ \* 2 �* � �* � \+ [ �+ C >, � �, � _- � <. � �. Q �/ � 0 F �0 " �1 - 2 � =2 e �2 " G3 j3 Z w3 �3 �3 V �3 � S4 �4 � �4 ! �5 O �5 6 6 ! 6 A7 Q H7 �7 q �8 � $9 � : V �; y < � �< ! Z> � |> � #? � �? e@ x@ �@ �@ * �@ . �@ A *A . FA 0 uA < �A � �A e hB �B � �B A known issue on VMware machines. ESX hosts lock certain critical virtual machine files and file systems to prevent concurrent changes. Sometimes the files are not unlocked when the virtual machine is powered off. When a virtual machine attempts to power on, it can not access these critical files, and the virtual machine is unable to power on. A virtual router is running, but the host is disconnected. A virtual router no longer functions as expected. Adjust the above command to suit your deployment needs. After changing the network offering on a network, load balancer rules stop working. Before you continue with destroying this router, ensure that the backup router is running. Otherwise the network connection will be lost. Below are a few troubleshooting steps to check whats going wrong with your network... Cause Create a firewall rule on the virtual router for each of your existing load balancing rules so that they continue to function. Data Loss on Exported Primary Storage Destroy the router by using the destroyRouter API. Ensure `Traffic Labels <http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html/Installation_Guide/about-physical-networks.html>`_ are set for the Zone. For more information about the API syntax, see the API Reference at `https://cloudstack.apache.org/api.html <https://cloudstack.apache.org/api.html>`_. Force stop the router. Use the stopRouter API with forced=true parameter to do so. Host was placed in maintenance mode, but still appears live in vCenter. However, the Virtual Router's (VR) Source NAT Public IP address **WONT** be reachable until appropriate Ingress rules are in place. You can add *Ingress* rules under *Network, Guest Network, IP Address, Firewall* setting page. If the pings dont work, run *tcpdump(8)* all over the place to check who is gobbling up the packets. Ultimately, if the switches are not configured correctly, CloudStack networking wont work so fix the physical networking issues before you proceed to the next steps If the template was created by uploading an OVA file that was created using vSphere Client, it is possible the OVA contained an ISO image. If it does, the deployment of VMs from the template will fail. If you are sure that a virtual router is down forever, or no longer functions as expected, destroy it. You must create one afresh while keeping the backup router up and running (it is assumed this is in a redundant router setup): In a vast majority of the cases, the problem has turned out to be at the switching layer where the L3 switches were configured incorrectly. It is possible that a client from outside the intended pool has mounted the storage. When this occurs, the LVM is wiped and all data in the volume is lost KVM traffic labels require to be named as *"cloudbr0"*, *"cloudbr2"*, *"cloudbrN"* etc and the corresponding bridge must exist on the KVM hosts. If you create labels/bridges with any other names, CloudStack (atleast earlier versions did) seems to ignore them. CloudStack does not create the physical bridges on the KVM hosts, you need to create them **before** before adding the host to Cloudstack. List labels using *CloudMonkey* Load balancer rules fail after changing network offering Load balancing rules were created while using a network service offering that includes an external load balancer device such as NetScaler, and later the network service offering changed to one that uses the CloudStack virtual router. Loss of existing data on primary storage which has been exposed as a Linux NFS server export on an iSCSI volume. Maintenance mode not working on vCenter More Information Note that the job ID is 1076. You can track back the events relating to job 1076 with the following grep: On *host1 (kvm1)* On *host2 (kvm2)* On an existing zone, you can modify the traffic labels by going to *Infrastructure, Zones, Physical Network* tab. Pre-create labels on the XenServer Hosts. Similar to KVM bridge setup, traffic labels must also be pre-created on the XenServer hosts before adding them to CloudStack. Recovering a Lost Virtual Router Recreate the missing router by using the restartNetwork API with cleanup=false parameter. For more information about redundant router setup, see Creating a New Network Offering. Remove the ISO and re-upload the template. See the export procedure in the "Secondary Storage" section of the CloudStack Installation Guide See the following: Solution Some users have reported that flushing IPTables rules (or changing routes) on the SSVM, CPVM or the Virtual Router makes the Internet work. This is not expected behaviour and suggests that your networking settings are incorrect. No IPtables/route changes are required on the SSVM, CPVM or the VR. Go back and double check all your settings. Symptom The CloudStack Agent Server logs its activities in `/var/log/cloudstack/agent/`. The CloudStack Management Server logs all web site, middle tier, and database activities for diagnostics purposes in `/var/log/cloudstack/management/`. The CloudStack logs a variety of error messages. We recommend this command to find the problematic output in the Management Server log:. The CloudStack administrator UI was used to place the host in scheduled maintenance mode. This mode is separate from vCenter's maintenance mode. The CloudStack processes requests with a Job ID. If you find an error in the logs and you are interested in debugging the issue you can grep for this job ID in the management server log. For example, suppose that you find the following ERROR message: The Internet would be accessible from both the SSVM and CPVM instances by default. Their public IPs will also be directly pingable from the Internet. Please note that these test would work only if your switches and traffic labels are configured correctly for your environment. If your SSVM/CPVM cant reach the Internet, its very unlikely that the Virtual Router (VR) can also the reach the Internet suggesting that its either a switching issue or incorrectly assigned traffic labels. Fix the SSVM/CPVM issues before you debug VR issues. The VM Instances by default wont be able to access the Internet. Add Egress rules to permit traffic. The Virtual Router (VR) should also be able to reach the Internet without having any Egress rules. The Egress rules only control forwarded traffic and not traffic that originates on the VR itself. The Virtual Router, SSVM, CPVM *public* interface would be bridged to a physical interface on the host. In the example below, *cloudbr0* is the public interface and CloudStack has correctly created the virtual interfaces bridge. This virtual interface to physical interface mapping is done automatically by CloudStack using the traffic label settings for the Zone. If you have provided correct settings and still dont have a working working Internet, check the switching layer before you debug any further. You can verify traffic using tcpdump on the virtual, physical and bridge interfaces. The Virtual router is lost or down. The switches have to be configured correctly to pass VLAN traffic. You can verify if VLAN traffic is working by bringing up a tagged interface on the hosts and pinging between them as below... This section was contibuted by Shanker Balan and was originally published on `Shapeblue's blog <http://shankerbalan.net/blog/internet-not-working-on-cloudstack-vms/>`_ Traffic labels need to be set for all hypervisors including XenServer, KVM and VMware types. You can configure traffic labels when you creating a new zone from the *Add Zone Wizard*. Trouble Shooting Steps TroubleShooting Troubleshooting Internet Traffic Unable to access Virtual machine configuration Unable to access a file since it is locked Unable to deploy VMs from uploaded vSphere template Unable to open Swap File Unable to power on virtual machine on VMware Use vCenter to place the host in maintenance mode. Virtual machine does not power on. You might see errors like: When attempting to create a VM, the VM will not deploy. When copying and pasting a command, be sure the command has pasted as a single line before executing. Some document viewers may introduce unwanted line breaks in copied text. When setting up LUN exports, restrict the range of IP addresses that are allowed access by specifying a subnet mask. For example: Working with Server Logs `VMware Knowledge Base Article <http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=10051/>`_ Project-Id-Version: Apache CloudStack Administration RTD
Report-Msgid-Bugs-To:
POT-Creation-Date: 2014-06-30 12:52+0200
PO-Revision-Date: 2014-06-30 12:04+0000
Last-Translator: FULL NAME <EMAIL@ADDRESS>
Language-Team: Chinese (China) (http://www.transifex.com/projects/p/apache-cloudstack-administration-rtd/language/zh_CN/)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Language: zh_CN
Plural-Forms: nplurals=1; plural=0;
这是VMware机器的已知问题。为防止并发修改，ESX主机会锁定特定的关键虚机文件和文件系统。有时，虚机关机时没有解锁这些文件。当虚机再次开机时，由于不能访问这些关键文件，虚机就不能启动。 虚拟路由器是运行着的，但主机失去连接。虚拟路由器不再按期望工作。 根据你的部署需求，调整如上参数。 修改网络的网络方案后，负载均衡规则不再生效。 在销毁虚拟路由器之前，请确保备份路由器正常运行。否则用户的网络连接将中断。 在下列故障排查步骤中检验你网络中出现的故障... 原因 针对每条已有的负载均衡规则，在虚拟路由器上创建相同的防火墙规则，以便规则继续生效。 在导出主存储时的数据丢失 使用destroyRouter API销毁该虚拟路由器。 确保 `流量标签 <http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html/Installation_Guide/about-physical-networks.html>`_ 已经设置在域中。 关于更多的API语法信息，参见API参考`https://cloudstack.apache.org/api.html <https://cloudstack.apache.org/api.html>`_。 强制停止虚拟路由器。请使用带参数forced=true的stopRouter API执行该步。 主机已经置为维护模式，但在vCenter中还是活动的。 尽管如此，Virtual Router(VR) Source NAT Pulic IP地址除非有近似的Ingress规则在此，要么**WONT** 达到。你可以添加 *Ingress* rules under *Network, Guest Network, IP Address, Firewall* 设置页。 如果ping不通，运行 *tcpdump(8)*在所有VLAN上检查丢失的数据包。最终，如果交换机配置失败，CloudStack网络将无法工作，所以在处理下一部前要确定物理网络设备的问题。 如果模板通过上传OVA文件创建，而OVA文件是使用vSphere Client创建的，可能OVA中包含ISO镜像。如果是的话，从模板部署虚拟机将失败。 如果您确定虚拟路由器宕机了，或不再正常工作，请销毁它。您必须再建一个新的，此时备份路由器应保持运行(假定在使用冗余路由器配置的情况下)。 在海量的实例中，问题会出现在交换层，原因是L3的配置错误. 可能的原因是存储池之外的某个客户端挂载了该存储。如果发生了这种情况，LVM会被擦除，该卷上的所有数据都会丢失。 KVM流量标签要求被命名为*"cloudbr0"*, *"cloudbr2"*, *"cloudbrN"* 等而且响应桥必须在KVM主机上。如果你以其他名字命名标记/桥，CloudStack(至少是较早版本)将会忽略它。CloudStack不能再KVM主机上创建物理桥，你需要在向CloudStackt添加主机前 **before**创建它们。 列出正在使用的*CloudMonkey* 改变网络方案后负载均衡规则失效 负载均衡规则创建时使用的是包含外部负载均衡器，例如NetScaler的网络方案，后来改为使用CloudStack虚拟路由器的网络方案。 主存储的已有数据丢失。该主存储是用iSCSI卷导出的一个Linux NFS服务器输出。 维护模式没在vCenter中生效 更多信息 注意到任务ID是1076。你可以追踪返回事件的相近任务1076按照以下grep: 在*host1 (kvm1)*上 在*host2 (kvm2)*上 在一个已经存在的域总，你可以通过*Add Zone Wizard*修改流量标签。 在XenServer上预先创建标签。类似于KVM桥启动，流量标签必须在加入CloudStack的XenServer主机上提前创建。 恢复丢失的虚拟路由器 使用restartNetwork API（参数cleanup=false）重建丢失的虚拟路由器。关于冗余虚拟路由器的配置，请参考创建新的网络方案。 移除ISO并重新上传模板。 请参考CloudStack安装指南的“辅助存储”章节中的导出过程。 参见： 解决方案 一些用户报告在SSVM，CPVM或者是Vir Router刷新IPTables规则(或改变路由)可以使Internet工作。这不是系统期望的行为并建议这样的网络设置是错误的。SSVM,CPVM或者是VR上没有要求IPtables/route改变。回去重新检查你所有的设置吧。 症状 CloudStack代理服务器在 `/var/log/cloudstack/agent/`记录了它的活动。 为了方便诊断系统，CloudStack 管理服务器在目录/var/log/cloud/management/下记录了所有网站、中间层和数据库的活动。CloudStack 会记录各种出错信息。我们推荐使用下述命令从管理服务器日志中寻找有问题的输出日志： CloudStack管理员用户界面使用日程中的主机维护模式。该模式与vCenter的维护模式无关。 CloudStack处理请求时会生成一个任务ID。如果您发现了日志中的某个错误，然后想调试该问题，您可以在管理服务器日志中grep这个任务ID。例如，假设您发现了以下的ERROR信息： 网络将会从SSVM和CPVM实例上默认获取。它们的公共IP也将会直接由网络ping通。请注意一下这些测试仅在交换机或者流量标签已被成功配置在你的环境中实现。如果你的 SSVM/CPVM可以连接到Internet, 它非常不同于虚拟路由器(VR)也可以连接到Internet,建议可能是交换时的问题或者是错误分配了流量标签。确定SSVM/CPVM的问题前请先调试VR问题。 默认的VM Instances不能够连接Internet。添加Egress规则后可允许连接。 除非有些Egress规则，Virtual Router(VR)也是不能到达Internet。Egress规则仅控制VR自身的通讯与否。 虚拟路由，SSVM,CPVM *public*接口将被桥接到主机的物理接口上。在下例中， *cloudbr0*是公共接口，CloudStack将创建虚拟接口桥。这个虚拟接口到物理接口映射式CloudStack用设置在域中的流量标签自动设置的。如果你提供争取的设置，但仍不能在网络上工作，在下一步调试前检查下交换层的设备。你可以在虚拟，物理和桥设备上使用tcpdump证实流量。 虚拟路由器丢失或宕机。 交换机上可以完成正确的配置VLAN通信。你可以辨别主机上的VLAN是否通讯通过提出标记接口，并在上述两个VLAN中使用ping命令。 这些内容有Shanker Balan贡献，其原文发布在`Shapeblue'博客中<http://shankerbalan.net/blog/internet-not-working-on-cloudstack-vms/>`_ 流量标签需要在包括XenServer，KVM和VMwarel在内的所有类型的hypervisors设置。当你从*Add Zone Wizard*创建一个域时，你可以配置流量标签。 故障排查步骤 故障排查 故障排查网络传输 不能访问虚机配置 不能访问文件，因为文件被锁定 无法从上传的vSphere模板部署虚拟机 不能打开交换文件 无法启动VMware的虚机 请使用vCenter将主机置为维护模式。 虚机不能启动。可能出现以下错误： 当试图创建一个虚拟机，虚拟机将无法部署。 当复制和粘贴命令时，请确保没有多余的换行符，因为一些文档查看器可能会在复制时加上换行符。 配置LUN输出时，通过指定子网掩码来限制可以访问存储的IP地址范围。例如： 使用服务器日志 `VMware Knowledge Base Article <http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=10051/>`_