-
Notifications
You must be signed in to change notification settings - Fork 0
FAQ U
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.
UQ2: 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?
UA2: Yes. Just deploy one or more instances of the Virtual Application (VApp) called NullWorkload. On the CLI, type aiattach nullworkload
UQ3: How can I quickly check the number of VMs failed/deployed?
UA3: Just use the stats command, and look for the counters under the "------------------ EXPERIMENT-WIDE COUNTERS ------------------" section.
UQ4: 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"?
UA4: This can be accomplished in three ways:
- Just re-define the VM role attributes directly on your private [private configuration file] (https://github.com/maugustosilva/cbtool/wiki/FAQ-S#wiki-sq2), 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
- Just use the
typealtercommand 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.
- 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=appuserwill override whatever is defined on the here or what was defined through thetypealtercommand.
UQ5: Can I extract collected performance data directly from the Metric Store?
UA5: Yes. Take a look at this how to
UQ6: How can I experiment with VM image capture on a cloud?
UA6: Assuming that your cloud supports the "capture" operation from within CBTOOL - the support is clearly specified in the [supported clouds list] (https://github.com/maugustosilva/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.
UQ7: 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?
UA7: 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] (https://github.com/maugustosilva/cbtool/wiki/FAQ-S#wiki-sq2):
[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] (https://github.com/maugustosilva/cbtool/wiki/FAQ-S#wiki-sq2).
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] (https://github.com/maugustosilva/cbtool/wiki/FAQ-S#wiki-sq2), by issuing the CLI/API cldalter vm_defaults <parameter> <value> or by dynamically overriding the parameters during an vmattach or aiattach CLI/API call).
UQ8: How can I control the operation (e.g., vmattach) parallelism in CBTOOL?
UA8: 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/maugustosilva/cbtool/wiki/FAQ-S#wiki-sq2) (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.
UQ9: How can I debug vmattach errors in the post-instance start phase?
UA9: Debug instructions