%BOOK_ENTITIES; ]>

At any point in time, each virtual machine instance is running on a single host. How does &PRODUCT; determine which host to place a VM on? There are several ways: Automatic default host allocation. &PRODUCT; can automatically pick the most appropriate host to run each virtual machine. Instance type preferences. &PRODUCT; 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. 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. &PRODUCT; 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 &PRODUCT; 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. &PRODUCT; also provides a pluggable interface for adding new allocators. These custom allocators can provide any policy the administrator desires.

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. To add an affinity group: Log in to the &PRODUCT; 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 &PRODUCT; is Host Anti-Affinity. This indicates that the VMs in this group should avoid being placed on the same VM with each other. If you see other types in this list, it means that your installation of &PRODUCT; has been extended with customized affinity group plugins. To assign a new VM to an affinity group: Create the VM as usual, as described in . In the Add Instance wizard, there is a new Affinity tab where you can select the affinity group. To assign an existing VM to an affinity group: Log in to the &PRODUCT; UI as an administrator or user. In the left navigation bar, click Instances. Click the name of the VM you want to work with. Stop the VM by clicking the Stop button. Click the Change Affinity button. change-affinity-button.png: button to assign an affinity group to a virtual machine To see which VMs are currently assigned to a particular affinity group: In the left navigation bar, click Affinity Groups. Click the name of the group you are interested in. Click View Instances. The members of the group are listed. From here, you can click the name of any VM in the list to access all its details and controls. To delete an affinity group: In the left navigation bar, click Affinity Groups. Click the name of the group you are interested in. Click Delete. 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.