source/locale/pot/troubleshooting.pot - cloudstack-docs-admin - Git at Google

 # SOME DESCRIPTIVE TITLE.
 # Copyright (C)
 # This file is distributed under the same license as the Apache CloudStack Administration Documentation package.
 # FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
 #
 #, fuzzy
 msgid ""
 msgstr ""
 "Project-Id-Version: Apache CloudStack Administration Documentation 4\n"
 "Report-Msgid-Bugs-To: \n"
 "POT-Creation-Date: 2014-03-31 14:08-0400\n"
 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
 "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
 "Language-Team: LANGUAGE <LL@li.org>\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"

 #: ../../troubleshooting.rst:17
 # e8bd92e93dac45f788464ab1963b20e7
 msgid "TroubleShooting"
 msgstr ""

 #: ../../troubleshooting.rst:20
 # 55d6cf3cc73d4ef5a617636942890a97
 msgid "Working with Server Logs"
 msgstr ""

 #: ../../troubleshooting.rst:22
 # 493b26a59c724cb0b4753cf2de7729c6
 msgid "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:."
 msgstr ""

 #: ../../troubleshooting.rst:29
 # e9110df374044f87990151358476d4c4
 msgid "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."
 msgstr ""

 #: ../../troubleshooting.rst:37
 # 0650dd8f9e3042b6a0023c284e9700af
 msgid "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:"
 msgstr ""

 #: ../../troubleshooting.rst:46
 # 8311990224b84dd0b3faf4084d527b4f
 msgid "Note that the job ID is 1076. You can track back the events relating to job 1076 with the following grep:"
 msgstr ""

 #: ../../troubleshooting.rst:53
 # e3ffc3e9a91f4bbd92acf9a582aa4f09
 msgid "The CloudStack Agent Server logs its activities in `/var/log/cloudstack/agent/`."
 msgstr ""

 #: ../../troubleshooting.rst:57
 # 2e3bac54e6a44e7a916a10b1a72ae7b8
 msgid "Data Loss on Exported Primary Storage"
 msgstr ""

 #: ../../troubleshooting.rst:60
 #: ../../troubleshooting.rst:94
 #: ../../troubleshooting.rst:138
 #: ../../troubleshooting.rst:158
 #: ../../troubleshooting.rst:178
 #: ../../troubleshooting.rst:215
 # 17772f3eaf854986935381edba6a08f4
 # a36bc3bf835b43ceb89eb0502f49427f
 # 5b32c5e122f34a7390b04dc584d7d8b1
 # 8c990e9835c843e0ba8e6389024c9da7
 # c07d93b58e73413caee9927f2f377a4c
 # 0210bf5ba6124daab904e885ec47d2c3
 msgid "Symptom"
 msgstr ""

 #: ../../troubleshooting.rst:62
 # b8c4b40af3fd4552bdc54740a5a0fd39
 msgid "Loss of existing data on primary storage which has been exposed as a Linux NFS server export on an iSCSI volume."
 msgstr ""

 #: ../../troubleshooting.rst:66
 #: ../../troubleshooting.rst:100
 #: ../../troubleshooting.rst:143
 #: ../../troubleshooting.rst:163
 #: ../../troubleshooting.rst:195
 #: ../../troubleshooting.rst:221
 # c0c2bc4870e74609a67d1aed2af2b411
 # 989912d8a32b45e8a4bd2c54b5a97647
 # 1b80c032e2184fad85a5b5d2321b104a
 # b3c2f63d649b4d4dbb78fe05f3e2f087
 # aa3a404aa32c48bbb850fca268ee4ac9
 # 57820682c7c44dc0b9429c160629a1eb
 msgid "Cause"
 msgstr ""

 #: ../../troubleshooting.rst:68
 # ea41406a62e9453a82d56cf6ddeb6106
 msgid "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"
 msgstr ""

 #: ../../troubleshooting.rst:73
 #: ../../troubleshooting.rst:105
 #: ../../troubleshooting.rst:149
 #: ../../troubleshooting.rst:170
 #: ../../troubleshooting.rst:204
 #: ../../troubleshooting.rst:229
 # f0ac12571f8b418ea67f8c179e9588d9
 # f84f95c1a8d549ed861a92e77654701f
 # 520bb677c65d4e4181f06db8804f56f0
 # 34a989bf06a745339a0202448dfa05be
 # a5d809d99a0f49cdbe7d4430121a264c
 # 2b638ad3018740ebb634edfd14737f06
 msgid "Solution"
 msgstr ""

 #: ../../troubleshooting.rst:75
 # 4e51a9c86fae49d7a0d2e695914263a2
 msgid "When setting up LUN exports, restrict the range of IP addresses that are allowed access by specifying a subnet mask. For example:"
 msgstr ""

 #: ../../troubleshooting.rst:82
 # 568eeac2135a4012ab60259769577431
 msgid "Adjust the above command to suit your deployment needs."
 msgstr ""

 #: ../../troubleshooting.rst:85
 # d4fee5a097ac450381983de58d22c6e9
 msgid "More Information"
 msgstr ""

 #: ../../troubleshooting.rst:87
 # 415506db5609428e9f0558889286845c
 msgid "See the export procedure in the \"Secondary Storage\" section of the CloudStack Installation Guide"
 msgstr ""

 #: ../../troubleshooting.rst:91
 # bc6b86b9b20744fa952c68c30ec06a25
 msgid "Recovering a Lost Virtual Router"
 msgstr ""

 #: ../../troubleshooting.rst:96
 # e1bedbd70a194eea9bcb6f65d3f50c4c
 msgid "A virtual router is running, but the host is disconnected. A virtual router no longer functions as expected."
 msgstr ""

 #: ../../troubleshooting.rst:102
 # 08893bf84e644b23a7e0c804ca534073
 msgid "The Virtual router is lost or down."
 msgstr ""

 #: ../../troubleshooting.rst:107
 # deaff49a430e473684632d83aedc2d39
 msgid "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):"
 msgstr ""

 #: ../../troubleshooting.rst:114
 # 263660e8d5c948cc90b7b071927c461c
 msgid "Force stop the router. Use the stopRouter API with forced=true parameter to do so."
 msgstr ""

 #: ../../troubleshooting.rst:119
 # a8c0f38a546c4ff7bee2db37d149b15c
 msgid "Before you continue with destroying this router, ensure that the backup router is running. Otherwise the network connection will be lost."
 msgstr ""

 #: ../../troubleshooting.rst:125
 # af2a90eee3694d938aa01933f42ba89b
 msgid "Destroy the router by using the destroyRouter API."
 msgstr ""

 #: ../../troubleshooting.rst:127
 # 9089ab21bdab4b03b6f2dcc47cebf9bc
 msgid "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."
 msgstr ""

 #: ../../troubleshooting.rst:131
 # a434f77186074258ad0e39e2ff0db759
 msgid "For more information about the API syntax, see the API Reference at `http://cloudstack.apache.org/docs/api/ <http://cloudstack.apache.org/docs/api/>`_."
 msgstr ""

 #: ../../troubleshooting.rst:135
 # eae25ddc68984cdf8cb3f8f596561d2a
 msgid "Maintenance mode not working on vCenter"
 msgstr ""

 #: ../../troubleshooting.rst:140
 # b72eae733c17444ba5a514ecb6b09fa5
 msgid "Host was placed in maintenance mode, but still appears live in vCenter."
 msgstr ""

 #: ../../troubleshooting.rst:145
 # fbf7e8fb0dd64ce1a2017a533e13295e
 msgid "The CloudStack administrator UI was used to place the host in scheduled maintenance mode. This mode is separate from vCenter's maintenance mode."
 msgstr ""

 #: ../../troubleshooting.rst:151
 # 7ab1f606082f4ed2a25670e6c57fc031
 msgid "Use vCenter to place the host in maintenance mode."
 msgstr ""

 #: ../../troubleshooting.rst:155
 # 1311ca0126c0430a9dd150a744645cdc
 msgid "Unable to deploy VMs from uploaded vSphere template"
 msgstr ""

 #: ../../troubleshooting.rst:160
 # 025f901918574e87add36be30ea7798f
 msgid "When attempting to create a VM, the VM will not deploy."
 msgstr ""

 #: ../../troubleshooting.rst:165
 # 07f8edc978564e228b5b8b83d7435203
 msgid "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."
 msgstr ""

 #: ../../troubleshooting.rst:172
 # e0782e40719a4fcaa6ceb63e014b5b83
 msgid "Remove the ISO and re-upload the template."
 msgstr ""

 #: ../../troubleshooting.rst:175
 # 35ac51f5ddaf48a793878e40c33977b9
 msgid "Unable to power on virtual machine on VMware"
 msgstr ""

 #: ../../troubleshooting.rst:180
 # 42400d62c2e14b4d9ad3abb86261cc42
 msgid "Virtual machine does not power on. You might see errors like:"
 msgstr ""

 #: ../../troubleshooting.rst:184
 # 87c7076aa51441eda4d24256adff07b5
 msgid "Unable to open Swap File"
 msgstr ""

 #: ../../troubleshooting.rst:188
 # 0cf604246d19441aba6cae448684bbf4
 msgid "Unable to access a file since it is locked"
 msgstr ""

 #: ../../troubleshooting.rst:192
 # d18757cf00914c3ca874b46461d59d4a
 msgid "Unable to access Virtual machine configuration"
 msgstr ""

 #: ../../troubleshooting.rst:197
 # 86aaef84a5ce401ba596471a5d992fa7
 msgid "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."
 msgstr ""

 #: ../../troubleshooting.rst:206
 # 2a6626575cfa4e8d9051adef52800493
 msgid "See the following:"
 msgstr ""

 #: ../../troubleshooting.rst:208
 # 5f72ef4ab29d49aabf6254dadff2157f
 msgid "`VMware Knowledge Base Article <http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=10051/>`_"
 msgstr ""

 #: ../../troubleshooting.rst:212
 # c0e9e61553884ca791e3221a8b15478b
 msgid "Load balancer rules fail after changing network offering"
 msgstr ""

 #: ../../troubleshooting.rst:217
 # 54be70ae479746b099f16a975e6b313e
 msgid "After changing the network offering on a network, load balancer rules stop working."
 msgstr ""

 #: ../../troubleshooting.rst:223
 # 8859286ab9d946d5afc087a41d70f300
 msgid "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."
 msgstr ""

 #: ../../troubleshooting.rst:231
 # c745ba81f8c64e42ad0d937ae17224cd
 msgid "Create a firewall rule on the virtual router for each of your existing load balancing rules so that they continue to function."
 msgstr ""

 #: ../../troubleshooting.rst:235
 # 59274eeb4f9c42eab20167cb78fcfcec
 msgid "Troubleshooting Internet Traffic"
 msgstr ""

 #: ../../troubleshooting.rst:237
 # 8b0eac2ff7a14b528639484afb576723
 msgid "Below are a few troubleshooting steps to check whats going wrong with your network..."
 msgstr ""

 #: ../../troubleshooting.rst:241
 # f27e96f760da43158895e31cefe0d354
 msgid "Trouble Shooting Steps"
 msgstr ""

 #: ../../troubleshooting.rst:243
 # 5b3da7b6d48a45ccaab81ec2fefb9b72
 msgid "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..."
 msgstr ""

 #: ../../troubleshooting.rst:247
 # ebc26236b36141e2ad5ea9414f0eefc4
 msgid "On *host1 (kvm1)*"
 msgstr ""

 #: ../../troubleshooting.rst:255
 # 1466a71fb13c4e8d9d6885ac3c9a46ea
 msgid "On *host2 (kvm2)*"
 msgstr ""

 #: ../../troubleshooting.rst:263
 # e3a67b52cabd4480b54de5ad3c79f6b5
 msgid "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"
 msgstr ""

 #: ../../troubleshooting.rst:268
 # ce37e4e95d564397b90ff5aef4baa80d
 msgid "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."
 msgstr ""

 #: ../../troubleshooting.rst:270
 # 6be4c1c298e3442c8353ba69a623d6d9
 msgid "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*."
 msgstr ""

 #: ../../troubleshooting.rst:276
 # f1555452ac5a4341a628cf84d907af13
 msgid "On an existing zone, you can modify the traffic labels by going to *Infrastructure, Zones, Physical Network* tab."
 msgstr ""

 #: ../../troubleshooting.rst:281
 # 344079c7f4e54f748b8d4b63b1be58d4
 msgid "List labels using *CloudMonkey*"
 msgstr ""

 #: ../../troubleshooting.rst:313
 # 5426cbca012c4e0ba7d7afa01f49719e
 msgid "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."
 msgstr ""

 #: ../../troubleshooting.rst:332
 # 4892fd19e0e14fc39b02e7c7dddb8f2b
 msgid "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."
 msgstr ""

 #: ../../troubleshooting.rst:364
 # a87950c34d404d9ba5426109cc68a1cc
 msgid "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."
 msgstr ""

 #: ../../troubleshooting.rst:377
 # 59c18293d72e465580db2a7b77faebcc
 msgid "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."
 msgstr ""

 #: ../../troubleshooting.rst:409
 # c4cfab36727849f1a4ca325b9a43eaf9
 msgid "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."
 msgstr ""

 #: ../../troubleshooting.rst:424
 # f7afcd661a50477fb5a663ebab387610
 msgid "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."
 msgstr ""

 #: ../../troubleshooting.rst:431
 # ad40b8f845bf4c679b118fa88838fc44
 msgid "The VM Instances by default wont be able to access the Internet. Add Egress rules to permit traffic."
 msgstr ""

 #: ../../troubleshooting.rst:436
 # 8f93a9ea7cec42038a0511d2d00b1b9c
 msgid "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."
 msgstr ""

 #: ../../troubleshooting.rst:443
 # 5b0ed7e9c0584d40aa39fb35184e6122
 msgid "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."
 msgstr ""

 #: ../../troubleshooting.rst:446
 # 264a011e35404961978190f2eebf50e0
 msgid "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/>`_"
 msgstr ""
	# SOME DESCRIPTIVE TITLE.
	# Copyright (C)
	# This file is distributed under the same license as the Apache CloudStack Administration Documentation package.
	# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
	#
	#, fuzzy
	msgid ""
	msgstr ""
	"Project-Id-Version: Apache CloudStack Administration Documentation 4\n"
	"Report-Msgid-Bugs-To: \n"
	"POT-Creation-Date: 2014-03-31 14:08-0400\n"
	"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
	"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
	"Language-Team: LANGUAGE <LL@li.org>\n"
	"MIME-Version: 1.0\n"
	"Content-Type: text/plain; charset=UTF-8\n"
	"Content-Transfer-Encoding: 8bit\n"

	#: ../../troubleshooting.rst:17
	# e8bd92e93dac45f788464ab1963b20e7
	msgid "TroubleShooting"
	msgstr ""

	#: ../../troubleshooting.rst:20
	# 55d6cf3cc73d4ef5a617636942890a97
	msgid "Working with Server Logs"
	msgstr ""

	#: ../../troubleshooting.rst:22
	# 493b26a59c724cb0b4753cf2de7729c6
	msgid "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:."
	msgstr ""

	#: ../../troubleshooting.rst:29
	# e9110df374044f87990151358476d4c4
	msgid "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."
	msgstr ""

	#: ../../troubleshooting.rst:37
	# 0650dd8f9e3042b6a0023c284e9700af
	msgid "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:"
	msgstr ""

	#: ../../troubleshooting.rst:46
	# 8311990224b84dd0b3faf4084d527b4f
	msgid "Note that the job ID is 1076. You can track back the events relating to job 1076 with the following grep:"
	msgstr ""

	#: ../../troubleshooting.rst:53
	# e3ffc3e9a91f4bbd92acf9a582aa4f09
	msgid "The CloudStack Agent Server logs its activities in `/var/log/cloudstack/agent/`."
	msgstr ""

	#: ../../troubleshooting.rst:57
	# 2e3bac54e6a44e7a916a10b1a72ae7b8
	msgid "Data Loss on Exported Primary Storage"
	msgstr ""

	#: ../../troubleshooting.rst:60
	#: ../../troubleshooting.rst:94
	#: ../../troubleshooting.rst:138
	#: ../../troubleshooting.rst:158
	#: ../../troubleshooting.rst:178
	#: ../../troubleshooting.rst:215
	# 17772f3eaf854986935381edba6a08f4
	# a36bc3bf835b43ceb89eb0502f49427f
	# 5b32c5e122f34a7390b04dc584d7d8b1
	# 8c990e9835c843e0ba8e6389024c9da7
	# c07d93b58e73413caee9927f2f377a4c
	# 0210bf5ba6124daab904e885ec47d2c3
	msgid "Symptom"
	msgstr ""

	#: ../../troubleshooting.rst:62
	# b8c4b40af3fd4552bdc54740a5a0fd39
	msgid "Loss of existing data on primary storage which has been exposed as a Linux NFS server export on an iSCSI volume."
	msgstr ""

	#: ../../troubleshooting.rst:66
	#: ../../troubleshooting.rst:100
	#: ../../troubleshooting.rst:143
	#: ../../troubleshooting.rst:163
	#: ../../troubleshooting.rst:195
	#: ../../troubleshooting.rst:221
	# c0c2bc4870e74609a67d1aed2af2b411
	# 989912d8a32b45e8a4bd2c54b5a97647
	# 1b80c032e2184fad85a5b5d2321b104a
	# b3c2f63d649b4d4dbb78fe05f3e2f087
	# aa3a404aa32c48bbb850fca268ee4ac9
	# 57820682c7c44dc0b9429c160629a1eb
	msgid "Cause"
	msgstr ""

	#: ../../troubleshooting.rst:68
	# ea41406a62e9453a82d56cf6ddeb6106
	msgid "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"
	msgstr ""

	#: ../../troubleshooting.rst:73
	#: ../../troubleshooting.rst:105
	#: ../../troubleshooting.rst:149
	#: ../../troubleshooting.rst:170
	#: ../../troubleshooting.rst:204
	#: ../../troubleshooting.rst:229
	# f0ac12571f8b418ea67f8c179e9588d9
	# f84f95c1a8d549ed861a92e77654701f
	# 520bb677c65d4e4181f06db8804f56f0
	# 34a989bf06a745339a0202448dfa05be
	# a5d809d99a0f49cdbe7d4430121a264c
	# 2b638ad3018740ebb634edfd14737f06
	msgid "Solution"
	msgstr ""

	#: ../../troubleshooting.rst:75
	# 4e51a9c86fae49d7a0d2e695914263a2
	msgid "When setting up LUN exports, restrict the range of IP addresses that are allowed access by specifying a subnet mask. For example:"
	msgstr ""

	#: ../../troubleshooting.rst:82
	# 568eeac2135a4012ab60259769577431
	msgid "Adjust the above command to suit your deployment needs."
	msgstr ""

	#: ../../troubleshooting.rst:85
	# d4fee5a097ac450381983de58d22c6e9
	msgid "More Information"
	msgstr ""

	#: ../../troubleshooting.rst:87
	# 415506db5609428e9f0558889286845c
	msgid "See the export procedure in the \"Secondary Storage\" section of the CloudStack Installation Guide"
	msgstr ""

	#: ../../troubleshooting.rst:91
	# bc6b86b9b20744fa952c68c30ec06a25
	msgid "Recovering a Lost Virtual Router"
	msgstr ""

	#: ../../troubleshooting.rst:96
	# e1bedbd70a194eea9bcb6f65d3f50c4c
	msgid "A virtual router is running, but the host is disconnected. A virtual router no longer functions as expected."
	msgstr ""

	#: ../../troubleshooting.rst:102
	# 08893bf84e644b23a7e0c804ca534073
	msgid "The Virtual router is lost or down."
	msgstr ""

	#: ../../troubleshooting.rst:107
	# deaff49a430e473684632d83aedc2d39
	msgid "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):"
	msgstr ""

	#: ../../troubleshooting.rst:114
	# 263660e8d5c948cc90b7b071927c461c
	msgid "Force stop the router. Use the stopRouter API with forced=true parameter to do so."
	msgstr ""

	#: ../../troubleshooting.rst:119
	# a8c0f38a546c4ff7bee2db37d149b15c
	msgid "Before you continue with destroying this router, ensure that the backup router is running. Otherwise the network connection will be lost."
	msgstr ""

	#: ../../troubleshooting.rst:125
	# af2a90eee3694d938aa01933f42ba89b
	msgid "Destroy the router by using the destroyRouter API."
	msgstr ""

	#: ../../troubleshooting.rst:127
	# 9089ab21bdab4b03b6f2dcc47cebf9bc
	msgid "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."
	msgstr ""

	#: ../../troubleshooting.rst:131
	# a434f77186074258ad0e39e2ff0db759
	msgid "For more information about the API syntax, see the API Reference at `http://cloudstack.apache.org/docs/api/ <http://cloudstack.apache.org/docs/api/>`_."
	msgstr ""

	#: ../../troubleshooting.rst:135
	# eae25ddc68984cdf8cb3f8f596561d2a
	msgid "Maintenance mode not working on vCenter"
	msgstr ""

	#: ../../troubleshooting.rst:140
	# b72eae733c17444ba5a514ecb6b09fa5
	msgid "Host was placed in maintenance mode, but still appears live in vCenter."
	msgstr ""

	#: ../../troubleshooting.rst:145
	# fbf7e8fb0dd64ce1a2017a533e13295e
	msgid "The CloudStack administrator UI was used to place the host in scheduled maintenance mode. This mode is separate from vCenter's maintenance mode."
	msgstr ""

	#: ../../troubleshooting.rst:151
	# 7ab1f606082f4ed2a25670e6c57fc031
	msgid "Use vCenter to place the host in maintenance mode."
	msgstr ""

	#: ../../troubleshooting.rst:155
	# 1311ca0126c0430a9dd150a744645cdc
	msgid "Unable to deploy VMs from uploaded vSphere template"
	msgstr ""

	#: ../../troubleshooting.rst:160
	# 025f901918574e87add36be30ea7798f
	msgid "When attempting to create a VM, the VM will not deploy."
	msgstr ""

	#: ../../troubleshooting.rst:165
	# 07f8edc978564e228b5b8b83d7435203
	msgid "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."
	msgstr ""

	#: ../../troubleshooting.rst:172
	# e0782e40719a4fcaa6ceb63e014b5b83
	msgid "Remove the ISO and re-upload the template."
	msgstr ""

	#: ../../troubleshooting.rst:175
	# 35ac51f5ddaf48a793878e40c33977b9
	msgid "Unable to power on virtual machine on VMware"
	msgstr ""

	#: ../../troubleshooting.rst:180
	# 42400d62c2e14b4d9ad3abb86261cc42
	msgid "Virtual machine does not power on. You might see errors like:"
	msgstr ""

	#: ../../troubleshooting.rst:184
	# 87c7076aa51441eda4d24256adff07b5
	msgid "Unable to open Swap File"
	msgstr ""

	#: ../../troubleshooting.rst:188
	# 0cf604246d19441aba6cae448684bbf4
	msgid "Unable to access a file since it is locked"
	msgstr ""

	#: ../../troubleshooting.rst:192
	# d18757cf00914c3ca874b46461d59d4a
	msgid "Unable to access Virtual machine configuration"
	msgstr ""

	#: ../../troubleshooting.rst:197
	# 86aaef84a5ce401ba596471a5d992fa7
	msgid "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."
	msgstr ""

	#: ../../troubleshooting.rst:206
	# 2a6626575cfa4e8d9051adef52800493
	msgid "See the following:"
	msgstr ""

	#: ../../troubleshooting.rst:208
	# 5f72ef4ab29d49aabf6254dadff2157f
	msgid "`VMware Knowledge Base Article <http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=10051/>`_"
	msgstr ""

	#: ../../troubleshooting.rst:212
	# c0e9e61553884ca791e3221a8b15478b
	msgid "Load balancer rules fail after changing network offering"
	msgstr ""

	#: ../../troubleshooting.rst:217
	# 54be70ae479746b099f16a975e6b313e
	msgid "After changing the network offering on a network, load balancer rules stop working."
	msgstr ""

	#: ../../troubleshooting.rst:223
	# 8859286ab9d946d5afc087a41d70f300
	msgid "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."
	msgstr ""

	#: ../../troubleshooting.rst:231
	# c745ba81f8c64e42ad0d937ae17224cd
	msgid "Create a firewall rule on the virtual router for each of your existing load balancing rules so that they continue to function."
	msgstr ""

	#: ../../troubleshooting.rst:235
	# 59274eeb4f9c42eab20167cb78fcfcec
	msgid "Troubleshooting Internet Traffic"
	msgstr ""

	#: ../../troubleshooting.rst:237
	# 8b0eac2ff7a14b528639484afb576723
	msgid "Below are a few troubleshooting steps to check whats going wrong with your network..."
	msgstr ""

	#: ../../troubleshooting.rst:241
	# f27e96f760da43158895e31cefe0d354
	msgid "Trouble Shooting Steps"
	msgstr ""

	#: ../../troubleshooting.rst:243
	# 5b3da7b6d48a45ccaab81ec2fefb9b72
	msgid "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..."
	msgstr ""

	#: ../../troubleshooting.rst:247
	# ebc26236b36141e2ad5ea9414f0eefc4
	msgid "On host1 (kvm1)"
	msgstr ""

	#: ../../troubleshooting.rst:255
	# 1466a71fb13c4e8d9d6885ac3c9a46ea
	msgid "On host2 (kvm2)"
	msgstr ""

	#: ../../troubleshooting.rst:263
	# e3a67b52cabd4480b54de5ad3c79f6b5
	msgid "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"
	msgstr ""

	#: ../../troubleshooting.rst:268
	# ce37e4e95d564397b90ff5aef4baa80d
	msgid "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."
	msgstr ""

	#: ../../troubleshooting.rst:270
	# 6be4c1c298e3442c8353ba69a623d6d9
	msgid "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."
	msgstr ""

	#: ../../troubleshooting.rst:276
	# f1555452ac5a4341a628cf84d907af13
	msgid "On an existing zone, you can modify the traffic labels by going to Infrastructure, Zones, Physical Network tab."
	msgstr ""

	#: ../../troubleshooting.rst:281
	# 344079c7f4e54f748b8d4b63b1be58d4
	msgid "List labels using CloudMonkey"
	msgstr ""

	#: ../../troubleshooting.rst:313
	# 5426cbca012c4e0ba7d7afa01f49719e
	msgid "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."
	msgstr ""

	#: ../../troubleshooting.rst:332
	# 4892fd19e0e14fc39b02e7c7dddb8f2b
	msgid "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."
	msgstr ""

	#: ../../troubleshooting.rst:364
	# a87950c34d404d9ba5426109cc68a1cc
	msgid "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."
	msgstr ""

	#: ../../troubleshooting.rst:377
	# 59c18293d72e465580db2a7b77faebcc
	msgid "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."
	msgstr ""

	#: ../../troubleshooting.rst:409
	# c4cfab36727849f1a4ca325b9a43eaf9
	msgid "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."
	msgstr ""

	#: ../../troubleshooting.rst:424
	# f7afcd661a50477fb5a663ebab387610
	msgid "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."
	msgstr ""

	#: ../../troubleshooting.rst:431
	# ad40b8f845bf4c679b118fa88838fc44
	msgid "The VM Instances by default wont be able to access the Internet. Add Egress rules to permit traffic."
	msgstr ""

	#: ../../troubleshooting.rst:436
	# 8f93a9ea7cec42038a0511d2d00b1b9c
	msgid "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."
	msgstr ""

	#: ../../troubleshooting.rst:443
	# 5b0ed7e9c0584d40aa39fb35184e6122
	msgid "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."
	msgstr ""

	#: ../../troubleshooting.rst:446
	# 264a011e35404961978190f2eebf50e0
	msgid "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/>`_"
	msgstr ""