Virtual servers are based on templates and are deployed on сompute resources. Compute resources give them access to CPU, disk, and network resources. OnApp supports two kinds of storage for virtual servers: traditional centralized SANs and the new distributed block storage functionality introduced with OnApp Storage, in which local disks in сompute resources provide the physical storage space allocated to virtual servers. In each case, the OnApp platform creates virtual data stores from the physical resources and uses these to provide virtual servers with virtual disks. This document provides information on how you can manage virtual servers in your OnApp сloud. 


View Virtual Servers

  1. Go to your Control Panel > Cloud > Virtual Servers menu to see an overview of all virtual servers in the cloud.
  2. The page that loads will show the list of VSs together with their: 
    • operating system
    • label - click to see the VS details.
    • VIP status - click the icon to enable/disable VIP status of a particular VS
    • IP addresses
    • allocated disk size
    • RAM
    • backups - the number of backups and the space these backups take
    • compute resource - the label of compute resource with which VS is associated
    • user - the owner of this VS. Click the user name to see the owner details
    • CPU(s) - the number of CPU(s) included
    • power status - click the on/off buttons to change the status
  3. Click the Actions button next to the VS for the quick access to the list of VS actions (the list of actions displayed depends on the VS status):
  • Recovery reboot
  • Power off a VS
  • CPU usage
  • Backups
  • Shutdown
  • Start up
  • Recovery start up
  • Unlock

If you are viewing the VSs list on a narrow screen, you can customize the way the table is displayed by clicking the actions icon at the top of the table. In the drop-down list that appears, check the columns you want to be displayed and click Apply. The narrower your screen is, the more unchecked columns will be hidden from the table. If your screen is too narrow to fit all the columns you have checked, a scrollbar will appear at the bottom of the VSs list. You can always alter your column selection later. Note that by default the VIP and Backups columns are not visible in the table on narrow screens.

Column selection is currently set for one browser. If you have checked some columns in one browser and open the list in some other browser, the column selection will be the default one for that other browser.

To search for a particular virtual server, click the Search icon at the top of the VS list. When the search box appears, type the text you want to search for and click the Search button.

View Virtual Server Details


  1. Go to your Control Panel > Cloud > Virtual Servers menu.
  2. Click the label of the virtual server you're interested in.
  3. The screen that appears loads the VS properties, notes, activity log and tools for managing your VS.

VS Properties

The VS properties page gives a general overview of the VS details:

  • - VIP status, click the icon to change the status
  • Template this VS is built on
  • ON, OFF, and REBOOT buttons - the greened out button indicates VS's power status

Clicking the OFF button performs a graceful shutdown and then powers off the virtual server after the timeout set in configuration settings.

  • Auto-backups - move the slider to enable/disable automatic backups for this VS. If the incremental backups are enabled in your cloud, you can set auto-backups per VS rather than per disk.

    If the automation options weren’t enabled during this virtual server creation, you’ll be redirected to the form where you can configure them.

  • Autoscale - move the slider to enable/disable the autoscaling rules set for this VS.

    • Until the autoscaling rules are configured the autoscaling itself will not start working.
    • If the Autoscale slider is greyed out that means that you have reached the autoscaling limit in bucket (or the max is set as 0).

  • Acceleration allowed - move the slider to the right to allow acceleration for this VS or move this slider to the left to prohibit acceleration for this VS. Acceleration status of the VS will be changed on the next CDN Sync Runner run (default value 20 minutes). To edit CDN Sync Runner delay, refer to the Edit Infrastructure Configuration section of this guide.

    Ensure that Accelerate any Virtual Server/Accelerate own Virtual Servers permissions are on before enabling acceleration for the VS. For more information about permissions refer to the Permissions section of this guide.

    To verify whether your VS has been accelerated successfully, curl the IP of your VS.

    curl -I [VS IP address]
HTTP/1.1 200 OK
Content-Type: text/html
Vary: Accept-Encoding
X-Accelerated-By: InviCDN
    CODE

    The X-Accelerated-By: InviCDN statement in the output confirms that your VS has been accelerated.

  • Segregated VS - this field appears if the VS is segregated from another virtual server. Click the label of the virtual server to view the details of the VS from which the current server is segregated. 
  • FQDN - fully qualified domain name
  • Compute Resource - click the compute resource name to see its details
  • Location - click to view the details of the location group with which the VS is associated
  • Login - credentials for this VS
  • Owner - owner of the VS, click to see the details
  • IP Addresses. Only the first five IP addresses are displayed on the virtual server properties page. To view the list of all virtual server IP addresses, mouse over IP addresses area or go to the Networking > IP addresses tab. To view external IP addresses, you have to add them via API call first. To add an external IP address, refer to Add/Edit External IP Address section of API Guide. Once you've added an IP address, you can view it after the -> sign. E.g. 7.7.0.17 -> 8.8.8.7
  • Estimated Price per hour - this sum does not take into consideration the free limits for resources set in the bucket. Therefore, the final price for the server might differ from the sum indicated here.
  • CPU(s)
  • CPU priority or CPU units
  • Disk Size - the total amount of disk size
  • Memory
  • Disk backups - the total amount of backups
  • CPU usage chart
  • Network usage (data sent and data received in GB per hour) chart

Notes

The Notes section lists brief comments or reminders for a VS. You can add either Admin's or User's notes. The Admin's note will be available to cloud administrators.

Service Add-ons

If you have the service add-on functionality enabled and service add-on is assigned to the VS, you can view it at the VS overview page together with the following details:

  • Label - the service add-on name (by clicking on it you can edit the service add-on)
  • Price - the service add-on price, set for this service add-on in the Service Add-on Store
  • Type - select user or system
  • Status - whether the service add-on is active or not
  • Delete icon - you can unassign the Service Add-on from this Virtual Server by clicking the Delete icon.

To assign more service add-ons to the VS, click the "+" button at the upper right corner of the section. You will be redirected to the VS Overview > Service Add-ons section of the VS options.

VS Management

  • Click Actions to see the menu with the VS management options.
  • Use the top menu to manage your virtual servers' statistics/networking/storage options.

Rebuild/Build Virtual Server Manually

To build/rebuild virtual server Build/rebuild virtual server and Manage public templates permissions must be enabled.

If you haven't checked the Build Virtual Server option during the VS creation process, you will have to do this manually after the VS has been created. Building a virtual server is the process of allocating physical resources to that VS.

To build a virtual server manually or rebuild the VS on the same (or another) template:

  1. Go to your Control Panel > Cloud > Virtual Servers menu.
  2. Click the label of the virtual server you're interested in.
  3. On the screen that appears, click the Actions button, point to Options and then click Rebuild Virtual Server.

  4. On the screen that pops up, use the drop-down menu to choose a template with which to build the VS.

    It is not possible to rebuild a Linux-based virtual server to FreeBSD templates.

    It is not possible to rebuild a Windows-based virtual server to Linux/FreeBSD template and vice versa.

  5. Move the Start VS after rebuild slider to the right if you want to have your VS started automatically after it is built.
  6. Select the following options if you selected Windows
    Windows
    • Windows Licensing type - KMS, MAK, or OWN
    • Licensing key - input license if you selected OWN licensing type
    • Select Server for KMS licensing type
  7. Click the Rebuild Virtual Server button to finish.
  • To successfully rebuild the VS, you have to approve this transaction as an administrator. To approve the transaction, go to Dashboard > Logs menu and click the Approve button.
  • After you rebuild your template all data will be lost!
  • If the VS was built from a template with system service add-ons assigned, all added system service add-ons will be removed from the VS after the rebuild. 

Edit Virtual Server

You can edit resources for all VSs. Depending on the template it is built on, some VSs can have their CPU or RAM or both resized without needing to be powered off ("resize without reboot"). If the VS template allows resizing of the required resource without the reboot, the resize should be completed automatically: you will be returned to the VS details screen and see a message indicating the resize was successful. If the template does not allow this, you will be asked to confirm that the VS will need rebooting so that the resize can take place. On how to determine whether the template you are interested in supports resizing without the reboot of RAM or CPU, refer to the Hot Resize page.

  • Windows virtual servers cannot be resized without the reboot.
  • It is not possible to increase the VSs RAM beyond its max_memory value without rebooting the server. For more information, refer to Hot Resize.
  • If the template on which the VS is built on has the value 'YES' for the resize without reboot option, it might denote that either CPU or RAM can be changed without rebooting the server. Some templates support the resize without reboot only for either CPU or RAM while in other templates both CPU and RAM can be changed without rebooting the server. The virtualization type also influences the resize without reboot option. For more information, refer to Hot Resize.

The Edit Virtual Server screen will differ depending on the way the VS resources were selected: either manually or using an instance package. To adjust VS resources:

  1. Go to your Control Panel > Cloud > Virtual Servers menu.
  2. Click the label of the server you want to resize, to show its details screen.
  3. Click the Actions button, point to Options and select the Edit Virtual Server link.

    For virtual servers built by selecting resources manually:

    • Change CPU cores, CPU priority/units and RAM values.

      If you are editing a VS in Federation, there are the following resources ratios for VSs built on public federated zones:

      • a 4:1 ratio for CPU cores and RAM. For example, if you are building a VS with 8 CPU cores, you need to allocate at least 2 GB of RAM to it.
      • a 20:1 ratio for storage and RAM. For example, if you are building a VS with 5 GB of storage, you need to allocate at least 256 MB of RAM to it.
    For VSs based on KVM compute resources only, providing the Enable CPU topology permission is switched on for the user:
    • Change the number of CPU sockets.

Setting the correct amount of CPU sockets

    • Set the total amount of virtualized CPUs and the number of sockets.
    • The value of cores_per_socket will be calculated automatically by the formula vCPUs  = cpu_sockets x cores_per_socket.
    • Thus, if you set the vCPU value 8, and the CPU sockets 2, this means that the cores_per_socket value will be set 4.

For virtual servers built using instance packages:

    • Choose the new instance package for your virtual server. Click the instance package to select it. After that, the instance package you have chosen will be highlighted in green.
    • Those instance packages that have resources incompatible with the compute zone, on which the VS is built, will be greyed out. Greyed out instance packages cannot be selected.
    • You can only choose from those instance packages that offer more disk size than the VS currently uses.
    • After you select a new instance package you can use the extra disk size to create a new disk for the VS or make the existing VS disk larger.

You can also edit the Time Zone parameter for all Windows KVM virtual servers. After you edit the server's time zone, you need to stop and then start up the VS. Currently, the time zone is set at the compute resource side only. Therefore, users need to set the target time zone inside a Windows VS manually. Setting the correct time zone at the compute resource side helps to keep correct time inside a VS after starting it if time synchronization is not completed for some reason.

After changing VS resources you can see two prices per this VS per hour, depending on VS power status (on/off).

    • Click the Save button.

Clone Virtual Server

This option might not work correctly for the VS build on Cloudboot and Static compute resources with integrated storage.


You can create a clone based on the same resources as the origin virtual server. The cloned virtual server inherits resources from the origin as follows. 

ResourceCloned Virtual Server

Properties - owner, hostname, password, and label.

The same as the origin virtual server with Clone in the label, for example, Clone Origin Label.
  • Compute, data store, and network resources & zones
  • Recipes, recipe variables, and service add-ons
  • Firewall rules

The same as the origin virtual server.
If there are no available resources on the same data store, network, and compute resource, you cannot clone a virtual server. 

IP address

A random IP address is assigned from an IP range in the origin network. If a virtual server is built from an OVA template with the Other OS type or any ISO template, an IP address from the origin virtual server is assigned. After a virtual server is cloned and before you start it, you should assign a new IP address.

Swap diskA new swap disk is created on the cloned virtual server.

Backups

The backups of the origin virtual server are not cloned.


To clone a virtual server, follow the next procedure:

  1. Go to your Control Panel > Cloud > Virtual Servers.
  2. Click a label of the virtual server that you want to clone.
  3. Click Actions, point to Options and then click Clone Virtual Server. 
  4. In the pop-up box, click Clone Virtual Server to confirm the action. 

After you confirm the action, several transactions are run to complete the cloning process. You can check a status of each transaction in Activity Log of the virtual server. After the virtual server is cloned, it is powered off until you start it. 

Migrate Virtual Server

You can migrate virtual servers using a hot or cold migration method:

  • Hot migration is a live migration of a virtual server with or without disks and NICs between compute resources that share common data stores or data store zones.
  • Cold migration is a migration of virtual servers with disks between compute resources with local storage or across compute zones.

As an Admin, you can control user access to virtual server migration. Using OnApp permissions, you can allow/forbid users to perform migration of all virtual servers or their own servers. This is handled via the Control Panel > Roles menu.

Hot Migration

You can migrate an online virtual server from one compute resource to another compute resource that is both utilizing local/shared/IS storage or across zones. There are two types of hot migration:

  • Compute Resource - a migration of a virtual server from one compute resource to another. 
  • Full Migrate - a migration of a virtual server with or without disks and NICs between compute resources, data stores, and networks.

Hot Migration Between Compute Resources

Before you begin, take into consideration the following: 

  • Check if your Windows template supports hot migration at the Windows Templates.
  • The source and destination compute resources and data stores should be in the same location. Migration between different locations is not possible.
  • Migrating a virtual server to a compute resource with Any operating system type has the next implications. It won’t be possible to set the Windows Only type for a compute resource, if there are any Linux or FreeBSD VSs residing on it. Likewise, it won't be possible to set the Non Windows type for a compute resource, if there are Windows-based VSs residing on it.
  • If both source and destination compute resources have backup IP addresses, VS migration will be performed using those backup IP addresses as an alternative network for traffic. If the migration fails for any reason, it will be retried using destination compute resource IP address in management network.
Migrate One Virtual Server

To hot migrate a virtual server:

  1. Go to your Control Panel > Cloud > Virtual Servers.
  2. Click a label of a virtual server that you want to migrate.
  3. Click the Actions button, point to Options and click the Migrate Virtual Server button.
  4. In the Migration Type box, select Compute Resource and click Next. 
  5. Select a Target compute resource from the box and click Next. 
  6. At the final step of the wizard, you can see the migration summary and select the following checkbox: 
    • Cold-migrate when hot-migration fails - select the check box to apply cold migration in case of the hot migration failure
  7. When you are finished, click the Submit button.
Migrate Multiple Virtual Servers

You can also migrate multiple virtual servers at once from one compute resource to another compute resource of the same type (KVM to KVM). The mass migration is available within compute resources that belong to the same compute zone. To migrate virtual servers, follow the next steps: 

  1. In the Admin > Compute Resources section, click a compute zone label to see the list of compute resources. 
  2. Click a label of a destination compute resource. On the screen that appears, you will see a list of all virtual servers hosted on the compute resource.

  3. Select checkboxes next to the virtual servers that you want to migrate and click the Migrate button. To select all virtual servers residing on the compute resource, click the first checkbox. To cancel the selection of all virtual servers, click this checkbox again.

  4. In the pop-up box, select the following options:
    • Target compute resource - select a destination compute resource to migrate the virtual servers to

    • Cold-migrate when hot-migration fails - select the checkbox if you want to apply cold migration in case of the hot migration failure

      If some of the selected virtual servers have disks that run as a local storage on this compute resource, these virtual servers could not be migrated. After the migration, these virtual servers remain on the previous compute resource, while other VSs are migrated to the destination compute resource.

  5. When you are finished, click the Submit button. 

After migration, the power status of your virtual server remains the same as before the migration. If you migrate a virtual server that is running, the whole process is almost unnoticeable.

Full Hot Migration 

Before you begin, take into consideration the following: 

  • The hot migration is applicable only to virtual servers running on CentOS 7 KVM compute resources and virtual servers can be migrated only to CentOS 7 KVM compute resources.
  • You can hot migrate a virtual server NIC to a VXLAN/VLAN management network that is not shared by the source and destination compute resources. When you migrate a NIC to another network, only one IP address assigned to this NIC is migrated. 
  • You cannot migrate the VS if its primary IP address is in the same network with Control Panel IP address.
  • Before VS migration to the same network, increase the ssh timeout to at least 60 seconds at the Edit Defaults Configuration page to avoid migration failure.
  • Note that only Windows-based and Linux-based VSs can be migrated with both Migrate Storage and Migrate Networks options enabled.

  • The bandwidth from compute resource to compute resource should be sufficient enough to allow transferring of virtual servers.

  • Hot migration is applicable to virtual servers with local storage. Be aware that migration will take much more time if you want to perform it between shared data stores.
  • If both source and destination compute resources have backup IP addresses, VS migration will be performed using those backup IP addresses as an alternative network for traffic. If the migration fails for any reason, it will be retried using destination compute resource IP address in management network.
  • Be aware that disk migration is better than full VS migration in case you want to migrate disks within the same compute zone and if the advanced backup scheme is used. Such scenario is applicable only to shared data stores within the same compute zone.
  • The hot migration is available only if a virtual server is online and your Quick Emulator (QEMU) version is later than 2.6.

To run a full hot migration of a virtual server:

  1. Go to your Control Panel > Cloud > Virtual Servers.
  2. Click a label of a virtual server that you want to migrate.
  3. Click the Actions button, point to Options and click the Migrate Virtual Server button.
  4. In the Migration Type box, select Full Migrate (Hot).
  5. Select Migrate Storage and/or Migrate Networks and click Next. 
  6. Select the destinations to which to migrate a virtual server:

    Compute Resources

    • Target compute zone - select a destination compute zone
    • Target compute resource - select a destination compute resource
      Click Next to proceed to the following step. 

    Storage Resources 

    • Target data store for disk - select a destination data store for each disk. The list includes available data stores associated with the compute zone and compute resource that you selected earlier.
      Click Next to proceed to the following step.

    Network Resources

    • Target network - select a destination network for each network interface
    • Target IP net - select an IP net in a destination network 
    • Target IP range - select an IP range in a destination network 
    • Select and assign IP address - select an IP address to assign to a virtual server.  You can click Free IPs or My IPs to select from all free IP addresses or your own IP addresses. 
      Click Next to proceed to the following step.
  7. At the final step of the wizard, you can see the migration summary. Click Submit to start the migration.

  • Hot migration is not performed if a virtual server has temporary disks (attached to or from other virtual server).

  • Hot migration is not performed for Integrated Storage data stores if any of the disks has snapshots.

  • Hot migration is not applicable for federated virtual servers that are built in compute zones submitted to the Marketplace.

  • If you have local backups on the source compute resource, please move them manually to a target compute resource or backup server.

  • If both source and destination compute resources have backup IP addresses, VS migration will be performed using those backup IP addresses as an alternative network for traffic. If migration fails for any reason, it will be retried using destination compute resource IP address in management network.

  • If you change the compute resource or data store zone, the billing will be changed according to the prices set for that new zone in the bucket.

  • Go to Admin > Settings > Configuration > Defaults > Migration options, if you want to set migration rate limit and limit of transactions which can be run simultaneously on the target compute resource when migrating a VS.
  • The following disk migration scenarios are applicable:
    • From LVM data store to LVM data store
    • From Integrated Storage data store to Integrated Storage data store
    • From LVM data store to Integrated Storage data store
    • From Integrated Storage data store to LVM data store
      Hot migration is not applicable for SolidFire storage.
  • Disks that are migrated from one LVM data store to another are renamed in the source data store. In case of Integrated Storage, disks remain with the same name at source data store and are marked as offline zombie disks. You need to delete them manually, otherwise, you will get an error during backward migration.

Cold Migration

Cold migration enables you to migrate virtual servers with or without disks and NICs between compute resources with local storage or across compute zones. There are several prerequisites for the cold migration:

  • You should shut down a virtual server before performing the migration.
  • You can cold migrate a virtual server NIC to a VXLAN/VLAN management network that is not shared by the source and destination compute resources. When you migrate a NIC to another network, only one IP address assigned to a virtual server is migrated. 

  • The source and destination compute resources and data stores should be in the same location. Migration between locations is not possible.

  • The bandwidth from compute resource to compute resource should be sufficient enough to allow transferring of virtual servers.

  • Cold migration is applicable to virtual servers with local storage. Be aware that migration will take more time if you want to perform it between shared data stores.
  • Be aware that disk migration is better than full VS migration in case you want to migrate the disks within the same compute zone and if the advanced backup scheme is used. Such scenario is applicable only to the shared data stores within the same compute zone.

To cold migrate a virtual server with disks:

  1. Go to your Control Panel > Cloud > Virtual Servers.
  2. Click a label of a virtual server that you want to migrate.
  3. Click the Actions button, point to Options and click the Migrate Virtual Server button.
  4. In the Migration Type box, select Full Migrate (Cold).
  5. Select Migrate Storage and/or Migrate Networks and click Next.  
  6. Select the destinations to which to migrate a virtual server:

    Compute Resources

    • Target compute zone - select a destination compute zone
    • Target compute resource - select a destination compute resource
      Click Next to proceed to the following step. 

    Storage Resources 

    • Target data store for disk - select a destination data store for each disk. The list includes available data stores associated with the compute zone and compute resource that you selected earlier.
      Click Next to proceed to the following step.

    Network Resources

    • Target network - select a destination network for each network interface
    • Target IP net - select an IP net in a destination network 
    • Target IP range - select an IP range in a destination network 
    • Select and assign IP address - select an IP address to assign to a virtual server.  You can click Free IPs or My IPs to select from all free IP addresses or your own IP addresses. 
      Click Next to proceed to the following step.
  7. At the final step of the wizard, you can see the migration summary. Click Submit to start the migration.

  • Cold migration is not applicable for federated virtual servers that are built in compute zones submitted to the Marketplace.

  • You cannot migrate a virtual server from a compute resource that is offline.

  • If you have local backups on source compute resource, please move them manually to a destination compute resource or backup server.

  • If you change the compute resource or data store zone, the billing will be changed according to the prices set for that new zone in the bucket. The new estimated price per hour for a VS is displayed at the bottom of the VS migration screen.

  • Go to Admin > Settings > Configuration > Defaults > Migration options, if you want to set migration rate limit and limit of transactions which can be run simultaneously on the target compute resource when migrating a VS.
  • The following disk migration scenarios are applicable:
    • From LVM data store to LVM data store
    • From Integrated Storage data store to Integrated Storage data store
    • From LVM data store to Integrated Storage data store
    • From Integrated Storage data store to LVM data store
      Cold migration is not applicable for SolidFire data stores.
  • Disks that are migrated from one LVM data store to another will be renamed in the source data store. In case of Integrated Storage, disks will remain with the same name in the source data store and will be marked as offline zombie disks. You need to check if the transaction is completed and delete them manually, otherwise, you will get an error during the backward migration.

Autoscale Virtual Server

VS autoscaling allows you to change the RAM, CPU and disk size settings of a virtual server automatically. VS resources scaling is based on rules you specify. For example, you can set up a rule that will add 1000MB of memory to a VS if RAM usage has been above 90% for the last 10 minutes - but add no more than 5000MB in total in 24 hours. You can set autoscaling down settings alongside with autoscaling up.

  • For Linux-based VSs and VS primary disks only.
  • Disk usage autoscaling is applicable for VS primary disk only.
  • Autoscaling for CPU cores is currently not implemented, it is implemented only for CPU units and CPU shares. 
  • If the VS is based on a template that allows resizing without the reboot - see the Edit Virtual Server section – then the VSs RAM or CPU or both can be increased without rebooting the VS. The resources that can be resized without reboot depend on the template and the virtualization type. Some templates support the resize without reboot only for either CPU or RAM. Disk space autoscaling requires a VS reboot.
  • If you autoscale a VS's memory to a value greater than current VS RAM x 16 (which is a max_memory parameter in a configuration file and database), the VS will be rebooted anyway, regardless of the template it is built on.
  • Make sure a VS can be reached via SSH. Otherwise, the autoscaling client installation will fail.
  • Starting with version 4.2, OnApp uses Zabbix for autoscaling. Monitis will be used for autoscaling of servers built using OnApp versions previous to 4.2 until you switch autoscaling off for such server(s). If you decide to switch autoscaling back on, autoscaling will be implemented using Zabbix. Zabbix also will be used for autoscaling of newly created VSs.
  • Note that Monitis support for OnApp autoscaling will come to its end of life on June 30th, 2019 and will be unavailable for use.
  • When autoscaling down is enabled, it will reduce the VS memory and disk size to the minimum, indicated in a template, on which this VS is built. CPU usage can be reduced to the minimum CPU priority allowed by the system(1%).

To configure autoscaling settings:

  1. Go to your Control Panel > Cloud > Virtual Servers menu.
  2. Click the label of the appropriate VS.
  3. On the page that follows, click the Overview tab, and then click Autoscaling.
  4. Click the required tab - Memory Usage, Disk Usage or CPU Usage - to see the statistics for each type of resources.
  5. Below you will see UP and DOWN autoscaling options. Move the slider to the right to add the autoscaling rule or move it to the left to remove the rule.
  6. Add autoscaling rules as explained below:

    Set autoscale up options:
    • Time - select a specific time period in which scaling will be executed. 
    • If RAM usage is above X% for a specific time period, add Y MB – but no more than Z MB in a 24 hour period.
    • If CPU usage is above X % for a specific time period, add Y% - but no more than Z% in a 24 hour period.
    • If disk usage is above X % for a specific time period, add Y GB - but no more than Z GB in a 24 hour period.

    Set autoscale down options:
    • Time - select a specific time period in which scaling will be executed
    • If RAM usage is below X% for a specific time period, remove Y MB.
    • If CPU usage is below X % for a specific time period, remove Y%.
    • If disk usage is below X % for a specific time period, remove Y GB.
  7. Click Apply.

Clicking the Apply button does not activate autoscaling if the Autoscale slider at the VS overview page is disabled. You can configure autoscaling rules, press the Apply button, these rules will be saved and will start working only after the Autoscale slider at VS overview page is enabled. Also, you can disable the Autoscale slider, autoscaling will stop working, but the configuration of rules will be saved in case you want to activate them in future.

Set VIP Status for Virtual Server

If a compute resource fails or reboots, the system migrates virtual servers to another compute resource, one VS at a time. The order VSs are migrated in is random. However, you can give a virtual server "VIP" status, and this will give that VS priority in the migration queue. 

To set or remove VIP status for a VS:

  1. Go to your Control Panel > Cloud > Virtual Servers menu.
  2. Use the icon in the VIP column next to a required virtual server to change switch on/off the VIP status.

Segregate Virtual Server

If required, you can instruct OnApp to make sure a VS is never booted on the same compute resource as another specific VS. This may be important if, for example, you have two name servers or a load balanced web server, and you need to keep VSs on separate physical servers. You can also remove segregation if required.

  • Virtual servers can only be segregated from other VSs built by its owner.
  • Virtual servers can only be segregated from VSs within the same compute zone.
  • Virtual servers cannot be segregated from VSs running on the same compute resource.
  • The segregated VS is not automatically migrated to another compute resource.

To isolate one VS from another:

  1. Go to your Control Panel > Cloud > Virtual Servers menu.
  2. Click the label of the virtual server you want to segregate.
  3. On the screen that appears, click the Actions button, point to Performance, then click Segregate Virtual Server.
  4. In the dialogue box that pops up, use the drop-down menu to choose a VS you want to keep away from.
  5. Click the Segregate Virtual Server button to finish.

To remove segregation:

  1. Go to your Control Panel > Cloud > Virtual Servers menu.
  2. Click the label of the virtual server you want to segregate.
  3. On the screen that appears, click the Actions button, point to Performance, then click Desegregate Virtual Server.
  4. In the dialogue box that pops up, click the OK button to finish.

To remove a segregation rule, go to the OnApp database and run the following:

update virtual_machines set strict_virtual_machine_id=NULL where identifier=XXXXXXXX*; 
CODE

Enable Virsh Console

You can use Virsh console to access a virtual server from a compute resource secure shell and perform various administrative tasks. You can enable Virsh console for the following instances:

  • Virtual servers that run on KVM compute resources.
  • Virtual servers that are built on Linux templates.
  • Virtual servers that are not built from ISO.

You can enable Default Virsh Console Policy via Settings for all newly created virtual servers to have Virsh console by default. For virtual servers that are created before you edit the settings, you can enable the console as follows:

  1. Go to your Control Panel > Cloud > Virtual Servers.
  2. Click a label of a destination virtual server.
  3. Click Actions, point to Options and then click Enable Virsh Console. 
  4. In the dialogue box, click OK to confirm.

After you confirm the action, the virtual server is rebooted and you can access it via Virsh console. 

To access the virtual server via Virsh console, follow the next steps:

  1. Connect via SSH to the destination compute resource. 

  2. Run the following command to list guest VSs using Virsh: 

    virsh list
Id    Name                           State
---------------------------------------------
1     freebsd						running
2     ubuntu						running
3     centos						running
    CODE

  3. Run the following command from the compute resource to log in to the guest named ubuntu: 

    virsh console ubuntu
    CODE

    To exit the console, press CTRL + 5.

Delete Virtual Server

Shut down the virtual server before destroying it. If you are deleting a VS that is running, the VS will be deleted after the time set in Timeout Before Shutting Down VSs configuration parameter.
To remove the virtual server from the cloud:

  1. Go to your Control Panel > Cloud > Virtual Servers menu.
  2. On the screen that appears, you'll see the list of all virtual servers in the cloud. Click the label of the virtual server you want to delete.
  3. On the virtual server's screen, click the Actions button, point to Options, then select Delete Virtual Server.
  4. Move the Move Last Backup to My Templates if it is present slider to the right if you want to save the last VS's backup as a template.
  5. Move the Destroy All Existing Backups slider to the right if you want to remove all existing backups of this virtual server.

IMPORTANT:

  • You won't be able to restore a virtual server after deleting it.
  • Deleting a virtual server removes all data stored on that virtual server. To save the data stored on the virtual server, back up your virtual server and select the Move Last Backup to My Templates if it is present box when following the instructions described in this section.
  • To delete a virtual server together with its backups, the user needs to have the Destroy any backup or Destroy own backup permission enabled. Otherwise, the backups of the VS deleted by the user will remain in the system.


See also:

Leave feedback