blob: 75012f43d1a3e6dd683b3effe60603cf24df3903 [file] [log] [blame]
# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2016, Apache Software Foundation
# This file is distributed under the same license as the Apache CloudStack Administration Documentation package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Apache CloudStack Administration Documentation 4.8\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2016-08-22 13:55+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../hosts.rst:18
msgid "Working with Hosts"
msgstr ""
#: ../../hosts.rst:21
msgid "Adding Hosts"
msgstr ""
#: ../../hosts.rst:23
msgid "Additional hosts can be added at any time to provide more capacity for guest VMs. For requirements and instructions, see `“Adding a Host” <http://docs.cloudstack.apache.org/projects/cloudstack-installation/en/latest/configuration.html#adding-a-host>`_."
msgstr ""
#: ../../hosts.rst:29
msgid "Scheduled Maintenance and Maintenance Mode for Hosts"
msgstr ""
#: ../../hosts.rst:31
msgid "You can place a host into maintenance mode. When maintenance mode is activated, the host becomes unavailable to receive new guest VMs, and the guest VMs already running on the host are seamlessly migrated to another host not in maintenance mode. This migration uses live migration technology and does not interrupt the execution of the guest."
msgstr ""
#: ../../hosts.rst:39
msgid "vCenter and Maintenance Mode"
msgstr ""
#: ../../hosts.rst:41
msgid "To enter maintenance mode on a vCenter host, both vCenter and CloudStack must be used in concert. CloudStack and vCenter have separate maintenance modes that work closely together."
msgstr ""
#: ../../hosts.rst:45
msgid "Place the host into CloudStack's \"scheduled maintenance\" mode. This does not invoke the vCenter maintenance mode, but only causes VMs to be migrated off the host"
msgstr ""
#: ../../hosts.rst:49
msgid "When the CloudStack maintenance mode is requested, the host first moves into the Prepare for Maintenance state. In this state it cannot be the target of new guest VM starts. Then all VMs will be migrated off the server. Live migration will be used to move VMs off the host. This allows the guests to be migrated to other hosts with no disruption to the guests. After this migration is completed, the host will enter the Ready for Maintenance mode."
msgstr ""
#: ../../hosts.rst:57
msgid "Wait for the \"Ready for Maintenance\" indicator to appear in the UI."
msgstr ""
#: ../../hosts.rst:59
msgid "Now use vCenter to perform whatever actions are necessary to maintain the host. During this time, the host cannot be the target of new VM allocations."
msgstr ""
#: ../../hosts.rst:63
msgid "When the maintenance tasks are complete, take the host out of maintenance mode as follows:"
msgstr ""
#: ../../hosts.rst:66
msgid "First use vCenter to exit the vCenter maintenance mode."
msgstr ""
#: ../../hosts.rst:68
msgid "This makes the host ready for CloudStack to reactivate it."
msgstr ""
#: ../../hosts.rst:70
msgid "Then use CloudStack's administrator UI to cancel the CloudStack maintenance mode"
msgstr ""
#: ../../hosts.rst:73
msgid "When the host comes back online, the VMs that were migrated off of it may be migrated back to it manually and new VMs can be added."
msgstr ""
#: ../../hosts.rst:78
msgid "XenServer and Maintenance Mode"
msgstr ""
#: ../../hosts.rst:80
msgid "For XenServer, you can take a server offline temporarily by using the Maintenance Mode feature in XenCenter. When you place a server into Maintenance Mode, all running VMs are automatically migrated from it to another host in the same pool. If the server is the pool master, a new master will also be selected for the pool. While a server is Maintenance Mode, you cannot create or start any VMs on it."
msgstr ""
#: ../../hosts.rst:87
msgid "**To place a server in Maintenance Mode:**"
msgstr ""
#: ../../hosts.rst:89
#: ../../hosts.rst:104
msgid "In the Resources pane, select the server, then do one of the following:"
msgstr ""
#: ../../hosts.rst:92
msgid "Right-click, then click Enter Maintenance Mode on the shortcut menu."
msgstr ""
#: ../../hosts.rst:95
msgid "On the Server menu, click Enter Maintenance Mode."
msgstr ""
#: ../../hosts.rst:97
msgid "Click Enter Maintenance Mode."
msgstr ""
#: ../../hosts.rst:99
msgid "The server's status in the Resources pane shows when all running VMs have been successfully migrated off the server."
msgstr ""
#: ../../hosts.rst:102
msgid "**To take a server out of Maintenance Mode:**"
msgstr ""
#: ../../hosts.rst:107
msgid "Right-click, then click Exit Maintenance Mode on the shortcut menu."
msgstr ""
#: ../../hosts.rst:110
msgid "On the Server menu, click Exit Maintenance Mode."
msgstr ""
#: ../../hosts.rst:112
msgid "Click Exit Maintenance Mode."
msgstr ""
#: ../../hosts.rst:116
msgid "Disabling and Enabling Zones, Pods, and Clusters"
msgstr ""
#: ../../hosts.rst:118
msgid "You can enable or disable a zone, pod, or cluster without permanently removing it from the cloud. This is useful for maintenance or when there are problems that make a portion of the cloud infrastructure unreliable. No new allocations will be made to a disabled zone, pod, or cluster until its state is returned to Enabled. When a zone, pod, or cluster is first added to the cloud, it is Disabled by default."
msgstr ""
#: ../../hosts.rst:125
msgid "To disable and enable a zone, pod, or cluster:"
msgstr ""
#: ../../hosts.rst:127
msgid "Log in to the CloudStack UI as administrator"
msgstr ""
#: ../../hosts.rst:129
#: ../../hosts.rst:419
msgid "In the left navigation bar, click Infrastructure."
msgstr ""
#: ../../hosts.rst:131
msgid "In Zones, click View More."
msgstr ""
#: ../../hosts.rst:133
msgid "If you are disabling or enabling a zone, find the name of the zone in the list, and click the Enable/Disable button. |enable-disable.png|"
msgstr ""
#: ../../hosts.rst:136
msgid "If you are disabling or enabling a pod or cluster, click the name of the zone that contains the pod or cluster."
msgstr ""
#: ../../hosts.rst:139
msgid "Click the Compute tab."
msgstr ""
#: ../../hosts.rst:141
msgid "In the Pods or Clusters node of the diagram, click View All."
msgstr ""
#: ../../hosts.rst:143
msgid "Click the pod or cluster name in the list."
msgstr ""
#: ../../hosts.rst:145
msgid "Click the Enable/Disable button. |enable-disable.png|"
msgstr ""
#: ../../hosts.rst:149
msgid "Removing Hosts"
msgstr ""
#: ../../hosts.rst:151
msgid "Hosts can be removed from the cloud as needed. The procedure to remove a host depends on the hypervisor type."
msgstr ""
#: ../../hosts.rst:156
msgid "Removing XenServer and KVM Hosts"
msgstr ""
#: ../../hosts.rst:158
msgid "A node cannot be removed from a cluster until it has been placed in maintenance mode. This will ensure that all of the VMs on it have been migrated to other Hosts. To remove a Host from the cloud:"
msgstr ""
#: ../../hosts.rst:162
msgid "Place the node in maintenance mode."
msgstr ""
#: ../../hosts.rst:164
msgid "See `“Scheduled Maintenance and Maintenance Mode for Hosts” <#scheduled-maintenance-and-maintenance-mode-for-hosts>`_."
msgstr ""
#: ../../hosts.rst:167
msgid "For KVM, stop the cloud-agent service."
msgstr ""
#: ../../hosts.rst:169
msgid "Use the UI option to remove the node."
msgstr ""
#: ../../hosts.rst:171
msgid "Then you may power down the Host, re-use its IP address, re-install it, etc"
msgstr ""
#: ../../hosts.rst:176
msgid "Removing vSphere Hosts"
msgstr ""
#: ../../hosts.rst:178
msgid "To remove this type of host, first place it in maintenance mode, as described in `“Scheduled Maintenance and Maintenance Mode for Hosts” <#scheduled-maintenance-and-maintenance-mode-for-hosts>`_. Then use CloudStack to remove the host. CloudStack will not direct commands to a host that has been removed using CloudStack. However, the host may still exist in the vCenter cluster."
msgstr ""
#: ../../hosts.rst:187
msgid "Re-Installing Hosts"
msgstr ""
#: ../../hosts.rst:189
msgid "You can re-install a host after placing it in maintenance mode and then removing it. If a host is down and cannot be placed in maintenance mode, it should still be removed before the re-install."
msgstr ""
#: ../../hosts.rst:195
msgid "Maintaining Hypervisors on Hosts"
msgstr ""
#: ../../hosts.rst:197
msgid "When running hypervisor software on hosts, be sure all the hotfixes provided by the hypervisor vendor are applied. Track the release of hypervisor patches through your hypervisor vendor’s support channel, and apply patches as soon as possible after they are released. CloudStack will not track or notify you of required hypervisor patches. It is essential that your hosts are completely up to date with the provided hypervisor patches. The hypervisor vendor is likely to refuse to support any system that is not up to date with patches."
msgstr ""
#: ../../hosts.rst:207
msgid "The lack of up-do-date hotfixes can lead to data corruption and lost VMs."
msgstr ""
#: ../../hosts.rst:209
msgid "(XenServer) For more information, see `Highly Recommended Hotfixes for XenServer in the CloudStack Knowledge Base <http://docs.cloudstack.org/Knowledge_Base/Possible_VM_corruption_if_XenServer_Hotfix_is_not_Applied/Highly_Recommended_Hotfixes_for_XenServer_5.6_SP2>`_."
msgstr ""
#: ../../hosts.rst:215
msgid "Changing Host Password"
msgstr ""
#: ../../hosts.rst:217
msgid "The password for a XenServer Node, KVM Node, or vSphere Node may be changed in the database. Note that all Nodes in a Cluster must have the same password."
msgstr ""
#: ../../hosts.rst:221
msgid "To change a Node's password:"
msgstr ""
#: ../../hosts.rst:223
msgid "Identify all hosts in the cluster."
msgstr ""
#: ../../hosts.rst:225
msgid "Change the password on all hosts in the cluster. Now the password for the host and the password known to CloudStack will not match. Operations on the cluster will fail until the two passwords match."
msgstr ""
#: ../../hosts.rst:229
msgid "if the password in the database is encrypted, it is (likely) necessary to encrypt the new password using the database key before adding it to the database."
msgstr ""
#: ../../hosts.rst:240
msgid "Get the list of host IDs for the host in the cluster where you are changing the password. You will need to access the database to determine these host IDs. For each hostname \"h\" (or vSphere cluster) that you are changing the password for, execute:"
msgstr ""
#: ../../hosts.rst:249
msgid "This should return a single ID. Record the set of such IDs for these hosts. Now retrieve the host_details row id for the host"
msgstr ""
#: ../../hosts.rst:256
msgid "Update the passwords for the host in the database. In this example, we change the passwords for hosts with host IDs 5 and 12 and host_details IDs 8 and 22 to \"password\"."
msgstr ""
#: ../../hosts.rst:266
msgid "Over-Provisioning and Service Offering Limits"
msgstr ""
#: ../../hosts.rst:268
msgid "(Supported for XenServer, KVM, and VMware)"
msgstr ""
#: ../../hosts.rst:270
msgid "CPU and memory (RAM) over-provisioning factors can be set for each cluster to change the number of VMs that can run on each host in the cluster. This helps optimize the use of resources. By increasing the over-provisioning ratio, more resource capacity will be used. If the ratio is set to 1, no over-provisioning is done."
msgstr ""
#: ../../hosts.rst:276
msgid "The administrator can also set global default over-provisioning ratios in the cpu.overprovisioning.factor and mem.overprovisioning.factor global configuration variables. The default value of these variables is 1: over-provisioning is turned off by default."
msgstr ""
#: ../../hosts.rst:281
msgid "Over-provisioning ratios are dynamically substituted in CloudStack's capacity calculations. For example:"
msgstr ""
#: ../../hosts.rst:284
msgid "Capacity = 2 GB Over-provisioning factor = 2 Capacity after over-provisioning = 4 GB"
msgstr ""
#: ../../hosts.rst:288
msgid "With this configuration, suppose you deploy 3 VMs of 1 GB each:"
msgstr ""
#: ../../hosts.rst:290
msgid "Used = 3 GB Free = 1 GB"
msgstr ""
#: ../../hosts.rst:293
msgid "The administrator can specify a memory over-provisioning ratio, and can specify both CPU and memory over-provisioning ratios on a per-cluster basis."
msgstr ""
#: ../../hosts.rst:297
msgid "In any given cloud, the optimum number of VMs for each host is affected by such things as the hypervisor, storage, and hardware configuration. These may be different for each cluster in the same cloud. A single global over-provisioning setting can not provide the best utilization for all the different clusters in the cloud. It has to be set for the lowest common denominator. The per-cluster setting provides a finer granularity for better utilization of resources, no matter where the CloudStack placement algorithm decides to place a VM."
msgstr ""
#: ../../hosts.rst:306
msgid "The overprovisioning settings can be used along with dedicated resources (assigning a specific cluster to an account) to effectively offer different levels of service to different accounts. For example, an account paying for a more expensive level of service could be assigned to a dedicated cluster with an over-provisioning ratio of 1, and a lower-paying account to a cluster with a ratio of 2."
msgstr ""
#: ../../hosts.rst:313
msgid "When a new host is added to a cluster, CloudStack will assume the host has the capability to perform the CPU and RAM over-provisioning which is configured for that cluster. It is up to the administrator to be sure the host is actually suitable for the level of over-provisioning which has been set."
msgstr ""
#: ../../hosts.rst:321
msgid "Limitations on Over-Provisioning in XenServer and KVM"
msgstr ""
#: ../../hosts.rst:323
#: ../../hosts.rst:431
msgid "In XenServer, due to a constraint of this hypervisor, you can not use an over-provisioning factor greater than 4."
msgstr ""
#: ../../hosts.rst:326
msgid "The KVM hypervisor can not manage memory allocation to VMs dynamically. CloudStack sets the minimum and maximum amount of memory that a VM can use. The hypervisor adjusts the memory within the set limits based on the memory contention."
msgstr ""
#: ../../hosts.rst:333
msgid "Requirements for Over-Provisioning"
msgstr ""
#: ../../hosts.rst:335
msgid "Several prerequisites are required in order for over-provisioning to function properly. The feature is dependent on the OS type, hypervisor capabilities, and certain scripts. It is the administrator's responsibility to ensure that these requirements are met."
msgstr ""
#: ../../hosts.rst:342
msgid "Balloon Driver"
msgstr ""
#: ../../hosts.rst:344
msgid "All VMs should have a balloon driver installed in them. The hypervisor communicates with the balloon driver to free up and make the memory available to a VM."
msgstr ""
#: ../../hosts.rst:350
#: ../../hosts.rst:380
msgid "XenServer"
msgstr ""
#: ../../hosts.rst:352
msgid "The balloon driver can be found as a part of xen pv or PVHVM drivers. The xen pvhvm drivers are included in upstream linux kernels 2.6.36+."
msgstr ""
#: ../../hosts.rst:357
msgid "VMware"
msgstr ""
#: ../../hosts.rst:359
msgid "The balloon driver can be found as a part of the VMware tools. All the VMs that are deployed in a over-provisioned cluster should have the VMware tools installed."
msgstr ""
#: ../../hosts.rst:365
msgid "KVM"
msgstr ""
#: ../../hosts.rst:367
msgid "All VMs are required to support the virtio drivers. These drivers are installed in all Linux kernel versions 2.6.25 and greater. The administrator must set CONFIG\\_VIRTIO\\_BALLOON=y in the virtio configuration."
msgstr ""
#: ../../hosts.rst:374
msgid "Hypervisor capabilities"
msgstr ""
#: ../../hosts.rst:376
msgid "The hypervisor must be capable of using the memory ballooning."
msgstr ""
#: ../../hosts.rst:382
msgid "The DMC (Dynamic Memory Control) capability of the hypervisor should be enabled. Only XenServer Advanced and above versions have this feature."
msgstr ""
#: ../../hosts.rst:387
msgid "VMware, KVM"
msgstr ""
#: ../../hosts.rst:389
msgid "Memory ballooning is supported by default."
msgstr ""
#: ../../hosts.rst:393
msgid "Setting Over-Provisioning Ratios"
msgstr ""
#: ../../hosts.rst:395
msgid "There are two ways the root admin can set CPU and RAM over-provisioning ratios. First, the global configuration settings cpu.overprovisioning.factor and mem.overprovisioning.factor will be applied when a new cluster is created. Later, the ratios can be modified for an existing cluster."
msgstr ""
#: ../../hosts.rst:401
msgid "Only VMs deployed after the change are affected by the new setting. If you want VMs deployed before the change to adopt the new over-provisioning ratio, you must stop and restart the VMs. When this is done, CloudStack recalculates or scales the used and reserved capacities based on the new over-provisioning ratios, to ensure that CloudStack is correctly tracking the amount of free capacity."
msgstr ""
#: ../../hosts.rst:409
msgid "It is safer not to deploy additional new VMs while the capacity recalculation is underway, in case the new values for available capacity are not high enough to accommodate the new VMs. Just wait for the new used/available values to become available, to be sure there is room for all the new VMs you want."
msgstr ""
#: ../../hosts.rst:415
msgid "To change the over-provisioning ratios for an existing cluster:"
msgstr ""
#: ../../hosts.rst:417
msgid "Log in as administrator to the CloudStack UI."
msgstr ""
#: ../../hosts.rst:421
msgid "Under Clusters, click View All."
msgstr ""
#: ../../hosts.rst:423
msgid "Select the cluster you want to work with, and click the Edit button."
msgstr ""
#: ../../hosts.rst:425
msgid "Fill in your desired over-provisioning multipliers in the fields CPU overcommit ratio and RAM overcommit ratio. The value which is intially shown in these fields is the default value inherited from the global configuration settings."
msgstr ""
#: ../../hosts.rst:436
msgid "Service Offering Limits and Over-Provisioning"
msgstr ""
#: ../../hosts.rst:438
msgid "Service offering limits (e.g. 1 GHz, 1 core) are strictly enforced for core count. For example, a guest with a service offering of one core will have only one core available to it regardless of other activity on the Host."
msgstr ""
#: ../../hosts.rst:443
msgid "Service offering limits for gigahertz are enforced only in the presence of contention for CPU resources. For example, suppose that a guest was created with a service offering of 1 GHz on a Host that has 2 GHz cores, and that guest is the only guest running on the Host. The guest will have the full 2 GHz available to it. When multiple guests are attempting to use the CPU a weighting factor is used to schedule CPU resources. The weight is based on the clock speed in the service offering. Guests receive a CPU allocation that is proportionate to the GHz in the service offering. For example, a guest created from a 2 GHz service offering will receive twice the CPU allocation as a guest created from a 1 GHz service offering. CloudStack does not perform memory over-provisioning."
msgstr ""
#: ../../hosts.rst:457
msgid "VLAN Provisioning"
msgstr ""
#: ../../hosts.rst:459
msgid "CloudStack automatically creates and destroys interfaces bridged to VLANs on the hosts. In general the administrator does not need to manage this process."
msgstr ""
#: ../../hosts.rst:463
msgid "CloudStack manages VLANs differently based on hypervisor type. For XenServer or KVM, the VLANs are created on only the hosts where they will be used and then they are destroyed when all guests that require them have been terminated or moved to another host."
msgstr ""
#: ../../hosts.rst:468
msgid "For vSphere the VLANs are provisioned on all hosts in the cluster even if there is no guest running on a particular Host that requires the VLAN. This allows the administrator to perform live migration and other functions in vCenter without having to create the VLAN on the destination Host. Additionally, the VLANs are not removed from the Hosts when they are no longer needed."
msgstr ""
#: ../../hosts.rst:475
msgid "You can use the same VLANs on different physical networks provided that each physical network has its own underlying layer-2 infrastructure, such as switches. For example, you can specify VLAN range 500 to 1000 while deploying physical networks A and B in an Advanced zone setup. This capability allows you to set up an additional layer-2 physical infrastructure on a different physical NIC and use the same set of VLANs if you run out of VLANs. Another advantage is that you can use the same set of IPs for different customers, each one with their own routers and the guest networks on different physical NICs."
msgstr ""
#: ../../hosts.rst:487
msgid "VLAN Allocation Example"
msgstr ""
#: ../../hosts.rst:489
msgid "VLANs are required for public and guest traffic. The following is an example of a VLAN allocation scheme:"
msgstr ""
#: ../../hosts.rst:495
msgid "VLAN IDs"
msgstr ""
#: ../../hosts.rst:495
msgid "Traffic type"
msgstr ""
#: ../../hosts.rst:495
msgid "Scope"
msgstr ""
#: ../../hosts.rst:497
msgid "less than 500"
msgstr ""
#: ../../hosts.rst:497
msgid "Management traffic."
msgstr ""
#: ../../hosts.rst:497
msgid "Reserved for administrative purposes. CloudStack software can access this, hypervisors, system VMs."
msgstr ""
#: ../../hosts.rst:498
msgid "500-599"
msgstr ""
#: ../../hosts.rst:498
msgid "VLAN carrying public traffic."
msgstr ""
#: ../../hosts.rst:498
msgid "CloudStack accounts."
msgstr ""
#: ../../hosts.rst:499
msgid "600-799"
msgstr ""
#: ../../hosts.rst:499
#: ../../hosts.rst:500
msgid "VLANs carrying guest traffic."
msgstr ""
#: ../../hosts.rst:499
msgid "CloudStack accounts. Account-specific VLAN is chosen from this pool."
msgstr ""
#: ../../hosts.rst:500
msgid "800-899"
msgstr ""
#: ../../hosts.rst:500
msgid "CloudStack accounts. Account-specific VLAN chosen by CloudStack admin to assign to that account."
msgstr ""
#: ../../hosts.rst:501
msgid "900-999"
msgstr ""
#: ../../hosts.rst:501
msgid "VLAN carrying guest traffic"
msgstr ""
#: ../../hosts.rst:501
msgid "CloudStack accounts. Can be scoped by project, domain, or all accounts."
msgstr ""
#: ../../hosts.rst:502
msgid "greater than 1000"
msgstr ""
#: ../../hosts.rst:502
msgid "Reserved for future use"
msgstr ""
#: ../../hosts.rst:507
msgid "Adding Non Contiguous VLAN Ranges"
msgstr ""
#: ../../hosts.rst:509
msgid "CloudStack provides you with the flexibility to add non contiguous VLAN ranges to your network. The administrator can either update an existing VLAN range or add multiple non contiguous VLAN ranges while creating a zone. You can also use the UpdatephysicalNetwork API to extend the VLAN range."
msgstr ""
#: ../../hosts.rst:515
msgid "Log in to the CloudStack UI as an administrator or end user."
msgstr ""
#: ../../hosts.rst:517
msgid "Ensure that the VLAN range does not already exist."
msgstr ""
#: ../../hosts.rst:519
msgid "In the left navigation, choose Infrastructure."
msgstr ""
#: ../../hosts.rst:521
msgid "On Zones, click View More, then click the zone to which you want to work with."
msgstr ""
#: ../../hosts.rst:524
msgid "Click Physical Network."
msgstr ""
#: ../../hosts.rst:526
msgid "In the Guest node of the diagram, click Configure."
msgstr ""
#: ../../hosts.rst:528
msgid "Click Edit |edit-icon.png|."
msgstr ""
#: ../../hosts.rst:530
msgid "The VLAN Ranges field now is editable."
msgstr ""
#: ../../hosts.rst:532
msgid "Specify the start and end of the VLAN range in comma-separated list."
msgstr ""
#: ../../hosts.rst:534
msgid "Specify all the VLANs you want to use, VLANs not specified will be removed if you are adding new ranges to the existing list."
msgstr ""
#: ../../hosts.rst:537
msgid "Click Apply."
msgstr ""
#: ../../hosts.rst:541
msgid "Assigning VLANs to Isolated Networks"
msgstr ""
#: ../../hosts.rst:543
msgid "CloudStack provides you the ability to control VLAN assignment to Isolated networks. As a Root admin, you can assign a VLAN ID when a network is created, just the way it's done for Shared networks."
msgstr ""
#: ../../hosts.rst:547
msgid "The former behaviour also is supported — VLAN is randomly allocated to a network from the VNET range of the physical network when the network turns to Implemented state. The VLAN is released back to the VNET pool when the network shuts down as a part of the Network Garbage Collection. The VLAN can be re-used either by the same network when it is implemented again, or by any other network. On each subsequent implementation of a network, a new VLAN can be assigned."
msgstr ""
#: ../../hosts.rst:555
msgid "Only the Root admin can assign VLANs because the regular users or domain admin are not aware of the physical network topology. They cannot even view what VLAN is assigned to a network."
msgstr ""
#: ../../hosts.rst:559
msgid "To enable you to assign VLANs to Isolated networks,"
msgstr ""
#: ../../hosts.rst:561
msgid "Create a network offering by specifying the following:"
msgstr ""
#: ../../hosts.rst:563
msgid "**Guest Type**: Select Isolated."
msgstr ""
#: ../../hosts.rst:565
msgid "**Specify VLAN**: Select the option."
msgstr ""
#: ../../hosts.rst:567
msgid "For more information, see the CloudStack Installation Guide."
msgstr ""
#: ../../hosts.rst:569
msgid "Using this network offering, create a network."
msgstr ""
#: ../../hosts.rst:571
msgid "You can create a VPC tier or an Isolated network."
msgstr ""
#: ../../hosts.rst:573
msgid "Specify the VLAN when you create the network."
msgstr ""
#: ../../hosts.rst:575
msgid "When VLAN is specified, a CIDR and gateway are assigned to this network and the state is changed to Setup. In this state, the network will not be garbage collected."
msgstr ""
#: ../../hosts.rst:580
msgid "You cannot change a VLAN once it's assigned to the network. The VLAN remains with the network for its entire life cycle."
msgstr ""
#: ../../hosts.rst:591
msgid "Out-of-band Management"
msgstr ""
#: ../../hosts.rst:593
msgid "CloudStack provides Root admins the ability to configure and use supported out-of-band management interface (e.g. IPMI, iLO, DRAC, etc.) on a physical host to manage host power operations such as on, off, reset etc. By default, IPMI 2.0 baseboard controller are supported out of the box with `IPMITOOL` out-of-band management driver in CloudStack that uses `ipmitool` for performing IPMI 2.0 management operations."
msgstr ""
#: ../../hosts.rst:600
msgid "Following are some global settings that control various aspects of this feature."
msgstr ""
#: ../../hosts.rst:605
msgid "Global setting"
msgstr ""
#: ../../hosts.rst:605
msgid "Default values"
msgstr ""
#: ../../hosts.rst:605
msgid "Description"
msgstr ""
#: ../../hosts.rst:607
msgid "outofbandmanagement.action.timeout"
msgstr ""
#: ../../hosts.rst:607
msgid "60"
msgstr ""
#: ../../hosts.rst:607
msgid "The out of band management action timeout in seconds, configurable per cluster"
msgstr ""
#: ../../hosts.rst:608
msgid "outofbandmanagement.ipmitool.interface"
msgstr ""
#: ../../hosts.rst:608
msgid "lanplus"
msgstr ""
#: ../../hosts.rst:608
msgid "The out of band management IpmiTool driver interface to use. Valid values are: lan, lanplus etc"
msgstr ""
#: ../../hosts.rst:609
msgid "outofbandmanagement.ipmitool.path"
msgstr ""
#: ../../hosts.rst:609
msgid "/usr/bin/ipmitool"
msgstr ""
#: ../../hosts.rst:609
msgid "The out of band management ipmitool path used by the IpmiTool driver"
msgstr ""
#: ../../hosts.rst:610
msgid "outofbandmanagement.ipmitool.retries"
msgstr ""
#: ../../hosts.rst:610
msgid "1"
msgstr ""
#: ../../hosts.rst:610
msgid "The out of band management IpmiTool driver retries option -R"
msgstr ""
#: ../../hosts.rst:611
msgid "outofbandmanagement.sync.interval"
msgstr ""
#: ../../hosts.rst:611
msgid "300"
msgstr ""
#: ../../hosts.rst:611
msgid "The out of band management background sync thread interval in seconds"
msgstr ""
#: ../../hosts.rst:612
msgid "outofbandmanagement.sync.poolsize"
msgstr ""
#: ../../hosts.rst:612
msgid "50"
msgstr ""
#: ../../hosts.rst:612
msgid "The out of band management background sync thread pool size 50"
msgstr ""
#: ../../hosts.rst:615
msgid "A change in `outofbandmanagement.sync.interval` or `outofbandmanagement.sync.poolsize` settings requires restarting of management server(s) as the thread pool and a background (power state) sync thread are configured during load time when CloudStack management server starts. Rest of the global settings can be changed without requiring restarting of management server(s)."
msgstr ""
#: ../../hosts.rst:621
msgid "The `outofbandmanagement.sync.poolsize` is the maximum number of ipmitool background power state scanners that can run at a time. Based on the maximum number of hosts you've, you can increase/decrease the value depending on how much stress your management server host can endure. It will take atmost number of total out-of-band-management enabled hosts in a round * `outofbandmanagement.action.timeout` / `outofbandmanagement.sync.poolsize` seconds to complete a background power-state sync scan in a single round."
msgstr ""
#: ../../hosts.rst:629
msgid "In order to use this feature, the Root admin needs to first configure out-of-band management for a host using either the UI or the `configureOutOfBandManagement` API. Next, the Root admin needs to enable it. The feature can be enabled or disabled across a zone or a cluster or a host,"
msgstr ""
#: ../../hosts.rst:634
msgid "Once out-of-band management is configured and enabled for a host (and provided not disabled at zone or cluster level), Root admins would be able to issue power management actions such as on, off, reset, cycle, soft and status."
msgstr ""
#: ../../hosts.rst:638
msgid "If a host is in maintenance mode, Root admins are still allowed to perform power management actions but in the UI a warning is displayed."
msgstr ""