DOC: Virtual Machines

• Virtual Machine (VM) deployments can be carried by one of the following components: the main CBTOOL Orchestration Node (in case of VMs deployed explicitly by the CLI, in synchronous/blocking mode), by a "Virtual Machine daemon" (in case of VMs deployed explicitly by the CLI, but in asynchronous/non-blocking mode) or by Virtual Application Daemons or Virtual Application Submitter daemons (always explicitly).

• CBTOOL decides which parameters need to be sent to the cloud based on a Virtual Machine template (Configuration Object [VM_TEMPLATES]). The list of template attributes can be inspected with the command roleshow (role type).

• Virtual Machine templates are defined by supplying at least three key attributes on a “template” file (more optional attributes can be added).

1. A VM role, typically a function performed by the VM within a given Virtual Application type. The VM role is an internal abstraction used extensively by CBTOOL, and has to be mapped to a set of (subsequent) cloud-specific attributes.

2. An image identifier (imageid1). This parameter is used by CBTOOL to decide, upon the instantiation of a new VM with a certain role, which cloud-specific VM image identifier should be supplied to the cloud.

3. An instance size, a cloud-specific identifier to a certain amount of hypervisor resources that the defined VM image will get upon instantiation.

• CBTOOL and SSH KEYS

1. After CBTOOL determines that a VM is fully booted, it has to login on each VM through SSH, in order to configure the basic VM Operating System resource data collection and (in case of VMs that are part of a Virtual Application) applications.

2. To perform the SSH login, CBTOOL uses the username (it has to be a user other than root) defined by the parameters login and a private SSH key defined in ssh_key_name. You can check the current value of these parameters with the command cldshow vm_defaults. Despite being part of the Configuration Object [VM_DEFAULTS], these values are read from the section [USER-DEFINED : CLOUDOPTION_XYZ ] on your private configuration file.

3. This means that the public part of the SSH key has to be injected on the VM, inside the file /home/USERNAME EQUALS VALUE OF THE LOGIN PARAMETER DEFINED IN THE CBTOOL CONFIGURATION FILE/.ssh/authorized_keys. The SSH key injection capabilities vary wildly from cloud to cloud, and while preparing a VM to be used with CBTOOL on a real cloud, there are 3 possible courses of action:

   a) Your cloud is able of injecting the appropriate public SSH into your VM during the boot process, taking care of writing the key to appropriate authorized_keys file belonging to the defined user. This is a very rare scenario, since it typically requires full support for cloud-init and the editing of /etc/cloud/cloud.cfg file to indicate which user should receive the injected key. If your cloud is in this category, the values of the parameters X_KEY_NAME and X_SSH_KEY_NAME (e.g., OSK_KEY_NAME and OSK_SSH_KEY_NAME) MUST be the same.

   b) Your cloud takes care of injecting the appropriate public SSH into your VM during the boot process, but only does that for the root user. If that is the case, then boot a VM, let the key defined in X_KEY_NAME (e.g., OSK_KEY_NAME) get injected for the root user, and then manually copy the contents of the keys file (/root/.ssh/authorized_keys) to /home/USERNAME EQUALS VALUE OF THE LOGIN PARAMETER DEFINED IN THE CBTOOL CONFIGURATION FILE/.ssh/authorized_keys. When the script ~/cbtool/scripts/common/cb_cleanup.sh is run, before capturing the VM, this action (copying the contents of the root's key file) is done automatically. If your cloud is in this category, then the values of the parameters X_KEY_NAME and X_SSH_KEY_NAME (e.g., OSK_KEY_NAME and OSK_SSH_KEY_NAME) CAN be the same.

   c) Your cloud does not support any kind of key injection. If that is the case, then boot a VM, manually scp the key file to the appropriate directory (/home/USERNAME EQUALS VALUE OF THE LOGIN PARAMETER DEFINED IN THE CBTOOL CONFIGURATION FILE/.ssh/authorized_keys), perform all other steps described in preparing a VM to be used with CBTOOL on a real cloud and just capture the VM. If your cloud in this category then the value of the parameter X_KEY_NAME (e.g., OSK_KEY_NAME) simply does not matter. CBTOOL will just use the private key file name defined in X_SSH_KEY_NAME (e.g., OSK_SSH_KEY_NAME) to login on the VMs.