You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cloudstack.apache.org by se...@apache.org on 2014/03/31 20:14:53 UTC

[4/8] setup i18n with transifex and sphinx-intl

http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/65303ea3/source/locale/pot/storage.pot
----------------------------------------------------------------------
diff --git a/source/locale/pot/storage.pot b/source/locale/pot/storage.pot
new file mode 100644
index 0000000..240f9fe
--- /dev/null
+++ b/source/locale/pot/storage.pot
@@ -0,0 +1,1106 @@
+# SOME DESCRIPTIVE TITLE.
+# Copyright (C) 
+# This file is distributed under the same license as the Apache CloudStack Administration Documentation package.
+# FIRST AUTHOR <EM...@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 <EM...@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"
+
+#: ../../storage.rst:18
+# 6a202e4741994470b627a504dfaa0ec4
+msgid "Working with Storage"
+msgstr ""
+
+#: ../../storage.rst:21
+# 162dc01704434bf39297420664b52155
+msgid "Storage Overview"
+msgstr ""
+
+#: ../../storage.rst:23
+# fb6cf279ed414191933888a05da50e30
+msgid "CloudStack defines two types of storage: primary and secondary. Primary storage can be accessed by either iSCSI or NFS. Additionally, direct attached storage may be used for primary storage. Secondary storage is always accessed using NFS."
+msgstr ""
+
+#: ../../storage.rst:28
+# 3e1682b1378e44d1b6277de404cef6c9
+msgid "There is no ephemeral storage in CloudStack. All volumes on all nodes are persistent."
+msgstr ""
+
+#: ../../storage.rst:32
+# 3b158cf365224a128dce4c9bf414bc05
+msgid "Primary Storage"
+msgstr ""
+
+#: ../../storage.rst:34
+# 0182a2b8079342b0b3ceb0b29b179646
+msgid "This section gives concepts and technical details about CloudStack primary storage. For information about how to install and configure primary storage through the CloudStack UI, see the Installation Guide."
+msgstr ""
+
+#: ../../storage.rst:38
+# 6050cb5647774b9191d87c9ac4c7db00
+msgid "`“About Primary Storage” <http://docs.cloudstack.apache.org/en/latest/concepts.html#about-primary-storage>`_"
+msgstr ""
+
+#: ../../storage.rst:41
+# 2d5f67decc454f279ad544d95f3a200c
+msgid "Best Practices for Primary Storage"
+msgstr ""
+
+#: ../../storage.rst:45
+# a8e6b6ee46a0407d89434124df4e5829
+msgid "The speed of primary storage will impact guest performance. If possible, choose smaller, higher RPM drives or SSDs for primary storage."
+msgstr ""
+
+#: ../../storage.rst:51
+# 25a499cd8ec24c99bfc6f0391d203d7b
+msgid "There are two ways CloudStack can leverage primary storage:"
+msgstr ""
+
+#: ../../storage.rst:53
+# 8c344e1829c64653b8c2a3f7fd4340c6
+msgid "Static: This is CloudStack's traditional way of handling storage. In this model, a preallocated amount of storage (ex. a volume from a SAN) is given to CloudStack. CloudStack then permits many of its volumes to be created on this storage (can be root and/or data disks). If using this technique, ensure that nothing is stored on the storage. Adding the storage to CloudStack will destroy any existing data."
+msgstr ""
+
+#: ../../storage.rst:61
+# 72b1dbe1653c4bfbb6de406140cd47d5
+msgid "Dynamic: This is a newer way for CloudStack to manage storage. In this model, a storage system (rather than a preallocated amount of storage) is given to CloudStack. CloudStack, working in concert with a storage plug-in, dynamically creates volumes on the storage system and each volume on the storage system maps to a single CloudStack volume. This is highly useful for features such as storage Quality of Service. Currently this feature is supported for data disks (Disk Offerings)."
+msgstr ""
+
+#: ../../storage.rst:71
+# 0a9a0545d65d499e9e87855b3f653046
+msgid "Runtime Behavior of Primary Storage"
+msgstr ""
+
+#: ../../storage.rst:73
+# c1b7c1df534f487d9b282f9cba881b25
+msgid "Root volumes are created automatically when a virtual machine is created. Root volumes are deleted when the VM is destroyed. Data volumes can be created and dynamically attached to VMs. Data volumes are not deleted when VMs are destroyed."
+msgstr ""
+
+#: ../../storage.rst:78
+# b55c6963f6704ca899a39303709603e6
+msgid "Administrators should monitor the capacity of primary storage devices and add additional primary storage as needed. See the Advanced Installation Guide."
+msgstr ""
+
+#: ../../storage.rst:82
+# 0e941196770047709eb7afb942ef3189
+msgid "Administrators add primary storage to the system by creating a CloudStack storage pool. Each storage pool is associated with a cluster or a zone."
+msgstr ""
+
+#: ../../storage.rst:86
+# 0be8863a4d5c46b1bfa11b79c1a1b407
+msgid "With regards to data disks, when a user executes a Disk Offering to create a data disk, the information is initially written to the CloudStack database only. Upon the first request that the data disk be attached to a VM, CloudStack determines what storage to place the volume on and space is taken from that storage (either from preallocated storage or from a storage system (ex. a SAN), depending on how the primary storage was added to CloudStack)."
+msgstr ""
+
+#: ../../storage.rst:95
+# 35ce9d0c83744d748be1f1449258f36c
+msgid "Hypervisor Support for Primary Storage"
+msgstr ""
+
+#: ../../storage.rst:97
+# 31019aa248e34fc6b8039761b2720e7f
+msgid "The following table shows storage options and parameters for different hypervisors."
+msgstr ""
+
+#: ../../storage.rst:101
+# 9b771149e496473c92a454c33198c403
+msgid "Storage media \\\\ hypervisor"
+msgstr ""
+
+#: ../../storage.rst:101
+#: ../../storage.rst:805
+# e97686c28c974dbf92162b6b0fa942b8
+# bfae9331e42b4e998bdae8c62e3765eb
+msgid "VMware vSphere"
+msgstr ""
+
+#: ../../storage.rst:101
+#: ../../storage.rst:805
+# 0058e135219d4613a2d541b1870917de
+# 3b343f7b559749a29a430c1a553b3526
+msgid "Citrix XenServer"
+msgstr ""
+
+#: ../../storage.rst:101
+#: ../../storage.rst:354
+#: ../../storage.rst:805
+# 367bf4f20f1c4984924962ff00d6df89
+# 52a52afa13aa4117b06c90af23419b9d
+# edc2d21234584f6a99ca592df4540bbe
+msgid "KVM"
+msgstr ""
+
+#: ../../storage.rst:101
+# b5679e3e7ee44ad081663d53a59df3e5
+msgid "Hyper-V"
+msgstr ""
+
+#: ../../storage.rst:103
+# 8c6b23cd30df4e11a24b05d287672f22
+msgid "**Format for Disks, Templates, and Snapshots**"
+msgstr ""
+
+#: ../../storage.rst:103
+# 1533db8909654e9dbdee1bfb501c22da
+msgid "VMDK"
+msgstr ""
+
+#: ../../storage.rst:103
+#: ../../storage.rst:352
+# aa7a7f57290745ebb004f74e8d93a94c
+# 7d5a6b20bd9c40dd8e2bf7f89defbb4f
+msgid "VHD"
+msgstr ""
+
+#: ../../storage.rst:103
+#: ../../storage.rst:354
+# 857238d5d0894c4195147b0552ef94cc
+# 85858348297d4cb18e06b4f68df7bb9b
+msgid "QCOW2"
+msgstr ""
+
+#: ../../storage.rst:103
+# 45f3ddfdaf174b0e844873ef2d5609aa
+msgid "VHD Snapshots are not supported."
+msgstr ""
+
+#: ../../storage.rst:105
+# 629dd8794f35435ba0c0de72442d0698
+msgid "**iSCSI support**"
+msgstr ""
+
+#: ../../storage.rst:105
+#: ../../storage.rst:106
+# df0857bbc10d454694cb27c6368cc385
+# 6cbf7a9a5ccf4c9b8d9cfea376fa936c
+msgid "VMFS"
+msgstr ""
+
+#: ../../storage.rst:105
+# 6356c605eb10407597ce69ae946eded4
+msgid "Clustered LVM"
+msgstr ""
+
+#: ../../storage.rst:105
+#: ../../storage.rst:106
+# 54f6f377a0e9433ba6646f2d344089a1
+# e8acf322132f4c1d92c944041a19c61f
+msgid "Yes, via Shared Mountpoint"
+msgstr ""
+
+#: ../../storage.rst:105
+#: ../../storage.rst:106
+#: ../../storage.rst:107
+#: ../../storage.rst:109
+#: ../../storage.rst:110
+#: ../../storage.rst:110
+#: ../../storage.rst:110
+#: ../../storage.rst:807
+#: ../../storage.rst:807
+# d6cf7d4bef014613aaf695ffffe4a235
+# c823d9f7038149b690668fa00379827b
+# 0b59cd2d03ac46529c20eaaab120981c
+# 846a3012c0ae422495176ac15ab15e55
+# d14fff6660d64688afc8ccbcc70cddfd
+# caa33ef9d4a04315a001850c938c31b8
+# 86461019f42a406e8b39a826bc193ed7
+# 5bb1f7b752e345d2b87e7e358be4b8a8
+# e68af722a2d2497aa6f8a8fca2cbdde6
+msgid "No"
+msgstr ""
+
+#: ../../storage.rst:106
+# 4a312a6b96eb419e9e8f0340e73043c7
+msgid "**Fiber Channel support**"
+msgstr ""
+
+#: ../../storage.rst:106
+# ca35f289a9684c7dbf0aa1d2eec7ea07
+msgid "Yes, via Existing SR"
+msgstr ""
+
+#: ../../storage.rst:107
+# 50c9535f99f94ba991e8f54be3a35868
+msgid "**NFS support**"
+msgstr ""
+
+#: ../../storage.rst:107
+#: ../../storage.rst:107
+#: ../../storage.rst:107
+#: ../../storage.rst:108
+#: ../../storage.rst:108
+#: ../../storage.rst:108
+#: ../../storage.rst:108
+#: ../../storage.rst:110
+#: ../../storage.rst:807
+# e2c8e01326de420a93da3da1cccc6e04
+# 03b10788ed144cee89bfeb280a91507b
+# 36ec13d7d1104063898e7ee586dc8e73
+# 7b8ce691a5754a2bbe7b77ba4a5beb29
+# 73f105a11ea244348d276ceda77ffa48
+# 8e54d7de196946248fa2f7c5e5e89ed6
+# f03361eae16c40518b6e18d98ee28635
+# 34559af0e0774036a131a78b6b54e924
+# 89b6eb69d35a47eabb875bdf4405e421
+msgid "Yes"
+msgstr ""
+
+#: ../../storage.rst:108
+# 6d3ad498707b47e183038ce5ebb1447d
+msgid "**Local storage support**"
+msgstr ""
+
+#: ../../storage.rst:109
+# 858891283fa8498382d9942dc59e2ae6
+msgid "**Storage over-provisioning**"
+msgstr ""
+
+#: ../../storage.rst:109
+# 876ffced6c3f4dd1825a99b39c624759
+msgid "NFS and iSCSI"
+msgstr ""
+
+#: ../../storage.rst:109
+#: ../../storage.rst:109
+# 34edc60597864cb88c0d3a68161bd014
+# afaccbd5ae404bbf9a2b322b957fc27f
+msgid "NFS"
+msgstr ""
+
+#: ../../storage.rst:110
+# 5cdd4df99d8146b99052b26946cfdebc
+msgid "**SMB/CIFS**"
+msgstr ""
+
+#: ../../storage.rst:113
+# 23cfe36aac394c0183ffe7482f8dcded
+msgid "XenServer uses a clustered LVM system to store VM images on iSCSI and Fiber Channel volumes and does not support over-provisioning in the hypervisor. The storage server itself, however, can support thin-provisioning. As a result the CloudStack can still support storage over-provisioning by running on thin-provisioned storage volumes."
+msgstr ""
+
+#: ../../storage.rst:119
+# bd46a0f32fc0459fadf89598bd0b9f7b
+msgid "KVM supports \"Shared Mountpoint\" storage. A shared mountpoint is a file system path local to each server in a given cluster. The path must be the same across all Hosts in the cluster, for example /mnt/primary1. This shared mountpoint is assumed to be a clustered filesystem such as OCFS2. In this case the CloudStack does not attempt to mount or unmount the storage as is done with NFS. The CloudStack requires that the administrator insure that the storage is available"
+msgstr ""
+
+#: ../../storage.rst:127
+# 5ab2d028f0aa4897b165fb8e42dbb0e4
+msgid "With NFS storage, CloudStack manages the overprovisioning. In this case the global configuration parameter storage.overprovisioning.factor controls the degree of overprovisioning. This is independent of hypervisor type."
+msgstr ""
+
+#: ../../storage.rst:132
+# 585fda9b393848eaa23c3131967805fe
+msgid "Local storage is an option for primary storage for vSphere, XenServer, and KVM. When the local disk option is enabled, a local disk storage pool is automatically created on each host. To use local storage for the System Virtual Machines (such as the Virtual Router), set system.vm.use.local.storage to true in global configuration."
+msgstr ""
+
+#: ../../storage.rst:138
+# c4c43cee4d724ef7aa505614fe3cedba
+msgid "CloudStack supports multiple primary storage pools in a Cluster. For example, you could provision 2 NFS servers in primary storage. Or you could provision 1 iSCSI LUN initially and then add a second iSCSI LUN when the first approaches capacity."
+msgstr ""
+
+#: ../../storage.rst:144
+# 235339683cb34f9984c233974b8da43d
+msgid "Storage Tags"
+msgstr ""
+
+#: ../../storage.rst:146
+# c9a9cdbd754642189859f3f96cfebe95
+msgid "Storage may be \"tagged\". A tag is a text string attribute associated with primary storage, a Disk Offering, or a Service Offering. Tags allow administrators to provide additional information about the storage. For example, that is a \"SSD\" or it is \"slow\". Tags are not interpreted by CloudStack. They are matched against tags placed on service and disk offerings. CloudStack requires all tags on service and disk offerings to exist on the primary storage before it allocates root or data disks on the primary storage. Service and disk offering tags are used to identify the requirements of the storage that those offerings have. For example, the high end service offering may require \"fast\" for its root disk volume."
+msgstr ""
+
+#: ../../storage.rst:158
+# 62e869476add4ac8a88d34476a992a0b
+msgid "The interaction between tags, allocation, and volume copying across clusters and pods can be complex. To simplify the situation, use the same set of tags on the primary storage for all clusters in a pod. Even if different devices are used to present those tags, the set of exposed tags can be the same."
+msgstr ""
+
+#: ../../storage.rst:165
+# 85d0b9514cd94531b80bb8458c5ce0dc
+msgid "Maintenance Mode for Primary Storage"
+msgstr ""
+
+#: ../../storage.rst:167
+# 51dcf6eb4eec44809e6e374dbf77c6bf
+msgid "Primary storage may be placed into maintenance mode. This is useful, for example, to replace faulty RAM in a storage device. Maintenance mode for a storage device will first stop any new guests from being provisioned on the storage device. Then it will stop all guests that have any volume on that storage device. When all such guests are stopped the storage device is in maintenance mode and may be shut down. When the storage device is online again you may cancel maintenance mode for the device. The CloudStack will bring the device back online and attempt to start all guests that were running at the time of the entry into maintenance mode."
+msgstr ""
+
+#: ../../storage.rst:179
+# 50c6445f7bbf459c8184fcbee613ef51
+msgid "Secondary Storage"
+msgstr ""
+
+#: ../../storage.rst:181
+# 93e8dd0aa2384174bfaff80a3205b6cb
+msgid "This section gives concepts and technical details about CloudStack secondary storage. For information about how to install and configure secondary storage through the CloudStack UI, see the Advanced Installation Guide."
+msgstr ""
+
+#: ../../storage.rst:186
+# 18793cf034ab43f1b77b289ac9d4286b
+msgid "`“About Secondary Storage” <http://docs.cloudstack.apache.org/en/latest/concepts.html#about-secondary-storage>`_"
+msgstr ""
+
+#: ../../storage.rst:189
+# 581e0ba4319a47feb92812e319ae14af
+msgid "Working With Volumes"
+msgstr ""
+
+#: ../../storage.rst:191
+# 142cd329b56e4fb2b0e17fb5fe687958
+msgid "A volume provides storage to a guest VM. The volume can provide for a root disk or an additional data disk. CloudStack supports additional volumes for guest VMs."
+msgstr ""
+
+#: ../../storage.rst:195
+# cdaaac178c9946e9bd5030fe82be6c78
+msgid "Volumes are created for a specific hypervisor type. A volume that has been attached to guest using one hypervisor type (e.g, XenServer) may not be attached to a guest that is using another hypervisor type, for example:vSphere, KVM. This is because the different hypervisors use different disk image formats."
+msgstr ""
+
+#: ../../storage.rst:201
+# 91341fe4ee6540a9a6ee240d99134524
+msgid "CloudStack defines a volume as a unit of storage available to a guest VM. Volumes are either root disks or data disks. The root disk has \"/\" in the file system and is usually the boot device. Data disks provide for additional storage, for example: \"/opt\" or \"D:\". Every guest VM has a root disk, and VMs can also optionally have a data disk. End users can mount multiple data disks to guest VMs. Users choose data disks from the disk offerings created by administrators. The user can create a template from a volume as well; this is the standard procedure for private template creation. Volumes are hypervisor-specific: a volume from one hypervisor type may not be used on a guest of another hypervisor type."
+msgstr ""
+
+#: ../../storage.rst:213
+# da3a2cb646de40cba343e682fd29a500
+msgid "CloudStack supports attaching up to 13 data disks to a VM on XenServer hypervisor versions 6.0 and above. For the VMs on other hypervisor types, the data disk limit is 6."
+msgstr ""
+
+#: ../../storage.rst:216
+# f994b230e52240c089e8967a20e17040
+msgid "Creating a New Volume"
+msgstr ""
+
+#: ../../storage.rst:218
+# 73e8fe50f38c4b7ab55f0fc3569b141f
+msgid "You can add more data disk volumes to a guest VM at any time, up to the limits of your storage capacity. Both CloudStack administrators and users can add volumes to VM instances. When you create a new volume, it is stored as an entity in CloudStack, but the actual storage resources are not allocated on the physical storage device until you attach the volume. This optimization allows the CloudStack to provision the volume nearest to the guest that will use it when the first attachment is made."
+msgstr ""
+
+#: ../../storage.rst:227
+# 4e95f1cce44c4810b4dbd2d9ad64b99c
+msgid "Using Local Storage for Data Volumes"
+msgstr ""
+
+#: ../../storage.rst:229
+# 77c86c26103b40de80b813b21c07de64
+msgid "You can create data volumes on local storage (supported with XenServer, KVM, and VMware). The data volume is placed on the same host as the VM instance that is attached to the data volume. These local data volumes can be attached to virtual machines, detached, re-attached, and deleted just as with the other types of data volume."
+msgstr ""
+
+#: ../../storage.rst:235
+# 4e4085b4548c4fd291c04570d4b72c31
+msgid "Local storage is ideal for scenarios where persistence of data volumes and HA is not required. Some of the benefits include reduced disk I/O latency and cost reduction from using inexpensive local disks."
+msgstr ""
+
+#: ../../storage.rst:239
+# fb5fadabf5084ba2be5f47f42c575bec
+msgid "In order for local volumes to be used, the feature must be enabled for the zone."
+msgstr ""
+
+#: ../../storage.rst:242
+# 2738dcf7ec914826a7fee9dde6d1dd3d
+msgid "You can create a data disk offering for local storage. When a user creates a new VM, they can select this disk offering in order to cause the data disk volume to be placed in local storage."
+msgstr ""
+
+#: ../../storage.rst:246
+# e6cc30d22423450c85f9517f7c29b58c
+msgid "You can not migrate a VM that has a volume in local storage to a different host, nor migrate the volume itself away to a different host. If you want to put a host into maintenance mode, you must first stop any VMs with local data volumes on that host."
+msgstr ""
+
+#: ../../storage.rst:252
+# 5ba5e0d99d2b485eb47568e8f5c49974
+msgid "To Create a New Volume"
+msgstr ""
+
+#: ../../storage.rst:256
+#: ../../storage.rst:386
+#: ../../storage.rst:428
+#: ../../storage.rst:498
+#: ../../storage.rst:529
+#: ../../storage.rst:566
+#: ../../storage.rst:636
+# 854156bcaf7841df87abdbbe3c2e1a97
+# 81089de40b7f4cfabaf992d654b45b6a
+# d2aadcf9b28745ccabf9ab9238f12bb8
+# 87447c411f444603b00a3bdf59da65d0
+# 6f7be70585d8470fb8e8e0f82a57714b
+# c9aa8bf9f15c4956ab9d0372030dc6ee
+# 88f2f68cca994709945a84a66ff08f83
+msgid "Log in to the CloudStack UI as a user or admin."
+msgstr ""
+
+#: ../../storage.rst:260
+#: ../../storage.rst:324
+#: ../../storage.rst:640
+#: ../../storage.rst:756
+# 72e414f9ba5a469aa0219d560888934b
+# 14f9e0c99a7a49f6ac1f53e3163d2025
+# 50e1473900704ebcae177aa3a73ed45c
+# ce7e768615b345d1a5cfd791b3e49343
+msgid "In the left navigation bar, click Storage."
+msgstr ""
+
+#: ../../storage.rst:264
+#: ../../storage.rst:394
+#: ../../storage.rst:644
+# 5e66820dfd5e495fb59a2e3b04eceaf4
+# 7490a7779492470692842a5bc16f66a8
+# 05e2753aad0543ed9de8f5fe61ae80d8
+msgid "In Select View, choose Volumes."
+msgstr ""
+
+#: ../../storage.rst:268
+# 98f953c385004db884f1a0b9d7fcce09
+msgid "To create a new volume, click Add Volume, provide the following details, and click OK."
+msgstr ""
+
+#: ../../storage.rst:273
+# f77218cc8e0944c5ac93425caddc5a5c
+msgid "Name. Give the volume a unique name so you can find it later."
+msgstr ""
+
+#: ../../storage.rst:277
+# 77f2d58bc029432fad2e20894e0dc4a4
+msgid "Availability Zone. Where do you want the storage to reside? This should be close to the VM that will use the volume."
+msgstr ""
+
+#: ../../storage.rst:282
+# 0dd389820dab437ab448b331b2e2e3dc
+msgid "Disk Offering. Choose the characteristics of the storage."
+msgstr ""
+
+#: ../../storage.rst:284
+# 3ff901f9fc4245859f4413152d691ec2
+msgid "The new volume appears in the list of volumes with the state “Allocated.” The volume data is stored in CloudStack, but the volume is not yet ready for use"
+msgstr ""
+
+#: ../../storage.rst:290
+# 1fd0848ef74948fdbcbccf818d92177d
+msgid "To start using the volume, continue to Attaching a Volume"
+msgstr ""
+
+#: ../../storage.rst:293
+# c0df3d546d4d4bb0b749ee670e7fb1b4
+msgid "Uploading an Existing Volume to a Virtual Machine"
+msgstr ""
+
+#: ../../storage.rst:295
+# 72bbdbadb3124063954e9e6fe0dce7a1
+msgid "Existing data can be made accessible to a virtual machine. This is called uploading a volume to the VM. For example, this is useful to upload data from a local file system and attach it to a VM. Root administrators, domain administrators, and end users can all upload existing volumes to VMs."
+msgstr ""
+
+#: ../../storage.rst:301
+# c9884a3f983640be9c819a9386183862
+msgid "The upload is performed using HTTP. The uploaded volume is placed in the zone's secondary storage"
+msgstr ""
+
+#: ../../storage.rst:304
+# 0a24f9d7f649445ea6f882e03af5a4c8
+msgid "You cannot upload a volume if the preconfigured volume limit has already been reached. The default limit for the cloud is set in the global configuration parameter max.account.volumes, but administrators can also set per-domain limits that are different from the global default. See Setting Usage Limits"
+msgstr ""
+
+#: ../../storage.rst:310
+# 561cea17ed5b4aa18cea478b6159261d
+msgid "To upload a volume:"
+msgstr ""
+
+#: ../../storage.rst:314
+# 5ca6925a182745bd92c83dddbb7ae803
+msgid "(Optional) Create an MD5 hash (checksum) of the disk image file that you are going to upload. After uploading the data disk, CloudStack will use this value to verify that no data corruption has occurred."
+msgstr ""
+
+#: ../../storage.rst:320
+# 51a89894bbfa4442971f72c7e46f146d
+msgid "Log in to the CloudStack UI as an administrator or user"
+msgstr ""
+
+#: ../../storage.rst:328
+# 28723898f3674b00ab161be4a747617a
+msgid "Click Upload Volume."
+msgstr ""
+
+#: ../../storage.rst:332
+# ad72af46b40f4b3f9a6e531498b729d9
+msgid "Provide the following:"
+msgstr ""
+
+#: ../../storage.rst:336
+# 2171cbf4083742a8be4e3f3d6905d0da
+msgid "Name and Description. Any desired name and a brief description that can be shown in the UI."
+msgstr ""
+
+#: ../../storage.rst:341
+# 4cd509c15df24aba8666b7d11a9051be
+msgid "Availability Zone. Choose the zone where you want to store the volume. VMs running on hosts in this zone can attach the volume."
+msgstr ""
+
+#: ../../storage.rst:346
+# 17cb7725cd0940cf8557d68206638aea
+msgid "Format. Choose one of the following to indicate the disk image format of the volume."
+msgstr ""
+
+#: ../../storage.rst:350
+# e4c763d0aab143b49ab6e9d9a1432df0
+msgid "Hypervisor"
+msgstr ""
+
+#: ../../storage.rst:350
+# 31ec3ac278d44770a548d99764119364
+msgid "Disk Image Format"
+msgstr ""
+
+#: ../../storage.rst:352
+# 81cdbfc4baaf46318a9b1031f0aa73f9
+msgid "XenServer"
+msgstr ""
+
+#: ../../storage.rst:353
+# b0ad57c5512c4cfda950f3a262618a6d
+msgid "VMware"
+msgstr ""
+
+#: ../../storage.rst:353
+# 9714e77ca28e441fad02c1f395a121a9
+msgid "OVA"
+msgstr ""
+
+#: ../../storage.rst:359
+# 1c6d0308a6d84f04909361d7d827e4a8
+msgid "URL. The secure HTTP or HTTPS URL that CloudStack can use to access your disk. The type of file at the URL must match the value chosen in Format. For example, if Format is VHD, the URL might look like the following:"
+msgstr ""
+
+#: ../../storage.rst:364
+# f0494cc84c3941c1b9f499bc95a77793
+msgid "``http://yourFileServerIP/userdata/myDataDisk.vhd``"
+msgstr ""
+
+#: ../../storage.rst:368
+# 459a453424c84b51abfd379a935f578d
+msgid "MD5 checksum. (Optional) Use the hash that you created in step 1."
+msgstr ""
+
+#: ../../storage.rst:372
+# 8532aa0d890a4990b343381696efe17b
+msgid "Wait until the status of the volume shows that the upload is complete. Click Instances - Volumes, find the name you specified in step 5, and make sure the status is Uploaded."
+msgstr ""
+
+#: ../../storage.rst:377
+# 9d29a7dddfd446539ef41dfcdf464ca1
+msgid "Attaching a Volume"
+msgstr ""
+
+#: ../../storage.rst:379
+# 59c5f93ac3c64d8eb008975ca5b66300
+msgid "You can attach a volume to a guest VM to provide extra disk storage. Attach a volume when you first create a new volume, when you are moving an existing volume from one VM to another, or after you have migrated a volume from one storage pool to another."
+msgstr ""
+
+#: ../../storage.rst:390
+# d2666c87d93e413aa8dd8637e062f650
+msgid "In the left navigation, click Storage."
+msgstr ""
+
+#: ../../storage.rst:398
+# 60b9f463a5304e338a5505ef7d8c64ff
+msgid "Click the volume name in the Volumes list, then click the Attach Disk button |AttachDiskButton.png|"
+msgstr ""
+
+#: ../../storage.rst:403
+# 9b1bee8f6c564762854e98112c13ef30
+msgid "In the Instance popup, choose the VM to which you want to attach the volume. You will only see instances to which you are allowed to attach volumes; for example, a user will see only instances created by that user, but the administrator will have more choices."
+msgstr ""
+
+#: ../../storage.rst:410
+# 650c85a5e1254efdb77ed55f37f13a14
+msgid "When the volume has been attached, you should be able to see it by clicking Instances, the instance name, and View Volumes."
+msgstr ""
+
+#: ../../storage.rst:414
+# 3a8754012f8f4da98dfba46033984c06
+msgid "Detaching and Moving Volumes"
+msgstr ""
+
+#: ../../storage.rst:417
+# 15d989ccfe6b43b28260c1289e7388cf
+msgid "This procedure is different from moving volumes from one storage pool to another as described in `“VM Storage Migration” <#vm-storage-migration>`_."
+msgstr ""
+
+#: ../../storage.rst:419
+# 8bf4295f191343829d3c43e858b12a1e
+msgid "A volume can be detached from a guest VM and attached to another guest. Both CloudStack administrators and users can detach volumes from VMs and move them to other VMs."
+msgstr ""
+
+#: ../../storage.rst:423
+# 4b538b0a7328497cbb1de6c4dd724eb2
+msgid "If the two VMs are in different clusters, and the volume is large, it may take several minutes for the volume to be moved to the new VM."
+msgstr ""
+
+#: ../../storage.rst:432
+# 39d64a096df5469ba79c30f50856d546
+msgid "In the left navigation bar, click Storage, and choose Volumes in Select View. Alternatively, if you know which VM the volume is attached to, you can click Instances, click the VM name, and click View Volumes."
+msgstr ""
+
+#: ../../storage.rst:439
+# 791d977d23984313b80ffa2aa915577d
+msgid "Click the name of the volume you want to detach, then click the Detach Disk button. |DetachDiskButton.png|"
+msgstr ""
+
+#: ../../storage.rst:444
+# 6b7ea67796a948bbbaeab6bbdaf832c2
+msgid "To move the volume to another VM, follow the steps in `“Attaching a Volume” <#attaching-a-volume>`_."
+msgstr ""
+
+#: ../../storage.rst:448
+# 6597c6aaa3fc40f89bdac966f91c4642
+msgid "VM Storage Migration"
+msgstr ""
+
+#: ../../storage.rst:450
+# 98aac3254e864e4dad42c3824a081f9d
+msgid "Supported in XenServer, KVM, and VMware."
+msgstr ""
+
+#: ../../storage.rst:453
+# 04f285a0220743a19e6d3a7b54226766
+msgid "This procedure is different from moving disk volumes from one VM to another as described in `“Detaching and Moving Volumes” <#detaching-and-moving-volumes>`_."
+msgstr ""
+
+#: ../../storage.rst:455
+# 63619f4ba4c14b57b06d4b6f34cad27e
+msgid "You can migrate a virtual machine’s root disk volume or any additional data disk volume from one storage pool to another in the same zone."
+msgstr ""
+
+#: ../../storage.rst:458
+# b374aaa7079f4357a3f44ea9e8d06dfc
+msgid "You can use the storage migration feature to achieve some commonly desired administration goals, such as balancing the load on storage pools and increasing the reliability of virtual machines by moving them away from any storage pool that is experiencing issues."
+msgstr ""
+
+#: ../../storage.rst:463
+# 04abf2b317084f6a948d7878ad1cbaf4
+msgid "On XenServer and VMware, live migration of VM storage is enabled through CloudStack support for XenMotion and vMotion. Live storage migration allows VMs to be moved from one host to another, where the VMs are not located on storage shared between the two hosts. It provides the option to live migrate a VM’s disks along with the VM itself. It is possible to migrate a VM from one XenServer resource pool / VMware cluster to another, or to migrate a VM whose disks are on local storage, or even to migrate a VM’s disks from one storage repository to another, all while the VM is running."
+msgstr ""
+
+#: ../../storage.rst:474
+# def78c6283b8421d959acad05e006b34
+msgid "Because of a limitation in VMware, live migration of storage for a VM is allowed only if the source and target storage pool are accessible to the source host; that is, the host where the VM is running when the live migration operation is requested."
+msgstr ""
+
+#: ../../storage.rst:477
+# c24b72459dde481887747acf4697636f
+msgid "Migrating a Data Volume to a New Storage Pool"
+msgstr ""
+
+#: ../../storage.rst:479
+# bf37a69a59b542a98c25363d45c9713d
+msgid "There are two situations when you might want to migrate a disk:"
+msgstr ""
+
+#: ../../storage.rst:483
+# f8b93cb34c384463a75f83959616871f
+msgid "Move the disk to new storage, but leave it attached to the same running VM."
+msgstr ""
+
+#: ../../storage.rst:488
+# 5cbf239bfd444a0f9c842deb94ed82ba
+msgid "Detach the disk from its current VM, move it to new storage, and attach it to a new VM."
+msgstr ""
+
+#: ../../storage.rst:492
+# 0d25ecabc349499586d885844f71b1d0
+msgid "Migrating Storage For a Running VM"
+msgstr ""
+
+#: ../../storage.rst:494
+# 245dccc84a4e456990f3c0543c4fead3
+msgid "(Supported on XenServer and VMware)"
+msgstr ""
+
+#: ../../storage.rst:502
+# 30cb4d3d0e4e417492b11e590eb7f765
+msgid "In the left navigation bar, click Instances, click the VM name, and click View Volumes."
+msgstr ""
+
+#: ../../storage.rst:507
+# 5277b5ef2825414da877bab6feb8fc04
+msgid "Click the volume you want to migrate."
+msgstr ""
+
+#: ../../storage.rst:511
+#: ../../storage.rst:533
+# d0f6564fdaf8483e98845c58dc25c962
+# 9e933a0caa314e80b7270c72c0de6271
+msgid "Detach the disk from the VM. See `“Detaching and Moving Volumes” <#detaching-and-moving-volumes>`_ but skip the “reattach” step at the end. You will do that after migrating to new storage."
+msgstr ""
+
+#: ../../storage.rst:517
+#: ../../storage.rst:539
+# 4649c894198146228bfeed3a1fb7bdd4
+# 27b66737b23347a0926867a4c198ca1a
+msgid "Click the Migrate Volume button |Migrateinstance.png| and choose the destination from the dropdown list."
+msgstr ""
+
+#: ../../storage.rst:521
+# 8b7c76c6d3b441929912e2e36ceb34d2
+msgid "Watch for the volume status to change to Migrating, then back to Ready."
+msgstr ""
+
+#: ../../storage.rst:525
+# 3ffc696411bf46ccacd94ed84c8a4e52
+msgid "Migrating Storage and Attaching to a Different VM"
+msgstr ""
+
+#: ../../storage.rst:543
+# 451b903ccdf9481a87553a1ff3e11675
+msgid "Watch for the volume status to change to Migrating, then back to Ready. You can find the volume by clicking Storage in the left navigation bar. Make sure that Volumes is displayed at the top of the window, in the Select View dropdown."
+msgstr ""
+
+#: ../../storage.rst:550
+# 3ea9addc45e04febafb2f43888f9756a
+msgid "Attach the volume to any desired VM running in the same cluster as the new storage server. See `“Attaching a Volume” <#attaching-a-volume>`_"
+msgstr ""
+
+#: ../../storage.rst:555
+# 4f145ec0a8e9487a840dd7dbd6858579
+msgid "Migrating a VM Root Volume to a New Storage Pool"
+msgstr ""
+
+#: ../../storage.rst:557
+# b1b1c5f5444e43bcb759263c0dc47036
+msgid "(XenServer, VMware) You can live migrate a VM's root disk from one storage pool to another, without stopping the VM first."
+msgstr ""
+
+#: ../../storage.rst:560
+# df65430daab94ed197c4acaf08a3e836
+msgid "(KVM) When migrating the root disk volume, the VM must first be stopped, and users can not access the VM. After migration is complete, the VM can be restarted."
+msgstr ""
+
+#: ../../storage.rst:570
+# be481dbccbbf4cb0a2cc056284533ab8
+msgid "In the left navigation bar, click Instances, and click the VM name."
+msgstr ""
+
+#: ../../storage.rst:574
+# 5274bdb89bf44ea3b038c790ff8672b4
+msgid "(KVM only) Stop the VM."
+msgstr ""
+
+#: ../../storage.rst:578
+# 33f3864ed4d34fb881cc89f632512d88
+msgid "Click the Migrate button |Migrateinstance.png| and choose the destination from the dropdown list."
+msgstr ""
+
+#: ../../storage.rst:581
+# 3349af1b38e4457482c539813e40a08c
+msgid "If the VM's storage has to be migrated along with the VM, this will be noted in the host list. CloudStack will take care of the storage migration for you."
+msgstr ""
+
+#: ../../storage.rst:585
+# 4445e369263d4d0dafd72fe3666283a7
+msgid "Watch for the volume status to change to Migrating, then back to Running (or Stopped, in the case of KVM). This can take some time."
+msgstr ""
+
+#: ../../storage.rst:590
+# e1ad558399c64d8aa7ae00633e58c413
+msgid "(KVM only) Restart the VM."
+msgstr ""
+
+#: ../../storage.rst:593
+# a5eee53b3a944bf88fba18aafe337287
+msgid "Resizing Volumes"
+msgstr ""
+
+#: ../../storage.rst:595
+# a5d5757162eb492aaf50d2220d1d1b98
+msgid "CloudStack provides the ability to resize data disks; CloudStack controls volume size by using disk offerings. This provides CloudStack administrators with the flexibility to choose how much space they want to make available to the end users. Volumes within the disk offerings with the same storage tag can be resized. For example, if you only want to offer 10, 50, and 100 GB offerings, the allowed resize should stay within those limits. That implies if you define a 10 GB, a 50 GB and a 100 GB disk offerings, a user can upgrade from 10 GB to 50 GB, or 50 GB to 100 GB. If you create a custom-sized disk offering, then you have the option to resize the volume by specifying a new, larger size."
+msgstr ""
+
+#: ../../storage.rst:606
+# 4d2a89a3e81a4293bb926db2952a2d89
+msgid "Additionally, using the resizeVolume API, a data volume can be moved from a static disk offering to a custom disk offering with the size specified. This functionality allows those who might be billing by certain volume sizes or disk offerings to stick to that model, while providing the flexibility to migrate to whatever custom size necessary."
+msgstr ""
+
+#: ../../storage.rst:612
+# 0c302b9381964652a04f4931be9a3656
+msgid "This feature is supported on KVM, XenServer, and VMware hosts. However, shrinking volumes is not supported on VMware hosts."
+msgstr ""
+
+#: ../../storage.rst:615
+# c9bd7905071a44d4a6f7905fee796c4a
+msgid "Before you try to resize a volume, consider the following:"
+msgstr ""
+
+#: ../../storage.rst:619
+# 82c7ca43b93f4df09d6c513ff5b70486
+msgid "The VMs associated with the volume are stopped."
+msgstr ""
+
+#: ../../storage.rst:623
+# 6f5a21b47e314e0484db238c6e9c457e
+msgid "The data disks associated with the volume are removed."
+msgstr ""
+
+#: ../../storage.rst:627
+# fec276a1979249fb9dc124f18e1455bd
+msgid "When a volume is shrunk, the disk associated with it is simply truncated, and doing so would put its content at risk of data loss. Therefore, resize any partitions or file systems before you shrink a data disk so that all the data is moved off from that disk."
+msgstr ""
+
+#: ../../storage.rst:632
+# 91d00577aa774910bc0090ff9249c714
+msgid "To resize a volume:"
+msgstr ""
+
+#: ../../storage.rst:648
+# b8b72eb1404144179334e6914f461c43
+msgid "Select the volume name in the Volumes list, then click the Resize Volume button |resize-volume-icon.png|"
+msgstr ""
+
+#: ../../storage.rst:653
+# 6d5f5f78fa294317aaaa19d07403aa91
+msgid "In the Resize Volume pop-up, choose desired characteristics for the storage."
+msgstr ""
+
+#: ../../storage.rst:656
+# 94cd2f322cad423485fcfdaa0afe2ab4
+msgid "|resize-volume.png|"
+msgstr ""
+
+#: ../../storage.rst:660
+# 7f15ee5fc83e482791baa84599ea55cd
+msgid "If you select Custom Disk, specify a custom size."
+msgstr ""
+
+#: ../../storage.rst:664
+# 138ac0a6338b4b0f95312bd4dec59967
+msgid "Click Shrink OK to confirm that you are reducing the size of a volume."
+msgstr ""
+
+#: ../../storage.rst:667
+# 7381eca9284e4773a1bb46e44a3865aa
+msgid "This parameter protects against inadvertent shrinking of a disk, which might lead to the risk of data loss. You must sign off that you know what you are doing."
+msgstr ""
+
+#: ../../storage.rst:673
+# eed53ca74872424ea49fa6cabfbe9eb9
+msgid "Click OK."
+msgstr ""
+
+#: ../../storage.rst:676
+# 5d71f55bf71c4f58beb781d2cb94c74c
+msgid "Reset VM to New Root Disk on Reboot"
+msgstr ""
+
+#: ../../storage.rst:678
+# 2521d69d348047fc8a660b3b8a77b2ac
+msgid "You can specify that you want to discard the root disk and create a new one whenever a given VM is rebooted. This is useful for secure environments that need a fresh start on every boot and for desktops that should not retain state. The IP address of the VM will not change due to this operation."
+msgstr ""
+
+#: ../../storage.rst:684
+# f9ff6cc586b8407c9ff1e235962ec731
+msgid "**To enable root disk reset on VM reboot:**"
+msgstr ""
+
+#: ../../storage.rst:686
+# 0c3f06afe8504df7a4bf4ea7bea288bf
+msgid "When creating a new service offering, set the parameter isVolatile to True. VMs created from this service offering will have their disks reset upon reboot. See `“Creating a New Compute Offering” <service_offerings.html#creating-a-new-compute-offering>`_."
+msgstr ""
+
+#: ../../storage.rst:692
+# d0e6735ecfb243bcb2038075c332453d
+msgid "Volume Deletion and Garbage Collection"
+msgstr ""
+
+#: ../../storage.rst:694
+# 15a72eae3cce46e494793039f4408bc2
+msgid "The deletion of a volume does not delete the snapshots that have been created from the volume"
+msgstr ""
+
+#: ../../storage.rst:697
+# 484eaae26aa442b2af1e54dea16342d2
+msgid "When a VM is destroyed, data disk volumes that are attached to the VM are not deleted."
+msgstr ""
+
+#: ../../storage.rst:700
+# 5fd59185e6d64db280b2ca89ecca3f89
+msgid "Volumes are permanently destroyed using a garbage collection process. The global configuration variables expunge.delay and expunge.interval determine when the physical deletion of volumes will occur."
+msgstr ""
+
+#: ../../storage.rst:706
+# 9111bfdfe0ee4dcf8c15a359324059fc
+msgid "`expunge.delay`: determines how old the volume must be before it is destroyed, in seconds"
+msgstr ""
+
+#: ../../storage.rst:711
+# b9e7a6caccba433b8b23ff40bfd62123
+msgid "`expunge.interval`: determines how often to run the garbage collection check"
+msgstr ""
+
+#: ../../storage.rst:714
+# 984f73d3efdc4d5a8a6a4309599cb386
+msgid "Administrators should adjust these values depending on site policies around data retention."
+msgstr ""
+
+#: ../../storage.rst:718
+# 08d9ad354b7942bda197e39303ab4ebe
+msgid "Working with Volume Snapshots"
+msgstr ""
+
+#: ../../storage.rst:720
+#: ../../storage.rst:773
+# 9eb74cf1e4cd42df8c38300249e3e96b
+# a741a75990ca4897a4f34de220bde407
+msgid "(Supported for the following hypervisors: **XenServer**, **VMware vSphere**, and **KVM**)"
+msgstr ""
+
+#: ../../storage.rst:723
+# 673b7caff5fb4ce481e087a9877d4dcd
+msgid "CloudStack supports snapshots of disk volumes. Snapshots are a point-in-time capture of virtual machine disks. Memory and CPU states are not captured. If you are using the Oracle VM hypervisor, you can not take snapshots, since OVM does not support them."
+msgstr ""
+
+#: ../../storage.rst:728
+# d6369c41ebb54df68c691818f61104bb
+msgid "Snapshots may be taken for volumes, including both root and data disks (except when the Oracle VM hypervisor is used, which does not support snapshots). The administrator places a limit on the number of stored snapshots per user. Users can create new volumes from the snapshot for recovery of particular files and they can create templates from snapshots to boot from a restored disk."
+msgstr ""
+
+#: ../../storage.rst:735
+# 90f5f9401836415abbc9e1620b3f224f
+msgid "Users can create snapshots manually or by setting up automatic recurring snapshot policies. Users can also create disk volumes from snapshots, which may be attached to a VM like any other disk volume. Snapshots of both root disks and data disks are supported. However, CloudStack does not currently support booting a VM from a recovered root disk. A disk recovered from snapshot of a root disk is treated as a regular data disk; the data on recovered disk can be accessed by attaching the disk to a VM."
+msgstr ""
+
+#: ../../storage.rst:744
+# 75d1388574754e729e8da27b3c799a49
+msgid "A completed snapshot is copied from primary storage to secondary storage, where it is stored until deleted or purged by newer snapshot."
+msgstr ""
+
+#: ../../storage.rst:748
+# bada0f726d0d4d729aea533943c409b3
+msgid "How to Snapshot a Volume"
+msgstr ""
+
+#: ../../storage.rst:752
+# 44e0d512d57c4888a44a396a5eac75bb
+msgid "Log in to the CloudStack UI as a user or administrator."
+msgstr ""
+
+#: ../../storage.rst:760
+# 19c4af0199724420aecc49d58b0f818e
+msgid "In Select View, be sure Volumes is selected."
+msgstr ""
+
+#: ../../storage.rst:764
+# 70d14f08edf540afaa590235f7ea2f8b
+msgid "Click the name of the volume you want to snapshot."
+msgstr ""
+
+#: ../../storage.rst:768
+# aed06a6f99fd4092a29f2307fa3f046b
+msgid "Click the Snapshot button. |SnapshotButton.png|"
+msgstr ""
+
+#: ../../storage.rst:771
+# 669a8d0c02184e369299bf9d7e5483d2
+msgid "Automatic Snapshot Creation and Retention"
+msgstr ""
+
+#: ../../storage.rst:776
+# 24d0d72217234a93a95c9d1990899367
+msgid "Users can set up a recurring snapshot policy to automatically create multiple snapshots of a disk at regular intervals. Snapshots can be created on an hourly, daily, weekly, or monthly interval. One snapshot policy can be set up per disk volume. For example, a user can set up a daily snapshot at 02:30."
+msgstr ""
+
+#: ../../storage.rst:782
+# 1ddc07ffd4744db3996a56928fabe1b3
+msgid "With each snapshot schedule, users can also specify the number of scheduled snapshots to be retained. Older snapshots that exceed the retention limit are automatically deleted. This user-defined limit must be equal to or lower than the global limit set by the CloudStack administrator. See `“Globally Configured Limits” <usage.html#globally-configured-limits>`_. The limit applies only to those snapshots that are taken as part of an automatic recurring snapshot policy. Additional manual snapshots can be created and retained."
+msgstr ""
+
+#: ../../storage.rst:793
+# cf33bcc958214dce8809b1b3664d8473
+msgid "Incremental Snapshots and Backup"
+msgstr ""
+
+#: ../../storage.rst:795
+# 790dbaf719ea4af3a21944492c933590
+msgid "Snapshots are created on primary storage where a disk resides. After a snapshot is created, it is immediately backed up to secondary storage and removed from primary storage for optimal utilization of space on primary storage."
+msgstr ""
+
+#: ../../storage.rst:800
+# c6a3543640914d2abcb184e9f17b9a33
+msgid "CloudStack does incremental backups for some hypervisors. When incremental backups are supported, every N backup is a full backup."
+msgstr ""
+
+#: ../../storage.rst:807
+# ca4450266a9e41e4ba1d71743809cc71
+msgid "Support incremental backup"
+msgstr ""
+
+#: ../../storage.rst:812
+# 05da4101c8ee4a32a1cd8e61dd902cca
+msgid "Volume Status"
+msgstr ""
+
+#: ../../storage.rst:814
+# 389f5943ba4c4e04be7c271c11632520
+msgid "When a snapshot operation is triggered by means of a recurring snapshot policy, a snapshot is skipped if a volume has remained inactive since its last snapshot was taken. A volume is considered to be inactive if it is either detached or attached to a VM that is not running. CloudStack ensures that at least one snapshot is taken since the volume last became inactive."
+msgstr ""
+
+#: ../../storage.rst:821
+# f6a7564bbd474bb28c93ac2ef46e537f
+msgid "When a snapshot is taken manually, a snapshot is always created regardless of whether a volume has been active or not."
+msgstr ""
+
+#: ../../storage.rst:825
+# e1558eacbe2f4d768b7fe6e226152c57
+msgid "Snapshot Restore"
+msgstr ""
+
+#: ../../storage.rst:827
+# eb2f5defecae49b9a0b4338cc0a8ff65
+msgid "There are two paths to restoring snapshots. Users can create a volume from the snapshot. The volume can then be mounted to a VM and files recovered as needed. Alternatively, a template may be created from the snapshot of a root disk. The user can then boot a VM from this template to effect recovery of the root disk."
+msgstr ""
+
+#: ../../storage.rst:834
+# e9999cd4fd964600a2979344583457d2
+msgid "Snapshot Job Throttling"
+msgstr ""
+
+#: ../../storage.rst:836
+# c31b190ad5a64d5c84c623c66056d37a
+msgid "When a snapshot of a virtual machine is requested, the snapshot job runs on the same host where the VM is running or, in the case of a stopped VM, the host where it ran last. If many snapshots are requested for VMs on a single host, this can lead to problems with too many snapshot jobs overwhelming the resources of the host."
+msgstr ""
+
+#: ../../storage.rst:842
+# b250747385d042f49ad48f81329b10a7
+msgid "To address this situation, the cloud's root administrator can throttle how many snapshot jobs are executed simultaneously on the hosts in the cloud by using the global configuration setting concurrent.snapshots.threshold.perhost. By using this setting, the administrator can better ensure that snapshot jobs do not time out and hypervisor hosts do not experience performance issues due to hosts being overloaded with too many snapshot requests."
+msgstr ""
+
+#: ../../storage.rst:850
+# d1dd9aa964bc44e39ace5434f582dcd1
+msgid "Set concurrent.snapshots.threshold.perhost to a value that represents a best guess about how many snapshot jobs the hypervisor hosts can execute at one time, given the current resources of the hosts and the number of VMs running on the hosts. If a given host has more snapshot requests, the additional requests are placed in a waiting queue. No new snapshot jobs will start until the number of currently executing snapshot jobs falls below the configured limit."
+msgstr ""
+
+#: ../../storage.rst:858
+# 7b49369aa49743b780984cc9c3bd2c52
+msgid "The admin can also set job.expire.minutes to place a maximum on how long a snapshot request will wait in the queue. If this limit is reached, the snapshot request fails and returns an error message."
+msgstr ""
+
+#: ../../storage.rst:863
+# fb6fcac386824780ac7f09de0d50a555
+msgid "VMware Volume Snapshot Performance"
+msgstr ""
+
+#: ../../storage.rst:865
+# 80cd717eab4a487f89e5d530af50dcdf
+msgid "When you take a snapshot of a data or root volume on VMware, CloudStack uses an efficient storage technique to improve performance."
+msgstr ""
+
+#: ../../storage.rst:868
+# 0feb29ffc87942eaa740795e36db3801
+msgid "A snapshot is not immediately exported from vCenter to a mounted NFS share and packaged into an OVA file format. This operation would consume time and resources. Instead, the original file formats (e.g., VMDK) provided by vCenter are retained. An OVA file will only be created as needed, on demand. To generate the OVA, CloudStack uses information in a properties file (\\*.ova.meta) which it stored along with the original snapshot data."
+msgstr ""
+
+#: ../../storage.rst:877
+# de8e361b5b984d8fac0ef05d6f5e03e2
+msgid "For upgrading customers: This process applies only to newly created snapshots after upgrade to CloudStack 4.2. Snapshots that have already been taken and stored in OVA format will continue to exist in that format, and will continue to work as expected."
+msgstr ""
+

http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/65303ea3/source/locale/pot/systemvm.pot
----------------------------------------------------------------------
diff --git a/source/locale/pot/systemvm.pot b/source/locale/pot/systemvm.pot
new file mode 100644
index 0000000..ac462bc
--- /dev/null
+++ b/source/locale/pot/systemvm.pot
@@ -0,0 +1,740 @@
+# SOME DESCRIPTIVE TITLE.
+# Copyright (C) 
+# This file is distributed under the same license as the Apache CloudStack Administration Documentation package.
+# FIRST AUTHOR <EM...@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 <EM...@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"
+
+#: ../../systemvm.rst:18
+# 8be3f4aab5e948cf9ebc392ede63eb61
+msgid "Working with System Virtual Machines"
+msgstr ""
+
+#: ../../systemvm.rst:20
+# 9b5d8dc94fe14b1188a4787951b5b7c1
+msgid "CloudStack uses several types of system virtual machines to perform tasks in the cloud. In general CloudStack manages these system VMs and creates, starts, and stops them as needed based on scale and immediate needs. However, the administrator should be aware of them and their roles to assist in debugging issues."
+msgstr ""
+
+#: ../../systemvm.rst:27
+# e59d13f8791c445b80132078609fc486
+msgid "The System VM Template"
+msgstr ""
+
+#: ../../systemvm.rst:29
+# 6f29f33ed8a249eba1387f295bc684c4
+msgid "The System VMs come from a single template. The System VM has the following characteristics:"
+msgstr ""
+
+#: ../../systemvm.rst:34
+# 9ce666c19d774839b1f8cb4590445c4c
+msgid "Debian 6.0 (\"Squeeze\"), 2.6.32 kernel with the latest security patches from the Debian security APT repository"
+msgstr ""
+
+#: ../../systemvm.rst:39
+# 63fe9d9aeac34acdaa94ec25235705a7
+msgid "Has a minimal set of packages installed thereby reducing the attack surface"
+msgstr ""
+
+#: ../../systemvm.rst:44
+# 8180871802ba4e12bb9ad0c90bfcc6b4
+msgid "32-bit for enhanced performance on Xen/VMWare"
+msgstr ""
+
+#: ../../systemvm.rst:48
+# efa0ecb7d9b340aa94a5b3d97c5df6e2
+msgid "pvops kernel with Xen PV drivers, KVM virtio drivers, and VMware tools for optimum performance on all hypervisors"
+msgstr ""
+
+#: ../../systemvm.rst:53
+# 94cc7872776443ce9c1e37cfda94a603
+msgid "Xen tools inclusion allows performance monitoring"
+msgstr ""
+
+#: ../../systemvm.rst:57
+# 285ca06aefd5405aa00784ffa1cada94
+msgid "Latest versions of HAProxy, iptables, IPsec, and Apache from debian repository ensures improved security and speed"
+msgstr ""
+
+#: ../../systemvm.rst:62
+# b0c807016df746d99783c98f27b847fd
+msgid "Latest version of JRE from Sun/Oracle ensures improved security and speed"
+msgstr ""
+
+#: ../../systemvm.rst:66
+# 980ff8d24ffa4282b0253bd5dced0af0
+msgid "Changing the Default System VM Template"
+msgstr ""
+
+#: ../../systemvm.rst:68
+# bfb28a5b9b2e40cd8ffe8f6283a4e11b
+msgid "CloudStack allows you to change the default 32-bit System VM template to 64-bit one. Using the 64-bit template, upgrade the virtual router to manage larger number of connection in your network."
+msgstr ""
+
+#: ../../systemvm.rst:74
+# a3da003f69c948a283852316ca9ffa82
+msgid "Based on the hypervisor you use, download the 64-bit template from the following location:"
+msgstr ""
+
+#: ../../systemvm.rst:78
+# b74fdcb62bef470783f70197cf39862a
+msgid "Hypervisor"
+msgstr ""
+
+#: ../../systemvm.rst:78
+# 82de6e1547904950afe93194ab91799e
+msgid "Download Location"
+msgstr ""
+
+#: ../../systemvm.rst:80
+# df1edb0301da483f8b0ca187dd744a9a
+msgid "XenServer"
+msgstr ""
+
+#: ../../systemvm.rst:80
+# a9827113f80349149b9e852182c71c66
+msgid "http://download.cloud.com/templates/4.2/64bit/systemvmtemplate64-2013-07-15-master-xen.vhd.bz2"
+msgstr ""
+
+#: ../../systemvm.rst:81
+# d7d1a2ca0edf4236a8b88cb136140a3a
+msgid "KVM"
+msgstr ""
+
+#: ../../systemvm.rst:81
+# e1c0fc4ecafa47c099784ed401cc859f
+msgid "http://download.cloud.com/templates/4.2/64bit/systemvmtemplate64-2013-07-15-master-kvm.qcow2.bz2"
+msgstr ""
+
+#: ../../systemvm.rst:86
+# 1991ed3c7f0a4f1b967f4df8e95a91a8
+msgid "As an administrator, log in to the CloudStack UI"
+msgstr ""
+
+#: ../../systemvm.rst:90
+# b1decf00ede048919d1c784794861c8c
+msgid "Register the 64 bit template."
+msgstr ""
+
+#: ../../systemvm.rst:92
+# 75b465541dca4b75b9478b03231dc561
+msgid "For example: KVM64bitTemplate"
+msgstr ""
+
+#: ../../systemvm.rst:96
+# fe9c54d3437f4392919edcc710f73459
+msgid "While registering the template, select Routing."
+msgstr ""
+
+#: ../../systemvm.rst:100
+# 30ba77a33a2e48628183d0526def5673
+msgid "Navigate to Infrastructure > Zone > Settings."
+msgstr ""
+
+#: ../../systemvm.rst:104
+# b372692c62ad4ab9b6b8bccc49531f94
+msgid "Set the name of the 64-bit template, KVM64bitTemplate, in the *``router.template.kvm``* global parameter."
+msgstr ""
+
+#: ../../systemvm.rst:107
+# 2a574634e2e8493c8da4b269d66aeb8f
+msgid "If you are using a XenServer 64-bit template, set the name in the *``router.template.xen``* global parameter."
+msgstr ""
+
+#: ../../systemvm.rst:110
+# 666051846b1f4a1ea93a880753cd8d27
+msgid "Any new virtual router created in this Zone automatically picks up this template."
+msgstr ""
+
+#: ../../systemvm.rst:115
+# 6c10aa07673b4a3e93b8a6a67399c5c6
+msgid "Restart the Management Server."
+msgstr ""
+
+#: ../../systemvm.rst:118
+# 5822cebf2557488fb14924b61507a3d9
+msgid "Multiple System VM Support for VMware"
+msgstr ""
+
+#: ../../systemvm.rst:120
+# f0ac39803b514fe783d81dc8e27501bf
+msgid "Every CloudStack zone has single System VM for template processing tasks such as downloading templates, uploading templates, and uploading ISOs. In a zone where VMware is being used, additional System VMs can be launched to process VMware-specific tasks such as taking snapshots and creating private templates. The CloudStack management server launches additional System VMs for VMware-specific tasks as the load increases. The management server monitors and weights all commands sent to these System VMs and performs dynamic load balancing and scaling-up of more System VMs."
+msgstr ""
+
+#: ../../systemvm.rst:131
+# 4bfb13dcef06450a869b263a475962c0
+msgid "Console Proxy"
+msgstr ""
+
+#: ../../systemvm.rst:133
+# 1891a33953af4ab5bfa2f0021c9cbcb0
+msgid "The Console Proxy is a type of System Virtual Machine that has a role in presenting a console view via the web UI. It connects the user’s browser to the VNC port made available via the hypervisor for the console of the guest. Both the administrator and end user web UIs offer a console connection."
+msgstr ""
+
+#: ../../systemvm.rst:139
+# 89e2955ebed34f69ad899a6ccf98a150
+msgid "Clicking a console icon brings up a new window. The AJAX code downloaded into that window refers to the public IP address of a console proxy VM. There is exactly one public IP address allocated per console proxy VM. The AJAX application connects to this IP. The console proxy then proxies the connection to the VNC port for the requested VM on the Host hosting the guest."
+msgstr ""
+
+#: ../../systemvm.rst:147
+# 56d88ad46e2745acb147e3b0cc16c012
+msgid "The hypervisors will have many ports assigned to VNC usage so that multiple VNC sessions can occur simultaneously."
+msgstr ""
+
+#: ../../systemvm.rst:149
+# bfa2d281e05b47a2a090213554adea82
+msgid "There is never any traffic to the guest virtual IP, and there is no need to enable VNC within the guest."
+msgstr ""
+
+#: ../../systemvm.rst:152
+# 956afe779c6a4490bf06ba6b3c8d9b7a
+msgid "The console proxy VM will periodically report its active session count to the Management Server. The default reporting interval is five seconds. This can be changed through standard Management Server configuration with the parameter consoleproxy.loadscan.interval."
+msgstr ""
+
+#: ../../systemvm.rst:157
+# 6ba80d42bac146da89dd7c0ddfaed6b9
+msgid "Assignment of guest VM to console proxy is determined by first determining if the guest VM has a previous session associated with a console proxy. If it does, the Management Server will assign the guest VM to the target Console Proxy VM regardless of the load on the proxy VM. Failing that, the first available running Console Proxy VM that has the capacity to handle new sessions is used."
+msgstr ""
+
+#: ../../systemvm.rst:164
+# d3194eb67f53470798abbefc2170f007
+msgid "Console proxies can be restarted by administrators but this will interrupt existing console sessions for users."
+msgstr ""
+
+#: ../../systemvm.rst:168
+# 5477616ef10c44a99bd0e5d91ee3c9d3
+msgid "Using a SSL Certificate for the Console Proxy"
+msgstr ""
+
+#: ../../systemvm.rst:171
+# 7c9861003bfe4abe99b1cfd073a0fe0e
+msgid "In the past CloudStack used the ``realhostip.com`` dynamic  DNS resolution service. As this service will be shut down as of  June 30th, 2014, CloudStack has stopped using the service as of version 4.3."
+msgstr ""
+
+#: ../../systemvm.rst:173
+# 0e590e7788f44b4d9a3b9ad796811333
+msgid "By default, the console viewing functionality uses plaintext HTTP. In any production environment, the console proxy connection should be encrypted via SSL at the mininum."
+msgstr ""
+
+#: ../../systemvm.rst:177
+# 0ff02ca358074c6ca30f83692bfe9919
+msgid "A CloudStack administrator has 2 ways to secure the console proxy communication with SSL:"
+msgstr ""
+
+#: ../../systemvm.rst:181
+# 7e0bf8a823b04926a0b9e726bb3b5429
+msgid "Set up a SSL wild-card certificate and domain name resolution"
+msgstr ""
+
+#: ../../systemvm.rst:184
+# cb6ce63cfc6c44c495463deb0c8d9069
+msgid "Set up SSL certificate for specific FQDN and configure load-balancer"
+msgstr ""
+
+#: ../../systemvm.rst:188
+# 3417b2470c9f4f539baac5d4cc994cae
+msgid "Changing the Console Proxy SSL Certificate and Domain"
+msgstr ""
+
+#: ../../systemvm.rst:190
+# 7002d85817e54eac8bb42dfe7bd4f2e2
+msgid "The administrator can configure SSL encryption  by selecting a domain and uploading a new SSL certificate and private key. The domain must run a DNS service that is capable of resolving queries for addresses of the form aaa-bbb-ccc-ddd.your.domain to an IPv4 IP address in the form aaa.bbb.ccc.ddd, for example, 202.8.44.1. To change the console proxy domain, SSL certificate, and private key:"
+msgstr ""
+
+#: ../../systemvm.rst:199
+# 528c9b8be4d14a0ab8403dff3eef4bf0
+msgid "Set up dynamic name resolution or populate all possible DNS names in your public IP range into your existing DNS server with the format aaa-bbb-ccc-ddd.consoleproxy.company.com -> aaa.bbb.ccc.ddd."
+msgstr ""
+
+#: ../../systemvm.rst:204
+# 0ec80daec466449db79404dbbf71124a
+msgid "In these steps you will notice *consoleproxy.company.com* -For security best practices, we recommend creating a wildcard SSL certificate on a separate subdomain so in the event that the certificate is compromised, a malicious user cannot impersonate a company.com domain."
+msgstr ""
+
+#: ../../systemvm.rst:208
+# 1484d83d7dcf452fbf59cb14fb8a2ac9
+msgid "Generate the private key and certificate signing request (CSR). When you are using openssl to generate private/public key pairs and CSRs, for the private key that you are going to paste into the CloudStack UI, be sure to convert it into PKCS#8 format."
+msgstr ""
+
+#: ../../systemvm.rst:215
+# 8d2e65e2ba1541cab43c314bde8a0285
+msgid "Generate a new 2048-bit private key"
+msgstr ""
+
+#: ../../systemvm.rst:223
+# 3067b8795544424aba9ba004412ba13e
+msgid "Generate a new certificate CSR. Ensure the creation of a wildcard certificate, eg *.consoleproxy.company.com"
+msgstr ""
+
+#: ../../systemvm.rst:232
+# c09f472413874e608a2ba56b2f252be7
+msgid "Head to the website of your favorite trusted Certificate Authority, purchase an SSL certificate, and submit the CSR. You should receive a valid certificate in return"
+msgstr ""
+
+#: ../../systemvm.rst:238
+# 6d8e7177a0674ed5ba0017acb2023cf0
+msgid "Convert your private key format into PKCS#8 encrypted format."
+msgstr ""
+
+#: ../../systemvm.rst:246
+# e84ab195ef4745de94b29161c636eb66
+msgid "Convert your PKCS#8 encrypted private key into the PKCS#8 format that is compliant with CloudStack"
+msgstr ""
+
+#: ../../systemvm.rst:255
+# e2eb37bdbd9348a49345d7ab4af8407a
+msgid "In the Update SSL Certificate screen of the CloudStack UI, paste the following:"
+msgstr ""
+
+#: ../../systemvm.rst:260
+# 0e5339200c5d495d81a2fa3b605140fd
+msgid "The certificate you've just generated."
+msgstr ""
+
+#: ../../systemvm.rst:264
+# 2ff7b3e117b34b79984384ff67d02a33
+msgid "The private key you've just generated."
+msgstr ""
+
+#: ../../systemvm.rst:268
+# 4ad81c4f609149a6ab2643fb3e4e52b7
+msgid "The desired domain name, prefixed with ``*.``; for example, *.consoleproxy.company.com"
+msgstr ""
+
+#: ../../systemvm.rst:270
+# c4b5f9b94d3a4ac5a9cb7cf8aab71229
+msgid "|update-ssl.png|"
+msgstr ""
+
+#: ../../systemvm.rst:274
+# 3c0c071f698549f2b472be8f635c3843
+msgid "This stops all currently running console proxy VMs, then restarts them with the new certificate and key. Users might notice a brief interruption in console availability."
+msgstr ""
+
+#: ../../systemvm.rst:278
+# 1d1a2c29eb6e49b8ac44653667dd7acc
+msgid "The Management Server generates URLs of the form \"aaa-bbb-ccc-ddd.consoleproxy.company.com\" after this change is made. The new console requests will be served with the new DNS domain name, certificate, and key."
+msgstr ""
+
+#: ../../systemvm.rst:284
+# a4bf2c5975d3412ea4e3aaa92e552a0c
+msgid "Load-balancing Console Proxies"
+msgstr ""
+
+#: ../../systemvm.rst:285
+# fe7709e48afe4cd7ab9f0a1fd1490af4
+msgid "An alternative to using dynamic DNS or creating a range of DNS entries as described in the last section would be to create a SSL certificate for a specific domain name, configure CloudStack to use that particular FQDN, and then configure a load balancer to load balance the console proxy's IP address behind the FQDN. As the functionality for this is still new, please see https://cwiki.apache.org/confluence/display/CLOUDSTACK/Realhost+IP+changes for more details."
+msgstr ""
+
+#: ../../systemvm.rst:295
+# 9af4851426194c41a2501ab36c4a159f
+msgid "Virtual Router"
+msgstr ""
+
+#: ../../systemvm.rst:297
+# 9ce6e91707bc4a7e991bc3c105ad6469
+msgid "The virtual router is a type of System Virtual Machine. The virtual router is one of the most frequently used service providers in CloudStack. The end user has no direct access to the virtual router. Users can ping the virtual router and take actions that affect it (such as setting up port forwarding), but users do not have SSH access into the virtual router."
+msgstr ""
+
+#: ../../systemvm.rst:304
+# 2522b8aa1b924af2a9e4949a1d5d9f69
+msgid "There is no mechanism for the administrator to log in to the virtual router. Virtual routers can be restarted by administrators, but this will interrupt public network access and other services for end users. A basic test in debugging networking issues is to attempt to ping the virtual router from a guest VM. Some of the characteristics of the virtual router are determined by its associated system service offering."
+msgstr ""
+
+#: ../../systemvm.rst:312
+# e45ecc9391d642928809c57529dc7c1d
+msgid "Configuring the Virtual Router"
+msgstr ""
+
+#: ../../systemvm.rst:314
+# 7d13b8bb3b1a4a16b722a92b49334947
+msgid "You can set the following:"
+msgstr ""
+
+#: ../../systemvm.rst:318
+# 44b8835e26ea4246b96ebb3462ae7d47
+msgid "IP range"
+msgstr ""
+
+#: ../../systemvm.rst:322
+# ba1e4554a5cb4fadb85802fc8dfa10e4
+msgid "Supported network services"
+msgstr ""
+
+#: ../../systemvm.rst:326
+# b24a9cab32c441a4a6c1f5c392b01534
+msgid "Default domain name for the network serviced by the virtual router"
+msgstr ""
+
+#: ../../systemvm.rst:330
+# bde8e898b23e47a49b93858446f8b2c3
+msgid "Gateway IP address"
+msgstr ""
+
+#: ../../systemvm.rst:334
+# 90d3eeaccd7a4d24931e20da1b3e3734
+msgid "How often CloudStack fetches network usage statistics from CloudStack virtual routers. If you want to collect traffic metering data from the virtual router, set the global configuration parameter router.stats.interval. If you are not using the virtual router to gather network usage statistics, set it to 0."
+msgstr ""
+
+#: ../../systemvm.rst:341
+# 33174573568c462da9b9bb8f32ac5da9
+msgid "Upgrading a Virtual Router with System Service Offerings"
+msgstr ""
+
+#: ../../systemvm.rst:343
+# 4128bcaf29264574bcb5520add843d5c
+msgid "When CloudStack creates a virtual router, it uses default settings which are defined in a default system service offering. See `“System Service Offerings” <#system-service-offerings>`_. All the virtual routers in a single guest network use the same system service offering. You can upgrade the capabilities of the virtual router by creating and applying a custom system service offering."
+msgstr ""
+
+#: ../../systemvm.rst:352
+# 6ff917ce569a4851ac880b4dda7f12e4
+msgid "Define your custom system service offering. See `“Creating a New System Service Offering” <#creating-a-new-system-service-offering>`_. In System VM Type, choose Domain Router."
+msgstr ""
+
+#: ../../systemvm.rst:358
+# 7cddcde709a1400297d4e1f750058515
+msgid "Associate the system service offering with a network offering. See `“Creating a New Network Offering” <networking.html#creating-a-new-network-offering>`_."
+msgstr ""
+
+#: ../../systemvm.rst:363
+# de01c46a779f4d83af353a858610a991
+msgid "Apply the network offering to the network where you want the virtual routers to use the new system service offering. If this is a new network, follow the steps in Adding an Additional Guest Network on page 66. To change the service offering for existing virtual routers, follow the steps in `“Changing the Network Offering on a Guest Network” <networking2.html#changing-the-network-offering-on-a-guest-network>`_."
+msgstr ""
+
+#: ../../systemvm.rst:371
+# b524a14c48bc495cadc308d7b63ac2a4
+msgid "Best Practices for Virtual Routers"
+msgstr ""
+
+#: ../../systemvm.rst:375
+# 0b2febff4097420d96a2ff9ef1aeaf46
+msgid "WARNING: Restarting a virtual router from a hypervisor console deletes all the iptables rules. To work around this issue, stop the virtual router and start it from the CloudStack UI."
+msgstr ""
+
+#: ../../systemvm.rst:382
+# 33e6af6c5b92437593f1714d86528d52
+msgid "Do not use the destroyRouter API when only one router is available in the network, because restartNetwork API with the cleanup=false parameter can't recreate it later. If you want to destroy and recreate the single router available in the network, use the restartNetwork API with the cleanup=true parameter."
+msgstr ""
+
+#: ../../systemvm.rst:385
+# e1f923bf381241aa8b2f6e0525dbd7c3
+msgid "Service Monitoring Tool for Virtual Router"
+msgstr ""
+
+#: ../../systemvm.rst:387
+# 166c312922e14f80ba6eaa81286860a4
+msgid "Various services running on the CloudStack virtual routers can be monitored by using a Service Monitoring tool. The tool ensures that services are successfully running until CloudStack deliberately disables them. If a service goes down, the tool automatically restarts the service, and if that does not help bringing up the service, an alert as well as an event is generated indicating the failure. A new global parameter, ``network.router.enableservicemonitoring``, has been introduced to control this feature. The default value is false, implies, monitoring is disabled. When you enable, ensure that the Management Server and the router are restarted."
+msgstr ""
+
+#: ../../systemvm.rst:391
+# f2aa21d6fd1645609a2c098d6d09bccc
+msgid "Monitoring tool can help to start a VR service, which is crashed due to an unexpected reason. For example:"
+msgstr ""
+
+#: ../../systemvm.rst:396
+# 90673418a28f414f9cf60f53a4a2b2c3
+msgid "The services crashed due to defects in the source code."
+msgstr ""
+
+#: ../../systemvm.rst:400
+# 7de0e474327d491a96aacd4fb31eecec
+msgid "The services that are terminated by the OS when memory or CPU is not sufficiently available for the service."
+msgstr ""
+
+#: ../../systemvm.rst:404
+# f92166fbe86541dea2b8ef0ac17616a7
+msgid "Only those services with daemons are monitored. The services that are failed due to errors in the service/daemon configuration file cannot be restarted by the Monitoring tool. VPC networks are not supported."
+msgstr ""
+
+#: ../../systemvm.rst:406
+# e834c36c5253482cadb9ee5127097911
+msgid "The following services are monitored in a VR:"
+msgstr ""
+
+#: ../../systemvm.rst:410
+#: ../../systemvm.rst:487
+# 5eb9ccfaf20f479f9a7b4cee96aedfa8
+# 5dab896f995444178c11b71d812ef1e4
+msgid "DNS"
+msgstr ""
+
+#: ../../systemvm.rst:414
+# 12d6fc507c824f6eb84aded5da24244a
+msgid "HA Proxy"
+msgstr ""
+
+#: ../../systemvm.rst:418
+# 51b1f6716b2745c4a097cc59d32242a6
+msgid "SSH"
+msgstr ""
+
+#: ../../systemvm.rst:422
+# 3dfcf65152e54be5bdf65e04ef4ada39
+msgid "Apache Web Server"
+msgstr ""
+
+#: ../../systemvm.rst:424
+# 4c17b9d1a4414d47acd51913cd1be094
+msgid "The following networks are supported:"
+msgstr ""
+
+#: ../../systemvm.rst:428
+# 28e056cf7a134d9cae449b40828ba914
+msgid "Isolated Networks"
+msgstr ""
+
+#: ../../systemvm.rst:432
+# 8384bb1c2d7c4e2ab34d88425ad4a1cf
+msgid "Shared Networks in both Advanced and Basic zone"
+msgstr ""
+
+#: ../../systemvm.rst:434
+# e8b7509b71234cecbac0aa2646beba62
+msgid "VPC networks are not supported"
+msgstr ""
+
+#: ../../systemvm.rst:436
+# 744b64cc707645a3a88ce7550f3a51f6
+msgid "This feature is supported on the following hypervisors: XenServer, VMware, and KVM."
+msgstr ""
+
+#: ../../systemvm.rst:440
+# 9559bdb81188441197d3737020a4f5d3
+msgid "Enhanced Upgrade for Virtual Routers"
+msgstr ""
+
+#: ../../systemvm.rst:442
+# 894d5248559d4c9fb2de284c4e9d8434
+msgid "Upgrading VR is made flexible. The CloudStack administrators will be able to control the sequence of the VR upgrades. The sequencing is based on Infrastructure hierarchy, such as by Cluster, Pod, or Zone, and Administrative (Account) hierarchy, such as by Tenant or Domain. As an administrator, you can also determine when a particular customer service, such as VR, is upgraded within a specified upgrade interval. Upgrade operation is enhanced to increase the upgrade speed by allowing as many upgrade operations in parallel as possible."
+msgstr ""
+
+#: ../../systemvm.rst:451
+# 390d4db6cf7b4418bfeb14d1a1c823de
+msgid "During the entire duration of the upgrade, users cannot launch new services or make changes to an existing service."
+msgstr ""
+
+#: ../../systemvm.rst:454
+# 8f52ba2d3aaa400fbadbc9370ab8bec3
+msgid "Additionally, using multiple versions of VRs in a single instance is supported. In the Details tab of a VR, you can view the version and whether it requires upgrade. During the Management Server upgrade, CloudStack checks whether VR is at the latest version before performing any operation on the VR. To support this, a new global parameter, *``router.version.check``*, has been added. This parameter is set to true by default, which implies minimum required version is checked before performing any operation. No operation is performed if the VR is not at the required version. Services of the older version VR continue to be available, but no further operations can be performed on the VR until it is upgraded to the latest version. This will be a transient state until the VR is upgraded. This will ensure that the availability of VR services and VR state is not impacted due to the Management Server upgrade."
+msgstr ""
+
+#: ../../systemvm.rst:469
+# 2331fd6f14b74031838819c4c9b6ebb7
+msgid "The following service will be available even if the VR is not upgraded. However, no changes for any of the services can be sent to the VR, until it is upgraded:"
+msgstr ""
+
+#: ../../systemvm.rst:475
+# 7516020ea8e044fb88f03f243dc262c8
+msgid "SecurityGroup"
+msgstr ""
+
+#: ../../systemvm.rst:479
+# f5c9179d8b634903b4ed88d21547163f
+msgid "UserData"
+msgstr ""
+
+#: ../../systemvm.rst:483
+# a841e81bc7f840cd90bde9fac872c5c4
+msgid "DHCP"
+msgstr ""
+
+#: ../../systemvm.rst:491
+# 05e911e9b8264679b13442e754ba881c
+msgid "LB"
+msgstr ""
+
+#: ../../systemvm.rst:495
+# f42a3ac7fca94077ba20fe12c98f4d78
+msgid "Port Forwarding"
+msgstr ""
+
+#: ../../systemvm.rst:499
+# 00acf0cb58cf46d38ce34b163e25e276
+msgid "VPN"
+msgstr ""
+
+#: ../../systemvm.rst:503
+# dd5fa0de47874783993d5994dc2fd2f5
+msgid "Static NAT"
+msgstr ""
+
+#: ../../systemvm.rst:507
+# 442821509b954101b664febb12148e0e
+msgid "Source NAT"
+msgstr ""
+
+#: ../../systemvm.rst:511
+# 976cf6d3ec014a5fa46956c266814608
+msgid "Firewall"
+msgstr ""
+
+#: ../../systemvm.rst:515
+# a952c4dfb48c40128f21c886c8344dc6
+msgid "Gateway"
+msgstr ""
+
+#: ../../systemvm.rst:519
+# de23c8c7f9844a17aedffe2a73f69611
+msgid "NetworkACL"
+msgstr ""
+
+#: ../../systemvm.rst:522
+# e4882b2d87d54dd3bc156802ff35c064
+msgid "Supported Virtual Routers"
+msgstr ""
+
+#: ../../systemvm.rst:526
+# 4d87bcbc7b9e43e5a9eca2df6be5d5ac
+msgid "VR"
+msgstr ""
+
+#: ../../systemvm.rst:530
+# 2366a655dfd34f968eb66f89ef1061e4
+msgid "VPC VR"
+msgstr ""
+
+#: ../../systemvm.rst:534
+# cf2ef91163e843d68825b0a5a4b95b6e
+msgid "Redundant VR"
+msgstr ""
+
+#: ../../systemvm.rst:537
+# 40a69f9a229a49388862563f000c4860
+msgid "Upgrading Virtual Routers"
+msgstr ""
+
+#: ../../systemvm.rst:541
+# 51999619ca9449acb43f2b7ff514e0f5
+msgid "Download the latest System VM template."
+msgstr ""
+
+#: ../../systemvm.rst:545
+# 2b9f628af9ae4dfa85e753fbe4df2b62
+msgid "Download the latest System VM to all the primary storage pools."
+msgstr ""
+
+#: ../../systemvm.rst:549
+# d67082be8aa144a590daf97a8e1a3f19
+msgid "Upgrade the Management Server."
+msgstr ""
+
+#: ../../systemvm.rst:553
+# 4a0db3a39c01439ab7d5ed74da052a23
+msgid "Upgrade CPVM and SSVM either from the UI or by using the following script:"
+msgstr ""
+
+#: ../../systemvm.rst:560
+# 75f1e4536fea4cc7b74f72f92c4ce4ed
+msgid "Even when the VRs are still on older versions, existing services will continue to be available to the VMs. The Management Server cannot perform any operations on the VRs until they are upgraded."
+msgstr ""
+
+#: ../../systemvm.rst:566
+# 52d169af58f5479d97ba0aa2d39427ba
+msgid "Selectively upgrade the VRs:"
+msgstr ""
+
+#: ../../systemvm.rst:570
+# bf46425e15e94970b120dc56e0a09344
+msgid "Log in to the CloudStack UI as the root administrator."
+msgstr ""
+
+#: ../../systemvm.rst:574
+# bc21fde401934629b30ec8c8ca4cf278
+msgid "In the left navigation, choose Infrastructure."
+msgstr ""
+
+#: ../../systemvm.rst:578
+# 4e8fccd1f33c40ccb6ed22ee6e8d332c
+msgid "On Virtual Routers, click View More."
+msgstr ""
+
+#: ../../systemvm.rst:580
+# f592498dba844e608a98645a5e029d73
+msgid "All the VRs are listed in the Virtual Routers page."
+msgstr ""
+
+#: ../../systemvm.rst:584
+# 8e507a8910a34e0ebdfe3d328e34a57a
+msgid "In Select View drop-down, select desired grouping based on your requirement."
+msgstr ""
+
+#: ../../systemvm.rst:587
+# f855b4bee2804bcfa3ed201dec42a5f9
+msgid "You can use either of the following:"
+msgstr ""
+
+#: ../../systemvm.rst:591
+# 01bf9acb8a8b466ba5c27d2d9a86a200
+msgid "Group by zone"
+msgstr ""
+
+#: ../../systemvm.rst:595
+# d8c3db41d03b415c9be8e88d8a30cbdd
+msgid "Group by pod"
+msgstr ""
+
+#: ../../systemvm.rst:599
+# a0cadfeca2fc4c36a1b9ec6f62173efd
+msgid "Group by cluster"
+msgstr ""
+
+#: ../../systemvm.rst:603
+# 172c882d2b264bf7adc756a2abf1f7bc
+msgid "Group by account"
+msgstr ""
+
+#: ../../systemvm.rst:607
+# a0bb9324a5594bb3b533bac200ac7f3f
+msgid "Click the group which has the VRs to be upgraded."
+msgstr ""
+
+#: ../../systemvm.rst:609
+# 11b6bdc33790432a9a05952ef21703ca
+msgid "For example, if you have selected Group by zone, select the name of the desired zone."
+msgstr ""
+
+#: ../../systemvm.rst:614
+# 26032885ac044b0a9f38285436395a3e
+msgid "Click the Upgrade button to upgrade all the VRs. |vr-upgrade.png|"
+msgstr ""
+
+#: ../../systemvm.rst:618
+# 41f6eec247474ec98c1088ddc2f8b1af
+msgid "Click OK to confirm."
+msgstr ""
+
+#: ../../systemvm.rst:621
+# 9a9ab1374064436ab421237b3915f8ed
+msgid "Secondary Storage VM"
+msgstr ""
+
+#: ../../systemvm.rst:623
+# a30a067a625b4308ada0c22ba29b3f0f
+msgid "In addition to the hosts, CloudStack’s Secondary Storage VM mounts and writes to secondary storage."
+msgstr ""
+
+#: ../../systemvm.rst:626
+# 4b35371f113244a284b9c6c317ed00e7
+msgid "Submissions to secondary storage go through the Secondary Storage VM. The Secondary Storage VM can retrieve templates and ISO images from URLs using a variety of protocols."
+msgstr ""
+
+#: ../../systemvm.rst:630
+# 5d192f685cb44355936e873868c40732
+msgid "The secondary storage VM provides a background task that takes care of a variety of secondary storage activities: downloading a new template to a Zone, copying templates between Zones, and snapshot backups."
+msgstr ""
+
+#: ../../systemvm.rst:634
+# 9d38d1ca3ce44e2e89de62903f01097f
+msgid "The administrator can log in to the secondary storage VM if needed."
+msgstr ""
+