-
Notifications
You must be signed in to change notification settings - Fork 50
- What do I need to start using CBTOOL?
- I see that CBTOOL can run a variety of different benchmarks/workloads. Will CBTOOL install these applications (e.g., Hadoop, MySQL, DB2, WebSphere) on the VMs automatically for me?
- What are the differences between a Virtual Application (VApp) and a Virtual Application Submitter (VAppS)?
- The documentation refers to Virtual Application (VApp) and a Virtual Application Submitter (VAppS), but on CBTOOL's CLI, messages and commands keep referring to Application Instance (AI) and Application Instance Deployment Request Submitter (AIDRS).
- What is my "private" cloud configuration file? Where is it located?
- What is the difference between
--soft_resetand--hard_reset? - I understand that there are in fact two ways to alter an attribute on an Object: (a) by changing my private cloud configuration file or (b) by issuing
cldalter,rolealter,typealterandpatternaltercommands on the CLI. That is a tiny bit confusing. Are there any guidelines on when to use (a) or (b)? - I just want the instantiate VMs, but don't want them to run any application. I just want to see the cloud's provisioning performance with "zero application load". Can I do that with CBTOOL?
- I know that the Virtual Application Submitters can continuously deploy Virtual Applications with a certain arrival rate. What I want is to deploy a bunch of Virtual Applications at once (i.e., "bulk arrival"). Can I do that with CBTOOL?
- Can I use CBTOOL to just deploy a Virtual Application, without generating load after it is started?
- I have an external Redis/MongoDB node (or set of nodes) that I would like to use as Object Store/Metric Store for CBTOOL. Which configurations do I need to change to "point" CBTOOL to these?
- In the configuration file, each cloud has two attributes relating to SSH keys (e.g., OSK_KEY_NAME and OSK_SSH_KEY_NAME for OpenStack). This seems confusing. What exactly are these?
- Can CBTOOL's OpenStack cloud adapter be used to instantiate VMs on RackSpace?
- [I am creating a new Virtual Application (VApp) type for CBTOOL. How can I debug my application-specific "setup" configuration scripts?] (https://github.com/ibmcb/cbtool/wiki/FAQ#wiki-q14)
- [Do you have any sizing guidelines for the CBTOOL orchestrator node?] (https://github.com/ibmcb/cbtool/wiki/FAQ#wiki-q15)
- I have tried to attach an OpenStack Cloud to an experiment and got the following error: status: ERROR! Please make sure that the network "private" can be found VMC NNNN
- I have tried to attach an OpenStack Cloud to an experiment and got the following error: status: ERROR! None of the image ids used by any VM "role" were detected in this OpenStack cloud. Please register at least one of the following images:...
- Can I use CBTOOL with OpenStack's Nova "Fake Driver"?
- Can I use CBTOOL to deploy and run Virtual Applications on bare-metal nodes, or even pre-deployed, already running VMs?
- How can I quickly check the number of VMs failed/deployed?
- I have a VM image that was configured to run a certain application with a username different than the username that is indicated on the VM role template. Is there a way for me to specify a per-Virtual Application-type login for each VM "role"?
- Can I extract collected performance data directly from the Metric Store?
- How can I experiment with VM image capture on a cloud?
- I know that CBTOOL keeps polling the cloud in order to determine when VMs become "active" (i.e., the instance started the booting process). How can I control the polling frequency?
- [I have a Virtual Application Submitter (VAppS) (Application Instance Deployment Request Submitter (AIDRS)) and just want to have it immediately stopping the deployment of new Virtual Application instances, while still removing the ones already created, once their lifetime expires. How can I do it?] (https://github.com/ibmcb/cbtool/wiki/FAQ#wiki-q25)
- I want to run the CBTOOL orchestrator node outside the cloud/I want to run a single large CBTOOL orchestrator node that benchmarks multiple clouds. How should I configure CBTOOL?
- How can I control the operation (e.g., vmattach) parallelism in CBTOOL?
- How can I debug vmattach errors in the post-instance start phase?
- When using CBTOOL with the OpenStack Cloud Adapter, can I instruct it to create each new VM or Virtual Application on its own tenant/network/subnet/router?
- Can I set SLA targets for Virtual Application provisioning time and performance?
- Can I "scale-out" (i.e., increase the number of VMs) an already deployed Virtual Application instance?
- Can I run multiple instances of CBTOOL on the same orchestrator node?
Q1: What do I need to start using CBTOOL?
A1: Three things. a) Access to an IaaS (public or private) cloud (see the list of clouds supported [here] (https://github.com/ibmcb/cbtool/wiki/DOC:-Supported-Clouds). b) One or more images that are prepared to be used with CBTOOL (see how to do it [here] (https://github.com/ibmcb/cbtool/wiki/HOWTO:-Preparing-a-VM-to-be-used-with-CBTOOL-on-a-real-cloud). c) A VM or HOST (with network access to the cloud), were CBTOOL can be installed (see how to do it [here] (https://github.com/ibmcb/cbtool/wiki/HOWTO:-Initial-Installation).
Q2: I see that CBTOOL can run a variety of different benchmarks/workloads. Will CBTOOL install these applications (e.g., Hadoop, MySQL, DB2, WebSphere) on the VMs automatically for me?
A2: No. CBTOOL assumes that the application binaries are already installed on the image. It will configure and start the applications automatically (as explained [here] (https://github.com/ibmcb/cbtool/wiki/DOC:-Virtual-Application-Deployment)) but you will have to perform the initial install. Some (but not all) workloads do have an automated installer, which can be invoked with ~/cbtool/install --wks <workload type>. Not however, that you still have to: a) boot a VM, b) run the installer, c) run ~/cbtool/scripts/common/cb_prepare_for_capture.sh, d) capture the VM and e) add the VM back into the [VM_TEMPLATES] section of your private cloud configuration file.
Q3: What are the differences between a Virtual Application (VApp) and a Virtual Application Submitter (VAppS)?
A3: You can deploy multiple instances of Virtual Application (VApps) in "immediate" mode by typing the command aiattach (vapp type) on CBTOOL's CLI. It is useful if you want to deploy a fixed number Virtual Applications and then collect data on the VApp's application performance. A VApp deployed explicitly will run until you remove it. Virtual Application Submitters (VAppS), on other side, keep deploying Virtual Applications, running it for a specified time, and then removing it. Please take a look at the [CBTOOL Key Concepts] (https://github.com/ibmcb/cbtool/wiki/DOC:-Key-Concepts)
Q4: The documentation refers to Virtual Application (VApp) and a Virtual Application Submitter (VAppS), but on CBTOOL's CLI, messages and commands keep referring to Application Instance (AI) and Application Instance Deployment Request Submitter (AIDRS).
A4: For "historical" reasons, the code still uses the "old" nomenclature (it will be changed someday). For now, just keep in mind:
Virtual Application (VApp) = Application Instance (AI)
Virtual Application Submitter (VAppS) = Application Instance Deployment Request Submitter (AIDRS)
Q5: What is my "private" cloud configuration file? Where is it located?
A5: Your "private" configuration file contains configuration changes made on CBTOOL when running on your environment, as explained here. By the default, CBTOOL looks for a file called (your username)_cloud_definitions.txt in ~/cbtool/configs, but you can indicate any other file by just running the tool's CLI with the --config option (e.g. ~/cbtool/cb --config <another cloud configuration file>.txt).
Q6: What is the difference between --soft_reset and --hard_reset ?
A6: "Soft Reset" kill all running CBTOOL daemons (list of daemons here) and cleans up the Object Store. "Hard Reset" goes beyond that by also removing any old log files from the Log Store, and removes all the collected performance data from the Metric Store. The cleanup of the Metric Store is kind of a big deal. If you didn't extract all values from the Metric Store to comma-separated value files using the command monextract, you will lose experiment data permanently.
Q7: Reading here and here, I understand that there are in fact two ways to alter an attribute on an Object: (a) by changing my private cloud configuration file or (b) by issuing cldalter, rolealter, typealter and patternalter commands on the CLI. That is a tiny bit confusing. Are there any guidelines on when to use (a) or (b)?
A7: While any Object could be changed by adding overriding attributes on your private cloud configuration file, we believe that it is a "best practice" to alter any parameters on the Configuration (Global) Objects that refer to your particular environment in your private configuration file, but alter any parameter on objects that refer to any VM, VApp or VAppS directly on the CLI (i.e., directly on the Object Store). It means that any experiment trace file submitted to CBTOOL should explicitly include the command to alter these Configuration Objects, increasing the reproducibility of your experiment, should you send it to another person to be re-run. The following table summarizes it, with some examples:
| Configuration Object | Altering method | Example | Comment |
|---|---|---|---|
| [OBJECTSTORE] | private configuration file |
[OBJECTSTORE] ... PORT = 10000 ... |
Refers only to *your* specific environment |
| [LOGSTORE] | private configuration file |
[LOGSTORE] ... VERBOSITY = 5 ... |
Refers only to *your* specific environment |
| [METRICSTORE] | private configuration file |
[METRICSTORE] ... DATABASE = mymetrics ... |
Refers only to *your* specific environment |
| [SPACE] | private configuration file |
[SPACE] ... STORES_WORKING_DIR = /home/$MAIN_USERNAME/stores ... |
Refers only to *your* specific environment |
| [TIME] | private configuration file |
[TIME] ... STORES_WORKING_DIR = /home/$MAIN_USERNAME/stores ... |
Refers only to *your* specific environment |
| [VMC_DEFAULTS] | private configuration file |
[VMC_DEFAULTS] ... DISCOVER_HOSTS = $True ... |
Refers only to *your* specific environment |
| [VM_DEFAULTS] | CLI or experiment trace file | cldalter vm_defaults run_generic_scripts=false | Refers only to an specific experiment |
| [VM_TEMPLATES] | private configuration file (cloud-specific) |
[VM_TEMPLATES : OSK_CLOUDCONFIG] ... HADOOPMASTER = size:m1.small, imageid1:cloudbench_root ... [VM_TEMPLATES : EC2_CLOUDCONFIG] ... HADOOPMASTER = size:m1.large, imageid1:ami-b3e44dda ... |
Refers only to *your* specific environment |
| [AI_DEFAULTS] | CLI or experiment trace file | cldalter ai_defaults attach_parallelism=5 | Refers only to an specific experiment |
| [AI_TEMPLATES] | CLI or experiment trace file | typealter daytrader db2_on_ramdisk=true | Refers only to an specific experiment |
| [AIDRS_DEFAULTS] | CLI or experiment trace file | cldalter aidrs_defaults daemon_parallelism=100 | Refers only to an specific experiment |
| [AIDRS_TEMPLATES] | CLI or experiment trace file | patternalter simplenw iait=10 | Refers only to an specific experiment |
Q8: I just want the instantiate VMs, but don't want them to run any application. I just want to see the cloud's provisioning performance with "zero application load". Can I do that with CBTOOL?
A8: Yes. Just deploy one or more instances of the Virtual Application (VApp) called NullWorkload. On the CLI, type aiattach nullworkload
Q9: I know that the Virtual Application Submitters can continuously deploy Virtual Applications with a certain arrival rate. What I want is to deploy a bunch of Virtual Applications at once (i.e., "bulk arrival"). Can I do that with CBTOOL?
A9: Yes. On the CLI, just type aiattach (vapp type) async=N (where N is the number of Virtual Applications)
Q10: Can I use CBTOOL to just deploy a Virtual Application, without generating load after it is started?
A10: Yes. On the CLI, just type cldalter ai_defaults dont_start_load_manager=true. After this, any VApp deployed with aiattach (vapp type) will just be deployed, without generating any application load.
Q11: I have an external Redis/MongoDB node (or set of nodes) that I would like to use as Object Store/Metric Store for CBTOOL. Which configurations do I need to change to "point" CBTOOL to these?
A11: UPDATE: The "shared" attribute is now the default for Object and Metric Stores.
Assuming that the Object and Metric Stores are reachable through IP address "ABC", add the following line to your "private" configuration file (more information on private configuration files can be found here):
...
[OBJECTSTORE]
HOST = ABC
USAGE = shared
...
[METRICSTORE]
HOST = ABC
USAGE = shared
```
...
...
[LOGSTORE] HOST = ABC USAGE = shared
....
Please note the "shared" attribute means that CBTOOL will stop controlling the Stores' state (i.e., it will stop trying to automatically start it every time the CLI is run). Also keep in mind that it is important for the network latency between the CBTOOL orchestrator node, this external node that houses the _Object Store_/_Metric Store_ and the instantiated VMs might play an important role, specially when performance data is being collected at a high frequency.
***
**Q12**: <a name="q12"/>In the [USER-DEFINED] section of many clouds (e.g., OpenStack, Amazon EC2) there are two attributes relating to SSH keys (e.g., OSK_KEY_NAME and OSK_SSH_KEY_NAME for OpenStack). This seems confusing. What exactly are these?
A12: **UPDATE: CBTOOL can now automatically create SSH keys. A typical user will not have to deal with these complexities anymore.**
Let's use OpenStack (OSK) as an example. The OSK_KEY_NAME is the name of the (public) key that will be "injected" on an image before it is booted. For instance, in OpenStack, the key is normally injected in ```/root/.ssh/authorized_keys```, allowing a user to login on a VM after the boot as root. This attribute refers to a key that is managed directly by the OpenStack cloud.
On other hand, OSK_SSH_KEY_NAME is the name of the key used to login on a VM as the user (non-root) specified by OSK_LOGIN. This key will not (necessarily) be injected on the image. It is expected that the key and username specified by OSK_SSH_KEY_NAME and OSK_LOGIN are pre-defined on the VM. These attributes are not managed (or known at all) by the OpenStack cloud.
***
**Q13**: <a name="q13"/>Can CBTOOL's OpenStack cloud adapter be used to instantiate VMs on RackSpace?
A13: Yes. While installing the dependencies on the CBTOOL orchestrator node (see how to do it [here] (https://github.com/ibmcb/cbtool/wiki/HOWTO:-Initial-Installation), install the python novaclient with the Rackspace authentication extensions with ```sudo pip install rackspace-novaclient``` (if you already installed the "regular" python-novaclient, just use ```sudo pip install --upgrade rackspace-novaclient```).
The OpenStack (OSK) section of your configuration file should look like this:
[USER-DEFINED : CLOUDOPTION_TESTOPENSTACK ]
OSK_ACCESS = https://identity.api.rackspacecloud.com/v2.0/
OSK_CREDENTIALS = ```YOUR_RACKSPACE_USER```-```YOUR_RACKSPACE_API_KEY```-```YOUR_RACKSPACE_USER```
OSK_SECURITY_GROUPS = default
OSK_INITIAL_VMCS = DFW:sut
OSK_LOGIN = cbuser
The possible values for the OSK_INITIAL_VMCS attribute are either "DFW:sut", "ORD:sut", or both.
The "RACKSPACE_API_KEY" can be obtained from the "Rackspace Control Panel". Go to the upper right corner, and click on the drop-down menu where your user name is.
***
**Q14**: <a name="q14"/>I am creating a new _Virtual Application_ (VApp) type for CBTOOL. How can I debug my application-specific "setup" configuration scripts?
A14: [Debug instructions](https://github.com/ibmcb/cbtool/wiki/HOWTO:-Debug-initial-setup)
***
**Q15**: <a name="q15"/>Do you have any sizing guidelines for the CBTOOL orchestrator node?
A15: The CBTOOL code is being constantly optimized, so expect these guidelines to change frequently. The sizing of the orchestrator node is closely related to the size of the experiment (in numbers of simultaneously active VMs) to be executed. In CBTOOL the primary source of resources consumption is the _Object Store_ and _Metric Store_. The resource amount consumed by this source is closely related to the number of running VMs, since each VM keeps updating/accessing both stores continuously. A second source of resource consumption are the _Virtual Application Submitters_. Since each VAppS is managed by a pair of python daemons running on the orchestrator node, the resource amount is directly related to the number of simultaneously running VAppS on a given experiment.
A good rule of thumb for processing power sizing is two cores for all CBTOOL daemons (list of daemons [here](https://github.com/ibmcb/cbtool/wiki/DOC:-Detailed-Architecture)), plus 1 core for every 2000 VMs (again, simultaneously active VMs), plus 1 core for every 200 VAppS. For memory, the rule of thumb is 2 GB of RAM for all daemons, plus 5 MB for every VM, plus 100 MB for every VAppS.
An alternative deployment architecture, where an external Redis server is used as the _Object Store_ and an external MongoDB is used as the _Metric Store_, is recommended in order to make CBTOOL much more scalable (both Redis and MongoDB can be scaled-out). Details on how to configure CBTOOL to use external servers are present in [Q9](https://github.com/ibmcb/cbtool/wiki/FAQ#wiki-q9). Evidently, in this particular case, the CBTOOL orchestration node sizing requirements can be greatly reduced.
***
**Q16**: <a name="q16"/> I have tried to attach an OpenStack Cloud to an experiment and got the following error: **status: ERROR! Please make sure that the network "private" can be found VMC NNNN**
A16: When CBTOOL is deploying new VMs, it has to contact and then login on each individual VM, as explained in detail [here] (https://github.com/ibmcb/cbtool/wiki/DOC:-Detailed-Virtual-Application-Deployment-Steps). In case of OpenStack, CBTOOL has to instantiate VMs by indicating (among other parameters), the name of an already existing virtual network that they will be connected to. The list of already existing virtual networks in OpenStack can be obtained by running a (novaclient) command like ```nova network-list```. By default CBTOOL assumes that the OpenStack virtual network that will be used to connect all VMs is named "private". If this is not the case, there are two possible options: a) use the OpenStack CLI (novaclient) or GUI to create a new network and call it "private" (remember, the CBTOOL orchestrator node is supposed to have access to this network) or b) change the network name by assigning the name of an already existing network to the parameter OSK_NETNAME on your [private configuration file] (https://github.com/ibmcb/cbtool/wiki/FAQ#wiki-q5) :
***
**Q17**: <a name="q17"/> I have tried to attach an OpenStack Cloud to an experiment and got the following error: **status: ERROR! None of the image ids used by any VM "role" were detected in this OpenStack cloud. Please register at least one of the following images:...**
A17: One of the main attributes of a VM role, as explained the [CBTOOL Key Concepts] (https://github.com/ibmcb/cbtool/wiki/DOC:-Key-Concepts) is its mapping to a cloud-specific image identifier (imageid). For instance, the VM with the role "DB2" is mapped to a particular imageid in OpenStack. The default role-to-imageid mapping is done ```~/cbtool/configs/templates/_openstack```, in the [VM_TEMPLATES : OSK_CLOUDCONFIG] section (please note that this mapping is always cloud-specific). You need to have at least one of the image identifiers listed there already present in your OpenStack cloud (a novaclient command like ```nova image-list``` will show the list of the already present image identifiers). If you wish to change the image identifiers (i.e., you want to point any VM role to a different image identifier), you can do so by adding a [VM_TEMPLATES : OSK_CLOUDCONFIG] section to your own [private configuration file] (https://github.com/ibmcb/cbtool/wiki/FAQ#wiki-q5).
***
**Q18**: <a name="q18"/> Can I use CBTOOL with OpenStack's Nova "Fake Driver"?**
A18: Yes. When using the OpenStack Nova Fake Driver, CBTOOL needs to be instructed to forfeit the execution of any steps beyond the number 5 (as shown in the [Deployment Detailed Timeline](https://github.com/ibmcb/cbtool/wiki/DOC:-Detailed-Virtual-Application-Deployment-Steps)). After all, there will be no actual VM to connect to, and thus the checking of the boot ending, the upload of a copy of the code, and the generic and application startup processes cannot be performed. To this end, execute the following commands:
```cldalter vm_defaults check_boot_complete wait_for_0```
```cldalter vm_defaults transfer_files False```
```cldalter vm_defaults run_generic_scripts False```
```cldalter ai_defaults run_application_scripts False```
```cldalter ai_defaults dont_start_load_manager true```
With these commands in place, CBTOOL will basically issue a provisioning request to nova-api, wait until the instance state is "ACTIVE", and the consider the provisioning done.
***
**Q19**: <a name="q19"/> Can I use CBTOOL to deploy and run _Virtual Applications_ on bare-metal nodes, or even pre-deployed, already running VMs?
A19: Yes, in a limited fashion. Please take a look at the [NO Operation cloud adapter](https://github.com/ibmcb/cbtool/wiki/HOWTO:-Use-the-NOOP-cloud-adapter).
***
**Q20**: <a name="q20"/> How can I quickly check the number of VMs failed/deployed?
A20: Just use the ```stats``` command, and look for the counters under the "------------------ EXPERIMENT-WIDE COUNTERS ------------------" section.
***
**Q21**: <a name="q21"/> I have a VM image that was configured to run a certain application with a username different than the username that is indicated on the VM role template. Is there a way for me to specify a per-_Virtual Application_-type login for each VM "role"?
A21: This can be accomplished in two ways:
1) Just re-define the VM role attributes directly on your private [private configuration file] (https://github.com/ibmcb/cbtool/wiki/FAQ#wiki-q5), on the "VM_TEMPLATES" _Configuration (Global) Object_.
Example:
[VM_TEMPLATES : OSK_CLOUDCONFIG] CASSANDRA = size:m1.medium, imageid1:cb_speccloud_cassandra_2111, login:cbuser SEED = size:m1.medium, imageid1:cb_speccloud_cassandra_2111, login:cbuser
2) Just use the ```typealter``` command to specify a different login for each VM "role" on your _Virtual Application_.
For instance, suppose that the VM with role "db2" has to be accessed using the user "db2user", while the other VM "roles" ("client_daytrader", "was") on the _Virtual Application_ "ibm_daytrader" can be accessed by the user "causer". By issuing the command ```typealter ibm_daytrader db2_login db2user```, CBTOOL will make sure that db2 VMs will always be contacted using this particular user.
***
**Q22**: <a name="q22"/> Can I extract collected performance data directly from the _Metric Store_?
A22: Yes. Take a look at this [how to](https://github.com/ibmcb/cbtool/wiki/HOWTO:-Extract-performance-data-directly-from-the-Metric-Store)
***
**Q23**: <a name="q23"/> How can I experiment with VM image capture on a cloud?
A23: Assuming that your cloud supports the "capture" operation from within CBTOOL - the support is clearly specified in the [supported clouds list] (https://github.com/ibmcb/cbtool/wiki/DOC:-Supported-Clouds) - individual _Virtual Machines_ (i.e. VMs that do not belong to any _VApp_) can be captured with the command ```vmcapture VM_NAME```, while _Virtual Applications_ can be captured with the command ```aicapture AI_NAME```. Please note that in the case of the _Virtual Applications_, CBTOOL will capture only one of the VMs that are part of the _VApp_, just destroying all others in the process.
***
**Q24**: <a name="q24"/> I know that CBTOOL keeps polling the cloud in order to determine when VMs become "active" (i.e., the instance started the booting process). How can I control the polling frequency?
A24: Both the number of polling attempts (for each VM creation) and the interval between attempts are controlled by the ```UPDATE_FREQUENCY``` and ```UPDATE_ATTEMPTS``` attributes on the [configuration object](https://github.com/ibmcb/cbtool/wiki/DOC:-Configuration-Objects) _VM_DEFAULTS_. If you want to change these, just add the following entry to your [private configuration file] (https://github.com/ibmcb/cbtool/wiki/FAQ#wiki-q5):
[VM_DEFAULTS] UPDATE_FREQUENCY = SECONDS BETWEEN STATUS REQUESTS FROM THE CLOUD UPDATE_ATTEMPTS = NUMBER OF TIMES STATUS REQUESTS ARE MADE BEFORE DECLARING THAT VM FAILED TO START
Please note that a similar attribute pair exists for other configuration objects, such as _AI_DEFAULTS_ (e.g., how many time should an application start script attempted to be executed before declaring a _Virtual Application_ deployment as failed) and _AIDRS_DEFAULTS_ (e.g., what is the interval between checks if a given _Virtual Application_ already past its lifetime). The **default** value for all parameter pairs on each configuration object is taken for _MAIN_UPDATE_FREQUENCY_ and _MAIN_UPDATE_ATTEMPTS_, specified in the USER-DEFINED section of your private configuration file.
***
**Q25**: <a name="q25"/> I have a _Virtual Application Submitter_ (VAppS) (_Application Instance Deployment Request Submitter_ (AIDRS)) and just want to have it immediately stopping the deployment of new _Virtual Application_ instances, while still removing the ones already created, once their lifetime expires. How can I do it?
A25: Instead of removing the _Virtual Application Submitter_, which would result on _Virtual Application_ instances created by this particular VAppS dangling perpetually (since no process is left to make sure that each individual VApp by deployed by this _Virtual Application Submitter_ is removed when their lifetime expires), the VAppS can be put on the "stopped" state. On CBTOOL's CLI, type the command ```statealter VAppS_NAME stopped```. To resume normal operation on the _Virtual Application Submitter_, use the command ```statealter VAppS_NAME attached```.
***
**Q26**: <a name="q26"/> I want to run the CBTOOL orchestrator node outside the cloud/I want to run a single large CBTOOL orchestrator node that benchmarks multiple clouds. How should I configure CBTOOL?
A26: This [how to](https://github.com/ibmcb/cbtool/wiki/HOWTO:-Run-the-CloudBench-orchestrator-outside-of-the-cloud-%28or-with-multiple-tenant-networks%29) will show you how to do this.
***
**Q27**: <a name="q27"/> How can I control the operation (e.g., vmattach) parallelism in CBTOOL?
A27: In CBTOOL specific operations, executed over specific objects, can be configured with different degrees of parallelism. For instance, to set the parallelism for operations against _Virtual Application_ instances, the following parameters can be set in your [private configuration file] (https://github.com/ibmcb/cbtool/wiki/FAQ#wiki-q5) (here the default values for a generic cloud are shown)
...
[AI_DEFAULTS] ATTACH_PARALLELISM = 1 DETACH_PARALLELISM = 20 EXECUTE_PARALLELISM = 6 RUNSTATE_PARALLELISM = 5
...
IMPORTANT: These same parameters are used by CBTOOL during the execution of the "clddetach" operation.
***
**Q28**: <a name="q28"/> How can I debug vmattach errors in the post-instance start phase?
A28: [Debug instructions](https://github.com/ibmcb/cbtool/wiki/HOWTO:-Debug-initial-setup)
***
**Q29**: <a name="q29"/> When using CBTOOL with the OpenStack Cloud Adapter, can I instruct it to create each new VM or Virtual Application on its own tenant/network/subnet/router?
A29: CBTOOL has the ability to execute generic scripts at specific points during the VM attachment (e.g., before the provision request is issued to the cloud, after the VM is reported as "started" by the cloud). A [small example script](https://github.com/ibmcb/cbtool/blob/experimental/scenarios/scripts/openstack_multitenant.sh) which creates a new keystone tenant, a new pubkey pair, a new security group and a neutron network, subnet and router was made available to under the "scenarios/util" directory.
To use it with VMs (i.e., each VM on its own tenant/network/subnet/router) issue the command ```cldalter vm_defaults execute_script_name=/home/cbuser/cbtool/scenarios/scripts/openstack_multitenant.sh``` on the CLI. After this each new VM that is attached with a command like ```vmattach tinyvm auto empty default execute_provision_originated``` will execute the aforementioned script. In case of the API, just add the parameter "pause_step" to the call (e.g., *cbapi.vmattach(cloud_name, role, pause_step = "execute_provision_originated")*).
To use it with Virtual Applications (i.e., ALL VMs belonging to a VApp on its own tenant/network/subnet/router) issue the command ```cldalter ai_defaults execute_script_name=/home/cbuser/cloudbench/scenarios/scripts/openstack_multitenant.sh``` on the CLI. After this each new VAPP that is attached with a command like ```aiattach nullworkload default default none none execute_provision_originated``` will execute the aforementioned script. In case of the API, just add the parameter "pause_step" to the call (e.g., *cbapi.appattach(cloud_name, type, pause_step = "execute_provision_originated")*.
Please note that the commands listed on the script will be executed *from the Orchestrator node*, and thus require the existence of all relevant OpenStack CLI clients (e.g., openstack, nova and neutron) present there.
***
**Q30**: <a name="q30"/> Can I set SLA targets for Virtual Application provisioning time and performance?
Yes, CBTOOL now has rudimentary support for SLA tracking. Great care was taken to make sure that this new capability is non-intrusive to users that prefer to have their SLA tracking done from the outside. Two kinds of SLA tracking are possible, provisioning and runtime.
If a VM is deployed with the attribute "sla_provisioning_target" set, then CBTOOL will calculate, at the end of the provisioning, if the total time taken to provision is smaller than the specified value, adding a new attribute - "sla_provisioning" - with values "ok" or "violated" to the VM. In addition to it, it will also add the VM to a "view" (i.e., a list of objects that share a common attribute) that can be queried at any time.
Example for SLA provisioning:
The command ```aiattach nullworkload tinyvm_sla_provisioning_target=50``` (the API equivalent of this command is *api.appattach("TESTSIMCLOUD", "nullworkload", temp_attr_list="tinyvm_sla_provisioning_target=1*)) will cause CBTOOL to automatically check if the total provisioning time is smaller than 50, and then place the VM on a list of VMs with violated or obeyed SLA provisioning. These lists (also known as "views" internally by CBTOOL) can be accessed by the command ```viewshow```.
A list of VMs who violated the provisioning SLA can be obtained with ```viewshow vm sla_provisioning violated```, while a list of VMs who fulfilled the SLA can be with obtained with ```viewshow vm sla_provisioning ok```. The API equivalent of these commands is *api.viewshow("TESTSIMCLOUD", "VM", "SLA_PROVISIONING", "OK")*.
Example for SLA runtime:
The command ```aiattach nullworkload sla_runtime_target_bandwidth=100-gt``` will cause CBTOOL to automatically check if the reported application bandwidth is smaller than 100 (that is controlled by "gt" or "greater than" and "lt" or "less than"), and then place the VM on a list of VMs with violated or obeyed SLA runtime.
A list of VMs who violated the SLA can be obtained with ```viewshow vm sla_runtime violated```, while a list of VMs who fulfilled the SLA can be with ```viewshow vm sla_runtime ok```. The API equivalent of these commands is *api.viewshow("TESTSIMCLOUD", "VM", "SLA_RUNTIME", "OK")*.
***
**Q31**: <a name="q31"/> Can I "scale-out" (i.e., increase the number of VMs) an already deployed _Virtual Application_ instance?
Yes, CBTOOL has the CLI command (and API call) "airesize" to this end. For instance, the command ```airesize TESTCLOUD ai_1 hadoopslave +1``` would add one additional Hadoop slave node (VM) to the already running _VApp_ ai_1. Conversely, a Hadoop slave node (VM) could be removed with ```airesize TESTCLOUD ai_1 hadoopslave -1```.
Please note that, while the airesize command could be applied to any _Virtual Application_ type, it is basically intended to be used with "scale-out" workloads (_Vapp_ types), such as Hadoop and HPCC.
***
**Q32**: <a name="q32"/> Can I run multiple instances of CBTOOL on the same orchestrator node?
Yes, **as long as each instance is ran under a different user** (this is extremely important). For each user, change the following parameters on your [private configuration file] (https://github.com/ibmcb/cbtool/wiki/FAQ#wiki-q5), picking different values for each user:
[OBJECTSTORE] DBID = 10
[LOGSTORE] PORT = 5137
[FILESTORE] PORT = 10037
[VPN] SERVER_PORT = 11037
[API_DEFAULTS] PORT = 7037
[GUI_DEFAULTS] PORT = 8037