source/adminguide/locale/zh_CN/LC_MESSAGES/storage.mo (23 lines of code) (raw):

���t� � � � � �� Yl#�z�e.�� ��+/�A����(X��#[����;)Nxt��m:f"�� �F�&h;a�/j62�c�%8�^�#� �� �N#��#��$ �%�%W&�i&.'K'9]'��'$|)��*T�+�+ , ,&,�F,��,1j-,�-�-P�-:.L?/C�/W�/�(0*�0&$1 K1l1�p1KG3��4/`57�57�5A6$B6"g61�6-�60�6K7g7 k7[y7=�788N8i:�y:�<=#=@=�Q=#@>d>hv>��>�@�@��@��A�:C�D �D��D�G�G(�G/H�LH6I]JIS�I.�I�+K��KaRL=�L?�M;2NUnN{�N�@O��O��P�Q��Q�R��RV�Th�TXU9lU�U��U1�V��V/�X$�YZ Z5ZJZOZTZ"[Z~Z&�Z �Z3�Z��[��\Gm]��]��^V$_v{_F�_p9a�b�c{�d�-e��e�f��hdjyj�j �jO�jl ll�:l�,n�*oJ�o�3q��q(�r�s/�t3vYPvL�vp�vthw�w��w�y�y��y�|zIH{�{��{ 3|%@|f| }| �|�|.�|�|u�|T^}��~}H��v��B�ua��ׁc�s�u�� ���Bք�2�C�ES���_��Y �*f�Y��'�Y�m������wيlQ�����T�� �ُ �^���U��%�$8��]� ����Hϔ�.� 6�A��a���Bf�*��Ԗ?��3�H �>U�P����!��!ə���������:P�.��.��<�&� ?�#`�$��$��VΞ%� )�b7�B��ݟ��� �� ��ޣ�� ����+��� �[��{�� %��2�(اQ� S� `�m�����!��$ݬ��-í-�A�a��d���Iy� ð6�+�RG�\��]���U��������;� �?��K<�W���*��'��=�'�y����!��������λӻػ߻��� �$��'�}��K/��{�z?�L��W��_�KQ����m�Zp�w���C����z��� %�2� B��L�A�E� `�����M��>����y���N� 6��W�  �3�TM�6��j��rD���(KVM only) Restart the VM.(KVM only) Stop the VM.(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.(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.(Supported for the following hypervisors: **XenServer**, **VMware vSphere**, and **KVM**)(Supported on XenServer and VMware)(XenServer, VMware) You can live migrate a VM's root disk from one storage pool to another, without stopping the VM first.**Fiber Channel support****Format for Disks, Templates, and Snapshots****Local storage support****NFS support****SMB/CIFS****Storage over-provisioning****To enable root disk reset on VM reboot:****iSCSI support**A completed snapshot is copied from primary storage to secondary storage, where it is stored until deleted or purged by newer snapshot.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.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.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.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.Administrators add primary storage to the system by creating a CloudStack storage pool. Each storage pool is associated with a cluster or a zone.Administrators should adjust these values depending on site policies around data retention.Administrators should monitor the capacity of primary storage devices and add additional primary storage as needed. See the Advanced Installation Guide.Attach the volume to any desired VM running in the same cluster as the new storage server. See `“Attaching a Volume” <#attaching-a-volume>`_Attaching a VolumeAutomatic Snapshot Creation and RetentionAvailability Zone. Choose the zone where you want to store the volume. VMs running on hosts in this zone can attach the volume.Availability Zone. Where do you want the storage to reside? This should be close to the VM that will use the volume.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.Before you try to resize a volume, consider the following:Best Practices for Primary StorageCitrix XenServerClick OK.Click Shrink OK to confirm that you are reducing the size of a volume.Click Upload Volume.Click the Migrate Volume button |Migrateinstance.png| and choose the destination from the dropdown list.Click the Migrate button |Migrateinstance.png| and choose the destination from the dropdown list.Click the Snapshot button. |SnapshotButton.png|Click the name of the volume you want to detach, then click the Detach Disk button. |DetachDiskButton.png|Click the name of the volume you want to snapshot.Click the volume name in the Volumes list, then click the Attach Disk button |AttachDiskButton.png|Click the volume you want to migrate.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.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.CloudStack does incremental backups for some hypervisors. When incremental backups are supported, every N backup is a full backup.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.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.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.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.Clustered LVMCreating a New VolumeDetach the disk from its current VM, move it to new storage, and attach it to a new VM.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.Detaching and Moving VolumesDisk Image FormatDisk Offering. Choose the characteristics of the storage.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).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.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.Format. Choose one of the following to indicate the disk image format of the volume.How to Snapshot a VolumeHyper-VHypervisorHypervisor Support for Primary StorageIf 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.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.If you select Custom Disk, specify a custom size.In Select View, be sure Volumes is selected.In Select View, choose Volumes.In order for local volumes to be used, the feature must be enabled for the zone.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.In the Resize Volume pop-up, choose desired characteristics for the storage.In the left navigation bar, click Instances, and click the VM name.In the left navigation bar, click Instances, click the VM name, and click View Volumes.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.In the left navigation bar, click Storage.In the left navigation, click Storage.Incremental Snapshots and BackupKVMKVM 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 availableLocal 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.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.Log in to the CloudStack UI as a user or admin.Log in to the CloudStack UI as a user or administrator.Log in to the CloudStack UI as an administrator or userMD5 checksum. (Optional) Use the hash that you created in step 1.Maintenance Mode for Primary StorageMigrating Storage For a Running VMMigrating Storage and Attaching to a Different VMMigrating a Data Volume to a New Storage PoolMigrating a VM Root Volume to a New Storage PoolMove the disk to new storage, but leave it attached to the same running VM.NFSNFS and iSCSIName and Description. Any desired name and a brief description that can be shown in the UI.Name. Give the volume a unique name so you can find it later.NoOVAOn 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.Primary StoragePrimary 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.Provide the following:QCOW2Reset VM to New Root Disk on RebootResizing VolumesRoot 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.Runtime Behavior of Primary StorageSecondary StorageSelect the volume name in the Volumes list, then click the Resize Volume button |resize-volume-icon.png|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.Snapshot Job ThrottlingSnapshot RestoreSnapshots 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.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.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.Storage OverviewStorage TagsStorage 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.Storage media \\ hypervisorSupport incremental backupSupported in XenServer, KVM, and VMware.The VMs associated with the volume are stopped.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.The data disks associated with the volume are removed.The deletion of a volume does not delete the snapshots that have been created from the volumeThe following table shows storage options and parameters for different hypervisors.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.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 useThe speed of primary storage will impact guest performance. If possible, choose smaller, higher RPM drives or SSDs for primary storage.The upload is performed using HTTP. The uploaded volume is placed in the zone's secondary storageThere 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.There are two situations when you might want to migrate a disk:There are two ways CloudStack can leverage primary storage:There is no ephemeral storage in CloudStack. All volumes on all nodes are persistent.This feature is supported on KVM, XenServer, and VMware hosts. However, shrinking volumes is not supported on VMware hosts.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.This procedure is different from moving disk volumes from one VM to another as described in `“Detaching and Moving Volumes” <#detaching-and-moving-volumes>`_.This procedure is different from moving volumes from one storage pool to another as described in `“VM Storage Migration” <#vm-storage-migration>`_.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.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.To Create a New VolumeTo 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.To create a new volume, click Add Volume, provide the following details, and click OK.To move the volume to another VM, follow the steps in `“Attaching a Volume” <#attaching-a-volume>`_.To resize a volume:To start using the volume, continue to Attaching a VolumeTo upload a volume: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:Uploading an Existing Volume to a Virtual MachineUsers 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.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.Using Local Storage for Data VolumesVHDVHD Snapshots are not supported.VM Storage MigrationVMDKVMFSVMwareVMware Volume Snapshot PerformanceVMware vSphereVolume Deletion and Garbage CollectionVolume StatusVolumes 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.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.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.Watch for the volume status to change to Migrating, then back to Ready.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.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.When a VM is destroyed, data disk volumes that are attached to the VM are not deleted.When a snapshot is taken manually, a snapshot is always created regardless of whether a volume has been active or not.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.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.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.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>`_.When the volume has been attached, you should be able to see it by clicking Instances, the instance name, and View Volumes.When you take a snapshot of a data or root volume on VMware, CloudStack uses an efficient storage technique to improve performance.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.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.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).Working With VolumesWorking with StorageWorking with Volume SnapshotsXenServerXenServer 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.YesYes, via Existing SRYes, via Shared MountpointYou 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.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.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.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.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.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.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.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.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``http://yourFileServerIP/userdata/myDataDisk.vhd```expunge.delay`: determines how old the volume must be before it is destroyed, in seconds`expunge.interval`: determines how often to run the garbage collection check`“About Primary Storage” <http://docs.cloudstack.apache.org/en/latest/concepts.html#about-primary-storage>`_`“About Secondary Storage” <http://docs.cloudstack.apache.org/en/latest/concepts.html#about-secondary-storage>`_|resize-volume.png|Project-Id-Version: Apache CloudStack Administration RTD Report-Msgid-Bugs-To: POT-Creation-Date: 2014-06-30 12:52+0200 PO-Revision-Date: 2014-06-30 12:04+0000 Last-Translator: FULL NAME <EMAIL@ADDRESS> Language-Team: Chinese (China) (http://www.transifex.com/projects/p/apache-cloudstack-administration-rtd/language/zh_CN/) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Language: zh_CN Plural-Forms: nplurals=1; plural=0; (仅限于KVM)重启VM。(仅限于KVM)停止VM。(KVM)当前已root磁盘卷的时候,VM必须关机,这时用户不能访问VM。在迁移完成之后,VM就能重启了。(可选项)为将要上传的磁盘镜像文件创建一个MD5哈希(校验)。再上传数据磁盘之后,CloudStack将使用这个校验值来检查这个磁盘文件再上传过程中没有出错。(支持以下hypervisors:**XenServer**, **VMware vSphere** 和 **KVM**)(支持XenServer和VMware)(XenServer、VMware)你可以在停止VM的情况下,使用在线迁移将VM的root磁盘从一个存储池移动到另外一个。**支持FC****磁盘、模板和快照的格式****支持本地存储****支持NFS****SMB/CIFS****存储超配****要启用在VM重启时重置root磁盘:****支持iSCSI**完整快照慧聪主存储拷贝到附加存储,并会一直存储在里面知道删除或被新的快照覆盖。快照不会立即从vCenter导出OVA格式文件到挂载的NFS共享中。这个操作会消耗时间和资源。相反的,由vCenter提供的原始文件格式(比如VMDK)被保留。OVA文件只有在需要的时候被创建。CloudStack使用与原始快照数据存储在一起的属性文件(\*.ova.meta)中的信息来生成OVA。卷可以从来宾虚机上卸载再附加到其他来宾虚机上。CloudStack管理员和用户都能从VMs上卸载卷再给其他VMs附加上。卷为来宾虚机提供存储。卷可以作为root分区或附加数据磁盘。CloudStack支持为来宾虚机添加卷。另外,使用 resizeVolume API,数据卷可以从一个静态磁盘方案移动到指定大小的自定义磁盘方案。此功能允对特定容量或磁盘方案进行收费,同时可以灵活地更改磁盘大小。管理员通过CloudStack创建存储池来给系统添加主存储。每个存储池对应一个群集或者区域。管理员可以根据站点数据保留策略来调整这些值。管理员可以监控主存储设备的容量和在需要时添加其他的主存储。强参阅高级安装指导。在新的存储服务器中给运行在同一群集中的任何想要的VM附加卷。请参阅 `“附加卷” <#attaching-a-volume>`_。附加一个卷创建和保留自动快照可用的区域:选择你想存储卷的区域。运行在该区域中的主机上的VMs都可以附加这个卷。可用的资源域。你想让这个存储在哪个地方有效?这个应该接近要是用这个卷的VM。(就是说你要 在单个资源域内使用这个存储就选择单个资源域,如果此存储要在多个资源与内共享你就选所有资源域)由于VMware中的限制,仅当源和目标存储池都能被源主机访问时才允许VM存储的在线迁移;也就是说,当需要在线迁移操作时,源主机是运行VM的主机。在你试图重新规划卷大小之前,请考虑以下几点:主存储的最佳实践Citrix XenServer点击确定。点击是否确实要缩小卷大小来确认你要缩小的容量。点击上传卷。点击迁移卷按钮 |Migrateinstance.png| ,然后从下拉列表里面选择目标位置。点击迁移按钮 |Migrateinstance.png| ,然后从下拉列表中选择目标位置。点击快照按钮。 |SnapshotButton.png|点击你想卸载卷的名字,然后点击卸载磁盘按钮。 |DetachDiskButton.png|点击你要做快照的卷的名称。在卷列表中点击卷的名称,然后点击附加磁盘按钮 |AttachDiskButton.png|点击你想迁移的卷。CloudStack定义一个卷作为来宾虚机的一个有效的存储单元。卷可能是root磁盘或者数据磁盘。root磁盘在文件系统中有 "/" 并且通常用于启动设备。数据磁盘提供额外的存储,比如:"/opt"或者"D:"。每个来宾VM都有一个root磁盘,VMs可能也还有数据磁盘。终端用可以给来宾VMs挂在多个数据磁盘。用户通过管理员创建的磁盘方案来选择数据磁盘。用户同样可以在卷上创建模板;这是标准私有模板的创建流程。针对不同的hypervisor卷也不同:一个hypervisor类型上的卷不能用于其它的hypervisor类型上的来宾虚机。CloudStack定义了两种存储:主存储和辅助存储。主存储可以使用iSCSI或NFS协议。另外,直接附加存储可被用于主存储。辅助存储通常使用NFS协议。CloudStack给一些 hypervisors做增量备份。当使用了增量备份,那么每N备份就是一个完全备份。CloudStack提供了调整数据盘大小的功能;CloudStack借助磁盘方案控制卷大小。这样提供了CloudStack管理员可以灵活地选择他们想要给终端用户多少可用空间。使用相同存储标签的磁盘方案中的卷可以重新划分。比如,如果你只想提供 10,50和100GB的方案,重新划分允许的极限就不会超过这些。也就是说,如果你定义了10GB,50GB和100GB的磁盘方案,用户可以从10GB升级到50GB,或者从50GB升级到100GB。如果你创建了自定义大小的磁盘方案,那么你可以重新规划卷的大小为更大的值。CloudStack支持给XenServer 6.0和以上版本的VM最多附加13个数据磁盘。其它hypervisor类型上的VMs,最多附加6个数据磁盘。CloudStack支持在一个群集内有多个主存储池。比如,使用2个NFS服务器提供主存储。或原有的1个iSCSI LUN达到一定容量时再添加第二个iSCSI LUN。CloudStack支持磁盘卷的快照。快照为虚拟机某一时间点的抓取。内存和CPU状态不会被抓取。如果你使用Oracle VM hypervisor,那么你不能做快照,因为OVM不支持。集群化的LVM创建新卷从当前VM上卸载磁盘,然后将其移动至新的存储,再将其附加至新的VM。从VM卸载磁盘。请参阅 `“卸载和移动卷” <#detaching-and-moving-volumes>`_ 但是跳过最后的"重新附加"步骤。你会在迁移过后在新的存储上做这一步。卸载和移动卷磁盘镜像格式磁盘方案。选择存储特性。动态:这是一个比较新的CloudStack管理存储的方式。在这个模式中,给CloudStack使用的是一个存储系统(但不是预分配的存储)。CloudStack配合存储一起工作,动态的在存储系统上创建卷并且存储系统上的每个卷都映射到一个CloudStack卷。这样做非常有利于存储的QoS。目前数据磁盘(磁盘方案)支持这个特性。已存在的数据现在可以被虚拟机存取。这个被称为上传一个卷到VM。例如,这对于从本地数据系统上传数据并将数据附加到VM是非常有用的。Root管理员、域管理员和终端用户都可以给VMs上传已存在的卷。对于旧版本升级的客户:这个过程只适用于在升级到CloudStack 4.2之后新创建的快照。已经做过快照并且使用OVA格式存储的将继续使用已有的格式,并且也能正常工作。格式。在下面所指出的卷的磁盘镜像格式中选择一种。如何给卷做快照Hyper-VHypervisorHypervisor对主存储的支持如果VM的存储与VM必须一起被迁移,这点会在主机列表中标注。CloudStack会为你自动的进行存储迁移。如果两个VMs存在于不同的群集中,并且卷很大,那么卷移动至新的VM上可能要耗费比较长的时间。如果你选择自定义磁盘,请指定一个自定义大小。在选择视图,确认选择的是卷。在选择视图中选择卷。为了能使用本地磁盘,区域中必须启用该功能。在弹出的实例界面,选择你打算附加卷的那台虚拟机。你只能看到允许你附加卷的实例;比如,普通用户只能看到他自己创建的实例,而管理员将会有更多的选择。在弹出的调整卷大小窗口中,为存储选择想要的方案。在左侧的导航栏里,点击实例,然后点击VM名。在左侧的导航栏,点击实例,再点击VM名,接着点击查看卷。在左侧的导航栏,点击存储,在选择视图中选择卷。或者,如果你知道卷要附加给哪个VM的话,你可以点击实例,再点击VM名称,然后点击查看卷。在左侧导航栏点击存储。在左侧导航栏点击存储。增量快照和备份KVMKVM支持 "Shared Mountpoint"存储。Shared Mountpoint是群集中每个服务器本地文件系统中的一个路径。群集所有主机中的该路径必须一致,比如/mnt/primary1。并假设Shared Mountpoint是一个集群文件系统如OCFS2。在这种情况下,CloudStack不会把它当做NFS存储去尝试挂载或卸载。CloudStack需要管理员确保该存储是可用的。在vSphere, XenServer和KVM中,本地存储是一个可选项。当选择了使用本地存储,所有主机会自动创建本地存储池。想要系统虚拟机 (例如虚拟路由器)使用本地存储,请设置全局配置参数system.vm.use.local.storage为true.在不需要持久化数据卷和HA的情况下,本地存储是个理想的选择。其优点包括降低磁盘I/O延迟、使用廉价的本地磁盘来降低费用等。使用用户或管理员登录到CloudStack用户界面。是用用户或者管理员登录CloudStack。用管理员或用户账号登录CloudStack UIMD5校验。(可选项)使用在步骤1中创建的哈希。主存储的维护模式为正在运行的VM迁移存储迁移存储和附加到不同的VM将数据卷迁移到新的存储池迁移VM的Root卷到新的存储池将磁盘移动到新的存储,但是还将其附加在原来正在运行的VM上。NFSNFS 和 iSCSI名称和描述。你想要的任何名称和一个简洁的描述,这些都会显示在UI中。名字。给卷取个唯一的名字以便于你以后找到它。否OVA在XenServer和VMware上,由于CloudStack支持XenMotion和vMotion,VM存储的在线迁移是启用的。在线存储迁移允许没有在共享存储上的VMs从一台主机迁移到另一台主机上。它提供选项让VM的磁盘与VM本身一起在线迁移。它让XenServer资源池之间/VMware群集之间迁移VM,或者在本地存储运行的VM,甚至是存储库之间迁移VM的磁盘成为可能,而且迁移同时VM是正在运行的。主存储主存储可以被设置成维护模式。这很有用,例如,替换存储设备中坏的RAM。对存储设备的维护模式将首先停止任何新的来自预处理的来宾虚机,然后停止所有有数据卷的来宾虚机。当所有来宾虚机被停止的时候,这个存储设备就进入维护模式了并且可以关机。当存储设备再次上线的时候,你可以对这个设备取消维护模式。CloudStack将返回在线状态并且试着启动所有曾在这个设备进入维护模式前运行的来宾机器。填写以下内容:QCOW2在VM重启时重设VM的root盘重新规划卷当创建虚拟机的时候,root卷也会自动的创建。在VM被销毁的时候root卷也会被删除。数据卷可以被创建并动态的挂载到VMs上。VMs销毁时并不会删除数据卷。主存储的运行时行为辅助存储在卷列表中选择卷名称,然后点击调整卷大小按钮 |resize-volume-icon.png|给concurrent.snapshots.threshold.perhost设置一个你结合目前主机资源和在主机上运行的VMs数量的最佳值,这个值代表了在同一时刻有多少快照工作在hypervisor主机上执行。如果一个主机有比较多的快照请求,额外的请求就会被放在等待队列里。在当前执行 的快照工作数量下降至限制值之内,新的快照工作才会开始。快照工作调节快照恢复创建的快照保存在磁盘所在的主存储。在创建快照之后,它会立即被备份到辅助存储并在主存储上删除以节省主存储的空间。卷,包括root和数据磁盘(使用Oracle VM hypervisor除外,因为OVM不支持快照)都可以做快照。管理员可以限制每个用户的快照数量。用户可以通过快照创建新的卷,用来恢复特定的文件,还可以通过快照创建模板来启动恢复的磁盘。静态:CloudStack管理存储的传统方式。在这个模式下,要给CloudStack预先分配几个存储(比如一个SAN上的卷)。然后CloudStack在上面创建若干个卷(可以是root和/或者数据盘)。如果使用这种技术,确保存储上没有数据。给CloudStack添加存储会销毁已存在的所有数据。存储概述存储标签存储是可以被"标签"的。标签是与主存储、磁盘方案或服务方案关联的字符串属性。标签允许管理员给存储添加额外的信息。比如"SSD"或者"慢速"。CloudStack不负责解释标签。它不会匹配服务和磁盘方案的标签。CloudStack要求在主存储上分配root或数据磁盘之前,所有服务和磁盘方案的都已存在对应的标签。服务和磁盘方案的标签被用于识别方案对存储的要求。比如,高端服务方案可能需要它的root磁盘卷是"快速的"存储媒介 \\ hypervisor支持增量备份支持XenServer、KVM和VMware。与卷关联的VMs是停止状态。管理员也可以通过job.expire.minutes给快照请求等待队列的长度设置一个最大值。如果达到了这个限制,那么快照请求会失败并且返回一个错误消息。与卷关联的数据磁盘已经移除了。删除卷不会删除曾经对卷做的快照下表显示了针对不同Hypervisors的存储选项和参数。标签,分配,跨集群或机架的卷复制之间的关系是很复杂的。简单的环境就是在一个机架内所有集群的主存储使用相同的标签。即使用这些标签表示不同设备,展现出来的标签组仍可以是一样的。新建的存储会在卷列表中显示为“已分配”状态。卷数据已经存储到CloudStack了,但是该卷还不能被使用。主存储的速度会直接影响来宾虚机的性能。如果可能,为主存储选择选择容量小,转速高的硬盘或SSDs。使用HTTP上传。上传的卷被存储在区域中的辅助存储中。有两种方式恢复快照。用户能够从快照中创建一个卷。卷可以随后被挂载到虚拟机上并且文件根据需要被复原。另一种方式是,模板可以从一个root 盘的快照创建。用户能够从这个模板启动虚拟机从而实际上复原root盘。当你想迁移磁盘的时候可能有两种情况:CloudStack用两种方式使用主存储:CloudStack不支持临时存储。所有节点上的所有卷都是持久存储。KVM, XenServer和VMware主机支持这个功能。但是VMware主机不支持卷的收缩。此参数避免了不小心的失误造成数据的丢失。你必须知道你在做什么。这个过程不同于从一个虚拟机移动磁盘卷到另外的虚拟机。这些内容在 "查看挂载和移动卷" <#detaching-and-moving-volumes>`_中有描述。这个过程不同于从一个存储池移动卷到其他的池。这些内容在 `“VM存储迁移” <#vm-storage-migration>`_中有描述。本章节讲述的是关于CloudStack的主存储概念和技术细节。更多关于如何通过CloudStack UI安装和配置主存储的信息,请参阅安装向导。本章节讲述的是关于CloudStack的辅助存储概念和技术细节。更多关于如何通过CloudStack UI安装和配置主存储的信息,请参阅高级安装向导。创建新卷针对这种情况,云端的root管理员可以利用全局配置设置中的concurrent.snapshots.threshold.perhost调节有多少快照工作同时在主机上运行。借助这个设置,当太多快照请求发生时,管理员更好的确认快照工作不会超时并且hypervisor主机不会有性能问题。点击添加卷来创建一个新卷,填写以下信息后点击确定。要移动卷至其他VM,按照`“附加卷” <#attaching-a-volume>`_中的步骤。要重新规划卷容量:通过附加卷来开始使用这个卷。要上传一个卷:URL。CloudStack用来访问你的磁盘的安全HTTP或HTTPS URL。URL对应的文件种类必须符合在格式中选择的。例如,格式为VHD,则URL必须像下面的:上传一个已存在的卷给虚拟机用户可以手动或者设置自动循环快照策略创建快照。用户也可以从快照创建附磁盘卷,并像其他磁盘卷一样附加到虚机上。root和数据磁盘支持快照。但是,CloudStack目前不支持通过恢复的root盘启动VM。从快照恢复的root盘会被认为是数据盘;恢复的磁盘可以附加到VM上以访问上面的数据。用户可以设置循环快照策略来自动的为磁盘定期地创建多个快照。快照可以按小时,天,周或者月为周期。每个磁盘卷都可以设置快照策略。比如,用户可以设置每天的02:30做快照。使用本地存储作为数据卷VHD不支持VHD快照。VM存储迁移VMDKVMFSVMwareVMware卷快照性能VMware vSphere卷的删除和回收卷状态不同的hypervisor创建的磁盘卷有所不同。当磁盘卷被附加到一种hypervisor的虚拟机(如:xenserver),就不能再被附加到其他类型的hypervisor,如:vmware、kvm的虚拟机中。因为它们所用的磁盘分区模式不同。使用回收程序后,卷就永久的被销毁了。全局配置变量expunge.delay和expunge.interval决定了何时物理删除卷。等到卷的上传显示完成。点击实例-卷,找到你在步骤5中指定的名称,单后确保状态是已上传。这期间,卷的状态会变成正在迁移,然后又变回已就绪。观察卷的状态会变成正在迁移,然后又变回已就绪。你可以点击左侧导航条中的存储找到卷。在选择查看的下拉列表中,确保卷显示在窗口的顶部。观察卷的状态会变成迁移中,然后变回运行中(或者停止,在KVM中)。这过程会持续一段时间。当一个VM被销毁时,附加到该VM的数据磁盘卷不会被删除。当手动创建了快照,不管改卷是不是活跃的,快照会一直被创建。当虚拟机需要快照时,VM所在的主机上就会运行快照工作,或者在VM最后运行的主机上。如果在一台主机上的VMs需要很多快照,那么这会导致太多的快照工作进而占用过多的主机资源。当快照操作是由一个循环快照策略所引发的时候,如果从其上次创建快照后,卷一直处于非活跃状态,快照被跳过。如果卷被分离或附加的虚拟机没有运行,那么它就被认为是非活跃的。CloudStack会确保从卷上一次变得不活跃后,至少创建了一个快照。当卷缩小的时候,上面的磁盘会被截断,这么做的话可能会丢失数据。因此,在缩小数据磁盘之前,重新规划任何分区或文件系统以便数据迁移出这个磁盘。当创建一个新的服务方案时,设置isVolatile这个参数为True。从这个服务方案创建的VMs一旦重启,它们的磁盘就会重置。请参阅 `“创建新的计算方案” <service_offerings.html#creating-a-new-compute-offering>`_。当卷被附加之后,你通过点击实例看到实例名和该实例所附加的卷。当你为VMware中的数据卷或root卷做快照时,CloudStack使用一种高效率的存储技术来提高性能。在NFS存储中,CloudStack管理超配。这种情况下,使用全局配置参数storage.overprovisioning.factor来控制超配的范围。且不受hyperviso类型约束。依靠每个快照计划,用户还可以指定计划快照的保留数量。超出保留期限的老快照会被自动的删除。用户定义的限制必须等于或小于CloudStack管理员设置的全局限制。请参阅 `“全局配置的限制” <usage.html#globally-configured-limits>`_.。限制只能应用给作为自动循环快照策略的一部分的快照。额外的手动快照能被创建和保留。对于数据磁盘,当一个用户执行一个磁盘方案来创建数据磁盘的时候,初始化信息就被写到了CloudStack的数据库中。根据第一次给VM附加数据磁盘的请求,CloudStack决定这个卷的位置和空间占用在哪个存储(预分配存储和存储系统(比如SAN)中的任意一种,这取决于CloudStack使用的哪种主存储)。使用磁盘卷使用存储使用卷快照XenServerXenServer通过在iSCSI和FC卷上使用集群化的LVM系统来存储VM镜像,并且不支持存储超配。尽管存储本身支持自动精简配置。不过CloudStack仍然支持在有自动精简配置的存储卷上使用存储超配。是支持,通过已有的SR支持,通过Shared Mountpoint你可以在符合你存储能力的情况下随时向来宾虚拟机添加多个数据卷。CloudStack的管理员和普通用户都可以向虚拟机实例中添加卷。当你创建了一个新卷,他以一个实体的形式存在于CloudStack中,但是在你将其附加到实例中之前他并不会被分配实际的物理空间。这个优化项允许CloudStack提供最接近来宾虚机的卷,并在第一个附加至虚机的时候使用它。你可以通过附加一个卷来提供虚拟机的额外磁盘存储。当你第一次创建新卷,或移动已存在的卷到另一台虚拟机,或实在从另一个存储池迁移过来一个卷的时候你才可以附加一个卷。您可以为本地存储创建一个数据盘方案。当创建新虚机时,用户就能够选择该磁盘方案使数据盘存放到本地存储上。您可以将数据盘创建在本地存储上(XenServer、KVM和VMware支持)。数据盘会存放在和所挂载的虚机相同的主机上。这些本地数据盘可以象其它类型的数据盘一样挂载到虚机、卸载、再挂载和删除。你可以从同一区域中的一个存储池迁移虚机的root磁盘卷或任何其他的数据磁盘卷到其他的池你不能将使用了本地存储作为磁盘的虚机迁移到别的主机,也不能迁移磁盘本身到别的主机。若要将主机置于维护模式,您必须先将该主机上所有拥有本地数据卷的虚机关机。你可以指定你想要放弃的root磁盘和创建一个新的,并且无论何时在VM重启时都使用新的。每次启动时都是一个全新的VM并且桌面不需要保存它的状态,出于安全环境考虑这非常有用。VM的IP地址在这个操作期间不会改变。你可以使用存储迁移功能完成一些常用的管理目标。如将它们从有问题的存储池中迁移出去以平衡存储池的负载和增加虚拟机的可靠性。如果预配置的卷已经达到了上限的话,那么你就不能上传卷了。默认的限制在全局配置参数max.account.volumes中设置,但是管理员同样可以为每个用户域设置不同于全局默认的上限值。请参阅设置使用限制。``http://yourFileServerIP/userdata/myDataDisk.vhd```expunge.delay`:决定在卷被销毁之前卷存在多长时间,以秒计算。`expunge.interval`:决定回收检查运行频率。`“关于主存储” <http://docs.cloudstack.apache.org/en/latest/concepts.html#about-primary-storage>`_`“关于辅助存储” <http://docs.cloudstack.apache.org/en/latest/concepts.html#about-secondary-storage>`_。|resize-volume.png|