Skip to content
maugustosilva edited this page Oct 8, 2019 · 48 revisions

Use


UQ1: What is the difference between --soft_reset and --hard_reset?

UA1: "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.

Back


UQ2: I see that CBTOOL has a GUI. Where can I learn more?

UA2: Basic information on how administrating the tool with the Graphical Environment. You can monitor the statistics collected by CBTOOL on the dashboard tab. The latter can be customized.

Back


UQ3 How can I quickly check if performance data is being properly generated by CBTOOL?

UA3: Just deploy one or more instances of a Virtual Application (VApp) via the CLI (aiattach nullworkload). Once the prompt returns, wait a couple of minutes an type monlist VM. You should a list of VMs which reported management, runtime (OS) and runtime (Applications) metrics. It should include the number of samples per VM, as well as the age of the latest sample.

Back


UQ4 How can I extract/save the performance data generated by CBTOOL?

UA4: Issue the CLI command monextract all, will instruct CB to get all the performance data from the Metric Store and dump it on four comma-separated value files (.csv), under a newly created directory named after the experiment (i.e., ~/cbtool/data/<experiment_identifier>). These files are briefly describe as follows:

  1. VM_management_<experiment_identifier>.csv: contains information regarding the provisioning time, capture time, among others, all extracted directly from the cloud management system.

  2. VM_runtime_app_<experiment_identifier>.csv: contains information regarding the application performance, such as latency, throughput and bandwidth, all generated directly from the VM.

  3. VM_runtime_os_<experiment_identifier>.csv: contains OS metrics (CPU, memory, disk I/O, network I/O) all generated by the VM.

  4. HOST_runtime_os_<experiment_identifier>.csv: contains OS metrics (CPU, memory, disk I/O, network I/O) all generated by the HOSTS. It can only be used on Clouds where there is direct access to the hosts (this means that this data cannot be collected on EC2, for instance), and where the Ganglia monitoring tool was manually configured on the hosts.

USEFUL TIP: in order to quickly check the sanity of the files directly on a text-only shell, install tabview (sudo pip3 install tabview) and issue the (outside CB CLI, of course), a command such as tabview --width max --delimiter , ~/cbtool/data/experiment_identifier/VM_runtime_app_experiment_identifier.csv

Back


UQ5: Do you have any utilities for automatic data plot generation?

UA5: Yes, issuing the CLI command monextract all, will instruct CB to get all the performance data from the Metric Store and dump it on four comma-separated value files (.csv), under a newly created directory named after the experiment (i.e., ~/cbtool/data/<experiment_identifier>). In addition to these files, a helper script, ~/cbtool/data/<experiment_identifier>/plot.sh will be created. This script invokes the CBTOOL - experimental GNU R code - ~/cbtool/util/plot/cbplotgen.R which will produce graphs.

Back


UQ6: What is the difference between the attributes NETNAME, RUN_NETNAME and PROV_NETNAME?

UA6:TBD

Back


UQ7: Does CBTOOL supports cloud-init?

UA7:TBD

Back


UQ8: How can I quickly check if CBTOOL is properly configured to deploy VMs in my cloud`?

UA8:TBD

Back


UQ9: 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?

UA9: Yes. Just deploy one or more instances of the Virtual Application (VApp) called NullWorkload. On the CLI, type aiattach nullworkload

Back


UQ10: How can I quickly check the number of VMs failed/deployed?

UA10: Just use the stats command, and look for the counters under the "------------------ EXPERIMENT-WIDE COUNTERS ------------------" section.

Back


UQ11: 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"?

UA11: This can be accomplished in three ways:

  1. Just re-define the VM role attributes directly on your private private configuration file, on the "VM_TEMPLATES" Configuration (Global) Object, just as described here

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
  1. Just use the typealter command to specify a different login for each VM "role" on your Virtual Application. Also described in further detail here

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.

  1. Finally, the specific parameters can be dynamically overridden during a VApp deployment. For instance, the command aiattach ibm_daytrader default default none none none db2_login=db2user,was_login=appuser will override whatever is defined on the here or what was defined through the typealter command.

IMPORTANT : please note that these three ways are simply a particular case of the generalized parameter change methods here and here.

Back


UQ12: Can I extract collected performance data directly from the Metric Store?

UA12: Yes. Take a look at this how to

Back


UQ13: How can I experiment with VM image capture on a cloud?

UA13: Assuming that your cloud supports the "capture" operation from within CBTOOL - the support is clearly specified in the supported clouds list - 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.

Back


UQ14: 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?

UA14: 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 VM_DEFAULTS. If you want to change these, just add the following entry to your private configuration file:

[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.

IMPORTANT : keep in mind that this parameter can be changed in any of the 3 ways discussed here and here (i.e., by changing the private configuration file, by issuing the CLI/API cldalter vm_defaults <parameter> <value> or by dynamically overriding the parameters during an vmattach or aiattach CLI/API call).

Back


UQ15: How can I control the operation (e.g., vmattach) parallelism in CBTOOL?

UA15: 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 (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 : keep in mind that this parameter can be changed in any of the 3 ways discussed here and here (i.e., by changing the private configuration file, by issuing the CLI/API cldalter vm_defaults <parameter> <value> or by dynamically overriding the parameters during an vmattach or aiattach CLI/API call).

Back


UQ15: How can I debug vmattach errors in the post-instance start phase?

UA15: Debug instructions

Back


UQ16: How can I debug aiattach errors in the post-instance start phase?

UA16: Debug instructions

Back


UQ17: How can I debug "application load" (i.e., load manager) errors in the post-instance start phase?

UA17: Debug instructions

Back


UQ18: What are the attributes IMAGE_PREFIX and IMAGE_SUFFIX?

UA18: TBD

Back


UQ19: Can CBTOOL execute generic action before/during/after deploying VMs or VApps ?

UA19: TBD

Back


UQ20: How can I experiment with "fault injection" on a cloud?

UA20: TBD

Back

Clone this wiki locally