DaanHoogland commented on a change in pull request #85: [WIP] Backup & Recovery Doc Guide URL: https://github.com/apache/cloudstack-documentation/pull/85#discussion_r386389203
########## File path: source/adminguide/virtual_machines.rst ########## @@ -801,236 +537,390 @@ following conditions: To manually live migrate a virtual machine -#. Log in to the CloudStack UI as a user or admin. +#. Log in to the CloudStack UI as a user or admin. + +#. In the left navigation, click Instances. + +#. Choose the VM that you want to migrate. + +#. Click the Migrate Instance button. |Migrateinstance.png| + +#. From the list of suitable hosts, choose the one to which you want to + move the VM. + + .. note:: + 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. + +#. Click OK. + +.. note:: + (KVM) If the VM's storage has to be migrated along with the VM, from a mounted NFS storage pool to a cluster-wide mounted NFS storage pool, then the 'migrateVirtualMachineWithVolume' API has to be used. There is no UI integration for this feature. + + (CloudMonkey) > migrate virtualmachinewithvolume virtualmachineid=<virtual machine uuid> hostid=<destination host uuid> migrateto[i].volume=<virtual machine volume number i uuid> migrateto[i].pool=<destination storage pool uuid for volume number i> + + where i in [0,..,N] and N = number of volumes of the virtual machine + + + +Assigning VMs to Hosts +---------------------- + +At any point in time, each virtual machine instance is running on a +single host. How does CloudStack determine which host to place a VM on? +There are several ways: + +- Automatic default host allocation. CloudStack can automatically pick + the most appropriate host to run each virtual machine. + +- Instance type preferences. CloudStack administrators can specify that + certain hosts should have a preference for particular types of guest + instances. For example, an administrator could state that a host + should have a preference to run Windows guests. The default host + allocator will attempt to place guests of that OS type on such hosts + first. If no such host is available, the allocator will place the + instance wherever there is sufficient physical capacity. + +- Vertical and horizontal allocation. Vertical allocation consumes all + the resources of a given host before allocating any guests on a + second host. This reduces power consumption in the cloud. Horizontal + allocation places a guest on each host in a round-robin fashion. This + may yield better performance to the guests in some cases. + +- Admin users preferences. Administrators have the option to specify a + pod, cluster, or host to run the VM in. CloudStack will then select + a host within the given infrastructure. + +- End user preferences. Users can not control exactly which host will + run a given VM instance, but they can specify a zone for the VM. + CloudStack is then restricted to allocating the VM only to one of the + hosts in that zone. + +- Host tags. The administrator can assign tags to hosts. These tags can + be used to specify which host a VM should use. The CloudStack + administrator decides whether to define host tags, then create a + service offering using those tags and offer it to the user. + +- Affinity groups. By defining affinity groups and assigning VMs to + them, the user or administrator can influence (but not dictate) which + VMs should run on separate hosts. This feature is to let users + specify that certain VMs won't be on the same host. + +- CloudStack also provides a pluggable interface for adding new + allocators. These custom allocators can provide any policy the + administrator desires. + + +Affinity Groups +~~~~~~~~~~~~~~~ + +By defining affinity groups and assigning VMs to them, the user or +administrator can influence (but not dictate) which VMs should run on +separate hosts. This feature is to let users specify that VMs with the +same “host anti-affinity” type won’t be on the same host. This serves to +increase fault tolerance. If a host fails, another VM offering the same +service (for example, hosting the user's website) is still up and +running on another host. + +The scope of an affinity group is per user account. + + +Creating a New Affinity Group +''''''''''''''''''''''''''''' + +To add an affinity group: + +#. Log in to the CloudStack UI as an administrator or user. + +#. In the left navigation bar, click Affinity Groups. + +#. Click Add affinity group. In the dialog box, fill in the following + fields: + + - Name. Give the group a name. + + - Description. Any desired text to tell more about the purpose of + the group. + + - Type. The only supported type shipped with CloudStack is Host + Anti-Affinity. This indicates that the VMs in this group should + avoid being placed on the same host with each other. If you see + other types in this list, it means that your installation of + CloudStack has been extended with customized affinity group + plugins. + + +Assign a New VM to an Affinity Group +'''''''''''''''''''''''''''''''''''' + +To assign a new VM to an affinity group: + +- Create the VM as usual, as described in `“Creating + VMs” <virtual_machines.html#creating-vms>`_. In the Add Instance + wizard, there is a new Affinity tab where you can select the + affinity group. + + +Change Affinity Group for an Existing VM +'''''''''''''''''''''''''''''''''''''''' + +To assign an existing VM to an affinity group: + +#. Log in to the CloudStack UI as an administrator or user. -#. In the left navigation, click Instances. +#. In the left navigation bar, click Instances. -#. Choose the VM that you want to migrate. +#. Click the name of the VM you want to work with. -#. Click the Migrate Instance button. |Migrateinstance.png| +#. Stop the VM by clicking the Stop button. -#. From the list of suitable hosts, choose the one to which you want to - move the VM. +#. Click the Change Affinity button. |change-affinity-button.png| - .. note:: - 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. -#. Click OK. +View Members of an Affinity Group +''''''''''''''''''''''''''''''''' -.. note:: - (KVM) If the VM's storage has to be migrated along with the VM, from a mounted NFS storage pool to a cluster-wide mounted NFS storage pool, then the 'migrateVirtualMachineWithVolume' API has to be used. There is no UI integration for this feature. +To see which VMs are currently assigned to a particular affinity group: - (CloudMonkey) > migrate virtualmachinewithvolume virtualmachineid=<virtual machine uuid> hostid=<destination host uuid> migrateto[i].volume=<virtual machine volume number i uuid> migrateto[i].pool=<destination storage pool uuid for volume number i> +#. In the left navigation bar, click Affinity Groups. - where i in [0,..,N] and N = number of volumes of the virtual machine +#. Click the name of the group you are interested in. +#. Click View Instances. The members of the group are listed. -Deleting VMs ------------- + From here, you can click the name of any VM in the list to access all + its details and controls. -Users can delete their own virtual machines. A running virtual machine -will be abruptly stopped before it is deleted. Administrators can delete -any virtual machines. -To delete a virtual machine: +Delete an Affinity Group +'''''''''''''''''''''''' -#. Log in to the CloudStack UI as a user or admin. +To delete an affinity group: -#. In the left navigation, click Instances. +#. In the left navigation bar, click Affinity Groups. -#. Choose the VM that you want to delete. +#. Click the name of the group you are interested in. -#. Click the Destroy Instance button. |Destroyinstance.png| +#. Click Delete. -#. Optionally both expunging and the deletion of any attached volumes can be enabled. + Any VM that is a member of the affinity group will be disassociated + from the group. The former group members will continue to run + normally on the current hosts, but if the VM is restarted, it will no + longer follow the host allocation rules from its former affinity + group. -Working with ISOs ------------------ +Changing a VM's Base Image +---------------------------- -CloudStack supports ISOs and their attachment to guest VMs. An ISO is a -read-only file that has an ISO/CD-ROM style file system. Users can -upload their own ISOs and mount them on their guest VMs. +Every VM is created from a base image, which is a template or ISO which +has been created and stored in CloudStack. Both cloud administrators and +end users can create and modify templates, ISOs, and VMs. -ISOs are uploaded based on a URL. HTTP is the supported protocol. Once -the ISO is available via HTTP specify an upload URL such as -http://my.web.server/filename.iso. +In CloudStack, you can change an existing VM's base image from one +template to another, or from one ISO to another. (You can not change +from an ISO to a template, or from a template to an ISO). -ISOs may be public or private, like templates.ISOs are not -hypervisor-specific. That is, a guest on vSphere can mount the exact -same image that a guest on KVM can mount. +For example, suppose there is a template based on a particular operating +system, and the OS vendor releases a software patch. The administrator +or user naturally wants to apply the patch and then make sure existing +VMs start using it. Whether a software update is involved or not, it's +also possible to simply switch a VM from its current template to any +other desired template. -ISO images may be stored in the system and made available with a privacy -level similar to templates. ISO images are classified as either bootable -or not bootable. A bootable ISO image is one that contains an OS image. -CloudStack allows a user to boot a guest VM off of an ISO image. Users -can also attach ISO images to guest VMs. For example, this enables -installing PV drivers into Windows. ISO images are not -hypervisor-specific. +To change a VM's base image, call the restoreVirtualMachine API command +and pass in the virtual machine ID and a new template ID. The template +ID parameter may refer to either a template or an ISO, depending on +which type of base image the VM was already using (it must match the +previous type of image). When this call occurs, the VM's root disk is +first destroyed, then a new root disk is created from the source +designated in the template ID parameter. The new root disk is attached +to the VM, and now the VM is based on the new template. +You can also omit the template ID parameter from the +restoreVirtualMachine call. In this case, the VM's root disk is +destroyed and recreated, but from the same template or ISO that was +already in use by the VM. -Adding an ISO -~~~~~~~~~~~~~ -To make additional operating system or other software available for use -with guest VMs, you can add an ISO. The ISO is typically thought of as -an operating system image, but you can also add ISOs for other types of -software, such as desktop applications that you want to be installed as -part of a template. +Advanced VM Instance Settings +------------------------------- Review comment: -- ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
