IBM SmartCloud Orchestrator

Version 2.3
User's Guide

IBM SmartCloud Orchestrator

Version 2.3
User's Guide

Note
Before using this information and the product it supports, read the information in Notices on page 1127.
Edition notice
This edition applies to IBM SmartCloud Orchestrator Version 2 Release 3 Fix Pack 1 (program number 5725-H28),
available as a licensed program product, and to all subsequent releases and modifications until otherwise indicated
in new editions.
The material in this document is an excerpt from the IBM SmartCloud Orchestrator 2.3 information center and is
provided for convenience. This document should be used in conjunction with the information center.
Copyright IBM Corporation 2013, 2014.
US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
Tables. . . . . . . . . . . . . . . xiii
Preface . . . . . . . . . . . . . . xv
Who should read this information. . . . . . . xv
Chapter 1. Overview . . . . . . . . . 1
What is new in this release . . . . . . . . . 1
Product architecture . . . . . . . . . . . . 2
Product features . . . . . . . . . . . . . 5
Custom extensions . . . . . . . . . . . . 7
Overview of OpenStack. . . . . . . . . . . 8
Chapter 2. Installing . . . . . . . . . 9
Planning your installation . . . . . . . . . . 9
Installation overview . . . . . . . . . . 9
Installation scenarios . . . . . . . . . . 10
Manage vCenter scenario . . . . . . . . 11
Manage VMControl scenario . . . . . . 12
Scale-out KVM scenario . . . . . . . . 12
SmartCloud Orchestrator Enterprise
installation . . . . . . . . . . . . 12
Hardware prerequisites . . . . . . . . . 13
Software prerequisites . . . . . . . . . . 15
Supported operating systems . . . . . . . 16
Preparing the central server and the region server 17
Preparing the installation media . . . . . . . 21
Preparing the installation based on electronic
download packages. . . . . . . . . . . 21
Preparing the installation based on DVD images 22
Installing the central server . . . . . . . . . 23
Installing the region server . . . . . . . . . 26
List of the RPM packages added during installation 30
Installing a compute node . . . . . . . . . 44
Installing a KVM compute node by PXE. . . . 44
Installing a KVM compute node by script . . . 45
Installing a multiple-region environment . . . . 47
Verifying the installation . . . . . . . . . . 47
Performing advanced configuration tasks . . . . 49
Setting up virtual machines to install Central
Server and Region Server. . . . . . . . . 49
Managing networks . . . . . . . . . . 54
Creating a network for a KVM region . . . 54
Creating a VLAN-based network . . . . 54
Creating a flat network . . . . . . . 57
Creating a network for a VMware or Power
region . . . . . . . . . . . . . . 59
Configuring DNS for the Workload Deployer
IP groups . . . . . . . . . . . . . 61
Deleting the existing networks . . . . . . 62
Shutting down or starting Central Servers and
Region Servers . . . . . . . . . . . . 62
Integrating SmartCloud Orchestrator with
VMware vCenter . . . . . . . . . . . 63
Integrating SmartCloud Orchestrator with
VMControl . . . . . . . . . . . . . 66
Setting NTP servers . . . . . . . . . . 71
Configuring Memcached cache size . . . . . 72
Configuring Virtual Image Library proxies . . . 72
Removing a Compute Node . . . . . . . . 74
Removing a region . . . . . . . . . . . 75
Configuring LDAP authentication . . . . . . 77
Configuring LDAP authentication
independently of the domain . . . . . . 77
Configuring LDAP authentication on a
domain-by-domain basis . . . . . . . . 80
Using external Directory Integration tools with
LDAP authentication . . . . . . . . . 81
LDAP Keystone configuration file reference . 82
Modifying project quotas . . . . . . . . . 86
Preparing to install additional Enterprise
components . . . . . . . . . . . . . 87
Quick start guide for metering and billing . . 87
Confirming the creation of offerings and
categories . . . . . . . . . . . . . . 88
Changing the language settings for the vSys
offerings and categories . . . . . . . . 89
Changing the various passwords . . . . . . 89
Replacing the existing certificates . . . . . . 97
Archiving historical data . . . . . . . . 100
Content Pack installation . . . . . . . . . 101
Upgrading to Fix Pack 1. . . . . . . . . . 101
Upgrading from SmartCloud Provisioning 2.3 . . 103
High Availability . . . . . . . . . . . . 104
Using vSphere HA clusters . . . . . . . . 105
Configuring vSphere DRS . . . . . . . 106
Using System Automation Application Manager 107
Installing System Automation Application
Manager . . . . . . . . . . . . . 107
Starting System Automation Application
Manager . . . . . . . . . . . . . 108
Planning for System Automation Application
Manager configuration . . . . . . . . 109
Modifying the sample configuration files . . 110
Configuring System Automation Application
Manager . . . . . . . . . . . . . 117
(Optional) Post configuring System
Automation Application Manager with
SmartCloud Orchestrator . . . . . . . 121
Controlling the management stack . . . . 124
Troubleshooting System Automation
Application Manager . . . . . . . . . 125
Ports used by SmartCloud Orchestrator . . . . 126
Chapter 3. Getting started . . . . . . 131
Chapter 4. Administering . . . . . . 135
Starting or stopping SmartCloud Orchestrator . . 135
Accessing SmartCloud Orchestrator user interfaces 135
Managing the services . . . . . . . . . . 137
Managing services with SCOrchestrator.py . . 137
Copyright IBM Corp. 2013, 2014 iii
Running the SCOrchestrator.py script . . . 138
Running the SCOrchestrator.py script with
non-root user . . . . . . . . . . . 138
Example SCOComponents.xml . . . . . . 140
Example SCOEnvironment.xml . . . . . . 141
Backing up and restoring the services . . . . 141
Managing settings . . . . . . . . . . . . 142
Managing email delivery . . . . . . . . 142
Configuring email delivery with the user
interface . . . . . . . . . . . . . 143
Virtual Image Library configuration files . . . 143
Configuring the scalable web infrastructure
server . . . . . . . . . . . . . . . 145
Configuring session timeout value . . . . . 146
Configuring timeout value for Ajax calls . . . 146
Configuring OpenStack synchronization . . . 146
Configuring OpenStack connection . . . . . 148
Configuring OpenStack to support thin
provisioning. . . . . . . . . . . . . 149
Configuring memory and CPU overcommitment 149
Managing users, projects, and domains. . . . . 149
User roles in SmartCloud Orchestrator . . . . 151
Managing users . . . . . . . . . . . 153
Managing projects . . . . . . . . . . . 155
Managing domains . . . . . . . . . . 158
Using the Public Cloud Gateway . . . . . . . 159
Public Cloud Gateway overview . . . . . . 160
Capabilities and limitations. . . . . . . 160
Managing Amazon EC2 using the Public Cloud
Gateway . . . . . . . . . . . . . . 161
Prerequisites. . . . . . . . . . . . 161
Configuring the Public Cloud Gateway. . . 162
Managing non-IBM supplied OpenStack using
the Public Cloud Gateway . . . . . . . . 168
Prerequisites. . . . . . . . . . . . 168
Configure the Public Cloud Gateway to
manage non-IBM supplied OpenStack . . . 169
Configure the Public Cloud Gateway
regions for non-IBM supplied OpenStack . 170
Configure non-IBM supplied OpenStack
flavors. . . . . . . . . . . . . 171
Configure non-IBM supplied OpenStack
EC2 credentials . . . . . . . . . . 172
Configure IaaS Gateway and restart the
Public Cloud Gateway . . . . . . . 174
Post configuration tasks . . . . . . . . 175
Create a supported image . . . . . . 175
Troubleshooting . . . . . . . . . . . 176
Loss of functionality in Public Cloud
Gateway cloud groups . . . . . . . . 177
Loss of functionality in Public Cloud
Gateway cloud groups (2) . . . . . . . 178
Region names displayed incorrectly in the
Virtual Image page . . . . . . . . . 178
Unable to connect to a public cloud due to
missing credentials . . . . . . . . . 179
Unable to deploy instance to non-IBM
supplied OpenStack . . . . . . . . . 180
Inconsistencies in deployed instance names 180
MAC address field is empty . . . . . . 180
Reference. . . . . . . . . . . . . . 181
Key pairs. . . . . . . . . . . . . 181
Command-line interface scripts . . . . . 181
Password authentication on Amazon EC2
images . . . . . . . . . . . . . 181
Configuring the Public Cloud Gateway
regions to use a proxy server . . . . . . 182
Building the cloud with topology resources . . . 183
Managing cloud resources . . . . . . . . 183
Administering cloud groups . . . . . . 184
Managing availability zones in OpenStack 185
Fields on the Cloud Groups window . . 186
Administering hypervisors . . . . . . . 187
vCenter management . . . . . . . . 188
Restricting access to vCenter . . . . . 190
VMware administrative user minimum
rights . . . . . . . . . . . . . 190
Fields on the Hypervisors window . . . 191
Administering virtual machines . . . . 194
Administering networks. . . . . . . 203
Administering storage . . . . . . . 206
Hypervisor states . . . . . . . . . 207
Administering IP groups and IP addresses 208
IP groups. . . . . . . . . . . . 209
Administering IP groups and IP addresses
with the user interface . . . . . . . 210
Managing environment profiles . . . . . . 220
Environment profiles overview . . . . . 221
Managing environment profiles in the user
interface . . . . . . . . . . . . . 222
Creating an environment profile . . . . 223
Cloning an environment profile . . . . 227
Editing an environment profile . . . . 228
Environment Profiles window fields . . . 230
Populating the catalog . . . . . . . . . . 233
Managing script packages . . . . . . . . 234
Script packages overview . . . . . . . 235
Example script package to install an
application . . . . . . . . . . . 236
Example script to configure the trace
levels . . . . . . . . . . . . . 238
Example script package to create a server 239
Example script package to create a
WebSphere Application Server cluster . . 240
Using script packages with the user interface 242
Adding a script package. . . . . . . 243
Cloning a script package . . . . . . 245
Making script packages read-only . . . 246
Associating a script package with a
pattern . . . . . . . . . . . . 247
Deleting a script package . . . . . . 248
Windows sample to check if a file already
exists . . . . . . . . . . . . . 249
Configuring a script package using a JSON
object . . . . . . . . . . . . . . 250
Script package environment variables . . . 251
Properties variable syntax . . . . . . . 253
Managing add-ons . . . . . . . . . . 254
Add-ons in the catalog . . . . . . . . 255
Managing add-ons with the user interface 257
Adding add-ons to the catalog . . . . 258
Cloning an add-on . . . . . . . . 259
iv IBM SmartCloud Orchestrator 2.3: User's Guide
Editing an add-on . . . . . . . . . 261
Making add-ons read-only . . . . . . 262
Associating an add-on with a pattern . . 263
Deleting an add-on . . . . . . . . 264
Fields on the Add-Ons user interface . . 265
Managing key pairs . . . . . . . . . . . 268
Monitoring the task queue . . . . . . . . . 269
Auditing . . . . . . . . . . . . . . . 270
Audit events . . . . . . . . . . . . 271
Audit event record attributes and usage tips . . 272
Download options for audit event records . . . 277
Retrieving audit data with the user interface 278
Retrieving audit data with the REST API . . 279
Monitoring the status of audit data storage . . 283
Deleting audit data to free storage . . . . . 284
Chapter 5. Managing virtual images 287
Managing virtual images with the user interface 288
Importing a virtual image to the catalog . . . 289
Registering a virtual image . . . . . . . . 290
Removing a virtual image from the catalog . . 291
Virtual image fields on the user interface . . . 292
Adding images to OpenStack . . . . . . . . 294
Working with Virtual Image Library. . . . . . 295
Overview. . . . . . . . . . . . . . 295
Virtual Image Library basics . . . . . . 296
Installing and configuring . . . . . . . . 299
Installing . . . . . . . . . . . . . 299
Installing the proxy component . . . . 301
Configuring . . . . . . . . . . . . 303
Configuring Virtual Image Library server
and remote proxy components . . . . 303
Configuring Virtual Image Library proxies
with slow connectivity . . . . . . . 304
Configuring Virtual Image Library for
VMware . . . . . . . . . . . . 305
Uninstalling . . . . . . . . . . . . 306
Uninstalling Virtual Image Library . . . 306
Uninstalling the distributed proxy . . . 307
Best practices . . . . . . . . . . . 307
Managing reference images. . . . . . 307
Managing the remote proxy . . . . . 309
Changing the WebSphere account
password. . . . . . . . . . . . 310
Backing up and restoring the proxy . . . 310
Getting started . . . . . . . . . . . . 311
User roles and requirements . . . . . . 312
Assigning a role to a user . . . . . . 313
Adding an operational repository . . . . 314
Changing server access credentials . . . 316
Removing an operational repository . . . 316
Indexing an image. . . . . . . . . . 317
Enabling the Keystone user registry . . . . 318
Managing Virtual Image Library . . . . . . 318
Managing the resource access control list . . 319
Copying an image to the reference repository 320
Importing an image . . . . . . . . . 321
Copying an image from the reference
repository . . . . . . . . . . . . 322
Removing an image from the reference
repository . . . . . . . . . . . . 323
Tracking image version and provenance . . 323
Moving an image to a different version
chain . . . . . . . . . . . . . 325
Searching for images . . . . . . . . . 326
Comparing images . . . . . . . . . 326
Finding similar images . . . . . . . . 327
Synchronizing repositories . . . . . . . 328
Using the plug-in for vSphere Client . . . . 328
Troubleshooting . . . . . . . . . . . 330
Log files . . . . . . . . . . . . . 330
Changing the time zone . . . . . . . . 332
Known problems and limitations . . . . . 333
Limitations . . . . . . . . . . . 333
Cannot check in a deployed virtual
machine . . . . . . . . . . . . 334
Cannot connect to the HBase database . . 334
NoClassDefFoundError exception . . . 334
rbagent component does not start . . . 335
Error 404 - Too many open files . . . . 335
Cannot create HBase tables . . . . . . 336
Disk space lower than the safe threshold
value . . . . . . . . . . . . . 336
Configuring WebSphere Application
Server . . . . . . . . . . . . . 337
Modifying the default check out settings 337
Image checkout fails . . . . . . . . 338
Domain status is out of sync . . . . . 338
New region, new repository, or new
image does not appear . . . . . . . 339
Virtual Image Library fails with message
java.lang.NoClassDefFoundError . . . . 339
After moving a Linux image, you have
problems starting the image . . . . . 339
REST API reference . . . . . . . . . . 340
ImageManager API reference . . . . . . 341
Administration REST API . . . . . . 341
Analytics REST API . . . . . . . . 343
Connector REST API . . . . . . . . 350
Domain REST API. . . . . . . . . 358
Image log REST API . . . . . . . . 361
Location REST API . . . . . . . . 362
Operational repository REST API . . . . 364
Operational images REST API . . . . . 365
Users REST API . . . . . . . . . 381
Version chain REST API . . . . . . . 381
IaaS API reference . . . . . . . . . . 385
Glance API . . . . . . . . . . . 385
OVF metadata REST API . . . . . . 386
Working with IBM Image Construction and
Composition Tool . . . . . . . . . . . . 387
Installing, upgrading, and uninstalling Image
Construction and Composition Tool . . . . . 389
Installing IBM Image Construction and
Composition Tool on Linux. . . . . . . 390
Upgrading the Image Construction and
Composition Tool . . . . . . . . . . 393
Upgrading from a previous version . . . 393
Upgrading silently from a previous
version . . . . . . . . . . . . 394
Uninstalling the product. . . . . . . . 395
Uninstalling a fix pack . . . . . . . 395
Contents v
Uninstalling the Image Construction and
Composition Tool . . . . . . . . . 395
Uninstalling the Image Construction and
Composition Tool silently . . . . . . 396
Getting started . . . . . . . . . . . . 396
The basics . . . . . . . . . . . . 396
Universal identifiers . . . . . . . . . 397
System requirements . . . . . . . . . 398
Changing your user password. . . . . . 398
Managing the Image Construction and
Composition Tool server. . . . . . . . 399
Managing the firewall . . . . . . . . 399
Configuring cloud providers . . . . . . 399
Configuring the OpenStack cloud provider 400
Working with virtual images . . . . . . . 400
Importing base images from OpenStack . . 401
Building virtual images . . . . . . . . 401
Extending virtual images . . . . . . 403
Adding software bundles to virtual
images . . . . . . . . . . . . 403
Adding licenses to virtual images . . . 405
Adding personalities to virtual images 405
Synchronizing virtual images . . . . . 407
Capturing virtual images . . . . . . 409
Creating virtual images from a template 409
Managing software bundles . . . . . . 410
Preparing to create software bundles . . 411
Creating software bundles . . . . . . 412
Searching for bundles . . . . . . . 417
Extending software bundles . . . . . 417
Uploading large files when creating
software bundles . . . . . . . . . 418
Sharing software bundles . . . . . . 418
Using the command-line interface . . . . . 419
Command-line interface high-level procedure 420
Command-line interface overview . . . . 421
Downloading and configuring the
command-line interface . . . . . . . . 422
Invoking the command-line interface . . . 423
Invoking in interactive mode . . . . . 425
Invoking in batch mode . . . . . . . 426
Command-line interface resource object
reference . . . . . . . . . . . . . 428
Bundles reference . . . . . . . . . 428
Cloud providers reference . . . . . . 449
Images reference . . . . . . . . . 452
Users reference . . . . . . . . . . 461
Problem determination reference for the
command-line interface . . . . . . . 463
Getting help on the command-line interface 465
Troubleshooting issues with Image Construction
and Composition Tool . . . . . . . . . 466
Log files for troubleshooting . . . . . . 466
Setting logging levels for troubleshooting . . 467
Adjusting the configuration timeout settings 468
Log files for virtual image synchronization 469
Troubleshooting problems during VM
activation. . . . . . . . . . . . . 470
Working with enablement bundles . . . . 471
Updating Activation Engine in a virtual
image . . . . . . . . . . . . . . 472
Image Construction and Composition Tool
does not respond . . . . . . . . . . 473
Image Construction and Composition Tool
does not start after installation . . . . 473
Image Construction and Composition Tool
returns EOFException . . . . . . . 474
Install executable launcher error during
installation . . . . . . . . . . . . 474
Exec error 1 during installation . . . . . 475
Universal ID and version must be unique 475
Cancel - use the current file link does not
work . . . . . . . . . . . . . . 475
Failure during OVA disk conversion. . . . 476
Import or export of the OVA file fails . . . 476
Error occurs during OVA export . . . . . 476
Virtual image capture fails . . . . . . . 477
Extending an image fails . . . . . . . 477
Virtual images that contain old versions of
the activation engine cannot be deployed . . 479
Files are not replaced correctly . . . . . 479
The user interface stops responding while
uploading files . . . . . . . . . . . 479
Limitation when performing concurrent
updates . . . . . . . . . . . . . 480
Cannot remove software bundles from a
personality . . . . . . . . . . . . 480
Bundles are not displayed in the list of
compatible images. . . . . . . . . . 480
Limitation when adding bundles to a
personality . . . . . . . . . . . . 480
Limitation when deleting images that are
synchronizing . . . . . . . . . . . 481
Time lag when deleting virtual images . . . 481
Virtual image synchronization takes a long
time . . . . . . . . . . . . . . 481
Virtual image synchronization fails after five
hours for images . . . . . . . . . . 482
SSL exception . . . . . . . . . . . 483
Cannot pass characters for arguments on the
command line . . . . . . . . . . . 483
Deploying a pattern with parts created by
Image Construction and Composition Tool
might not work . . . . . . . . . . 483
Import fails using OpenStack cloud provider 484
New password is not set after upgrade or
reinstallation . . . . . . . . . . . 484
Virtual image synchronization problems . . 484
Synchronization fails for a virtual image
imported from a running virtual machine . 484
Virtual image synchronization fails
because of return code value . . . . . 485
Virtual image synchronization fails and
troubleshooting is not possible . . . . 487
Windows image synchronization fails . . 487
Synchronization fails on a Linux operating
system . . . . . . . . . . . . 488
Image management . . . . . . . . . . . 488
Creating new images or using existing images 488
Creating new AIX or Linux images or using
existing ones . . . . . . . . . . . 488
Prerequisites for KVM or VMware images 488
vi IBM SmartCloud Orchestrator 2.3: User's Guide
Creating new images or using existing
images on KVM . . . . . . . . . 490
Creating new images or using existing
images on VMware . . . . . . . . 492
Creating new images or using existing
images on VMControl . . . . . . . 492
Creating new Windows images or using
existing ones . . . . . . . . . . . 494
Prerequisites for KVM or VMware images 494
Creating new images or using existing
images on KVM . . . . . . . . . 497
Creating new images or using existing
images on VMware . . . . . . . . 498
Importing images . . . . . . . . . . . 498
Registering images . . . . . . . . . . 500
Deploying images . . . . . . . . . . . 501
Deploying an image through a pattern in
OpenStack . . . . . . . . . . . . 501
Deploying an image through a pattern in
vCenter or VMControl . . . . . . . . 503
Extending images . . . . . . . . . . . 505
Extending images in OpenStack . . . . . 505
Extending images in vCenter . . . . . . 507
Image management on Power . . . . . . . 509
Chapter 6. Managing and deploying
virtual patterns. . . . . . . . . . . 511
Virtual pattern types . . . . . . . . . . . 511
Working with virtual system patterns . . . . . 511
Supported virtual system patterns . . . . . 512
Working with virtual system patterns in the
user interface . . . . . . . . . . . . 513
Selecting a virtual system pattern. . . . . 514
Using a predefined virtual system pattern 516
Cloning an existing virtual system pattern 517
Creating a virtual system pattern. . . . 519
Editing a virtual system pattern . . . . . 521
Virtual system pattern editing views and
parts . . . . . . . . . . . . . 522
Ordering parts to run at deployment . . 526
Configuring parts . . . . . . . . . . 527
Configuring advanced options. . . . . . 529
Configuring advanced options for cluster
virtual system patterns . . . . . . . 532
Configuring advanced options for
Intelligent Management Pack . . . . . 536
Configuring advanced messaging for
databases. . . . . . . . . . . . 541
Configuring advanced options for single
server virtual system patterns . . . . . 543
Configuring database implemented
session persistence for Derby . . . . . 545
Making virtual system patterns read-only 546
Deploying a virtual system pattern . . . . 547
Deploying a pattern with additional
actions . . . . . . . . . . . . 551
Deleting a virtual system pattern . . . . . 551
Virtual system pattern windows . . . . . 552
Fields on the Virtual System Patterns
window . . . . . . . . . . . . 554
Fields on the Pattern Editor window . . 556
Virtual system pattern processing . . . . . 559
Creating new flavors in OpenStack . . . . . 560
Customizing flavors for Power features. . . . 561
Managing virtual system instances . . . . . 562
Managing virtual system instances with the
user interface . . . . . . . . . . . 563
Starting a persistent virtual system
instance . . . . . . . . . . . . 565
Stopping a persistent virtual system
instance . . . . . . . . . . . . 566
Removing a virtual system instance . . . 567
Creating a snapshot image . . . . . . 569
Restoring virtual system instances from a
snapshot image. . . . . . . . . . 570
Deleting snapshot images . . . . . . 571
Virtual Systems fields on the user
interface . . . . . . . . . . . . 572
Accessing virtual machines in your virtual
system instance. . . . . . . . . . 573
Expanding disk on deployed virtual
machines . . . . . . . . . . . . 574
Viewing the details for your virtual
machines . . . . . . . . . . . . 575
Working with virtual applications . . . . . . 581
Virtual application pattern components. . . . 583
Managing pattern types . . . . . . . . . 585
Viewing pattern types . . . . . . . . 586
Viewing the plug-ins in the pattern types . . 587
Importing pattern types . . . . . . . . 587
Removing a pattern type . . . . . . . 588
Upgrading pattern types . . . . . . . 588
Upgrading a deployed pattern type . . . . 589
Pattern type packaging reference . . . . . 590
Managing virtual applications . . . . . . . 591
Creating virtual application patterns. . . . 592
Editing virtual application patterns . . . . 593
Cloning virtual application patterns . . . . 594
Deleting virtual application patterns. . . . 595
Creating virtual application layers . . . . 595
Editing virtual application layers . . . . . 596
Deleting virtual application pattern layers 597
Importing virtual application pattern layers 598
Working with reusable application
components . . . . . . . . . . . . 598
Working with virtual application templates 599
Creating a virtual application template 600
Creating virtual applications from
templates. . . . . . . . . . . . 601
Cloning a virtual application template . . 602
Editing virtual application templates . . 603
Importing a virtual application template 603
Exporting a virtual application template 604
Removing a virtual application template 604
Working with virtual application pattern
plug-ins . . . . . . . . . . . . . . 605
Managing system plug-ins . . . . . . . 606
Plug-ins shipped with pattern types . . . 606
Adding system plug-ins to the catalog . . 607
Deleting plug-ins from the catalog . . . 607
Virtual application pattern components. . . 607
Application components. . . . . . . 609
Contents vii
Database components . . . . . . . 623
User Registry components . . . . . . 633
Messaging components . . . . . . . 643
OSGi components . . . . . . . . . 648
Transaction processing components . . . 653
Other components. . . . . . . . . 658
Policies . . . . . . . . . . . . 660
Developing plug-ins . . . . . . . . . 666
Plug-in Development Kit . . . . . . 671
Plug-in development guide. . . . . . 676
Samples . . . . . . . . . . . . 723
Deploying virtual applications. . . . . . . 735
Deploying virtual application patterns . . . 736
Terminating virtual machines and
reclaiming IP addresses . . . . . . . 740
Deploying virtual application templates . . 741
Securing virtual applications . . . . . . 744
Securing virtual application instances with
SSL. . . . . . . . . . . . . . 744
Configuring SSH key-based access during
application deployment . . . . . . . 746
Configuring SSH key-based access in the
user interface . . . . . . . . . . 747
LTPA keys . . . . . . . . . . . 748
Working with virtual application instances . . 749
Monitoring virtual application instances . . 751
Viewing virtual application instance logs 752
Using the command-line interface for
applications . . . . . . . . . . . . . 753
Working with shared services . . . . . . . . 754
Deploying shared services . . . . . . . . 754
Monitoring shared services . . . . . . . . 755
Deploying a monitoring shared service . . . 756
Enabling TOSCA support for SmartCloud
Orchestrator . . . . . . . . . . . . . . 757
Configuring the RPM repository for the
deployment of TOSCA patterns . . . . . . 757
Configuring an RPM repository of type ISO
Image on NFS . . . . . . . . . . . 758
Configuring an RPM repository of type FTP 759
Configuring an RPM repository of type
HTTP . . . . . . . . . . . . . . 759
Disabling the configuration of an RPM
repository . . . . . . . . . . . . 760
Configuring Chef support for TOSCA based
virtual application patterns . . . . . . . . 760
Chapter 7. Managing orchestration
workflows . . . . . . . . . . . . . 763
Orchestration workflows . . . . . . . . . 763
Self-service offerings . . . . . . . . . . 764
User actions . . . . . . . . . . . . . 764
Event-triggered actions . . . . . . . . . 765
Samples and standard extensions for orchestration
workflows . . . . . . . . . . . . . . 765
Working with Business Process Manager . . . . 766
Setting up IBM Process Designer . . . . . . 766
Adding users to IBM Process Designer . . . 767
Creating a process application in Process
Designer . . . . . . . . . . . . . . 767
Reusing processes and human services in a
process application . . . . . . . . . 769
Editing process applications and toolkits . . 769
Creating a process . . . . . . . . . . . 769
User input required at service request time 771
Making a new process available as a self-service
offering . . . . . . . . . . . . . . 771
Making a process available as an orchestration
action . . . . . . . . . . . . . . . 772
Upgrading a process on a development system
or production system. . . . . . . . . . 773
Configuring development mode . . . . . 774
Configuring production mode . . . . . . 774
Guidelines for working with Business Process
Manager . . . . . . . . . . . . . . 775
Guidelines for naming and documenting
your toolkit or process application . . . . 775
Guidelines for creating artifacts in a toolkit 776
Guidelines to structure your solution . . . 777
Guidelines for handling errors. . . . . . 777
Chapter 8. Working with self-service 779
Managing self-service offerings . . . . . . . 779
Adding offerings . . . . . . . . . . . 779
Categorizing self-service offerings . . . . . 779
Modifying self-service offerings . . . . . . 780
Using self-service . . . . . . . . . . . . 780
Navigating the Self-Service panel . . . . . . 780
Submitting a self-service request . . . . . . 781
Viewing the status of your requests . . . . . 781
Completing an assignment in My Inbox . . . 782
Chapter 9. Integrating . . . . . . . . 783
Integrating with IBM Tivoli Monitoring . . . . 783
Preparing a base operating system . . . . . 783
Database setup . . . . . . . . . . . . 784
Installing IBM Tivoli Monitoring . . . . . . 784
Packages used for installation . . . . . . 785
Creating a warehouse database . . . . . . 786
Monitoring Agent for Linux . . . . . . . 787
Monitoring Agent for Kernel-based virtual
machines . . . . . . . . . . . . . . 787
OpenStack hypervisors . . . . . . . . . 788
Installing Image Construction and Composition
Tool bundle to deploy Tivoli Monitoring agents . 788
Integrating with IBM Endpoint Manager . . . . 790
Installing Endpoint Manager agent to existing
computers . . . . . . . . . . . . . 790
Installing Endpoint Manager agents during
virtual machine deployment . . . . . . . 790
Chapter 10. Reporting. . . . . . . . 799
Machine activity reporting . . . . . . . . . 800
User activity reporting . . . . . . . . . . 801
Tivoli Common Reporting . . . . . . . . . 802
Installing Jazz for Service Management and Tivoli
Common Reporting . . . . . . . . . . . 802
Installing Jazz for Service Management in the
silent mode . . . . . . . . . . . . . 803
viii IBM SmartCloud Orchestrator 2.3: User's Guide
Installing Tivoli Common Reporting in the silent
mode . . . . . . . . . . . . . . . 804
Chapter 11. Reference. . . . . . . . 805
Using the command-line interface . . . . . . 805
Command-line interface overview . . . . . 806
Core functions . . . . . . . . . . . . 807
Command-line interface resource object
reference . . . . . . . . . . . . . . 808
AddOn command-line interface reference . . 810
Audit logging command-line interface
reference . . . . . . . . . . . . . 813
Cloud group command-line interface
reference . . . . . . . . . . . . . 815
Domain Name System (DNS) server
command-line interface reference. . . . . 817
Environment profiles command-line interface
reference . . . . . . . . . . . . . 819
Environment profiles on the
command-line interface . . . . . . . 820
Environment profile clouds on the
command-line interface . . . . . . . 824
Environment profile cloud IP groups on
the command-line interface. . . . . . 827
Hypervisor command-line interface reference 830
Image command-line interface reference . . 833
IP command-line interface reference . . . . 834
IP group command-line interface reference 838
Mail delivery command-line interface
reference . . . . . . . . . . . . . 841
Maintenance command-line interface
reference . . . . . . . . . . . . . 841
Network command-line interface reference 843
Pattern command-line interface reference . . 844
Importing and exporting virtual system
patterns . . . . . . . . . . . . 846
Patterns on the command-line interface 848
Pattern parts on the command-line
interface . . . . . . . . . . . . 855
Pattern scripts on the command-line
interface . . . . . . . . . . . . 861
Parts on the command-line interface. . . 867
Pattern type command-line interface . . . 870
Plug-in command-line interface reference . . 872
Problem determination command-line
interface reference . . . . . . . . . . 874
Script package command-line interface
reference . . . . . . . . . . . . . 876
Snapshots on the command-line interface . . 880
Storage command-line interface reference . . 882
Virtual application instance command-line
interface reference . . . . . . . . . . 883
Virtual application pattern command-line
interface reference . . . . . . . . . . 886
Virtual images command-line interface
reference . . . . . . . . . . . . . 893
Virtual machines on the command-line
interface . . . . . . . . . . . . . 899
Virtual system instances command-line
interface reference . . . . . . . . . . 902
Downloading and configuring the
command-line interface . . . . . . . . . 909
Invoking the command-line interface . . . . 911
Using the command-line interface for
applications . . . . . . . . . . . . . 913
Getting help on the command-line interface . . 913
Resources, resource collections, and methods 914
Resources on the command line . . . . . 916
Resource collections on the command line 920
Resource methods on the command-line
interface . . . . . . . . . . . . . 921
Resource collections methods on the
command-line interface . . . . . . . . 927
Wizard objects on the command-line interface 933
ACL object . . . . . . . . . . . . 935
Additional command-line interface utilities . . 938
REST API reference . . . . . . . . . . . 940
REST API frameworks . . . . . . . . . 941
Application patterns REST API . . . . . . 942
Auditing REST API . . . . . . . . . . 950
Certificates REST API . . . . . . . . . 952
Cloud groups REST API . . . . . . . . . 954
diagnostics.zip file REST API . . . . . . 961
Environment profiles REST API . . . . . . 962
Hypervisors REST API . . . . . . . . . 966
IP addresses REST API . . . . . . . . . 973
IP groups REST API . . . . . . . . . . 977
Log viewer manager REST API . . . . . . 983
Logging REST API . . . . . . . . . . 985
Monitoring REST API . . . . . . . . . 987
Networks REST API . . . . . . . . . . 991
Pattern types REST API . . . . . . . . . 994
Patterns REST API. . . . . . . . . . . 997
Plug-ins REST API . . . . . . . . . . 1002
Shared services REST API . . . . . . . . 1004
Storage REST API . . . . . . . . . . 1006
Version REST API . . . . . . . . . . 1009
Virtual appliance instances REST API . . . . 1010
Virtual applications REST API . . . . . . 1014
Virtual images REST API . . . . . . . . 1019
Virtual machines REST API . . . . . . . 1025
Virtual system instances REST API . . . . . 1030
OpenStack and IaaS REST API . . . . . . 1040
Using REST APIs to manage users, projects,
roles, and domains . . . . . . . . . 1041
Orchestration actions REST API . . . . . . 1043
List all orchestration action entries . . . . 1043
Retrieve an orchestration action entry . . . 1044
Add or update an entry in the orchestration
actions . . . . . . . . . . . . . 1045
Delete an orchestration action entry . . . 1046
Get entries for a specific virtual system 1046
Business Process Manager Invoker REST API 1047
Retrieve available BPM Business Processes 1047
List all BPM Business Processes . . . . 1047
Get entries for a specific BPM Business
Process . . . . . . . . . . . . 1048
Retrieve available human services . . . . 1048
List all human services . . . . . . . 1048
Get entries for a specific human service 1049
Retrieve My Inbox . . . . . . . . . 1050
Contents ix
List all My Inbox items. . . . . . . 1050
Get entries for a specific My Inbox item 1052
Service instance REST API. . . . . . . . 1053
Get entries for a specific service instance 1054
Metadata parameters REST APIs . . . . . 1057
Get parameters of specific metadata . . . 1057
Post metadata parameters . . . . . . . 1058
Delete parameters of specific metadata . . 1058
Virtual machines parameters REST API . . . 1059
Get parameters of a specific virtual machine 1059
Post virtual machine parameters . . . . 1059
Delete parameters of specific virtual
machines . . . . . . . . . . . . 1060
Task engine REST API . . . . . . . . . 1060
List all currently running and recently
completed tasks . . . . . . . . . . 1060
Get entries for a specific task. . . . . . 1061
Deployment parameters REST API . . . . . 1062
Get deployment parameters for a specific
instance . . . . . . . . . . . . . 1063
Post deployment parameters for a specific
instance . . . . . . . . . . . . . 1064
Self-service offering REST API . . . . . . 1064
List all self-service offerings . . . . . . 1064
Get entries for a specific self-service offering 1066
Delete a specific self-service offering . . . 1068
Update a specific self-service offering . . . 1068
Executing a self-service offering . . . . . 1069
Chapter 12. Troubleshooting . . . . 1077
Finding the log files . . . . . . . . . . . 1077
Problem determination with pdcollect tool . . . 1078
Running the pdcollect tool . . . . . . . 1079
Running the pdcollect tool with non-root user 1080
Example Components.xml . . . . . . . . 1081
Example Environment.xml . . . . . . . . 1083
Example Environment_work.xml . . . . . . 1083
Setting logging levels . . . . . . . . . . 1084
Controlling the size of the IaaS gateway log file 1086
Workload Deployer log files . . . . . . . . 1087
Known errors and limitations . . . . . . . 1088
Product limitations . . . . . . . . . . 1089
Installation errors . . . . . . . . . . 1089
Region Server installation failure with error:
Region already exists. . . . . . . . 1089
Installation fails because the chef-server is
down. . . . . . . . . . . . . . 1089
Installation fails to deploy central servers 1090
Installation fails to deploy central servers (2) 1091
Region Server deployment completes with
network configuration warning . . . . . 1092
Error when upgrading the Region Server 1092
Upgrade Central Server fails while re-run
deploy_central_server.sh . . . . . . 1093
Hypervisor errors and scenarios that can cause
them . . . . . . . . . . . . . . . 1094
Image errors . . . . . . . . . . . . 1096
Instance errors. . . . . . . . . . . . 1100
Deployment errors . . . . . . . . . . 1100
Setting the host name when deploying a
Windows system . . . . . . . . . . 1100
Unable to deploy a virtual system pattern
with a non-admin user . . . . . . . . 1101
Error displayed when deploying a virtual
system pattern. . . . . . . . . . . 1102
Unable to deploy a virtual machine in a
VMware multi-region environment . . . . 1102
Unable to deploy a virtual machine due to
insufficient resources . . . . . . . . 1103
Deployment might hang . . . . . . . 1103
Unable to deploy IBM DB2 Enterprise or
WebSphere MQ OVA image . . . . . . 1104
Unable to deploy WebSphere Application
Server OVA image . . . . . . . . . 1104
Unable to deploy WebSphere Portal 8.0.0.1
pattern . . . . . . . . . . . . . 1105
Unable to deploy IBM InfoSphere
Information Server Enterprise Edition 9.1
pattern . . . . . . . . . . . . . 1106
Unable to deploy IBM Integration Bus
Hypervisor Edition pattern . . . . . . 1106
Unable to deploy or to delete virtual
machines . . . . . . . . . . . . 1107
Deployment of the virtual system pattern
fails due to the name of the virtual machine. 1110
Script execution does not report failing
condition . . . . . . . . . . . . 1111
nova command errors and limitations . . . . 1111
Security limitations . . . . . . . . . . 1112
User interface errors . . . . . . . . . . 1112
Fixing command-line interface errors when
using multi-byte character sets . . . . . . 1113
SmartCloud Entry does not function properly 1114
Command nova-cloud-create fails with an error 1114
Unable to change the flavor of VMware virtual
machines . . . . . . . . . . . . . 1114
Error message displayed after launching a
virtual system . . . . . . . . . . . . 1115
Unable to list keystone endpoints on the
Region Server . . . . . . . . . . . . 1116
Unable to log in by using an LDAP user . . . 1118
Must remove hosts that are not eligible for
cloud . . . . . . . . . . . . . . . 1118
Hotplug is not fully supported . . . . . . 1119
Unable to capture a NIM-based image in
VMControl . . . . . . . . . . . . . 1119
Troubleshooting Workload Deployer . . . . . 1122
Failure to deploy a virtual system or
application when a linked clone is enabled . . 1122
Increasing the default timeout if hypervisor
fails . . . . . . . . . . . . . . . 1122
Troubleshooting virtual applications . . . . . 1122
Setting runtime trace in the Agent process . . 1123
Deployment stops during middleware setup in
VMware. . . . . . . . . . . . . . 1123
Troubleshooting Business Process Manager . . . 1123
Troubleshooting Virtual Image Library . . . . 1124
Troubleshooting Image Construction and
Composition Tool . . . . . . . . . . . 1125
x IBM SmartCloud Orchestrator 2.3: User's Guide
Notices . . . . . . . . . . . . . 1127
Glossary . . . . . . . . . . . . . 1129
A . . . . . . . . . . . . . . . . . 1129
B . . . . . . . . . . . . . . . . . 1130
C . . . . . . . . . . . . . . . . . 1130
E . . . . . . . . . . . . . . . . . 1130
H . . . . . . . . . . . . . . . . . 1130
K . . . . . . . . . . . . . . . . . 1130
O . . . . . . . . . . . . . . . . . 1131
P . . . . . . . . . . . . . . . . . 1131
R . . . . . . . . . . . . . . . . . 1132
S . . . . . . . . . . . . . . . . . 1132
T . . . . . . . . . . . . . . . . . 1132
V . . . . . . . . . . . . . . . . . 1133
Trademarks and service marks . . . 1135
Privacy policy considerations . . . . 1137
Accessibility features for SmartCloud
Orchestrator . . . . . . . . . . . 1139
Contents xi
xii IBM SmartCloud Orchestrator 2.3: User's Guide
Tables
1. Summary of SmartCloud Orchestrator
installation scenarios . . . . . . . . . 10
2. The minimum Manage-from requirements 13
3. KVM Compute Nodes . . . . . . . . . 14
4. VMware Compute Nodes . . . . . . . . 14
5. Power Compute Nodes . . . . . . . . 15
6. Host and guest operating systems supported
by the standard installation . . . . . . . 16
7. Host and guest operating systems supported
by the hypervisors . . . . . . . . . . 16
8. Compulsory attributes . . . . . . . . . 24
9. Compulsory configurations . . . . . . . 27
10. Configuration file options in ldap_pre_auth
section . . . . . . . . . . . . . . 82
11. Configuration file options in auto-population
section . . . . . . . . . . . . . . 85
12. Environment configuration in sample files 109
13. Ports used by SmartCloud Orchestrator 126
14. Object level access definitions . . . . . . 153
15. Ports used by Public Cloud Gateway 161
16. Parameters that are used in the admin.json
file . . . . . . . . . . . . . . . 163
17. Parameters used in the config.json file 164
18. Parameters that are used in the
credentials.json file . . . . . . . . . 165
19. Ports used by Public Cloud Gateway 169
20. Parameters used in the cacheCounter tag
section of the config.json file . . . . . . 178
21. The minimum rights of a VMware
administrative user . . . . . . . . . 190
22. Events that are tracked by audit data 271
23. Universal event record attributes . . . . . 273
24. Attribute name-value pairs . . . . . . . 273
25. Download options for audit data . . . . . 277
26. Overview of sample scripts . . . . . . . 280
27. User roles. . . . . . . . . . . . . 297
28. User roles. . . . . . . . . . . . . 312
29. Creating an image using Image Construction
and Composition Tool . . . . . . . . 388
30. Main Image Construction and Composition
Tool pages . . . . . . . . . . . . 397
31. Specify the software to install on your
instances . . . . . . . . . . . . . 414
32. Incoming connectable components . . . . 609
33. Policy components for enterprise applications 611
34. Incoming connectable components . . . . 611
35. Outgoing connectable components . . . . 612
36. Incoming connectable components . . . . 616
37. Incoming connectable components . . . . 617
38. Policy components for web applications 618
39. Incoming connectable components . . . . 619
40. Outgoing connectable components . . . . 619
41. Incoming connectable components . . . . 625
42. Incoming connectable components . . . . 626
43. Incoming connectable components . . . . 628
44. Incoming connectable components . . . . 630
45. Incoming connectable components . . . . 631
46. Incoming connectable components . . . . 634
47. Incoming connectable components . . . . 637
48. Incoming connectable components . . . . 640
49. Incoming connectable components . . . . 644
50. Incoming connectable components . . . . 645
51. Incoming connectable components . . . . 647
52. Incoming connectable components . . . . 649
53. Incoming connectable components . . . . 650
54. Outgoing connectable components . . . . 650
55. Incoming connectable components . . . . 654
56. Incoming connectable components . . . . 657
57. Incoming connectable components . . . . 659
58. Outgoing connectable components . . . . 661
59. Outgoing connectable components . . . . 662
60. Outgoing connectable components . . . . 663
61. Outgoing connectable components . . . . 664
62. Role state and status . . . . . . . . . 689
63. Logtypes . . . . . . . . . . . . . 709
64. Custom logtypes . . . . . . . . . . 709
65. Monitoring collector types. . . . . . . . 714
66. Monitoring collector types. . . . . . . . 715
67. Monitor types . . . . . . . . . . . 717
68. Chart types . . . . . . . . . . . . 717
69. Possible status values for a deployed virtual
application . . . . . . . . . . . . 738
70. Possible status values for a deployed virtual
application . . . . . . . . . . . . 742
71. Possible status values for a deployed virtual
application . . . . . . . . . . . . 749
72. Editing process applications and toolkits 769
73. List all application patterns.. . . . . . . 942
74. Create an application pattern with specific
attributes details. . . . . . . . . . . 942
75. Create an application pattern from an existing
application or template (clone) details. . . . 943
76. List application pattern with various filters
details. . . . . . . . . . . . . . . 944
77. Update application pattern details. . . . . 945
78. Return detailed information about the
application pattern. . . . . . . . . . 946
79. Download the application pattern zip file,
including all artifacts and the json file details.. 946
80. Update application pattern access right
details. . . . . . . . . . . . . . . 947
81. Delete a specified application pattern details. 947
82. List all artifact of a given application pattern
details. . . . . . . . . . . . . . . 947
83. Upload an artifact file details. . . . . . . 948
84. Download an artifact file details. . . . . . 949
85. Get the detail of the artifact. . . . . . . 949
86. Delete an artifact file details. . . . . . . 949
87. REST API for working with audit event
records. . . . . . . . . . . . . . 950
88. REST API for Certificates . . . . . . . 953
89. REST API for Clouds . . . . . . . . . 954
Copyright IBM Corp. 2013, 2014 xiii
90. REST API for diagnostics.zip. . . . . . 961
91. REST API for environment profiles . . . . 962
92. REST API for hypervisors . . . . . . . 967
93. REST API for IP addresses . . . . . . . 973
94. REST API for IpGroups . . . . . . . . 977
95. REST API for LogViewerMgr . . . . . . 984
96. List all the logs on a specific virtual machine 985
97. Get the content of a specific log file . . . . 986
98. Get the overall monitoring status of a given
virtual application . . . . . . . . . . 987
99. Get the virtual machine monitoring status for
a given virtual application instance . . . . 988
100. Get the middleware monitoring status for a
given virtual application instance . . . . . 989
101. Get virtual machine level monitoring metrics
of a specific virtual machine . . . . . . 989
102. Get middleware level monitoring metrics of a
specific middleware . . . . . . . . . 990
103. REST API for Networks . . . . . . . . 991
104. List all pattern types with version format "vr"
or "vmf" details . . . . . . . . . . . 994
105. Create a pattern type details . . . . . . 995
106. List detail information of one pattern type 995
107. List plugin list of one pattern type details 996
108. Accept the license agreement of a pattern
type. . . . . . . . . . . . . . . 996
109. Delete a pattern type details . . . . . . 997
110. REST API for Patterns . . . . . . . . 997
111. Retrieve all plug-ins details . . . . . . 1002
112. Create a plug-in details . . . . . . . . 1002
113. Delete a plug-in details . . . . . . . . 1003
114. Retrieve plug-in information details 1003
115. List all patterns of shared services . . . . 1004
116. Deploy a shared services pattern into a
cloud group . . . . . . . . . . . 1005
117. REST API for Storage . . . . . . . . 1006
118. REST API for versions . . . . . . . . 1009
119. REST API for VirtualApplianceInstances 1010
120. Retrieve all virtual application details 1014
121. Retrieve the virtual applications with filter 1014
122. Deploy a virtual application details 1015
123. Retrieve virtual application instance status 1016
124. Updated virtual application status details 1017
125. Delete a virtual application details 1018
126. Update application access right for the
specified user name or group name. . . . 1018
127. REST API for VirtualMachines . . . . . 1019
128. REST API for virtual machines . . . . . 1025
129. REST API for VirtualSystems . . . . . . 1030
130. List all orchestration action entries REST API
call . . . . . . . . . . . . . . 1043
131. Retrieve an orchestration action entry REST
API call . . . . . . . . . . . . . 1044
132. Add or update an entry in the orchestration
actions REST API call . . . . . . . . 1045
133. Delete an orchestration action entry REST
API call . . . . . . . . . . . . . 1046
134. Get entries for a specific virtual system
REST API call . . . . . . . . . . . 1046
135. Get list of all BPM Business Processes 1047
136. Get information about a specific BPM
Business Process . . . . . . . . . . 1048
137. Get list of all human services . . . . . . 1048
138. Get information about a specific human
service . . . . . . . . . . . . . 1049
139. Get list of all My Inbox items . . . . . . 1050
140. Get information about a specific My Inbox
item . . . . . . . . . . . . . . 1052
141. Get entries for a specific service instance
entry with a specified deployment ID REST
API call . . . . . . . . . . . . . 1054
142. Get metadata parameters of a specific
service instance REST API call . . . . . 1057
143. Post metadata parameters of a specific
service instance REST API call . . . . . 1058
144. Delete metadata parameters of a specific
service instance REST API call . . . . . 1058
145. Get virtual machine parameters of a specific
service instance REST API call . . . . . 1059
146. Post virtual machine parameters of a specific
service instance REST API call . . . . . 1059
147. Delete virtual machines parameters of a
specific service instance REST API call . . . 1060
148. List all currently running and recently
completed tasks REST API call . . . . . 1060
149. Get information about a specific task 1061
150. Get deployment parameters for a specific
service instance REST API call . . . . . 1063
151. Post deployment parameters for a specific
service instance REST API call . . . . . 1064
152. Get list of all self-service offerings . . . . 1064
153. Get entries for a specific self-service offering
REST API call . . . . . . . . . . . 1066
154. Delete a self-service offering REST API call 1068
155. Update a self-service offering REST API call 1068
156. Log files . . . . . . . . . . . . . 1077
xiv IBM SmartCloud Orchestrator 2.3: User's Guide
Preface
This publication documents how to use IBM

SmartCloud Orchestrator.
Who should read this information
This information is intended for cloud administrators who install and configure
IBM SmartCloud

Orchestrator, and for users who work with this product.

Copyright IBM Corp. 2013, 2014 xv
xvi IBM SmartCloud Orchestrator 2.3: User's Guide
Chapter 1. Overview
IBM SmartCloud Orchestrator offers many
functionalities related to managing your
cloud infrastructure.
SmartCloud Orchestrator helps you with end-to-end service deployment across
infrastructure and platform layers. It also provides integrated IT workflow
capabilities for process automation and IT governance, resource monitoring, and
cost management. The product offers you an extensible approach to integration
with existing environments such as network management tools. It also facilitates
integration with customer-specific service management processes, such as those
defined in the IT infrastructure library (ITIL).
SmartCloud Orchestrator provides a consistent, flexible, and automated way of
integrating the cloud with customer data center policies, processes, and
infrastructures across various IT domains, such as backup, monitoring, and
security. You use the intuitive, graphical tool in SmartCloud Orchestrator to define
and implement business rules and IT policies. You can connect the aspects of
different domains into a consistent orchestration of automated and manual tasks to
achieve your business goals.
SmartCloud Orchestrator is based on a common cloud platform that is shared
across IBM's Cloud offerings. This common cloud stack provides a common
realization of the core technologies for comprehensive and efficient management of
cloud systems.
You choose between two editions: SmartCloud Orchestrator and SmartCloud
Orchestrator Enterprise which also includes Monitoring and Cost Management.
What is new in this release
The following enhancements were introduced in the current release.
Multitenancy
SmartCloud Orchestrator supports multi-tenant cloud environments by
introducing a 3-tier hierarchy of entities as supported in Keystone V3. In
SmartCloud Orchestrator a tenant is reflected by a domain which represents
the high-level container for users and projects. An user is a pair of
credentials that is used for authentication and authorization. A project
authorizes a set of users to a set of cloud resources. Therefore a project
owns in cloud resources like images, pattern, environment profiles, and
self-service offerings. A user and project exist within one single domain.
However, within the same domain, a user can be member of multiple
projects which authorizes the users to the resources that are granted to the
project. For more information, see Managing users, projects, and
domains on page 149.
Copyright IBM Corp. 2013, 2014 1
High availability
A new high availability solution helps to reduce the downtime of the
SmartCloud Orchestrator management stack. It includes a new component,
the System Automation Application Manager, which helps to recover from
application failures and which simplifies to control the SmartCloud
Orchestrator management stack for the operating team. For more
information, see High Availability on page 104.
LDAP authentication
In addition to the Keystone authentication, SmartCloud Orchestrator
supports authentication to an external corporate directory (such as LDAP
or Active Directory). In a multidomain configuration, SmartCloud
Orchestrator also extends the authentication capability to allow any
corporate directory details to be specified on a domain-by-domain basis.
For more information, see Configuring LDAP authentication on page 77.
PowerVM

hypervisors
SmartCloud Orchestrator supports PowerVM hypervisors managed by IBM
Systems Director VMControl

.
Importing virtual machine
You can import virtual machines that were not provisioned by SmartCloud
Orchestrator and that already exist on your hypervisors. After you import
a virtual machine, you can manage it by using the SmartCloud
Orchestrator user interface. For more information, see Importing virtual
machines on page 197.
Product architecture
IBM SmartCloud Orchestrator is a comprehensive product that integrates the
capabilities of several other IBM solutions. It adds several components and
functionalities to IBM SmartCloud Provisioning.
The main components of IBM SmartCloud Orchestrator are the process engine and
the corresponding modeling user interface, which is used to create processes. For
this purpose, SmartCloud Orchestrator uses the capabilities of IBM Business
Process Manager. It also integrates other domain-specific components that are
responsible for such functions as monitoring, metering, and accounting.
SmartCloud Orchestrator bundles all these products and components and provides
processes that are required to implement the domain-specific functionalities. Both
the self-service user interface and the administrative user interface of SmartCloud
Provisioning are extended to reflect the new functions that are provided by
SmartCloud Orchestrator.
2 IBM SmartCloud Orchestrator 2.3: User's Guide
Cloud Marketplace
Development
tools
IaaS gateway
Storage
(Cinder)
Public
Cloud
Compute
(Nova)
Network
(Nova Networks)
Infrastructure-as-a-Service (IaaS)
Workflow
Image
management
Patterns Software stacks
Service management
- Monitor
- Backup and Restore
- Security and patch compliance
The following is a description of the role each major component plays in
SmartCloud Orchestrator:
Infrastructure-as-a-Service
The Infrastructure-as-a-Service (IaaS) component is responsible for
managing access to compute, storage and networking resources in the
virtual environment. All requests to provision services across these services
is performed by this component. The IaaS component is delivered by using
OpenStack, a leading open source, community-driven project for highly
scalable, highly resilient cloud infrastructure management. IBM is one of
the Platinum Members of the OpenStack Foundation.
IaaS Gateway
The IaaS Gateway provides a routing mechanism that allows two
important configurations. Firstly, it allows multi-geographical deployments
in which multiple IaaS/OpenStack instances can be deployed in multiple
sites and then federated together within SmartCloud Orchestrator.
Secondly, it allows for connectivity to public clouds such as Amazon EC2
and other public clouds compatible with OpenStack.
Software stacks
While not a specific component itself, Software Stacks represent the
concept that when one or more virtual systems are deployed, it is also
possible to specify multiple software packages to be deployed upon first
boot of those systems. It can be done by invoking simple installation
scripts, but also other strong tools can be used such as Chef recipes and
cookbooks for automated installation and configuration.
Patterns
Patterns allow for deploying more complex middleware configurations and
multinode applications. The Patterns component provides a graphical
editor that allows the user to describe multiple virtual systems, each with a
base image and set of software to be installed, and then specify the
relationships and configuration scripts necessary to connect those systems
together. With this level of automation, an entire multisystem deployment
can be done with just a few simple clicks.
Chapter 1. Overview 3
Image management
The Image Management component has two major functional areas. The
first one is the Image Construction and Composition Tool, which allows a
user to describe a base image and set of software stacks, and then capture
that fully deployed system into an image that can be reused. The second
one is the Virtual Image Library, which allows a user to manage images
similar to other assets, providing check-in and check-out options,
versioning, indexing and searching facilities so that corporate compliance
rules can be followed even when the images are offline.
Workflow orchestration
The Workflow Orchestration component provides a graphical editor that
allows the user to easily customize and extend the procedures that are
followed when a user request is initiated. In addition, it also provides the
facilities to customize the self-service catalog so that users have access to a
variety of service request types that they can access. This component is
delivered by embedding IBM's award-winning Business Process Manager
technology along with a number of pre-built automation toolkits that make
it possible to integrate workflow automation with the cloud platform and
its other components. The graphical designer is highly flexible, providing
many integration techniques ranging from invocation of simple scripts and
calling web services to invoking more sophisticated programs such as
those written in Java.
Cloud Marketplace
The Cloud Marketplace is a publicly accessible website where various
forms of automation can be downloaded and used within SmartCloud
Orchestrator. It includes references to supported automation communities
such as Chef, ready to use Patterns and Images, and a variety of pre-built
Workflow Orchestration routines, packages and toolkits. It is designed to
"ship when ready", meaning that new automation can become available at
any time, regardless of SmartCloud Orchestrator release schedules.
Service management
This box represents optional additional management functions that are
included in SmartCloud Orchestrator Enterprise. It also highlights the
ability to integrate through Workflow Orchestration other management
tools and disciplines that may be important within your environment.
Development tools
This box represents the ability to integrate developer tools from IBM
Rational Team Concert and a set of plug-ins within SmartCloud
Continuous Delivery such as that a user can automate a "continuous
delivery pipeline" from check-in of code, through build, deployment, test,
and promotion. Those tools are not provided within SmartCloud
Orchestrator, but more information about them can be found on ibm.com.
4 IBM SmartCloud Orchestrator 2.3: User's Guide
Product features
Read about the main features that are available with SmartCloud Orchestrator
version 2.3.
Pattern-based cloud delivery
SmartCloud Orchestrator provides capabilities for multi-domain orchestration
(virtual system and virtual application) and a graphical orchestrator for simple
composition of cloud automation.
SmartCloud Orchestrator is a new private cloud offering based on the open
sourced OpenStack software that significantly speeds and simplifies managing an
enterprise-grade cloud. You have a core set of open source-based technologies to
build enterprise-class cloud services that can be ported across hybrid cloud
environments.
SmartCloud Orchestrator gives you greater flexibility by removing the need to
develop specific interfaces for different cloud services. You can quickly combine
and deploy various cloud services onto the cloud infrastructure by lining up the
compute, storage and network resources with an easy-to-use graphical interface.
Designing business processes
SmartCloud Orchestrator is integrated with IBM Business Process Manager, a
workflow engine with graphical tooling. It provides a possibility to create and edit
complex workflows through simple drag and drop. you can extend the capabilities
of SmartCloud Orchestrator and design your own workflows. For more
information see Custom extensions on page 7.
Self-service user interface
Intuitive self-service user interface containing a customizable catalog of offerings is
available for users. Offerings can be group into categories which are created by
administrators to fit the needs of work environment. For more information about
self-service, see Managing self-service offerings on page 779.
OpenStack adoption
OpenStack is a cloud operating system that controls large pools of compute,
storage, and networking resources throughout a data center, all managed through a
dashboard that gives administrators control while empowering their users to
provision resources through a web interface. For more information see Overview
of OpenStack on page 8.
Image management
SmartCloud Orchestrator provides two components that simplify image
management: Image Construction and Composition Tool, and Virtual Image
Library.
You can use the Image Construction and Composition Tool to build virtual images
for deployment into cloud environments. Experts can build particular software
bundles for reuse by others. This simplifies the complexity of image creation and
Chapter 1. Overview 5
reduces errors. You can reuse and manage images and software in a cloud
environment and build and share images that are self-descriptive, customizable,
and manageable.
The Virtual Image Library component provides extended services for image
management. It supports VMware and OpenStack operational image repositories.
After you define the operational repository to Virtual Image Library and index the
images that it contains, all the information about the images is stored in the Virtual
Image Library database. You can use a local image store, called the reference
repository, to save copies of key images from any operational repository or to
replicate copies of images from the reference repository to any operational
repository. You can also import images from the Virtual Image Library file system
to the reference repository to perform image management operations on the
imported images.
For more information about managing virtual images, see Chapter 5, Managing
virtual images, on page 287.
Cost management
The IBM SmartCloud Cost Management component provides functionality for
collecting, analyzing, reporting, and billing that is based on usage and costs of
shared computing resources. With this tool, you can understand your costs and
track, allocate, and invoice based on allocated or actual resource use by
department, user, and many more criteria. For more information about cost
management, see Metering and billing.
Within SmartCloud Orchestrator metering is primarily driven from the OpenStack
layer to capture all virtual machine provisioning requests. For more information,
see the OpenStack Collector topic.
TOSCA support
SmartCloud Orchestrator supports importing, deploying, and exporting service
templates according to the OASIS Topology and Orchestration Specification for
Cloud Applications (TOSCA). This enables the consumption of third-party content
provided in a standardized format.
Monitoring
In SmartCloud Orchestrator you can monitor workloads and instances using IBM
Tivoli Monitoring. With this component, you can measure the cost of cloud
services with metering and charge-back capabilities. For more information about
monitoring, see Integrating with IBM Tivoli Monitoring on page 783.
Reporting
SmartCloud Orchestrator provides a diverse set of reports that provide specific
data you can use for planning purposes. System usage reports are generated to
track both physical and virtual resource utilization. You can also access reports to
track the user activity in the clouds that are managed by SmartCloud Orchestrator.
For more information about reports, see Chapter 10, Reporting, on page 799.
6 IBM SmartCloud Orchestrator 2.3: User's Guide
Custom extensions
You create custom extensions to SmartCloud Orchestrator in the Business Process
Manager Process Designer tool and base them on Business Process Manager
business processes. To implement user interface extensions, you can use Business
Process Manager human services.
SmartCloud Orchestrator delivers a Business Process Manager toolkit called
SCOrchestrator_Toolkit. This toolkit provides many useful artifacts:
Business processes
A business process is any course of action or procedure that an
organization follows to achieve a larger business goal. When you break it
down, a business process is actually a series of individual tasks or
activities that are performed in a specific order. Business processes provide
the primary means through which enterprise services are integrated.
Services
Services provide functions for a business process, which itself is a sequence
of services. Creating services separately from a business process means a
service can be developed independently of a business process and that
many types of business processes can reuse that service.
Human services
Human service includes an activity in your business process definition that
creates an interactive task that process participants can perform in a
web-based user interface.
Coaches
Coaches are the user interfaces for human services.
Business object definitions
Business objects carry the functional properties, data transformation
information, and file content that the adapter needs to process requests and
generate responses.
With the help of these artifacts, you can efficiently build custom extensions for
SmartCloud Orchestrator. The SCOrchestrator_Toolkit also contains numerous
samples that show how to define custom extensions.
You can download more Business Process Manager toolkits from the online
marketplace. These toolkits provide more content for different areas, such as
networking or storage, and you can also use them to build SmartCloud
Orchestrator extensions.
Restriction: If you define more than one snapshot for Business Process Manager
process application or toolkit, you will be able to use only the artifacts of the top
level to define a new extension in SmartCloud Orchestrator.
Related tasks:
Chapter 7, Managing orchestration workflows, on page 763
Create custom orchestration workflows in the Business Process Manager user
interface and run them in your SmartCloud Orchestrator environment.
Chapter 1. Overview 7
Overview of OpenStack
SmartCloud Orchestrator is based on OpenStack (the Grizzly release).
OpenStack is a collection of open source technologies that provide scalable
computing software for both public and private clouds. For detailed information
about OpenStack, see the OpenStack documentation.
SmartCloud Orchestrator uses the following components and services of
OpenStack:
v Image (codenamed Glance) that provides a catalog and repository for virtual disk
images. The virtual disk images are mostly used in the OpenStack Compute
service component.
v Compute (codenamed Nova) that provides virtual servers on demand.
v Identity (codenamed Keystone) that provides authentication and authorizations
for all OpenStack services.
v Block Storage (codenamed Cinder) that provides persistent block storage to guest
virtual machines.
SmartCloud Orchestrator does not use the Object Store (codenamed Swift) service
component, nor the Network (codenamed Neutron) service component for network
management, nor the Dashboard (codenamed Horizon) service component for the
web-based user interface.
SmartCloud Orchestrator uses the nova-network of OpenStack as a networking
option (see networking with nova-network).
To configure and administer SmartCloud Orchestrator, you must learn to use the
OpenStack command-line interface. For example, you might need to use the
keystone command-line interface to manage authentication and authorizations, and
the glance command-line interface to manage virtual images. For more information
about the OpenStack command-line interface, see the OpenStack CLI Guide.
8 IBM SmartCloud Orchestrator 2.3: User's Guide
Chapter 2. Installing
Follow this procedure to install SmartCloud Orchestrator.
Planning your installation
Before you start the installation, review the requirements and plan the whole
process.
Installation overview
Get familiar with the basic concepts of SmartCloud Orchestrator so that you can
properly plan your installation.
The main components of SmartCloud Orchestrator installation topology are the
Central Server and the Region Server, The Central Server represents the core
SmartCloud Orchestrator management components. The Region Server represents
the component that is used to communicate with a specific hypervisor
management infrastructure (KVM, VMware, or PowerVM).
The Central Server and the Region Server must run on KVM or VMware virtual
machines. Central Server is a set of components that are grouped into four virtual
machines. An additional virtual machine is required if you want to use the high
availability solution. For more information, see High Availability on page 104.
Region Server is set up on a single virtual machine. Additional Region Servers can
be added to enable a multiple-region environment. If you are using a KVM region,
a KVM Compute Server is required and it must be installed on a physical machine.
The key components of the installation are:
Central Server
Is installed on the following virtual machines:
Central Server 1
DB2 plus tooling (yum, chef) for installing components on the other
central servers
Central Server 2
IaaS Gateway, Public Cloud Gateway, Keystone, and Virtual Image
Library
Central Server 3
Workload Deployer and SmartCloud UI
Central Server 4
Business Process Manager
Region Server
Is installed on a single virtual machine:
Region Server -1
The following key components are installed:
v OpenStack
v DB2 (optional, it is installed only if you want this region server
use its own DB2)
Copyright IBM Corp. 2013, 2014 9
v SmartCloud Entry driver (optional, it is installed only on
VMware and Power regions)
v yum
v chef
v PXE (optional, it is installed only for KVM region servers so that
additional KVM compute nodes can be installed)
KVM Compute Server
Only for KVM region. This server must be associated with a KVM Region
Server and have VM work load running on it. The KVM compute server
must be installed on bare metal.
The central servers must be located in the same network, while the region server
can be distributed, as long as it has network connectivity to the central servers
Typically, a customers corporate DNS can be used as SmartCloud Orchestrator
upstream DNS. Central server has a DNS, while each region server also has one.
This means that they are connected hierarchically. As a result, you can delegate a
subdomain to SmartCloud Orchestrator when the installation is complete.
Meanwhile, it is also possible that SmartCloud Orchestrator fully relies on
customers corporate DNS without deploying any embedded DNS, if all
prerequisites are satisfied.
For more information about the SmartCloud Orchestrator topology, you can refer
to the SmartCloud Orchestrator product wiki.
Installation scenarios
Before you proceed with the installation of SmartCloud Orchestrator, you must
choose one of the installation scenarios.
SmartCloud Orchestrator 2.3 supports the following basic installation scenarios:
v Manage vCenter
v Manage VMControl
v Scale-out KVM
The following table presents a brief summary of these scenarios:
Table 1. Summary of SmartCloud Orchestrator installation scenarios
Scenario Description
Manage-from
environment
Manage-to
hypervisor
Distribution of
manage-to and
manage-from
Manage vCenter Installing all
components on
several virtual
machines. Then
connecting to
one or more
existing vCenter
instances.
KVM or
VMware virtual
machines
One or more
vCenter-
managed ESXi
nodes
v Manage-from
not
distributed
v Manage-to
distributed via
vCenter
mechanisms
10 IBM SmartCloud Orchestrator 2.3: User's Guide
Table 1. Summary of SmartCloud Orchestrator installation scenarios (continued)
Scenario Description
Manage-from
environment
Manage-to
hypervisor
Distribution of
manage-to and
manage-from
Manage
VMControl
Installing all
components on
several virtual
machines. Then
connecting to the
existing
VMControl
instance.
KVM or
VMware virtual
machines
One or more
VMControl-
managed Power
systems or Flex
Chasis with
Power nodes
v Manage-from
not
distributed
v Manage-to
distributed via
VMControl
server-pool
mechanisms
Scale-out KVM Installing all
components on
several virtual
machines. Then
adding
manage-to KVM
hypervisors to
increase capacity
as user demand
grows.
KVM or
VMware virtual
machines
One or more
KVM nodes
v Manage-from
not
distributed
v Manage-to
distributed via
additional
KVM nodes
Manage vCenter scenario
Plan for this installation scenario if you want to connect your SmartCloud
Orchestrator environment to already existing vCenter instances.
You can connect the manage-from components to one or more existing vCenter
instances so that the existing vCenter/ESXi infrastructure can be used as a
manage-to environment. The graphic presents the default topology for this
scenario: see Figure 1 at https://www.ibm.com/developerworks/community/
wikis/home?lang=en#!/wiki/IBM%20SmartCloud%20Orchestrator/page/IBM
%20SmartCloud%20Orchestrator%202.3%20Network%20Topology
Management Network
In the default topology, the management network is used to set up
connectivity with vCenters and Virtual Image Library proxies as well as to
permit IBM Workload Deployer, Business Process Manager, and virtual
machine communication. It is also used to grant user access to the
SmartCloud Orchestrator user interface. Upon initial setup, you can change
the SmartCloud Orchestrator configuration to have physical and logical
segregation between this traffic.
VMware internal management network
This network allows for communication between vCenter and ESX. Virtual
Image Library proxy must be located in this network because it requires
network access to ESX servers.
Important: If a datastore cluster is configured in vCenter, then DRS must
be enabled as well. Deployments fail without DRS enabled when
provisioning to a datastore cluster.
To enable DRS, check Turn on Storage DRS under General, when you
create or edit a Datastore Cluster in vCenter.
Chapter 2. Installing 11
Manage VMControl scenario
Plan for this installation scenario if you want to connect your SmartCloud
Orchestrator environment to already existing VMControl instances.
The graphic presents the default topology for this scenario: see Figure 2 at
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/
wiki/IBM%20SmartCloud%20Orchestrator/page/IBM%20SmartCloud
%20Orchestrator%202.3%20Network%20Topology
Scale-out KVM scenario
Plan for this installation scenario if you want to add manage-to KVM nodes to
increase the capacity of your SmartCloud Orchestrator environment.
You can connect the manage-from components to additional manage-to KVM
compute nodes as user demand requires additional capacity. The graphic presents
the default topology for this scenario: see Figure 3 at https://www.ibm.com/
developerworks/community/wikis/home?lang=en#!/wiki/IBM%20SmartCloud
%20Orchestrator/page/IBM%20SmartCloud%20Orchestrator%202.3%20Network
%20Topology
SmartCloud Orchestrator Enterprise installation
To give you more control over your cloud environment, SmartCloud Orchestrator
Enterprise bundles three additional products: Jazz

for Service Management, IBM

Tivoli

Monitoring, and IBM SmartCloud Cost Management.

The products are responsible for the following additional functionalities:
v Jazz for Service Management - reporting
v IBM Tivoli Monitoring - monitoring
v IBM SmartCloud Cost Management - metering and billing
Installation flow
The first part of the SmartCloud Orchestrator Enterprise installation is exactly the
same as of the base version. Then you need to install the additional products on
separate machines:
1. Refer to the installation procedure in the Chapter 2, Installing, on page 9
section to install SmartCloud Orchestrator and its services.
2. Install Jazz for Service Management. For the instructions, refer to Installing
Jazz for Service Management and Tivoli Common Reporting on page 802.
3. Install IBM Tivoli Monitoring. For the instructions, refer to Installing IBM
Tivoli Monitoring on page 784.
4. Install IBM SmartCloud Cost Management. For the instructions, refer to Quick
start guide for metering and billing on page 87.
12 IBM SmartCloud Orchestrator 2.3: User's Guide
Hardware prerequisites
Review the hardware prerequisites to make sure that your environment meets
them.
Manage-from requirements
The SmartCloud Orchestrator management components need to be installed on the
following VMware or KVM virtual machines that must run Red Hat Enterprise
Linux 6.3 or 6.4 :
v Four virtual machines for installing the Central Server management components.
They are referred as Central Server 1, Central Server 2, Central Server 3, and
Central Server 4.
v One optional virtual machine for High Availability solution. It is referred as
Central Server 5. For more information, see High Availability on page 104.
v One virtual machine for each Region Server. The first Region Server is referred
as Region Server 1.
For more information on creating the virtual machines on VMware or KVM, see
Setting up virtual machines to install Central Server and Region Server on page
49.
Table 2. The minimum Manage-from requirements
Machine
Role
Processor
(vCPU)
Memory
(Free
value, GB)
Overall
Volume
Requirements
(GB)
Free Space:
"/"
Free Space:
"/home"
Free Space:
Other
Partitions
Central
Server 1
2 6 100 75 19
Central
Server 2
2 8 141 55 30 /opt 10
/tmp 40
Central
Server 3
2 4 80 70 4
Central
Server 4
2 6 50 40 4
Central
Server 5
(optional)
2 4 20 20 N/A
Region
Server
2 4 76 40 30
Disk planning considerations:
v The specified hard disk space is the minimum free space required on the machine before
the SmartCloud Orchestrator installation. Be sure that there is sufficient space for the
required partitions.
For Central Server 1 and the Region server, additional disk size (about 14 GB) is
required considering where the SmartCloud Orchestrator package locates.
For Central Server 1 and Central Server 2, additional space on /home may be required
over time based on database and image management practices. Monitoring is
recommended.
v You must attach, without mounting it, an additional raw disk of 5 GB to Central Server
2. You need the disk label of this disk during the installation of the Central Server.
v For all Servers, /tmp needs read, write, and execute permissions.
Chapter 2. Installing 13
Capacity planning considerations:
v The minimum and recommended levels are a function of the number of users,
managed virtual machines, and managed images. For the minimum values, the
expectation is a small cloud on the order of 5 users, 100 managed virtual
machines, and 10 managed images. The system allocations should progress to
the recommended values as these values are increased. Storage requirements
might increase based on image management approaches. Standard volume
management is recommended.
Manage-to requirements
KVM compute nodes:
You can add Red Hat Enterprise Linux 6.3 or 6.4 nodes to the SmartCloud
Orchestrator environment. The compute node must be a physical machine, and
will be deployed from repositories on the manage-from server. All KVM compute
nodes must use the same interface to connect to the Region Server, for example,
eth0, eth1, or eth2. The minimum configuration for KVM servers is as follows:
Table 3. KVM Compute Nodes
Machine Role
Number of
NICs Processor Memory
Hard Dish
Space
KVM
Hypervisor
1 VT enabled At least 20 GB At least 200 GB
VMware compute nodes:
The VMware vCenter managed infrastructures might be connected to the
SmartCloud Orchestrator environment. The physical minimum configuration for
the ESXi servers is as follows:
Table 4. VMware Compute Nodes
Machine role
Number of
NICs Processor Memory
Hard Disk
Space
ESXi Hypervisor 1 VT enabled At least 20 GB At least 200 GB
Power compute nodes:
VMControl 2.4.3 managed infrastructures might be connected to the SmartCloud
Orchestrator environment. The minimum configuration for Power systems
managed by VMControl is as follows:
14 IBM SmartCloud Orchestrator 2.3: User's Guide
Table 5. Power Compute Nodes
Machine Role
Number of
NICs Processor Memory
Hard Disk
Space
Power
Hypervisor
At least 1 for
single VIOS, at
least 2 for dual
VIOS
Any # of
Power5, Power6
or Power7
At least 16 GB,
additional 8 GB
are required if
hosting
Director/
VMControl
At least 200 GB
are highly
recommended to
use SAN
infrastructure
(V5000, V7000 or
SVC) for Storage
Copy Services
support.
Network requirements
SmartCloud Orchestrator uses MTU standards in all network devices, that is MTU
= 1500. For given networks with different MTU size, make sure that the MTU of all
management servers has the same value, otherwise packages might be too big and
cannot be transferred.
Software prerequisites
Review the software prerequisites for your environment.
Required packages
SmartCloud Orchestrator runs on top of Red Hat Enterprise Linux 6.3 or 6.4 64-bit.
The following packages are required:
v RHEL6.3*.iso or RHEL6.4*.iso
Note: Before installing SmartCloud Orchestrator, prepare an ISO file of Red Hat
Enterprise Linux 6.3 or 6.4 x86_64 and place it on Central Server 1 and on the
Region Servers, for example, in the /opt directory.
Note: You must use the base Red Hat Enterprise Linux 6.3 or 6.4 image when
installing SmartCloud Orchestrator. You cannot use an image that contains any
Red Hat Enterprise Linux patch. After installing SmartCloud Orchestrator, you
can install Red Hat Enterprise Linux patches, if needed.
v rubygems-*.el6.noarch.rpm (<= 1.3.7-1)
v libguestfs-winsupport-*.el6.x86_64.rpm (<= 1.0-7)
Make sure that the rubygems-*.el6.noarch.rpm (<= 1.3.7-1) and
libguestfs-winsupport-*.el6.x86_64.rpm (<= 1.0-7)RPM packages are copied into
the /data/repos/scp directory on Central Server 1 and on the Region Servers.
You can download the libguestfs package from https://rhn.redhat.com/network/
software/packages/name_overview.pxt?package_name=libguestfs-winsupport
&archIdList=&archLabelList=&search_subscribed_channels=yes using your Red
Hat login credentials.
Note: To download the libguestfs package, you must have the Red Hat
Enterprise Virtualization license.
You can download the rubygems package from https://rhn.redhat.com/network/
software/packages/name_overview.pxt%3Fpackage_name=rubygems
Chapter 2. Installing 15
%26archIdList=%26archLabelList=%26search_subscribed_channels=yes.
Supported operating systems
This topic describes the operating systems that are supported in a SmartCloud
Orchestrator environment.
Manage-from requirements
SmartCloud Orchestrator services can be installed on KVM or VMware virtual
machines.
The following table describes the host and guest operating systems supported for
installing SmartCloud Orchestrator.
Table 6. Host and guest operating systems supported by the standard installation
Hypervisor Host operating system Guest operating system Reference
KVM Red Hat Enterprise Linux 6.3,
6.4 x86_64
Red Hat Enterprise Linux 6.3,
6.4 x86_64
Managing guests with the
Virtual Machine Manager
(virt-manager)
VMware VMware vCenter Server 4.1 u1,
5.0, 5.1
VMware vSphere 4.1 u1, 5.0, 5.1
Red Hat Enterprise Linux 6.3,
6.4 x86_64
vSphere Virtual Machine
Administration
Manage-to requirements
The following table describes the host and guest operating systems supported by
each type of hypervisor in a SmartCloud Orchestrator environment.
Table 7. Host and guest operating systems supported by the hypervisors
Hypervisor Host operating system Guest operating systems of deployed virtual machines
KVM Red Hat Enterprise Linux 6.3, 6.4
x86_64
SLES 11 SP1 and SP2, 32-bit and 64-bit
RHEL 5.x, RHEL 6.1, 6.2, 6.3, and 6.4, 32-bit and 64-bit
CentOS 6.3 and 6.4, 64-bit
Windows 2008 R2 64-bit, Windows 7 64-bit, Windows
Server 2012 64-bit
VMware VMware vCenter Server 4.1 u1, 5.0,
5.1
VMware vSphere 4.1 u1, 5.0, 5.1
SLES 11 SP1 and SP2, 32-bit and 64-bit
RHEL 5.x, RHEL 6.1, 6.2, 6.3, and 6.4, 32-bit and 64-bit
CentOS 6.3 and 6.4, 64-bit
Windows 2008 R2 64-bit, Windows 7 64-bit, Windows
Server 2012 64-bit
Power IBM Systems Director 6.3.3.1 and
VMControl 2.4.3.1
VIOS 2.2.2.2 on the Power systems
NIM server is required for non-SCS
environments or for importing
mksysb images
AIX 6.x and AIX 7.x
RHEL 6.3, 6.4 for Power (ppc64)
SLES 11 for Power (ppc64)
Activation Engine is required for these images.
Note:
v The image imported or created in VMControl must have the VMControl
Activation Engine. For information, see Installing the VMControl activation
engine on AIX and Linux.
v For more information about image management, see Image management on
page 488.
16 IBM SmartCloud Orchestrator 2.3: User's Guide
Preparing the central server and the region server
To start the installation process, you must prepare four Central Server virtual
machines and at least one Region Server virtual machine.
Before you begin
In this topic, the Central Server virtual machines are called Central Server 1,
Central Server 2, Central Server 3, and Central Server 4. The fist Region Server
virtual machine is called Region Server 1.
You can use VMware or KVM virtual machines to run the Central Server and
Region Server services. To manage KVM virtual machines, it is recommended to
use the virt-manager application. To manage VMware virtual machines, it is
recommended to use the VMware vCenter application. If you want to use the high
availability solution in your SmartCloud Orchestrator environment, use VMware
virtual machines to run your SmartCloud Orchestrator environment. For more
information about high availability, see High Availability on page 104.
If the virtual machines are already available, run the following procedure. If you
need to create the virtual machines, follow the procedure described in Setting up
virtual machines to install Central Server and Region Server on page 49.
About this task
During this task, you repeat the described procedure for each of the Central Server
and Region Server virtual machines to prepare them for the installation process.
Note: For a VMware region, the Region Server network configuration must be
such that the Region Server can contact the ESXi hosts using the host name or IP
address that has been used to register those servers with the vCenter. Even if the
ESXi hosts have multiple IP addresses and one or more of them can be reached
from the Region Server, the only way for the vilProxy service (Virtual Image
Library service, for details refer to Configuring Virtual Image Library server and
remote proxy components on page 303) to index images on those hosts is to
connect to them using exactly the same IP addresses (or host names) that are
displayed in the vCenter.
Note: To exploit best performance of Virtual Image Library and Virtual Image
Library proxy, when they are installed on virtual machines on VMware 5.1, the
virtual machines (Central Server 2 and Region Server) must have nested
virtualization enabled. It is not required if the system is not a virtual machine but
bare metal system. For information about enabling nested virtualization, see
http://pubs.vmware.com/vsphere-51/topic/com.vmware.vsphere.vm_admin.doc/
GUID-2A98801C-68E8-47AF-99ED-00C63E4857F6.html.
Note: If the manage to VMware environment is a cluster environment, the vSphere
DRS must be enabled in the vCenter to which the SmartCloud Entry will connect,
and make sure that the automation level is not Manual (Fully or Partially
Automated is OK). This is a prerequisite before adding a VMware vCenter in a
SmartCloud Orchestrator environment, otherwise you have to delete it after you
enable the DRS and recreate it again. You can find more information regarding the
vSphere DRS enablement at http://pubs.vmware.com/vsphere-51/index.jsp?topic=
%2Fcom.vmware.vsphere.resmgmt.doc%2FGUID-8ACF3502-5314-469F-8CC9-
4A9BD5925BC2.html
Chapter 2. Installing 17
Procedure
1. Make sure that the virtual machines meet the hardware prerequisites described
in Hardware prerequisites on page 13.
2. Install Red Hat Enterprise Linux V6.3 or V6.4 64-bit on the virtual machines.
a. Make sure that all Central Server virtual machines and Region Server
virtual machines have the same kernel version installed and is consistent
with the ISO file you prepared.
b. Make sure that all Central Server virtual machines have the same root user
password.
c. When installing the Red Hat Enterprise Linux V6.3 or V6.4 64-bit operating
system for the Central or Region servers, the Basic Server package group is
sufficient, because the Central and Region servers deploy script installs the
SmartCloud Orchestrator required packages from the corresponding Red
Hat ISO files.
Note: Make sure that the RHEL installation includes the bind-utils RPM.
3. Edit the /etc/selinux/config file and set the parameter SELINUX=disabled.
Reboot the computer.
4. Make sure the SSHD is enabled on the virtual machine.
5. Make sure that the network is configured for the virtual machine (static IP is
recommended):
v All Central Server virtual machines must be in the same network.
v All Central Server virtual machines and the Region Server virtual machines
must have network connectivity to Central Server 1.
v Make sure that /etc/hosts on each Central Server or Region Server virtual
machine has no records associated with the IP addresses of any Central
Server or Region Server Virtual machine.
6. Choose a Domain Name Server (DNS) configuration option. For each option,
additional steps might be needed.
Option A:
SmartCloud Orchestrator uses a built-in DNS (stand-alone environment). In this
case, the installation process performs a hierarchical DNS deployment on
Central Server 1 and each Region Server. Each Region Server is a subdomain of
Central Server 1 and each Region Server forwards DNS requests to Central
Server 1.
Additional setup steps needed: none.
The following graphic shows the topology for a built-in DNS stand-alone
environment.
Option B:
18 IBM SmartCloud Orchestrator 2.3: User's Guide
SmartCloud Orchestrator uses a built-in DNS, but the corporate DNS is the
parent DNS. In this case, the installation process performs a hierarchical DNS
deployment on Central Server 1 and each Region Server. The corporate DNS is
used as an upstream forwarder of Central Server 1. Central Server 1 forwards
DNS requests to the upstream DNS while each Region Server forwards DNS
requests to Central Server 1.
Additional setup steps needed:
The required steps are described here using an example where the corporate
DNS uses named with IP 198.51.100.50 and the Search Domain is company.com:
a. Ensure each Central Server and Region Server is not included in the reverse
lookup of the corporate DNS. Check file /var/named/reverse-lookup.db and
remove any entries related with the Central Servers and Region Servers.
b. Edit the /etc/resolv.conf file on each Central Server and Region Server
and add a nameserver entry that points to the corporate DNS, as shown in
the following example:
cat /etc/resolv.conf
nameserver 198.51.100.50
c. After installation finishes, modify the corporate DNS zone file to delegate
the subdomain to central-server-1.
The following graphic shows the topology for a built-in DNS environment
where the corporate DNS is the parent DNS.
Option C:
SmartCloud Orchestrator uses the corporate DNS and no built-in DNS. In this
case, the installation process will not deploy any DNS server.
Additional setup steps needed:
The required steps are illustrated here using an example, where the corporate
DNS IP is 198.51.100.50 and the Search Domain is company.com:
a. Register new DNS entries for each Central Server and Region Server into
the corporate DNS, and ensure that both forward lookup and reverse
lookup work for all domain users, for example:
Forward lookup: Add the following entries to a forward file named
/var/named/forward-lookup.db:
central-server-1 A 198.51.100.51
central-server-2 A 198.51.100.52
central-server-3 A 198.51.100.53
central-server-4 A 198.51.100.54
region-server-1 A 198.51.100.55
region-server-2 A 198.51.100.56
Chapter 2. Installing 19
Reverse lookup: Add the following entries to a reverse file named
/var/named/reverse-lookup.db:
$ORIGIN 100.51.198.in-addr.arpa.
51 PTR central-server-1.cloud.company.com.
52 PTR central-server-2.cloud.company.com.
53 PTR central-server-3.cloud.company.com.
54 PTR central-server-4.cloud.company.com.
55 PTR region-server-1.cloud.company.com.
56 PTR region-server-2.cloud.company.com.
...
b. Register new DNS entries for provisioned virtual machines into the
corporate DNS. The corresponding IP range must be specified in the
region-server.conf configuration file when performing the procedure to
install the Region Server. See Installing the region server on page 26.
Forward lookup: Add the following entries to a forward file named
/var/named/forward-lookup.db:
SC-198-51-100-80 A 198.51.100.80
SC-198-51-100-81 A 198.51.100.81
SC-198-51-100-82 A 198.51.100.82
SC-198-51-100-83 A 198.51.100.83
SC-198-51-100-84 A 198.51.100.84
SC-198-51-100-85 A 198.51.100.85
SC-198-51-100-86 A 198.51.100.86
SC-198-51-100-87 A 198.51.100.87
SC-198-51-100-88 A 198.51.100.88
SC-198-51-100-89 A 198.51.100.89
SC-198-51-100-90 A 198.51.100.90
Reverse lookup: Add the following entries to a reverse file named
/var/named/reverse-lookup.db:
80 PTR SC-198-51-100-80.company.com.
81 PTR SC-198-51-100-81.company.com.
82 PTR SC-198-51-100-82.company.com.
83 PTR SC-198-51-100-83.company.com.
84 PTR SC-198-51-100-84.company.com.
85 PTR SC-198-51-100-85.company.com.
86 PTR SC-198-51-100-86.company.com.
87 PTR SC-198-51-100-87.company.com.
88 PTR SC-198-51-100-88.company.com.
89 PTR SC-198-51-100-89.company.com.
90 PTR SC-198-51-100-90.company.com.
c. Edit the /etc/resolv.conf file on each Central Server and Region Server
and add a nameserver entry that points to the corporate DNS, as shown in
the following example:
cat /etc/resolv.conf
nameserver 198.51.100.50
d. To verify that the DNS resolution is correctly configured, run the following
commands for all Central Servers and Region Servers:
1) host <IP_address>
This command must return the Fully Qualified Domain Name (FQDN)
of the server.
2) hostname --fqdn
This command must return the same FQDN as in the previous
command.
3) hostname
This command must return the first part of the FQDN.
The following graphic shows the topology for using the corporate DNS and no
built-in DNS.
20 IBM SmartCloud Orchestrator 2.3: User's Guide
7. Single Sign On is automatically configured and enabled by the SmartCloud
Orchestrator deployment. Make sure that the resolv.conf and DNS configuration
on the machine is correctly updated to be able to resolve each central and
region server's fully-qualified domain name.
a. If you choose option A in previous step, the installer uses "dns_suffix"
which must be specified in the configuration file central-server.conf when
performing the procedure to install the central server to generate the Single
Sign On domain. See Installing the central server on page 23. This option
means that for client nodes where the web browser is running to connect to
the SmartCloud Orchestrator UI, the configuration file must have the name
server pointing to Central Server 1.
b. If you choose option B or option C in the previous step, make sure that the
client nodes where the web browser is running on to connect to SmartCloud
Orchestrator UI has the name server pointing to the corporate DNS.
8. Optional: If the central and region servers are running on virtual machines, a
snapshot is highly recommended to back up a copy of the virtual machine disk
file of each central and region server before you start the installation procedure.
Snapshots provide a change log for the virtual disk and they are used to restore
a virtual machine to a specific status, so that, when an installation fails, all the
central and region servers can be reverted to the fresh status.
What to do next
When all systems and configurations are ready, proceed as documented in
Installing the central server on page 23.
Preparing the installation media
Before installation, prepare the installation media.
Preparing the installation based on electronic download
packages
To install SmartCloud Orchestrator from electronic download packages, you must
first prepare the images. Note: These images must be copied to Central Server 1
and to each Region server that is being installed.
Procedure
1. Download the packages from the Passport Advantage

website:
For SmartCloud Orchestrator, download the following packages:
CIQ3VML.tar
CIQ6EML.tar
CIQ6FML.tar
CIQ6GML.tar
Chapter 2. Installing 21
For SmartCloud Orchestrator Enterprise, download the following packages:
CIQ3XML.tar
CIQ6EML.tar
CIQ6FML.tar
CIQ6GML.tar
Note: The packages CIQ6EML.tar, CIQ6FML.tar and CIQ6GML.tar are used for
both types of installation.
2. Use the following command to extract the content of the TAR files into the
installation directory of your choice. In this example of installation, the
directory is called /install_images:
tar xvf <tar file>
Replace <tar file> with respective file names from the list.
Important: Extract all TAR files into the same installation directory.
3. Central Server only: Download the tar files for the following Business Process
Manager part numbers:
CIL73ML
CIL74ML
CIL75ML
Copy the following files to the install_images/bpm directory:
BPM_Std_V85_Linux_x86_1_of_3.tar.gz
BPM_Std_V85_Linux_x86_2_of_3.tar.gz
BPM_Std_V85_Linux_x86_3_of_3.tar.gz
Do not extract the contents of the tar.gz files.
Preparing the installation based on DVD images
To install SmartCloud Orchestrator from DVDs, you must first prepare the images.
Note: These images must be copied to Central Server 1 and to each Region server
that is being installed.
Procedure
1. Copy the following TAR files from the DVDs to one directory:
For SmartCloud Orchestrator V2.3, copy the files from the following DVDs:
IBM SmartCloud Orchestrator V2.3.0
IBM SmartCloud Provisioning V2.3.0 Base 1 of 3 for Linux RHEL
IBM SmartCloud Provisioning V2.3.0 Base 2 of 3 for Linux RHEL
IBM SmartCloud Provisioning V2.3.0 Base 3 of 3 for Linux RHEL
For SmartCloud Orchestrator V2.3, Fix Pack 1, copy the files from the
following DVDs:
IBM SmartCloud Orchestrator V2.3.0.1 for Multiplatform
IBM SmartCloud Provisioning V2.3.0.1 Base 1 of 4 for Linux RHEL
IBM SmartCloud Provisioning V2.3.0.1 Base 2 of 4 for Linux RHEL
IBM SmartCloud Provisioning V2.3.0.1 Base 3 of 4 for Linux RHEL
IBM SmartCloud Provisioning V2.3.0.1 Base 4 of 4 for Linux RHEL
For SmartCloud Orchestrator Enterprise V2.3, copy the files from the
following DVDs:
IBM SmartCloud Orchestrator Enterprise V2.3.0
IBM SmartCloud Provisioning V2.3.0 Base 1 of 3 for Linux RHEL
IBM SmartCloud Provisioning V2.3.0 Base 2 of 3 for Linux RHEL
IBM SmartCloud Provisioning V2.3.0 Base 3 of 3 for Linux RHEL
22 IBM SmartCloud Orchestrator 2.3: User's Guide
2. Use the following command to extract the content of the TAR files into the
installation directory of your choice. In this example of installation, the
directory is called /install_images:
tar xvf <tar file>
Replace <tar file> with respective file names from the list.
Important: Extract all TAR files into the same installation directory.
3. Central Server only: For Business Process Manager, copy the files from the
following DVDs into the install_images/bpm directory:
IBM Business Process Manager Standard V8.5 for Linux 32bit/64bit (1 of 3)
[BPM_Std_V85_Linux_x86_1_of_3.tar.gz]
IBM Business Process Manager Standard V8.5 for Linux 32bit/64bit (2 of 3)
[BPM_Std_V85_Linux_x86_2_of_3.tar.gz]
IBM Business Process Manager Standard V8.5 for Linux 32bit/64bit (3 of 3)
[BPM_Std_V85_Linux_x86_3_of_3.tar.gz]
Do not extract the contents of the tar.gz files.
Installing the central server
The central server represents the set of machines where the core SmartCloud
Orchestrator components are running, and are grouped into four virtual machines.
Before you begin
Before you start this installation procedure, make sure that you have completed the
preparation steps required for each of the central server virtual systems. For more
information, see Preparing the central server and the region server on page 17.
When you start the installation of the Central Server 1, the virtual machines for all
the other Central Servers must be up and running and must be accessible.
About this task
The following virtual machines are components of the central server:
Central Server 1
DB2 plus tooling (yum, chef) for installing components on the other central
servers
Central Server 2
IaaS Gateway, Public Cloud Gateway, Keystone, and Virtual Image Library
Central Server 3
Workload Deployer and SmartCloud UI
Central Server 4
Business Process Manager
Procedure
1. Log on to Central Server 1.
2. Make sure that the software on Central Server 1 meets the software
prerequisites. See Software prerequisites on page 15.
3. Prepare the installation media on Central Server 1. See Preparing the
installation media on page 21.
Chapter 2. Installing 23
4. If you are a SmartCloud Orchestrator Enterprise customer, copy swtag to
SmartCloud_Orchestrator-2.3.0.swtag by executing the following command:
cp /install_images/iwd/SmartCloud_Orchestrator_Enterprise-2.3.0.swtag /install_images/iwd/SmartCloud_Orchestrator-2.3.0.swtag
5. Edit the file central-server.cfg in folder /install_images/installer.
6. Customize the file so that it reflects your environment setup. The table below
describes the required parameters that you must customize:
Table 8. Compulsory attributes
Configuration Parameter = default value Description
iso_location=/opt/RHEL6.3-20120613.2-
Server-x86_64-DVD1.iso
Location of the Red Hat Enterprise Linux
Server 6 DVD ISO file
dns_suffix=example.com How to define dns_suffix:
v If you choose to use SmartCloud
Orchestrator built-in DNS, define a
domain name for your cloud.
v If you choose to use SmartCloud
Orchestrator built-in DNS with corporate
DNS as the parent DNS, define a sub
domain name for your cloud. For
example, if your company domain name
is company.com, then the sub domain is
cloud.company.com.
v If you choose to use corporate DNS with
no SmartCloud Orchestrator built-in DNS,
make sure that dns_suffix="", and make
sure that the entries which were
configured in step 6 of Preparing the
central server and the region server on
page 17 are correctly resolved on each
central server and region server.
management_network_device=eth0 This option works with the
central_server_ips of the following row,
which means that central_server_ips must be
the same network of this NIC's IP address
central_server_ips=
10.10.10.10,10.10.10.11,10.10.10.12
The IP addresses for Central Server 2,
Central Server 3 and Central Server 4 must
be in the same network with Central Server
1. The FQDN is used for single sign on if
these IP addresses can be resolved from
upstream DNS, so /etc/resolv.conf
hbase-disk=/dev/sdb Specify the name of the 5GB disk you
attached to central server 2 machine as
described in the hardware requirement for
central server 2. The disk is used by Virtual
Image Library to deploy HBase.
central_server_domain_names=central-
server-1,central-server-2,central-
server-3,central-server-4
The hostname of the central servers used to
register into SmartCloud Orchestrator DNS.
Used for Single Sign On only when
central_server_ips cannot be resolved.
7. To install Central Server, run the following command on Central Server 1 (this
command will install also the other central servers):
/install_images/installer/deploy_central_server.sh [-h] [-a]
[-p <os-root-password>] [-P <smartcloud-password>]
where:
24 IBM SmartCloud Orchestrator 2.3: User's Guide
-h Shows usage.
-a Accepts license by default.
-p <os-root-password>
Defines the password of the root user on all central servers. Assign the
same password to all your central servers. This parameter is optional
and, if not indicated it, the command prompts you for it.
-P <smartcloud-password>
Defines the password of the SmartCloud user admin. This parameter is
optional and, if not indicated it, the command prompts you for it.
Important: The password can only contain 0-9,a-z,A-Z, special
characters (for example: -/* @ # ) are not allowed.
Note: It is not supported to rerun deploy_central_server.sh in case of
any installation failures. The Central Server images must either be
recreated or reverted to the previous snapshot.
Note: The install process uses SmartCloud user admin as the OpenStack
administrative user and the OpenStack service users. It is used in the internal
communication between different subcomponents, and used to log into
SmartCloud services, Workload Deployer, and Virtual Image Library. A domain
with domain name Default is generated automatically, and is used to log into
SmartCloud services, Workload Deployer, and Virtual Image Library.
Note: The Central Server IP addresses can only be configured before running
deploy_central_server.sh. Otherwise, the reconfiguration of Central Server IP
addresses will have a high risk to break the existing SmartCloud Orchestrator
environment.
8. Important: If you are a SmartCloud Orchestrator Enterprise customer, login to
Central Server 3 and rename the SmartCloud_Orchestrator-2.3.0.swtag file by
executing the following command:
cd /opt/ibm/SmartCloud_Orchestrator/properties/version/
mv SmartCloud_Orchestrator-2.3.0.swtag SmartCloud_Orchestrator_Enterprise-2.3.0.swtag
Results
You can find the installation logs in /var/log/smartcloud/.
What to do next
After all central servers are successfully installed, add the region server to the
environment. See Installing the region server on page 26. If you want to reboot
the central servers before you install the region server, refer to Shutting down or
starting Central Servers and Region Servers on page 62.
Chapter 2. Installing 25
Installing the region server
A region server represents the component needed to communicate with a specific
hypervisor management infrastructure, including KVM, VMware, or Power.
Before you begin
A SmartCloud Orchestrator environment requires at least one region server
installed, however, additional region servers can be successively installed and can
point to any of the supported hypervisor management infrastructures.
The components representing a region server are installed on a single virtual
machine and are:
v OpenStack
v DB2 (optional, it is installed only if you want this region server use its own
DB2)
v SmartCloud Entry driver (optional, it is installed only on VMware and Power
regions)
v yum
v chef
v PXE (optional, it is installed only for KVM region servers so that additional
KVM compute nodes can be installed)
Before you start this installation procedure, complete the following steps:
1. Complete the preparation steps required for the region server virtual machine.
See Preparing the central server and the region server on page 17.
2. The DB2 in the region server is used to store the OpenStack data. You can have
a single DB2 shared between the central servers and the region servers. It is
suggested to have a separate DB2 for improving the performance especially in
production environments or in the environments where the region servers are
geographically dispersed.
Decide whether this region server uses its own DB2 or shares the central server
DB2. If you want this region to use its own DB2, skip this step and proceed to
the next section. If you want this region server to share the same DB2 used by
the central server, an authorized central server DB2 administrator must run a
command provided by the installation to prepare the DB2 to be used by this
region sever:
a. Log on to Central Server-1 and locate the /install_images/installer/
directory.
b. Run the command:
/install_images/installer/deploy create-region-db --region_name <region-name>
where:
--region_name <region-name>
Defines the name representing this region and that you later use as
input for the region server installation procedure. This parameter is
required.
26 IBM SmartCloud Orchestrator 2.3: User's Guide
About this task
The installation procedure can be repeated as is for each additional region server to
install. The procedure refers to the region server virtual machine as Region
server-n.
Procedure
1. Log on to the Region Server-n machine.
2. Make sure that the software on Region Server meets the software prerequisites
described in Software prerequisites on page 15.
3. Prepare the installation media on Region Server-n. See Preparing the
installation media on page 21.
4. Edit the file region-server.cfg in folder /install_images/installer.
Customize the file to reflect your environment setup. The following table
describes the required parameters that you must customize:
Table 9. Compulsory configurations
Configuration Parameter = default value Description
iso_location=/opt/RHEL6.3-20120613.2-
Server-x86_64-DVD1.iso
The location of the Red Hat Enterprise
Linux Server 6 DVD ISO file.
management_network_device=eth0 The management NIC device name. If your
machine has multiple NICs, the parameter
specifies which NIC is used to as the
manage from network.
vm_ip_range=10.10.10.100-10.10.10.200 IP address range for provisioned virtual
machines.
Restriction: the vm_ip_range must match the
subnet for the PowerVM network (network
where the VIOS's reside on). It must be in
the same subnet with the region server, and
in the same network of the compute node.
vm_ip_netmask=255.255.255.0 Netmask of the vm_ip_range.
vm_gateway=10.10.10.0 The gateway address for provisioned virtual
machines.
share_central_db=no Specify no if the region server uses its own
DB2. Specify yes if the region must share the
same DB2 of the central server.
Note: If you specify yes, make sure that you
have completed Step 2 in the section Before
you begin.
region_type=kvm Region type that you want to deploy to
configure the product to an hypervisor
management infrastructure for that type.
The value can be KVM, VMware, or Power.
If VMware or Power is specified, further
connection configuration parameters are
required for the relative virtual environment.
Chapter 2. Installing 27
Table 9. Compulsory configurations (continued)
Configuration Parameter = default value Description
region_name=RegionOne Region name that you want to use to deploy,
it will be also used as the prefix of the
domain name for the DNS that will be
deployed on the region server when you
choose the build-in DNS or build-in DNS
with the cooperate DNS as the parent DNS
mode.
Note: The region name only use
0-9,a-z,A-Z and it cannot contain special
characters (for example: -/*).
Note: If you specified yes for the
share_central_db option, make sure that
you use a region name that matches the one
you used as input to the command in Step 2
in the Before you begin section.
vcenter_host=""
vcenter_username=""
vcenter_network="""
vcenter_port="443"
The configuration of your vCenter. Only
effective if region_type=vmware.
vcenter_host:
The host name or IP address of
vCenter, for
example:"172.16.102.200".
vcenter_username:
The user name of the administrator
of vCenter, for
example:"Administrator".
Note: SmartCloud Orchestrator
does not support Domain User
Account for vCenter.
vcenter_network:
The network name defined in
vCenter, for example:"VM
Network".
Note: The vcenter_network
parameter is used for the virtual
machine and it is not used to
configure the region server. The
requirement for this network is that
it must be accessible from the
region server. The network
requirement of the region server
depends on the requirement and
network topology of your
environment. To simplify the
topology, you can use the same port
group (network) as the virtual
machine which is defined by the
vcenter_network parameter. If you
use a different port group, make
sure that those two port groups
(network) are accessible.
vcenter_port:
The port to connect to vCenter
(defaults: 443).
28 IBM SmartCloud Orchestrator 2.3: User's Guide
Table 9. Compulsory configurations (continued)
Configuration Parameter = default value Description
vmcontrol_host=""
vmcontrol_username=""
vmcontrol_network=""
vmcontrol_port="8422"
The configuration of your VMControl. Only
applicable if region_type=power.
vmcontrol_host:
The host name or IP address of
VMControl, for
example:"172.16.102.210".
vmcontrol_username:
The user name of the administrator
of VMControl, for example: "root".
vmcontrol_network:
The network name defined in
VMControl, for example:
"Discovered/1/0/ETHERNET0". It
will be used for provisioned virtual
machines.
vmcontrol_port:
The port to connect to VMControl
(defaults: 8422).
Note: The parameter vmcontrol_network is
combined with two VMControl discovered
network device names:
v From the Systems Director Network
Management or Network Control "Logical
Networks" view, select the network name
planned for SmartCloud Orchestrator
instances, like Discovered/1/0.
v To determine the switch device name for
the network, select "Power Systems
Management" from the System Director,
then "X Power Systems Hosts (Physical
Servers)" where "X" is indicating a number
of Power systems hosts, go into the target
host link. You will see a device like
ETHERNET0-IBM*8205-E6D*068840T with a
type of Switch in its properties. Then
ETHERNET0 would be device name of the
network.
So the full vmcontrol_network is the "Logical
Networks" + "/" + switch device name, here
is Discovered/1/0/ETHERNET0
5. If the region server shares a database with the central server, make sure that
the configuration is share_central_db=yes and that you have completed Step 2
in the section Before you begin.
6. Install the Region Server by running the following command on Region
Server-n:
/install_images/installer/deploy_region_server.sh [-h] [-a]
[-p <os-root-password>] -C <central-server-1-ip-address>
[-P <vcenter/vmcontrol-password>]
where:
-h Shows usage
Chapter 2. Installing 29
-a Accepts license by default
-p <os-root-password>
Defines the root password of the Region Server. This parameter is
optional. If it is not indicated here, the command will prompt you for
it.
-C <central-server-1-ip-address>
Defines the IP address of Central Server 1. This parameter is required.
-P <vcenter/vmcontrol-password>
Defines the password of the user name that you specified for your
vCenter or VMControl. This parameter is optional and it applies only
when you are not deploying a KVM region server. If it is not indicated
here, the command will prompt you for it.
Note: In case of any issues, the region can be removed and added again. For
details, refer to Removing a region on page 75.
Results
You can find the installation logs in /var/log/smartcloud/.
What to do next
After one region server has been setup:
v If the region type is VMware or Power, a SmartCloud Orchestrator with the
specific region was setup successfully. If multiple region are required, see
Installing a multiple-region environment on page 47, otherwise see Verifying
the installation on page 47.
v If the region type is KVM , you need add an extra machine to set up the
hypervisor, see Installing a compute node on page 44.
Note: For subsequent KVM compute nodes on the same subnet as the first
compute node, a new region server is not required, as the existing region server
can be reused. See Installing a compute node on page 44.
List of the RPM packages added during installation
This topic provides the list of the RPM packages that are added during the
installation of the Central Servers and Region Servers.
RPM packages added during the installation of Central Server 1
> apr-1.3.9-5.el6_2.x86_64
> apr-util-1.3.9-3.el6_0.1.x86_64
> apr-util-ldap-1.3.9-3.el6_0.1.x86_64
> audit-libs-2.2-2.el6.i686
> bind-9.8.2-0.17.rc1.el6.x86_64
> cloog-ppl-0.15.7-1.2.el6.x86_64
> compat-libstdc++-296-2.96-144.el6.i686
> compat-libstdc++-33-3.2.3-69.el6.i686
> compat-libstdc++-33-3.2.3-69.el6.x86_64
> compat-readline5-5.2-17.1.el6.x86_64
> cpp-4.4.7-3.el6.x86_64
> cracklib-2.8.16-4.el6.i686
> createrepo-0.9.9-17.el6.noarch
> dapl-2.0.34-1.el6.x86_64
> db4-4.7.25-17.el6.i686
> deltarpm-3.5-0.5.20090913git.el6.x86_64
30 IBM SmartCloud Orchestrator 2.3: User's Guide
> dhcp-4.1.1-34.P1.el6.x86_64
> ebtables-2.0.9-6.el6.x86_64
> gcc-4.4.7-3.el6.x86_64
> gcc-c++-4.4.7-3.el6.x86_64
> glibc-2.12-1.107.el6.i686
> glibc-devel-2.12-1.107.el6.x86_64
> glibc-headers-2.12-1.107.el6.x86_64
> httpd-2.2.15-26.el6.x86_64
> httpd-tools-2.2.15-26.el6.x86_64
> ibm-java-x86_64-sdk-6.0-10.0.x86_64
> jss-4.2.6-24.el6.x86_64
> kernel-headers-2.6.32-358.el6.x86_64
> ksh-20100621-19.el6.x86_64
> libgcc-4.4.7-3.el6.i686
> libibverbs-1.1.6-5.el6.x86_64
> librdmacm-1.0.17-0.git4b5c1aa.el6.x86_64
> libselinux-2.0.94-5.3.el6.i686
> libstdc++-4.4.7-3.el6.i686
> libstdc++-devel-4.4.7-3.el6.x86_64
> mpfr-2.4.1-6.el6.x86_64
> nss-softokn-freebl-3.12.9-11.el6.i686
> pam-1.1.1-13.el6.i686
> ppl-0.10.2-11.el6.x86_64
> python-deltarpm-3.5-0.5.20090913git.el6.x86_64
> rsct.64bit-3.1.4.4-13032.x86_64
> rsct.basic-3.1.4.4-13032.i386
> rsct.basic.msg.de_DE-3.1.1.2-11266.i386
> [email protected]
> rsct.basic.msg.de_DE.ISO-8859-1-3.1.1.2-11266.i386
> rsct.basic.msg.de_DE.UTF-8-3.1.1.2-11266.i386
> rsct.basic.msg.es_ES-3.1.1.2-11266.i386
> [email protected]
> rsct.basic.msg.es_ES.ISO-8859-1-3.1.1.2-11266.i386
> rsct.basic.msg.es_ES.UTF-8-3.1.1.2-11266.i386
> rsct.basic.msg.fr_FR-3.1.1.2-11266.i386
> [email protected]
> rsct.basic.msg.fr_FR.ISO-8859-1-3.1.1.2-11266.i386
> rsct.basic.msg.fr_FR.UTF-8-3.1.1.2-11266.i386
> rsct.basic.msg.it_IT-3.1.1.2-11266.i386
> [email protected]
> rsct.basic.msg.it_IT.ISO-8859-1-3.1.1.2-11266.i386
> rsct.basic.msg.it_IT.UTF-8-3.1.1.2-11266.i386
> rsct.basic.msg.ja_JP.eucJP-3.1.1.2-11266.i386
> rsct.basic.msg.ja_JP.UTF-8-3.1.1.2-11266.i386
> rsct.basic.msg.ko_KR.eucKR-3.1.1.2-11266.i386
> rsct.basic.msg.ko_KR.UTF-8-3.1.1.2-11266.i386
> rsct.basic.msg.pt_BR-3.1.1.2-11266.i386
> rsct.basic.msg.pt_BR.UTF-8-3.1.1.2-11266.i386
> rsct.basic.msg.zh_CN.GB18030-3.1.1.2-11266.i386
> rsct.basic.msg.zh_CN.GB2312-3.1.1.2-11266.i386
> rsct.basic.msg.zh_CN.GBK-3.1.1.2-11266.i386
> rsct.basic.msg.zh_CN.UTF-8-3.1.1.2-11266.i386
> rsct.basic.msg.zh_TW-3.1.1.2-11266.i386
> rsct.basic.msg.zh_TW.Big5-3.1.1.2-11266.i386
> rsct.basic.msg.zh_TW.eucTW-3.1.1.2-11266.i386
> rsct.basic.msg.zh_TW.UTF-8-3.1.1.2-11266.i386
> rsct.core-3.1.4.4-13032.i386
> rsct.core.msg.de_DE-3.1.1.2-11266.i386
> [email protected]
> rsct.core.msg.de_DE.ISO-8859-1-3.1.1.2-11266.i386
> rsct.core.msg.de_DE.UTF-8-3.1.1.2-11266.i386
> rsct.core.msg.es_ES-3.1.1.2-11266.i386
> [email protected]
> rsct.core.msg.es_ES.ISO-8859-1-3.1.1.2-11266.i386
> rsct.core.msg.es_ES.UTF-8-3.1.1.2-11266.i386
> rsct.core.msg.fr_FR-3.1.1.2-11266.i386
> [email protected]
Chapter 2. Installing 31
> rsct.core.msg.fr_FR.ISO-8859-1-3.1.1.2-11266.i386
> rsct.core.msg.fr_FR.UTF-8-3.1.1.2-11266.i386
> rsct.core.msg.it_IT-3.1.1.2-11266.i386
> [email protected]
> rsct.core.msg.it_IT.ISO-8859-1-3.1.1.2-11266.i386
> rsct.core.msg.it_IT.UTF-8-3.1.1.2-11266.i386
> rsct.core.msg.ja_JP.eucJP-3.1.1.2-11266.i386
> rsct.core.msg.ja_JP.UTF-8-3.1.1.2-11266.i386
> rsct.core.msg.ko_KR.eucKR-3.1.1.2-11266.i386
> rsct.core.msg.ko_KR.UTF-8-3.1.1.2-11266.i386
> rsct.core.msg.pt_BR-3.1.1.2-11266.i386
> rsct.core.msg.pt_BR.UTF-8-3.1.1.2-11266.i386
> rsct.core.msg.zh_CN.GB18030-3.1.1.2-11266.i386
> rsct.core.msg.zh_CN.GB2312-3.1.1.2-11266.i386
> rsct.core.msg.zh_CN.GBK-3.1.1.2-11266.i386
> rsct.core.msg.zh_CN.UTF-8-3.1.1.2-11266.i386
> rsct.core.msg.zh_TW-3.1.1.2-11266.i386
> rsct.core.msg.zh_TW.Big5-3.1.1.2-11266.i386
> rsct.core.msg.zh_TW.eucTW-3.1.1.2-11266.i386
> rsct.core.msg.zh_TW.UTF-8-3.1.1.2-11266.i386
> rsct.core.utils-3.1.4.4-13032.i386
> rsct.core.utils.msg.de_DE-3.1.1.2-11266.i386
> [email protected]
> rsct.core.utils.msg.de_DE.ISO-8859-1-3.1.1.2-11266.i386
> rsct.core.utils.msg.de_DE.UTF-8-3.1.1.2-11266.i386
> rsct.core.utils.msg.es_ES-3.1.1.2-11266.i386
> [email protected]
> rsct.core.utils.msg.es_ES.ISO-8859-1-3.1.1.2-11266.i386
> rsct.core.utils.msg.es_ES.UTF-8-3.1.1.2-11266.i386
> rsct.core.utils.msg.fr_FR-3.1.1.2-11266.i386
> [email protected]
> rsct.core.utils.msg.fr_FR.ISO-8859-1-3.1.1.2-11266.i386
> rsct.core.utils.msg.fr_FR.UTF-8-3.1.1.2-11266.i386
> rsct.core.utils.msg.it_IT-3.1.1.2-11266.i386
> [email protected]
> rsct.core.utils.msg.it_IT.ISO-8859-1-3.1.1.2-11266.i386
> rsct.core.utils.msg.it_IT.UTF-8-3.1.1.2-11266.i386
> rsct.core.utils.msg.ja_JP.eucJP-3.1.1.2-11266.i386
> rsct.core.utils.msg.ja_JP.UTF-8-3.1.1.2-11266.i386
> rsct.core.utils.msg.ko_KR.eucKR-3.1.1.2-11266.i386
> rsct.core.utils.msg.ko_KR.UTF-8-3.1.1.2-11266.i386
> rsct.core.utils.msg.pt_BR-3.1.1.2-11266.i386
> rsct.core.utils.msg.pt_BR.UTF-8-3.1.1.2-11266.i386
> rsct.core.utils.msg.zh_CN.GB18030-3.1.1.2-11266.i386
> rsct.core.utils.msg.zh_CN.GB2312-3.1.1.2-11266.i386
> rsct.core.utils.msg.zh_CN.GBK-3.1.1.2-11266.i386
> rsct.core.utils.msg.zh_CN.UTF-8-3.1.1.2-11266.i386
> rsct.core.utils.msg.zh_TW-3.1.1.2-11266.i386
> rsct.core.utils.msg.zh_TW.Big5-3.1.1.2-11266.i386
> rsct.core.utils.msg.zh_TW.eucTW-3.1.1.2-11266.i386
> rsct.core.utils.msg.zh_TW.UTF-8-3.1.1.2-11266.i386
> rsct.opt.stackdump-3.1.4.4-13032.i386
> rsct.opt.storagerm-3.1.4.4-13032.i386
> ruby-1.8.7.352-7.el6_2.x86_64
> ruby-devel-1.8.7.352-7.el6_2.x86_64
> rubygems-1.3.7-1.el6.noarch
> ruby-irb-1.8.7.352-7.el6_2.x86_64
> ruby-libs-1.8.7.352-7.el6_2.x86_64
> ruby-rdoc-1.8.7.352-7.el6_2.x86_64
> sam-3.2.2.5-13129.i386
> sam.adapter-3.2.2.5-13129.i386
> sam.msg.de_DE-3.2.2.4-0.i386
> [email protected]
> sam.msg.de_DE.ISO-8859-1-3.2.2.4-0.i386
> sam.msg.de_DE.UTF-8-3.2.2.4-0.i386
> sam.msg.es_ES-3.2.2.4-0.i386
> [email protected]
32 IBM SmartCloud Orchestrator 2.3: User's Guide
> sam.msg.es_ES.ISO-8859-1-3.2.2.4-0.i386
> sam.msg.es_ES.UTF-8-3.2.2.4-0.i386
> sam.msg.fr_FR-3.2.2.4-0.i386
> [email protected]
> sam.msg.fr_FR.ISO-8859-1-3.2.2.4-0.i386
> sam.msg.fr_FR.UTF-8-3.2.2.4-0.i386
> sam.msg.it_IT-3.2.2.4-0.i386
> [email protected]
> sam.msg.it_IT.ISO-8859-1-3.2.2.4-0.i386
> sam.msg.it_IT.UTF-8-3.2.2.4-0.i386
> sam.msg.ja_JP.eucJP-3.2.2.4-0.i386
> sam.msg.ja_JP.UTF-8-3.2.2.4-0.i386
> sam.msg.ko_KR.eucKR-3.2.2.4-0.i386
> sam.msg.ko_KR.UTF-8-3.2.2.4-0.i386
> sam.msg.pt_BR-3.2.2.4-0.i386
> sam.msg.pt_BR.UTF-8-3.2.2.4-0.i386
> sam.msg.zh_CN.GB18030-3.2.2.4-0.i386
> sam.msg.zh_CN.GB2312-3.2.2.4-0.i386
> sam.msg.zh_CN.GBK-3.2.2.4-0.i386
> sam.msg.zh_CN.UTF-8-3.2.2.4-0.i386
> sam.msg.zh_TW-3.2.2.4-0.i386
> sam.msg.zh_TW.Big5-3.2.2.4-0.i386
> sam.msg.zh_TW.eucTW-3.2.2.4-0.i386
> sam.msg.zh_TW.UTF-8-3.2.2.4-0.i386
> sam.policies.one-3.2.2.5-13129.i386
> sam.policies.two-3.2.2.5-13129.i386
> sam.sappolicy-3.2.2.5-13129.i386
> scp-chef_repo_srv-2.2.0.0-201311090045.noarch
> scp-cookbooks-2.3.0.0-B20131109005700.noarch
> sg3_utils-1.28-4.el6.x86_64
> src-3.1.4.4-13032.i386
> src.msg.de_DE-1.3.1.1-11266.i386
> [email protected]
> src.msg.de_DE.ISO-8859-1-1.3.1.1-11266.i386
> src.msg.de_DE.UTF-8-1.3.1.1-11266.i386
> src.msg.es_ES-1.3.1.1-11266.i386
> [email protected]
> src.msg.es_ES.ISO-8859-1-1.3.1.1-11266.i386
> src.msg.es_ES.UTF-8-1.3.1.1-11266.i386
> src.msg.fr_FR-1.3.1.1-11266.i386
> [email protected]
> src.msg.fr_FR.ISO-8859-1-1.3.1.1-11266.i386
> src.msg.fr_FR.UTF-8-1.3.1.1-11266.i386
> src.msg.it_IT-1.3.1.1-11266.i386
> [email protected]
> src.msg.it_IT.ISO-8859-1-1.3.1.1-11266.i386
> src.msg.it_IT.UTF-8-1.3.1.1-11266.i386
> src.msg.ja_JP.eucJP-1.3.1.1-11266.i386
> src.msg.ja_JP.UTF-8-1.3.1.1-11266.i386
> src.msg.ko_KR.eucKR-1.3.1.1-11266.i386
> src.msg.ko_KR.UTF-8-1.3.1.1-11266.i386
> src.msg.pt_BR-1.3.1.1-11266.i386
> src.msg.pt_BR.UTF-8-1.3.1.1-11266.i386
> src.msg.zh_CN.GB18030-1.3.1.1-11266.i386
> src.msg.zh_CN.GB2312-1.3.1.1-11266.i386
> src.msg.zh_CN.GBK-1.3.1.1-11266.i386
> src.msg.zh_CN.UTF-8-1.3.1.1-11266.i386
> src.msg.zh_TW-1.3.1.1-11266.i386
> src.msg.zh_TW.Big5-1.3.1.1-11266.i386
> src.msg.zh_TW.eucTW-1.3.1.1-11266.i386
> src.msg.zh_TW.UTF-8-1.3.1.1-11266.i386
> tunctl-1.5-3.el6.x86_64
Chapter 2. Installing 33
RPM packages added during the installation of Central Server 2
> atk-1.28.0-2.el6.i686
> audit-libs-2.2-2.el6.i686
> augeas-libs-0.9.0-4.el6.x86_64
> avahi-libs-0.6.25-12.el6.i686
> axis-1.2.1-7.2.el6.noarch
> bcel-5.2-7.2.el6.x86_64
> boost-1.47.0-7.ibm.x86_64
> boost-chrono-1.47.0-7.ibm.x86_64
> boost-date-time-1.47.0-7.ibm.x86_64
> boost-filesystem-1.47.0-7.ibm.x86_64
> boost-graph-1.47.0-7.ibm.x86_64
> boost-iostreams-1.47.0-7.ibm.x86_64
> boost-program-options-1.47.0-7.ibm.x86_64
> boost-python-1.47.0-7.ibm.x86_64
> boost-random-1.47.0-7.ibm.x86_64
> boost-regex-1.47.0-7.ibm.x86_64
> boost-serialization-1.47.0-7.ibm.x86_64
> boost-signals-1.47.0-7.ibm.x86_64
> boost-system-1.47.0-7.ibm.x86_64
> boost-test-1.47.0-7.ibm.x86_64
> boost-thread-1.47.0-7.ibm.x86_64
> boost-wave-1.47.0-7.ibm.x86_64
> btrfs-progs-0.20-0.2.git91d9eec.el6.x86_64
> bzip2-devel-1.0.5-7.el6_0.x86_64
> bzip2-libs-1.0.5-7.el6_0.i686
> cairo-1.8.8-3.1.el6.i686
> celt051-0.5.1.3-0.el6.x86_64
> classpathx-jaf-1.0-15.4.el6.x86_64
> classpathx-mail-1.1.1-9.4.el6.noarch
> cloog-ppl-0.15.7-1.2.el6.x86_64
> compat-db42-4.2.52-15.el6.i686
> compat-db42-4.2.52-15.el6.x86_64
> compat-db43-4.3.29-15.el6.i686
> compat-db43-4.3.29-15.el6.x86_64
> compat-db-4.6.21-15.el6.i686
> compat-db-4.6.21-15.el6.x86_64
> compat-libstdc++-33-3.2.3-69.el6.i686
> compat-libstdc++-33-3.2.3-69.el6.x86_64
> compat-readline5-5.2-17.1.el6.x86_64
> cpp-4.4.7-3.el6.x86_64
> cracklib-2.8.16-4.el6.i686
> cups-libs-1.4.2-48.el6_3.3.i686
> cyrus-sasl-md5-2.1.23-13.el6_3.1.x86_64
> db4-4.7.25-17.el6.i686
> dbus-libs-1.2.24-7.el6_3.i686
> dos2unix-3.1-37.el6.x86_64
> ebtables-2.0.9-6.el6.x86_64
> ecj-3.4.2-6.el6.x86_64
> elfutils-libelf-0.152-1.el6.i686
> elfutils-libs-0.152-1.el6.i686
> expat-2.0.1-11.el6_2.i686
> febootstrap-supermin-helper-3.12-2.el6.x86_64
> fontconfig-2.8.0-3.el6.i686
> freetype-2.3.11-6.el6_2.9.i686
> fuse-2.8.3-4.el6.x86_64
> fuse-libs-2.8.3-4.el6.x86_64
> gamin-0.1.10-9.el6.i686
> gcc-4.4.7-3.el6.x86_64
> gcc-c++-4.4.7-3.el6.x86_64
> genisoimage-1.1.9-12.el6.x86_64
> glib2-2.22.5-7.el6.i686
> glibc-2.12-1.107.el6.i686
> glibc-devel-2.12-1.107.el6.x86_64
> glibc-headers-2.12-1.107.el6.x86_64
> gnutls-2.8.5-10.el6.i686
> gnutls-utils-2.8.5-10.el6.x86_64
34 IBM SmartCloud Orchestrator 2.3: User's Guide
> gpxe-roms-qemu-0.9.7-6.9.el6.noarch
> gtk2-2.18.9-12.el6.i686
> gtk2-engines-2.18.4-5.el6.i686
> gtk2-engines-2.18.4-5.el6.x86_64
> hivex-1.3.3-4.2.el6.x86_64
> iaasgateway-2013.1-1.1.1.ibm.201310312301.noarch
> ibm-java-x86_64-sdk-6.0-10.0.x86_64
> ibm-simpletoken-authenticator-middleware-2013.1.4-201310161128.ibm.noarch
> iscsi-initiator-utils-6.2.0.873-2.el6.x86_64
> jakarta-commons-collections-3.2.1-3.4.el6.noarch
> jakarta-commons-daemon-1.0.1-8.9.el6.x86_64
> jakarta-commons-dbcp-1.2.1-13.8.el6.noarch
> jakarta-commons-discovery-0.4-5.4.el6.noarch
> jakarta-commons-httpclient-3.1-0.6.el6.x86_64
> jakarta-commons-logging-1.0.4-10.el6.noarch
> jakarta-commons-pool-1.3-12.7.el6.x86_64
> jasper-libs-1.900.1-15.el6_1.1.i686
> java-1.5.0-gcj-1.5.0.0-29.1.el6.x86_64
> java_cup-0.10k-5.el6.x86_64
> kernel-headers-2.6.32-358.el6.x86_64
> keyutils-libs-1.4-4.el6.i686
> keyutils-libs-devel-1.4-4.el6.x86_64
> krb5-devel-1.10.3-10.el6.x86_64
> krb5-libs-1.10.3-10.el6.i686
> ksh-20100621-19.el6.x86_64
> libart_lgpl-2.3.20-5.1.el6.x86_64
> libcom_err-1.41.12-14.el6.i686
> libcom_err-devel-1.41.12-14.el6.x86_64
> libconfig-1.3.2-1.1.el6.x86_64
> libgcc-4.4.7-3.el6.i686
> libgcj-4.4.7-3.el6.x86_64
> libgcrypt-1.4.5-9.el6_2.2.i686
> libgcrypt-devel-1.4.5-9.el6_2.2.x86_64
> libgpg-error-1.7-4.el6.i686
> libgpg-error-devel-1.7-4.el6.x86_64
> libguestfs-1.16.34-2.el6.x86_64
> libguestfs-tools-1.16.34-2.el6.x86_64
> libguestfs-tools-c-1.16.34-2.el6.x86_64
> libguestfs-winsupport-1.0-7.el6.x86_64
> libICE-1.0.6-1.el6.i686
> libicu-4.2.1-9.1.el6_2.x86_64
> libjpeg-turbo-1.2.1-1.el6.i686
> libpng-1.2.49-1.el6_2.i686
> libselinux-2.0.94-5.3.el6.i686
> libselinux-devel-2.0.94-5.3.el6.x86_64
> libsepol-devel-2.0.41-4.el6.x86_64
> libSM-1.2.1-2.el6.i686
> libstdc++-4.4.7-3.el6.i686
> libstdc++-devel-4.4.7-3.el6.x86_64
> libtasn1-2.3-3.el6_2.1.i686
> libthai-0.1.12-3.el6.i686
> libtiff-3.9.4-9.el6_3.i686
> libuuid-2.17.2-12.9.el6.i686
> libvirt-client-0.10.2-18.el6.x86_64
> libX11-1.5.0-4.el6.i686
> libXau-1.0.6-4.el6.i686
> libxcb-1.8.1-1.el6.i686
> libXcomposite-0.4.3-4.el6.i686
> libXcursor-1.1.13-2.el6.i686
> libXdamage-1.1.3-4.el6.i686
> libXext-1.3.1-2.el6.i686
> libXfixes-5.0-3.el6.i686
> libXft-2.3.1-2.el6.i686
> libXi-1.6.1-3.el6.i686
> libXinerama-1.1.2-2.el6.i686
> libXmu-1.1.1-2.el6.i686
> libXmu-1.1.1-2.el6.x86_64
Chapter 2. Installing 35
> libXp-1.0.0-15.1.el6.i686
> libXp-1.0.0-15.1.el6.x86_64
> libXrandr-1.4.0-1.el6.i686
> libXrender-0.9.7-2.el6.i686
> libXt-1.1.3-1.el6.i686
> libXtst-1.2.1-2.el6.i686
> log4j-1.2.14-6.4.el6.x86_64
> lzo-2.03-3.1.el6.x86_64
> lzop-1.02-0.9.rc1.el6.x86_64
> memcached-1.4.4-3.el6.x86_64
> mpfr-2.4.1-6.el6.x86_64
> mx4j-3.0.1-9.13.el6.noarch
> MySQL-python-1.2.3-0.3.c1.1.el6.x86_64
> nc-1.84-22.el6.x86_64
> ncurses-devel-5.7-3.20090208.el6.x86_64
> netcf-libs-0.1.9-3.el6.x86_64
> nss-softokn-freebl-3.12.9-11.el6.i686
> openssl-devel-1.0.0-27.el6.x86_64
> openstack-keystone-2013.1.4.1-201310310850.ibm.5.noarch
> openstack-utils-2013.1.1.1-201306031701.ibm.1.noarch
> pam-1.1.1-13.el6.i686
> pango-1.28.1-7.el6_3.i686
> perl-Digest-SHA1-2.12-2.el6.x86_64
> perl-hivex-1.3.3-4.2.el6.x86_64
> perl-libintl-1.20-1.el6.x86_64
> perl-Sys-Guestfs-1.16.34-2.el6.x86_64
> perl-Sys-Virt-0.10.2-5.el6.x86_64
> perl-XML-Writer-0.606-6.el6.noarch
> perl-XML-XPath-1.13-10.el6.noarch
> pixman-0.26.2-4.el6.i686
> ppl-0.10.2-11.el6.x86_64
> PyPAM-0.5.0-12.el6.x86_64
> python-anyjson-0.2.4-4.003.ibm.noarch
> python-argparse-1.2.1-3.ibm.noarch
> python-babel-0.9.6-3.001.ibm.noarch
> python-decorator-3.0.1-3.1.el6.noarch
> python-eventlet-0.9.17-2.ibm.noarch
> python-greenlet-0.3.4-11.001.ibm.x86_64
> python-httplib2-0.7.4-7.ibm.noarch
> python-ibm-db-2.0.4.1-2.ibm.el6.x86_64
> python-ibm-db-sa-0.3.0-6.ibm.el6.noarch
> python-iso8601-0.1.4-3.ibm.noarch
> python-keystone-2013.1.4.1-201310310850.ibm.5.noarch
> python-keystoneclient-0.2.3-71.ibm.noarch
> python-libguestfs-1.16.34-2.el6.x86_64
> python-memcached-1.43-6.el6.noarch
> python-migrate-0.7.2-9.ibm.noarch
> python-oslo-config-1.1.1-201308151039.ibm.noarch
> python-passlib-1.5.3-2.ibm.noarch
> python-paste-1.7.4-2.el6.noarch
> python-paste-deploy-1.5.0-5.ibm.001.noarch
> python-prettytable-0.6.1-2.ibm.noarch
> python-requests-0.14.1-2.002.ibm.noarch
> python-routes-1.12.3-5.001.ibm.noarch
> python-sqlalchemy-0.7.9-3.ibm.el6.x86_64
> python-tempita-0.4-2.el6.noarch
> python-webob-1.2.3-2.ibm.noarch
> qemu-img-0.12.1.2-2.355.el6.x86_64
> qemu-kvm-0.12.1.2-2.355.el6.x86_64
> qpid-cpp-client-0.18-6.001.ibm.x86_64
> qpid-cpp-client-ssl-0.18-6.001.ibm.x86_64
> readline-devel-6.0-4.el6.x86_64
> regexp-1.5-4.4.el6.x86_64
> rpm-build-4.8.0-32.el6.x86_64
> ruby-1.8.7.352-7.el6_2.x86_64
> ruby-devel-1.8.7.352-7.el6_2.x86_64
> rubygems-1.3.7-1.el6.noarch
36 IBM SmartCloud Orchestrator 2.3: User's Guide
> ruby-irb-1.8.7.352-7.el6_2.x86_64
> ruby-libs-1.8.7.352-7.el6_2.x86_64
> ruby-rdoc-1.8.7.352-7.el6_2.x86_64
> scrub-2.2-1.el6.x86_64
> seabios-0.6.1.2-26.el6.x86_64
> sgabios-bin-0-0.3.20110621svn.el6.noarch
> sinjdoc-0.5-9.1.el6.x86_64
> spice-server-0.12.0-12.el6.x86_64
> sqlite-devel-3.6.20-1.el6.x86_64
> tomcat6-6.0.24-49.el6.noarch
> tomcat6-el-2.1-api-6.0.24-49.el6.noarch
> tomcat6-jsp-2.1-api-6.0.24-49.el6.noarch
> tomcat6-lib-6.0.24-49.el6.noarch
> tomcat6-servlet-2.5-api-6.0.24-49.el6.noarch
> tunctl-1.5-3.el6.x86_64
> usbredir-0.5.1-1.el6.x86_64
> vgabios-0.6b-3.7.el6.noarch
> wsdl4j-1.5.2-7.8.el6.noarch
> xml-commons-apis-1.3.04-3.6.el6.x86_64
> xml-commons-resolver-1.1-4.18.el6.x86_64
> xz-libs-4.999.9-0.3.beta.20091007git.el6.i686
> yajl-1.0.7-3.el6.x86_64
> zlib-1.2.3-29.el6.i686
RPM packages added during the installation of Central Server 3
> cloog-ppl-0.15.7-1.2.el6.x86_64
> compat-libstdc++-33-3.2.3-69.el6.i686
> compat-libstdc++-33-3.2.3-69.el6.x86_64
> compat-readline5-5.2-17.1.el6.x86_64
> cpp-4.4.7-3.el6.x86_64
> dos2unix-3.1-37.el6.x86_64
> ebtables-2.0.9-6.el6.x86_64
> gcc-4.4.7-3.el6.x86_64
> gcc-c++-4.4.7-3.el6.x86_64
> genisoimage-1.1.9-12.el6.x86_64
> glibc-2.12-1.107.el6.i686
> glibc-devel-2.12-1.107.el6.x86_64
> glibc-headers-2.12-1.107.el6.x86_64
> ibm-java-i386-sdk-6.0-9.3.i386
> ibm-java-x86_64-sdk-6.0-10.0.x86_64
> kernel-headers-2.6.32-358.el6.x86_64
> libgcc-4.4.7-3.el6.i686
> libstdc++-devel-4.4.7-3.el6.x86_64
> mpfr-2.4.1-6.el6.x86_64
> nss-softokn-freebl-3.12.9-11.el6.i686
> ppl-0.10.2-11.el6.x86_64
> ruby-1.8.7.352-7.el6_2.x86_64
> ruby-devel-1.8.7.352-7.el6_2.x86_64
> rubygems-1.3.7-1.el6.noarch
> ruby-irb-1.8.7.352-7.el6_2.x86_64
> ruby-libs-1.8.7.352-7.el6_2.x86_64
> ruby-rdoc-1.8.7.352-7.el6_2.x86_64
> tunctl-1.5-3.el6.x86_64
RPM packages added during the installation of Central Server 4
> atk-1.28.0-2.el6.i686
> audit-libs-2.2-2.el6.i686
> avahi-libs-0.6.25-12.el6.i686
> cairo-1.8.8-3.1.el6.i686
> cloog-ppl-0.15.7-1.2.el6.x86_64
> compat-readline5-5.2-17.1.el6.x86_64
> cpp-4.4.7-3.el6.x86_64
> cups-libs-1.4.2-48.el6_3.3.i686
> dbus-libs-1.2.24-7.el6_3.i686
> ebtables-2.0.9-6.el6.x86_64
> expat-2.0.1-11.el6_2.i686
Chapter 2. Installing 37
> fontconfig-2.8.0-3.el6.i686
> freetype-2.3.11-6.el6_2.9.i686
> gamin-0.1.10-9.el6.i686
> gcc-4.4.7-3.el6.x86_64
> gcc-c++-4.4.7-3.el6.x86_64
> glib2-2.22.5-7.el6.i686
> glibc-2.12-1.107.el6.i686
> glibc-devel-2.12-1.107.el6.x86_64
> glibc-headers-2.12-1.107.el6.x86_64
> gnutls-2.8.5-10.el6.i686
> gtk2-2.18.9-12.el6.i686
> jasper-libs-1.900.1-15.el6_1.1.i686
> kernel-headers-2.6.32-358.el6.x86_64
> keyutils-libs-1.4-4.el6.i686
> krb5-libs-1.10.3-10.el6.i686
> ksh-20100621-19.el6.x86_64
> libcom_err-1.41.12-14.el6.i686
> libgcc-4.4.7-3.el6.i686
> libgcrypt-1.4.5-9.el6_2.2.i686
> libgpg-error-1.7-4.el6.i686
> libjpeg-turbo-1.2.1-1.el6.i686
> libpng-1.2.49-1.el6_2.i686
> libselinux-2.0.94-5.3.el6.i686
> libstdc++-4.4.7-3.el6.i686
> libstdc++-devel-4.4.7-3.el6.x86_64
> libtasn1-2.3-3.el6_2.1.i686
> libthai-0.1.12-3.el6.i686
> libtiff-3.9.4-9.el6_3.i686
> libX11-1.5.0-4.el6.i686
> libXau-1.0.6-4.el6.i686
> libxcb-1.8.1-1.el6.i686
> libXcomposite-0.4.3-4.el6.i686
> libXcursor-1.1.13-2.el6.i686
> libXdamage-1.1.3-4.el6.i686
> libXext-1.3.1-2.el6.i686
> libXfixes-5.0-3.el6.i686
> libXft-2.3.1-2.el6.i686
> libXi-1.6.1-3.el6.i686
> libXinerama-1.1.2-2.el6.i686
> libXrandr-1.4.0-1.el6.i686
> libXrender-0.9.7-2.el6.i686
> libXtst-1.2.1-2.el6.i686
> mpfr-2.4.1-6.el6.x86_64
> nss-softokn-freebl-3.12.9-11.el6.i686
> pango-1.28.1-7.el6_3.i686
> pixman-0.26.2-4.el6.i686
> ppl-0.10.2-11.el6.x86_64
> ruby-1.8.7.352-7.el6_2.x86_64
> ruby-devel-1.8.7.352-7.el6_2.x86_64
> rubygems-1.3.7-1.el6.noarch
> ruby-irb-1.8.7.352-7.el6_2.x86_64
> ruby-libs-1.8.7.352-7.el6_2.x86_64
> ruby-rdoc-1.8.7.352-7.el6_2.x86_64
> tunctl-1.5-3.el6.x86_64
> zlib-1.2.3-29.el6.i686
RPM packages added during the installation of Region Server
"n"
> apr-1.3.9-5.el6_2.x86_64
> apr-util-1.3.9-3.el6_0.1.x86_64
> apr-util-ldap-1.3.9-3.el6_0.1.x86_64
> audit-libs-2.2-2.el6.i686
> augeas-libs-0.9.0-4.el6.x86_64
> bind-9.8.2-0.17.rc1.el6.x86_64
> boost-1.47.0-7.ibm.x86_64
> boost-chrono-1.47.0-7.ibm.x86_64
38 IBM SmartCloud Orchestrator 2.3: User's Guide
> boost-date-time-1.47.0-7.ibm.x86_64
> boost-filesystem-1.47.0-7.ibm.x86_64
> boost-graph-1.47.0-7.ibm.x86_64
> boost-iostreams-1.47.0-7.ibm.x86_64
> boost-program-options-1.47.0-7.ibm.x86_64
> boost-python-1.47.0-7.ibm.x86_64
> boost-random-1.47.0-7.ibm.x86_64
> boost-regex-1.47.0-7.ibm.x86_64
> boost-serialization-1.47.0-7.ibm.x86_64
> boost-signals-1.47.0-7.ibm.x86_64
> boost-system-1.47.0-7.ibm.x86_64
> boost-test-1.47.0-7.ibm.x86_64
> boost-thread-1.47.0-7.ibm.x86_64
> boost-wave-1.47.0-7.ibm.x86_64
> btrfs-progs-0.20-0.2.git91d9eec.el6.x86_64
> bzip2-devel-1.0.5-7.el6_0.x86_64
> celt051-0.5.1.3-0.el6.x86_64
> cloog-ppl-0.15.7-1.2.el6.x86_64
> compat-libstdc++-296-2.96-144.el6.i686
> compat-libstdc++-33-3.2.3-69.el6.i686
> compat-libstdc++-33-3.2.3-69.el6.x86_64
> compat-readline5-5.2-17.1.el6.x86_64
> cpp-4.4.7-3.el6.x86_64
> cracklib-2.8.16-4.el6.i686
> createrepo-0.9.9-17.el6.noarch
> cyrus-sasl-md5-2.1.23-13.el6_3.1.x86_64
> dapl-2.0.34-1.el6.x86_64
> db4-4.7.25-17.el6.i686
> deltarpm-3.5-0.5.20090913git.el6.x86_64
> dhcp-4.1.1-34.P1.el6.x86_64
> dnsmasq-2.59-5.ibm.003.x86_64
> dnsmasq-utils-2.59-5.ibm.003.x86_64
> dos2unix-3.1-37.el6.x86_64
> ebtables-2.0.9-6.el6.x86_64
> febootstrap-supermin-helper-3.12-2.el6.x86_64
> fuse-2.8.3-4.el6.x86_64
> fuse-libs-2.8.3-4.el6.x86_64
> gcc-4.4.7-3.el6.x86_64
> gcc-c++-4.4.7-3.el6.x86_64
> genisoimage-1.1.9-12.el6.x86_64
> glibc-2.12-1.107.el6.i686
> glibc-devel-2.12-1.107.el6.x86_64
> glibc-headers-2.12-1.107.el6.x86_64
> gnutls-utils-2.8.5-10.el6.x86_64
> gpxe-roms-qemu-0.9.7-6.9.el6.noarch
> hivex-1.3.3-4.2.el6.x86_64
> httpd-2.2.15-26.el6.x86_64
> httpd-tools-2.2.15-26.el6.x86_64
> iscsi-initiator-utils-6.2.0.873-2.el6.x86_64
> kernel-headers-2.6.32-358.el6.x86_64
> keyutils-libs-devel-1.4-4.el6.x86_64
> krb5-devel-1.10.3-10.el6.x86_64
> ksh-20100621-19.el6.x86_64
> libcom_err-devel-1.41.12-14.el6.x86_64
> libconfig-1.3.2-1.1.el6.x86_64
> libgcc-4.4.7-3.el6.i686
> libgcrypt-devel-1.4.5-9.el6_2.2.x86_64
> libgpg-error-devel-1.7-4.el6.x86_64
> libguestfs-1.16.34-2.el6.x86_64
> libguestfs-tools-1.16.34-2.el6.x86_64
> libguestfs-tools-c-1.16.34-2.el6.x86_64
> libguestfs-winsupport-1.0-7.el6.x86_64
> libibverbs-1.1.6-5.el6.x86_64
> libicu-4.2.1-9.1.el6_2.x86_64
> librdmacm-1.0.17-0.git4b5c1aa.el6.x86_64
> libselinux-2.0.94-5.3.el6.i686
> libselinux-devel-2.0.94-5.3.el6.x86_64
Chapter 2. Installing 39
> libsepol-devel-2.0.41-4.el6.x86_64
> libstdc++-4.4.7-3.el6.i686
> libstdc++-devel-4.4.7-3.el6.x86_64
> libvirt-0.10.2-18.el6.x86_64
> libvirt-client-0.10.2-18.el6.x86_64
> libvirt-python-0.10.2-18.el6.x86_64
> lzo-2.03-3.1.el6.x86_64
> lzop-1.02-0.9.rc1.el6.x86_64
> mpfr-2.4.1-6.el6.x86_64
> mtools-4.0.12-1.el6.x86_64
> MySQL-python-1.2.3-0.3.c1.1.el6.x86_64
> nc-1.84-22.el6.x86_64
> ncurses-devel-5.7-3.20090208.el6.x86_64
> netcf-libs-0.1.9-3.el6.x86_64
> novnc-0.4-6.003.ibm.el6.noarch
> nss-softokn-freebl-3.12.9-11.el6.i686
> openssl-devel-1.0.0-27.el6.x86_64
> openstack-cinder-2013.1.4.1-201310310842.ibm.5.noarch
> openstack-glance-2013.1.4.1-201310310845.ibm.5.noarch
> openstack-nova-2013.1.4.1-201310310901.ibm.8.noarch
> openstack-nova-api-2013.1.4.1-201310310901.ibm.8.noarch
> openstack-nova-cells-2013.1.4.1-201310310901.ibm.8.noarch
> openstack-nova-cert-2013.1.4.1-201310310901.ibm.8.noarch
> openstack-nova-common-2013.1.4.1-201310310901.ibm.8.noarch
> openstack-nova-compute-2013.1.4.1-201310310901.ibm.8.noarch
> openstack-nova-compute-prereqs-2013.1-201308201437.ibm.1.x86_64
> openstack-nova-conductor-2013.1.4.1-201310310901.ibm.8.noarch
> openstack-nova-console-2013.1.4.1-201310310901.ibm.8.noarch
> openstack-nova-network-2013.1.4.1-201310310901.ibm.8.noarch
> openstack-nova-novncproxy-0.4-6.003.ibm.el6.noarch
> openstack-nova-objectstore-2013.1.4.1-201310310901.ibm.8.noarch
> openstack-nova-scheduler-2013.1.4.1-201310310901.ibm.8.noarch
> openstack-utils-2013.1.1.1-201306031701.ibm.1.noarch
> pam-1.1.1-13.el6.i686
> perl-Config-General-2.44-1.el6.noarch
> perl-hivex-1.3.3-4.2.el6.x86_64
> perl-libintl-1.20-1.el6.x86_64
> perl-Sys-Guestfs-1.16.34-2.el6.x86_64
> perl-Sys-Virt-0.10.2-5.el6.x86_64
> perl-XML-Writer-0.606-6.el6.noarch
> perl-XML-XPath-1.13-10.el6.noarch
> ppl-0.10.2-11.el6.x86_64
> PyPAM-0.5.0-12.el6.x86_64
> pyparsing-1.5.7-2.ibm.noarch
> python-amqplib-0.6.1-3.002.ibm.noarch
> python-anyjson-0.2.4-4.003.ibm.noarch
> python-argparse-1.2.1-3.ibm.noarch
> python-boto-2.5.2-2.ibm.noarch
> python-cheetah-2.4.4-4.001.ibm.x86_64
> python-cinder-2013.1.4.1-201310310842.ibm.5.noarch
> python-cinderclient-1.0.3-2.ibm.noarch
> python-cliff-1.3.2-1.ibm.noarch
> python-cmd2-0.6.4-3.ibm.noarch
> python-crypto-2.3-7.ibm.002.x86_64
> python-decorator-3.0.1-3.1.el6.noarch
> python-deltarpm-3.5-0.5.20090913git.el6.x86_64
> python-eventlet-0.9.17-2.ibm.noarch
> python-glance-2013.1.4.1-201310310845.ibm.5.noarch
> python-glanceclient-0.9.0-4.ibm.el6.noarch
> python-greenlet-0.3.4-11.001.ibm.x86_64
> python-httplib2-0.7.4-7.ibm.noarch
> python-ibm-db-2.0.4.1-2.ibm.el6.x86_64
> python-ibm-db-sa-0.3.0-6.ibm.el6.noarch
> python-iso8601-0.1.4-3.ibm.noarch
> python-jsonpatch-0.10-2.ibm.noarch
> python-jsonpointer-0.5-2.ibm.noarch
> python-jsonschema-0.7-2.ibm.noarch
40 IBM SmartCloud Orchestrator 2.3: User's Guide
> python-keystone-2013.1.4.1-201310310850.ibm.5.noarch
> python-keystoneclient-0.2.3-71.ibm.noarch
> python-kombu-1.0.4-2.002.ibm.noarch
> python-libguestfs-1.16.34-2.el6.x86_64
> python-lockfile-0.8-4.ibm.002.noarch
> python-markdown-2.0.1-3.1.el6.noarch
> python-memcached-1.43-6.el6.noarch
> python-migrate-0.7.2-9.ibm.noarch
> python-nova-2013.1.4.1-201310310901.ibm.8.noarch
> python-novaclient-2.13-2.ibm.noarch
> python-ordereddict-1.1-3.001.ibm.noarch
> python-oslo-config-1.1.1-201308151039.ibm.noarch
> python-paramiko-1.8.0-3.ibm.el6.noarch
> python-passlib-1.5.3-2.ibm.noarch
> python-paste-1.7.4-2.el6.noarch
> python-paste-deploy-1.5.0-5.ibm.001.noarch
> python-prettytable-0.6.1-2.ibm.noarch
> python-pyasn1-0.0.12a-2.ibm.noarch
> python-pygments-1.1.1-1.el6.noarch
> python-qpid-0.18-3.ibm.el6.noarch
> python-qpid-qmf-0.18-6.001.ibm.x86_64
> python-quantumclient-2.2.1-5.ibm.noarch
> python-requests-0.14.1-2.002.ibm.noarch
> python-routes-1.12.3-5.001.ibm.noarch
> python-sqlalchemy-0.7.9-3.ibm.el6.x86_64
> python-stevedore-0.8-2.ibm.noarch
> python-suds-0.4.1-3.el6.noarch
> python-swiftclient-1.2.0-4.ibm.noarch
> python-tempita-0.4-2.el6.noarch
> python-warlock-0.7.0-2.ibm.noarch
> python-webob-1.2.3-2.ibm.noarch
> python-websockify-0.2.0-3.001.ibm.noarch
> python-wsgiref-0.1.2-10.001.ibm.noarch
> qemu-img-0.12.1.2-2.355.el6.x86_64
> qemu-kvm-0.12.1.2-2.355.el6.x86_64
> qpid-cpp-client-0.18-6.001.ibm.x86_64
> qpid-cpp-server-0.18-6.001.ibm.x86_64
> qpid-cpp-server-ha-0.18-6.001.ibm.x86_64
> qpid-qmf-0.18-6.001.ibm.x86_64
> qpid-tools-0.18-6.001.ibm.noarch
> radvd-1.6-1.el6.x86_64
> readline-devel-6.0-4.el6.x86_64
> rsct.64bit-3.1.4.4-13032.x86_64
> rsct.basic-3.1.4.4-13032.i386
> rsct.basic.msg.de_DE-3.1.1.2-11266.i386
> [email protected]
> rsct.basic.msg.de_DE.ISO-8859-1-3.1.1.2-11266.i386
> rsct.basic.msg.de_DE.UTF-8-3.1.1.2-11266.i386
> rsct.basic.msg.es_ES-3.1.1.2-11266.i386
> [email protected]
> rsct.basic.msg.es_ES.ISO-8859-1-3.1.1.2-11266.i386
> rsct.basic.msg.es_ES.UTF-8-3.1.1.2-11266.i386
> rsct.basic.msg.fr_FR-3.1.1.2-11266.i386
> [email protected]
> rsct.basic.msg.fr_FR.ISO-8859-1-3.1.1.2-11266.i386
> rsct.basic.msg.fr_FR.UTF-8-3.1.1.2-11266.i386
> rsct.basic.msg.it_IT-3.1.1.2-11266.i386
> [email protected]
> rsct.basic.msg.it_IT.ISO-8859-1-3.1.1.2-11266.i386
> rsct.basic.msg.it_IT.UTF-8-3.1.1.2-11266.i386
> rsct.basic.msg.ja_JP.eucJP-3.1.1.2-11266.i386
> rsct.basic.msg.ja_JP.UTF-8-3.1.1.2-11266.i386
> rsct.basic.msg.ko_KR.eucKR-3.1.1.2-11266.i386
> rsct.basic.msg.ko_KR.UTF-8-3.1.1.2-11266.i386
> rsct.basic.msg.pt_BR-3.1.1.2-11266.i386
> rsct.basic.msg.pt_BR.UTF-8-3.1.1.2-11266.i386
> rsct.basic.msg.zh_CN.GB18030-3.1.1.2-11266.i386
Chapter 2. Installing 41
> rsct.basic.msg.zh_CN.GB2312-3.1.1.2-11266.i386
> rsct.basic.msg.zh_CN.GBK-3.1.1.2-11266.i386
> rsct.basic.msg.zh_CN.UTF-8-3.1.1.2-11266.i386
> rsct.basic.msg.zh_TW-3.1.1.2-11266.i386
> rsct.basic.msg.zh_TW.Big5-3.1.1.2-11266.i386
> rsct.basic.msg.zh_TW.eucTW-3.1.1.2-11266.i386
> rsct.basic.msg.zh_TW.UTF-8-3.1.1.2-11266.i386
> rsct.core-3.1.4.4-13032.i386
> rsct.core.msg.de_DE-3.1.1.2-11266.i386
> [email protected]
> rsct.core.msg.de_DE.ISO-8859-1-3.1.1.2-11266.i386
> rsct.core.msg.de_DE.UTF-8-3.1.1.2-11266.i386
> rsct.core.msg.es_ES-3.1.1.2-11266.i386
> [email protected]
> rsct.core.msg.es_ES.ISO-8859-1-3.1.1.2-11266.i386
> rsct.core.msg.es_ES.UTF-8-3.1.1.2-11266.i386
> rsct.core.msg.fr_FR-3.1.1.2-11266.i386
> [email protected]
> rsct.core.msg.fr_FR.ISO-8859-1-3.1.1.2-11266.i386
> rsct.core.msg.fr_FR.UTF-8-3.1.1.2-11266.i386
> rsct.core.msg.it_IT-3.1.1.2-11266.i386
> [email protected]
> rsct.core.msg.it_IT.ISO-8859-1-3.1.1.2-11266.i386
> rsct.core.msg.it_IT.UTF-8-3.1.1.2-11266.i386
> rsct.core.msg.ja_JP.eucJP-3.1.1.2-11266.i386
> rsct.core.msg.ja_JP.UTF-8-3.1.1.2-11266.i386
> rsct.core.msg.ko_KR.eucKR-3.1.1.2-11266.i386
> rsct.core.msg.ko_KR.UTF-8-3.1.1.2-11266.i386
> rsct.core.msg.pt_BR-3.1.1.2-11266.i386
> rsct.core.msg.pt_BR.UTF-8-3.1.1.2-11266.i386
> rsct.core.msg.zh_CN.GB18030-3.1.1.2-11266.i386
> rsct.core.msg.zh_CN.GB2312-3.1.1.2-11266.i386
> rsct.core.msg.zh_CN.GBK-3.1.1.2-11266.i386
> rsct.core.msg.zh_CN.UTF-8-3.1.1.2-11266.i386
> rsct.core.msg.zh_TW-3.1.1.2-11266.i386
> rsct.core.msg.zh_TW.Big5-3.1.1.2-11266.i386
> rsct.core.msg.zh_TW.eucTW-3.1.1.2-11266.i386
> rsct.core.msg.zh_TW.UTF-8-3.1.1.2-11266.i386
> rsct.core.utils-3.1.4.4-13032.i386
> rsct.core.utils.msg.de_DE-3.1.1.2-11266.i386
> [email protected]
> rsct.core.utils.msg.de_DE.ISO-8859-1-3.1.1.2-11266.i386
> rsct.core.utils.msg.de_DE.UTF-8-3.1.1.2-11266.i386
> rsct.core.utils.msg.es_ES-3.1.1.2-11266.i386
> [email protected]
> rsct.core.utils.msg.es_ES.ISO-8859-1-3.1.1.2-11266.i386
> rsct.core.utils.msg.es_ES.UTF-8-3.1.1.2-11266.i386
> rsct.core.utils.msg.fr_FR-3.1.1.2-11266.i386
> [email protected]
> rsct.core.utils.msg.fr_FR.ISO-8859-1-3.1.1.2-11266.i386
> rsct.core.utils.msg.fr_FR.UTF-8-3.1.1.2-11266.i386
> rsct.core.utils.msg.it_IT-3.1.1.2-11266.i386
> [email protected]
> rsct.core.utils.msg.it_IT.ISO-8859-1-3.1.1.2-11266.i386
> rsct.core.utils.msg.it_IT.UTF-8-3.1.1.2-11266.i386
> rsct.core.utils.msg.ja_JP.eucJP-3.1.1.2-11266.i386
> rsct.core.utils.msg.ja_JP.UTF-8-3.1.1.2-11266.i386
> rsct.core.utils.msg.ko_KR.eucKR-3.1.1.2-11266.i386
> rsct.core.utils.msg.ko_KR.UTF-8-3.1.1.2-11266.i386
> rsct.core.utils.msg.pt_BR-3.1.1.2-11266.i386
> rsct.core.utils.msg.pt_BR.UTF-8-3.1.1.2-11266.i386
> rsct.core.utils.msg.zh_CN.GB18030-3.1.1.2-11266.i386
> rsct.core.utils.msg.zh_CN.GB2312-3.1.1.2-11266.i386
> rsct.core.utils.msg.zh_CN.GBK-3.1.1.2-11266.i386
> rsct.core.utils.msg.zh_CN.UTF-8-3.1.1.2-11266.i386
> rsct.core.utils.msg.zh_TW-3.1.1.2-11266.i386
> rsct.core.utils.msg.zh_TW.Big5-3.1.1.2-11266.i386
42 IBM SmartCloud Orchestrator 2.3: User's Guide
> rsct.core.utils.msg.zh_TW.eucTW-3.1.1.2-11266.i386
> rsct.core.utils.msg.zh_TW.UTF-8-3.1.1.2-11266.i386
> rsct.opt.stackdump-3.1.4.4-13032.i386
> rsct.opt.storagerm-3.1.4.4-13032.i386
> ruby-1.8.7.352-7.el6_2.x86_64
> ruby-devel-1.8.7.352-7.el6_2.x86_64
> rubygems-1.3.7-1.el6.noarch
> ruby-irb-1.8.7.352-7.el6_2.x86_64
> ruby-libs-1.8.7.352-7.el6_2.x86_64
> ruby-rdoc-1.8.7.352-7.el6_2.x86_64
> sam-3.2.2.5-13129.i386
> sam.adapter-3.2.2.5-13129.i386
> sam.msg.de_DE-3.2.2.4-0.i386
> [email protected]
> sam.msg.de_DE.ISO-8859-1-3.2.2.4-0.i386
> sam.msg.de_DE.UTF-8-3.2.2.4-0.i386
> sam.msg.es_ES-3.2.2.4-0.i386
> [email protected]
> sam.msg.es_ES.ISO-8859-1-3.2.2.4-0.i386
> sam.msg.es_ES.UTF-8-3.2.2.4-0.i386
> sam.msg.fr_FR-3.2.2.4-0.i386
> [email protected]
> sam.msg.fr_FR.ISO-8859-1-3.2.2.4-0.i386
> sam.msg.fr_FR.UTF-8-3.2.2.4-0.i386
> sam.msg.it_IT-3.2.2.4-0.i386
> [email protected]
> sam.msg.it_IT.ISO-8859-1-3.2.2.4-0.i386
> sam.msg.it_IT.UTF-8-3.2.2.4-0.i386
> sam.msg.ja_JP.eucJP-3.2.2.4-0.i386
> sam.msg.ja_JP.UTF-8-3.2.2.4-0.i386
> sam.msg.ko_KR.eucKR-3.2.2.4-0.i386
> sam.msg.ko_KR.UTF-8-3.2.2.4-0.i386
> sam.msg.pt_BR-3.2.2.4-0.i386
> sam.msg.pt_BR.UTF-8-3.2.2.4-0.i386
> sam.msg.zh_CN.GB18030-3.2.2.4-0.i386
> sam.msg.zh_CN.GB2312-3.2.2.4-0.i386
> sam.msg.zh_CN.GBK-3.2.2.4-0.i386
> sam.msg.zh_CN.UTF-8-3.2.2.4-0.i386
> sam.msg.zh_TW-3.2.2.4-0.i386
> sam.msg.zh_TW.Big5-3.2.2.4-0.i386
> sam.msg.zh_TW.eucTW-3.2.2.4-0.i386
> sam.msg.zh_TW.UTF-8-3.2.2.4-0.i386
> sam.policies.one-3.2.2.5-13129.i386
> sam.policies.two-3.2.2.5-13129.i386
> sam.sappolicy-3.2.2.5-13129.i386
> scp-chef_repo_srv-2.2.0.0-201311090045.noarch
> scp-cookbooks-2.3.0.0-B20131109005700.noarch
> scrub-2.2-1.el6.x86_64
> scsi-target-utils-1.0.24-2.el6.x86_64
> seabios-0.6.1.2-26.el6.x86_64
> sg3_utils-1.28-4.el6.x86_64
> sgabios-bin-0-0.3.20110621svn.el6.noarch
> smartcloud-2013.1-1.1.ibm.201311080518.noarch
> spice-server-0.12.0-12.el6.x86_64
> sqlite-devel-3.6.20-1.el6.x86_64
> src-3.1.4.4-13032.i386
> src.msg.de_DE-1.3.1.1-11266.i386
> [email protected]
> src.msg.de_DE.ISO-8859-1-1.3.1.1-11266.i386
> src.msg.de_DE.UTF-8-1.3.1.1-11266.i386
> src.msg.es_ES-1.3.1.1-11266.i386
> [email protected]
> src.msg.es_ES.ISO-8859-1-1.3.1.1-11266.i386
> src.msg.es_ES.UTF-8-1.3.1.1-11266.i386
> src.msg.fr_FR-1.3.1.1-11266.i386
> [email protected]
> src.msg.fr_FR.ISO-8859-1-1.3.1.1-11266.i386
Chapter 2. Installing 43
> src.msg.fr_FR.UTF-8-1.3.1.1-11266.i386
> src.msg.it_IT-1.3.1.1-11266.i386
> [email protected]
> src.msg.it_IT.ISO-8859-1-1.3.1.1-11266.i386
> src.msg.it_IT.UTF-8-1.3.1.1-11266.i386
> src.msg.ja_JP.eucJP-1.3.1.1-11266.i386
> src.msg.ja_JP.UTF-8-1.3.1.1-11266.i386
> src.msg.ko_KR.eucKR-1.3.1.1-11266.i386
> src.msg.ko_KR.UTF-8-1.3.1.1-11266.i386
> src.msg.pt_BR-1.3.1.1-11266.i386
> src.msg.pt_BR.UTF-8-1.3.1.1-11266.i386
> src.msg.zh_CN.GB18030-1.3.1.1-11266.i386
> src.msg.zh_CN.GB2312-1.3.1.1-11266.i386
> src.msg.zh_CN.GBK-1.3.1.1-11266.i386
> src.msg.zh_CN.UTF-8-1.3.1.1-11266.i386
> src.msg.zh_TW-1.3.1.1-11266.i386
> src.msg.zh_TW.Big5-1.3.1.1-11266.i386
> src.msg.zh_TW.eucTW-1.3.1.1-11266.i386
> src.msg.zh_TW.UTF-8-1.3.1.1-11266.i386
> syslinux-4.02-8.el6.x86_64
> tftp-server-0.49-7.el6.x86_64
> tunctl-1.5-3.el6.x86_64
> usbredir-0.5.1-1.el6.x86_64
> vgabios-0.6b-3.7.el6.noarch
> xinetd-2.3.14-38.el6.x86_64
> yajl-1.0.7-3.el6.x86_64
> zlib-devel-1.2.3-29.el6.x86_64
Installing a compute node
If you have already deployed the Region Server with KVM type, compute nodes
must be installed on a physical machine. If the machine has no operating system,
use PXE. If the machine already has Red Hat Enterprise Linux 6.3 or 6.4 64-bit
system installed, use the script.
Note: If you have a Region Server, for example, - rs-1 -, with one KVM compute
node added, it is possible to add a second or subsequent nodes to this same
Region Server. However, this is only possible if the compute nodes that are added
are on the same subnet. When adding these additional compute nodes, you can
run the deploy_compute_node.sh script. You do not need to run the
deploy_region_server.sh script again.
All KVM compute nodes must use the same interface to connect to the Region
Server, for example, eth0, eth1, or eth2.
Installing a KVM compute node by PXE
Pre-Boot Execution Environment (PXE) allows a workstation to start from a server
on a network before it runs the operating system on the local hard disk drive. You
can use this method to add a KVM compute node to your network.
Before you begin
The KVM compute node must be a physical machine.
Restriction: PXE does not support a physical machine with SAN storage.
Procedure
1. Make sure that you have already installed a KVM region server and that the
physical machine is PXE-enabled.
44 IBM SmartCloud Orchestrator 2.3: User's Guide
2. On the region server where the KVM compute node must be connected, run
the following command to register the KVM compute node:
/install_images/installer/inst-scripts/register_node.sh
<kvm-host-name> <mac-of-nic> <ip-of-nic>
where:
<kvm-host-name>
Required. Defines the host name that you want to assign to the newly
deployed compute node.
<mac-of-nic>
Required. Defines the MAC address of the NIC that you want to boot
from the PXE.
<ip-of-nic>
Required. Defines the IP address that you want to assign to the newly
deployed compute node.
Note: If the physical node has multiple network devices, choose the device that
connects to the cloud.
3. On the physical node, reboot and change the BIOS settings to ensure it boots
from network.
4. After the physical machine reboots, choose "Choose Compute Node In Disk"
in the prompted menu.
5. On the physical machine, once the operating system has been installed and a
reboot occurs. change the BIOS settings to ensure that the hard disk is the first
boot device.
What to do next
When you have completed this procedure, a SmartCloud Orchestrator with KVM
region was setup successfully. If multiple region are required, see Installing a
multiple-region environment on page 47, otherwise go to Verifying the
installation on page 47.
Note: If you have a region server, for example, - rs-1 -, and it has one KVM
compute node added to it, it is possible to add a second or subsequent nodes to
this same region server. However, this is only possible if the compute nodes that
are added are on the same subnet.
Installing a KVM compute node by script
You can install a KVM compute node using a script.
Before you begin
Make sure that you already have a physical machine with Red Hat Enterprise
Linux 6.3/6.4 64-bit system installed. "Basic Server" is enough to meet the OS
requirement.
Restriction: The compute node and region server must be in the same subnet.
Note:
v Make sure that compute node must be in the same network with the
vm_ip_range specified in region-server.conf.
Chapter 2. Installing 45
v Make sure that compute node operating system is freshly installed and that the
kernel version is consistent with the kernel version of the Region Server.
v Make sure that you have 100 GB in the "/var" partition.
Procedure
1. Make sure that you have already installed a KVM region server.
2. Configure the network with static IP which can be connected to region server.
3. Make sure that the SSHD is enabled and the region server can SSH to it.
4. Edit the /etc/selinux/config file and set the parameter SELINUX=disabled.
5. Reboot the computer.
6. Run the following command to deploy the compute node on region server
where the KVM compute node must be connected:
/install_images/installer/./deploy_compute_node.sh [-h]
<-s <additional node ip> [-p OS root password]
[-n additional-node-name][-e chef-environment]
where:
<-s additional node ip>
Required. Defines the IP address of the KVM compute node.
-p OS root password
Optional. Defines the OS root password to login the additional node. If
it is not indicated here, the command will prompt you for it.
-n additional-node-name
Optional. Defines the name of the KVM compute service that will be
stored in Chef server, the default value is the hostname of your
compute node.
-e chef-environment
Optional. Defines the chef environment of SmartCloud Orchestrator.
Default is production.
What to do next
When you have completed this procedure, a SmartCloud Orchestrator with KVM
region was setup successfully. If multiple region are required, see Installing a
multiple-region environment on page 47, otherwise go to Verifying the
installation on page 47.
Note: If you have a region server, for example, - rs-1 -, and it has one KVM
compute node added to it, it is possible to add a second or subsequent nodes to
this same region server. However, this is only possible if the compute nodes that
are added are on the same subnet. When adding these additional compute nodes,
you can run the deploy_compute_node.sh script. You do not need to run the
deploy_region_server.sh script again.
46 IBM SmartCloud Orchestrator 2.3: User's Guide
Installing a multiple-region environment
You can install SmartCloud Orchestrator in a multiple-region environment.
About this task
A SmartCloud Orchestrator environment must have at least one region server
installed. However, you can install additional region servers. Each region server
can point to any of the supported hypervisor management infrastructures.
Therefore, you can choose whether the regions use the same hypervisor type or
different hypervisor types.
In a multiple-region environment, you can use a single SmartCloud Orchestrator
user interface to deploy your application across multiple providers. For a
high-level overview of the multiple-region structure, see the diagram displayed at
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/
wiki/IBM%20SmartCloud%20Orchestrator/page/IBM%20SmartCloud
%20Orchestrator%202.3%20topology
Procedure
1. Install SmartCloud Orchestrator with at least one region.
2. Prepare a new region server. For more information, see Preparing the central
server and the region server on page 17.
3. Deploy the new region server. For more information, see Installing the region
server on page 26.
4. Repeat steps 2 and 3 to add the required number of region servers.
Verifying the installation
When you have completed the installation, you can verify it by completing the
verification steps.
Procedure
1. Make sure that the integration of all components is successful by accessing the
SmartCloud Orchestrator user interfaces. To access each user interface, use the
admin user name, and the SmartCloud Orchestrator password specified in
Installing the central server on page 23. Leave the domain name blank, the
default value default is used.
a. To access the main user interface:
1) Open the following URL:
https://$central-server-3_ip
where $central-server-3_ip is the IP address of Central Server 3.
2) Click Configuration > Cloud Group.
3) Find the cloud group with the name that is prefixed with the region
name that you specified in Installing the central server on page 23,
and make sure that the cloud group is connected. When you use
multiple regions, multiple cloud groups should be discovered and
connected. One cloud group corresponds to one region.
b. To access the Virtual Image Library user interface:
1) Open the following URL:
https://$central-server-2_ip:9443/ImageLibraryUI
Chapter 2. Installing 47
where $central-server-2_ip is the IP address of Central Server 2.
2) Click Images > Operational Repositories.
3) Make sure that one repository with the same name as the region name
that you specified in Installing the region server on page 26 is
connected. When you use multiple regions, multiple repositories should
be discovered and connected. One repository corresponds to one region.
c. To access the Business Process Manager user interface, open the following
URL:
https://$central-server-4_ip:9443/ProcessCenter/
where $central-server-4_ip is the IP address of Central Server 4.
For advanced usage of the SmartCloud Orchestrator user interfaces, see
Accessing SmartCloud Orchestrator user interfaces on page 135.
2. Verify the connectivity to the KVM compute node or VMware vCenter or
VMControl, by using the OpenStack command line.
To configure and administer SmartCloud Orchestrator, you might need to use
the Keystone command-line interface to manage authentication and
authorizations, and the Glance command-line interface to manage virtual
images. The environment profile /root/keystonerc is generated on each region
server. Make sure that the OpenStack command-line interface can be executed
by using the profile, as shown in the following example:
a. Run the following command to invoke the profile:
source /root/keystonerc
b. Run the following command to display a list of services:
nova-manage service list
The output should be displayed in the following format. The State of each
service should be :-). Otherwise, the cloud is not ready.
v For a KVM region:
Binary Host Zone Status State Updated_At
nova-scheduler region-server-1 internal enabled :-) 2013-10-10 09:27:57.870300
nova-conductor region-server-1 internal enabled :-) 2013-10-10 09:27:58.027345
nova-consoleauth region-server-1 internal enabled :-) 2013-10-10 09:27:57.547338
nova-cert region-server-1 internal enabled :-) 2013-10-10 09:27:50.464783
nova-compute compute-1 nova enabled :-) 2013-10-10 09:27:53.349208
nova-network compute-1 internal enabled :-) 2013-10-10 09:27:57.227900
v For a VMware or VMControl region:
Binary Host Zone Status State Updated_At
nova-scheduler region-server-1 internal enabled :-) 2013-09-26 07:36:17.428072
nova-conductor region-server-1 internal enabled :-) 2013-09-26 07:36:17.426761
nova-consoleauth region-server-1 internal enabled :-) 2013-09-26 07:36:17.426186
nova-network region-server-1 internal enabled :-) 2013-09-26 07:36:17.428626
nova-cert region-server-1 internal enabled :-) 2013-09-26 07:36:17.424870
nova-smartcloud region-server-1 internal enabled :-) 2013-09-14 19:48:19.691012
nova-compute [email protected] nova_smartcloud enabled :-) 2013-09-14 19:48:19.695301
For more information about the OpenStack command-line interface, see the
OpenStack End User Guide(http://docs.openstack.org/user-guide/content/
index.html).
3. Additional verification steps:
The IaaS Generic REST call makes REST calls to OpenStack services through
the IaaS gateway. You can use the interface to specify the target region and the
service to start. If required, check the status by accessing the
http://$central-server-2_ip:9973/providers URL.
The following information should be displayed:
<serviceCatalog>
<service type="identity" name="keystone">
<endpoint interface="internal" url="<http://172.16.102.182:9973/5177539e9caa42959a2818209754a485/v3"
region="RegionOne" id="5177539e9caa42959a2818209754a485"/>
<endpoint interface="admin" url="<http://172.16.102.182:9973/164a8cf0ad3541438200dcc1f3d81abb/v3"
region="RegionOne" id="164a8cf0ad3541438200dcc1f3d81abb"/>
48 IBM SmartCloud Orchestrator 2.3: User's Guide
<endpoint interface="internal" url="http://172.16.102.182:9973/6836f7dfb3954371bfc9261e40d069e8/v3"
region="Master" id="6836f7dfb3954371bfc9261e40d069e8"/>
<endpoint interface="admin" url="http://172.16.102.182:9973/6bffb3fd97a94b1597fe0b25d7e1493b/v3"
region="Master" id="6bffb3fd97a94b1597fe0b25d7e1493b"/>
<endpoint interface="public" url="http://172.16.102.182:9973/d0ec3a2830b6470d900aa66ede514313/v3"
region="RegionOne" id="d0ec3a2830b6470d900aa66ede514313"/>
<endpoint interface="public" url="http://172.16.102.182:9973/85d0ffc426604dc488dc0c8103fa249b/v3"
region="Master" id="85d0ffc426604dc488dc0c8103fa249b"/>
</service>
</serviceCatalog>
4. To improve the performance of the SmartCloud Orchestrator environment, you
can add both the fully-qualified domain name (FQDN) and the host name of all
the central and region servers to /etc/hosts on all the SmartCloud Orchestrator
server nodes. For example:
cat /etc/hosts on central server 2
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
172.16.34.201 central-server-1.cloud.company.com central-server-1
172.16.34.202 central-server-2.cloud.company.com central-server-2
172.16.34.203 central-server-3.cloud.company.com central-server-3
172.16.34.204 central-server-4.cloud.company.com central-server-4
172.16.34.205 region-server-1.cloud.company.com region-server-1
172.16.34.206 region-server-2.cloud.company.com region-server-2
You can find FQDN by "nslookup" on each server that has the correct
nameserver configured. For example:
[root@central-server-2 ]# nslookup 172.16.34.202
Server: 172.16.34.200
Address: 172.16.34.200#53
201.34.16.172.in-addr.arpa name = central-server-2.cloud.company.com.
[root@central-server-2 ]# cat /etc/resolv.conf
search cloud.company.com company.com
nameserver 172.16.34.200
What to do next
After checking the environment profile and cloud groups, start to use the product
to work with virtual images in your cloud environment. See Chapter 3, Getting
started, on page 131. Make sure that virtual system patterns can be deployed.
Performing advanced configuration tasks
After successful installation of SmartCloud Orchestrator, you can perform
advanced configuration tasks that help you better manage the product.
Setting up virtual machines to install Central Server and
Region Server
Set up the KVM or VMware virtual machines to install the Central Server and
Region Server by using the virt-manager or the vCenter application. You can also
set up the KVM virtual machines by using the command line.
Setting up KVM virtual machines
To set up a KVM virtual machine, install and configure the KVM-related software
and create the virtual machines as described in the following procedures. It is
recommended to use the same operating system version on your Central Server
and Region Server.
Install and configure KVM-related software
Chapter 2. Installing 49
1. Make sure that the KVM-related feature is enabled in the BIOS of your
host machines. The host machines must use either Intel VT or AMD-V
chipsets that support hardware-assisted virtualization. Verify that the
processor supports KVM by running the following command on your
system:
grep -E vmx|svm /proc/cpuinfo
If the command returns output, your system supports KVM.
2. Configure an ISO repository to be available to your host for
downloading the KVM-related packages. To create a repository using
an ISO image, perform the following steps:
a. For example, if you have your RHEL 6 ISO image stored in
/opt/RHEL6.3-20120613.2-Server-x86_64-DVD1.iso, mount the ISO
image by running the following commands:
mkdir -p /mnt/rhel6
mount -o loop /opt/RHEL6.3-20120613.2-Server-x86_64-DVD1.iso /mnt/rhel6
b. Create a repo file in the /etc/yum.repos.d directory and change the
base path to the directory path that you specified in the mount
command. For example, create the /etc/yum.repos.d/DVD.repo file
with the following content:
[RHEL-Repository]
name=RHEL repository
baseurl=file:///mnt/rhel6
enabled=1
gpgcheck=0
3. Install the KVM management packages via yum by running the
following command:
yum install kvm virt-manager libvirt libvirt-python python-virtinst tunctl
4. Configure the network by performing the following steps:
a. Switch to root user.
b. Disable NetworkManager by running the following commands:
chkconfig NetworkManager off
chkconfig network on
service NetworkManager stop
service network start
c. Start the libvirtd service by running the following command:
service libvirtd start
d. Create a bridge (br0) based on the eth0 interface by running the
following command on the host:
virsh iface-bridge eth0 br0
If the command fails, you can manually configure the networks by
performing the following steps:
a. Edit your /etc/sysconfig/network-scripts/ifcfg-eth0 file as in the
following example:
DEVICE=eth0
HWADDR=AA:BB:CC:AA:BB:CC
ONBOOT=yes
BRIDGE=br0
b. Edit your /etc/sysconfig/network-scripts/ifcfg-br0 file as in the
following example:
DEVICE=br0
ONBOOT=yes
TYPE=Bridge
BOOTPROTO=none
50 IBM SmartCloud Orchestrator 2.3: User's Guide
IPADDR=192.168.1.2
NETMASK=255.255.255.0
GATEWAY=192.168.1.1
STP=on
DELAY=0
c. Restart the network by running the following command:
service network restart
d. You can review your interfaces and bridge by running the following
commands:
ifconfig
brctl show
Creating the virtual machines
v By using virt-manager (recommended)
The virt-manager application is a desktop user interface for managing
KVM virtual machines. It uses a GUI based front end for KVM creation,
installation and monitoring. It also allows an easy method for adding
hardware.
v By using the command line
Perform the following steps:
1. Create a base qcow2 image for Central Server and Region Server by
running the following command:
qemu-img create -f qcow2 -o cluster_size=2048k
/home/sco-base.qcow2 200G
2. Creating guests with virt-install, by running the following command:
virt-install --connect=qemu:///system \
--name=sco-base \
--ram=2048 \
--vcpus=2 \
--arch=x86_64 \
--os-type=linux \
--os-variant=rhel6 \
--hvm \
--virt-type kvm \
--cdrom=/opt/RHEL6.3-20120613.2-Server-x86_64-DVD1.iso \
--disk path=/home/sco-base.qcow2,format=qcow2,bus=virtio \
--network bridge=br0,model=virtio \
--accelerate \
--vnc
where
--arch Specifies the bits of the guest operating system. x86_64 is
64-bit and i686 is 32-bit.
--os-variant
Specifies the detailed variant of the guest operating system.
You can get the full list by running the man virt-install
command.
--disk Specifies the virtual disk or disks for installing the guest
operating system. If supported, enable virtio.
--network
Specifies the bridge device name. If supported, enable virtio.
The virt-viewer window is displayed. Follow the steps in the
installation wizard to complete the RHEL installation. Install the
Chapter 2. Installing 51
operating system with base mode. For operating systems that
support virtio, customize the partition layout with only /filesystem.
3. Configure the image file by performing the following steps:
a. Log in to the operating system by using virt-viewer:
virtviewer <ID or name>
For example:
virtviewer sco-base
Run the virsh list --all command to get a list of all the IDs or
names.
b. Disable SELinux by editing the /etc/selinux/config file and
specifying the following value:
SELINUX=disabled
c. Disable the firewall by running the following commands:
service iptables stop
service ip6tables stop
chkconfig iptables off
chkconfig ip6tables off
d. Edit the /etc/hosts file and specify the following value:
# Do not remove the following line, or various programs that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
e. Edit the /etc/sysconfig/network file and specify the following
value:
NETWORKING=yes
f. Edit the /etc/sysconfig/network-scripts/ifcfg-eth0 file and
specify the following values:
# Intel Corporation 82562GT 10/100 Network Connection
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Ethernet
PERSISTENT_DHCLIENT=1
Remove the write net rules by running the following commands:
mv /lib/udev/write_net_rules /lib/udev/write_net_rules.bak
mv /etc/udev/rules.d/70-persistent-net.rules /etc/udev/rules.d/70-persistent-net.rules.bak
mv /lib/udev/rules.d/75-persistent-net-generator.rules
/lib/udev/rules.d/75-persistent-net-generator.rules.bak
g. Shut down the virtual machine by running the following
command:
shutdown -h now
4. Create Central Server and Region Server image files by running the
following command:
qemu-img create -b <path>/sco-base.qcow2 -f qcow2 -F qcow2 <path>/<SERVER_NAME>.qcow2
5. Create XML templates file called <SERVER_NAME>.xml for Central
Server and Region Server with the following content:
<domain type=kvm>
<name>SERVER_NAME</name>
<memory unit=KiB>SERVER_RAM</memory>
<currentMemory unit=KiB>SERVER_RAM</currentMemory>
<vcpu placement=static>CPU_NUM</vcpu>
<os>
<type arch=x86_64>hvm</type>
<boot dev=hd/>
</os>
<features>
<acpi/>
<apic/>
</features>
52 IBM SmartCloud Orchestrator 2.3: User's Guide
<clock offset=localtime/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<emulator>/usr/libexec/qemu-kvm</emulator>
<disk type=file device=disk>
<driver name=qemu type=qcow2 cache=none/>
<source file=IMAGE_PATH/>
<target dev=vda bus=virtio/>
</disk>
<controller type=ide index=0>
<address type=pci domain=0x0000 bus=0x00 slot=0x01 function=0x1/>
</controller>
<controller type=usb index=0>
<address type=pci domain=0x0000 bus=0x00 slot=0x01 function=0x2/>
</controller>
<interface type=bridge>
<source bridge=br0/>
<model type=virtio/>
<address type=pci domain=0x0000 bus=0x00 slot=0x03 function=0x0/>
</interface>
<serial type=pty>
<target port=0/>
</serial>
<console type=pty>
<target type=serial port=0/>
</console>
<input type=tablet bus=usb/>
<input type=mouse bus=ps2/>
<graphics type=vnc port=-1 autoport=yes/>
<video>
<model type=cirrus vram=9216 heads=1/>
<address type=pci domain=0x0000 bus=0x00 slot=0x02 function=0x0/>
</video>
<memballoon model=virtio>
<address type=pci domain=0x0000 bus=0x00 slot=0x06 function=0x0/>
</memballoon>
</devices>
</domain>
Note: To define the SERVER_RAM and CPU_NUM values for each server,
see Hardware prerequisites on page 13. Replace SERVER_NAME and
IMAGE_PATH with the actual values.
6. Create the virtual machines by using the generated XML files by
running the following commands:
virsh define <IMAGE_PATH>/<SERVER_NAME>.xml
virsh start <SERVER_NAME>
7. Create a volume and attach the volume to Central Server 2 by
performing the following steps:
a. Run the following command:
qemu-img create -f qcow2 -o cluster_size=2048k
/hbase-disk.qcow2 5G
b. Create the attach_device.xml file with the following content:
<disk type=block device=disk>
<driver name=qemu type=qcow2/>
<source dev=<path>/hbase-disk.qcow2/>
<target dev=vdb bus=virtio/>
</disk>
c. Run the following command:
virsh attach-device <Central_Server_2_domain_ID> attach_device.xml
After setting up the KVM virtual machines to install the Central Server and Region
Server, start the virtual machine configuration by following the procedure
described in Preparing the central server and the region server on page 17.
Chapter 2. Installing 53
Setting up VMware virtual machines
VMware vCenter Server provides a centralized platform for managing your
VMware vSphere environments. You can automate and deliver a virtual
infrastructure. vCenter Server also supports the high availability solution. For more
information, see the VMware documentation.
After setting up the VMware virtual machines to install the Central Server and
Region Server, start the virtual machine configuration by following the procedure
described in Preparing the central server and the region server on page 17.
Managing networks
SmartCloud Orchestrator uses VLAN network that is also compatible with flat
interface. By default, the network is created according to the vm_ip_range
parameter in the region-server.cfg file while deploying the region server. If you
want to organize and manage instances with different networks, you can create
and configure more networks for SmartCloud Orchestrator.
Creating a network for a KVM region
There are two types of network for a KVM region.
Creating a VLAN-based network:
This topic describes how to create a VLAN-based network for SmartCloud
Orchestrator.
Before you begin
v Plan your network before you create a virtual machine, so that you reserve the
required IP addresses for the compute nodes.
v You cannot create multiple networks with overlapping IP ranges.
v The GATEWAY_IP must exist and belong to X.X.X.X/YY.
v You must configure the VLAN ID on the switch as a trunk.
v All KVM compute nodes must use the same interface to connect to the Region
Server, for example, eth0, eth1, or eth2.
Procedure
1. To create a network, run the following command on one line:
nova-manage network create --label=LABEL
--fixed_range_v4=X.X.X.X/YY --num_networks=1
--network_size=256
--gateway=GATEWAY_IP
--vlan=VLAN --bridge_interface=NIC
For example:
nova-manage network create --label=VLAN106
--fixed_range_v4=10.10.6.0/24 --num_networks=1
--network_size=256
--gateway=10.10.6.1
--vlan=106 --bridge_interface=eth3
The bridge_interface parameter is the interface that all compute nodes must
use to connect to the Region Server. The compute node does not create the
VLAN or bridge until a virtual machine is deployed.
2. Configure the nodes to use the new gateway. Otherwise, they might use their
host as a gateway. Run the following commands on the Region Server and each
compute node:
54 IBM SmartCloud Orchestrator 2.3: User's Guide
echo "dhcp-option=tag:LABEL,option:router,GATEWAY_IP" >>
/etc/dnsmasq.d/nova.gateway
echo "domain=DNS_SUFFIX,X.X.X.X/YY" >>
/etc/dnsmasq.d/nova.domain
3. Stop all dnsmasq services and restart the openstack-nova-network on the Region
Server or compute node:
killall dnsmasq
service openstack-nova-network restart
4. Decide which IP addresses you need to reserve. Reserve an IP address range
for the compute nodes, and use unreserved IP addresses for virtual machines.
For example, if the VLAN network is 192.0.2.0./22 and you plan to install 70
compute nodes, you reserve the IP address range 192.0.2.3 through
192.0.2.72 for the compute nodes, as follows:
a. Connect to the nova database.
b. In the fixed IPs table, update the reserved and host field for each IP
address that you want to reserve. For example, rtpvc11-01-bc01bld01 is a
newly installed compute node that does not host any virtual machine. To
reserve IP address 192.0.2.3 for compute node rtpvc11-01-bc01bld01, run
the following command:
db2 => update fixed_ips set host=rtpvc11-01-bc01bld01, reserved=1
where address=192.0.2.3 and deleted = 0
If you create a virtual machine host on this compute node, the IP address is
192.0.2.3.
c. Reserve IP addresses for the compute nodes that you plan to add in the
future. For example, to reserve the IP address range 192.0.2.73 through
192.0.2.150, run the following command:
db2 => update fixed_ips set reserved=1 where address >192.0.2.72 and
address < 192.0.2.151 and deleted = 0
You can then use the IP address range 192.0.2.151 through 192.0.2.254 for
the virtual machines.
5. To reserve an IP address, you have the following options:
v Option 1: Reserve the IP address via the nova command on the region server
to reserve an IP address which cannot be used by SmartCloud Orchestrator:
nova fixed-ip-reserve <fixed_ip>.
v Option 2: Update the database directly if there are too many fixed IP
addresses that need to be reserved. If there are some IP addresses in the
X.X.X.X/YY range and you do not want them to be used by SmartCloud
Orchestrator, you can exclude them. For example, to exclude the IP addresses
10.10.10.0-10.10.10.20, run the following commands:
db2 => connect to openstac
Database Connection Information
Database server = DB2/LINUXX8664 10.1.2
SQL authorization ID = DB2INST1
Local database alias = OPENSTACdb2
db2 => select schemaname from syscat.schemata
SCHEMANAME
------------------------------------------------
CIR14447
GLE14447
NOA14447
NULLID
SCE14447
Chapter 2. Installing 55
SQLJ
SYSCAT
SYSFUN
SYSIBM
SYSIBMADM
SYSIBMINTERNAL
SYSIBMTS
SYSPROC
SYSPUBLIC
SYSSTAT
SYSTOOLS
16 record(s) selected.
Find the user for nova, here it is NOA14447.
db2 => connect to openstac user $username using $password_for_db2
Database Connection Information
Database server = DB2/LINUXX8664 10.1.2
SQL authorization ID = NOA14447
Local database alias = OPENSTAC
Find the corresponding ID numbers for the reserved IPs.
db2 => select * from fixed_ips where ADDRESS=10.10.10.0
CREATED_AT UPDATED_AT DELETED_AT ID ADDRESS NETWORK_ID ALLOCATED LEASED RESERVED VIRTUAL_INTERFACE_ID
-------------------------- ----------- ----------- ---- ----------- ----------- --------- ------ -------- --------------------
2013-09-23-19.03.58.894240 - - 11 10.10.10.0 1 0 0 0 -
HOST INSTANCE_UUID DELETED
------- -------------- -------
- - 0
1 record(s) selected.
db2 => select * from fixed_ips where ADDRESS=10.10.10.20
CREATED_AT UPDATED_AT DELETED_AT ID ADDRESS NETWORK_ID ALLOCATED LEASED RESERVED VIRTUAL_INTERFACE_ID
-------------------------- ----------- ----------- ---- ----------- ----------- --------- ------ -------- --------------------
2013-09-23-19.03.58.951306 - - 32 10.10.10.20 1 0 0 0 -
HOST INSTANCE_UUID DELETED
------- -------------- -------
- - 0
1 record(s) selected.
Here we can see the ID numbers for the IP addresses 10.10.10.0-10.10.10.20
is 11-32. Update the database to reserve the IP addresses 10.10.10.0-
10.10.10.20 using the following command:
db2 => update fixed_ips set reserved=1 where id>10 and id<33
DB20000I The SQL command completed successfully.
6. Update DNS with the new network information. Run the following commands:
db2 => update NETWORKS set dns1=X.X.X.X, dns2=X.X.X.X
DB20000I The SQL command completed successfully.
where:
v The value X.X.X.X can be your DNS server or IP address of the Region
Server.
What to do next
Proceed to Configuring DNS for the Workload Deployer IP groups on page 61.
56 IBM SmartCloud Orchestrator 2.3: User's Guide
Creating a flat network:
You can create a flat network for workstations that are directly connected to each
other.
Procedure
1. Create a bridge. Select any number from 0 to 4095, for example, 4080:
brctl addbr br4080
Edit /etc/sysconfig/network-scripts/ifcfg-br4080 with the following
content:
DEVICE=br4080
TYPE="Bridge"
BOOTPROTO="none"
DELAY=0
ONBOOT=yes
Then run this command:
ifup br4080
2. Enslave the flat interface, for example eth3, to the bridge created in step 1.
Note: This interface must be different than the value of
managment_network_device in the region-server.cfg file.
Run:
brctl addif br4080 eth3
Note: Make sure there is no IP address on this flat interface. You can ensure
this with command ifconfig eth3 0.0.0.0 up.
Add BRIDGE=br4080 in the /etc/sysconfig/network-scripts/ifcfg-eth3 file as
in the following example:
DEVICE="eth3"
BOOTPROTO=none
NM_CONTROLLED="yes"
ONBOOT=yes
TYPE="Ethernet"
BRIDGE=br4080
3. Create a fake VLAN interface and enslave it by running the following
commands:
tunctl -t vlan4080
brctl addif br4080 vlan4080
Important: Complete steps 1 to 3 on the Region Server and each of the
compute nodes.
4. Run the following command on one line to create a network on the Region
Server:
nova-manage network create --label=newnet --fixed_range_v4=<X.X.X.X/YY>
--num_networks=1 --network_size=256 --gateway=<NEWNET_GW>
--vlan=4080 --bridge=br4080 --bridge_interface=eth3
5. Configure the nodes to use the new gateway. Run the following commands on
the Region Server and each compute node:
echo "dhcp-option=tag:newnet,option:router,NEWNET_GW" >>
/etc/dnsmasq.d/nova.gateway
echo "domain=DNS_SUFFIX,X.X.X.X/YY" >> /etc/dnsmasq.d/nova.domain
6. To reserve an IP address, you have the following options:
Chapter 2. Installing 57
v Option 1: Reserve the IP address via the nova command on the region server
to reserve an IP address which cannot be used by SmartCloud Orchestrator:
nova fixed-ip-reserve <fixed_ip>.
v Option 2: Update the database directly if there are too many fixed IP
addresses that need to be reserved. If there are some IP addresses in the
X.X.X.X/YY range and you do not want them to be used by SmartCloud
Orchestrator, you can exclude them. For example, to exclude the IP addresses
10.10.10.0-10.10.10.20, run the following commands:
db2 => connect to openstac
Database Connection Information
Database server = DB2/LINUXX8664 10.1.2
SQL authorization ID = DB2INST1
Local database alias = OPENSTACdb2
db2 => select schemaname from syscat.schemata
SCHEMANAME
------------------------------------------------
CIR14447
GLE14447
NOA14447
NULLID
SCE14447
SQLJ
SYSCAT
SYSFUN
SYSIBM
SYSIBMADM
SYSIBMINTERNAL
SYSIBMTS
SYSPROC
SYSPUBLIC
SYSSTAT
SYSTOOLS
16 record(s) selected.
Find the user for nova, here it is NOA14447.
db2 => connect to openstac user $username using $password_for_db2
Database Connection Information
Database server = DB2/LINUXX8664 10.1.2
SQL authorization ID = NOA14447
Local database alias = OPENSTAC
Find the corresponding ID numbers for the reserved IPs.
db2 => select * from fixed_ips where ADDRESS=10.10.10.0
CREATED_AT UPDATED_AT DELETED_AT ID ADDRESS NETWORK_ID ALLOCATED LEASED RESERVED VIRTUAL_INTERFACE_ID
-------------------------- ----------- ----------- ---- ----------- ----------- --------- ------ -------- --------------------
2013-09-23-19.03.58.894240 - - 11 10.10.10.0 1 0 0 0 -
HOST INSTANCE_UUID DELETED
------- -------------- -------
- - 0
1 record(s) selected.
db2 => select * from fixed_ips where ADDRESS=10.10.10.20
CREATED_AT UPDATED_AT DELETED_AT ID ADDRESS NETWORK_ID ALLOCATED LEASED RESERVED VIRTUAL_INTERFACE_ID
-------------------------- ----------- ----------- ---- ----------- ----------- --------- ------ -------- --------------------
2013-09-23-19.03.58.951306 - - 32 10.10.10.20 1 0 0 0 -
HOST INSTANCE_UUID DELETED
------- -------------- -------
- - 0
1 record(s) selected.
58 IBM SmartCloud Orchestrator 2.3: User's Guide
Here we can see the ID numbers for the IP addresses 10.10.10.0-10.10.10.20
is 11-32. Update the database to reserve the IP addresses 10.10.10.0-
10.10.10.20 using the following command:
db2 => update fixed_ips set reserved=1 where id>10 and id<33
DB20000I The SQL command completed successfully.
7. Update DNS with the new network information. Run the following commands:
db2 => update NETWORKS set dns1=X.X.X.X, dns2=X.X.X.X
DB20000I The SQL command completed successfully.
where:
v The value X.X.X.X can be your DNS server or IP address of the Region
Server.
You might need to update dhcp_start for your network in mysql:
db2 => update networks set dhcp_start=X.X.X.X where uuid=XXXXXXXX
8. Optional but recommended. It is better to have the IP range well planned for
usage, for example, explicitly reserve the 10 IP addresses for the compute
nodes:
db2 => update fixed_ips set host=compute_name_1 where address=10.10.10.21
db2 => update fixed_ips set host=compute_name_2 where address=10.10.10.22
...
db2 => update fixed_ips set host=compute_name_10 where address=10.10.10.30
9. If there is an existing DHCP service running on this flat network, run the
following command on all compute nodes including on the Region Server:
ebtables -t nat -A POSTROUTING -o $flat_interface -p IPv4 --ip-protocol udp
--ip-destination-port 67 -j DROP
Where $flat_interface is the flat interface you are going to make use of.
What to do next
Proceed with Configuring DNS for the Workload Deployer IP groups on page
61.
Creating a network for a VMware or Power region
This topic describes how to create a network for a VMware or Power region.
About this task
To create a network for a VMware or Power region, you must run the following
command on the region server:
/install_image/installer/scripts/ ./config_network.sh -d $database_password -p $password
-t $region_type -r $vm_ip_range -m $vm_ip_netmask -g $vm_gateway -H $host
-U $username -N $network -P $port
where:
-d db2_password
Defines the password of the database.
-p password
Defines the password of the administrator of the VMware (or Power)
vCenter VMControl.
-t region_type
Specifies one of region types (vmware/power)
Chapter 2. Installing 59
-r vm_ip_range
Defines the IP addresses for provisioned virtual machines.
-m vm_ip_netmask
Defines the netmask of vm_ip_range.
-g vm_gateway
Defines the gateway IP address for vm_ip_range.
-H host
Defines the hostname or IP address of vCenter/VMControl.
-U username
Defines the user name of the administrator of vCenter/VMControl.
Note: SmartCloud Orchestratordoes not support Domain User Account for
vCenter.
-N network
Defines the network name defined in vCenter/VMControl.
-P port
Defines the port to connect to vCenter/VMControl (the default is: 443)
For example, if your vCenter is 10.10.0.5 with username Administrator and
password mypassword, you can create a new network for VMware region by
running the following command:
./config_network.sh -d passw0rd -p mypassword -t vmware -r 10.10.0.20-10.10.0.30
-m 255.255.255.0 -g 10.10.0.1 -H 10.10.0.5 -U Administrator -N VM Network -P 443
What to do next
(Optional) To reserve an IP address in the database, you have the following
options:
v Option 1: Reserve the IP address via the nova command on the region server to
reserve an IP address which cannot be used by SmartCloud Orchestrator: nova
fixed-ip-reserve <fixed_ip>.
v Option 2: Update the database directly if there are too many fixed IP addresses
that need to be reserved. If there are some IP addresses in the X.X.X.X/YY range
and you do not want them to be used by SmartCloud Orchestrator, you can
exclude them. For example, to exclude the IP addresses 10.10.10.0-10.10.10.20,
run the following commands:
db2 => connect to openstac
Database Connection Information
Database server = DB2/LINUXX8664 10.1.2
SQL authorization ID = DB2INST1
Local database alias = OPENSTACdb2
db2 => select schemaname from syscat.schemata
SCHEMANAME
------------------------------------------------
CIR14447
GLE14447
NOA14447
NULLID
SCE14447
SQLJ
SYSCAT
SYSFUN
60 IBM SmartCloud Orchestrator 2.3: User's Guide
SYSIBM
SYSIBMADM
SYSIBMINTERNAL
SYSIBMTS
SYSPROC
SYSPUBLIC
SYSSTAT
SYSTOOLS
16 record(s) selected.
Find the user for nova, here it is NOA14447.
db2 => connect to openstac user $username using $password_for_db2
Database Connection Information
Database server = DB2/LINUXX8664 10.1.2
SQL authorization ID = NOA14447
Local database alias = OPENSTAC
Find the corresponding ID numbers for the reserved IPs.
db2 => select * from fixed_ips where ADDRESS=10.10.10.0
CREATED_AT UPDATED_AT DELETED_AT ID ADDRESS NETWORK_ID ALLOCATED LEASED RESERVED VIRTUAL_INTERFACE_ID
-------------------------- ----------- ----------- ---- ----------- ----------- --------- ------ -------- --------------------
2013-09-23-19.03.58.894240 - - 11 10.10.10.0 1 0 0 0 -
HOST INSTANCE_UUID DELETED
------- -------------- -------
- - 0
1 record(s) selected.
db2 => select * from fixed_ips where ADDRESS=10.10.10.20
CREATED_AT UPDATED_AT DELETED_AT ID ADDRESS NETWORK_ID ALLOCATED LEASED RESERVED VIRTUAL_INTERFACE_ID
-------------------------- ----------- ----------- ---- ----------- ----------- --------- ------ -------- --------------------
2013-09-23-19.03.58.951306 - - 32 10.10.10.20 1 0 0 0 -
HOST INSTANCE_UUID DELETED
------- -------------- -------
- - 0
1 record(s) selected.
Here we can see the ID numbers for the IP addresses 10.10.10.0-10.10.10.20
is 11-32. Update the database to reserve the IP addresses 10.10.10.0-
10.10.10.20 using the following command:
db2 => update fixed_ips set reserved=1 where id>10 and id<33
DB20000I The SQL command completed successfully.
Proceed with what documented in Configuring DNS for the Workload Deployer
IP groups.
Configuring DNS for the Workload Deployer IP groups
Configure the Workload Deployer IP groups to be able to resolve host name.
About this task
The following configuration applies to:
v SmartCloud Orchestrator uses a built-in DNS (standalone environment).
v SmartCloud Orchestrator uses a built-in DNS but with the corporate DNS being
the parent DNS.
On central server 1, run:
/install_image/installer/scripts/delegate_region.sh <region name> <region ip> [vm_ip_range]
where
Chapter 2. Installing 61
v region-name is a required parameter. The region name of the new added
network.
v region ip is a required parameter. The ip address of the region server.
v vm_ip_range is an optional parameter, required for new added networks. The IP
range of the new added network. For example, 10.10.10.100-10.10.10.200.
For SmartCloud Orchestrator that uses the corporate DNS and no built-in DNS,
refer to Preparing the central server and the region server on page 17 for manual
work.
Deleting the existing networks
The commands can be used to disassociate the project from the network, delete an
existing network, or delete the virtual machines that belong to it.
Procedure
v To delete all virtual machines in the network through GUI or CLI, run:
nova delete xxxx
v To disassociate the project from the network, run:
nova-manage network modify x.x.x.x/yy --disassociate-project
v To delete a network, run:
nova-manage network delete x.x.x.x/yy
v If the network that you want to delete is not a network created in the out-of-box
installation, delete the related bridges and the dnsmasq service on the Region
Server and each of the compute nodes. Run the following commands:
ifconfig brxxxx down
brctl delbr brxxxx
killall dnsmasq
/etc/init.d/openstack-nova-network restart
Shutting down or starting Central Servers and Region Servers
This topic describes how to shut down or start Central Servers and Region Servers.
To shut down the Central Servers and the Region Servers, follow this order:
1. Shut down Central Server 1.
2. Shut down Central Server 2.
3. Shut down Central Server 3.
4. Shut down Central Server 4.
5. Shut down the Region Servers.
To start the Central Servers and the Region Servers, follow these steps:
1. Start Central Server 1.
2. Make sure that all services are started on Central Server 1, you can run this
command to check this:
# netstat -tnlp | grep 5000
if the output of the command is like the following, then you can proceed:
# netstat -tnlp | grep 5000
tcp 0 0 0.0.0.0:50000 0.0.0.0:* LISTEN 6856/db2sysc 0
3. Start Central Server 2.
4. Start Central Server 3.
5. Start Central Server 4.
62 IBM SmartCloud Orchestrator 2.3: User's Guide
6. Start the Region Servers.
To reboot the Central Servers and the Region Servers, follow these steps:
1. Reboot Central Server 1.
2. Make sure that all services are started on Central Server 1, you can run this
command to check this:
# netstat -tnlp | grep 5000
if the output of the command is like the following, then you can go next:
# netstat -tnlp | grep 5000
tcp 0 0 0.0.0.0:50000 0.0.0.0:* LISTEN 6856/db2sysc 0
3. Reboot Central Server 2.
4. Reboot Central Server 3.
5. Reboot Central Server 4.
6. Reboot the Region Servers.
Integrating SmartCloud Orchestrator with VMware vCenter
Integrate your SmartCloud Orchestrator environment with VMware vCenter to
effectively manage your cloud environment based on VMware ESX Systems.
Before you begin
Restriction: Metadata service is not supported in a VMware environment.
About this task
After OpenStack SmartCloud Extension has been deployed, you can use the CLI to
configure SmartCloud Orchestrator to connect to the existing vCenter.
Procedure
1. Make sure that the OpenStack services are running, including the SmartCloud
service.
2. Create a vCenter backend connection for SmartCloud:
a. Verify that the source file works in the OpenStack environment:
# cd /opt/ibm/openstack/iaas/smartcloud/bin
# source ~/keystonerc
b. Add an existing vCenter environment:
#/opt/ibm/openstack/iaas/smartcloud/bin/nova-cloud-create
[--os-region-name <region-name>] <os-hostname> <name>
<hostname> <username> <password> <type>[<port>]
where:
<os-hostname>
Fully qualified host name where the OpenStack SmartCloud driver
is running, normally the output of hostname --fqdn.
<name>
The cloud name. The cloud name must be unique across a region.
<hostname>
Host name or IP address of the vCenter or VMControl system.
<username>
User name of the administrator for the system.
Chapter 2. Installing 63
<password>
Password of the administrator for the system.
<type>
Region type. Either VMware or VMControl.
<port>
Optional. Port to connect to the system (defaults: type VMware 443
and VMControl 8422).
<region-name>
Optional. The OpenStack region name. Must be the first in the
command argument.
Example:
# /opt/ibm/openstack/iaas/smartcloud/bin/nova-cloud-create
rs-34-1.customer.ibm.com RegionVMW 172.16.133.254
Administrator password VMware 443
c. Verify that the vCenter backend connection for SmartCloud:
# /opt/ibm/openstack/iaas/smartcloud/bin/nova-cloud-show
{"username": "administrator"
"jmsPort": 61617
"name": "RegionVMW"
"hostname": "172.16.133.254"
"port": 443
"state":
{"id": "OK"
"label": "OK"}
"cloudType": "VMware"
"timeout": 600
"external_uri": "172.16.133.254:443"
"id": "rs-34-1:301"
"description": "OpenStack managed VMware"}
3. Match nova-network with VMware hypervisor networks queried from vCenter:
a. Check if the existing nova-network IP addresses are available for the
VMware deployment. If not, create a workable network. For example:
# nova-manage network create --fixed_range_v4=172.16.133.0/24 --label vm-network --bridge=br4090
# nova-manage network list
id IPv4 IPv6 start addres DNS1 DNS2 VlanID project uuid
1 172.16.133.0/24 None 172.16.133.10 172.16.34.200 172.16.34.205 None None
83d7f72a-3b03-48c5-a6fa-19be15daae18
Note: For more information about the OpenStack command-line interface,
see the OpenStack End User Guide.
b. Get the available networks list from vCenter:
# ./opt/ibm/openstack/iaas/smartcloud/bin/nova-netext-show [--os-region-name <region-name>[raw]
where:
<cloud name>
Name of the cloud. All clouds can be listed with nova-cloud-show.
[region-name]
Optional. The OpenStack region name. Must be the first in the
command argument.
[raw] Optional. Show the output in raw JSON form.
Example:
#/opt/ibm/openstack/iaas/smartcloud/bin/nova-netext-show RegionVMW
{"enableDhcpV6": false
64 IBM SmartCloud Orchestrator 2.3: User's Guide
"activeDirectoryPassword": null
"name": "VM Network"
"domainName": null
"computerNamePrefix": null
"networkName": "VM Network"
"cloudId": "rs-34-1:301"
"activeDirectory": null
"wins2": null
"hostnamePrefix": null
"enableDhcp": false
"wins1": null
"cloudType": "VMware"
"activeDirectoryUser": null
"osNetworkId": "83d7f72a-3b03-48c5-a6fa-19be15daae18"
"id": "2792e082-a1db-4033-81c5-740d0e8200b3"
"workgroup": null}
c. Match the target hypervisor network with nova network.
# ./nova-netext-match [--os-region-name <region-name>] <cloud name>
<network_name>
<nova_network_id> [domainName]
where:
<cloud name>
Name of the cloud. All clouds can be listed with nova-cloud-show.
<network name>
Name of the network extension. All network extensions are listed by
cloud with nova-netext-show.
<nova network id>
The network ID list in nova.
[domain name]
Optional. Domain name applied to virtual servers on this network.
[region-name]
Optional. The OpenStack region name. Must be the first in the
command argument.
# ./nova-netext-match RegionVMW "VM Network" 83d7f72a-3b03-48c5-a6fa-19be15daae18
{"networkExtension": {"enableDhcpV6": false, "activeDirectoryPassword": null, "name": "VM Network",
"domainName": null, "computerNamePrefix": null, "networkName": "VM Network", "cloudId":
"rs-34-1:301",
"activeDirectory": null, "wins2": null, "hostnamePrefix": null, "enableDhcp": false, "wins1": null,
"cloudType": "VMware", "activeDirectoryUser": null, "osNetworkId":
"83d7f72a-3b03-48c5-a6fa-19be15daae18",
"id": "2792e082-a1db-4033-81c5-740d0e8200b3", "workgroup": null}}
4. Verify the connectivity to vCenter. Verify the configuration. Check if the virtual
machine template has been synchronized as image in Glance by comparing the
list with the virtual machine templates showing in the vCenter:
> glance index
ID Name Disk Format Container FormatSize
------------------------------------ -------------------- ---------------------------------
af53c607-f9e9-4048-b6ee-55d8c62fef39 win2k8r2ee raw ovf 0
f0f676f4-98ef-445a-b685-966252b99141 takeover-248 raw ovf 0
45c8d691-fc1c-447b-8ae7-e7e5cc127d5b SCE Default Image raw ovf 0
Check if the virtual machine has been synchronized as server in nova by
comparing the list with the virtual machines showing in the vCenter:
> nova list
+--------------------------------------+-------------------+---------+----------+
| ID | Name | Status | Networks |
+--------------------------------------+-------------------+---------+----------+
| 8a2172a3-0a22-4403-97aa-23e0fc72ae94 | hilltest | ACTIVE | |
Chapter 2. Installing 65
| b398a87f-8db6-40c4-b6d4-fbcb9c34a5ae | q3 | ACTIVE | |
| f3ee86e1-8804-455c-8a4f-83ef98064bb8 | takeover-demo-248 | SHUTOFF | |
| d83940fb-0c94-45f0-8364-f6f1c5e7db60 | vCentGMN | ACTIVE | |
+--------------------------------------+-------------------+---------+----------+
Restriction: SCE Default Image is used to provide details for instances that
have no information about the images that created them. You cannot use the
image to deploy a virtual machine, but do not delete it.
5. Boot a server:
> nova boot --image af53c607-f9e9-4048-b6ee-55d8c62fef39 --flavor m1.tiny mytest
Note: The Virtual Machine template in vCenter must be installed with
VMware-tools. This is mandatory if you want to use this template to boot
servers from OpenStack.
Note: The virtual machine template must have the operating system
successfully installed.
Note: The flavor value must be bigger than the virtual machine template size
or use m1.tiny which is to match the template size.
6. Configure the Virtual Image Library for VMware (see Configuring Virtual
Image Library for VMware on page 305).
7. Additional CLIs:
v /opt/ibm/openstack/iaas/smartcloud/bin/nova-cloud-delete <cloud id>
where cloud id is the ID of the cloud to delete. Use nova-cloud-show to find
the ID.
v /opt/ibm/openstack/iaas/smartcloud/bin/nova-cloud-delete-byname <cloud name>
where cloud name is the name of the cloud to delete. Use nova-cloud-show to
find the name.
v nova-cloud-pingtest <hostname> <username> <password>
<type> [port]
where hostname is the name of the vCenter system, username is the username
of the system administrator, password is the administrator's password, type is
either VMware or VMControl, [port is the port to connect to the system
(defaults: type VMware 443).
v nova-netext-unset <cloud name> <network name> <nova network id>
where cloud name is the name of the cloud (all clouds can be listed with
nova-cloud-show), network name is the name of the network (all networks can
be listed with nova-netext-show).
Integrating SmartCloud Orchestrator with VMControl
Integrate your SmartCloud Orchestrator environment with IBM Systems Director
VMControl to effectively manage your cloud environment based on IBM Power
Systems

.
About this task
After OpenStack SmartCloud Extension has been deployed, you can use the CLI to
configure SmartCloud Orchestrator to connect to the existing VMControl.
66 IBM SmartCloud Orchestrator 2.3: User's Guide
Procedure
1. It is necessary to upgrade the Director/VMControl or Flex System Manager
(FSM) to the IBM Director 6.3.3.1, which ships with VMControl 2.4.3.1.
However, SmartCloud Orchestrator requires an additional VMControl APAR
that needs to be loaded on top of VMControl 2.4.3.1 This fix is bundled with
SmartCloud Orchestrator inside the VMControl-upgrade directory. The
vmc-update.2.4.3.1-201310251457-IC97186.zip file is for the standalone
Director/VMControl environment and the fsmfix_vmc-update.2.4.3.1-
201310251457-IC97186.zip is for the Flex System Manager (FSM). These files
must be copied over to the VMC/FSM server and be decompressed there.
From there, you can use the Director UI to install the updates or use the CLI as
follows:
smcli importupd -v -r <directory_of_decompressed_contents>
smcli lsupd *IC96480
(which should return something similar to the following
three lines:
confirm thatthose updates were imported to the Director
upgrade manager):
com.ibm.ensemble.local.mgmt.feature_2.4.3.1-201309300916- IC96480
com.ibm.vmcontrol.rf.power.feature_2.4.3.1-201309300916-
IC96480
com.ibm.vmcontrol.services.feature_2.4.3.1-201309300916-
IC96480
smcli installneeded (this drives the install of those updates into director )
Once finished, one must restart Director after this installation using the smstop
and smstart commands.
2. Make sure that the OpenStack services are running, including the SmartCloud
service.
3. Create a VMControl backend connection for SmartCloud.
a. Verify that the source file works in the OpenStack environment:
# cd /opt/ibm/openstack/iaas/smartcloud/bin
# source ~/keystonerc
b. Add an existing VMControl environment:
# ./nova-cloud-create [--os-region-name <region-name>] <openstack-hostname>
<cloud_name> <VMControl-hostname> <VMControl-username>
<VMControl-password> <type> [port]
where:
<region-name>
Optional. The OpenStack region name. If specified, this argument
must be the first argument in the command.
<openstack-hostname>
The name of the host where the OpenStack SmartCloud driver is
running. This value must be the same as the result returned by the
hostname command.
<cloud_name>
The cloud name. This name must be unique across a region.
<VMControl-hostname>
The host name or IP address of the VMControl system.
<VMControl-username>
The user name of the administrator of the VMControl system.
<VMControl-password>
The password of the administrator of the VMControl system.
Chapter 2. Installing 67
<type> The type of system. Specify VMControl.
[port] Optional. The port to connect to the VMControl system. The default
port for VMControl is 8422.
Example:
# ./nova-cloud-create sco-vmw-29-fb vmcontrol 172.16.22.6
root object00 VMControl
{ "cloud":{ "driver":"sco-vmw-29-fb", "name":"vmcontrol",
"description":"OpenStack managed VMControl",
"hostname":"172.16.22.6",
"username":"root", "password":"object00", "type":"VMControl",
"port":8422, "version":"2.4.3.x"} }
{"cloud": {"username": "root", "jmsPort": 61617, "name": "vmcontrol",
"hostname": "172.16.22.6", "port": 8422, "version": "2.4.3.x",
"timeout": 600, "cloudType": "VMControl", "id":
"sco-vmw-29-fb:301",
"description": "OpenStack managed VMControl"}}
{ "cloud":{ "cloudId":"sco-vmw-29-fb:301", "name":"vmcontrol",
"description":"OpenStack managed VMControl",
"hostname":"172.16.22.6",
"username":"root", "password":"object00",
"type":"VMControl", "port":8422} }
4. Match nova-network with Power hypervisor networks queried from
VMControl.
a. Check whether the existing nova-network IP addresses are available for the
Power LPAR deployment. If not, create a workable network. Here the
network 172.17.40.0/22 does not work for Power LPAR deployment.
# ./nova-manage network list
id IPv4 IPv6 start address DNS1
1 172.17.40.0/22 None 172.17.41.230 172.17.41.224
DNS2 VlanID project uuid
172.17.41.224 None None 215b4dfa-11f4-47d5-872d-4e0620057b16
# nova-manage network create --fixed_range_v4 172.16.22.0/24 --gateway 172.16.22.1
--dns1 172.17.41.224 --label vmcnet --fixed_cidr 172.16.22.224/28 --bridge br4090
# nova-manage network list
id IPv4 IPv6 start address DNS1
1 172.17.40.0/22 None 172.17.41.230 172.17.41.224
2 172.16.22.0/24 None 172.16.22.2 172.17.41.224
DNS2 VlanID project uuid
172.17.41.224 None None 215b4dfa-11f4-47d5-872d-e0620057b16
None None None 365a1ab0-94e2-40a5-8601-d98c3584536f
b. Get the available networks list from VMControl.
# ./nova-netext-show [--os-region-name <region-name>] <cloud_name> [raw]
where:
<region-name>
Optional. The OpenStack region name. If specified, this argument
must be the first argument in the command.
<cloud_name>
The cloud name. To show all cloud names, use the nova-cloud-show
command.
[raw] Show the output in raw JSON format.
Example:
# ./nova-netext-show vmcontrol
{"enableDhcpV6": false
"activeDirectoryPassword": null
"name": "Discovered/99/0/ETHERNET0 (VLAN 99
68 IBM SmartCloud Orchestrator 2.3: User's Guide
Not Bridged)"
"domainName": null
"computerNamePrefix": null
"networkName": "Discovered/99/0/ETHERNET0"
"cloudId": "sco-vmw-29-fb:301"
"activeDirectory": null
"wins2": null
"hostnamePrefix": null
"enableDhcp": false
"wins1": null
"cloudType": "VMControl"
"activeDirectoryUser": null
"osNetworkId": null
"id": "5c411f0d-ac77-4dce-807a-b849de6d928a"
"workgroup": null}
{"enableDhcpV6": false
"activeDirectoryPassword": null
"name": "Discovered/1/0/ETHERNET0 (VLAN 1
Bridged)"
"domainName": null
"computerNamePrefix": null
"networkName": "Discovered/1/0/ETHERNET0"
"cloudId": "sco-vmw-29-fb:301"
"activeDirectory": null
"wins2": null
"hostnamePrefix": null
"enableDhcp": false
"wins1": null
"cloudType": "VMControl"
"activeDirectoryUser": null
"osNetworkId": null
"id": "1c94bf17-6499-416a-8e4f-4391e4105fa6"
"workgroup": null}
c. Match the target hypervisor network with nova network.
# ./nova-netext-match [--os-region-name <region-name>] <cloud name>
<network_name> <nova_network_id> [domainName]
where:
<region-name>
Optional. The OpenStack region name. If specified, this argument
must be the first argument in the command.
<cloud_name>
The cloud name. To show all cloud names, use the nova-cloud-show
command.
<network_name>
The name of the network extension. To list all network extensions
by cloud, use the nova-netext-show command.
<nova_network_id>
The network ID list in nova.
[domainName]
Must match the domain name used for that network on the NIM
server if one is being used. NIM-based deployments can fail if the
domain name returned by a reverse DNS lookup on the NIM server
does not match this value.
Example:
# ./nova-netext-match vmcontrol "Discovered/1/0/ETHERNET0"
365a1ab0-94e2-40a5-8601-d98c3584536f mydomainname.com
{"networkExtension": {"enableDhcpV6": false,
"activeDirectoryPassword": null,
Chapter 2. Installing 69
"name": "Discovered/1/0/ETHERNET0 (VLAN 1, Bridged)",
"domainName": "mydomainname.com",
"computerNamePrefix": null, "networkName":
"Discovered/1/0/ETHERNET0", "cloudId": "sco-vmw-29-fb:301",
"activeDirectory": null, "wins2": null,
"hostnamePrefix": null, "enableDhcp": false, "wins1": null,
"cloudType": "VMControl", "activeDirectoryUser":
null, "osNetworkId": "365a1ab0-94e2-40a5-8601-d98c3584536f",
"id": "1c94bf17-6499-416a-8e4f-4391e4105fa6", "workgroup": null}}
Note: If there are multiple Power networks in the environment, make sure
to use the right network in OpenStack to match with the Power network.
5. Create an OpenStack flavor for the Power instance deployment.
Note: Many Power images have predefined limit properties that restrict the
ability to deploy a virtual machine with traditional OpenStack flavors as they
unnecessarily require a specific amount of cpu and memory. For example,
many IBM PureApp Hypervisor Edition images require exactly 1 vCPU and 3
GB of memory. It is strongly recommended to run the ./nova-remove-ovf-
limits <cloud-name> command after those images have been loaded into
VMControl to remove those limits so that traditional OpenStack flavors can be
used. However, one can still define your own custom flavors (for details, refer
toCreating new flavors in OpenStack on page 560).
# ./nova flavor-create [--ephemeral <ephemeral>] [--swap <swap>]
[--rxtx-factor <factor>] [--is-public <is-public>]
<name> <id> <ram> <disk> <vcpus>
where:
<ephemeral>
The ephemeral space size in GB. The default value is 0.
<swap>
The swap space size in MB. The default value is 0.
<factor>
The RX/TX factor. The default value is 1.
<is-public>
Make the flavor accessible to the public. The default value is true.
<name>
The name of the new flavor.
<id> A unique ID (integer or UUID) for the new flavor. If you specify auto, a
UUID is generated.
<ram> The memory size in MB.
<disk> The disk size in GB.
<vcpus>
The number of vCPUs.
Example:
# ./nova flavor-create --is-public True IPAS 6 4096 30 1
+----+------+-----------+------+-----------+------+-------+-------------+-----------+-------------+
| ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public | extra_specs |
+----+------+-----------+------+-----------+------+-------+-------------+-----------+-------------+
| 6 | IPAS | 4096 | 30 | 0 | | 1 | 1.0 | True | {} |
+----+------+-----------+------+-----------+------+-------+-------------+-----------+-------------+
6. To customize flavors for Power features, refer to Customizing flavors for
Power features on page 561.
Example:
70 IBM SmartCloud Orchestrator 2.3: User's Guide
# ./nova flavor-key IPAS set ibm-smartcloud:cpushu=0.3
./nova flavor-key IPAS set ibm-smartcloud:memmax=32768
./nova flavor-key IPAS set ibm-smartcloud:cpushmaxu=4
./nova flavor-key IPAS set ibm-smartcloud:cpushmax=4
./nova flavor-list
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------
| ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------
| 1 | m1.tiny | 512 | 0 | 0 | | 1 | 1.0 | True
| 2 | m1.small | 2048 | 20 | 0 | | 1 | 1.0 | True
| 3 | m1.medium | 4096 | 40 | 0 | | 2 | 1.0 | True
| 4 | m1.large | 8192 | 80 | 0 | | 4 | 1.0 | True
| 5 | m1.xlarge | 16384 | 160 | 0 | | 8 | 1.0 | True
| 6 | IPAS | 4096 | 30 | 0 | | 1 | 1.0 | True
| | | | | | | | |
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------
+----------------------------------------------------------------------------+
| extra_specs |
+----------------------------------------------------------------------------+
| {} |
| {} |
| {} |
| {} |
| {} |
| {uibm-smartcloud:cpushu: u0.3, uibm-smartcloud:memmax: u32768, |
| uibm-smartcloud:cpushmaxu: u4, uibm-smartcloud:cpushmax: u4} |
+----------------------------------------------------------------------------+
For SCS deployment, you can use the extra_specs flavor to customize the
storage connection method. The default method is VSCSI. The NPIV method
requires hardware support.
Example:
# ./nova flavor-key IPAS set ibm-smartcloud:storageconnection=NPIV
For SCS deployment, you can use the extra_specs flavor to customize the
storage connection method. The default method is VSCSI. The NPIV method
requires hardware support and has a limitation (for details, refer to Product
limitations on page 1089).
7. Optional: When you add new hosts, clean up the hypervisor list. For more
information, see Must remove hosts that are not eligible for cloud on page
1118.
What to do next
You can now log into the SmartCloud Orchestrator interface to register images and
deploy VMs from those registered images.
Setting NTP servers
Use Network Time Protocol (NTP) servers to maintain a synchronized time and
date across your systems and virtual machines.
About this task
A configured NTP server that is accessible by your virtual machines is required to
successfully deploy a virtual application pattern or virtual system pattern. When
virtual application patterns or virtual system patterns are deployed, the NTP
server is used to establish the system time for your virtual machines. Without a
synchronized date and time, problems might occur resulting in incomplete
Chapter 2. Installing 71
deployments or failure to start virtual application instances or virtual system
instances. If an NTP server is not used, the system clocks for the SmartCloud
Orchestrator environment and the hypervisors must be synchronized manually.
Procedure
1. In Central Server 3, edit the /opt/ibm/rainmaker/purescale.app/private/
expanded/ibm/scp.ui-1.0.0/config/openstack.config file.
2. In the /config/openstack section, set the NTP servers as in the following
example:
"ntp_servers": [
"127.0.0.1",
"127.0.0.2",
"127.0.0.3",
"127.0.0.4"
]
Note: The list of the defined NTP servers is propagated to the provisioned
virtual machines and it is used to configure NTP on them.
3. Restart the Workload Deployer service by running the following command:
service iwd restart
Results
After completing these steps, you have defined an NTP server to maintain clock
synchronization across your environments.
Configuring Memcached cache size
SmartCloud Orchestrator uses Memcached with an in-memory storage and
expiration dates to manage the tokens in case the performance is impacted by large
numbers of tokens that are generated by multiple concurrent users, you could
increase the cache size according to your requirement.
Procedure
1. Login to Central Server 2, edit the /etc/sysconfig/memcached file and set the
CACHESIZE=4096 parameter. Then restart the service to take effect by running the
following command:
service memcached restart
2. Verify that the Memcached cache size is increased by running memcached-tool
127.0.0.1:11211 stats. If Memcached works properly, the values of
total_items, total_connections, and get_hits are increasing.
Configuring Virtual Image Library proxies
Use distributed components, called proxies, to offload the typical image
management operations that are performed by Virtual Image Library to remote
sites. Using proxies, you do not need to access remote data stores directly from the
main server. The proxies also provide a more efficient solution for managing
segregated networks and slow links.
About this task
By default, the installer configures Virtual Image Library to work with a remote
proxy that is installed on the Region Server so that it can manage the OpenStack
system.
72 IBM SmartCloud Orchestrator 2.3: User's Guide
If you want to add more proxies or modify the existing configuration, you must
edit the origami configuration file that stores the main configuration properties
which determine which proxy manages which domain. You can find the file on
both the Virtual Image Library server and any remote node where you installed
the proxy. Even if the structure is the same, the file that is related to the Virtual
Image Library server contains some additional configuration sections to identify
the knowledge base and all the deployed proxies that it must be aware of to
properly distribute the actions to particular nodes.
Procedure
1. The /etc/origami/origami.config file on the Virtual Image Library server,
contains the following proxies section:
"proxies": [
{
"url": "local://",
"capabilities": ["crawl", "cache", "portability"],
"connectivity": ["Central Server 2","localhost","127.0.0.1"],
"agent_id":"Central Server 2",
"enabled": true
},
{
"url": "http://<PROXYAGENT>:8123/origami",
"capabilities": ["crawl", "cache", "portability"],
"connectivity": ["<PROXYAGENT>"],
"agent_id": "<PROXYAGENT>",
"enabled": true
},
...
]
2. To define a new proxy, run the following commands:
cd /home/library
./configureProxy.sh --addProxyDef -h <PROXYAGENT_IP> -c <Hypervisor_Manager_IP>
where
v <PROXYAGENT_IP> is the IP address of the new proxy agent.
v <Hypervisor_Manager_IP> is the IP address of the hypervisor manager. If
your hypervisor manager is VMware, you must specify both the IP address
and port in the format <Hypervisor_Manager_IP>:<port> (the default port
value is 443).
As an alternative, if you already defined a Virtual Image Library proxy, you can
add a new hypervisor manager to be managed by the existing proxy by
running the following commands:
cd /home/library
./configureProxy.sh --addRepDef -h <PROXYAGENT_IP> -c <Hypervisor_Manager_IP>
where
v <PROXYAGENT_IP> is the IP address of the proxy agent that is already defined
in the origami.config file.
v <Hypervisor_Manager_IP> is the IP address of the new hypervisor manager. If
your hypervisor manager is VMware, you must specify both the IP address
and port in the format <Hypervisor_Manager_IP>:<port> (the default port
value is 443).
3. Restart the proxy service on the Virtual Image Library server by running the
following command:
service vilProxy restart
Chapter 2. Installing 73
4. If the Virtual Image Library proxy is not installed, follow the procedure that is
described in Installing the proxy component on page 301 to install the proxy
on a new machine.
5. In the proxy machine, configure the Virtual Image Library proxy by running
the following commands:
cd /home/library
./configureProxy.sh --addRepDef -c <Hypervisor_Manager_IP>
where <Hypervisor_Manager_IP> is the IP address of the hypervisor manager to
be managed by the proxy. If your hypervisor manager is VMware, you must
specify the both IP address and port in the format
<Hypervisor_Manager_IP>:<port> (the default port value is 443). The proxy
definition is modified in the /etc/origami/origami.config file.
6. Restart the Virtual Image Library proxy on the proxy machine by running the
following command:
service vilProxy restart
Results
You configured the Virtual Image Library proxy. For more information about
configuring Virtual Image Library proxies, see Configuring Virtual Image Library
server and remote proxy components on page 303.
Removing a Compute Node
Follow this procedure to remove a KVM compute node from SmartCloud
Orchestrator.
Procedure
1. List the services on all the compute nodes:
On the Region Server, run:. ~/openrc && nova service-list
+------------------+--------------+----------+---------+-------+----------------------------+
| Binary | Host | Zone | Status | State | Updated_at |
+------------------+--------------+----------+---------+-------+----------------------------+
| nova-cells | rs-135-3 | internal | enabled | up | 2013-10-09T06:47:41.699503 |
| nova-cert | rs-135-3 | internal | enabled | up | 2013-10-09T06:47:48.464156 |
| nova-compute | rs-5-blade-6 | nova | enabled | up | 2013-10-09T06:47:42.402192 |
| nova-conductor | rs-135-3 | internal | enabled | up | 2013-10-09T06:47:49.713611 |
| nova-network | rs-5-blade-6 | internal | enabled | up | 2013-10-09T02:47:32.317892 |
| nova-consoleauth | rs-135-3 | internal | enabled | up | 2013-10-09T06:47:49.928091 |
| nova-scheduler | rs-135-3 | internal | enabled | up | 2013-10-09T06:47:49.929776 |
+------------------+--------------+----------+---------+-------+----------------------------+
2. Disable the nova compute and nova network service on the compute node you
want to remove. On the Region Server, run: nova-manage service disable
--host=<host> --service=<services>.
For example, if you want to remove node rs-5-blade-6, run the following
commands:
nova-manage service disable --host=rs-5-blade-6 --service=nova-network
nova-manage service disable --host=rs-5-blade-6 --service=nova-compute
3. If you want to remove the compute node completely, you must manually
remove it from the database, create a file drop_node.sql with following
contents:
connect to openstac user <dbuser> using <dbpassword>
delete from compute_node_stats where compute_node_id in
(select id from compute_nodes
where hypervisor_hostname=rs-5-blade-6)
delete from compute_nodes where hypervisor_hostname=rs-5-blade-6
delete from services where host=rs-5-blade-6
74 IBM SmartCloud Orchestrator 2.3: User's Guide
Log on to central server(share db) / region server(non-shared db) with
user db2inst1 and run the sql script:
su - db2inst1
db2 -tf drop_node.sql
4. (Optional, this step is required before re-adding a removed compute back to the
Region Server) On the Region Server, remove the file /iaas/chef-repo-srv/
data/nodes/<compute_node_hostname>.
5. (Optional, this step is required before re-adding a removed compute back to the
Region Server) On the Compute Node, clean the OpenStack packages. Find the
packages needed to remove: rpm -qa | grep "*openstack*". Remove the
packages using the command: rpm -e <package name>
6. (Optional, this step is required before re-adding a removed compute back to the
Region Server) Restore the network configuration of the compute node.
Remove the bridge which created by the SmartCloud Orchestrator installer and
reassign the IP back to ethX interface.
What to do next
The availability zone will be removed from the OpenStack region after all the
compute nodes that used this availability zone are removed. You can run the
command nova availability-zone-list to find the compute nodes that use the
availability zone.
Removing a region
Use the steps that are described in this section to remove a region from the
SmartCloud Orchestrator environment.
Procedure
1. The SmartCloud Orchestrator admin must delete all instances on the region
from the cloud groups:
v Log on to the SmartCloud Orchestrator user interface and click Instances >
All Instances.
v Review each of the instances and delete the instances that belong to the
region that you want to remove.
2. Update the Virtual Image Library environment to ensure that all region-specific
data is removed:
v On the Virtual Image Library proxy machine, which is also referred to as the
Region Server, copy the images if required:
Run the /home/library/copyImages.sh script to copy the images to the
Virtual Image Library server or to another proxy connected to it:
copyImages.sh -destdomain <DESTDOMAIN> [-srcdomain <SRCDOMAIN>]
where
- -destdomain, -dest, -d <DESTDOMAIN> indicates the fully qualified
domain name of the destination Virtual Image Library proxy or server.
- -srcdomain, -src, -s <SRCDOMAIN> indicates the fully qualified domain
name of the source Virtual Image Library proxy or server. If this is not
specified, the local domain name is used.
v On the Virtual Image Library proxy machine, stop and disable the Virtual
Image Library proxy by running the following commands:
service vilProxy stop
chkconfig vilProxy off
Chapter 2. Installing 75
v On the Virtual Image Library server machine - Central Server 2:
Run
java -cp "/opt/p2pdiff/TransferClient/p2pDiffTransfer.jar:/opt/p2pdiff/TransferClient"
com.ibm.sid.RunCommand <ServerHostName> DeleteDatacenter <targetDatacenterName>
where:
- <ServerHostName> is the Virtual Image Library fully qualified server
host name.
- <targetDatacenterName> is the removed Virtual Image Library proxy
fully qualified host name. This is the region server fully qualified host
name.
This command might return the Status=false xxx not found message, if
no images were checked in or checked out from this region.
3. On Central Server 2, update the Keystone entries that relate to the region that
you want to remove, for example, RegionOne:
source /root/keystonerc
keystone endpoint-list |grep RegionOne | cut -d | -f2 | while read endpoint;
do keystone endpoint-delete $endpoint; done
For VMware or Power

regions only, run the following command on the

applicable region server:
source /root/openrc
/opt/ibm/openstack/iaas/smartcloud/bin/nova-cloud-delete <Region>
4. Update the SmartCloud Orchestrator environment as follows:
v Delete the region cloud groups:
Click Configuration > Cloud Groups.
Select the cloud group for the region you are deleting and click Discover.
Select each cloud group related to the region and click Delete.
v Delete the region IP group:
Click Configuration > IP Groups, select the required IP group and click
Delete.
5. On the Virtual Image Library proxy machine, enable and start the Virtual
Image Library proxy machine by running the following commands:
chkconfig vilProxy on
service vilProxy start
6. Optional: Update the region data:
v Update the data on Central Server 1: /iaas/installer/scripts/
clean_region_data.sh RegionOne
Note: This step erases data that is related to the removed region in the
OPENSTAC database. You must back up your data if required.
7. To check if the region has been successfully removed, perform these steps:
a. Be sure that no endpoints are found in keystone. Run the following
command on Central Server 2:
source /root/keystonerc
keystone endpoint-list |grep RegionOne
where RegionOne is the region you removed. No output should be returned.
b. Be sure there are no cloud groups related to this region in SmartCloud
Orchestrator. Login to SmartCloud Orchestrator, click Configuration >
Cloud Groups, there should be no cloud groups related to the region.
76 IBM SmartCloud Orchestrator 2.3: User's Guide
c. In SmartCloud Orchestrator, click Images&Patterns > Virtual Image
Library. In Virtual Image Library, click images and verify that the deleted
region is not listed in Operational Repositories.
Configuring LDAP authentication
Configure SmartCloud Orchestrator to use an LDAP server for user authentication.
By default, SmartCloud Orchestrator authenticates users against the OpenStack
Keystone database that is part of the product. You can configure SmartCloud
Orchestrator to authenticate against an external corporate directory (such as LDAP
or Active Directory) by enabling SmartCloud Orchestrator to pass an
authentication request to the corporate directory before passing the request to
Keystone.
The LDAP authentication support provided by SmartCloud Orchestrator enables
users defined in LDAP to logon to SmartCloud Orchestrator by specifying the
LDAP credentials (user name and password) if configured correctly. However,
users defined locally in OpenStack Keystone are not populated into LDAP.
If you have a single corporate directory server which contains all the users
irrespective of which domain they are in, then follow the procedure described in
Configuring LDAP authentication independently of the domain.
In a multidomain configuration, SmartCloud Orchestrator extends the
pre-authentication capability to allow any corporate directory details to be
specified on a domain-by-domain basis. In this mode, for any domain that requires
separate corporate directory details, you can define a specific partial Keystone
configuration file in addition to the main Keystone configuration file that is used
by all the domains. To configure LDAP authentication for a specific domain, follow
the procedure described in Configuring LDAP authentication on a
domain-by-domain basis on page 80.
Configuring LDAP authentication independently of the domain
You can configure LDAP authentication for SmartCloud Orchestrator.
To configure LDAP authentication, you must already have an LDAP server set up.
You will also need to specify which LDAP attributes are used as part of the
authentication process. You need to decide on the following:
v Which LDAP attribute will be checked against the username as part of
authentication? The default is the common name (cn) attribute, but you can
choose whatever suits your environment, for instance, email is a common
alternative. Whatever you chose here will be what the user must type into the
SmartCloud Orchestrator login panel.
v Where are the user objects stored in the LDAP server? You need to specify the
root of the subtree that contains these user objects. They do not need to exists at
the same level, but they do need to be all within one subtree.
v Does your LDAP server support anonymous query? If not, you will need an
LDAP user and password account that does have search capabilities, for the
subtree that contains the user's objects.
Note: The SmartCloud Orchestrator administrator account admin will already exist
in the local OpenStack database. Care must be taken to make sure there is not an
LDAP account that also has the name admin, otherwise this will now supersede the
local admin account.
Chapter 2. Installing 77
With the above items decided, perform the following steps to configure LDAP
authentication:
1. Make sure that the ldapauth.py file exists in your Keystone installation in the
keystone/middleware directory.
2. The following properties can be defined in your Keystone configuration file to
control LDAP authentication (the keystone configuration file is, by default, to
be found in /etc/keystone/keystone.conf on central server 2):
[ldap_pre_auth]
# The url of the corporate directory server
url = ldap://localhost
# The root of the tree that contains the user records
user_tree_dn = cn=users,dc=example,dc=com
# The property in the user record that will be checked against the username
user_name_attribute = cn
# In order to search for user records, we will try and use anonymous query.
# If anonymous query is not available, then define the user
and password of an account
# that does have rights to do a search
user = cn=admin,cn=users,dc=example,dc=com
password = <admin_password>
# Define this property if you want to customize the user id
# which will be used if we automatically populate the user to keystone
user_id_attribute = dn
# By default if we fail to find a user in LDAP,
we will then try and find that user
# directly in keystone. If you dont want that to happen
then set pass_through to False
#pass_through = False
3. You can configure support for LDAP SSL or TLS. To use SSL, then you must
configure the underlying openldap client with the appropriate certificate details
(which are typically stored in /etc/openldap/ldap.conf), for example:
TLS_CACERT /etc/openldap/certs/serverkey.cer
TLS_REQCERT DEMAND
With openldap configured, you can simply refer to your secure LDAP server by
specifying url = ldaps://.... in keystone.conf.
If you use TLS, then the certificate details are specified instead in the
keystone.conf file itself:
[ldap_pre_auth]
tls_cacertfile = /path/to/certfile
tls_cacertdir = /path/to/certdir
tls_req_cert = demand
use_tls = True
tls_cacertfile and tls_cacertdir are both not required. If you use TLS, you
must use the regular url = ldap://.... connection specification (and not use
ldaps).
4. The LDAP objects that are checked during authentication can be restricted
using two variables in the configuration file. user_objectclass allows you to
specify the class of objects to be checked and user_filter allows you to specify
additional AND filters to be used in the objects being checked. For instance, the
following statement restricts authentication to objects of class person that have
an attribute memberOf indicating membership to an existing OpenStack group in
your corporate directory server:
[ldap_pre_auth]
user_objectclass = person
user_filter = (memberOf=CN=OpenStack,dc=ldap,dc=com)
5. In your Keystone configuration file or paste.ini, define a filter for this class:
78 IBM SmartCloud Orchestrator 2.3: User's Guide
[filter:ldapauth]
paste.filter_factory =
keystone.middleware.ldapauth:LdapAuthAuthentication.factory
6. Add the ldapauth plug-in to the pipeline that you are using. By default this is
the api_v3 pipeline. ldapauth must come after the simpletoken filter:
[pipeline:api_v3]
pipeline = access_log sizelimit stats_monitoring
url_normalize token_auth admin_token_
auth xml_body json_body simpletoken ldapauth
debug stats_reporting
ec2_extension s3_extension service_v3
This procedure enables authentication to occur against your corporate directory.
However, a representation of an authenticated user must also be available in
Keystone after authorization so that, for example, roles can be assigned to the user.
While this can be done manually, or using an external directory synchronization
tool, SmartCloud Orchestrator provides you with an auto population plug-in that
can help you perform simple, automatic population of an LDAP user to Keystone
when that user first authenticates successfully to LDAP. The plug-in only
populates the minimal amount of information required into Keystone, namely user
name and user ID. Because the plug-in does not propagate the user password,
these Keystone user entries do not allow the LDAP authentication step to be
bypassed. They are only present to allow role assignment. To configure
auto-population, you need to decide on the following:
v Which LDAP attribute will be used to create a unique user_id within
the OpenStack keystone? This must be something that will not change over
time, that is limited to 64 characters and that does not contain blank space
characters. The default is the distinguished name (DN) attribute, but you can
chose whatever suits your environment, for example, the email attribute is,
again, a common alternative (it is perfectly acceptable, for example, to use email
as both the username and the user_id).
v Which project should the user be given an initial role on as part of the
auto-population? This project will already need to exist before the
auto-population takes place.
Note: It is not recommended that you enable a situation where a user sometimes
authenticates with LDAP and sometimes directly with Keystone, since unless these
are carefully maintained, with matching user_ids and so forth, this can cause
confusion about which is the master user record.
Note: The auto-population plug-in is not a replacement for a full directory
synchronization capability. While the plug-in will create a user-record the first time
a user authenticates, it will not, for example, delete that user record in keystone if
the LDAP user record is subsequently deleted. Such a user would indeed no longer
be able to log in to SmartCloud Orchestrator, but the database cleanup is outside of
the scope of the auto-population plug-in. If such a full capability is required, then
the use of an external directory synchronization tool is recommended (for details
refer to Using external Directory Integration tools with LDAP authentication on
page 81).
1. Make sure the autopop.py file exists in your Keystone installation in the
keystone/middleware directory.
2. The main job of the auto-population plug-in is to ensure that a user record is
created in Keystone, so that subsequent role assignments can take place.
However, optionally, the plug-in can grant an initial role to that user. This is
achieved by specifying the project and role required in an [auto_population]
section of the configuration file. First, you must specify the project, by
Chapter 2. Installing 79
providing either a project ID by defining default_project_id or a project name
by defining default_project. If a project name is specified, then this is
assumed to be in the same domain as the user who has just been authenticated,
whereas a project ID is, by definition, unique across all domains. For example:
[auto_population]
default_project = test-project
instructs the auto population plug-in to assign the authenticated user the
standard membership role in the project named test-project in the user's
domain. This project must already exist for this role assignment to take place.
Additionally, you can ask for the plug-in to grant a further explicit role to the
user on the project by specifying either a role name using a default_role or a
role ID using default_role_id. Hence, the following gives an authenticated
user both the membership role and the vm-manager role:
[auto_population]
default_project = test-project
default_role = vm-manager
Note: The roles assigned here only affect the assignments held within
SmartCloud Orchestrator and Keystone. They do not modify anything that is
actually stored in LDAP. The plug-in does not attempt to propagate any roles
stored explicitly within LDAP, although the use of an external directory
synchronization tool can enable such a capability.
Note: default_project_id is the standard config file variable for setting the
default project by ID. However, for backward compatibility with SmartCloud
Orchestrator 2.2 fix pack 1, setting this using default_tenant_id is also still
supported.
3. In your Keystone configuration file or paste.ini, define a filter for this class:
[filter:autopop]
paste.filter_factory = keystone.middleware.autopop:AutoPopulation.factory
4. Add the autopop plug-in to the pipeline that you are using, by default this is
the api_v3 pipeline. The plug-in autopop must come after the ldapauth filter:
[pipeline:api_v3]
pipeline = access_log sizelimit stats_monitoring
url_normaliz e token_auth admin_token_auth
xml_body json_body simpletoken ldapauth autopop debug
stats_reporting ec2_extension s3_extension service_v3
Configuring LDAP authentication on a domain-by-domain basis
There are some additional steps to configure LDAP authentication in a SmartCloud
Orchestrator multidomain environment.
To specify corporate directory details on a domain-by-domain basis, perform the
following steps in addition to the procedure described in Configuring LDAP
authentication independently of the domain on page 77:
1. For each domain that needs its own corporate directory details, in the
<domain_config_files_dir> directory, you must create a domain-specific
configuration file with the following name:
keystone.<domain_name>.conf
Only the [ldap_pre_auth] and [auto_population] sections should be included
in the domain specific configuration file, within which you should define the
specific configuration for the LDAP server for that domain. The options
available are the same as those listed in topic Configuring LDAP
authentication independently of the domain on page 77.
80 IBM SmartCloud Orchestrator 2.3: User's Guide
2. Add the following properties in your Keystone configuration file:
[ldap_pre_auth]
domain_specific_drivers_enabled = True
domain_config_dir = <domain_config_files_dir>
where <domain_config_files_dir> is the directory where the domain specific
configuration files are stored.
Note: TLS certification details cannot currently be specified on a
domain-by-domain basis.
Using external Directory Integration tools with LDAP
authentication
An alternative approach to using the provided auto-populate function is to use a
directory synchronization product, such as, for example, Tivoli Directory Integrator.
The configuration of this external capability depends on the specific product,
however you must perform the following steps:
1. In the user table in the Keystone SQL database, insert a record for each valid
LDAP or Active Directory that you want to use with the product. The structure
of the user table is as follows:
id character varying(64) NOT NULL
name character varying(64) NOT NULL
domain_id character varying(64) NOT NULL
password character varying(128) NOT NULL
enabled Boolean
extra text
where:
id Must be unique across all user entries in Keystone. For example, it
might be the dn of the LDAP user.
name Is the user name that is used for authentication.
domain_id
Must match the domain_id for the domain the user is in. If you have
not created any domains, this is the default domain for which the
domain_id is default. If you are using multiple domains, then the
domain_id must match the entry in the domains table.
password
This is not used for authentication, since that is done against the
corporate directory, so this must be set to some randomly generated
string to prevent the user from bypassing the corporate directory
authentication.
enabled
Must be set to true.
extra Can be left blank.
2. If the directory synchronization tool is used to delete user entries from the
Keystone database in response to a deletion in the corporate directory, then
there are a number of tables that must be updated and the user entry described
above must finally be deleted. Since a number of these tables use foreign keys
to point back to the user table, it is important that you only delete the user
entry itself once all the changes listed below have been made.
In the following tables you must delete any entry with a user_id that matches
the ID from the user table:
Chapter 2. Installing 81
Table: UserProjectGrant:
user_id character varying(64) NOT NULL
project_id character varying(64) NOT NULL
data text
Table: UserDomainGrant:
user_id character varying(64) NOT NULL
domain_id character varying(64) NOT NULL
data text
Table: UserGroupMembership:
user_id character varying(64) NOT NULL
group_id character varying(64) NOT NULL
If you are using an SQL server to store tokens, then to ensure that the user
being deleted is denied access to the product as soon as possible, the
TokenModel table must also be updated. If you are archiving expired tokens for
auditing purposes, then set the valid field to False for any token record that
matches the user_id. If you are not concerned about token archiving, you can
simple delete any token records that match this user_id.
Table: TokenModel:
id character varying(64) NOT NULL
expires datetime
extra text
valid boolean
user_id character varying(64) NOT NULL
trust_id character varying(64) NOT NULL
If using memcache as a token store, to disable a deleted LDAP user as soon as
possible, the memcache entries of tokens for that user must be deleted. The
memcache token store has two types of entries, with the keys of:
'usertokens-<user_id>'
Contains a list of token IDs for the user with the ID specified by
<user_id>
'tokens-<token_id>'
A specific token
To remove all tokens for a user, a memcache get must be issued for the key of
usertokens-<user_id> with the user_id in question. The value for this entry
is a list of token IDs, and for each of these delete the corresponding memcache
key of tokens-<token_id>. Finally, delete the key for usertokens-
<user_id>.
LDAP Keystone configuration file reference
The connection details of your corporate directory are stored within the
[ldap_pre_auth] and [auto-population] sections of either the keystone.conf file
or a domain specific configuration file.
The supported options within each of the two section are as follows:
Table 10. Configuration file options in ldap_pre_auth section
domain_config_dir The directory that contains any domain specific configuration files. This is
only used if domain_specific_drivers_enabled is True.
Default
/etc/keystone/domains
Example
domain_config_dir = /etc/myconfigs
82 IBM SmartCloud Orchestrator 2.3: User's Guide
Table 10. Configuration file options in ldap_pre_auth section (continued)
domain_specific_drivers_enabled If True, then both the ldapauth and autopop plugins will look in the
domain_config_dir for domain specific configuration files of the form
keystone.<domainname>.conf, where <domainname>.conf is the name given to
the domain when it was created via the SmartCloud Orchestrator UI.
Domain configuration files are only read when the keystone component of
SmartCloud Orchestrator is started (or restarted).
Default
False
pass_through If True, then if a user record is not found in the corporate directory server
that matches the specified user_name_attribute, then the authentication
request will be retried against the internal keystone database directly.
Default
True
Example
pass_through = False
password The password for the user account specified by user to enable searching
within the corporate directory. This is unrelated to the actual user and the
password that is being authenticated.
Default
None
Example
password = secret
tls_cacertdir The directory where TLS certificates are stored.
Default
None
Example
tls_cacertdir = /etc/openldap/cacertdir
tls_cacertfile The TLS certification file itself.
Default
None
Example
tls_cacertfile = /etc/openldap/cacertdir/server.cer
tls_req_cert The certificate requirement specification. This may be one of the following:
'never', 'demand' or 'allow'.
Default
None
Example
tls_req_cert = demand
Chapter 2. Installing 83
Table 10. Configuration file options in ldap_pre_auth section (continued)
url The URL of the corporate directory server. If using SSL, you must also
configure the underlying openldap client with the certificate details. These
are typically stored in /etc/openldap/ldap.conf, for example:
TLS_CACERT /etc/openldap/certs/serverkey.cer
TLS_REQCERT ALLOW
With TLS, however, you configure these details in the keystone
configuration file itself (see the options tls_cacert and tls_req_cert
below), and use a regular ldap://... URL.
Default
None
Example
url = ldap://www.ibm.com/myserver
If using SSL, then use ldaps, for example:
url = ldaps://www.ibm.com/mysecureserver
user The user account to be used for searching within the corporate directory.
This is unrelated to the actual user and password that is being
authenticated. If the corporate directory server supports anonymous query,
then this must not be specified.
Default
None
Example
user = cn=root
user_attribute_name This is now depreciated, but has the same meaning as user_name_attribute.
Default
cn
user_filter An additional filter (or filters) that will be ANDed into the search for the
user_name_attribute. The filter must be in brackets, as ain the example.
Default
None
Example
user_filter = (memberOf=cn=openstack,dc=root)
user_id_attribute If auto-population is enabled, this is the attribute that will be used as the
user_id when the keystone user record is created. A keystone user_id is
limited to 64 characters and must not contain blank space characters and
should be something that will not change for the lifetime of that user.
Default
dn
Example
user_id_attribute = mail
84 IBM SmartCloud Orchestrator 2.3: User's Guide
Table 10. Configuration file options in ldap_pre_auth section (continued)
user_mail_attribute If auto-population is enabled and it is required to propagate the email
address into the Keystone database, then define the attribute within the
corporate directory object to be used.
Default
None
Example
user_mail_attribute = mail
user_name_attribute The attribute within each corporate directory object that will be compared
against the user name in the authentication request.
Default
cn
Example
user_name_attribute = mail
user_objectclass The class of objects that will be searched to try and match the
user_name_attribute.
Default
*
Example
user_objectclass = person
user_tree_dn The root of the subtree in the corporate directory server that will be
searched.
Default
cn=users,dc=example,dc=com
Example
user_tree_dn = cn=users,dc=root
use_tls Indicates that the connection to the corporate directory should uses TLS.
Using an SSL LDAP connection (for example, url = ldaps://...) must not
be used as well as TLS.
Default
False
Example
use_tls = True
Table 11. Configuration file options in auto-population section
default_project The default project to be assigned to the new user being created, which
means a member role will be given to this project for the user. The project
must already exist. Note that this project must exist in the same domain as
the user being created. If you want to assign the user a role in a project that
is in a different domain, then use default_project_id.
Default
None
Example
default_project = project1
Chapter 2. Installing 85
Table 11. Configuration file options in auto-population section (continued)
default_project_id The default project ID to be assigned to the new user being created, which
means a member role will be given to this project for the user. The project
must already exist.
Default
None
Example
default_project_id = 87bb06e36a854c0b97c45b4e6dbf5ee4
default_role An additional role (specified by name) that will be granted to the newly
created user on the default project (in addition to the member role).
Default
None
Example
default_role = vm-manager
default_role_id An additional role (specified by ID) that will be granted to the newly
created user on the default project (in addition to the member role).
Default
True
Example
default_role_id= 34bc06e13a854c0b97c45b4e66bf5fe1
default_tenant_id This is now depreciated, but has the same meaning as default_project_id.
Default
None
Modifying project quotas
You can configure the project quotas in OpenStack so that they suit your business
needs.
About this task
Nova utilizes a quota system at the project level to control resource consumption
across the available hardware resources. The default values of quotas are listed in
the nova.conf file and you can edit this file to change the default values. For more
information about quotas, see the OpenStack documentation.
Procedure
1. Run the following command to see the quota for a project:
nova quota-show --tenant <project_id>
where <project_id> is the ID of the project (not the name of the project) for
which you want to set the quotas.
To get the list of the project IDs, run the following command:
keystone tenant-list
+----------------------------------+---------+---------+
| id | name | enabled |
+----------------------------------+---------+---------+
| 3d48139b938a4671b3c72df1ac27983a | admin | true |
86 IBM SmartCloud Orchestrator 2.3: User's Guide
| 715c10e6871d4e518f98e0a917eda857 | service | true |
| d592e14e8df64868aafc18cec4abb87c | DJ01 | true |
+----------------------------------+---------+---------+
2. To change the default project quotas, edit the nova.conf file.
3. To change the quota values in your project, run the following command:
nova quota-update --instances <number_of_instances>
--cores <number_of_process_cores>
--ram <size_of_ram_in_MB>
--volumes <number_of_volumes>
--fixed-ips <number_of_fixed_ips>]
<project_id>
To make the quota values unlimited in your project, set the corresponding
quota value to "-1".
Preparing to install additional Enterprise components
A complete deployment of SmartCloud Orchestrator Enterprise involves the
installation of various optional components that comprise the SmartCloud
Orchestrator Enterprise release.
These components include:
v Jazz for Service Management
v IBM SmartCloud Cost Management
v IBM Tivoli Monitoring
These components can be installed on physical or virtual machines, subject to the
relevant hardware and software requirements. For more information about these
components, visit the links below:
1. Quick Start Guide for Jazz for Service Management.
2. Quick Start Guide for IBM SmartCloud Cost Management
3. Quick Start Guide for IBM Tivoli Monitoring and Tivoli Monitoring for Virtual
Environments
Quick start guide for metering and billing
Use this topic as a go to guide when configuring SmartCloud Cost Management
for metering and billing.
The following list provides information about configuration steps required for
metering and billing:
Install Tivoli Common Reporting 3.1.0.1
For information about this task, see the installing Tivoli Common
Reporting section in the Jazz for Service Management information center.
Install SmartCloud Cost Management
For information about this task, see Installing SmartCloud Cost
Management 2.1.0.3.
Configuration required for metering
For more information about the configuration required for metering, see
the Automated configuration topic.
Configure job processing
v For information about configuring processing paths, see the setting
processing options topic.
Chapter 2. Installing 87
v For information about defining rates and rate templates. see
Administering the system.
v For information about customizing jobs, see Administering data
processing.
Confirming the creation of offerings and categories
You can confirm the creation of offerings and categories to verify that the
SCO-CatalogImport.sh tool is installed correctly.
About this task
The SCO-CatalogImport.sh tool is used during installation to install the offerings
and categories for the vSys toolkit which is included in SmartCloud Orchestrator. If
the offerings and categories are created, it means that the action was performed
correctly.
To verify that the offerings and categories have been created successfully, perform
the following steps:
Procedure
1. Go to Configuration > Self Service Categories and verify the following
categories:
v Virtual System Operations (Single Instance)
v Virtual System Operations (Multiple Instances)
2. Go to Configuration > Self Service Offerings and verify the following
categories:
v Deploy Virtual System Instance
v Start Virtual System Instance
v Stop Virtual System Instance
v Restart Virtual System Instance
v Delete Virtual System Instance
v Change End Time of Virtual System Instance
v Change Limits of Environmental Profile
v Start Single Server Virtual System Instance
v Stop Single Server Virtual System Instance
v Restart Single Server Virtual System Instance
v Delete Single Server Virtual System Instance
v Modify Single Server Virtual System Instance
v Start Multiple Virtual System Instances
v Stop Multiple Virtual System Instances
v Restart Multiple Virtual System Instances
v Delete Multiple Virtual System Instances
88 IBM SmartCloud Orchestrator 2.3: User's Guide
Changing the language settings for the vSys offerings and
categories
After installation, you can change the language settings for the vSys offerings and
categories.
About this task
After installation, you can change the language settings from the English default to
another language. To do this, manually remove all the vSys-created offerings and
categories. Use the SCO-CatalogImport.sh tool with the translated xml files located
on the Business Process Manager node in the directory /opt/ibm/ccs/catalog/
samples/vsys. For example, for Italian, use the file ./SCO-CatalogImport.sh
/opt/ibm/ccs/catalog/samples/vsys/vSysToolkitOfferings_it.xml admin admin.
Changing the various passwords
This topic describes how you can change the password for SmartCloud
Orchestrator built-in users, and how to change the password for the user that is
used to connect to a VMware vCenter in a VMware-based region.
The topic contains the following sections:
v Changing the admin password
v Changing the wasadmin password on page 91
v Changing the bpm_admin and tw_admin passwords on page 91
v Changing the db2inst1 password on page 91
v Changing the bpmuser password on page 93
v Changing the password for the vCenter connection (VMware regions only) on
page 94
v Changing the password for the VMControl connection (PowerVM regions
only) on page 95
Changing the admin password
The admin user is used across the following SmartCloud Orchestrator components:
SmartCloud Orchestrator user interface, Iaas Gateway, and OpenStack.
1. Change the password in the SmartCloud Orchestrator user interface by editing
the admin user in the Users panel (Administration > Users). After you change
the password, you cannot continue to work with the user interface until you
complete step 4 of this procedure. Close your browser.
2. Log on to the Region Server and encrypt the new password using the
/usr/bin/openstack-obfuscate <new password> command. Then log on to
Central Server 2 and edit the /etc/iaasgateway/iaasgateway.conf file by
changing the following line to the new password:
password = <type the new admin encrypted password here>
3. Restart the IaaS gateway service:
v If you are not using the SmartCloud Orchestrator high availability solution,
run the following command:
service openstack-iaasgateway restart
v If you are using the SmartCloud Orchestrator high availability solution, log
in to the System Automation Application Manager user interface and
initiate a restart of the openstack-iaasgateway resource.
4. Log on to Central Server 3 and restart the Workload Deployer service:
Chapter 2. Installing 89
v If you are not using the SmartCloud Orchestrator high availability solution,
run the following command:
service iwd restart
v If you are using the SmartCloud Orchestrator high availability solution, log
in to the System Automation Application Manager user interface and
initiate a restart of the Workload Deployer resource.
5. Log on to Central Server 2 and restart Virtual Image Library by doing the
following steps:
v If you are not using the SmartCloud Orchestrator high availability solution,
run the following command:
service vil restart
v If you are using the SmartCloud Orchestrator high availability solution, log
in to the System Automation Application Manager user interface and
initiate a restart of the Virtual Image Library resource group.
6. Log on to the Virtual Image Library user interface, select the OpenStack
domain in the Operational Repositories section in the resource tree, and then
click Actions > Change Credentials.
7. Specify the new password for the admin user.
8. Log on to Central Server 2 and edit the /root/keystonerc file to change the
following line:
export OS_PASSWORD=<old admin password>
to:
export OS_PASSWORD=<new admin password>
9. If you are using a VMware or Power region:
a. Change the admin password in SmartCloud Entry using the following
command (to be run from the Region Server):
curl -v -ku admin:<old admin password>
http://<ip address of the region server>:7080/cloud/api/users/admin
-H "Content-Type:application/json"
-d {"username":"admin","password":"<new admin password>",
"oldPassword":"<old admin password>"}
-X PUT
b. Restart the SmartCloud Entry service:
v If you are not using the SmartCloud Orchestrator high availability
solution, run the following command: service sce restart.
v If you are using the SmartCloud Orchestrator high availability solution,
log in to the System Automation Application Manager user interface and
initiate a restart of the SmartCloud Entry resource.
c. On the Region Server, update /etc/nova/smartcloud.conf replacing the
old encrypted admin password with the new admin encrypted password
in the sce_connection_password property and in the
admin_password property.
d. Restart the openstack-smartcloud service:
v If you are not using the SmartCloud Orchestrator high availability
solution, run the following command: service openstack-smartcloud
restart .
v If you are using the SmartCloud Orchestrator high availability solution,
log in to the System Automation Application Manager user interface and
initiate a restart of the openstack-smartcloud resource.
10. If you used admin as the user to connect to the cloud provider in Image
Construction and Composition Tool, you must remove the cloud provider
90 IBM SmartCloud Orchestrator 2.3: User's Guide
from Administer -> Manage Cloud Providers and create it again
specifying the new password. Then you must import again your images. If
you stopped Image Construction and Composition Tool before recreating the
cloud provider, the cloud provider will no longer be visible. You must
recreate it with a different name and import again the images.
Changing the wasadmin password
To change the wasadmin password used by WebSphere

Application Server, see

Changing the WebSphere account password on page 310.
Changing the bpm_admin and tw_admin passwords
To change the bpm_admin password, follow these steps:
1. Change the password of bpm_admin in the WebSphere Application Server page:
a. Log on to https://$central-server4:9043/ibm/console/logon.jsp.
b. Select Users and Groups.
c. Select bpm_admin.
d. In the User Properties panel, set the password, confirm it, and click Apply.
e. Change the following configuration files:
1) On Central Server 4, create a backup copy of the following files:
/opt/ibm/BPM/v8.5/profiles/DmgrProfile/properties/soap.client.props
and:
/opt/ibm/BPM/v8.5/profiles/Node1Profile/properties/soap.client.props
2) Edit each of the soap.client.props files listed in step i to find the
com.ibm.SOAP.loginUserid=bpm_admin entry, and update the associated
com.ibm.SOAP.loginPassword entry to specify the new password as plain
text:
com.ibm.SOAP.loginUserid=bpm_admin
com.ibm.SOAP.loginPassword=<type the new bpm_admin password here>
3) Encrypt the password by running the following two commands:
/opt/ibm/BPM/v8.5/bin/PropFilePasswordEncoder.sh
/opt/ibm/BPM/v8.5/profiles/DmgrProfile/properties/soap.client.props
com.ibm.SOAP.loginPassword
/opt/ibm/BPM/v8.5/bin/PropFilePasswordEncoder.sh
/opt/ibm/BPM/v8.5/profiles/Node1Profile/properties/soap.client.props
com.ibm.SOAP.loginPassword
4) To test if it works well, you can try to restart the service:
service bpm-dmgr restart
service bpm-node restart
2. To change the password of tw_admin, run the same procedure as described in
Step 1.
Changing the db2inst1 password
The db2inst1 password must be changed in the operating system where the DB2
instance is installed and in the OpenStack configuration files.
Remember that db2inst1 is used for OpenStack and Workload Deployer database
connections.
Chapter 2. Installing 91
1. To change the db2inst1 password in the operating system where DB2 is, log on
the system as root and type:
passwd db2inst1
then type in the new password.
2. Update the DB2 related password in the OpenStack configuration file:
a. Update the keystone configuration file on Central Server 2:
1) Find the keystone configuration file:
cd /etc/keystone
grep -Fnr connection ./
./keystone.conf:28:connection =
W0lCTTp2MV12b3pfcW9fZm46Ly94ZnFvOmZwYjRmaWdAMTcyLjE2LjM0LjIwMTo1MDAwMC9iY3JhZmducA==
b. Decode the DB2 connect information:
openstack-obfuscate
-u W0lCTTp2MV12b3pfcW9fZm46Ly94ZnFvOmZwYmdyZmdAMTAuMTYuMzQuMjAxOjUwMDAwL2JjcmFmZ25w
ibm_db_sa://ksdb:[email protected]:50000/openstac
c. Encrypt the DB2 connect information with the new password:
openstack-obfuscate ibm_db_sa://ksdb:<type here the new password>@10.16.34.201:50000/openstac
W0lCTTp2MV12b3pfcW9fZm46Ly94ZnFvOmFyamNuZmYwamVxQDEwLjE2LjM0LjIwMTo1MDAwMC9iY3JhZmducA==
d. Update the other OpenStack components on the Region Server.
3. Find the configuration files and replace the DB2 connection information with
the new password.
On a KVM region, find the configuration files:
cd /etc
grep -Fnr sql_connection ./
./glance/glance-registry.conf:27:sql_connection =
W0lCTTp2MV12b3pfcW9fZm46Ly90eXI1NDg5OTpmcGI0ZmlnQDE3Mi4xNi4zNC4yMDE6NTAwMDAvYmNyYWZnbnA=
./glance/glance-api.conf:32:sql_connection =
W0lCTTp2MV12b3pfcW9fZm46Ly90eXI1NDg5OTpmcGI0ZmlnQDE3Mi4xNi4zNC4yMDE6NTAwMDAvYmNyYWZnbnA=
./cinder/cinder.conf:17:sql_connection =
W0lCTTp2MV12b3pfcW9fZm46Ly9wdmU1NDg5OTpmcGI0ZmlnQDE3Mi4xNi4zNC4yMDE6NTAwMDAvYmNyYWZnbnA=
./nova/nova.conf:71:sql_connection =
W0lCTTp2MV12b3pfcW9fZm46Ly9hYm41NDg5OTpmcGI0ZmlnQDE3Mi4xNi4zNC4yMDE6NTAwMDAvYmNyYWZnbnA=
On a VMware region, find the configuration files:
cd /etc
grep -Fnr sql_connection ./
./glance/glance-registry.conf:27:sql_connection =
W0lCTTp2MV12b3pfcW9fZm46Ly90eXIxNDQ0Nzpub3AxMjNAOS4xMTUuNzcuMzk6NTAwMDAvYmNyYWZnbnA=
./glance/glance-api.conf:32:sql_connection =
W0lCTTp2MV12b3pfcW9fZm46Ly90eXIxNDQ0Nzpub3AxMjNAOS4xMTUuNzcuMzk6NTAwMDAvYmNyYWZnbnA=
./cinder/cinder.conf:17:sql_connection =
W0lCTTp2MV12b3pfcW9fZm46Ly9wdmUxNDQ0Nzpub3AxMjNAOS4xMTUuNzcuMzk6NTAwMDAvYmNyYWZnbnA=
./nova/smartcloud.conf:48:smartcloud_sql_connection=
W0lCTTp2MV12b3pfcW9fZm46Ly9mcHIxNDQ0Nzpub3AxMjNAOS4xMTUuNzcuMzk6NTAwMDAvYmNyYWZnbnA=
./nova/nova.conf:70:sql_connection=
W0lCTTp2MV12b3pfcW9fZm46Ly9hYm4xNDQ0Nzpub3AxMjNAOS4xMTUuNzcuMzk6NTAwMDAvYmNyYWZnbnA=
./nova/nova.conf:142:smartcloud_sql_connection =
W0lCTTp2MV12b3pfcW9fZm46Ly9mcHIxNDQ0Nzpub3AxMjNAOS4xMTUuNzcuMzk6NTAwMDAvYmNyYWZnbnA=
After modifying the configuration files, you must restart all the OpenStack
services. To test the changes has been correctly done, execute an OpenStack
command. For example, try to deploy an instance running the command nova
boot.
Change the db2inst1 password on Workload Deployer:
92 IBM SmartCloud Orchestrator 2.3: User's Guide
a. Login as root on Central Server 3.
b. Backup file /etc/rc.d/init.d/iwd-env.
c. Run the command:
service iwd setdb2host $DB2_HOST_ADDRESS $DB2_HOST_PORT $DB2_USER $DB2_PASS
d. Modify the parameter DB2_PASS in the files /etc/rc.d/init.d/iwd-env and
/etc/init.d/iwd-env. Pay attention to the value DB2_PASS, it must be an
encrypted password for the DB2 user, dbinst1. Here is an example on how
to get the encrypted password on Central Server 2:
vim /tmp/tmp_password.txt
password=$db2_password_in_plain_text
then run the command to encrypt the DB2 password:
/IBM/WebSphere/AppServer/bin/PropFilePasswordEncoder.sh /tmp/tmp_password.txt <new password>
Then you can find the encrypted password in /tmp/tmp_password.txt
Note: Pay attention to the format when modifying the password in file
iwd-env.
e. Restart the Workload Deployer by running:
service iwd restart
The output should look like:
[root@CS-3 init.d]# service iwd status
Processes:
db2sysc : STOPPED
derby : STOPPED
storehouse : RUNNING ( 2839 )
kernelservices : RUNNING ( 2917 )
zso : RUNNING ( 3398 )
Changing the bpmuser password
To change the password for the DB2 user used by the Business Process Manager
(bpmuser) you must change it both on Central Server 1 and in the WebSphere
Application Server console used by the Business Process Manager.
1. To change the password for the DB2 user used by the Business Process
Manager (bpmuser log on as root on Central Server 1 and launch:
passwd bpmuser
2. To change the Business Process Manager DB password in WebSphere
Application Server, follow these steps:
a. Log on to the Business Process Manager WebSphere Application Server
console: https://$central-server-4:9043/ibm/console/logon.jsp as
tw_admin
b. Select Resources.
c. Select JDBC.
d. Select Data sources and click BPM Business Space data source.
e. Click the option JAAS - J2C authentication data.
f. Click BPM_DB_ALIAS.
g. Insert the new password.
h. Click Apply to validate the change.
i. A message informs you that you must save your change.
Chapter 2. Installing 93
j. Click Save directly to the master configuration.
k. Click Synchronize.
l. Test the DB connection by clicking Test connection and selecting BPM
Business Space data source.
Note: If you get errors while synchronizing the changes, try to log out and log
in the page, and try to modify the password again.
Note: For details, refer to http://pic.dhe.ibm.com/infocenter/dmndhelp/
v8r5m0/index.jsp?topic=%2Fcom.ibm.wbpm.admin.doc%2Ftopics
%2Ftcfig_db_pwd_postconfig_1.html
Note: To change the Workload Deployer DB2 connection password, change the
DB2 password for the Workload Deployer:
passwd db2inst1
Changing the password for the vCenter connection (VMware
regions only)
The password of the user used to connect to vCenter is recorded in SmartCloud
Entry and in Virtual Image Library, so the change needs to be done in these two
places.
v Changing the password for the vCenter connected to Virtual Image Library can
be done logging in into the Virtual Image Library user interface and selecting
the VMware domain in the Operational Repositories section in the resource tree,
and then clicking Actions > Change Credentials.
v Changing the password in SmartCloud Entry is done using the REST APIs:
v Obtain the id of the involved cloud provider using this command (on a single
line ):
curl -ku <SCE_user_name>:<SCE_user_password>
http://<SCE_UI_hostname>:<SCE_UI_port_number>/cloud/api/clouds/
-H "Content-Type:application/json"
for example:
curl -ku admin:passw0rd http://192.0.2.0:7080/cloud/api/clouds/
-H "Content-Type:application/json"
Here is an example of the output:
{"clouds":[{"jmsPort":61617,"timeout":600,"state":
{"label":"OK","id":"OK"},"isComplete":true,"hostname":"198.51.100.0","isJmsSSL":false,
"username":"Administrator","name":"vmware","id":"301","description":"OpenStack managed VMware",
"uri":"http://192.0.2.0:7080/cloud/api/clouds/301 ","cloudType":"VMware"}]}
v Change the password (on a single line):
curl -v -ku <SCE_user_name>:<SCE_user_password>
http://<SCE_UI_hostname>:<SCE_UI_port_number>/cloud/api/clouds/<CLOUD_PROVIDER_ID>
-H "Content-Type:application/json" -d {"hostname":"<VCENTER_hostname>",
"username":"<VCENTER_user_name>",
"password":"<VCENTER_user_new_password>","cloudType":"VMware"} -X PUT
v For example:
curl -v -ku admin:passw0rd http://192.0.2.0:7080/cloud/api/clouds/301
-H "Content-Type:application/json" -d {"hostname":"198.51.100.0", "username":"Administrator",
"password":"mypassword", "cloudType":"VMware"} -X PUT
Here is an example for the output:
94 IBM SmartCloud Orchestrator 2.3: User's Guide
* About to connect() to 192.0.2.0 port 7080 (#0)
* Trying 192.0.2.0... connected
* Connected to 192.0.2.0 (192.0.2.0) port 7080 (#0)
* Server auth using Basic with user admin
> PUT /cloud/api/clouds/301 HTTP/1.1
> Authorization: Basic YWRtaW46cGFzc3cwcmQ=
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.13.1.0 zlib/1.2.3
libidn/1.18 libssh2/1.2.2
> Host: 192.0.2.0:7080
> Accept: */*
> Content-Type:application/json
> Content-Length: 101
>
< HTTP/1.1 200 OK
< Content-Language: en_US
< Content-Type: text/plain; charset=UTF-8
< Date: Fri, 31 Jan 2014 16:24:45 GMT
< Accept-Ranges: bytes
< Server: Restlet-Framework/2.1.1
< Content-Length: 18
<
* Connection #0 to host 192.0.2.0 left intact
* Closing connection #0
Changing the password for the VMControl connection (PowerVM
regions only)
The password of the user used to connect to VMControl is recorded in SmartCloud
Entry and in Virtual Image Library, so the change must be applied in both places.
1. To change the password for the VMControl connection in Virtual Image
Library, complete the following steps:
a. Log into the Virtual Image Library user interface.
b. In the Operational Repositories section in the resource tree, select the
PowerVM domain.
c. Click Actions > Change Credentials.
2. To change the password in SmartCloud Entry, use the REST APIs as follows:
a. Get the id of the relevant cloud provider by entering the following
command on one line:
curl -ku <SCE_user_name>:<SCE_user_password>
http://<SCE_UI_hostname>:<SCE_UI_port_number>/cloud/api/clouds/
-H "Content-Type:application/json"
where:
<SCE_user_name>
The SmartCloud Entry user admin.
<SCE_user_password>
The password for the SmartCloud Entry user admin.
<SCE_UI_hostname>
The IP address or host name of the PowerVM region server where
SmartCloud Entry is installed.
<SCE_UI_port_number>
The port number used to access SmartCloud Entry. The default
value is 7080.
For example:
Chapter 2. Installing 95
curl -ku admin:sco4svt http://192.0.2.0:7080/cloud/api/clouds/
-H "Content-Type:application/json"
Here is an example of the output:
{"clouds":
[{"timeout":600,"port":8422,"isComplete":true,"isJmsSSL":false,"name":"RegionPower",
"uri":"http://192.0.2.0:7080/cloud/api/clouds/301","cloudType":"VMControl",
"jmsPort":61617,"state":
{"label":"OK","id":"OK"},"hostname":"198.51.100.0","username":"root","version":"2.4.3.x",
"id":"301","description":"OpenStack managed VMControl"}]}
b. Change the password by entering the following command on one line:
curl -v -ku <SCE_user_name>:<SCE_user_password>
http://<SCE_UI_hostname>:<SCE_UI_port_number>/cloud/api/clouds/<CLOUD_PROVIDER_ID>
-H "Content-Type:application/json"
-d {"hostname":"<VMCONTROL_hostname>",
"username":"<VMCONTROL_user_name>",
"password":"<VMCONTROL_user_new_password>","cloudType":"VMControl"} -X PUT
where:
<SCE_user_name>
The SmartCloud Entry user admin.
<SCE_user_password>
The password for the SmartCloud Entry user admin.
<SCE_UI_hostname>
The IP address or host name of the PowerVM region server where
SmartCloud Entry is installed.
<SCE_UI_port_number>
The port number used to access SmartCloud Entry. The default
value is 7080.
<CLOUD_PROVIDER_ID>
The ID obtained in the previous step.
<VMCONTROL_hostname>
The IP address or host name of the server where VMControl is
installed.
<VMCONTROL_user_name>
The user that connects to VMControl.
<VMCONTROL_user_new_password>
The new password for the user that connects to VMControl.
For example:
curl -v -ku admin:sco4svt http://192.0.2.0:7080/cloud/api/clouds/301
-H "Content-Type:application/json" -d {"hostname":"198.51.100.0",
"username":"root", "password":"newpassword", "cloudType":"VMControl"} -X PUT
Changing the password for OpenStack service users
OpenStack has three service users: nova, cinder and glance.
By default, the service users are created with the same password assigned at
installation time to the admin user. If you would like to change their passwords
follow these procedures:
To change the password for nova user:
96 IBM SmartCloud Orchestrator 2.3: User's Guide
1. Change the password in the SmartCloud Orchestrator user interface by
editing the nova user in the Users panel (Administration > Users).
2. On the Region Server run /usr/bin/openstack-obfuscate <new
password for nova user> to obtain the encrypted password.
3. On the Region Server, do a backup copy of /etc/nova/nova.conf.
4. On the Region Server, edit /etc/nova/nova.conf replacing the old value
of admin_password with the newly generated in Step 2.
Attention: It is recommended to comment out the property
admin_token in nova.conf.
5. Restart all openstack-nova* services.
To change the password for glance user:
1. Change the password in the SmartCloud Orchestrator user interface by
editing the glance user in the Users panel (Administration > Users).
2. On the Region Server run /usr/bin/openstack-obfuscate <new
password for glance user> to obtain the encrypted password.
3. On the Region Server, do a backup copy of /etc/glance/glance-
api.conf;/etc/glance/glance-registry.conf.
4. On the Region Server, edit /etc/glance/glance-api.conf replacing the
old value of admin_password with the newly generated in Step 2. Do
the same in /etc/glance/glance-registry.conf.
Attention: It is recommended to comment out the property
admin_token in both glance-api.conf and glance-registry.conf.
5. Restart all openstack-glance* services.
To change the password for cinder user:
1. Change the password in the SmartCloud Orchestrator user interface by
editing the cinder user in the Users panel (Administration > Users).
2. On the Region Server run /usr/bin/openstack-obfuscate <new
password for cinder user> to obtain the encrypted password.
3. On the Region Server, do a backup copy of /etc/cinder/cinder.conf.
4. On the Region Server, edit /etc/cinder/cinder.conf replacing the old
value of admin_password with the newly generated in Step 2.
Attention: It is recommended to comment out the property
admin_token in cinder.conf.
5. Restart all openstack-cinder* services.
Replacing the existing certificates
This topic describes how you can replace existing certificates.
SmartCloud Orchestrator user interface (Central Server 3)
To replace the certificates of the SmartCloud Orchestrator user interface with the
certificates officially released by a Certification Authority, follow the procedure to
import and apply into SmartCloud Orchestrator UI components once you receive
the official certificates.
The reference documentation for the jetty server can be found at:
http://wiki.eclipse.org/Jetty/Howto/
Configure_SSL#Loading_Keys_and_Certificates.
1. Log on to Central Server 3 (on the SmartCloud Orchestrator user interface
machine) and navigate to the scoui folder:
Chapter 2. Installing 97
/opt/ibm/ccs/scui/etc/
2. Back up the current keystore file and the jetty.xml configuration file as
follows:
mv keystore keystore.BAK
cp jetty.xml jetty.xml.BAK
3. Next you must follow the following procedure "Loading Keys and Certificates
through PKCS12" to include the new certificate and key into a keystore to be
used for jetty.
Loading Keys and Certificates through PKCS12:
If you have a key and certificate in separate files, you must combine them into
a PKCS12 format file to load into a new keystore. The certificate can be one you
generated yourself or one returned from a Certification Authority in response
to your certification service request.
The following OpenSSL command combines the keys in jetty.key and the
certificate in the jetty.crt file into the jetty.pkcs12.
If you have a chain of certificates, because your Certification Authority is an
intermediary, build the PKCS12 file as follows:
# cat example.crt intermediate.crt [intermediate2.crt]... rootCA.crt > cert-chain.txt
# openssl pkcs12 -export -inkey example.key -in cert-chain.txt -out example.pkcs12
The order of certificates must be from server to rootCA, as per RFC2246 section
7.4.2.
Use keytool (starting from jdk1.6) to import a PKCS12 file with the following
command:
keytool -importkeystore -srckeystore jetty.pkcs12 -srcstoretype PKCS12 -destkeystore newkeystore
The command asks for two passphrase. Give the password from the last step as
the input passphrase and you are set. The "output passphrase" must appear in
your jetty.xml configuration file as both the Password and KeyPassword of the
SunJsseListener that uses the certificate.
4. Configure jetty in order to use the new certificate:
a. Encode the password you used to create the key and the password you
used to import key into the keystore (they can be the same):
java -cp /opt/ibm/ccs/scui/lib/org.eclipse.jetty.util_8.1.3.v20120522.jar
org.eclipse.jetty.util.security.Password <your-password>
This will provide in output the encoded password as follows:
OBF:1v2j1uum1tfe1pot1zer1lbw1uvk1v1v
b. Edit the jetty.xml file and update the path of the keystore file to the new
one. In the sample provided in Step 3, newkeystore is the name of the
keystore file and the relative path from the SmartCloud Orchestrator user
interface root folder is /etc/newkeystore:
Original:
<Set name="keyStore"<SystemProperty name="jetty.home"/etc/keystore</Set>
<Set name="trustStore"<SystemProperty name="jetty.home"/etc/keystore</Set>
New configuration:
<Set name="keyStore"<SystemProperty name="jetty.home"/etc/newkeystore</Set>
<Set name="trustStore"<SystemProperty name="jetty.home"/etc/newkeystore</Set>
Replace the passwords for keystore and key with the encoded password
you got in the previous step:
98 IBM SmartCloud Orchestrator 2.3: User's Guide
<Set name="keyStorePassword">OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4</Set>
<Set name="keyManagerPassword">OBF:1u2u1wml1z7s1z7a1wnl1u2g</Set>
<Set name="trustStorePassword">OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4</Set>
c. Restart the SmartCloud Orchestrator user interface to apply the changes:
service scui restart
Workload Deployer (Central Server 3)
The reference documentation for the smash server can be found at:
http://publib.boulder.ibm.com/infocenter/wsmashin/v1r1/index.jsp?topic=/
com.ibm.websphere.sMash.doc/using/zero.core/SSLConfiguration.html.
1. Log on to Central Server 3 (SmartCloud Orchestrator user interface machine)
and navigate to the iwd folder:
/opt/ibm/rainmaker/purescale.app/private/expanded/ibm/rainmaker.rest-4.0.0.1/config/
2. Back up the current keystore file and https-server.config configuration file as
follows:
mv rm.p12 rm.p12.BAK
cp https-server.config https-server.config.BAK
3. Next reuse the same certificates used for jetty. You can reuse the jetty.pkcs12
file as keystore and modify the configuration file as in the next step.
4. Edit the configuration file /opt/ibm/rainmaker/purescale.app/private/
expanded/ibm/rainmaker.rest-4.0.0.0/config/https-server.config and
replace the passwords and keystore path. Note that the passwords must be
encoded using the utility provided by smash:
/opt/ibm/rainmaker/purescale.app/zero encode <your-password>
/config/https/sslconfig = {
"keyStore": "${/config/dependencies/ibm:rainmaker.rest}/config/rm.p12",
"keyStorePassword": "<xor>Lz4sLChvLTs=",
"keyStoreType": "PKCS12",
"trustStore": "${/config/dependencies/ibm:rainmaker.rest}/config/rm.p12",
"trustStorePassword": "<xor>Lz4sLChvLTs=",
"trustStoreType": "PKCS12"
5. Back up the Workload Deployer keystore and Workload Deployer connection
configuration for the SmartCloud Orchestrator user interface. Navigate to the
folder:
/opt/ibm/ccs/scui/etc/
Back up the file iwd_keystore.jks:
mv iwd_keystore.p12 iwd_keystore.p12.BAK
Back up the file config.json:
cp config.json config.json.BAK
6. Edit the section iwd of the file config.json to make it use the same keystore
defined in the section above for the SmartCloud Orchestrator user interface
keystore (in the sample newkeystore).
Note: Remember to change the encrypted password accordingly, same as for
the jetty.xml file in the SmartCloud Orchestrator user interface configuration:
"iwd": {
"provider": "iwd",
"service_url": "https:\/\/9.168.58.29",
"simple_token_secret":
"OBF:1c3d1ggf1ls21j8z1x8m1pk31ugk1t9a1q4o1ksl1oxc1jra1jug1oy61ks91q461tb41uh61pi31x881j631lrw1gfj1c3p",
"keyStore": {
"path": "\/opt\/ibm\/ccs\/scui\/etc\/newkeystore",
"password": "OBF:1v2j1uum1lfm1zej1zer1lbw1uvk1v1v"
}
},
Chapter 2. Installing 99
Workload Deployer Kernel Service truststore:
After changing the SSL certificate, you must import it to the Kernel Service
truststore.
The keystore for the Kernel Service is:
/opt/ibm/maestro/maestro/usr/resources/security/KSTrustStore.jks
The password of the keystore is pureScale and you can check this in the
configuration file:
/opt/ibm/maestro/maestro/usr/servers/kernelservices/server.cfg
To set the Workload Deployer certificate in the Kernel Service truststore:
source /etc/profile.d/jdk_iwd.sh;
keytool -v -importkeystore
-srckeystore
/opt/ibm/rainmaker/purescale.app/private/expanded/ibm/rainmaker.rest-4.0.0.1/config/rm.p12
-srcstoretype PKCS12
-destkeystore /opt/ibm /maestro/maestro/usr/resources/security/KSTrustStore.jks
-deststoretype JKS -deststorepass pureScale -srcstorepass <cert_password>
Business Process Manager (Central Server 4)
When the Workload Deployer certificate is changed, the new certificate must be
imported in the Business Process Manager truststore to secure the communication
between Business Process Manager and Workload Deployer. To do so, follow the
instructions documented at http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/
index.jsp?topic=%2Fcom.ibm.websphere.express.doc%2Fae
%2Ftsec_sslretrievesignersport.html.
Import the certificate from the Workload Deployer server (Central Server 3 port
443). You need to import it into CellDefaultTrustStore and restart Business
Process Manager afterwards.
Archiving historical data
Archive periodically historical data related to deleted VM instances to keep stable
the performance of an OpenStack region server.
About this task
Use the archiveHistory.sh script to periodically archive historical data. The script
is released with the SmartCloud Orchestrator product in the <install_image>/
installer/tools/archive_history_utility directory.
For detailed information about the script installation and usage, see the related
ReadMe.txt file.
100 IBM SmartCloud Orchestrator 2.3: User's Guide
Content Pack installation
To make the content pack processes available in SmartCloud Orchestrator, import
the toolkit provided with the content pack inBusiness Process Manager as
described in this topic.
Follow this procedure:
1. In the Business Process Manager Designer, click Process Center.
2. In the Toolkits, click Import Toolkit.
3. In Import Toolkit, click Browse to select the file to import.
Note: The Toolkit file extension is in twx extension format.
4. Click OK.
When the Toolkit is imported in Business Process Manager, the processes of the
toolkit are available in SmartCloud Orchestrator, which can be configured as
self-service offering or Orchestration Action from the SmartCloud Orchestrator
user interface.
Log in to the SmartCloud Orchestrator user interface:
1. Click Configuration > Self-service Categories.
2. Assign a name, a description, and select a graphical icon for the category.
3. Click Configuration > Self-service Offerings.
4. Provide the offering name, select the newly created category and icon.
5. Select a process to create self-service offerings.
Upgrading to Fix Pack 1
This topic describes how to upgrade SmartCloud Orchestrator 2.3.0.0 to 2.3.0.1.
Before you begin
Both fresh installation and upgrade use the same package. Prepare the package by
performing the following steps on Central Server 1 and on all Region Servers:
1. Extract the package into a new directory, for example, if your working directory
is /install_images:
# tar xvf <installation tar media>
2. Extract install_images/IBM_SmartCloud_Installer_and_OpenStack-*.tgz to
/install_images, then navigate to the directory /install_images/installer/.
3. Prepare the Red Hat Enterprise Linux server DVD ISO file on Central Server 1
and all Region Servers:
a. On Central Server 1, set iso_location to the correct location in the file
central-server.cfg.
b. On each Region Server, set iso_location to the correct location in the file
region-server.cfg.
iso_location=/opt/RHEL6.3-20120613.2-
Server-x86_64-DVD1.iso
The location of the Red Hat Enterprise
Linux Server 6 DVD ISO file.
Note: No other parameters in the configuration files need to be updated, as
these can be determined from the existing installation of SmartCloud
Orchestrator 2.3.
Chapter 2. Installing 101
Note: Do not move to other directories when you perform the upgrade steps.
About this task
Perform the following steps to upgrade SmartCloud Orchestrator:
Procedure
1. Stop the SmartCloud Orchestrator processes:
v If you do not use System Automation Application Manager to control
SmartCloud Orchestrator, see Starting or stopping SmartCloud
Orchestrator on page 135 for information about stopping SmartCloud
Orchestrator.
v If you use System Automation Application Manager to control SmartCloud
Orchestrator, see Controlling the management stack on page 124 for
information about stopping the SmartCloud Orchestrator management stack
from System Automation Application Manager.
2. Back up the virtual machines of the Central Servers, Region Server, and
compute nodes. Backup the file /opt/ibm/pcg/etc/flavors.json on Central
Server 2. Otherwise, Public Cloud Gateway will lose the original flavor
customization after upgrade.
For VMware-hosted virtual machines, see Taking Snaphots for information
about taking snapshots of the virtual machines.
3. On Central Server 1, run deploy_central_server.sh to upgrade the Central
Server:
/install_images/installer/deploy_central_server.sh
4. On each Region Server, run deploy_region_server.sh to upgrade the Region
Server:
/install_images/installer/deploy_region_server.sh -C <central-server-1-ip-address>
5. On each KVM Region Server, run deploy_compute_node.sh to upgrade compute
node for KVM regions:
/install_images/installer/deploy_compute_node.sh -s <additional-node-ip> [-p <OS-root-password>]
6. Restart the SmartCloud Orchestrator processes:
v If you do not use System Automation Application Manager to control
SmartCloud Orchestrator, see Starting or stopping SmartCloud
Orchestrator on page 135 for information about starting SmartCloud
Orchestrator.
v If you use System Automation Application Manager to control SmartCloud
Orchestrator, follow the procedure described in Configuring System
Application Automation Manager to:
Re-configure service autostart on the Central Servers, Region Server, and
compute nodes.
Run the step to copy control scripts from /iaas/scorchestrator to
/home/saam on all the servers.
Note: After restarting SmartCloud Orchestrator processes, if the Virtual Image
Library repositories are not aligned and the resources are in out of synch status,
run Synchronize Repositories from the Virtual Image Library user interface.
7. Restore /opt/ibm/pcg/etc/flavors.json on Central Server 2.
Note: If you forget to backup the file /opt/ibm/pcg/etc/flavors.json in step 2,
you can find it in /opt/ibm/pcg/backup/server-*.zip on Central Server 2.
102 IBM SmartCloud Orchestrator 2.3: User's Guide
Results
You can find the upgrade logs in /tmp/bootstrap-update*.log.
If the upgrade procedure fails, you can roll back your SmartCloud Orchestrator
environment with the data you backed up. For VMware-hosted virtual machines,
see Taking Snaphots for information about taking snapshots of the virtual
machines.
Upgrading from SmartCloud Provisioning 2.3
This topic describes the upgrade from SmartCloud Provisioning 2.3.
About this task
To upgrade from SmartCloud Provisioning 2.3, perform the following steps.
Note: To upgrade to SmartCloud Orchestrator 2.3.0.1, before running the following
procedure, you must upgrade your environment to SmartCloud Provisioning
2.3.0.1.
Procedure
1. Create and prepare Central Server 4 as documented in Preparing the central
server and the region server on page 17.
2. On Central Server 1 untar the required packages. For more information about
the relevant packages, see the Preparing the installation based on electronic
download packages topic. For a list of the available media, refer to the
Preparing the installation based on DVD images topic.
3. On Central Server 1 under the installer/conf directory, do the following:
a. Copy deploy.conf to deploy.conf.bak.
b. Copy deploy_upgrade_from_SCP.conf to deploy.conf (the file contains
product_type=SCO and install_type=upsell).
c. In deploy.conf, replace the CHEF_SERVER_IP with the IP address of Central
Server 1.
4. Copy the SmartCloud_Orchestrator*-2.3.0.swtag file to the required location
using the following command:
cp <SCO install dir>/swtag/SmartCloud_Orchestrator*-2.3.0.swtag
/data/repos/scp/install-packages/iwd/SmartCloud_Orchestrator-2.3.0.swtag
5. On Central Server 1 under the installer directory, customize the
central-server.cfg file to reflect your environment. For more information
about this, see the Installing the central server topic.
6. Run the following command:
/deploy --debug central-server --os_password <admin password>
--os_service_password <service password> --password <root password>
Required arguments:
--os_password <admin password>
OpenStack admin user password.
--os_service_password <service password>
OpenStack service user password.
Optional arguments:
Chapter 2. Installing 103
--identity_file <identity file>
Identity (private key) for ssh public key authentication to login the
central servers.
--password <root password>
root password to login the central servers.
--ldap_password <ldap password>
Password to authenticate LDAP.
7. Important: If you are a SmartCloud Orchestrator Enterprise customer, login to
Central Server 3 and rename the SmartCloud_Orchestrator-2.3.0.swtag file by
executing the following command:
cd /opt/ibm/SmartCloud_Orchestrator/properties/version/
mv SmartCloud_Orchestrator-2.3.0.swtag SmartCloud_Orchestrator_Enterprise-2.3.0.swtag
High Availability
Learn how to setup a SmartCloud Orchestrator management stack with high
availability Quality of Services (QoS).
The high availability solution helps to reduce the downtime of the SmartCloud
Orchestrator management stack. In addition, operation of the SmartCloud
Orchestrator management stack is simplified.
The high availability solution includes a new component, the System Automation
Application Manager, which helps in recovery from application failures and which
simplifies the control of the SmartCloud Orchestrator management stack for the
operating team. The high availability solution can be enhanced by using the high
availability features of the hypervisors, for example, restart of all the virtual
servers on a backup hypervisor. The usage of the hypervisor high availability
capabilities requires additional manual steps at installation time.
The high availability capabilities for the SmartCloud Orchestrator management
stack are achieved through the following functions:
vSphere High Availability (HA) clusters
You can automatically recover after a virtual server failure, a ESXi failure,
or even a server failure by restarting the virtual server. The restart of the
virtual server can occur on the same ESXi server or, depending on the
failure situation, on another ESXi server.
System Automation Application Manager
Used to monitor and automatically recover failed application components.
Both high availability functions work together and should be used together to
achieve high availability of the SmartCloud Orchestrator management stack.
vSphere HA clusters enable a collection of ESXi Servers to work together so that,
as a group, they provide higher levels of availability for virtual machines than each
ESXi host can provide individually. vSphere HA pools virtual machines and ESXi
hosts so that they reside in a cluster. Hosts within the cluster are managed and, in
the event of a failure, the virtual machines on a failed ESXi host are restarted on
alternate host within the cluster. For SmartCloud Orchestrator, using vSphere HA
gives an extra level of redundancy, for example, if one of the ESXi Servers fails, the
SmartCloud Orchestrator virtual machines that were located on that host are
restarted on alternate ESXi hosts. Additionally, one of the features of vSphere HA
is VM Monitoring which, in the event of an OS failure, restarts the virtual machine.
104 IBM SmartCloud Orchestrator 2.3: User's Guide
If vSphere HA is not configured, a hardware failure might, in a worse-case
scenario, involve a reinstallation of the environment, a rather significant outage,
and potential data loss.
System Automation is used to automate the availability of resources. This
availability is accomplished by starting and stopping resources automatically and
in the correct sequence. System Automation Application Manager uses agentless
adapters to monitor and control remote applications. It ensures availability and
provides automation of these services even across operating system boundaries.
This is ideal for SmartCloud Orchestrator because it allows it to have a centralized
server that monitors and automatically stops, starts, or restarts the various
applications on the virtual machines in the SmartCloud Orchestrator environment.
Using both vSphere HA and System Automation Application Manager
withSmartCloud Orchestrator allows the recovery of the SmartCloud Orchestrator
environment in the event of either hardware and software failures, thereby
reducing the downtime of the SmartCloud Orchestrator management stack.
Using vSphere HA clusters
Configure the vSphere HA clusters for the SmartCloud Orchestrator environment.
Before you begin
To set up the vSphere HA solution, make sure that the following requirements are
met:
v vSphere HA Cluster
v Three or more ESXi servers
v Shared Storage (FC, iSCSI, NFS storage)
v Common Network configuration between ESXi Servers
v vMotion-enabled network
v Management network redundancy
v Shared Storage between all the ESXi Servers
v For optimum datastore heartbeating, a minimum of two shared data stores
About this task
For additional information about configuring and using vSphere HA clusters, see
the vSphere Availability guide.
To implement the vSphere HA solution by creating the SmartCloud Orchestrator
virtual machines on datastores that are shared between the ESXi servers, perform
the following procedure:
Procedure
1. Install at least three ESXi Servers. Storage and networking prerequisites must
be configured on all the ESXi Servers.
2. On the vCenter server, create a cluster. Do not enable vSphere at this time.
3. Add the ESXi Servers to the cluster.
4. Select Edit Settings on the cluster and select Turn on vSphere HA.
5. Perform the following steps:
a. Ensure that Host Monitoring is enabled
b. Ensure that Admission Control is enabled.
Chapter 2. Installing 105
c. Admission Control Policy must tolerate one host failure.
Note: Enabling Admission Control and setting the policy to tolerate one
host failure means that you cannot power on any virtual machines that
vSphere HA is not able to restart. For more information, see Configure
Host Monitoring and Admission Control in the vSphere Availability guide.
d. Leave the cluster default settings as it is.
e. Ensure VM Monitoring is set to VM Monitoring only.
f. Optionally, you can configure vSphere DRS. For more information, see
Configuring vSphere DRS.
g. Leave all the other settings as default, and click Finish.
6. The ESXi Servers are now configured for vSphere HA. You can check it in the
Summary tab of the ESXi host.
Note: One ESX Server is defined as the vSphere HA master, and all the other
ESXi Servers are defined as slaves. For more information, see Master and
Slave Hosts in the vSphere Availability guide.
7. Create the virtual machines and install SmartCloud Orchestrator.
Note: For the virtual machines to be protected by HA, you must install them
on the shared storage and they must have network connectivity.
8. Verify that the virtual machines are protected in the vSphere HA Protection
field in the Summary tab for each virtual machine or in the Virtual Machine
tab for the ESXi host.
Configuring vSphere DRS
vSphere Distributed Resource Scheduler (DRS) monitors utilization across vSphere
ESXi servers and allocates resources among virtual machines according to your
needs.
About this task
If a failure occurs, vSphere HA might separate clustered virtual machines that are
meant to stay together, or vSphere HA might put clustered virtual machines that
are meant to stay apart on the same host. You can avoid this problem by setting up
DRS groups and using the VM-Host affinity rules which are followed by vSphere
HA.
For further information about vSphere DRS, see the vSphere Resource Management
guide.
Note: vSphere HA starts the virtual machines on any available ESXi Servers, and
then vSphere DRS moves the virtual machines around for best resource allocation
and based on any rules configured.
The most basic configuration for SmartCloud Orchestrator is to have all virtual
machines on one ESXi server. If there are multiple ESXi servers in the cluster, a
rule is required to keep the virtual machines together.
To configure VM-Host-Affinity rules for the SmartCloud Orchestrator central
server, perform the following steps:
106 IBM SmartCloud Orchestrator 2.3: User's Guide
Note: The IBM SCO all-in-one rule in the following procedure is only for
example. The required rule depends on the physical infrastructure where you
installed SmartCloud Orchestrator.
Procedure
1. Select Edit Settings on the cluster and select Turn on vSphere DRS.
2. On the right of the window, select Rules under vSphere DRS.
3. Click Add and specify the following values:
v Specify IBM SCO all-in-one in the Name field.
v Specify Keep Virtual Machines Together in the Type field.
v In the Virtual Machines field, click Add... and select all SmartCloud
Orchestrator virtual machines.
4. Click OK.
5. Ensure that the rule SCO Central Server VMs together is selected and click
OK.
Using System Automation Application Manager
Use System Automation Application Manager to control the complete SmartCloud
Orchestrator management stack and its subcomponents.
About this task
System Automation Application Manager can detect if a software component of
SmartCloud Orchestrator failed and then automatically restart it. As a result, you
can achieve an improved availability solution for the SmartCloud Orchestrator
management stack.
System Automation Application Manager continuously monitors all the
components and subcomponents of the SmartCloud Orchestrator management
stack. In case of failure, it reacts by automatically restarting the failed components
and the related subcomponents. The System Automation Application Manager
configuration includes automation policies which define the start and stop
dependency graph for all the SmartCloud Orchestrator components. As a result,
the operating team can start, stop, and monitor the state of the SmartCloud
Orchestrator management stack. System Automation Application Manager also
simplifies the operating tasks because it is possible to control the SmartCloud
Orchestrator management stack in a more granular manner on the component
level. For example, with a single request you can recycle only one component like
Business Process Manager.
Installing System Automation Application Manager
System Automation Application Manager version 3.2.2 is bundled with
SmartCloud Orchestrator version 2.3.
About this task
To install System Automation Application Manager perform the following steps.
Procedure
1. Create a virtual machine with at least 2 CPUs, 4 GB RAM and 20 GB disk
space.
2. Install and configure RHEL.
Chapter 2. Installing 107
Note: You can use the same version of the RHEL media that you used to install
SmartCloud Orchestrator. For information about software prerequisites, see
Software prerequisites on page 15.
Ensure the following packages are installed on the RHEL virtual machine. They
are included in the RHEL installation package.
v X11
v Firefox
v compat-libstdc++-33.i686
v compat-libstdc++-33.x86_64
v libstdc++.i686
3. Install DB2 and upgrade to the latest fix pack. For more information, see the
"Installing the middleware software" section in the System Automation
Application Manager, Installation and Configuration Guide.
4. Install WebSphere Application Server and upgrade to the latest fix pack. For
more information, see the "Installing the middleware software" section in the
System Automation Application Manager, Installation and Configuration Guide.
5. Install System Automation Application Manager. For more information, see the
"Installing System Automation Application Manager" section in the System
Automation Application Manager, Installation and Configuration Guide.
6. Download and install the latest fix pack for System Automation Application
Manager version 3.2.2. Fix pack 2 or later is required. For a list of the available
fix packs, see http://www-933.ibm.com/support/fixcentral/swg/
selectFixes?parent=ibm~Tivoli&product=ibm/Tivoli/
Tivoli+System+Automation+Application+Manager&release=3.2.2
&platform=Linux&function=all.
7. Verify the System Automation Application Manager installation. For more
information, see the "Verifying the installation" section of the System
Automation Application Manager, Installation and Configuration Guide.
8. System Automation Application Manager uses a special tool (named getamdata)
to gather debug output. You must install the tool manually by following the
related documentation. For more information, see http://www-01.ibm.com/
support/docview.wss?&uid=swg27017972#tarball.
Starting System Automation Application Manager
Because System Automation Application Manager is not started when the virtual
machine where it is installed starts, you must start System Automation Application
Manager manually.
To start System Automation Application Manager, run the following commands:
su db2inst1 -c /home/db2inst1/sqllib/adm/db2start
/opt/IBM/WebSphere/AppServer/bin/startServer.sh server1
eezdmn start
eezaladapter start
Stopping System Automation Application Manager
To stop System Automation Application Manager, run the following commands:
eezaladapter stop
eezdmn -SHUTDOWN
/opt/IBM/WebSphere/AppServer/bin/stopServer.sh server1
-username <adminid> -password <password>
su db2inst1 -c /home/db2inst1/sqllib/adm/db2stop
108 IBM SmartCloud Orchestrator 2.3: User's Guide
where <adminid> and <password> are the credentials that you specified during the
installation.
Starting System Automation Application Manager automatically
To automatically start System Automation Application Manager at the startup of
the virtual machine where it is installed, perform the following steps:
1. Create as root a script named startup in the /etc/opt/IBM/tsamp/eez directory
with the following content:
su db2inst1 -c /home/db2inst1/sqllib/adm/db2start
sleep 10
/opt/IBM/WebSphere/AppServer/bin/startServer.sh server1
sleep 30
eezdmn start
eezaladapter start
2. Make sure the script is executable by running the following command:
chmod 755 /etc/opt/IBM/tsamp/eez/startup
3. Add the following lines at the end of the /etc/inittab file:
# start of SA AM
saam:5:wait:/etc/opt/IBM/tsamp/eez/startup
Ensure that the default run level in the inittab of theSystem Automation
Application Manager virtual machine is 5.
Note: This step in only valid for RHEL 5.x, but not for RHEL6.x and beyond.
For these newer versions of RHEL, you must copy the startup script to
/etc/rc.d/init.d, and create a symbolic link to it under /etc/rc.d/
rc$runlevel.d.
Planning for System Automation Application Manager
configuration
Adapt the sample configuration files delivered with System Automation
Application Manager to your SmartCloud Orchestrator environment.
In SmartCloud Orchestrator, the following configuration files are delivered in the
/iaas/scorchestrator/TSA_AM_Policy directory:
ala_SCO.xml
Sample agentless adapter policy configuration file for SmartCloud
Orchestrator
e2e_SCO.xml
Sample end-to-end policy configuration file for SmartCloud Orchestrator
Because you must modify the configuration files for your environment, the
following environment configuration is used to make the changes easier:
Table 12. Environment configuration in sample files
Section in sample file Sample value Value
Central server central-server-1 myserver1
central-server-2 myserver2
central-server-3 myserver3
central-server-4 myserver4
Chapter 2. Installing 109
Table 12. Environment configuration in sample files (continued)
Section in sample file Sample value Value
Region server VMware region-server-VM vmcloud1
IDforVMregion VMcloud1
Region server KVM region-server-KVM kvmcloud1
IDforKVMregion KVMcloud1
Region server PowerVM region-server-POWER pcloud1
IDforPOWERregion Pcloud1
Compute node KVM region-server-Compute kvmcompute1
IDforKVMcompute kvmcompute1
Note:
v If you have more than one VMware region server or KVM region server, define
a host name and a unique ID for each additional region server.
v If you have more than one KVM compute node, define a host name and a
unique ID for each additional compute node.
Modifying the sample configuration files
Make a copy of the sample System Automation Application Manager configuration
files and modify the files to adapt them to your SmartCloud Orchestrator
environment.
Agentless adapter policy
The agentless adapter policy is defined in the ala_SCO.xml configuration file. In the
configuration file, set the name of the agentless adapter automation domain as in
the following example:
<PolicyInformation>
<PolicyName>SCO_ala_Policy</PolicyName>
<AutomationDomainName>SCOalaPolicy</AutomationDomainName>
<PolicyToken>0.3.0</PolicyToken>
</PolicyInformation>
You can change the SCO_ala_Policy policy name. If you change the automation
domain name in the PolicyInformation section, ensure to change all the other
occurrences of the automation domain name in the configuration files.
Central server
In the ala_SCO.xml configuration file, modify the host name of the central servers
for each service by replacing central-server-# with the actual host name of the
server, for example, myserver#.
Note: The server where System Automation Application Manager is running is not
included, because System Automation Application Manager cannot manage its
own server.
For example, the Business Process Manager services are located on
central-server-4. There are three resources defined for Business Process Manager
and for each resource the node parameter must be set to myserver4. You must
modify the configuration file for the Business Process Manager resources as in the
following example:
110 IBM SmartCloud Orchestrator 2.3: User's Guide
<Resource name="bpm-server" class="IBM.RemoteApplication" node="myserver4">
<ClassAttributesReference>
<IBM.RemoteApplicationAttributes name="IBM.RemoteApplication.bpm-server"/>
</ClassAttributesReference>
</Resource>
<Resource name="bpm-node" class="IBM.RemoteApplication" node="myserver4">
<ClassAttributesReference>
<IBM.RemoteApplicationAttributes name="IBM.RemoteApplication.bpm-node"/>
</ClassAttributesReference>
</Resource>
<Resource name="bpm-dmgr" class="IBM.RemoteApplication" node="myserver4">
<ClassAttributesReference>
<IBM.RemoteApplicationAttributes name="IBM.RemoteApplication.bpm-dmgr"/>
</ClassAttributesReference>
</Resource>
Note: System Automation Application Manager must be able to resolve to the host
names that you specify. As an alternative, you can specify the IP address of the
central servers.
Region servers
SmartCloud Orchestrator installation requires cloud regions to host the deployed
systems. SmartCloud Orchestrator can manage three types of cloud regions:
OpenStack KVM, VMware, and PowerVM. You must adapt the policy depending
on your SmartCloud Orchestrator environment. The sample policy contains one
sample entry for each cloud region types. Delete all the sample sections of your
ala_SCO.xml policy file which are not applicable to your environment and adapt
the other sections to your environment.
VMware region server
In the ala_SCO.xml configuration file, modify the sample section related to a
VMware region. If you have more than one VMware region, ensure that you have
a section for each VMware region server and define a unique identifier for each
region. In the sample file, the unique identifier is IDforVMregion. In the following
example, your unique ID is VMcloud1. You must also change the node name to the
host name or IP address of the VMware region server. The sample node name is
region-server-VM. Adapt the whole section by globally replacing the strings
IdforVMregion and region-server-VM with the unique ID for this region and the
host name of the region server.
<Resource name="VMcloud1-remoteproxy" class="IBM.RemoteApplication" node="vmcloud1">
<ClassAttributesReference><IBM.RemoteApplicationAttributes
name="IBM.RemoteApplication.remoteproxy"/>
</ClassAttributesReference>
</Resource>
Note: System Automation Application Manager must be able to resolve to the host
name that you specify. As an alternative, you can specify the IP address of the
region server.
In the installation of the region server, it is possible to either use the shared central
DB2 or a local installation of DB2 on the region server. If you use the shared
central DB2, ensure that the local DB2 service definition is commented out in the
configuration file. If you use a local DB2, uncomment the DB2 server definition
and modify the host name of the region server as for the other services.
Chapter 2. Installing 111
For a VMware region server using a local DB2, change the IDforVMregion value to
the actual region server ID and change the region server host name to the actual
value. For example:
<Resource name="VMcloud1-db2" class="IBM.RemoteApplication" node="vmcloud1">
<ClassAttributesReference>
<IBM.RemoteApplicationAttributes name="IBM.RemoteApplication.db2"/>
</ClassAttributesReference>
</Resource>
KVM region server
In the ala_SCO.xml configuration file, modify the sample section related to the
OpenStack KVM region. If you have more than one KVM region, ensure that you
have a section for each KVM region server and define a unique identifier for each
region. In the sample file, the unique identifier is IDforKVMregion. In the following
example, your unique ID is KVMcloud1. You must also change the node name to the
host name or IP address of the OpenStack KVM region server. The sample node
name is region-server-KVM. Adapt the whole section by globally replacing the
strings IdforKVMregion and region-server-KVM with the unique ID for this region
and the host name of the region server.
<Resource name="KVMcloud1-remoteproxy" class="IBM.RemoteApplication"
node="kvmcloud1">
<ClassAttributesReference><IBM.RemoteApplicationAttributes
name="IBM.RemoteApplication.remoteproxy"/>
</ClassAttributesReference>
</Resource>
Note: System Automation Application Manager must be able to resolve to the host
name that you specify. As an alternative, you can specify the IP address of the
region server.
In the installation of the region server, it is possible to either use the shared central
DB2 or a local installation of DB2 on the region server. If you use the shared
central DB2, ensure that the local DB2 service definition is commented out in the
configuration file. If you use a local DB2, uncomment the DB2 server definition
and modify the host name of the region server as for the other services.
For an OpenStack KVM region server using a local DB2, change the
IDforKVMregion value to the actual region server ID and change the region server
host name to the actual value. For example:
<Resource name="KVMcloud1-db2" class="IBM.RemoteApplication" node="kvmcloud1">
<ClassAttributesReference>
<IBM.RemoteApplicationAttributes name="IBM.RemoteApplication.db2"/>
</ClassAttributesReference>
</Resource>
KVM compute node
In addition to a region server, each OpenStack KVM cloud region contains also
several compute servers. You must modify the related sample section in the
ala_SCO.xml configuration file. If you have more than one KVM compute node,
ensure that you have a section for each KVM compute node and that the resource
name contains a unique identifier. For example, for the nova-compute resource that
is located on the KVM compute node kvmcompute1, modify the configuration file to:
112 IBM SmartCloud Orchestrator 2.3: User's Guide
<Resource name="kvmcompute1-nova-compute" class="IBM.RemoteApplication" node="kvmcompute1">
<ClassAttributesReference>
<IBM.RemoteApplicationAttributes name="IBM.RemoteApplication.openstack-nova-compute"/>
</ClassAttributesReference>
</Resource>
Adapt the whole section by globally replacing the strings IdforKVMcompute and
region-server-Compute with the unique ID for this region and the host name of
the region server.
Note: System Automation Application Manager must be able to resolve to the host
name that you specify. As an alternative, you can specify the IP address of the
compute node.
PowerVM region server
In the ala_SCO.xml configuration file, modify the sample section related to a
PowerVM region. If you have more than one PowerVM region, ensure that you
have a section for each PowerVM region server and define a unique identifier for
each region. In the sample file, the unique identifier is IDforPOWERregion. In the
following example, your unique ID is Pcloud1. You must also change the node
name to the host name or IP address of the PowerVM region server. The sample
node name is region-server-POWER. Adapt the whole section by globally replacing
the strings IdforVMregion and region-server-VM with the unique ID for this region
and the host name of the region server.
<Resource name="Pcloud1-remoteproxy" class="IBM.RemoteApplication" node="pcloud1">
<ClassAttributesReference><IBM.RemoteApplicationAttributes
name="IBM.RemoteApplication.remoteproxy"/>
</ClassAttributesReference>
</Resource>
Note: System Automation Application Manager must be able to resolve to the host
name that you specify. As an alternative, you can specify the IP address of the
region server.
In the installation of the region server, it is possible to either use the shared central
DB2 or a local installation of DB2 on the region server. If you use the shared
central DB2, ensure that the local DB2 service definition is commented out in the
configuration file. If you use a local DB2, uncomment the DB2 server definition
and modify the host name of the region server as for the other services.
For a PowerVM region server using a local DB2, change the IDforPOWERregion
value to the actual region server ID and change the region server host name to the
actual value. For example:
<Resource name="Pcloud1-db2" class="IBM.RemoteApplication" node="pcloud1">
<ClassAttributesReference>
<IBM.RemoteApplicationAttributes name="IBM.RemoteApplication.db2"/>
</ClassAttributesReference>
</Resource>
End-to-End policy
The end-to-end policy is defined in the e2e_SCO.xml configuration file. The
configuration file contains sections for the VMware region server, the OpenStack
KVM region server, and the OpenStack KVM compute node. In the configuration
file, set the name of the end-to-end automation domain as in the following
example:
Chapter 2. Installing 113
<PolicyInformation>
<PolicyName>SCO_e2e_Policy</PolicyName>
<AutomationDomainName>SCOE2EPolicy</AutomationDomainName>
<PolicyToken>0.3.0</PolicyToken>
</PolicyInformation>
You can change the SCO_e2e_Policy policy name. If you change the automation
domain name in the PolicyInformation section, ensure to change all the other
occurrences of the automation domain name in the configuration file.
Note: If you changed the automation domain name in the agentless adapter policy
you must also change the SCOalaPolicy name to the new name in this
configuration file.
Central server
In the e2e_SCO.xml configuration file, modify the host name of the central servers
for each service by replacing central-server-# with the actual host name of the
server, for example, myserver#.
Note: The server where System Automation Application Manager is running is not
included, because System Automation Application Manager cannot manage its
own server.
For example, the bpm-dmgr service is located on central-server-4. You must
modify the configuration file as in the following example:
<ResourceReference name="bpm-dmgr">
<DesiredState>Online</DesiredState>
<ReferencedResource>
<AutomationDomain>SCOalaPolicy</AutomationDomain>
<Name>bpm-dmgr</Name>
<Class>IBM.RemoteApplication</Class>
<Node>myserver4</Node>
</ReferencedResource>
</ResourceReference>
Note: System Automation Application Manager must be able to resolve to the host
names that you specify. As an alternative, you can specify the IP address of the
central servers.
For DB2 defined on the central server, modify the configuration file as in the
following example:
<ResourceReference name="db2">
<DesiredState>Online</DesiredState>
<ReferencedResource>
<AutomationDomain>SCOalaPolicy</AutomationDomain>
<Name>db2</Name>
<Class>IBM.RemoteApplication</Class>
<Node>myserver1</Node>
</ReferencedResource>
</ResourceReference>
Region servers
Check the Top Level Resource Group in the e2e_SCO.xml sample file. The sample
file contains sample lines for each type of region server. Depending on your
SmartCloud Orchestrator environment, uncomment the type of region server that
you are using and adapt it accordingly.
114 IBM SmartCloud Orchestrator 2.3: User's Guide
VMware region server
In the e2e_SCO.xml configuration file, modify the section related to the VMware
region server by replacing:
v All the IDforVMregion instances to the ID you used in the agentless adapter
policy (for example, VMcloud1)
v All the region-server-VM instances to the actual VMware region server host
name (for example, vmcloud1)
If you have more than one VMware region, ensure that you have a section for each
VMware region server and that the resource name contains a unique identifier. The
section is contained between the comments VMware Region Server Start and
VMware Region Server End.
The end-to-end policy contains sample entries for a central DB2 server. If you use a
local DB2 server, uncomment the entry related to local DB2. You can find it by
searching for Local DB2 Service. Also, for the resource group that follows this
resource definition, you must uncomment the entry line for the local DB2.
Depending if a local DB2 or the central DB2 is used, you must adapt the
relationships. There are the sample sections Relationships to central DB2 and
Relationships to local DB2. In the sample, the relationships to the central DB2
are configured, the relationship to a local DB2 are commented out. If the central
DB2 is used, either leave the relationships for local DB2 commented out or delete
them. If a local DB2 is used, comment out or delete the relationships for the central
DB2 and uncomment the relationships for the local DB2. In addition to this, you
must replace all the sample IDforVMregion occurrences with the unique ID for this
region.
Note: System Automation Application Manager must be able to resolve to the host
name that you specify. As an alternative, you can specify the IP address of the
region server.
KVM region server
In the e2e_SCO.xml configuration file, modify the section related to the OpenStack
KVM region server by replacing:
v All the IDforKVMregion instances to the ID that you used in the agentless
adapter policy (for example, KVMcloud1)
v All the region-server-KVM instances to the actual KVM region server host name
(for example, kvmcloud1)
If you have more than one OpenStack KVM region server, ensure that you have a
section for each KVM region server and that the resource name contains a unique
identifier. The section is contained between the comments OpenStack KVM Region
Server Start and OpenStack KVM Region Server End.
The end-to-end policy contains sample entries for a central DB2 server. If you use a
local DB2 server, uncomment the entry related to local DB2. You can find it by
searching for Local DB2 Service. Also, for the resource group that follows this
resource definition, you must uncomment the entry line for the local DB2.
Depending if a local DB2 or the central DB2 is used, you must adapt the
relationships. There are the sample sections Relationships to central DB2 and
Relationships to local DB2. In the sample, the relationships to the central DB2
are configured, the relationship to a local DB2 are commented out. If the central
Chapter 2. Installing 115
DB2 is used, either leave the relationships for local DB2 commented out or delete
them. If a local DB2 is used, comment out or delete the relationships for the central
DB2 and uncomment the relationships for the local DB2. In addition to this, you
must replace all the sample IDforKVMregion occurrences with the unique ID for
this region.
Note: System Automation Application Manager must be able to resolve to the host
name that you specify. As an alternative, you can specify the IP address of the
region server.
KVM compute node
In the e2e_SCO.xml configuration file, modify the section related to the OpenStack
KVM compute node by replacing:
v All the IDforKVMcompute instances to the ID that you used in the agentless
adapter policy (for example, KVMcompute1)
v All the region-server-Compute instances to the actual KVM compute node host
name (for example, kvmcompute1)
If you have more than one OpenStack KVM compute node, ensure that you have a
section for each KVM compute node and that the resource name contains a unique
identifier. The section is contained between the comments OpenStack KVM Compute
Server Start and OpenStack KVM Compute Server End.
Note: System Automation Application Manager must be able to resolve to the host
name that you specify. As an alternative, you can specify the IP address of the
compute node.
PowerVM region server
In the configuration file, modify the section related to the PowerVM region server
by replacing:
v All the IDforPOWERregion instances to the ID you used in the agentless adapter
policy (for example, Pcloud1)
v All the region-server-POWER instances to the actual PowerVM region server host
name (for example, pcloud1)
If you have more than one PowerVM region, ensure that you have a section for
each PowerVM region server and that the resource name contains a unique
identifier. The section is contained between the comments PowerVM Region Server
Start and PowerVM Region Server End.
The end-to-end policy contains sample entries for a central DB2 server. If you use a
local DB2 server, uncomment the entry related to local DB2. You can find it by
searching for Local DB2 Service. Also, for the resource group that follows this
resource definition, you must uncomment the entry line for the local DB2.
Depending if a local DB2 or the central DB2 is used, you must adapt the
relationships. There are the sample sections Relationships to central DB2 and
Relationships to local DB2. In the sample, the relationships to the central DB2
are configured, the relationship to a local DB2 are commented out. If the central
DB2 is used, either leave the relationships for local DB2 commented out or delete
them. If a local DB2 is used, comment out or delete the relationships for the central
DB2 and uncomment the relationships for the local DB2. In addition to this, you
must replace all the sample IDforPOWERregion occurrences with the unique ID for
this region.
116 IBM SmartCloud Orchestrator 2.3: User's Guide
Note: System Automation Application Manager must be able to resolve to the host
name that you specify. As an alternative, you can specify the IP address of the
region server.
Validating the policy
To check the validity of the policy xml file with the System Automation
Application Manager policy checker tool, run the following command:
eezpolicychecker /<policy_file_path>/<policy_filename>.xml
Configuring System Automation Application Manager
Configure System Automation Application Manager to work with SmartCloud
Orchestrator.
Before you begin
System Automation Application Manager requires access to all the servers to
manage the related services. Use one of the following options to set the access by
using SSH:
v Set up an SSH key infrastructure by running the following procedure:
1. Log on as root to the server where System Automation Application Manager
is installed.
2. Run the following command:
ssh-keygen -t rsa
Accept the default values and press enter when asked for the passphrase. A
new SSH key that does not require any password is created in the
/root/.ssh directory.
3. Run the following commands:
chmod 700 /root/.ssh
cat /root/.ssh/id_rsa.pub >> /root/.ssh/authorized_keys
chmod 600 /root/.ssh/authorized_keys
4. Concatenate the content of the /root/.ssh/id_rsa.pub file to the
/root/.ssh/authorized_keys file for all the central servers, all the region
servers, and all the OpenStack compute servers, by running the following
command:
ssh <servername> "echo ` cat /root/.ssh/id_rsa.pub` >> /root/.ssh/authorized_keys"
The /root/.ssh directory must have security set to 700 and the
/root/.ssh/authorized_keys file must have security set to 600 on all the
servers. To verify these settings, log on as root to all the servers from the
System Automation Application Manager server. Accept the server keys to
avoid any prompt in the following SSH accesses.
v Configure System Automation Application Manager to use user ID and
password to access the servers. To do this, an additional steps is added in the
following configuration procedure.
To ensure that System Automation Application Manager has full control on the
SmartCloud Orchestrator services, the service autostart must be disabled by
running the following procedure:
1. On Central Server 1, edit the /etc/rc.local file and comment out the following
lines to disable the DB2 autostart:
/opt/ibm/db2/v10.1/bin/db2fm -i db2inst1 -U -u
/opt/ibm/db2/v10.1/bin/db2fm -i db2inst1 -f on
Chapter 2. Installing 117
Run the following commands:
cd /etc/init
mv db2fmcd.conf db2fmcd.conf_off
2. On Central Server 2, run the following commands:
chkconfig openstack-iaasgateway off
chkconfig openstack-keystone off
chkconfig vil off
chkconfig vilProxy off
chkconfig pcg off
3. On Central Server 3, run the following commands:
chkconfig iwd off
chkconfig scui off
4. On Central Server 4, run the following command:
chkconfig bpm off
5. On the region servers, if a local DB2 is installed, edit the /etc/rc.local file and
comment out the following lines:
/opt/ibm/db2/v10.1/bin/db2fm -i db2inst1 -U -u
/opt/ibm/db2/v10.1/bin/db2fm -i db2inst1 -f on
Run the following commands:
cd /etc/init
mv db2fmcd.conf db2fmcd.conf_off
6. On the VMware region server, run the following commands:
chkconfig qpidd off
chkconfig sce off
chkconfig vilProxy off
chkconfig openstack-cinder-api off
chkconfig openstack-cinder-scheduler off
chkconfig openstack-cinder-volume off
chkconfig openstack-glance-api off
chkconfig openstack-glance-registry off
chkconfig openstack-nova-api off
chkconfig openstack-nova-cert off
chkconfig openstack-nova-conductor off
chkconfig openstack-nova-consoleauth off
chkconfig openstack-nova-network off
chkconfig openstack-nova-novncproxy off
chkconfig openstack-nova-scheduler off
chkconfig openstack-smartcloud off
7. On the KVM region server, run the following commands:
chkconfig qpidd off
chkconfig vilProxy off
chkconfig openstack-cinder-api off
chkconfig openstack-cinder-scheduler off
chkconfig openstack-cinder-volume off
chkconfig openstack-glance-api off
chkconfig openstack-glance-registry off
chkconfig openstack-nova-api off
chkconfig openstack-nova-cert off
chkconfig openstack-nova-conductor off
chkconfig openstack-nova-consoleauth off
chkconfig openstack-nova-scheduler off
8. On the KVM compute node, run the following commands:
chkconfig openstack-nova-compute off
chkconfig openstack-nova-metadata-api off
chkconfig openstack-nova-network off
chkconfig openstack-nova-novncproxy off
9. On the PowerVM, run the following commands:
118 IBM SmartCloud Orchestrator 2.3: User's Guide
chkconfig qpidd off
chkconfig sce off
chkconfig vilProxy off
chkconfig openstack-cinder-api off
chkconfig openstack-cinder-scheduler off
chkconfig openstack-cinder-volume off
chkconfig openstack-glance-api off
chkconfig openstack-glance-registry off
chkconfig openstack-nova-api off
chkconfig openstack-nova-cert off
chkconfig openstack-nova-conductor off
chkconfig openstack-nova-consoleauth off
chkconfig openstack-nova-network off
chkconfig openstack-nova-novncproxy off
chkconfig openstack-nova-scheduler off
chkconfig openstack-smartcloud off
System Automation Application Manager needs control script to manage the
SmartCloud Orchestrator applications. The control scripts are delivered in the
/iaas/scorchestrator directory on the server from which the installation is started
(Central Server 1, by default). Create on all the SmartCloud Orchestrator
management servers, region control servers, and KVM compute nodes, a directory
named /home/saam and copy all the control scripts that end with .sh from the
/iaas/scorchestrator to the /home/saam on all the servers.
About this task
To configure System Automation Application Manager to use the policies that you
defined, run the following procedure:
Procedure
1. Copy the policy configuration files to the System Automation Application
Manager server:
a. Copy the ala_SCO.xml configuration file to the /etc/opt/IBM/tsamp/eez/
aladapterPolicyPool/ directory.
b. Copy the e2e_SCO.xml configuration file to the /etc/opt/IBM/tsamp/eez/
policyPool/ directory.
2. Configure System Automation Application Manager to use the defined policies
by performing the following steps:
a. Run the cfgeezdmn command. The System Automation Application Manager
Configuration window is displayed.
b. In the Application Manager tab, click Configure. The Application Manager
Common Configuration window is displayed.
c. In the Domain tab, enter the AutomationDomainName value that you specified
in the e2e_SCO.xml configuration file, for example, SCOE2EPolicy,in the
Domain Name field.
d. Enter the host name or the IP address of the System Automation
Application Manager server.
e. In the Command Shell tab, select Use specified user credentials and enter
the administrator user ID that you created during the installation. The
default user is eezadmin. To change the password value to the password
specified during the installation, click Change..., enter the password, and
click OK.
f. Select Use FLA domain access credentials as defined under "User
credentials".
Chapter 2. Installing 119
g. In the User Credentials tab in the Credentials for accessing first-level
automation (FLA) domains section, enter root in the Generic user ID for
FLA domains field. To change the password value, click Change..., enter the
password, and click OK.
h. In the Security tab, enter /root/.ssh/id_rsa in the Keystore field.
i. Click Save to confirm your changes and close the Application Manager
Common Configuration window.
j. In the Non-clustered Nodes tab of the System Automation Application
Manager Configuration window, check Enable local Agentless Adapter
configuration, and click Configure to configure the local agentless adapter.
The Application Manager Local Agentless Adapter Configuration window is
displayed.
k. If you do not use the shared SSH for System Automation Application
Manager access to the SmartCloud Orchestrator servers, configure System
Automation Application Manager with the root credentials by performing
the following steps:
1) Click the User Credentials tab and click Add....
2) In the displayed window enter as Node name the server name or the IP
address of a SmartCloud Orchestrator server.
3) Enter the root credentials on this server in the User ID, Password, and
Password confirmation fields.
4) Repeat these steps for all the central servers, all the region servers and
all the OpenStack KVM compute servers in your SmartCloud
Orchestrator environment.
l. In the Adapter tab, click Add... and specify the AutomationDomainName value
that you specified in the ala_SCO.xml configuration file, for example,
SCOalaPolicy in the Domain Name field.
m. In the Security tab, check Enable user authentication with SSH public and
private keys in the Communication between Agentless Adapter and
remote non-clustered nodes section and enter /root/.ssh/id_rsa in the
SSH private key file field.
n. Click Save to confirm your changes and close the Application Manager
Local Agentless Adapter Configuration window.
o. Click Done.
3. Load and activate the xml configuration files by performing the following
steps:
a. Log on to System Automation Application Manager web user interface at
https://<SAAM server hostname>:9043/ibm/console/. Specify the user and
password that you defined during the installation. The default user is
eezadmin.
b. On the left pane, click Tivoli System Automation > SA Operations
Console.
c. In the Topology section, click the end-to-end automation domain name that
you specified, for example, SCOE2EPolicy.
d. In the Information Area on the right, in the Policy tab, click Activate New
Policy....
e. In the displayed panel, select the configuration file that you want to use for
the end-to-end policy and click Activate. If you see a closed lock on the
right of the policy name, click the policy name and enter the root
credentials to access the agentless adapter installed on the System
Automation Application Manager virtual machine.
120 IBM SmartCloud Orchestrator 2.3: User's Guide
The policy is activated.
f. In the Topology section, click the agentless adapter automation domain
name that you specified, for example, SCOalaPolicy.
g. In the Information Area on the right, in the Policy tab, click Activate New
Policy....
h. In the displayed panel, select the configuration file that you want to use for
the agentless adapter policy and click Activate. The policy is activated.
Results
System Automation Application Manager is configured and the policies are
activated. System Automation Application Manager checks the status of the
SmartCloud Orchestrator management services and starts them if needed. After the
services are started, System Automation Application Manager detects any outage
of the SmartCloud Orchestrator management services and automatically restart
them.
If you want to stop any services, see System Automation Application Manager in
Controlling the management stack on page 124.
(Optional) Post configuring System Automation Application
Manager with SmartCloud Orchestrator
This topic describes how to configure System Automation Application Manager to
work with SmartCloud Orchestrator with a non-root user ssh.
Before you begin
Before starting this post configuration, ensure that you have completed the steps
described in Configuring System Automation Application Manager on page 117
About this task
Note: The following commands are all run as root on the server indicated, shell
for lists with the server names should not be put into "".
Procedure
1. Clean up the root access: If root-ssh is already working, do the following to
clean up the root access:
a. On System Automation Application Manager, stop System Automation
Application Manager to avoid error messages during the change:
eezaladapter stop
eezdmn -SHUTDOWN
/opt/IBM/WebSphere/AppServer/bin/stopServer.sh server1 -username <yourname> -password <yourpassword>
su db2inst1 -c /home/db2inst1/sqllib/adm/db2stop
b. Delete the /home/saam scripts on all SmartCloud Orchestrator servers (This
command is executed from the System Automation Application Manager
server with root ssh still working):
for i in <list of your SCO servers>; do ssh $i "rm -rf /home/saam"; done
c. Delete authorized_keys from /root/.ssh/.
2. Copy the sample files in the SmartCloud Orchestrator package:
Copy $install-images/installer/tools/scorchestrator/TSA_AM_Policy/
ala_SCO_nonroot_sample/* to <your_path> on the System Automation
Application Managerserver as root.
Chapter 2. Installing 121
Note: The sample files are all configured using a user named mechasaam.
Search for this in the sample files and change them to the user name you
want to use.
3. Prepare the System Automation Application Manager server for non-root ssh
to the SmartCloud Orchestrator servers:
a. On System Automation Application Manager, create a new user
<yourmechid> and set the password:
useradd -m <yourmechid>
passwd <yourmechaid> #enter at the prompt <yourmechapwd>
b. On System Automation Application Manager, create a directory .ssh,
generate the ssh keys for <yourmechid> and set file permissions:
su - <yourmechid> -c "mkdir .ssh"
su - <yourmechid> -c "ssh-keygen -q -t rsa -N -f ~/.ssh/id_rsa"
su - <yourmechid> -c "chmod 700 .ssh"
c. Copy wrap.py to the path where the control scripts are stored:
/home/<yourmechid>/root/
d. Copy sudoers.saam to the path where the control scripts are stored:
/home/<yourmechid>/root/
e. On System Automation Application Manager, copy the sample files to
<yourmechid> home and change users:
cp -R <your_path>/* /home/yourmechid/
chown <yourmechid>:<yourmechidgroup> /home/<yourmechid>/*
4. Prepare the SmartCloud Orchestrator servers for non-root ssh access:
Note: This must be performed on all Central Servers and Region Servers.
a. On the SmartCloud Orchestrator servers, create a new user <yuormechid>
and set the password:
useradd -m <yourmechid>
passwd <yourmechaid> #enter at the prompt <yourmechapwd>
b. On the SmartCloud Orchestratorservers, create a directory .ssh and set file
permits.
c. On the SmartCloud Orchestrator servers, create a root owned directory
that contains control scripts:
mkdir /home/<yourmechid>/root
chmod 755 /home/<yourmechid>/root
5. Copy the ssh keys from System Automation Application Manager to the
SmartCloud Orchestrator servers and verify that the new user <yourmechid>
can access all SmartCloud Orchestrator servers without password:
a. On System Automation Application Manager, run the following command:
for i in <list of your SCO servers>; do su - <yourmechid> -c "scp ~/.ssh/id_rsa.pub $i:~/.ssh/authorized_keys"; done
Note: It is important in the command that you accept the server key and
the password required is of <yourmechid>.
b. Verify that <yourmechid> on the System Automation Application Manager
server can ssh without interruption to <yourmechid> on your SmartCloud
Orchestrator servers:
su - <yourmechid> -c "ssh <yourmechid>@$SCO_server_ip"
6. Create directory for control scripts and set file permits:
a. On Central Server 1 run:
for i in <list of your SCO servers>;do scp /iaas/scorchestrator/*.sh root@$i:/home/<yourmechid>/root/; done
for i in <list of your SCO servers>;do ssh $i "chmod 755 /home/<yourmechid>/root/*.sh"; done
122 IBM SmartCloud Orchestrator 2.3: User's Guide
b. On Central Server 2 run:
ln -s /home/library/manageVilComponents.sh /home/<yourmechid>/root/manageVilComponents.sh
c. On the Region Servers run:
ln -s /home/library/manageVilProxyComponents.sh /home/<yourmechid>/root/manageVilProxyComponents.sh
7. Deploy wrapper script on the SmartCloud Orchestrator servers:
a. On the System Automation Application Manager server, create a directory
and set file permits:
for i in <list of your SCO servers>;do su - <yourmechid> -c "ssh $i mkdir ~/wrap; chmod 700 ~/wrap"; done
b. On the System Automation Application Manager server, copy wrap script
to wrap directory and set file permit:
for i in <list of your SCO servers>;do su - <yourmechid> -c "scp wrap.py <yourmechid>@$i:~/wrap/"; done
for i in <list of your SCO servers>;do su - <yourmechid> -c "scp sample.askpass.sh sample.bashrc <yourmechid>@$i:"; done
for i in <list of your SCO servers>;do su - <yourmechid> -c "ssh $i chmod 700 ~/wrap/wrap.py; chmod 600 ~/sample.askpass.sh; chmod 600 ~/sam
8. Deploy sudo rules for the new user <yourmechid>:
a. On System Automation Application Manager, copy the sudo rule to the
SmartCloud Orchestrator servers:
for i in <list of your SCO servers>;do scp ~/non-root/saam.sudoers $i:/etc/sudoers.d/saam; done
b. On System Automation Application Manager, set file permission:
for i in <list of your SCO servers>;do ssh $i "chmod 440 /etc/sudoers.d/saam"; done
9. Adapt non-root_ala_SCO.xml as the standard ala_SCO.xml and copy to the
correct directory:
To modify the ala_SCO.xml, refer to the standard SmartCloud Orchestrator
documentation at Modifying the sample configuration files on page 110.
Also, follow the documentation for the e2e policy .
10. Reconfiguring System Automation Application Manager:
On the System Automation Application Manager server:
a. Run the cfgeezdmn command. The System Automation Application
Manager Configuration window is displayed .
b. In the Non-clustered Nodes tab of the System Automation Application
Manager Configuration window, click Configure to configure the local
agentless adapter.
c. The Application Manager Local Agentless Adapter Configuration
window is displayed.
d. In the Security tab, check Enable user authentication with SSH public
and private keys in the Communication between Agentless Adapter and
remote non-clustered nodes section and enter /home/<yourmechid>/.ssh/
id_rsa in the SSH private key file field.
e. Click Save to confirm your changes and close the Application Manager
Local Agentless Adapter Configuration window.
11. Start System Automation Application Manager:
On the System Automation Application Manager server, run the following
commands:
su db2inst1 -c /home/db2inst1/sqllib/adm/db2start
/opt/IBM/WebSphere/AppServer/bin/startServer.sh server1
eezdmn start
eezaladapter start
Chapter 2. Installing 123
Controlling the management stack
Use System Automation Application Manager to control the SmartCloud
Orchestrator management stack to shut down the whole stack or specific services
for maintenance and planned outages.
About this task
In addition to stopping a specific service, System Automation Application Manager
can also ensure that any dependencies between services are automatically resolved.
For example, if you want to stop DB2 for a backup, before stopping the DB2
service, all the services requiring DB2 are automatically stopped.
Important: If you plan to reboot or shut down a SmartCloud Orchestrator virtual
machine, you must stop the SmartCloud Orchestrator services on this virtual
machine via System Automation Application Manager before the OS is shut down
or rebooted. Otherwise,System Automation Application Manager might set a
resource in error. To resolve the error, follow the steps described in
Troubleshooting System Automation Application Manager on page 125. After the
virtual machine is started again, you can start the services by cancelling the offline
request as described in the following procedure.
To stop a SmartCloud Orchestrator service by using System Automation
Application Manager, perform the following steps:
Procedure
1. Log on to System Automation Application Manager web user interface at
https://<SAAM server hostname>:9043/ibm/console/. Specify the user and
password that you defined during the installation. The default user is eezadmin.
2. On the left pane, click Tivoli System Automation > SA Operations Console. In
the console, you can see if all the services are working according to the defined
policies.
3. In the Topology section, click the end-to-end automation domain name that
you specified, for example, SCOE2EPolicy.
4. In the Resources section for the policy, click the SCO resource group to expand
the list of all the related resources and resource groups.
5. If you want to stop the whole SmartCloud Orchestrator management stack,
click Request Offline... in the Resource Group Status section. Enter a comment
in the displayed window and click Submit.
6. If you want to stop a specific resource, click on the resource name to select it
and click Request Offline... in the Resource Reference Status section. Enter a
comment in the displayed window and click Submit. The service and all the
dependent services are stopped.
7. To restart a resource or a resource group, click Cancel Request in the Resource
Reference Status or Resource Group Status section.
Results
You stopped and restarted the SmartCloud Orchestrator services.
For more information about using System Automation Application Manager, see
the System Automation Application Manager, Administrator's and User's Guide.
124 IBM SmartCloud Orchestrator 2.3: User's Guide
Troubleshooting System Automation Application Manager
Troubleshoot problems that might occur when running System Automation
Application Manager.
Resource in error
If a resource is in error, perform the following steps:
1. Log on to the System Automation Application Manager web user interface at
https://<SAAM server hostname>:9043/ibm/console/. Specify the user and
password that you defined during the installation. The default user is eezadmin.
2. On the left pane, click Tivoli System Automation > SA Operations Console.
An error icon is displayed for the end-to-end automation policy.
3. In the Topology section, click the end-to-end automation domain name that
you specified, for example, SCOE2EPolicy.
4. In the Resources section for the policy, click the SCO resource group to expand
the list of all the related resources and resource groups. Continue to expand the
resource groups where the error icon is displayed until you select the resource
in error. In the Resource Reference Status section the following message is
displayed:
The resource has an unrecoverable problem.
5. Click Reset to try to recover the problem by restarting the resource with the
System Automation Application Manager control.
6. To understand the cause of the problem, you can check the log files by
performing the following steps:
a. In the Topology section, click the agentless adapter domain name that you
specified, for example, SCOalaPolicy.
b. In the General tab of Information Area section, click View Log in the Log
section.
c. In the Log Viewer window, scroll down the message list until you find an
entry marked as ERROR. You can read the related log to find the cause of the
problem.
Using /etc/hosts
If the /etc/hosts file is used for System Automation Application Manager to
resolve the host name of the SmartCloud Orchestrator servers, you must restart
System Automation Application Manager after each change in the /etc/hosts file
to allow System Automation Application Manager to use the changes.
Stopping automation for a resource or a resource group for manual
interaction
If you need to manual interact with a SmartCloud Orchestrator management stack
resource or resource group, you must stop the System Automation Application
Manager automation to avoid that System Automation Application Manager
controls the resource and tries to bring it to the desired state. For example, if you
are upgrading the product or installing a fix, you might need to start and stop a
resource. To stop the System Automation Application Manager automation,
perform the following steps:
1. Log on to the System Automation Application Manager web user interface at
https://<SAAM server hostname>:9043/ibm/console/. Specify the user and
password that you defined during the installation. The default user is eezadmin.
Chapter 2. Installing 125
2. In the Topology section, click the end-to-end automation domain name that
you specified, for example, SCOE2EPolicy.
3. In the Resources section for the policy, click the SCO resource group to expand
the list of all the related resources and resource groups.
4. Click the resource or resource group for which you want to temporarily
suspend the System Automation Application Manager automation.
5. Click Suspend Automation... in the Resource Reference Status or Resource
Group Status section. In the displayed window, click Submit. The resource or
the resource group and all the resources in the group are excluded from the
System Automation Application Manager automation.
6. After you finish to manually interact with the resource or the resource group,
you can resume the automation by clicking Resume Automation. System
Automation Application Manager brings the resource or the resource group to
the desired state.
Gathering information for problem determination
In the default configuration file for the pdcollect tool, the log collection for System
Automation Application Manager is not enabled.
To collect logs for System Automation Application Manager, add the following
lines in the Environment.xml file:
<host hostname="SAAM_host">
<component name="ALL"/>
<component name="SAAM"/>
</host>
You must replace the SAAM_host string with the host name or the IP address of the
System Automation Application Manager virtual machine.
For more information about the pdcollect tool, see Problem determination with
pdcollect tool on page 1078.
Ports used by SmartCloud Orchestrator
This topic describes the ports used by SmartCloud Orchestrator across the stack of
components.
Table 13. Ports used by SmartCloud Orchestrator
Port
number Protocol From To
9443 HTTPS Image Construction and
Composition Tool
Virtual Image Library server on
Central Server 2
9443 HTTPS Workload Deployer Virtual Image Library server on
Central Server 2
9443 HTTPS Web browser with which the
SmartCloud UI is accessed
Virtual Image Library server on
Central Server 2
9443 HTTPS Web browser with which the
Virtual Image Library UI is
accessed
Virtual Image Library server on
Central Server 2
9043 HTTPS Web browser with which the
WebSphere Web console is
accessed
Virtual Image Library server on
Central Server 2
126 IBM SmartCloud Orchestrator 2.3: User's Guide
Table 13. Ports used by SmartCloud Orchestrator (continued)
Port
number Protocol From To
9060 HTTP Web browser with which the
WebSphere Web console is
accessed
Virtual Image Library server on
Central Server 2
4444 Virtual Image Library proxy Virtual Image Library proxy
9443 HTTPS Business Process Designer Business Process Manager on
Central Server 4
2809 TCP Business Process Designer Business Process Manager on
Central Server 4
7276 TCP Business Process Designer Business Process Manager on
Central Server 4
7286 TCP Business Process Designer Business Process Manager on
Central Server 4
9403 HTTP Business Process Designer Business Process Manager on
Central Server 4
9080 HTTP Business Process Designer Business Process Manager on
Central Server 4
9100 ORB Business Process Designer Business Process Manager on
Central Server 4
9810 ORB Business Process Designer Business Process Manager on
Central Server 4
9405 RMI/IIOP,
SSL
Business Process Designer Business Process Manager on
Central Server 4
9201 RMI/IIOP,
SSL
Business Process Designer Business Process Manager on
Central Server 4
9080 HTTP Web browser with which
Business Process Manager is
accessed
Business Process Manager on
Central Server 4
9080 HTTP SmartCloud UI on Central
Server 3
Business Process Manager on
Central Server 4
80 HTTP Business Process Manager on
Central Server 4
Workload Deployer on Central
Server 3
80 HTTP SmartCloud UI on Central
Server 3
internet (infocenter)
443 HTTPS Business Process Manager on
Central Server 4
Workload Deployer on Central
Server 3
443 HTTPS Virtual Image Library server
on Central Server 2
VMware vCenter
443 HTTPS Web browser with which the
Image Construction and
Composition Tool is accessed
Image Construction and
Composition Tool
443 HTTPS SmartCloud Entry driver VMware vCenter
7443 HTTPS Web browser with which the
SmartCloud UI is accessed
SmartCloud UI on Central
Server 3
9973 HTTP SmartCloud UI on Central
Server 3
IAAS Gateway on Central Server
2
9973 HTTP Workload Deployer on
Central Server 3
IAAS Gateway on Central Server
2
Chapter 2. Installing 127
Table 13. Ports used by SmartCloud Orchestrator (continued)
Port
number Protocol From To
9973 HTTP Image Construction and
Composition Tool
IAAS Gateway on Central Server
2
6379 Virtual Image Library proxy Virtual Image Library proxy on
Central Server 2
8123 HTTP Virtual Image Library server
on Central Server 2
Virtual Image Library proxy
22 SSH Image Construction and
Composition Tool
Extended image
22 SSH Workload Deployer on
Central Server 3
Deployed virtual systems
445 TCP Image Construction and
Composition Tool
Extended image (Windows only)
445 TCP Workload Deployer on
Central Server 3
Deployed virtual systems
(Windows only)
80 Image Construction and
Composition Tool
Extended image
9797 HTTP Virtual Image Library server
on Central Server 2
Public Cloud Gateway
9797 HTTP Workload Deployer on
Central Server 3
Public Cloud Gateway
8776 HTTP OpenStack cinder
9292 HTTP Virtual Image Library server
on Central Server 2
OpenStack glance
5000 HTTP SmartCloud UI on Central
Server 3
OpenStack keystone
5000 HTTP Workload Deployer on
Central Server 3
OpenStack keystone
5000 HTTP Virtual Image Library server
on Central Server 2
OpenStack keystone
35357 HTTP SmartCloud UI on Central
Server 3
OpenStack keystone
35357 HTTP Workload Deployer on
Central Server 3
OpenStack keystone
35357 HTTP Virtual Image Library server
on Central Server 2
OpenStack keystone
8774 HTTP Workload Deployer on
Central Server 3
OpenStack nova
8774 HTTP Virtual Image Library server
on Central Server 2
OpenStack nova
902 HTTP Virtual Image Library proxy VMware ESXis
53 UDP Central Server 1 (if DNS
server is installed)
Any system using the DNS
server
123 UDP Central Server 1 (if NTP
server is installed)
Any system using the NTP
server
ICMP Workload Deployer on
Central Server 3
Deployed virtual systems
128 IBM SmartCloud Orchestrator 2.3: User's Guide
Table 13. Ports used by SmartCloud Orchestrator (continued)
Port
number Protocol From To
ICMP Extended image (Windows
only)
Image Construction and
Composition Tool
ICMP Deployed virtual systems
(Windows only and only if
using add-ons and script
packages)
Workload Deployer on Central
Server 3
139 TCP Workload Deployer on
Central Server 3
Deployed virtual systems
(Windows only)
50000 TCP Virtual Image Library Server
on Central Server 2
DB2 Service on Central Server 1
50000 TCP Workload Deployer on
Central Server 3
DB2 Service on Central Server 1
50000 TCP Business Process Manager on
Central Server 4
DB2 Service on Central Server 1
50000 TCP OpenStack Service on Region
Server
If share_central_db="yes" in
region.server.cfg, DB2 Service
on Central Server 1
Note: For more information on the ports, refer to file /etc/services on each
server.
Chapter 2. Installing 129
130 IBM SmartCloud Orchestrator 2.3: User's Guide
Chapter 3. Getting started
After installing and configuring SmartCloud Orchestrator, learn how to start to use
the product to work with virtual images in your cloud environment.
Before you begin
SmartCloud Orchestrator offers many features to manage your cloud infrastructure.
For more information, see Product features on page 5.
SmartCloud Orchestrator is based on OpenStack to manage the following types of
hypervisor:
v KVM
v VMware ESX (through VMware vCenter)
v IBM PowerVM (through VMControl)
For more information about OpenStack, see Overview of OpenStack on page 8.
Be sure that your SmartCloud Orchestrator environment is started and working.
For more information about starting SmartCloud Orchestrator, see Starting or
stopping SmartCloud Orchestrator on page 135.
Be sure that you have a user to perform the following procedure. A user with the
admin role can perform any step in the procedure. For more information about
users, see Managing users, projects, and domains on page 149. For more
information about roles, see User roles in SmartCloud Orchestrator on page 151.
About this task
To start to work with SmartCloud Orchestrator, perform the following steps:
Procedure
1. Access the SmartCloud Orchestrator user interface.
Log in to the SmartCloud Orchestrator following URL:
https://central-server-3_fqdn
where central-server-3_fqdn is the fully-qualified domain name of Central
Server 3.
Note: Do not use the IP address to access the SmartCloud Orchestrator user
interface.
When logging in to the SmartCloud Orchestrator user interface, you can specify
a scope for the user by entering the domain to which the user belongs. If you
do not specify any domain, the user is authenticated to the Default domain. By
default, the user is also authenticated to the scope of the primary project that
you specified when you created the user in order to access cloud resources.
After logging in, you can change the project scope by selecting a new project
from the project list in the top banner of the user interface. For more
information about users, projects, and domains, see Managing users, projects,
and domains on page 149.
Copyright IBM Corp. 2013, 2014 131
For more information about accessing SmartCloud Orchestrator user interfaces,
see Accessing SmartCloud Orchestrator user interfaces on page 135.
2. Create virtual images in your environment.
SmartCloud Orchestrator supports virtual images that contain the scp-cloud-init
script and the Activation Engine. SmartCloud Orchestrator also supports virtual
images that run on VMware, if the images contain the Activation Engine and
the VMware tools are installed. Use the Image Construction and Composition
Tool to create images that are supported by SmartCloud Orchestrator.
SmartCloud Orchestrator also supports virtual images that run on PowerVM.
For more information, see Working with IBM Image Construction and
Composition Tool on page 387.
You can also create images in your OpenStack environment by following the
procedure described in Creating new images or using existing images on
page 488.
3. Define virtual images to SmartCloud Orchestrator.
Before you can use the virtual images that you created, you must define them
to the SmartCloud Orchestrator environment by using one of the following
procedures:
v If you want to import an OVA image file, follow the procedure described in
Importing a virtual image to the catalog on page 289.
When you import an image, the image location can be either an HTTP URL
or you can transfer the image using Secure Copy Protocol (SCP) with the
following format: <hostname>:/path. The images that are located in the
/data/repos/scp directory on Central Server-1 can be accessed by specifying
the HTTP URL in the following format:
http://central-server-1_ip/scp/my_virtual_image.ova
where central-server-1_ip is the IP address of Central Server-1.
The image that you imported is stored in the reference repository in the
Virtual Image Library. Before you can deploy the virtual image in a pattern,
you must copy the image to an OpenStack operational repository (KVM,
VMware, or PowerVM). Access the Virtual Image Library user interface by
clicking Images & Patterns > Virtual Image Library, and follow the
procedure described in Copying an image from the reference repository on
page 322.
In Virtual Image Library you can also perform advance management tasks
on the virtual images. For more information, see Working with Virtual
Image Library on page 295.
v If you want to define the virtual images that are stored in your OpenStack
environment, follow the procedure described in Registering a virtual image
on page 290.
When you register an image, you can choose it from a list of the available
images available in the OpenStack region that you selected. If you are using
a VMware hypervisor or a PowerVM hypervisor, the available images are
automatically discovered in your OpenStack environment when the vCenter
connection or VMControl connection is established. If you are using a KVM
hypervisor, before registering an image to SmartCloud Orchestrator, you
must add the image to your OpenStack environment. For more information,
see Adding images to OpenStack on page 294.
You can also perform advance management tasks on the images that are
available in your OpenStack environment by using Virtual Image Library. For
more information, see Working with Virtual Image Library on page 295.
4. Create an environment profile.
132 IBM SmartCloud Orchestrator 2.3: User's Guide
Use environment profiles to group related deployment configuration options
together, and deploy from a single pattern. For more information about
environment profiles, see Environment profiles overview on page 221.
Before you can deploy a virtual image, you must create an environment profile
by following the procedure described in Creating an environment profile on
page 223. When you create the environment profile, define the cloud group to
which you want to deploy the virtual image.
5. Create a virtual system pattern.
A virtual system pattern is one or more virtual images and applications from
the SmartCloud Orchestrator catalog that implements a deployment topology.
For more information about virtual system pattern, see Working with virtual
system patterns on page 511.
Before you can deploy a virtual image, you must create a virtual system pattern
by following the procedure described in Creating a virtual system pattern on
page 519. When you create the virtual system pattern, add the virtual image
that you want to deploy as a part of the virtual system pattern.
6. Deploy a virtual system pattern.
You can deploy a virtual image by deploying the virtual system pattern that
contains it. To deploy a virtual system pattern, follow the procedure described
in Deploying a virtual system pattern on page 547. When you deploy a
virtual system pattern, specify to use the environment profile that you created.
What to do next
You can create custom orchestration workflows in the Business Process Manager
user interface and run them in your SmartCloud Orchestrator environment. For
more information, see Chapter 7, Managing orchestration workflows, on page
763.
Chapter 3. Getting started 133
134 IBM SmartCloud Orchestrator 2.3: User's Guide
Chapter 4. Administering
After you have installed SmartCloud Orchestrator, you can start your environment,
configure optional settings, define users and projects, build your cloud
environment by defining cloud resources, and populate the catalog as described in
the following sections.
Starting or stopping SmartCloud Orchestrator
This topic describes how to start or stop SmartCloud Orchestrator.
Before you begin
Before running the SCOrchestrator.py script, you must review the Managing
services with SCOrchestrator.py topic and ensure that the assumptions that are
described are satisfied.
About this task
You can run the SCOrchestrator.py script to start, stop and view the status of the
SmartCloud Orchestrator components.
For information about running the SCOrchestrator.py script, see Running the
SCOrchestrator.py script on page 138.
If you are using System Automation Application Manager, SmartCloud
Orchestrator must only be started and stopped via System Automation Application
Manager and must not be managed by the SCOrchestrator.py script For more
information, see Using System Automation Application Manager on page 107.
Accessing SmartCloud Orchestrator user interfaces
SmartCloud Orchestrator provides several user interfaces to access the various
components.
To correctly display the SmartCloud Orchestrator user interface, use one of the
following browsers:
v Internet Explorer versions 9, 10, and 11
v Firefox Extended Support Release 24
v Google Chrome versions 29, 30, and 31
To access the main SmartCloud Orchestrator user interface, log in to the following
URL:
https://central-server-3_fqdn
where central-server-3_fqdn is the fully-qualified domain name of Central Server
3.
Note: Do not use the IP address to access the SmartCloud Orchestrator user
interface.
Copyright IBM Corp. 2013, 2014 135
When logging in to the SmartCloud Orchestrator user interface, you can specify a
scope for the user by entering the domain to which the user belongs. If you do not
specify any domain, the user is authenticated to the Default domain. By default,
the user is also authenticated to the scope of the primary project that you specified
when you created the user in order to access cloud resources. After logging in, you
can change the project scope by selecting a new project from the project list in the
top banner of the user interface. For more information about users, projects, and
domains, see Managing users, projects, and domains on page 149.
Note: In SmartCloud Orchestrator, the following limitations apply:
v You cannot log in by using a user name that contains a : (colon) character.
v You cannot log in by using a password that contains a @ character.
v You cannot log in if the primary project to which your user is assigned is
disabled.
v You cannot log in to the same SmartCloud Orchestrator user interface with more
than one browser session on the same machine. If you need to log in to the
SmartCloud Orchestrator user interface with two browser sessions on the same
machine, use different browsers for the two sessions as, for example, an Internet
Explorer browser and a Firefox browser.
To access the Virtual Image Library user interface, log in to the following URL:
https://central-server-2:9443/ImageLibraryUI
where central-server-2 is the host name or the IP address of the machine where
Virtual Image Library has been installed. The default user name and password are
admin/passw0rd.
You can also launch the Virtual Image Library user interface by clicking Images &
Patterns > Virtual Image Library in the menu bar of the SmartCloud Orchestrator
user interface.
To access the Image Construction and Composition Tool user interface, log in to
the following URL:
https://ICCT_server/icn/ui
where ICCT_server is the host name or the IP address of the machine where the
Image Construction and Composition Tool has been installed. The default user
name and password are iconadmin/object00.
To access IBM Business Process Manager user interface:
1. Open SmartCloud Orchestrator user interface.
2. Click Administration > Process Center.
You might also use Business Process Manager Process Designer user interface, but
this application must be installed locally on your computer. The download link for
the installation package is available in Business Process Manager Process Center.
To view the SmartCloud Orchestrator user interface in another language, set the
language option in your browser. Select the language that you want as the first one
in the list, clear the browser cache, and refresh your browser view. For some
browser and operating system combinations, you might need to change the
regional settings of your operating system to the locale and language of your
choice.
136 IBM SmartCloud Orchestrator 2.3: User's Guide
Managing the services
The following topics describe how to manage the SmartCloud Orchestrator
services.
Managing services with SCOrchestrator.py
The SCOrchestrator.py Python script can start, stop and provide information about
the status of SmartCloud Orchestrator services.
SmartCloud Orchestrator contains of a number of services and modules, which
have to be online or running before the product can be used. The modules and
services are spread on several virtual appliances. Because some of these modules
and services require to be started and stopped in sequence, SmartCloud
Orchestrator is delivered with the SCOrchestrator.py script that you can use it to
start, stop and monitor the status of a single component or to start and stop all the
SmartCloud Orchestrator services with one command. If you use the
SCOrchestrator.py script to start or stop all the SmartCloud Orchestrator services,
the services are started or stopped in the correct sequence and all the dependencies
are resolved.
If you use System Automation Application Manager to manage the SmartCloud
Orchestrator services, do not use the SCOrchestrator.py script. For more
information, see Using System Automation Application Manager on page 107.
The SCOrchestrator.py script uses two XML files to obtain the information about
the environment and the components:
v SCOEnvironment.xml
v SCOComponents.xml
v SCOComponents_work.xml
The XML files define the names and the start/stop priority of the SmartCloud
Orchestrator services.
The following tasks are performed when you run SCOrchestrator.py:
1. The script reads the SCOEnvironment.xml and the SCOComponents.xml files.
2. The script obtains the computeNodes of the system and enhances the
SCOEnvironment_work.xml file with the computeNodes.
3. The script obtains the parameters and options and analyzes them for the
actions to take.
4. For start, stop, and status sequences, scripts are copied to the specific systems
and executed on the remote systems.
5. The scripts are cleaned up from the /tmp directory of the systems.
The script files which are executed on the systems can be found in the same
directory as the SCOrchestrator.py script.
You can start or stop certain components if you know the exact name of the
component or hostname. You can start or stop all modules of a specific virtual
machine by using the hostname of the machine. As a result, all components of that
machine are started or stopped.
Note: Because some SmartCloud Orchestrator services must be started in a given
sequence to work correctly, it is not recommended to start or stop any single
services but only to start or stop the whole SmartCloud Orchestrator stack. Only
Chapter 4. Administering 137
experienced administrators who are aware of the dependencies between the
SmartCloud Orchestrator services can use the SCOrchestrator.py script to start or
stop single services.
Assumptions for running the SCOrchestrator.py script
v The script is executed as root on the Central Server 1.
v Components of additional compute nodes are hardcoded.
v No Windows support on management systems.
Running the SCOrchestrator.py script
You can run the SCOrchestrator.py script to start, stop and view the status of the
SmartCloud Orchestrator components.
Procedure
1. As root, navigate to /iaas/scorchestrator on the Central Server 1.
2. Run the SCOrchestrator.py script with the following options:
v To start the whole product, run ./SCOrchestrator.py --start.
v To stop the whole product, run ./SCOrchestrator.py --stop.
v To view the status of components, run ./SCOrchestrator.py --status.
v To view help for this script, run ./SCOrchestrator.py --help. The following
help is displayed:
Usage:SCOrchestrator.py [options]
Options:
-h, --help show this help message and exit
-s, --start start SC Orchestrator with default parameters in
default sequence
--halt, --shutdown, --stop
stops SC Orchestrator in default sequence
--status status of components of SC Orchestrator
-c SCOComponents.xml, --componentfile=SCOComponents.xml
defines the input properties filename defaultname is
SCOComponents.xml
-e SCOEnvironment.xml, --environmentfile=SCOEnvironment.xml
defines the environment filename defaultname is
SCOEnvironment.xml
-n SYSTEMSLIST, --hostnames=SYSTEMSLIST
list of hostnames to start/stop format
hostname1,hostname2,hostname3,...
-p COMPONENTSLIST, --components=COMPONENTSLIST
list of components to start/stop format
component1,component2,component3,...
--version show PDCollector version and exit
Running the SCOrchestrator.py script with non-root user
The following commands are all run as root on the server indicated.
Procedure
1. Create a new user ssh for all the Central Servers and Region Servers:
a. On each of the Central Servers and Region Servers:
Create a new user <yourmechid> and set the password:
useradd -m <yourmechid>
passwd <yourmechid> #enter at the prompt <yourmechpwd>
Create an .ssh directory and set file permissions:
su - <yourmechid> -c "mkdir .ssh; chmod 700 .ssh"
138 IBM SmartCloud Orchestrator 2.3: User's Guide
b. On Central Server 1:
Generate the ssh keys for <yourmechid> and copy it to all SmartCloud
Orchestrator servers:
su - <yourmechid> -c "ssh-keygen -q -t rsa -N -f ~/.ssh/id_rsa"
Here $i stands for the IP address of each SmartCloud Orchestrator server:
[root@cs-1] su <yourmechid>
[yourmechid@cs-1] scp ~/.ssh/id_rsa.pub $i:~/.ssh/authorized_keys
Note: It is important in the command above that you accept the server key
and the password required is of <yourmechid>.
c. Verify that <yourmechid> on Central Server 1 can ssh to all the SmartCloud
Orchestrator servers without interruption:
su - <yourmechid> -c "ssh <yourmechid>@$SCO_server_ip"
2. Copy the /iaas/scorchestrator and change the directory permission:
On Central Server 1, copy the directory /iaas/scorchestrator to
/home/<yourmechid>:
cp -rf /iaas/scorchestrator /home/<yourmechid>
Change the owner of /home/<yourmechid>:
chown -R <yourmechid>:<yourmechidgroup> /home/<yourmechid>/
3. On each of the SmartCloud Orchestrator servers, add the user <yourmechid> in
the sudo list:
a. Create a sudoer file named <yourmechid> and place it in /etc/sudoers.d.
The content of the file <yourmechid> is like what follows:
Note: Replace <yourmechid> with your new user name.
# sudoers additional file for /etc/sudoers.d/
# IMPORTANT: This file must have no ~ or . in its name and file permissions must be set to 440!!!
# this file is for the SAAM mech-ID to call the SCO control scripts
Defaults:<yourmechid> !requiretty
# scripts found in control script directory
# adapt the directory names to the mech id!
Cmnd_Alias SACTRL = /tmp/*.sh
# allow for
<yourmechid> ALL = (root) NOPASSWD: SACTRL
b. Change the sudoer file permission:
chmod 440 <yourmechid>
4. On Central Server 1, modify the file /home/<yourmechid>/scorchestrator/
SCOrchestrator.py:
sed -i "s/\.\//sudo \.\//g" /home/<yourmechid>/scorchestrator/SCOrchestrator.py
sed -i -e s/^SSH_USER.*/SSH_USER = "<yourmechid&gt>"/g/home/
<yourmechid>/scorchestrator/SCOrchestrator.py
5. Run SCOrchestrator.py:
Move to the path /home/<yourmechid>/scorchestrator and run
SCOrchestrator.py with user <yourmechid>:
[root@cs-1] cd /home/<yourmechid>/scorchestrator
[root@CS-1 scorchestrator]# su <yourmechid>
[yourmechid@CS-1 scorchestrator2]$ ./SCOrchestrator.py
For the usage of SCOrchestrator.py, refer to Running the SCOrchestrator.py
script on page 138.
Chapter 4. Administering 139
Example SCOComponents.xml
This topic provides an example of an SCOComponents.xml file that is used by
SCOrchestrator.py.
<SCOComponents>
<component name="db2" scriptName="db2ctrl.sh" workdir="/tmp"
startPrio="10" stopPrio="290"/>
<component name="qpidd" scriptName="qpiddctrl.sh" workdir="/tmp"
startPrio="30" stopPrio="270"/>
<component name="sce" scriptName="scectrl.sh" workdir="/tmp"
startPrio="40" stopPrio="260"/>
<component name="openstack-keystone" openstackService="true"
scriptName="openstack-servicectrl.sh" workdir="/tmp"
startPrio="70" stopPrio="230"/>
<component name="openstack-cinder-api" openstackService="true"
scriptName="openstack-servicectrl.sh" workdir="/tmp"
startPrio="80" stopPrio="220"/>
<component name="openstack-cinder-scheduler" openstackService="true"
scriptName="openstack-servicectrl.sh" workdir="/tmp"
startPrio="90" stopPrio="210"/>
<component name="openstack-cinder-volume" openstackService="true"
scriptName="openstack-servicectrl.sh" workdir="/tmp"
startPrio="100" stopPrio="200"/>
<component name="openstack-glance-api" openstackService="true"
scriptName="openstack-servicectrl.sh" workdir="/tmp"
startPrio="110" stopPrio="190"/>
<component name="openstack-glance-registry" openstackService="true"
scriptName="openstack-servicectrl.sh" workdir="/tmp"
startPrio="120" stopPrio="180"/>
<component name="openstack-nova-api" openstackService="true"
scriptName="openstack-servicectrl.sh" workdir="/tmp"
startPrio="130" stopPrio="170"/>
<component name="openstack-nova-cert" openstackService="true"
scriptName="openstack-servicectrl.sh" workdir="/tmp"
startPrio="140" stopPrio="160"/>
<component name="openstack-nova-conductor" openstackService="true"
scriptName="openstack-servicectrl.sh" workdir="/tmp"
startPrio="150" stopPrio="150"/>
<component name="openstack-nova-cells" openstackService="true"
scriptName="openstack-servicectrl.sh" workdir="/tmp"
startPrio="160" stopPrio="140"/>
<component name="openstack-smartcloud" openstackService="true"
scriptName="openstack-servicectrl.sh" workdir="/tmp"
startPrio="170" stopPrio="130"/>
<component name="openstack-nova-metadata-api" openstackService="true"
scriptName="openstack-servicectrl.sh" workdir="/tmp"
startPrio="180" stopPrio="120"/>
<component name="openstack-nova-network" openstackService="true"
scriptName="openstack-servicectrl.sh" workdir="/tmp"
startPrio="190" stopPrio="110"/>
<component name="openstack-nova-scheduler" openstackService="true"
scriptName="openstack-servicectrl.sh" workdir="/tmp"
startPrio="200" stopPrio="100"/>
<component name="openstack-nova-consoleauth" openstackService="true"
scriptName="openstack-servicectrl.sh" workdir="/tmp"
startPrio="210" stopPrio="90"/>
<component name="openstack-nova-novncproxy" openstackService="true"
scriptName="openstack-servicectrl.sh" workdir="/tmp"
startPrio="220" stopPrio="80"/>
<component name="openstack-nova-compute" openstackService="true"
scriptName="openstack-servicectrl.sh" workdir="/tmp"
startPrio="230" stopPrio="70"/>
<component name="openstack-iaasgateway" openstackService="true"
scriptName="openstack-servicectrl.sh" workdir="/tmp"
startPrio="240" stopPrio="60"/>
<component name="vil" scriptName="vilctrl.sh" workdir="/tmp"
startPrio="250" stopPrio="50"/>
140 IBM SmartCloud Orchestrator 2.3: User's Guide
<component name="vilProxy" scriptName="vilProxyCtrl.sh" workdir="/tmp"
startPrio="215" stopPrio="55"/>
<component name="iwd" scriptName="iwdctrl.sh" workdir="/tmp"
startPrio="260" stopPrio="40"/>
<component name="swi" scriptName="swictrl.sh" workdir="/tmp"
startPrio="270" stopPrio="30"/>
<component name="pcg" scriptName="pcgctrl.sh" workdir="/tmp"
startPrio="280" stopPrio="20"/>
<component name="bpm-dmgr"
scriptName="bpm-dmgrctrl.sh" workdir="/tmp"
startPrio="290" stopPrio="10"/>
<component name="bpm-node"
scriptName="bpm-nodectrl.sh" workdir="/tmp"
startPrio="291" stopPrio="9"/>
<component name="bpm-server"
scriptName="bpm-serverctrl.sh" workdir="/tmp"
startPrio="292" stopPrio="8"/>
</SCOComponents>
Example SCOEnvironment.xml
This topic provides an example of SCOEnvironment.xml file that is used by
SCOrchestrator.py.
This file is automatically generated by the installation procedure when the central
SmartCloud Orchestrator servers are installed. Afterwards, the installation
procedure automatically updates the file if a region server is installed. You must
manually modify the file only if a region server is removed.
<SCOEnvironment>
<host hostname="central-server-1">
<component name="db2"/>
</host>
<host hostname="central-server-2">
<component name="qpidd"/>
<component name="openstack-keystone"/>
<component name="openstack-iaasgateway"/>
<component name="pcg"/>
<component name="vil"/>
</host>
<host hostname="central-server-3">
<component name="iwd"/>
<component name="swi"/>
</host>
<host hostname="central-server-4">
<component name="bpm-dmgr"/>
<component name="bpm-node"/>
<component name="bpm-server"/>
</host>
</SCOEnvironment>
Backing up and restoring the services
This topic describes how to backup and restore the core services.
About this task
To backup and restore Workload Deployer and Virtual Image Library, as these
services are installed on virtual machines, backup and restore the related virtual
machine.
To backup and restore Business Process Management, refer to the documentation at
http://pic.dhe.ibm.com/infocenter/dmndhelp/v8r0m1/index.jsp?topic=
%2Fcom.ibm.wbpm.mon.trbl.doc%2Ftopics%2Fcadm_recovery_scenarios.html.
Chapter 4. Administering 141
To backup and restore OpenStack, refer to the OpenStack documentation.
Managing settings
You can configure product settings before building a cloud infrastructure.
Before you begin
You must be assigned the admin role to manage the product settings.
Managing email delivery
The mail delivery function is used to send event notifications and to send the new
password to locally authenticated users when the product administrator changes it.
Before you begin
You must be assigned the admin role to perform these steps.
About this task
The mail delivery function is used to automatically notify the owner of a virtual
system instance, a virtual system pattern, or a virtual image about the following
events:
v Virtual system instance is created.
v Virtual system instance has successfully started.
v Virtual system instance failed to start successfully.
v Virtual system instance is going to be removed due to expired reservation.
v Virtual system pattern is created.
v Virtual system pattern is going to be removed due to expired reservation.
v Virtual image is exported.
v Virtual image is imported.
A Simple Mail Transfer Protocol (SMTP) server must be configured for use with
SmartCloud Orchestrator.
Procedure
To configure the mail delivery function, use either the graphical user interface or
the command-line interface as described in the following procedures:
v Configuring email delivery with the user interface on page 143
v Mail delivery command-line interface reference on page 841
142 IBM SmartCloud Orchestrator 2.3: User's Guide
Configuring email delivery with the user interface
Configure the mail delivery function to send event notifications and password
change notices.
Before you begin
You must be assigned the admin role to perform these steps.
About this task
To configure the mail delivery function, specify the required Simple Mail Transfer
Protocol (SMTP) server to be used for SmartCloud Orchestrator by performing the
following steps:
Procedure
1. Click Administration > Settings.
2. Expand Mail Delivery.
3. Add an SMTP server. Provide the IP address or host name for the SMTP server
to be used for SmartCloud Orchestrator.
4. Add a reply-to address. The email address for the administrator should be used
for this field.
Results
The mail deliver function has been configured to send event notifications and
password change notices.
Virtual Image Library configuration files
You can optionally edit the configuration files to change the parameters to access
the Virtual Image Library user interface from the SmartCloud Orchestrator user
interface with the single sign-on (SSO).
During the SmartCloud Orchestrator installation, the parameters to access the
Virtual Image Library user interface are configured automatically. If you change the
Virtual Image Library server URL, you must change the following configuration
files on the machine where the Workload Deployer component is installed:
v <install-path>/purescale.app/config/iwdvil.config
v /opt/ibm/ccs/scui/etc/config.json
To change the configuration files, perform the following steps:
1. Change the parameters in the iwdvil.config file as described in the following
example:
#example https://<hostname>:<port>/ImageLibrary/ImageLibrary
/config/vil/url = "https://tcloudvm01.rome.ibm.com:9443
/ImageLibrary/ImageLibrary"
#example https://<host_name>:<port>/ImageLibraryUI
/config/vil/ui_url = "https://tcloudvm01.rome.ibm.com:9443
/ImageLibraryUI"
/config/vil/keystorePassword = "<xor>KD4sPjsyNjE="
/config/vil/userName = "adminuser"
/config/vil/password = "passw0rd"
/config/vil/url
Defines the URL for the Virtual Image Library REST operations.
Chapter 4. Administering 143
/config/vil/ui_url
Defines the URL for the Virtual Image Library user interface.
/config/vil/keystorePassword
Defines the encoded password.
Note: If you want to create a new keystore you need to run the
command (in Virtual Image Library):
./createKeys.sh -password password -overwrite yes -was <WAS_INSTALL_DIR>
The script createKeys.sh creates a keystore file in the current directory
named iwdvil.p12, which contains the public and private key pair.
Copy the file to the following directories:
v Image Library server directory in WebSphere
v SmartCloud Orchestrator configuration directory
<install-path>/purescale.app/config
After you have created a new keystore, you must encrypt the password
using the sMash command line. To encrypt the password, go to
<install-path>/purescale.app directory and run the following
command:
./zero encode <password>
For example, if you run the following command:
./zero encode mypassw0rd
the following output is displayed:
CWPZC2029I: Input
mypassw0rd
CWPZC2030I: Result
<xor>MiYvPiwsKG8tOw==
Then you must update the /config/vil/keystorePassword parameter.
/config/vil/userName
/config/vil/password
Define the credentials of the Virtual Image Library administrator.
Note: When you change the password of the administrator user ID,
you must also update the /config/vil/password parameter. This
parameter can be encrypted. To encrypt the new password use the zero
encode command.
2. Change the vil statement in the config.json file as described in the following
example:
"vil":
{
"provider": "vil",
"service_url": ""https://tcloudvm01.rome.ibm.com:9443"
},
where service_url defines the URL for the Virtual Image Library server.
144 IBM SmartCloud Orchestrator 2.3: User's Guide
Configuring the scalable web infrastructure server
You can optionally change the parameters to communicate to the scalable web
infrastructure server in your SmartCloud Orchestrator environment.
During the SmartCloud Orchestrator installation, the parameters related to the
scalable web infrastructure server are configured automatically.
Communicating to the scalable web infrastructure server
To change the parameters to communicate to the scalable web infrastructure server,
modify the following values in the WD_inst_dir/config/zero.config file where
WD_inst_dir is the directory where the Workload Deployer component is installed:
/config/swi/protocol = server_protocol
/config/swi/hostname = server_hostname
/config/swi/port = server_port
where
server_protocol
is the protocol to communicate to the scalable web infrastructure server. By
default, it is https.
server_hostname
is the host name of the scalable web infrastructure server.
server_port
is the port used to communicate to the scalable web infrastructure server.
By default, it is 443.
Defining a Yum repository
If you want to install an RPM package on a deployed virtual machine the first time
that the virtual machine starts, you must define a Yum repository that is accessible
from the scalable web infrastructure server and from the deployed virtual machine.
To define the Yum repository, specify the following parameters in the
/opt/ibm/ccs/scpui/etc/config.json file on the scalable web infrastructure server:
"package_libraries" : [
{
"provider": "yum",
"http_service_url": "http_service_url"
}
]
where http_service_url is the HTTP URL of the directory configured as Yum
repository (that is the directory that contains the repodata directory). For example:
"http_service_url": "http://<ip_address>/rhel/6.3/x86_64"
Chapter 4. Administering 145
Configuring session timeout value
You can optionally increase the default timeout value for the SmartCloud
Orchestrator web interface session.
About this task
The default timeout value for a web interface session is 30 minutes.
To increase the session timeout value, change the following parameter in the
/opt/ibm/rainmaker/purescale.app/private/expanded/ibm/rainmaker.rest-
4.0.0.1/config/timeouts-default.config file on the machine where the Workload
Deployer component is installed:
/config/userZone/idleTimeout = new_idleTimeout_value_in_minutes
/config/security/token/simple += {
"tokenExpiration": new_tokenExpiration_value_in_minutes
}
where
new_idleTimeout_value_in_minutes
Is the session expiration timeout value that you want to change.
new_tokenExpiration_value_in_minutes
Is the token expiration timeout value that you want to change.
Configuring timeout value for Ajax calls
You might need to increase this timeout value to display in the expandable section
all the virtual machines that are available for a selected hypervisor or a virtual
system instance.
About this task
The timeout value for Ajax calls is set in the rainmaker.ui/config/zero.config file
through the parameter /config/rainmaker/ajax/timeout and the default value is
60 seconds.
To increase the timeout value, override the default value by adding the following
line in the purescale.app/config/overrides.config file on the machine where the
Workload Deployer component is installed:
/config/rainmaker/ajax/timeout = new_value_in_seconds
where new_value_in_seconds is the new timeout value.
Configuring OpenStack synchronization
You can optionally change the default synchronization interval with the OpenStack
environment.
About this task
In SmartCloud Orchestrator, the lists of cloud groups, hypervisors, and IP groups
are automatically imported from the OpenStack environment. This information is
periodically refreshed so that each change you make in the OpenStack
environment is automatically applied also in the SmartCloud Orchestrator
environment.
146 IBM SmartCloud Orchestrator 2.3: User's Guide
To change the synchronization time interval, edit the /opt/ibm/rainmaker/
purescale.app/private/expanded/ibm/scp.ui-1.0.0/config/openstack.config file
(on the Central Server 3) and change the following statement:
/config/openstack = {
...
"synchronization": {
"initial_delay_sec": 60,
"interval_sec": 600,
"hypervisor_discovery_timeout_sec": 600,
"hypervisor_discovery_check_interval_sec": 10 }
}
where
initial_delay
Specifies the time interval (in seconds) between the start of the Workload
Deployer server and the first synchronization with the OpenStack
environment. It is optional. The default value is 60.
interval_sec
Specifies the time interval (in seconds) between the synchronizations with
the OpenStack environment. The default value is 600.
hypervisor_discovery_timeout_sec
Specifies the timeout after which the operation will be reported as failed.
hypervisor_discovery_check_interval_sec
Specifies the time interval for the hypervisor discovery operation. By
default, Workload Deployer will check every 10 seconds for a maximum of
10 minutes. If this timeout is reached, you must check the hypervisor
status in the Hypervisor panel. The message should be meaningful and
after correcting the problem (like network issue), rerunning the Discovery
from the UI should help. Of course exceptions will be logged in traces for
Workload Deployer as well.
To change the server operation settings , edit the /opt/ibm/rainmaker/
purescale.app/private/expanded/ibm/scp.ui-1.0.0/config/openstack.config file
(on the Central Server 3) and change the following statement:
/config/openstack = {
.....
"openstack": { "server_operation_timeout_sec": 3600,
"server_operation_check_interval_sec": 60,
"image_service": "vil" }
....
}
where:
server_operation_timeout_sec
Specifies the timeout for each OpenStack operation (for example, the
deployment of a virtual machine). The default is 3600 seconds (1 hour).
server_operation_check_interval_sec
Specifies the interval for the OpenStack operation status check. The default
is 10 seconds.
image_service
Specifies the image service to be used, glance or VIL. Do not change this
parameter.
Chapter 4. Administering 147
Configuring OpenStack connection
You can optionally change the parameters to communicate to OpenStack in your
SmartCloud Orchestrator environment.
About this task
During the SmartCloud Orchestrator installation, the parameters related to the
OpenStack communication are configured automatically. If you need to change
these parameters for technical reasons related to your OpenStack environment,
change the following configuration files on the Central Server 3:
/opt/ibm/maestro/maestro/usr/servers/kernelservices/overrides.cfg
/opt/ibm/maestro/usr/servers/storehouse/overrides.cfg
Change the following parameters:
openstack.iaas.service_url=http://iaas_gateway_hostname:port
openstack.iaas.provider=iaas_gateway
openstack.iaas.admin_user=admin_user
openstack.iaas.admin_tenant=primary_admin_project
openstack.auth.simple_token_secret=simple_token_secret
/opt/ibm/rainmaker/purescale.app/private/expanded/ibm/scp.ui-1.0.0/config/
openstack.config
Change the parameters in the following statement:
/config/openstack = {
"iaas": {
"provider": "iaas_gateway",
"service_url": "http://iaas_gateway_hostname:port",
"admin_user": "admin_user",
"admin_tenant": "primary_admin_project",
"simple_token_secret": "simple_token_secret"
...
}
where
iaas_gateway_hostname:port
Specifies the host name (or the IP address) and the port number of the
machine where the IAAS gateway component is installed.
admin_user
Specifies a user with admin role in the OpenStack environment.
default_admin_project
Specifies the primary project of the user specified in admin_user.
simple_token_secret
Specifies the simple token to be used to communicate.
Note: Be sure that you use the same parameter values in all the configuration files.
148 IBM SmartCloud Orchestrator 2.3: User's Guide
Configuring OpenStack to support thin provisioning
This topic describes how you can configure OpenStack to support thin
provisioning.
About this task
For VMware regions, you can enable thin provisioning for a specific flavor using
this command:
nova flavor-key <flavor name> set ibm-smartcloud:VMWareUseLinkedClones=true
Configuring memory and CPU overcommitment
SmartCloud Orchestrator supports memory and CPU overcommitment for
VMware and KVM regions.
About this task
In the /etc/nova/nova.conf file on the region server, use the cpu_allocation_ratio
configuration option to specify the virtual CPU to physical CPU allocation ratio,
and use the ram_allocation_ratio configuration option to specify the virtual RAM
to physical RAM allocation ratio.
After you change the /etc/nova/nova.conf file, you must restart the nova services.
Managing users, projects, and domains
You can manage users and the level of access that each user has in the SmartCloud
Orchestrator environment. You can assign which roles a user has on a specific
project, as well as the primary project for a user. A user can have different roles on
different projects. Both users and projects belong to a domain.
About this task
The OpenStack Compute system is designed to be used by many different
cloud-computing consumers or customers, basically projects on a shared system,
using role-based access assignments. Roles control the actions that a user is
allowed to perform. For example, you can define that a user cannot allocate a
public IP without the admin role. A user's access to particular images is limited by
project, but the username and password are assigned per user. Key pairs granting
access to an instance are enabled per user, but quotas to control resource
consumption across available hardware resources are per project.
A project is an isolated resource container forming the principal organizational
structure within the OpenStack environment. It consists of a separate VLAN,
volumes, instances, images, keys, and users. For more information about
OpenStack users and projects, see the OpenStack documentation.
For projects, quota controls are available to limit the following resources:
v Number of volumes that can be created
v Total size of all volumes within a project as measured in GB
v Number of instances that can be launched
v Number of processor cores that can be allocated
v Publicly accessible IP addresses
Chapter 4. Administering 149
For more information about the OpenStack commands to be used to manage quota
values in the projects, see Modifying project quotas on page 86.
When you create users and projects in SmartCloud Orchestrator, they are actually
being created in the underlying OpenStack environment. The roles that are defined
in the OpenStack environment are used in SmartCloud Orchestrator as described
in User roles in SmartCloud Orchestrator on page 151.
In SmartCloud Orchestrator, the OpenStack concept of domain is also supported. A
domain represents a customer (that is, for example an organization or a division)
and the related resources as a segregated entity. Only users within that domain
have access to these resources. In this way service providers can use the same
SmartCloud Orchestrator infrastructure to serve multiple customers. A domain can
also be seen as a sort of container for projects and users. A user or a project can
belong only to one domain. Domain administrators are authorized to create,
update and delete resources related to the domain.
Important: SmartCloud Orchestrator does not support the definition of same
resource names in multiple domains at the same time (for example, a project with
same name exists in different domains). The cloud administrator must ensure that
there are no duplicated user names, project names, and domains.
When a user logs in to the SmartCloud Orchestrator user interface, the user must
specify the domain scope to which the user wants to be authenticated. In a single
domain environment or if the user does not specify a domain, the users is
authenticated to the Default domain. In addition to the domain-based
authentication, when logging in, by default, the user is authenticated to scope of
the primary project that was specified when the user was created. After successful
authentication, the user can switch the project from the project list in the top
banner of the user interface.
Important: A user always authenticates on behalf of its domain. Therefore, as a
user, you must enter the domain name at the login page of SmartCloud
Orchestrator. To login to Business Process Manager and Virtual Image Library, you
must specify the domain name as a prefix of the username wherein the delimiter
between domain name and username is a '/'. For example, a user 'user1' of domain
'domain1' must specify 'domain1/user'. If you are a user who is within the default
domain, you must authenticate only with your username. Users and projects are
shown in Business Process Manager and Virtual Image Library as users and
groups. Any user or project of custom domains are prefixed with the domain name
delimited by '/', that is, project 'p1' of domain 'domain1' appears as a group
'domain1/p1' in Business Process Manager and Virtual Image Library. To ensure
backward compatibility, users and projects of the default domain appear with its
user and project name. As the user and the project name are prefixed by their
domain name in Business Process Manager and Virtual Image Library with a '/' as
delimiter, the user name, project name, and domain name must not contain a '/'
character.
Note: In the current release of SmartCloud Orchestrator user, project and domain
names are case insensitive (in other words, if a user is created with the name
'George Windsor', then they would be able to login successfully as 'george
windsor'). However, this is likely to change in a future release, so this fact should
not be relied on.
150 IBM SmartCloud Orchestrator 2.3: User's Guide
If you are using an LDAP server to authenticate users, you can configure LDAP
authentication to allow any corporate directory details to be specified on a
domain-by-domain basis. For more information, see Configuring LDAP
authentication on page 77.
You can work with your users, projects (only to manage users), and domains with
the SmartCloud Orchestrator user interface.
Procedure
v To work with SmartCloud Orchestrator users, see Managing users on page
153.
v To work with SmartCloud Orchestrator projects, see Managing projects on
page 155.
v To work with SmartCloud Orchestrator domains, see Managing domains on
page 158.
Results
After you completed these steps, users, projects, and domains are defined to
customize the SmartCloud Orchestrator environment to your organization's
business needs.
User roles in SmartCloud Orchestrator
Protect your cloud environment by using roles to control how different users
interact with SmartCloud Orchestrator. When you assign roles to users, you
designate the types of objects (such as cloud groups) that they can access, and the
tasks that they can perform.
In SmartCloud Orchestrator the users and the projects are defined in the related
OpenStack environment. When you create a user, you must assign a role to the
user related to the project to which the user belongs. A user can have different
roles in different projects.
The authority to access a type of object might not equate with the authority to
access all instances of that object. In some cases, users can access an object instance
only if they have been granted authority by the creator of that instance. See
Object-level access control on page 152 for more information.
In SmartCloud Orchestrator, you can use the following roles:
admin Can run the following tasks in the SmartCloud Orchestrator environment:
v Assign other user roles, configure product settings, and modify resources
such as: images, patterns, shared services, environment profiles, other
catalog content, and deployed cloud content.
v Create environment profiles to group related cloud topology settings for
easy deployment of virtual system patterns. Environment profile creators
can also edit or delete any profile that they create, or to which they have
access.
v Download audit data and change auditing settings that are editable
(such as the option to delete audit data from the SmartCloud
Orchestrator after download).
Note: The admin role grants a user to have full privileges to all cloud
resources, including all projects and all domains. It is recommended that
Chapter 4. Administering 151
you assign this role only to the cloud administrators and only to users
within the Default domain and admin project.
catalogeditor
Can run the following tasks in the SmartCloud Orchestrator environment:
v Can create both virtual system patterns and virtual application patterns.
These users can also edit or delete any patterns that they create, or to
which they have access.
v Can add objects to the SmartCloud Orchestrator catalog. They can also
modify or delete any catalog content that they create, or to which they
have access.
v Can import image files but cannot register images from a region. For
more information about importing and registering images, see
Importing a virtual image to the catalog on page 289 and Registering
a virtual image on page 290.
v Can create self-service offerings, self-service categories, and orchestration
actions. They can also modify or delete any self-service offerings,
self-service categories, and orchestration actions that they create, or to
which they have access.
Member
Can view and manage the virtual system instances, patterns, and catalog
content to which they are granted access. They can deploy virtual system
patterns and virtual application patterns, but cannot add, remove, or
modify any items.
Object-level access control
SmartCloud Orchestrator implements an object-level access control framework for
some object types. Users must have specific levels of access permissions to view, or
perform tasks with, instances of those objects. For example, a user with Member
role can only deploy a particular pattern if the user belongs to a project that has
been granted access to that pattern. Even a user with the catalogeditor role cannot
modify a particular pattern unless he or she created that pattern, or belongs to a
project that has been granted access to that pattern by the creator. Object-level
access applies to the following types of objects:
v Environment profiles
v Virtual images
v Patterns
v Script packages
v Add-ons
v Virtual system instances
v Shared services instances
v Self-service offerings
v Orchestration actions
The following table depicts the object-level access definitions in SmartCloud
Orchestrator. The all or owner definition applies to both the creator of the object
instance and the users with admin role (which has complete access to every
instance of every object that is created in the product). Object creators and users
with admin role can assign the object permissions read, write or all to other
projects.
152 IBM SmartCloud Orchestrator 2.3: User's Guide
Table 14. Object level access definitions
Access level definition Description
Read You can see the object listed in the user
interface panels and are able to view the
details for this object
Write You can see the object listed in the user
interface panels and are able to view and
modify the details for this object.
All or owner You can see the object listed in the user
interface panels and are able to view and
modify the details for this object. You are
able to delete this object.
None If you are not assigned access to the object,
you cannot see the object listed in the user
interface panels. You cannot perform any
action associated with the object.
Managing users
You can manage the level of access for each individual user to SmartCloud
Orchestrator with the user interface.
Before you begin
You must be assigned the admin role to perform these steps.
About this task
In the SmartCloud Orchestrator environment, the users are defined in the related
OpenStack environment.
If you configure your OpenStack to use LDAP authentication, you can log in to
SmartCloud Orchestrator by using the LDAP users and perform the tasks that are
allowed to the role associated to the user in the related project. For more
information about configuring OpenStack to work with an LDAP server, see
Configuring LDAP authentication on page 77.
Note: If you want to define an account lockout policy, you must configure
OpenStack to work with an LDAP server and enable the policy on LDAP. You
cannot define an account lockout policy with the local Keystone authentication in
OpenStack.
You can manage OpenStack users from the SmartCloud Orchestrator user interface,
by performing the following procedure.
Note: The following procedure apply only to OpenStack users that are locally
defined, and do not apply to users eventually defined in an external LDAP server.
If you create an OpenStack user, be careful about creating a local user with the
same name as an LDAP user, because when you log in to SmartCloud
Orchestrator, the user is authenticated to the LDAP server before being
authenticated locally to OpenStack.
Chapter 4. Administering 153
Procedure
1. Open the User window by clicking Administration > Users in the menu bar.
The list of the existing users is displayed in the left pane.
2. You can perform the following tasks:
v Creating a user -
To create a user, perform the following steps:
a. Click the Add icon in the user list. The Create a new user window is
displayed.
b. Insert the credentials and a valid email address for the user.
Important: As the user and the project name are prefixed by their
domain name in Business Process Manager and Virtual Image Library
with a '/' as delimiter, the user name, project name, and domain name
must not contain a '/' character.
Important: SmartCloud Orchestrator does not support the definition of
same resource names in multiple domains at the same time. Be sure that
there are no duplicated user names.
c. In the Primary project list, select the primary project to which the user is
assigned. For more information about projects, see Managing users,
projects, and domains on page 149.
d. In the Role in primary project list, select the user role in the specified
project. For more information about roles, see User roles in SmartCloud
Orchestrator on page 151.
e. If you do not want to allow the user to log in or to perform any
operation in SmartCloud Orchestrator select Disabled in the State list.
f. Select a domain for the user. Make sure that you already enabled the
domain that you want to use.
Note: After you created the user, you cannot change the domain to which
the user belongs.
g. Click Create. The user is created in the OpenStack environment and it is
available in SmartCloud Orchestrator.
Note: To allow the new user to work with the Process Designer, you
must define the user in the Business Process Manager environment. To
define a user in Business Process Manager, open the Process Center user
interface by clicking Administration > Process Center and follow the
procedure described in Adding users and groups section in the IBM
Business Process Manager information center.
v Editing a user
To change the properties of a user, perform the following steps:
a. Select the user in the user list. The user details are displayed in the right
pane.
b. Click the Edit icon.
c. You can change the following properties:
Email address
Password
Primary project
State
154 IBM SmartCloud Orchestrator 2.3: User's Guide
Note: Only users with admin role can change the user password.
d. Click the Save icon to apply your changes.
v Enabling or disabling a user
To enable or disable a user, select the user in the list and click the Enable or
Disable icon.
v Deleting a user
To delete a user that you do not need anymore, perform the following steps:
a. Select the user in the user list. The user details are displayed in the right
pane.
b. Click the Delete icon. A confirmation window is displayed.
c. Click OK to delete the user. The user is deleted in the OpenStack
environment and it is not more available in SmartCloud Orchestrator.
Results
You managed the users in the SmartCloud Orchestrator environment.
Note: You can also manage users directly from the OpenStack interface. The
changes that you make from the OpenStack interface are automatically displayed
in the SmartCloud Orchestrator environment when you open the Users window. To
refresh the user list in the Users window, click the Refresh icon.
For more information about OpenStack, see Overview of OpenStack on page 8.
Managing projects
You can manage the level of access for each project to SmartCloud Orchestrator
with the user interface.
Before you begin
You must be assigned the admin role to perform these steps.
About this task
In the SmartCloud Orchestrator environment, the projects are defined in the related
OpenStack environment. For more information about projects, see Managing
users, projects, and domains on page 149.
A built-in project named Everyone is already defined in the SmartCloud
Orchestrator environment. This project contains all the existing users and it cannot
be deleted. You must not create a project named Everyone in your OpenStack
environment.
Note: The name of the built-in project depends on the server locale that was
defined when you installed SmartCloud Orchestrator.
To manage projects from the SmartCloud Orchestrator user interface, perform the
following steps:
Procedure
1. Open the Project window by clicking Administration > Projects in the menu
bar. The list of the existing projects is displayed in the left pane. To show the
details of a project in the right pane, select the project in the list.
Chapter 4. Administering 155
2. You can perform the following tasks:
v Creating a project -
To create a project, perform the following steps:
a. Click the Add icon in the project list. The Create a new project window is
displayed.
b. Insert a name for the project.
Important: SmartCloud Orchestrator does not support the definition of
same resource names in multiple domains at the same time. Be sure that
there are no duplicated project names.
Important: As the user and the project name are prefixed by their
domain name in Business Process Manager and Virtual Image Library
with a '/' as delimiter, the user name, project name, and domain name
must not contain a '/' character.
c. Optionally insert a description for the project.
d. If you do not want to allow the project members to perform any
operation in SmartCloud Orchestrator, select Disabled in the State list.
Note: If a project is disabled, the users that are assigned to the project as
their primary project cannot log in to the SmartCloud Orchestrator user
interface.
e. Select a domain for the project. Make sure that you already enabled the
domain that you want to use.
Note: After you created the project, you cannot change the domain to
which the project belongs.
f. Click Create. The project is created in the OpenStack environment and it
is available in SmartCloud Orchestrator.
After you created a new project, perform the following steps to work with
this project in your Virtual Image Library environment:
a. Click Images & Patterns > Virtual Image Library to open the Virtual
Image Library user interface.
b. Click Images in the toolbar.
c. In the Images tab, click Actions > Synchronize User and Group List.
Note: Before you perform this action, be sure that there are no pending
tasks because the Virtual Image Library component is restarted when you
synchronize the user and group list.
v Editing a project
To change the properties of a project, perform the following steps:
a. Select the project in the project list. The project details are displayed in
the right pane.
b. Click the Edit icon.
c. You can change the following properties:
Name
Description
State
Note: Even if you change the project name, the old project name is
displayed in the Access granted to list of the objects that are already
156 IBM SmartCloud Orchestrator 2.3: User's Guide
accessible by the project. Anyway, the access to these objects is still
granted to the users that belong to the project.
d. To add a user to the project, click the Members field and select a user in
the list. The user is added to the project with a default role. You can also
remove a user from the project by clicking remove on the right of the
related user entry.
Note: If you remove your user from a project and your user does not
belong to any other project, you cannot log in to the user interface any
more. Ask to a user with admin role to readd your user to a project. As
an alternative, ask to the OpenStack Keystone administrator to add your
user to a project by running the keystone user-role-add command.
e. To add a role to a user, click the field on the right of the user name and
select a role in the list. You can also remove a role of a user by clicking x
on the right of the role name. A user must have at least one role in the
project. For more information about roles, see User roles in SmartCloud
Orchestrator on page 151.
f. Click the Save icon to apply your changes.
v Enabling or disabling a project
To enable or disable a project, select the project in the list and click the
Enable or Disable icon.
Note: If you disable a project, the users that are assigned to the project as
their primary project cannot log in to the SmartCloud Orchestrator user
interface.
v Deleting a project
To delete a project that you do not need anymore, perform the following
steps:
a. Select the project in the project list. The project details are displayed in
the right pane.
b. Click the Delete icon. A confirmation window is displayed.
c. Click OK to delete the project. The project is deleted in the OpenStack
environment and it is not more available in SmartCloud Orchestrator.
Note: When you delete a project, the users that belong to the project are not
deleted.
Results
You managed the projects in the SmartCloud Orchestrator environment.
Note: You can also manage projects directly in OpenStack. The changes that you
make in the OpenStack environment are automatically displayed in the
SmartCloud Orchestrator environment when you open the Projects window. To
refresh the project list in the Projects window, click the Refresh icon.
To change quota values that are related to the projects, you must use the
OpenStack interface. For more information, see Modifying project quotas on
page 86.
Chapter 4. Administering 157
What to do next
You can grant the access to SmartCloud Orchestrator objects to the users that
belong to a project by adding the project in the Access granted to list in the related
view of the following objects:
v Environment profiles. For more information, see Environment Profiles window
fields on page 230.
v Virtual images. For more information, see Virtual image fields on the user
interface on page 292.
v Virtual system patterns. For more information, see Fields on the Virtual System
Patterns window on page 554.
v Script packages. For more information, see Adding a script package on page
243.
v Add-ons. For more information, see Fields on the Add-Ons user interface on
page 265.
v Orchestration actions. For more information, see Making a process available as
an orchestration action on page 772.
v Self-service offerings. For more information, see Modifying self-service
offerings on page 780.
For more information about user and project permissions, see Object-level access
control on page 152.
Managing domains
You can manage domains in SmartCloud Orchestrator with the user interface.
Before you begin
You must be assigned the admin role to perform these steps.
About this task
A built-in domain named Default is already defined in the SmartCloud
Orchestrator environment. For information about domains, see Managing users,
projects, and domains on page 149.
To manage domains from the SmartCloud Orchestrator user interface, perform the
following steps:
Procedure
1. Open the Domain window by clicking Administration > Domains in the menu
bar. The list of the existing domains displayed in the left pane. To show the
details of a domain in the right pane, select the domain in the list.
2. You can perform the following tasks:
v Creating a domain
To create a domain, perform the following steps:
a. Click the Add icon in the domain list. The Create a new domain window
is displayed.
b. Insert a name for the domain.
158 IBM SmartCloud Orchestrator 2.3: User's Guide
Important: As the user and the project name are prefixed by their
domain name in Business Process Manager and Virtual Image Library
with a '/' as delimiter, the user name, project name, and domain name
must not contain a '/' character.
c. Optionally insert a description for the domain.
d. If you do not want to allow users to log in to the domain select Disabled
in the State list.
e. Click Create. The domain is created in SmartCloud Orchestrator.
v Editing a domain
To change the properties of a domain, perform the following steps:
a. Select the domain in the domain list. The domain details are displayed in
the right pane.
b. Click the Edit icon.
c. You can change the following properties:
Name
Description
State
d. Click the Save icon to apply your changes.
v Enabling or disabling a domain
To enable or disable a domain, select the domain in the list and click the
Enable or Disable icon.
v Deleting a domain
To delete a domain that you do not need anymore, perform the following
steps.
Note: When you delete a domain, all the users and projects belonging to the
domain are also deleted.
a. Select the domain in the domain list. The domain details are displayed in
the right pane.
b. Click the Delete icon. A confirmation window is displayed.
c. Click OK to delete the domain. The domain and all the users and projects
belonging to the domain are deleted.
Results
You managed the domains in the SmartCloud Orchestrator environment.
Using the Public Cloud Gateway
The Public Cloud Gateway is installed on the Central Server 2 machine during the
installation of SmartCloud Orchestrator. Use the topics in this section to learn more
about the Public Cloud Gateway and its use within SmartCloud Orchestrator.
Chapter 4. Administering 159
Public Cloud Gateway overview
The Public Cloud Gateway is a web application that provides an OpenStack API
compatibility layer, so the Amazon Elastic Compute Cloud (Amazon EC2) works
like the standard OpenStack Nova and Glance instances.
The Public Cloud Gateway is automatically installed on the Central Server 2
machine as part of the SmartCloud Orchestrator installation process. For more
information about installing SmartCloud Orchestrator, see the related installation
guide. You can deploy and manage virtual machines and storage across both
private and public clouds, for example, Amazon EC2.
Note: With the Public Cloud Gateway, higher level components such as Workload
Deployer and the SmartCloud Orchestrator User Interface operate normally with
the public clouds with no changes required to support them.
Note: The Public Cloud Gateway can also be used to manage non-IBM supplied
OpenStack from SmartCloud Orchestrator. See the related section for more
information.
See the related topic for more information about how the Public Cloud Gateway
fits into the SmartCloud Orchestrator product architecture.
Related tasks:
Installing
Follow this procedure to install SmartCloud Orchestrator.
Capabilities and limitations
Review the following list of capabilities and limitations available with the Public
Cloud Gateway.
Public Cloud Gateway capabilities within SmartCloud Orchestrator
v Deploy a virtual system.
v Stop and start a virtual system instance.
v Remove a virtual system instance.
v Script packages support is available.
v Keypair administration is available.
v Configure the root Keypair on a virtual machine.
v Configure administrator password on a virtual machine with images
containing the Activation Engine.
v Dynamic Host Configuration Protocol (DHCP) networking is available.
v User add-on support is available.
v User data support is available.
Public Cloud Gateway limitations within SmartCloud Orchestrator
v Unable to manage existing instances.
v Unable to leverage the Image Construction and Composition Tool
capabilities using the Public Cloud Gateway. This limitation occurs
because the image must be manually prepared or prepared using the
Image Construction and Composition Tool on a local provider and then
imported into the non-IBM supplied OpenStack.
v Unable to manage virtual application patterns.
v Unable to clone a virtual machine instance.
v Unable to add parts to a virtual system:
160 IBM SmartCloud Orchestrator 2.3: User's Guide
Disk add-on
Network Interface Controller (NIC) add-on
v Unable to retrieve hypervisor resource information when used in a
non-IBM supplied OpenStack configuration.
v Supporting only Dynamic Host Configuration Protocol (DHCP)
networking.
v Unable to manage imported Open Virtualization Appliance (OVA)
images.
v Windows images on Amazon EC2 are not supported.
Related tasks:
Create a supported image
Create a supported image for use with SmartCloud Orchestrator.
Related reference:
Create a supported image
Create a supported image for use with SmartCloud Orchestrator.
Managing Amazon EC2 using the Public Cloud Gateway
The Public Cloud Gateway is not pre-configured for use with Amazon Elastic
Compute Cloud (Amazon EC2) as part of the SmartCloud Orchestrator. Certain
configuration tasks must be completed before using the Public Cloud Gateway
functionality.
Prerequisites
Before configuring the Public Cloud Gateway you must ensure that the
requirements mentioned in this topic are satisfied.
General requirements
An Amazon Web Service (AWS) account with Amazon EC2 credentials for
each tenant/project using the Public Cloud Gateway functionality is
required. See the AWS Management Console for more information:
https://console.aws.amazon.com/console/home
Network requirements
v Port requirements The Public Cloud Gateway requires access to a
number of ports in the installation environment and in the default
Amazon EC2 security group. If these ports are blocked by a firewall or
used by another process, some Public Cloud Gateway functions will not
work.
Table 15. Ports used by Public Cloud Gateway
Port TCP or UDP Direction Description
22 TCP Outbound SSH communication
with:
v Virtual Machine
instances created
on the Amazon
EC2 network. This
must be allowed in
the default
Amazon EC2
security group *.
Chapter 4. Administering 161
Table 15. Ports used by Public Cloud Gateway (continued)
Port TCP or UDP Direction Description
ICMP ICMP communication
with:
v Virtual Machine
instances created
on the Amazon
EC2 network. This
must be allowed in
the default
Amazon EC2
security group *.
443 TCP Outbound HTTPS
communication with:
v Amazon EC2
management
endpoints.
Note: * For more information about Amazon EC2 security groups, see
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-
network-security.html
v Nameserver (DNS) requirements Ensure that the Nameserver is
configured correctly in both Central Server 2 and Central Server 3. Both
Central Server 2 and Central Server 3 instances must be able to resolve
the Amazon EC2 management endpoints as defined in
/opt/ibm/pcg/etc/config.json. If the Nameserver is not configured
correctly, Public Cloud Gateway functions will not work.
Configuring the Public Cloud Gateway
The Public Cloud Gateway is deployed as part of the SmartCloud Orchestrator
installation on the Central Server 2 machine. However, the Public Cloud Gateway
is not enabled by default and certain updates to the configuration files are required
before using the Public Cloud Gateway functionality.
Before you begin
You must ensure that the prerequisites are satisfied.
About this task
At a minimum, you must complete the following steps to configure the Public
Cloud Gateway for use with Amazon EC2.
Procedure
1. Ensure that the admin.json file is configured with the correct Keystone
credentials.
Note: The values in the admin.json file are populated by default during the
installation of SmartCloud Orchestrator.
admin.json
This file is used to store Keystone credentials that are used to create
Amazon EC2 region endpoints in Keystone. These endpoints are
created when the Public Cloud Gateway is started. For more
information about starting the Public Cloud Gateway, see
162 IBM SmartCloud Orchestrator 2.3: User's Guide
Command-line interface scripts on page 181. These values are
populated by default during the installation of SmartCloud
Orchestrator.
Go to the /opt/ibm/pcg/etc directory and open the admin.json file:
{
"auth":{
"passwordCredentials":{
"username":"xxx",
"password":"xxx"
},
"tenantName":"admin"
}
}
The parameters in the admin.json are explained in the following table.
These parameters are required to create Keystone endpoints that
correspond to the Amazon EC2 regions.
Table 16. Parameters that are used in the admin.json file
Parameter Description
username Keystone administrator user name.
password Keystone administrator password. This
value must be encoded by using the
encryptpassword.sh script that is available
in the /opt/ibm/pcg directory. For more
information about the encryptPassword.sh
script, see Command-line interface scripts
on page 181.
tenantName The project name that is associated with the
administrator user.
2. Edit the config.json file to enable the appropriate Amazon EC2 regions and
configure the Keystone endpoints:
config.json
This file is used to specify the Keystone admin, service endpoints,
Amazon EC2 endpoints, and the regions that must be created in
Keystone, thus allowing access to the different Amazon EC2 vCenters
using the Public Cloud Gateway.
Note: The Keystone admin and service endpoints are populated by
default during the installation of SmartCloud Orchestrator.
Go to the /opt/ibm/pcg/etc directory and open the config.json
property file:
{
"auth":{
"provider":"keystone",
"service_url":"http://sco-pcg.xxx:5000",
"admin_url":"http://sco-pcg.xxx:35357"
},
"vcenters":{
"ec2":[
{
"name":"EC2-US-EAST_NORTHERN-VIRGINIA",
"url":"https://ec2.us-east-1.amazonaws.com",
"enabled":true
},
{
Chapter 4. Administering 163
"name":"EC2-US-WEST_OREGON",
"url":"https://ec2.us-west-2.amazonaws.com",
"enabled":true
},
{
"name":"EC2-US-WEST_NORTHERN-CA",
"url":"https://ec2.us-west-1.amazonaws.com",
"enabled":false
}
]
}
}
The parameters in the config.json are explained in the following table.
Update the enabled parameter to true if you want to specify that a
particular region must be created in Keystone.
Table 17. Parameters used in the config.json file
Parameter Description
provider The security provider, only Keystone is
supported in the Public Cloud Gateway.
This is populated during the installation of
SmartCloud Orchestrator.
service_url Public access URL for Keystone. The default
port number is 5000. This is populated
during the installation of SmartCloud
Orchestrator.
admin_url Private access url for Keystone. The default
port number is 35357. This is populated
during the installation of SmartCloud
Orchestrator.
name Name of the region that must be created.
Default Amazon EC2 endpoints are defined.
url The URL of the Amazon EC2 vCenter that
must be associated with the region. Default
Amazon EC2 endpoints are defined.
enabled If set to true this region and all required
Nova, Glance and Keystone endpoints are
created. All Amazon EC2 endpoints are set
to false by default.
3. Obtain the Amazon EC2 credentials (Access key ID and Secret access key) and
use the encryptPassword.sh script to encode the Secret access key. For more
information about the encryptPassword.sh script, see Command-line interface
scripts on page 181.
4. Obtain the project names that will use the public cloud functionality. For more
information about managing projects, see Managing projects on page 155.
5. Edit the credentials.json file to add the appropriate Access key ID and the
encoded Secret access key for each project:
credentials.json
This file is used to specify Amazon EC2 credentials for each project. For
more information about defining projects, see Managing projects on
page 155. The Amazon EC2 credentials are mapped to specific projects
in SmartCloud Orchestrator. These mappings are specified in the
credentials.json configuration file:
164 IBM SmartCloud Orchestrator 2.3: User's Guide
Go to the /opt/ibm/pcg/etc directory and open the credentials.json
file:
{
"cred":{
"ec2":[
{
"tenantName":"demo",
"access_key_ID":"xxx",
"secret_access_key":"xxx=="
},
{
"tenantName":"admin",
"access_key_ID":"xxx",
"secret_access_key":"xxx=="
},
{
"tenantName":"*",
"access_key_ID":"xxx",
"secret_access_key":"xxx=="
}
]
}
}
The parameters in the credentials.json are explained in the following
table. Update these parameters if you want to specify credentials to
project mappings and define what credentials must be used for the
different projects specified.
Table 18. Parameters that are used in the credentials.json file
Parameter Description
tenantName The project name that is associated with the
Amazon EC2 credentials. A default set of
credentials that can be used for projects can
also be specified by using the wildcard
configuration, for example,
"tenantName":"*".
access_key_ID This is the Amazon EC2 credentials user
name.
secret_access_key This is the Amazon EC2 credentials
password. This value must be encoded using
the encryptpassword.sh script that is
available in the ../opt/ibm/pcg directory.
6. Restart the Public Cloud Gateway by using the service pcg restart command.
For more information about starting the Public Cloud Gateway, see
Command-line interface scripts on page 181.
7. Restart the IaaS Gateway by using the service openstack-iaasgateway restart
command.
8. Log in to the SmartCloud Orchestrator UI and go to the Cloud Groups page to
verify that the cloud groups for the availability zones in the new region are
listed.
Note: It may take a few minutes to verify that the region is now enabled.
What to do next
Enable root login to Amazon EC2 images
By default, some Amazon EC2 images do not allow you to log in as the
Chapter 4. Administering 165
root user and only allow you to log in using the ec2-user user. To log in as
the root user, complete the following steps:
v Log in to the image by ssh using the ec2-user user and run the
following commands:
sudo cp ~/.ssh/authorized_keys /root/.ssh/authorized_keys
and
sudo service sshd restart
Create a supported image on Amazon EC2 for use with SmartCloud
Orchestrator
Note: The following instructions are applicable for Linux images only.
Windows images are not supported.
1. Download the following file to the Linux image: http://
<Workload_Deployer_machine>/downloads/cloud-init/scp-cloud-init
2. Run the following commands as the root user:
chmod 755 scp-cloud-init
and
./scp-cloud-init install
3. Create the ovf-env.done file by using the following commands:
mkdir -p /opt/IBM/AE/AR/
and
touch /opt/IBM/AE/AR/ovf-env.done
4. Delete the content of the /etc/rc.d/rc.local file. rc.local is an init
script file provided by Amazon to edit the authentication_keys and
sshd_config files. You must delete the content of the rc.local file to
keep your preferences.
5. Select the Create Image option from the Amazon Web Service (AWS)
Management Console to create an image from the instance. For more
information about the AWS Management Console, see
https://console.aws.amazon.com/console/home.
Change an Amazon EC2 region name
1. Go to the /opt/ibm/pcg/etc directory and open the config.json
property file, replace the old name with new one.
For example, change the region name from EC2-001 to EC2region. The
original EC2 region is :
"ec2":[
{
"name":"EC2-001",
"url":"https://ec2.us-east-1.amazonaws.com/",
"enabled":true
}
change the region's name:
"ec2":[
{
"name":"EC2region",
"url":"https://ec2.us-east-1.amazonaws.com/",
"enabled":true
}
166 IBM SmartCloud Orchestrator 2.3: User's Guide
2. Configure SmartCloud Orchestrator for the new region and remove the
entry for the old region. For more information about configuring a
multiple region environment, see the Installing a multiple-region
environment on page 47.
3. Restart the Public Cloud Gateway by using the service pcg restart
command. For more information about starting the Public Cloud
Gateway, see the related CLI topic.
4. Restart the IaaS Gateway by using the service openstack-iaasgateway
restart command.
5. Delete the services of the old region from keystone:
[root@central-server-2 ~]# source ~/keystonerc
[root@central-server-2 ~]# keystone endpoint-list
WARNING: Bypassing authentication using a token and endpoint (authentication credentials are being ignored).
+----------------------------------+-----------+---------------------------------------------------------+
| id | region | publicurl |
+----------------------------------+-----------+---------------------------------------------------------+
| 0ff9e584b3d04c56af32e7b43ad5324d | EC2-001 | http://central-server-2:5000/v3 |
| 11924c78eca949ae939f2309a4e21bf9 | EC2-001 | http://central-server-2:9797/EC2-001/v1/%(tenant_id)s |
| 187dbc8c68b74d5f8e098d4c61544d0b | RegionOne | http://central-server-2:8776/v1/%(tenant_id)s |
| 19ded8422da445a7b6ceb0ce6d3c5f5e | RegionOne | http://central-server-2:8774/v2/%(tenant_id)s |
| 311e7c36c6b84ee3a5e2f39a04001481 | RegionOne | https://172.17.41.129:9443/ImageLibrary/ImageService/v1 |
| 3d8ff61f86f64838be5000b7efd60b89 | RegionOne | http://central-server-2:9292/ |
| 7f5a578d80684fcaaa473c9012ba7f46 | EC2-001 | http://central-server-2:9797/EC2-001/v2.0/%(tenant_id)s |
| bf8de63072ae453fb5ddf8b3027945cf | RegionOne | http://central-server-2:5000/v3 |
| e0a8c3d7c821424e94a0ef17c8c1a383 | EC2-001 | http://central-server-2:9797/EC2-001/v2.0 |
+----------------------------------+-----------+---------------------------------------------------------+
---------------------------------------------------------+
internalurl |
---------------------------------------------------------+
http://central-server-2:5000/v3 |
http://central-server-2:9797/EC2-001/v1/%(tenant_id)s |
http://central-server-2:8776/v1/%(tenant_id)s |
http://central-server-2:8774/v2/%(tenant_id)s |
https://172.17.41.129:9443/ImageLibrary/ImageService/v1 |
http://central-server-2:9292/ |
http://central-server-2:9797/EC2-001/v2.0/%(tenant_id)s |
http://central-server-2:5000/v3 |
http://central-server-2:9797/EC2-001/v2.0 |
---------------------------------------------------------+
---------------------------------------------------------+----------------------------------+
adminurl | service_id |
---------------------------------------------------------+----------------------------------+
http://central-server-2:35357/v3 | 40a0d00ad6d34cfc8a5c412c61cb3e33 |
http://central-server-2:9797/EC2-001/v1/%(tenant_id)s | 372311fb67564e41987038d587c6a539 |
http://central-server-2:8776/v1/%(tenant_id)s | 372311fb67564e41987038d587c6a539 |
http://central-server-2:8774/v2/%(tenant_id)s | b6155b46d8d1463185fdfbddb05f18b5 |
https://172.17.41.129:9443/ImageLibrary/ImageService/v1 | ac8c99aa1fb445898f92fd0aeb43c8e1 |
http://central-server-2:9292/ | 1f3d30e2fcf04bdd908969a987722acc |
http://central-server-2:9797/EC2-001/v2.0/%(tenant_id)s | b6155b46d8d1463185fdfbddb05f18b5 |
http://central-server-2:35357/v3 | 40a0d00ad6d34cfc8a5c412c61cb3e33 |
http://central-server-2:9797/EC2-001/v2.0 | 1f3d30e2fcf04bdd908969a987722acc |
---------------------------------------------------------+----------------------------------+
Delete all the endpoints related for the old region EC2-001 with the
following command, for example:
[root@central-server-2 ~]# keystone endpoint-delete 0ff9e584b3d04c56af32e7b43ad5324d
Related reference:
Command-line interface scripts
Command Line Interface (CLI) scripts are available in the /opt/ibm/pcg directory.
These scripts are used to perform manual tasks, for example, starting the Public
Cloud Gateway, encrypting a password, changing port numbers and so on.
Password authentication on Amazon EC2 images on page 181
Use this topic if you want to allow password authentication and root login by
using password authentication on Amazon EC2 images.
Region names displayed incorrectly in the Virtual Image page on page 178
A known issue exists where SmartCloud Orchestrator removes the name after an
_ in the region name when registering images.
Chapter 4. Administering 167
Unable to connect to a public cloud due to missing credentials on page 179
Exceptions may occur in the Public Cloud Gateway stating that it is Unable to
connect to public cloud due to missing credentials. This is due to
tenants/projects being present on SmartCloud Orchestrator that are not accounted
for in the credentials.json file.
Loss of functionality in Public Cloud Gateway cloud groups on page 177
Loss of functionality may occur in Public Cloud Gateway cloud groups in
SmartCloud Orchestrator, where there has been heavy load on the Public Cloud
Gateway cloud groups.
Managing non-IBM supplied OpenStack using the Public
Cloud Gateway
SmartCloud Orchestrator is unable to manage non-IBM supplied OpenStack
directly due to the differences between IBM supplied OpenStack and non-IBM
supplied OpenStack. As a result of this, the Public Cloud Gateway can be used as
an interface between SmartCloud Orchestrator and non-IBM supplied OpenStack.
The Public Cloud Gateway provides a compatibility layer that enables SmartCloud
Orchestrator to manage Amazon EC2 images and instances by performing the
necessary translation to the Amazon EC2 API. This functionality can be used to
enable SmartCloud Orchestrator to manage non-IBM supplied OpenStack services
by accessing them through their Amazon EC2 API.
Note: Not all EC2 operations are supported by the OpenStack EC2
implementation. For example, the Resize Instance functionality is not supported
in Public Cloud Gateway by the OpenStack EC2 API.
Additional information on the capabilities of the OpenStack EC2 implementation is
available under API Feature Comparison at: https://wiki.openstack.org/wiki/
Main_Page.
Prerequisites
Before configuring the Public Cloud Gateway to manage non-IBM supplied
OpenStack, you must ensure that the requirements mentioned in this topic are
satisfied.
General requirements
v A configured and working non-IBM supplied OpenStack must be
available.
v The non-IBM supplied OpenStack must be the Folsom release or higher.
v Compute nodes must be configured to any OpenStack-supported
hypervisor type.
Network requirements
v Port requirements The Public Cloud Gateway requires access to a
number of ports in the installation environment and in the default
non-IBM supplied OpenStack security group. If these ports are blocked
by a firewall or used by another process, some Public Cloud Gateway
functions will not work.
168 IBM SmartCloud Orchestrator 2.3: User's Guide
Table 19. Ports used by Public Cloud Gateway
Port TCP or UDP Direction Description
22 TCP Outbound SSH communication
with:
v Virtual Machine
instances created
on the non-IBM
supplied
OpenStack a
network. This must
be allowed in the
default non-IBM
supplied
OpenStack security
group *.
ICMP ICMP communication
with:
v Virtual Machine
instances created
on the non-IBM
supplied
OpenStack
network. This must
be allowed in the
default non-IBM
supplied
OpenStack security
group *.
443 TCP Outbound HTTPS
communication with:
v non-IBM supplied
OpenStack
Amazon EC2
management
endpoints.
v Nameserver (DNS) requirements Ensure that the Nameserver is
configured correctly in both Central Server 1 and Central Server 2.
Both Central Server 1 and Central Server 2 instances must be able to
resolve the non-IBM supplied OpenStack management endpoints as
defined in /opt/ibm/pcg/etc/config.json. If the Nameserver is not
configured correctly, Public Cloud Gateway functions will not work.
Configure the Public Cloud Gateway to manage non-IBM
supplied OpenStack
The following configuration topics assume that you already have one or more
OpenStack regions that are configured and functioning. Instructions on how to
install and configure a basic OpenStack instance can be found at
http://docs.openstack.org.
Chapter 4. Administering 169
Configure the Public Cloud Gateway regions for non-IBM supplied OpenStack:
The Public Cloud Gateway requires connection details for every non-IBM supplied
OpenStack region it manages.
About this task
To obtain the connection details, log on to the host that is running the Keystone
service in each non-IBM supplied OpenStack region and complete the following
steps:
Procedure
1. Run the following command:
keystone service-list
and look for the entry for Amazon EC2 and take note of the ID.
2. Run the following command:
keystone endpoint-list
and find the entry where the service_id matches the Amazon EC2 ID from the
previous step. Take a note of the publicurl also. It will be something similar to
http://<address>:8773/services/Cloud
Note: If you want the Public Cloud Gateway to manage more than one
non-IBM supplied OpenStack region, repeat these steps on the Keystone server
for each non-IBM supplied OpenStack region. This is required to obtain the
Amazon EC2 API interface address for each region.
3. The Public Cloud Gateway reads the connection details at startup from the
/opt/ibm/pcg/etc/config.json file on the Central Server 2 node. By default,
this file only contains the details of the Amazon EC2 regions. This file must be
updated to add the non-IBM supplied OpenStack regions to a data block
tagged nios inside the vcenters scope similar to this partial example:
"vcenters":{
"ec2":[
{
"name":"EC2-US-EAST_NORTHERN-VIRGINIA",
"url":"https://ec2.us-east-1.amazonaws.com",
"enabled":false
},
{
"name":"EC2-US-WEST_OREGON",
"url":"https://ec2.us-west-2.amazonaws.com",
"enabled":false
},
],
"nios":[
{
"name":"nioRegion1",
"url":"http://172.16.108.12:8773/services/Cloud/",
"enabled":true
},
{
"name":"nioRegion2",
"url":"http://172.16.108.13:8773/services/Cloud/",
"enabled":true
}
]
},
170 IBM SmartCloud Orchestrator 2.3: User's Guide
Note: The url that is obtained from Keystone has a trailing / appended to it.
Note: The region name specified in the nios tag section must be a unique
name for that particular region.
What to do next
If the connection details contain a host name rather than an IP address, make sure
that the Central Server 2 node can resolve the host names and add entries to the
/etc/hosts file if required. Alternatively, use the IP address rather than the host
name in the config.json file.
Configure non-IBM supplied OpenStack flavors:
As stated in the related introduction topic, there are limitations to the functionality
provided by the Amazon EC2 API. One of the limitations is that there is no
support for managing the flavors of the compute instances.
Since the OpenStack API does support flavors, and SmartCloud Orchestrator must
query each region to collect a list of the available flavors, the Public Cloud
Gateway requires an alternative source for this information. This is required so that
it can answer the requests that it receives from SmartCloud Orchestrator.
The flavors are defined in a file on the Central Server 2 machine, which must be
manually updated to match the flavors available in each non-IBM supplied
OpenStack region. If the detail of the flavors is later changed, the file must be
updated again and the Public Cloud Gateway must be restarted.
1. To obtain the list of flavors that are supported on a particular non-IBM
supplied OpenStack region, logon to a Nova node in that region and issue the
command:
nova flavor-list
The following is an example of the response:
root@nio3:~# nova flavor-list
OS Password:
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+-------------+
| ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public | extra_specs |
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+-------------+
| 1 | m1.small | 2048 | 20 | 0 | | 1 | 1.0 | True | {} |
| 2 | m1.medium | 4096 | 40 | 0 | | 2 | 1.0 | True | {} |
| 3 | m1.large | 8192 | 80 | 0 | | 4 | 1.0 | True | {} |
| 4 | m1.xlarge | 16384 | 160 | 0 | | 8 | 1.0 | True | {} |
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+-------------+
2. Edit the file /opt/ibm/pcg/etc/flavors.json file on the Central Server 2 node
and use the data from the Name, Memory_MB, Disk, and VCPUs columns to
populate the name, ram, disk, and cpu fields. Different flavors can be defined
for each non-IBM supplied OpenStack region and the default region can be
used for any non-IBM supplied OpenStack region not explicitly mentioned. The
region names must exactly match those defined in the config.json file.
3. If the output in the previous step was generated in a non-IBM supplied
OpenStack region that is defined as nioRegion1 in the config.json file, the
resulting flavors.json would look similar to this:
{
"default": {
"m1.small": {"name":"Small", "cpu":1, "ram":1700, "disk":150},
"m1.medium": {"name":"Medium", "cpu":2, "ram":3750, "disk":400},
"m1.large": {"name":"Large", "cpu":4, "ram":7500, "disk":840},
"m1.xlarge": {"name":"Extra Large", "cpu":8, "ram":15000, "disk":1680},
"c1.xlarge": {"name":"High-CPU Extra Large", "cpu":20, "ram":7000, "disk":1680},
"m2.xlarge": {"name":"High-Memory Extra Large", "cpu":6, "ram":17100, "disk":410}
Chapter 4. Administering 171
},
"nioRegion1": {
"m1.small": {"name":"Small", "cpu":1, "ram":2048, "disk":20},
"m1.medium": {"name":"Medium", "cpu":2, "ram":4096, "disk":40},
"m1.large": {"name":"Large", "cpu":4, "ram":8192, "disk":80},
"m1.xlarge": {"name":"Extra Large", "cpu":8, "ram":16384, "disk":160},
}
}
Using this example, when accessing nioRegion1, SmartCloud Orchestrator
offers a list of four flavors, but any other non-IBM supplied OpenStack regions
offers the six flavors that are defined for the default region.
Note:
v The flavors.json file does not alter the flavors for Amazon EC2 regions, even if
the Amazon EC2 region names are listed in the file.
v The id in the flavors.json file (m1.small in the above output) must match the
flavor name on non-IBM supplied OpenStack and not the flavor ID.
v SmartCloud Orchestrator requires at least 512 MB of memory to be defined in
flavors.
Related tasks:
Configuring the Public Cloud Gateway
The Public Cloud Gateway is deployed as part of the SmartCloud Orchestrator
installation on the Central Server 2 machine. However, the Public Cloud Gateway
is not enabled by default and certain updates to the configuration files are required
before using the Public Cloud Gateway functionality.
Related reference:
Configure IaaS Gateway and restart the Public Cloud Gateway on page 174
Configure SmartCloud Orchestrator for the new region. For more information
about configuring a multiple region environment, see the related configuring topic.
When all the configuration tasks are complete, the Public Cloud Gateway and the
IaaS gateway must be restarted.
Configure non-IBM supplied OpenStack EC2 credentials:
The credentials that are used on the Amazon EC2 API are different from the
credentials that are used by the OpenStack API. As a result, it is necessary to
generate these special credentials and configure the Public Cloud Gateway to use
them when accessing the non-IBM supplied OpenStack services.
The credentials that the Public Cloud Gateway uses on the Amazon EC2 API
interface are checked by the Keystone service that is running in the non-IBM
supplied OpenStack region. As a result, you must use the non-IBM supplied
OpenStack Keystone service to generate the Amazon EC2 API credentials.
1. The command that is used to create the Amazon EC2 credentials requires the
32-digit IDs of the user and tenant that will be copied during the Amazon EC2
API calls. Log on to the non-IBM supplied OpenStack Keystone host in each
non-IBM supplied OpenStack region and obtain these IDs using the commands:
keystone user-list
keystone tenant-list
172 IBM SmartCloud Orchestrator 2.3: User's Guide
Note: The user and tenant that is chosen must have sufficient access to do the
necessary actions on Nova and Glance. Use the admin user and admin tenant
unless you have suitable alternatives that are configured on the non-IBM
supplied OpenStack Keystone.
2. Create the Amazon EC2 credentials using the command:
keystone ec2-credentials-create --tenant-id <tenant ID> --user-id <user ID>
If successful, the command returns 2 new 32-bit keys that are called Access and
Secret.
Note: Amazon EC2 credentials that are created on non-IBM supplied
OpenStack Keystone apply to both tenant and user when using these
credentials. For example, when deploying a virtual machine, the virtual
machine is created using the tenant and the user specified in the previous
command.
3. The following example shows the previous steps where Amazon EC2
credentials are created on the non-IBM supplied OpenStack using the admin
tenant and the admin user: :
root@nio3:/etc/glance# keystone user-list
+----------------------------------+---------+---------+--------------------+
| id | name | enabled | email |
+----------------------------------+---------+---------+--------------------+
| 475e0cb45d1049cbb5bddf1eb508b391 | admin | True | [email protected] |
| 901653358e49460297fbba3dfb0848cf | cinder | True | [email protected] |
| 79fabd02dc1f43aabc03f77d97a840ee | demo | True | [email protected] |
| 00cb0e8b6d734e7499fca57d077b0fc1 | glance | True | [email protected] |
| 10f54c9b123147c488ae3c942143acc8 | nova | True | [email protected] |
| 940f130d79cc46b9ae38ae6bda929767 | quantum | True | [email protected] |
+----------------------------------+---------+---------+--------------------+
root@nio3:/etc/glance# keystone tenant-list
+----------------------------------+---------+---------+
| id | name | enabled |
+----------------------------------+---------+---------+
| 40a39220bf5747edaac54216b5e8eb60 | admin | True |
| 7cdafa91633a43d19e773bdbe0b28b76 | demo | True |
| 0420552b5721451a9d42b5e96ba79444 | service | True |
+----------------------------------+---------+---------+
root@nio3:/etc/glance# keystone ec2-credentials-create
--tenant-id 40a39220bf5747edaac54216b5e8eb60
--user-id 475e0cb45d1049cbb5bddf1eb508b391
+-----------+----------------------------------+
| Property | Value |
+-----------+----------------------------------+
| access | 7e3d858e92324564a31e5d9b50fa62f0 |
| secret | 98d7e15c0ae649b6a90bcbd8f9dbb725 |
| tenant_id | 40a39220bf5747edaac54216b5e8eb60 |
| user_id | 475e0cb45d1049cbb5bddf1eb508b391 |
+-----------+----------------------------------+
root@nio3:/etc/glance#
Note: If the Keystone ec2-credentials-create command is run a second time,
even if the same user ID and tenant ID are used, the result will be entirely
different and the previous access and secret key becomes invalid. Also, ensure
that the commands are run on each separate non-IBM supplied OpenStack
region that is controlled by the Public Cloud Gateway. This is required as
different Keystone instances generate different IDs for the same user name or
tenant name.
4. Before the secret key can be used, it must be base-64 encoded using the
encryptpassword.sh script:
v Edit /opt/ibm/pcg/etc/credentials.json on the Central Server 2 machine.
Chapter 4. Administering 173
v In the nios section, insert a new block of data with the correct region name,
tenant name, access key, and encoded secret key.
Note: Take care to insert the appropriate comma if a new block is being
appended to an existing section.
Note: Credentials should be defined for all SmartCloud Orchestrator tenants.
v Save the file.
The following example of credentials.json shows the formatting:
{
"cred":{
"ec2":[
{
"tenantName":"admin",
"access_key_ID":"XXXXXXXXXXXXXXXXXXXX",
"secret_access_key":"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=="
}
],
"nios":[
{
"tenantName":"admin",
"access_key_ID":"7e3d858e92324564a31e5d9b50fa62f0",
"secret_access_key":"OGQ3ZTE1YzBhZTY0OWI2YTkwYmNiZDhmOWRiYjcyNQ==",
"region":"nioRegion1"
}
]
}
}
The tenantName supplied as part of the credentials.json refers to SmartCloud
Orchestrator tenant. This tenantName signifies which tenant has access to non-IBM
supplied OpenStack. The tenant that is used by the non-IBM supplied OpenStack
is determined by the access (access_key_ID) and secret access keys
(secret_access_key).
Configure IaaS Gateway and restart the Public Cloud Gateway:
Configure SmartCloud Orchestrator for the new region. For more information
about configuring a multiple region environment, see the related configuring topic.
When all the configuration tasks are complete, the Public Cloud Gateway and the
IaaS gateway must be restarted.
Restart the Public Cloud Gateway service by logging on to Central Server 2 as root
and running the following command:
service pcg restart
Restart the IaaS Gateway by logging on to Central Server 2 as root and running the
following command:
service openstack-iaasgateway restart
For more information about managing the IaaS Gateway service, see the related
topic.
174 IBM SmartCloud Orchestrator 2.3: User's Guide
If the Public Cloud Gateway is properly configured, it starts to add the new
endpoints to the service catalog of the main SmartCloud Orchestrator Keystone
instance. You can check this by logging on Central Server 2 and running the
following command:
keystone endpoint-list
Review the region column for entries that match the names that are given to the
non-IBM supplied OpenStack regions. Log on to the SmartCloud Orchestrator
application and go to the Cloud Groups page to verify that the cloud groups for
the availability zones in the new region are listed.
Note: It may take a few minutes to verify that the region is now enabled.
Related reference:
Configure non-IBM supplied OpenStack flavors on page 171
As stated in the related introduction topic, there are limitations to the functionality
provided by the Amazon EC2 API. One of the limitations is that there is no
support for managing the flavors of the compute instances.
Post configuration tasks
After successful configuration of the Public Cloud Gateway to manage non-IBM
supplied OpenStack, the following tasks can be completed.
Create a supported image:
Create a supported image for use with SmartCloud Orchestrator.
Note: Windows images are not supported.
Check the prerequisites for a KVM or VMware image at Prerequisites for KVM or
VMware images on page 488.
Images activated by scp-cloud-init:
Manually creating images activated by cloud-init:
v Detailed information about creating images compatible with OpenStack
and activated by cloud-init can be found in OpenStack documentation:
http://docs.openstack.org/image-guide/content/
ch_creating_images_manually.html
v Additional information and documentation about cloud-init can be
found on the projects web site: https://launchpad.net/cloud-init, or in
it's latest documentation: http://cloudinit.readthedocs.org/en/latest/.
Images activated by cloud-init:
Example images activated by cloud-init:
v There are many ready to use GNU/Linux images available on the
internet. The OpenStack community has gathered some links for the
most popular Operating Systems: http://docs.openstack.org/image-
guide/content/ch_obtaining_images.html
Manually creating Linux images only:
1. Download the following file to the Linux instance:
http://<Workload_Deployer_machine>/downloads/cloud-init/scp-
cloud-init.
2. Run the following commands as the root user:
chmod 755 scp-cloud-init
and
Chapter 4. Administering 175
./scp-cloud-init install
Note: To run the scp-cloud-init script, you must have the following
commands installed on the system. Most of these commands are
already included in the default Linux installation: scp, awk, chmod, cat,
curl, find, grep, mkfs, parted, sed, od, unzip.
3. Create the ovf-env.done file on the file system by using the following
commands:
mkdir -p /opt/IBM/AE/AR/
and
touch /opt/IBM/AE/AR/ovf-env.done
4. At this point, you can create an image from the instance using the
Nova image-create command for use with SmartCloud Orchestrator.
For information about managing virtual images, see Chapter 5,
Managing virtual images, on page 287.
Create image using the Image Construction and Composition Tool
While there is no support available in the Public Cloud Gateway for the
Image Construction and Composition Tool, images created or extended
using this tool can be exported from the image repository configured in the
Image Construction and Composition Tool. These images are then
imported directly into the non-IBM supplied OpenStack:
1. Use the Image Construction and Composition Tool instructions for
creating a supported image using a different cloud provider, for
example, OpenStack cloud provider.
2. Export the image from the OpenStack environment using the
OpenStack glance command.
3. Import the image directly on to the non-IBM supplied OpenStack
environment using the glance command.
For more information about the glance command, see
http://docs.openstack.org/user-guide/content/glance_commands.html.
Related concepts:
Working with virtual images
You can build virtual images.
Related information:
Managing virtual images
Virtual images provide the operating system and product binary files that are
required to create a virtual system instance.
Troubleshooting
Use this section to resolve any issues that you may encounter when using the
Public Cloud Gateway.
Logs are stored in the /var/log/pcg.log.
The Public Cloud Gateway uses log4j logging. The log4j.properties file is
located in the /opt/ibm/pcg/etc directory.
For more information about the properties in the log4j.properties file, see the
documentation on the Log4j web site: http://logging.apache.org/log4j
176 IBM SmartCloud Orchestrator 2.3: User's Guide
Loss of functionality in Public Cloud Gateway cloud groups
Loss of functionality may occur in Public Cloud Gateway cloud groups in
SmartCloud Orchestrator, where there has been heavy load on the Public Cloud
Gateway cloud groups.
Symptom
As stated in description.
Solution
This is due to exceeding the Amazon Web Service (AWS) API Request Rate
limit. The Public Cloud Gateway has addressed this issue by introducing a
caching mechanism. This functionality provides for caching of servers,
availability zones, and image details internally when they are returned
from Amazon EC2. The Public Cloud Gateway queries Amazon EC2 every
"N" number of times that it is called, where "N" is the value that is defined
in the cacheCounter tag section of the config.json file. Use the following
steps if you want to update the default values in the cacheCounter tag
section:
1. Update the config.json file and add the cacheCounter tag section to
overwrite the default cache counter settings. The cacheCounter tag
section can be added as follows:
{
"auth":{
"provider":"keystone",
"service_url":"http://sco-pcg.xxx:5000",
"admin_url":"http://sco-pcg.xxx:35357"
},
"vcenters":{
"ec2":[
{
"name":"EC2-US-EAST_NORTHERN-VIRGINIA",
"url":"https://ec2.us-east-1.amazonaws.com",
"enabled":true
},
{
"name":"EC2-US-WEST_OREGON",
"url":"https://ec2.us-west-2.amazonaws.com",
"enabled":true
},
{
"name":"EC2-US-WEST_NORTHERN-CA",
"url":"https://ec2.us-west-1.amazonaws.com",
"enabled":false
}
]
},
"cacheCounter":{
"serversCounter":"N",
"glanceImagesCounter":"N",
"availabilityZoneCounter":N
}}
Note: If you do not specify the above values in the cacheCounter tag
section or it is not added to the config.json, then the values 5, 10, and
20 are used by default. For example:
"cacheCounter":{
"serversCounter":"5",
"glanceImagesCounter":"10",
"availabilityZoneCounter":20
}
The following table explains these parameters in more detail.
Chapter 4. Administering 177
Table 20. Parameters used in the cacheCounter tag section of the config.json file
Parameter Description
serversCounter Every time, for example 5 times,
SmartCloud Orchestrator attempts to get a
list of servers or a single server, it queries
Amazon EC2 once for a new list servers.
glanceImagesCounter Every time, for example 10 times,
SmartCloud Orchestrator requests a list of
images, the Public Cloud Gateway queries
Amazon EC2 once for a new list images.
availabilityZoneCounter Every time, for example 20 times,
SmartCloud Orchestrator requests a list of
availability zones, the Public Cloud Gateway
queries Amazon EC2 once for a new list of
availability zones.
2. Restart the Public Cloud Gateway.
Related tasks:
Configuring the Public Cloud Gateway on page 162
The Public Cloud Gateway is deployed as part of the SmartCloud Orchestrator
installation on the Central Server 2 machine. However, the Public Cloud Gateway
is not enabled by default and certain updates to the configuration files are required
before using the Public Cloud Gateway functionality.
Loss of functionality in Public Cloud Gateway cloud groups (2)
Loss of functionality might occur in Public Cloud Gateway cloud groups in
SmartCloud Orchestrator, where there has been outage in the endpoint being
managed by the Public Cloud Gateway.
Symptom
As stated in description.
Solution
Perform the following steps:
1. Restart the Public Cloud Gateway.
2. Manually start the hypervisors for the affected cloud groups in this
situation if there are no instances associated with this cloud group.
SmartCloud Orchestrator will rediscover the cloud groups after the
Public Cloud Gateway is restarted.
Region names displayed incorrectly in the Virtual Image page
A known issue exists where SmartCloud Orchestrator removes the name after an
_ in the region name when registering images.
Symptom
EC2-US-WEST_NORTHERN-CA and EC2-US-WEST_OREGON regions are displayed as
EC2-US-WEST when registering an image. This error prevents you from
selecting images from both regions.
Solution
1. Edit /opt/ibm/pcg/etc/config.json on Central Server 2 and replace _
(underscore) in region names with a (dash).
2. Restart the Public Cloud Gateway to allow the changes to take effect:
service pcg restart
178 IBM SmartCloud Orchestrator 2.3: User's Guide
3. Log in to SmartCloud Orchestrator and wait for the new regions to
display. Once the images are displayed, delete the old
EC2-US-WEST_NORTHERN-CA and EC2-US-WEST_OREGON cloud groups and
hypervisors . You can also delete any registered images that belong to
these regions.
4. Log in to the Central Server 2 and run the following command:
keystone endpoint-list
and identify the old endpoints by their region name.
5. Delete the old endpoints for EC2-US-WEST_NORTHERN-CA and
EC2-US-WEST_OREGON, by running the following command:
keystone endpoint-delete <endpoint-id>
Note: Be careful not to delete any valid endpoints.
6. Images can now be registered for both regions.
Related tasks:
Configuring the Public Cloud Gateway on page 162
The Public Cloud Gateway is deployed as part of the SmartCloud Orchestrator
installation on the Central Server 2 machine. However, the Public Cloud Gateway
is not enabled by default and certain updates to the configuration files are required
before using the Public Cloud Gateway functionality.
Unable to connect to a public cloud due to missing credentials
Exceptions may occur in the Public Cloud Gateway stating that it is Unable to
connect to public cloud due to missing credentials. This is due to
tenants/projects being present on SmartCloud Orchestrator that are not accounted
for in the credentials.json file.
Symptom
As stated in description.
Solution
There are two methods that can be used to resolve this issue:
1. Add Amazon EC2 credentials for each tenant inSmartCloud
Orchestrator to the credentials.json file.
2. Add Amazon EC2 credentials, where the tenantName is * as stated in
step 5 in the related configuring topic. This ensures that these Amazon
EC2 credentials are applied to each tenant that is not explicitly stated in
credentials.json file.
Related tasks:
Configuring the Public Cloud Gateway on page 162
The Public Cloud Gateway is deployed as part of the SmartCloud Orchestrator
installation on the Central Server 2 machine. However, the Public Cloud Gateway
is not enabled by default and certain updates to the configuration files are required
before using the Public Cloud Gateway functionality.
Chapter 4. Administering 179
Unable to deploy instance to non-IBM supplied OpenStack
Unable to deploy an instance to non-IBM supplied OpenStack with error:
"org.apache.http.impl.client.DefaultRequestDirector [WARN] Authentication
error: Unable to respond to any of these challenges: {}".
While Public Cloud Gateway might appear to behave normally, the hypervisors are
present, the cloud group exists, registering images is successful, there following is
shown in the log file when deploying an instance to non-IBM supplied OpenStack.
[2013-08-01 09:00:33,607] org.apache.http.impl.client.DefaultRequestDirector [WARN]
Authentication error: Unable to respond to any of these challenges: {}
[2013-08-01 09:00:33,621] com.ibm.ccs.publiccloud.service.actions.ServerActions [ERROR]
Unable to deploy Instance com.ibm.ccs.publiccloud.broker.exception.ServiceException
.
.
Caused by: com.amazonaws.AmazonClientException: Unable to unmarshall error response
(Content is not allowed in prolog.)
.
.
Caused by: org.xml.sax.SAXParseException: Content is not allowed in prolog.
Solution:
The credentials used to connect to non-IBM supplied OpenStack have read but not
write permissions. The Public Cloud Gateway requires credentials with
permissions to deploy instances.
Inconsistencies in deployed instance names
When server instances are deployed on non-IBM supplied OpenStack, the names
that are given to the instances in the non-IBM supplied OpenStack differ from the
names that are given to the instances in SmartCloud Orchestrator.
This is a known issue in the Amazon EC2 API implementation in OpenStack
versions before the Grizzly release.
For more information about this known issue, see the following link:
https://bugs.launchpad.net/nova/+bug/1096821
MAC address field is empty
No information is displayed for the MAC address field when viewing non-IBM
supplied OpenStack or Amazon EC2 virtual system instances.
Symptom
Once a non-IBM supplied OpenStack or Amazon EC2 virtual system
instance is deployed, open the Virtual System Instances panel, by clicking
Instances > Virtual Systems. You will notice that no information is
displayed for the MAC address field.
Solution
This information is not available when using the Public Cloud Gateway.
180 IBM SmartCloud Orchestrator 2.3: User's Guide
Reference
This section provides reference information for the Public Cloud Gateway.
Key pairs
Key pairs are needed to access the virtual machines that you deploy in a pattern.
When you deploy a virtual machine, these keys are injected into the instance to
allow password-less SSH access to the instance.
The default key pair that is created from the SmartCloud Orchestrator UI in
Amazon EC2 regions is appended with the user ID of the user that created the key
pair. For example, if the user creating the key pair in the SmartCloud Orchestrator
UI is admin, the name of the key pair that is created in Amazon EC2 will be
deafult_admin. For information about managing key pairs, see the related topic.
Related tasks:
Managing key pairs
Manage pairs of SSH private and public keys in your environment to access
deployed virtual machines.
Command-line interface scripts
Command Line Interface (CLI) scripts are available in the /opt/ibm/pcg directory.
These scripts are used to perform manual tasks, for example, starting the Public
Cloud Gateway, encrypting a password, changing port numbers and so on.
Note: The default port number is 9797. To change this, you must edit the
startServer.sh script and change the value of -DHybrid.Port to the new port
number.
v encryptPassword.sh <secret_Access_key> used to encrypt the Amazon EC2
Secret_access_key to a form that can be used by the Public Cloud Gateway.
v service pcg start used to start the Public Cloud Gateway server with the
default settings.
v service pcg stop used to stop the Public Cloud Gateway server.
v service pcg restart used to restart the Public Cloud Gateway server.
Password authentication on Amazon EC2 images
Use this topic if you want to allow password authentication and root login by
using password authentication on Amazon EC2 images.
Log on to the Amazon EC2 image by using ssh and complete the following steps:
1. Edit the following file: /etc/ssh/sshd_config
2. Update the line that contains PasswordAuthentication as follows:
PasswordAuthentication yes
3. Update the line that contains PermitRootLogin as follows:
PermitRootLogin yes
4. Save the file.
5. Run the following command:
sudo service sshd restart
Related tasks:
Configuring the Public Cloud Gateway on page 162
The Public Cloud Gateway is deployed as part of the SmartCloud Orchestrator
installation on the Central Server 2 machine. However, the Public Cloud Gateway
is not enabled by default and certain updates to the configuration files are required
before using the Public Cloud Gateway functionality.
Chapter 4. Administering 181
Configuring the Public Cloud Gateway regions to use a proxy
server
You can configure the Public Cloud Gateway regions to use a proxy server.
About this task
You can specify proxy server details at region level or at vCenter level (ec2 or
nios). The proxy configuration that you specify at region level overrides the proxy
configuration specified at vCenter level.
The Public Cloud Gateway reads the proxy server details at startup from the
/opt/ibm/pcg/etc/config.json file on the Central Server 2.
In the following example, the proxy server configuration is defined at region level
for the EC2-EU-IRELAND region. Also a second proxy server configuration is
defined for the nios vCenter.
"vcenters":
{
"ec2":[
{
"name":"EC2-EU-IRELAND",
"url":"https://ec2.eu-west-1.amazonaws.com",
"enabled":true,
"proxy":{
"host":"proxy-server-host",
"username":"admin",
"password":"cGFzc3cwcmQ=",
"port": 3128
}
},
{
"name":"EC2-US-WEST_OREGON",
"url":"https://ec2.us-west-2.amazonaws.com",
"enabled":true
},
],
"nios":[
{
"name":"nioRegion1",
"url":"http://172.16.108.12:8773/services/Cloud/",
"enabled":true
}
]
},
"proxy":[
{
"vcenter":"nios",
"host":"172.17.41.129",
"username":"admin",
"password":"cGFzc3cwcmQ=",
"port": 3128
}
]
Note: The passwords specified in the proxy server configuration must be base-64
encoded by using the encryptpassword.sh script.
182 IBM SmartCloud Orchestrator 2.3: User's Guide
Building the cloud with topology resources
You can build clouds using your existing resources, for example hypervisors,
networks and storage, with SmartCloud Orchestrator. SmartCloud Orchestrator
manages these resources in the cloud.
About this task
You can work with resources to build your cloud. The following procedure
provides a layout of the information for each type of resource with links to the
specific section.
Procedure
1. Determine which interface you want to use.
v You can work with the user interface. Ensure that you have access to the
user interface.
v You can work with the command-line interface. Ensure that you have
downloaded and installed the command-line interface. For more information
about downloading and initializing the command-line interface, see
Downloading and configuring the command-line interface on page 909 and
Invoking the command-line interface on page 911.
2. You can work with the following resources to build your cloud:
Administering cloud groups on page 184
Cloud groups are collections of hypervisors.
Administering hypervisors on page 187
A platform virtualization software that allows multiple operating
systems to run on a host computer concurrently.
Administering virtual machines on page 194
The virtual machines running on a hypervisor.
Administering networks on page 203
A network object that is defined for a hypervisor.
Administering storage on page 206
The storage devices, and their configuration, that are linked to a
hypervisor.
Administering IP groups and IP addresses on page 208
Groups of IP addresses defined to enable granular assignment of IP
address ranges to hypervisors.
Managing cloud resources
Use the user interface or the command-line interface to manage the resources in
the cloud system.
Chapter 4. Administering 183
Administering cloud groups
In SmartCloud Orchestrator, a cloud group is identified by an availability zone in a
region of the related OpenStack environment.
Before you begin
Before starting to work with cloud groups in SmartCloud Orchestrator, define the
OpenStack availability zones as described in Managing availability zones in
OpenStack on page 185.
About this task
In the SmartCloud Orchestrator user interface, the availability zones already
defined in the regions of the related OpenStack environment are automatically
listed as cloud groups named region-name_availability-zone-name, where region-name
is the name of the region where the availability zone named availability-zone-name is
defined. A region is an OpenStack instance. For more information about creating
additional OpenStack regions in your environment, see Installing a
multiple-region environment on page 47.
For VMware regions, in SmartCloud Orchestrator a cloud group is listed for each
VMware cluster or resource pool that is defined in the vCenter. You can specify the
cluster or resource pool as a deployment target by specifying the related cloud
group in the environment profile.
Note: SmartCloud Orchestrator does not report information related to reserved
resources and limits associated to the resource pool in VMware. By default, the
resource pool is considered as unlimited. Use the environment profile in
SmartCloud Orchestrator to manage the resource limits.
To use the command-line interface, see the information provided in Cloud group
command-line interface reference on page 815.
Procedure
1. Access the Cloud Groups window by clicking Configuration > Cloud Groups
from the menu bar. The list of available cloud groups is listed in the left pane.
2. If you select a cloud group in the list, the cloud group details are displayed in
the right pane. See Fields on the Cloud Groups window on page 186 for
more information about the displayed details.
3. If you have administrative access to the cloud group, you can perform the
following tasks:
Editing the description
Click the description to edit it.
Changing the default base image
To change the default base image to be used when deploying virtual
application patterns, select a new image in the Default image field.
This value overrides the default base image that you specify in the
Settings for Default Deploy window. For more information about
deploying virtual application patterns, see Deploying virtual
application patterns on page 736.
Changing the URL
If the URL for the cloud changes, update it in the URL field.
184 IBM SmartCloud Orchestrator 2.3: User's Guide
Discovering the hypervisor and resetting the connections
To discover the hypervisor in the cloud group, click the Discover icon
at the top of the window. This task also resets the latest storage and
network connections in addition to discovering any new hypervisor.
Managing access
You can add or remove access for projects with the Access granted to:
field. You can also change the type of access provided. Valid types of
access are read, write and, all. Use the toggle link to change the type of
access.
Deleting the cloud group
Click the Delete icon at the top of the window.
Note: The cloud group is deleted in the SmartCloud Orchestrator
environment but the related availability zone is not deleted in the
OpenStack environment. If the availability zone still exists in your
OpenStack environment, the cloud group is listed again in the
SmartCloud Orchestrator user interface when the automatic
synchronization occurs. See Configuring OpenStack synchronization
on page 146, for more information about the OpenStack
synchronization. See Managing availability zones in OpenStack, for
more information about deleting availability zones in OpenStack.
Managing availability zones in OpenStack:
Create availability zones in your OpenStack environment to define the SmartCloud
Orchestrator cloud groups.
About this task
An OpenStack availability zone is a logical partition of hosts or volume services
within a single OpenStack deployment. Compute service availability zones are
defined at the host configuration level, providing a method to segment compute
nodes by arbitrary criteria, such as hardware characteristics, physical location, or
task designation.
To create an availability zone in OpenStack, run the following steps:
Procedure
1. On each Compute Node that you want include in the availability zone, add the
following statement in the /etc/nova/nova.conf:
node_availability_zone=availability_zone_name
2. Run the following commands:
service openstack-nova-metadata-api restart
service openstack-nova-compute restart
For more information about the OpenStack services, see the OpenStack
documentation.
Results
The availability zone is created in your OpenStack environment.
You can delete the availability zone by running the following steps on each
Compute Node that is included in the availability zone
1. Ensure there are not any virtual machines running on the Compute Node.
Chapter 4. Administering 185
2. Comment or delete the following statement in the /etc/nova/nova.conf file:
node_availability_zone=availability_zone_name
3. Run the following commands:
service openstack-nova-metadata-api restart
service openstack-nova-compute restart
For more information about the OpenStack services, see the OpenStack
documentation.
Fields on the Cloud Groups window:
You can administer your cloud groups by using the fields on the Cloud Groups
window of the SmartCloud Orchestrator user interface.
To work with a cloud group, first select it from the list in the left panel of the
Cloud Groups window. Selecting a cloud group shows the following fields:
Description
The description of the cloud group.
Created on
Provides the date when the cloud group was created.
Type Displays Managed by OpenStack.
Version
Shows the version of the cloud provider.
Current status
The status of the cloud group. One of the following states is shown:
Connected
The cloud group is connected to the hypervisor manager.
Unable to connect
The cloud group cannot connect to the hypervisor manager.
Discovering hypervisors, networks, and storage devices
The connections for hypervisors in this cloud group are being
reset.
Updated on
Shows the date and timestamp when the cloud group was updated.
Hypervisor type
Displays OpenStack .
Default image
Specifies the base image to be used when deploying virtual application
patterns in the cloud group. This value overrides the default base image
that you specify in the Settings for Default Deploy window. For more
information about deploying virtual application patterns, see Deploying
virtual application patterns on page 736.
URL Specifies the location of the hypervisor manager for the cloud group.
Cloud hardware
Shows the list of hypervisors with the following information:
Status Each hypervisor shows one of the following statuses:
v Started
v Maintenance mode
186 IBM SmartCloud Orchestrator 2.3: User's Guide
v Resetting
v System is powered off
Hypervisors
Provides a linked name of the hypervisor. Clicking the link opens
the Hypervisors window for that hypervisor.
Shared Network
Any shared networks configured for the hypervisor.
Access granted to:
You can add projects in the entry field to allow the users belonging to a
project to work with the cloud group. You can also click Everyone to add
all users. You can specify the access level of the projects and you can
remove any project to whom you previously granted access.
Related tasks:
Administering cloud groups on page 184
In SmartCloud Orchestrator, a cloud group is identified by an availability zone in a
region of the related OpenStack environment.
Related reference:
Cloud group command-line interface reference on page 815
You can work with cloud groups using the SmartCloud Orchestrator command-line
interface.
Administering hypervisors
You can use the SmartCloud Orchestrator user interface to work with the
hypervisors.
About this task
In the SmartCloud Orchestrator user interface, the hypervisors already defined in
the related OpenStack environment are automatically listed.
In your OpenStack environment, you can manage the following hypervisor types:
v KVM
v VMware ESX (through VMware vCenter)
v Power
For more information about defining hypervisors in an OpenStack environment,
see the OpenStack documentation. Detailed information about the hypervisor states
is available in Hypervisor states. To use the command-line interface, see the
information provided in Hypervisor command-line interface reference on page
830.
Procedure
1. Access the Hypervisors window by clicking Configuration > Hypervisors from
the menu bar. The list of available hypervisors is listed in the left pane.
2. If you select a hypervisor in the list, the hypervisor details are displayed in the
right pane. For more information about the displayed details, see Fields on the
Hypervisors window on page 191. You can access the hypervisor details also
clicking the hypervisor name in the Cloud hardware section of the related
cloud group in the Cloud Groups window.
3. If you have administrative access to the hypervisor, you can perform the
following tasks:
Chapter 4. Administering 187
Starting the hypervisor
Click the start icon in the upper right corner of the Hypervisors
window. If the start icon is unavailable, check the Current status field
for information about possible issues with your hypervisor
configuration.
Putting the hypervisor in maintenance mode
Take one of the following actions:
v If there are no started virtual machines that are managed by
SmartCloud Orchestrator, click the Maintenance icon on the upper
right of the window.
v If there are virtual machines that are started, perform the following
steps:
a. Click the Quiesce icon on the upper right of the window. In the
quiesce state, the hypervisor does not accept new deployment
tasks.
b. Click the Maintenance icon on the upper right of the window.
Administering virtual machines
For more information about this task, see Administering virtual
machines with the user interface on page 194.
Changing the network configuration
For more information about configuring the network, see
Administering networks with the user interface on page 204.
Managing the storage devices
For more information about managing the storage devices, see
Administering storage on page 206.
Deleting the hypervisor
Put the hypervisor in maintenance mode and click the Delete icon at
the top of the window.
Note: The hypervisor is deleted in the SmartCloud Orchestrator
environment but not in the OpenStack environment. The hypervisor is
listed again in the SmartCloud Orchestrator user interface when the
automatic synchronization occurs. For more information about the
OpenStack synchronization, see Configuring OpenStack
synchronization on page 146.
Related reference:
Hypervisors REST API on page 966
You can use the representational state transfer (REST) application programming
interface (API) to manage hypervisors.
vCenter management:
Refer to this topic for some basic information on how vCenter is managed in a
SmartCloud Orchestrator environment.
vCenter instances supported by one SmartCloud Orchestrator instance
As of version 2.3, a SmartCloud Orchestrator instance supports a single instance of
vCenter per OpenStack region.
188 IBM SmartCloud Orchestrator 2.3: User's Guide
Using distinct credentials to segment resources in vCenter
SmartCloud Orchestrator can access a given vCenter instance by only one set of
user credentials. See Restricting access to vCenter on page 190 for information on
how to restrict availability of VMware resources.
Modifying the configuration of clusters/servers/datastores assigned for
provisioning
You can control which managed resources are chosen for provisioning in two
ways:
v You can restrict access to a given resource at the VMware authorization level. If
the user name specified when defining the vCenter server to SmartCloud
Orchestrator does not have access to a given resource, it is unavailable to the
SmartCloud Orchestrator platform. If you use this method, no VMs or templates
on the restricted hosts or data stores are detected. This may be a problem
because a user might want to manage some existing VMs but not provision to
the hosting resources where those VMs are located.
v You can control data store placement in a given OpenStack flavor using Nova
extra specifications. To do this, run the nova flavor-key command to get a list of
the defined flavors, and update the ones you want by entering the following
command on one line:
nova flavor-key <flavor name>
set ibm-smartcloud:VMWareDatastoreIncludeList="<list of datastores separated by comma>"
Note: All SmartCloud Orchestrator extra specifications have ibm-smartcloud in
their name.
Discovery of the vCenter resources in SmartCloud Orchestrator
Discovery is performed using Java API for vCenter. SmartCloud Orchestrator is
also registered in order to receive vCenter events which allows for detection of
changes, such as VM movements, starting of a VM.
Discovery of resources in case more clusters and some stand-alone servers are
defined
SmartCloud Orchestrator treats each VMware cluster and stand-alone ESXi hosts as
a single hypervisor, referred to in the user interface by the name of the OpenStack
availability zone to which the openstack-smartcloud service belongs. You can run
nova-manage service list and nova-availability-zone-list to verify it. The
default name is openstack-nova-vmware. Any virtual machines that already exist
are exposed to SmartCloud Orchestrator as virtual machines running under that
openstack-nova-vmware hypervisor. Information on where those machines are
physically located is unavailable.
Virtual machines mobility scenarios
SmartCloud Orchestrator tolerates moving virtual instances in the same VMware
cluster by means of manual exercise of VMware vMotion feature or by means of
automatic migration capability (for example DRS). Moving deployed instances
across VMware clusters is not supported.
Chapter 4. Administering 189
Restricting access to vCenter:
You can use VMware security settings to restrict the vSphere resources available to
SmartCloud Orchestrator users.
Procedure
1. In your vCenter system, create a user that can be used by SmartCloud
Orchestrator to access VMware resources.
2. In your VMware system, create an administrative role for SmartCloud
Orchestrator.
a. In the vSphere Client Home page, click AdministrationRoles > Add roles.
The Add New Role panel opens.
b. Type the Name for the new role.
c. Select at least the privileges described in VMware administrative user
minimum rights.
3. Create/Select one or more datacenter for each region that you are going to
create leveraging the same vCenter.
Note: Two different SmartCloud Orchestrator users accessing same datacenter
is not a supported configuration.
4. In vSphere, assign to the SmartCloud Orchestrator user the newly created role
on the vCenter server (deselecting the propagate option), and assign same role
(selecting the propagate option) on the datacenters and clusters that you want
to use for your cloud.
Results
When the vCenter connection is created using the nova-cloud-create command,
then only the authorized resources are available using this new user ID.
VMware administrative user minimum rights:
This topic describes the minimum rights for an administrative VMware user.
Table 21. The minimum rights of a VMware administrative user
Privilege name Options to be selected
Data store
v Allocate space
v Browse DataStore
v Configure datastore
v Low level file operations
v Move datastore
v Remove datastore
v Remove file
v Rename datastore
v Update virtual machine files
Distributed Virtual Port Group
v Create
v Modify
v Delete
190 IBM SmartCloud Orchestrator 2.3: User's Guide
Table 21. The minimum rights of a VMware administrative user (continued)
Privilege name Options to be selected
Network
v Assign Network
v Configure
v Move Network
Resources
v Assign virtual machine to resource pool
v Create resource pool
v Remove resource pool
Virtual Machine Select all permissions in this group.
Task
v Create task
v Update task
Folder Delete folder
Global
v Act as vCenter
v Cancel Task
v Disable methods
v Enable methods
v Licenses
v Log Event
v Manage custom attribute
v Proxy
v Script action
v Set custom attribute
v Settings
Host Inventory:
v Remove cluster
v Remove host
Fields on the Hypervisors window:
You can administer your hypervisors using the fields on the Hypervisors window
of the SmartCloud Orchestrator user interface.
To work with hypervisors on the SmartCloud Orchestrator user interface, select it
from the list in the left panel of the Hypervisors window. Selecting a hypervisor
shows the following fields:
Type Shows OpenStack the type of the hypervisor.
Version
The type and version of the server.
Current status
The status, or hints about the state, of the hypervisor. If the hypervisor is
not started, this field provides hints about missing configuration that is
necessary before the hypervisor can be started. This field shows the status
of the hypervisor as one of the following states:
v Started
v Maintenance mode
v Resetting
Chapter 4. Administering 191
v Quiesced
v System is powered off
This field might, for example, provide details about a problem if the
hypervisor has been placed in an error state. For more information about
these states, see the Hypervisor states on page 207 information.
In cloud group
The name of the cloud group to which this hypervisor belongs. The name
is a link that can be clicked to view the cloud group details in the Cloud
Groups window.
Performance
Indicates, in a graphic display, the CPU usage and memory usage status.
Initially, only the Hypervisor line is shown. Clicking the show more link
expands the display to show all of the following machine usage:
Hypervisor
The actual processor and memory usage of the started hypervisor.
Included is any extra usage on the hypervisor from a SmartCloud
Orchestrator perspective, such as virtual machines that are not
managed by SmartCloud Orchestrator.
If stopped machines started
This hypothetical status would show the processor usage and
memory usage of the stopped and started hypervisors if the
following criteria were true:
v All active virtual machines were using full resources (in addition
to what they are currently actually using)
v All stopped virtual machines were using all their assigned
resources
If stored machines started
This hypothetical status would show the processor usage and
memory usage of the stopped, started, and archived hypervisors if
the following criteria were true:
v All active virtual machines were using full resources (in addition
to what they are currently actually using)
v All stopped virtual machines were using all their assigned
resources
v All archived virtual machines were using all of their resources
Active unmanaged virtual machines
Provides the processor and memory usage of any virtual machines
that are active but that are unmanaged. Unmanaged virtual
machines are those that were discovered on a hypervisor that was
already running and not started with SmartCloud Orchestrator.
If all unmanaged machines started
This hypothetical status shows what the processor and memory
usage would be if all of the unmanaged virtual machines were
started. Unmanaged virtual machines are those that were
discovered on a hypervisor that was already running and not
started with SmartCloud Orchestrator.
The show more or show less toggle either expands all of these displays or
shows only the Hypervisor status.
192 IBM SmartCloud Orchestrator 2.3: User's Guide
Deployment statistics
Summary information is initially shown in the Deployment statistics
section that provides a summary of deployments. For example, the
Deployment statistics summary line could show: 12 successful, 0 failed, 0
consecutive failures. Click to expand and show the following, more
detailed, information about the deployments on this hypervisor:
Successful deployments
The number of successful deployments on this hypervisor.
Failed deployments
The number of failed deployments on this hypervisor.
Note: This number includes only deployments that failed at
registration stage when the hypervisor is actually involved. Any
deployment that fails at other stages for reasons like, for example,
Not all cloud resources could be reserved or No physical
machines are found for the hypervisor are not included in the
deployment statistics.
Consecutive failures
The number of consecutive failures.
Updated on
The date on which the deployment status was last updated.
History
The summary line in the History section shows the last action performed
on this hypervisor. For example, the History summary line could show:
Maintenance mode (must select a storage to use to start). Click to expand
and show a list of actions performed on the hypervisor, with a time stamp
for each.
Virtual machines
Each virtual system instance contains a set of virtual machines that
represent a physical node in an application server environment. If you are
working with a hypervisor in a cloud group that has been deployed, this
field is available. When cloud groups have been deployed, the Virtual
machines field provides a list of the virtual machines linked to this
hypervisor. Summary information is provided for the total number of
virtual machines and the number of virtual machines that are started.
For information about configuring virtual system instances, see Managing
virtual system instances on page 562.
Networks
The summary line in the Networks section shows the status of the
networks in this hypervisor. For example, the Networks summary line
could show: 3 total, 2 in use, 1 mapped to IPGroups. See Network fields
on the Hypervisor window on page 205 for more information.
Storage devices
Clicking this link expands a list of storage devices that are linked to this
hypervisor. For more information about storage devices, see Storage fields
on the Hypervisor window on page 206.
Chapter 4. Administering 193
Administering virtual machines:
Virtual machines are assigned to and hosted by a hypervisor. You can access the
individual virtual machines using either the SmartCloud Orchestrator user
interface or the command-line interface.
Before you begin
You can administer virtual machines with the user interface or the command-line
interface. To use the command-line interface download and configure the tool. See
Downloading and configuring the command-line interface on page 909 and
Invoking the command-line interface on page 911 for more information.
About this task
With SmartCloud Orchestrator, you can access any of the virtual machines that are
hosted on your hypervisors.
Procedure
Determine the interface you want to work with and see the following information:
v Use the information provided in Administering virtual machines with the user
interface to work with your virtual machines on the user interface.
v Use the information provided in Virtual machines on the command-line
interface on page 899 to work with virtual machines on the command-line
interface.
Results
After completing these steps, you have accessed or managed your virtual
machines.
What to do next
You can work with your hypervisor, the cloud containing it, or your virtual system
instance.
Related reference:
Virtual machines on the command-line interface on page 899
This topic provides a reference for administering virtual machines using the
SmartCloud Orchestrator command-line interface.
Administering virtual machines with the user interface:
Each virtual system instance consists of a set of virtual machines that represent a
physical node in an application server environment. These virtual machines are
assigned to and hosted by a hypervisor. You can access the individual virtual
machines from the Hypervisors window of the user interface.
Before you begin
You must specifically be granted access to the hypervisor you intend to access.
Optionally, you can be assigned the admin role to perform these steps.
194 IBM SmartCloud Orchestrator 2.3: User's Guide
About this task
With SmartCloud Orchestrator, you can access any of the virtual machines that are
hosted on your hypervisors.
Procedure
1. You can access virtual machines from the Hypervisors window by clicking
Configuration > Hypervisors on the menu.
Tip: You can also access virtual machines in a virtual system instance from the
Virtual System Instances window. For more information, see Accessing virtual
machines in your virtual system instance on page 573
2. From the left panel of the Hypervisors window, select the associated
hypervisor. Information about the hypervisor is displayed in the right panel of
the window.
3. From the right panel of the window, expand Virtual Machines by clicking the
expand icon to view a list of the virtual machines that exists on the selected
hypervisor. The number of virtual machines that exist for the hypervisor is
dependent on the number being hosted by the hypervisor. From the list of the
virtual machines included in this hypervisor, you can view both managed and
unmanaged virtual machines. For more detailed information about the fields of
information, see Virtual machine fields on the Hypervisor window on page
198.
4. View the details for your virtual machine. Expand the details for your virtual
machine by clicking the expand icon next to the <virtual_machine_name> for the
virtual machine you want to access.
You can view the CPU and the Memory currently being used by a virtual
machine.
5. Access your virtual machine. Use one of the following procedure to access your
virtual machine:
v Click Login under the SSH column to open a new browser window and
access the virtual machine using SSH. A prompt is displayed to enter user
name and password.
v Click VNC under the Consoles section to access your virtual machine using
Virtual Network Computing (VNC). During pattern creation, the default
setting is for your host operating system to be configured to accept VNC
connections. VNC connections can be disabled by modifying the virtual
machine properties during pattern creation.
v Click WebSphere under the Consoles section to access the WebSphere
Application Server administrative console on your virtual machine.
Important: To access your virtual machine using VNC or to access
theWebSphere Application Server administrative console on your virtual
machine, your virtual machine must be accessible from the machine you are
accessing the user interface. If a firewall is preventing the connection on the
required port, you must open this port to establish a connection. In addition to
this, the DNS server must be correctly configured to resolve the virtual machine
host name. For more information about configuring DNS, see Configuring
DNS for the Workload Deployer IP groups on page 61.
Results
After completing these steps, you have accessed your virtual machine from the
user interface.
Chapter 4. Administering 195
Related tasks:
Administering hypervisors on page 187
You can use the SmartCloud Orchestrator user interface to work with the
hypervisors.
Monitoring your virtual machines:
Each virtual system instance consists of a set of virtual machines that represent a
physical node in an application server environment. These virtual machines are
assigned to and hosted by a hypervisor. You can monitor the details of each of
these virtual machines.
Before you begin
You must specifically be granted access to hypervisor you intend to access.
Optionally, you can be assigned the admin role to perform these steps.
About this task
You can view and monitor the details about each virtual machine by following
these steps.
Procedure
1. From the left panel of the Hypervisors window, select the associated
hypervisor. Information about the hypervisor is displayed in the right panel of
the window.
2. From the right panel of the window, expand Virtual Machines by clicking the
expand icon to view a list of the virtual machines that exists on hypervisor. You
can view the following details for each virtual machine.
CPU This field graphically specifies the percentage of the virtual CPU power
that is currently being used. The number of virtual CPUs available is
determined by the pattern used to create the virtual system. The default
number of virtual CPUs for a virtual machine is 1.
Memory
This field displays a graph that specifies the percentage of the memory
that is currently being used by the virtual machine. The amount of
memory available is determined by the pattern used to create the
virtual system instance associated with this virtual machine. The
default amount of virtual memory for a virtual machine is 2048 MB.
SSH This field provides the Login link that you can click to log in to your
virtual machine using Secure Shell (SSH).
Actions
This field displays the available actions for a virtual machine. Actions
that are not available for a specific virtual machine are not active. Click
the Manage link to show or hide the available actions for the virtual
machine.
Move This action is not currently supported.
Start If a virtual machine is stopped, then it can be restarted using
this action.
Stop If a virtual machine is running, then it can be stopped using the
stop action.
196 IBM SmartCloud Orchestrator 2.3: User's Guide
Note: If your application is running DB2, and the application is
stopped and an operation that cannot be interrupted (RESTORE
DATABASE, for example) is forced, the operation must be
successfully restarted before the database becomes available
again. See the DB2 information center topic, STOP DATABASE
MANAGER command, for more information.
Delete A virtual machine can be deleted to release the resources
associated with it.
Take Over
You can take over a virtual machine that was not provisioned
by using SmartCloud Orchestrator. For more information, see
Importing virtual machines.
3. Expand the details for a virtual machine by clicking the expand icon next to the
<virtual_machine_name>.
4. View your virtual machine details. For more information about the fields for
each virtual machine, see Virtual machine fields on the Hypervisor window
on page 198.
Results
After you have completed these steps, you have reviewed the details for your
virtual machines.
What to do next
When you have your virtual machines ready, you can work with the hypervisor.
Related information:
STOP DATABASE MANAGER command
Importing virtual machines:
You can import a virtual machine that was not provisioned by using SmartCloud
Orchestrator.
Before you begin
You must be assigned the admin role to perform these steps.
About this task
You can import unmanaged virtual machines hosted by an hypervisor in the
SmartCloud Orchestrator environment.
Note: The imported virtual machine does not affect the quota usage.
To import an unmanaged virtual machine, perform the following steps:
Procedure
1. From the left panel of the Hypervisor window, select the hypervisor currently
hosting the virtual machines to be imported.
2. Expand the list of virtual machines to view by clicking the expand icon next to
Virtual Machines.
Chapter 4. Administering 197
3. Optional: You can expand the details for a virtual machine by clicking the
expand icon next to the <virtual_machine_name>.
4. Choose the virtual machine, or groups of virtual machines, to be imported. You
can import only unmanaged virtual machines.
Importing a single virtual machine
a. From the list of virtual machines, click the Manage link (under the
Actions column) beside any individual virtual machine to view the
actions you can perform.
b. Click the Import the virtual machine icon to import that single
virtual machine.
Importing a selection of virtual machines
a. From the list of virtual machines, check the check box on the far
right column beside any virtual machines you want to import as a
group. Likewise, you can remove the check from any virtual
machines you decide not to import.
b. Click the Group Actions link at the top right of the list of virtual
machines listing to display the available actions.
c. Click the Import selected virtual machines icon to import any
selected virtual machines.
Importing all the virtual machines
a. From the list of virtual machines, check the check box in the far
right column of the header row to select all of the virtual machines
in the list.
b. Click Group Actions to display the actions you can perform for the
virtual machines.
c. Click the Import selected virtual machines icon.
Results
After you completed these steps, you can manage the virtual machine in the
Imported Virtual Machines window. To access the Imported Virtual Machines
window, click Instances > Virtual Machines.
In the Imported Virtual Machines window, you can see details about virtual
machines and you can start, stop, or delete the virtual machine that you select.
Virtual machine fields on the Hypervisor window:
You can work with the virtual machines that are associated with a hypervisor
using the Virtual machines panel on the Hypervisors window.
Virtual machine summary fields
The Virtual machines section is shown on the right panel of the Hypervisors
window when a specific hypervisor is selected. Before being expanded, the Virtual
machines section shows a status summary line. The status line shows the total
number of virtual machines for this hypervisor, and the number of virtual
machines in each state. For example, the status bar could read: 4 total - 1 deleted -
3 started - 1 failed to indicate the total number of virtual machines in the
hypervisor and how many are in which state. When expanded, the Virtual
machines section lists the virtual machines in the hypervisor.
198 IBM SmartCloud Orchestrator 2.3: User's Guide
The following check boxes allow you to filter the virtual machines listed:
Show virtual machines that are
started only
Click this check box to show, in the listing of virtual machines,
only the virtual machines on this hypervisor that are started.
unmanaged
Click this check box to show, in addition to the managed machines
in the listing of virtual machines, the virtual machines on this
hypervisor that are not managed by SmartCloud Orchestrator.
Virtual machines, displayed on the Hypervisors window, can be
either managed by SmartCloud Orchestrator or unmanaged. Some
information is available about the unmanaged virtual machines
that were discovered with the hypervisor. More information is
available about the managed virtual machines that were started by
this SmartCloud Orchestrator.
You can import an unmanaged virtual machine to make it
managed by SmartCloud Orchestrator. For more information about
importing virtual machines, see Importing virtual machines on
page 197.
deleted
Click this check box to show, in addition to the current machines in
the listing of virtual machines, the virtual machines that have been
deleted from this hypervisor.
When the Virtual machines section is expanded, the following fields are provided
for each virtual machine listing, without expanding the details for each virtual
machine:
Name The name of the virtual machine that is hosted by the hypervisor being
viewed. If an environment profile was used, then the virtual machine name
could have been provided by the user who provided the environment
profile.
CPU Displays, graphically and numerically, the percentage of available
processor being used by this virtual machine.
Memory
Provides the graphic and numeric percentage of available memory being
used by this virtual machine.
SSH Clicking the Login link opens a dialog to log in to an SSH session. This
link is not available for virtual machines that were imported.
Actions
Clicking the Manage link under this column heading for any virtual
machine displays or hides the following set of icons to work with the
individual virtual machine:
Move This action is not currently supported.
Start If it is stopped, starts the virtual machine.
Stop If it is started, stops the virtual machine.
Delete If you have permission, you can delete the virtual machine.
Import
You can import a virtual machine that was not provisioned by
Chapter 4. Administering 199
using SmartCloud Orchestrator. For more information, see
Importing virtual machines on page 197.
Check box
Checking the check box in the header of this column selects all of the
virtual machines that have not been deleted. Clearing the check box in the
header row also clears all of the virtual machines in the listing. Use this
check box with the Group Actions link to apply an action to the selected
group of virtual machines.
Group Actions
Select this check box to apply an action to the group of virtual machines
selected. Actions can be applied to all of the virtual machines that have not
been deleted or to a selected group of virtual machines.
General information
When the view of any individual virtual machine is expanded, the General
information section provides basic information about that virtual machine. The
fields displayed in this section are different for managed and unmanaged virtual
machines.
The following fields are shown for managed virtual machines:
Created on
Specifies the time and the date the virtual machine was created. This field
is automatically generated.
From virtual image
Specifies the virtual image that was used when creating this virtual
machine by providing a link to that virtual image in the catalog. Clicking
the link displays the details for that virtual image.
Part name
The name of the part.
Current status
Specifies the status of the virtual machine.
Updated on
Specifies the time and date of the last change to the virtual machine.
In virtual system
Specifies the virtual system instance in which this virtual machine
represent a physical node (in an application server environment). The
virtual system instance name is a link. You can click the link to display
details about the virtual system instance in which this virtual machine
resides.
In cloud group
Specifies the cloud group where this virtual machine is located by
providing a link to the Cloud Groups panel. You can click the link to
display the details of the cloud group where this virtual machine is
running.
Registered as
Specifies how the virtual machine is registered on the hypervisor.
Stored on
Specifies the storage device associated with this virtual machine.
200 IBM SmartCloud Orchestrator 2.3: User's Guide
In virtual application
Specifies the virtual application that contains this virtual machine.
The following fields are shown for unmanaged virtual machines:
Registered as
Specifies how the virtual machine is registered on the hypervisor.
Current status
Specifies the status of the virtual machine.
Hypervisor
Specifies the hypervisor where the virtual machine is running.
Virtual CPU count
A numeric count of the CPU detected.
CPU shares on host
A numeric representation of the shares of CPU detected on the host.
CPU shares consumed on host
A numeric representation of the shares of CPU that the host has actually
used.
Virtual memory (MB)
A numeric representation of the virtual memory detected, in MB.
Memory consumed on host
A numeric representation of the memory detected as actually having been
used on the host.
Hardware and network
If the virtual machine is managed by SmartCloud Orchestrator, the Hardware and
network section is shown. If the virtual machine is unmanaged, this information is
not available.
Virtual CPU count
This field specifies the number of CPU this virtual machine represents.
This value is specified in the pattern that was deployed to create the
virtual system instance. See Working with virtual system patterns on
page 511 for more details on the pattern options.
SSH public key
The name of, and a link to, the public key.
Network interface
The network interface address.
Multiple pairs of network interface and MAC address definitions show
multiple network interface controllers (NICs) defined. You could see a
default NIC and add-on NICs.
MAC address
Specifies the Media Access Control (MAC) address of the virtual machine.
Multiple pairs of network interface and MAC address definitions show
multiple NICs defined. You could see a default NIC and add-on NICs.
Chapter 4. Administering 201
Operating System
If the virtual machine is managed by SmartCloud Orchestrator, the Operating
System section is shown. If the virtual machine is unmanaged, this information is
not available.
Name Specifies the type of operating system that is running on the virtual
machine.
Type Shows the specific variety of the operating system that is running on the
virtual machine.
Version
Specifies the equivalent of the command uname - a for the operating
system on the virtual machine.
Script Packages
If the virtual machine is managed by SmartCloud Orchestrator, the Script Packages
section is shown. If the virtual machine is unmanaged this information is not
available.
This field specifies any script packages that have been run on this virtual machine.
If any script packages have been run for this virtual machine, then links to the
associated log files are also included. For more information about script packages,
see Managing script packages on page 234.
If a script is user initiated, meaning the executes attribute is set as when I initiate it,
then the start icon is displayed next to the script name. Click the icon to run the
script. There is no limit on the number of times a script is run using this method.
Scripts in this section can include add-ons. For more information about add-on
scripts, see Managing add-ons on page 254.
Consoles
If the virtual machine is managed by SmartCloud Orchestrator, the Consoles
section is shown. If the virtual machine is unmanaged this information is not
available.
This field provides links to access your virtual machine. For more information
about accessing your virtual machines, see Administering virtual machines on
page 194.
Related tasks:
Administering virtual machines on page 194
Virtual machines are assigned to and hosted by a hypervisor. You can access the
individual virtual machines using either the SmartCloud Orchestrator user
interface or the command-line interface.
202 IBM SmartCloud Orchestrator 2.3: User's Guide
Administering networks:
You can administer networks using either the SmartCloud Orchestrator user
interface or the command-line interface.
Before you begin
SmartCloud Orchestrator can be run on two or more networks.
Note: When you are setting up an ESX network, select the default port group.
Selecting the default port group ensures that the IP groups you assign to networks
are associated with the correct NIC card. If you select incorrect network settings,
you receive no verification that you are setting up the IP group for the correct NIC
card. Your deployments then fail.
You can administer networks with the user interface or the command-line
interface. To use the command-line interface download and configure the tool. See
Downloading and configuring the command-line interface on page 909 and
Invoking the command-line interface on page 911 for more information.
About this task
You can provide network management and structure using the SmartCloud
Orchestrator to work with network resources, such as IP addresses within IP
groups. The simplest setup is to use one 24 bit subnet for the SmartCloud
Orchestrator, the hypervisors, and the virtual system instances.
Procedure
Determine the interface you want to work with and see the following information:
v Use the information provided in Administering networks with the user
interface on page 204 to work with networks on the user interface.
v Use the information provided in Network command-line interface reference on
page 843 to work with networks on the command-line interface.
Related tasks:
Building the cloud with topology resources on page 183
You can build clouds using your existing resources, for example hypervisors,
networks and storage, with SmartCloud Orchestrator. SmartCloud Orchestrator
manages these resources in the cloud.
Administering networks with the user interface on page 204
You can specify network information for hypervisors using the SmartCloud
Orchestrator user interface.
Related reference:
Network command-line interface reference on page 843
You can work with the network resource objects on the SmartCloud Orchestrator
command-line interface.
Networks REST API on page 991
You can use the representational state transfer (REST) application programming
interface (API) to manage networks.
Chapter 4. Administering 203
Administering networks with the user interface:
You can specify network information for hypervisors using the SmartCloud
Orchestrator user interface.
Before you begin
You must have administrative access to edit or provide hypervisor network
information.
About this task
You can view and configure the connection characteristics of a hypervisor (the
network information) on the Hypervisors window. For more information about the
Hypervisors window, see Administering hypervisors on page 187. Multiple
networks can be defined for a hypervisor and at least two networks are required.
Hypervisor networks cannot be manually defined to SmartCloud Orchestrator.
Hypervisor networks are automatically discovered when the hypervisor is defined
and you accept the security certification. You can also accept the security
certification when you reset the storage and network connections of the hypervisor.
Procedure
1. From the left panel of the Hypervisors window, select the hypervisor for which
to configure the network settings. If you have administrative access to a
hypervisor, you can edit it, or you can create a new one.
2. Put the hypervisor in maintenance mode. See Administering hypervisors on
page 187 for more information.
3. In the right panel, expand the Networks link.
4. Select the networks you want to include. Click the In use box for any networks
to be used. By default, when you add a hypervisor, none of the networks are
selected. To start the hypervisor, at least one network must be selected.
You can also remove the check from the In use box for any networks you do
not want to include.
Note: For VMware clusters, only the networks that are common to all the ESX
servers in the cluster are displayed. If the message No network found or no
common network found is displayed, ensure that there is at least one network
that is commonly defined to each ESX server in the cluster.
5. Expand the network you want to configure.
6. Edit the required IP group information for the network. See Administering IP
groups and IP addresses on page 208 for more information about IP groups.
SmartCloud Orchestrator cannot detect incorrect settings for the network;
therefore, be sure that you specify the correct information.
Note:
v An IP group must be specified for at least one network before the hypervisor
can be started.
v Assigning an empty IP group results in multiple network interface
controllers (NICs).
Related tasks:
Building the cloud with topology resources on page 183
You can build clouds using your existing resources, for example hypervisors,
networks and storage, with SmartCloud Orchestrator. SmartCloud Orchestrator
204 IBM SmartCloud Orchestrator 2.3: User's Guide
manages these resources in the cloud.
Related reference:
Network command-line interface reference on page 843
You can work with the network resource objects on the SmartCloud Orchestrator
command-line interface.
Network fields on the Hypervisor window:
You can work with the networks that are associated with a hypervisor using the
Networks panel on he Hypervisors window.
Network summary fields
The Networks section is shown on the right panel of the Hypervisors window
when a specific hypervisor is selected. Before being expanded, the Networks
section shows a status summary line. The status summary line shows the total
number of networks for this hypervisor, the number in use, and the number that
have an IP group assigned. For example, the status bar could read: 4 total, 2 in
use, 1 mapped to IPGroups to indicate the total number of networks in the
hypervisor and how many are in which state. When expanded, the Networks
section lists the networks in the hypervisor by name and shows whether or not the
network is in use. Expand an individual network to see the following fields for
each network in the list.
Note: For VMware clusters, only the networks that are common to all the ESX
servers in the cluster are displayed. If the message No network found or no common
network found is displayed, ensure that there is at least one network that is
commonly defined to each ESX server in the cluster.
In use Indicates whether the network attachment on this hypervisor is in use.
Click this check box to put a network in use.
VLAN The virtual local area network (VLAN), as defined for the hypervisor
network element, on the hypervisor console. The VLAN value cannot be
changed in SmartCloud Orchestrator; it is reported here for convenience.
IP group
Shows the IP group to be used with the network element of a hypervisor if
one has been selected. If an IP group has not been selected and the
hypervisor is in maintenance mode, use this field to select one. For more
information about IP groups, see Administering IP groups and IP
addresses on page 208.
Note: An IP group must be specified for at least one network in the
hypervisor before the hypervisor can be started.
Shared Network
Specifies if the network is shared in the cloud group.
Related tasks:
Administering networks with the user interface on page 204
You can specify network information for hypervisors using the SmartCloud
Orchestrator user interface.
Chapter 4. Administering 205
Administering storage:
You can administer storage using the SmartCloud Orchestrator user interface or the
command-line interface.
Before you begin
To use the command-line interface download and configure the tool. See
Downloading and configuring the command-line interface on page 909 and
Invoking the command-line interface on page 911 for more information.
About this task
Multiple storage devices can be defined for a hypervisor. Hypervisor storage
cannot be manually defined to SmartCloud Orchestrator. It is automatically
discovered when the hypervisor is defined or when you reset the connections. You
can administer storage specifications with the user interface or the command-line
interface tool.
Procedure
Determine the interface you want to work with and see the following information:
v Use the information provided in Storage fields on the Hypervisor window to
work with storage specifications on the user interface.
v Use the information provided in Storage command-line interface reference on
page 882 to work with storage specifications on the command-line interface.
Related tasks:
Building the cloud with topology resources on page 183
You can build clouds using your existing resources, for example hypervisors,
networks and storage, with SmartCloud Orchestrator. SmartCloud Orchestrator
manages these resources in the cloud.
Related reference:
Storage REST API on page 1006
You can use the representational state transfer (REST) application programming
interface (API) to manage storage.
Storage fields on the Hypervisor window:
You can work with the storage devices in use with the hypervisor using the
Storage panel on the Hypervisors window.
Storage fields
The Storage section is shown on the right panel of the Hypervisors window when
a specific hypervisor is selected. Before being expanded, the Storage section shows
a status summary line. The status summary line shows the total number of storage
devices for this hypervisor, the number in use, and a graphical representation of
what is in use Right now and what is Reserved. For example, the status bar could
read: 3 total, 1 in use and the graphical bars to indicate the amount currently in
use and what is reserved. This status indicates the total number of storage devices
in the hypervisor and how many are in which state. The following fields
graphically display summarized information about the storage devices associated
with this hypervisor:
206 IBM SmartCloud Orchestrator 2.3: User's Guide
Right now
The current percentage of storage device usage.
Reserved
The percentage of storage device space that has been reserved.
When expanded, the Storage section lists the storage devices in the hypervisor by
name. Expand an individual storage device to see the following fields for each
storage device in the list.
In use Indicates whether the storage device attachment on this hypervisor is in
use. It is always checked.
Device type
The type of storage device. For example, VMFS.
Used space (MB)
The space used on the storage device, reported in megabytes.
Reserved space (MB)
The space that has been reserved, but not yet used, on the storage device,
reported in megabytes.
Free space (MB)
The free space available on the storage device, reported in megabytes.
Total space
The total space on the storage device, reported in megabytes.
Unique ID
The identification string for the storage device.
Shared by other hypervisors
Displays the hypervisors, if any, for which this storage device is also
associated.
Related tasks:
Administering storage on page 206
You can administer storage using the SmartCloud Orchestrator user interface or the
command-line interface.
Hypervisor states:
SmartCloud Orchestrator manages hypervisors from the user interface or the
command-line interface.
In SmartCloud Orchestrator, hypervisors can be in the following states:
Maintenance mode
The hypervisor is not running or accepting work and can be configured.
You can reset the resource connections only when the hypervisor is in this
state. Hypervisors with virtual system instances that are started cannot be
put in maintenance mode until all virtual system instances are stopped.
Resetting
The hypervisor is resetting the storage and network information. This
information is being reset for one of the following reasons:
v A user has requested this action
v The security certificate is being obtained for the first time
The resetting state is a special case of the maintenance mode state.
Chapter 4. Administering 207
Started
The hypervisor is able to accept work and might already be running work.
It cannot be configured in this state.
Disconnected
A hypervisor enters the disconnected state when it is in the started state
and a temporary disruption occurs in the communication between
SmartCloud Orchestrator and the hypervisor. If the disruption is resolved
within approximately 15 minutes, the hypervisor goes back into the started
state in the console, with no user intervention required.
Quiesce
The hypervisor is in a suspended state and it is not accepting new
deployments.
Failed A failure occurred and has been reported. This status usually indicates a
connection problem between SmartCloud Orchestrator and the hypervisor.
In this case, the following status message is also displayed: The hypervisor
cannot be deleted due to existing instances.
A failed state also results if sufficient information cannot be gathered by
the hypervisor like the processor model or metric information.
Administering IP groups and IP addresses
IP groups contain IP addresses that are managed separately within each group.
Before you begin
You must have administrative access to the range of IP addresses to use with
SmartCloud Orchestrator. If you are creating IP groups, you must also decide how
you want to group these IP addresses into IP groups.
About this task
In SmartCloud Orchestrator, the networks defined in your OpenStack environment
are automatically listed as IP groups named region-name_network-name, where
region-name is the name of the region where the network named network-name is
defined. For more information about managing networks in OpenStack, see
Configuring Networking on the Compute Node in the OpenStack documentation.
Note: For OpenStack networks that do not use a DHCP server, the number of IP
addresses that are automatically listed for each IP group is limited to 20 by default.
For more information about modifying this number, see Configuring OpenStack
synchronization on page 146.
In addition to the IP groups defined in OpenStack, you can create and manage IP
groups directly in your SmartCloud Orchestrator environment.
You can administer IP groups with the SmartCloud Orchestrator user interface or
the command-line interface. If you use the command-line interface, download and
configure it. For more information, see Downloading and configuring the
command-line interface on page 909 and Invoking the command-line interface
on page 911.
Procedure
1. See the information about IP groups and IP addresses. Information about how
IP groups contain IP addresses is available in IP groups on page 209.
2. Determine the interface with which to work.
208 IBM SmartCloud Orchestrator 2.3: User's Guide
v To work with the user interface, use the information provided in
Administering IP groups and IP addresses with the user interface on page
210.
v To work with the command-line interface, use the information provided in
IP command-line interface reference on page 834 and IP group
command-line interface reference on page 838.
Related tasks:
Building the cloud with topology resources on page 183
You can build clouds using your existing resources, for example hypervisors,
networks and storage, with SmartCloud Orchestrator. SmartCloud Orchestrator
manages these resources in the cloud.
Related reference:
IP command-line interface reference on page 834
You can work with IP addresses, using the IPs and IP objects on the SmartCloud
Orchestrator command-line interface.
IP group command-line interface reference on page 838
You can work with IP groups on the SmartCloud Orchestrator command-line
interface using the IPgroups and IPgroup objects and attributes.
IP groups REST API on page 977
You can use the representational state transfer (REST) application programming
interface (API) to manage IP groups.
IP addresses REST API on page 973
You can use the representational state transfer (REST) application programming
interface (API) to manage IP addresses.
IP groups:
SmartCloud Orchestrator manages IP groups, or collections of IP addresses.
An IP group is a range of IP addresses that you can select to use them with
specific hypervisors. For example, you might split 100 IP addresses into four blocks
of 25 IP addresses to be used by four departments in your enterprise. Though
these IP addresses are all on the same real subnet in this example, creating the IP
groups enables you to manage them separately and to ensure that they are only
used by SmartCloud Orchestrator for a particular purpose. Alternatively, for IPv4
networks, you can create IP groups that obtain the IP addresses from a DHCP
server.
In SmartCloud Orchestrator, the networks defined in your OpenStack environment
are automatically listed as IP groups named region-name_network-name, where
region-name is the name of the region where the network named network-name is
defined. For more information about managing networks in OpenStack, see
Configuring Networking on the Compute Node in the OpenStack documentation.
Note: For OpenStack networks that do not use a DHCP server, the number of IP
addresses that are automatically listed for each IP group is limited to 20 by default.
For more information about modifying this number, see Configuring OpenStack
synchronization on page 146.
In addition to the IP groups defined in OpenStack, you can create and manage IP
groups directly in your SmartCloud Orchestrator environment.
IP addresses are only accessible to SmartCloud Orchestrator through IP groups.
When you create an IP group that obtains IP addresses from an IP address pool,
Chapter 4. Administering 209
you give it an address and a netmask that defines the IP group. You then define a
pool of IP addresses within the subnet (an IP group within a subnet) that are
available to SmartCloud Orchestrator. IP groups enable you to partition a subnet.
Therefore, blocks of IP addresses from the subnet can be assigned to a hypervisor,
department, or other entity. You can also partition the subnet into smaller
groupings. You can create IP groups with duplicate subnet information. You can
enter IP addresses by specifying a range in the user interface or the command-line
interface.
By default, SmartCloud Orchestrator uses all available IP addresses from the IP
group.
If you do not enter any IP address and you are not using an IP group that obtains
IP addresses from a DHCP server, you cannot deploy virtual systems to
hypervisors using that IP group. Messages alert you about possible errors.
The IP group must have available addresses for the maximum number of virtual
machines that you want to access in the cloud. To enhance performance, a
minimum of 10 available IP addresses is required, however for any significant
cloud deployments, substantially more available IP addresses are needed. To
determine how many IP addresses you need, you can count the number of virtual
image parts. Each virtual image part is equal to one unique IP address.
Related tasks:
Building the cloud with topology resources on page 183
You can build clouds using your existing resources, for example hypervisors,
networks and storage, with SmartCloud Orchestrator. SmartCloud Orchestrator
manages these resources in the cloud.
Administering IP groups and IP addresses with the user interface:
You can create, edit, or delete IP groups using the SmartCloud Orchestrator user
interface. You can also add IP addresses to an IP group or remove IP addresses
from an IP group.
Before you begin
You must have administrative access to the range of IP addresses to use with
SmartCloud Orchestrator.
About this task
In SmartCloud Orchestrator, the networks defined in your OpenStack environment
are automatically listed as IP groups named region-name_network-name, where
region-name is the name of the region where the network named network-name is
defined. For more information about managing networks in OpenStack, see
Configuring Networking on the Compute Node in the OpenStack documentation.
Note: For OpenStack networks that do not use a DHCP server, the number of IP
addresses that are automatically listed for each IP group is limited to 20 by default.
For more information about modifying this number, see Configuring OpenStack
synchronization on page 146.
In addition to the IP groups defined in OpenStack, you can create and manage IP
groups directly in your SmartCloud Orchestrator environment.
To work with IP groups and IP addresses, perform the following steps:
210 IBM SmartCloud Orchestrator 2.3: User's Guide
Procedure
1. Open the IP Groups window by clicking Configuration > IP Groups from the
menu bar.
2. Determine the task. You can perform the following tasks with the SmartCloud
Orchestrator user interface:
Adding an IP group
Add an IP group and define ranges of IP addresses using the
instructions provided in Creating an IP group.
Editing IP groups
If you have administrative access, you can edit IP groups using the
instructions provided in Adding IP addresses and IP groups on page
214.
Deleting IP groups
If you have administrative access, you can delete IP groups from a
hypervisor using the instructions provided in Deleting IP addresses
and IP groups on page 215.
Results
You have created, edited, or deleted your IP group or groups.
What to do next
When you have created the IP group or groups, define them to the hypervisor. See
Administering hypervisors on page 187 for more information about adding IP
groups to the hypervisor.
Related reference:
IP command-line interface reference on page 834
You can work with IP addresses, using the IPs and IP objects on the SmartCloud
Orchestrator command-line interface.
IP group command-line interface reference on page 838
You can work with IP groups on the SmartCloud Orchestrator command-line
interface using the IPgroups and IPgroup objects and attributes.
IP groups REST API on page 977
You can use the representational state transfer (REST) application programming
interface (API) to manage IP groups.
IP addresses REST API on page 973
You can use the representational state transfer (REST) application programming
interface (API) to manage IP addresses.
Creating an IP group:
You can create an IP group and specify a range of IP addresses, using the
SmartCloud Orchestrator user interface.
Before you begin
You must have administrative access to the range of valid IP addresses to add to
the IP group you are creating.
Chapter 4. Administering 211
Attention: Do not use host names in the .local domain, for example
machine1.mycompany.local. Ensure that the host names for your IP addresses are in
a domain other than .local. SmartCloud Orchestrator does not support host
names in the .local domain.
About this task
IP addresses are only accessible to SmartCloud Orchestrator when they are
included in IP groups. When you create an IP group that does not obtain IP
addresses from a DHCP server, you must specify an address and a netmask that
defines the IP group. Then you define a pool of IP addresses within the IP group
that are available to hypervisors which are also defined to SmartCloud
Orchestrator. SmartCloud Orchestrator validates the information and creates the IP
group.
Procedure
1. From the upper right of the left panel of the IP Groups window, click the Add
icon.
2. Provide the required information. Provide the following information in the
Describe the IP group you want to add window:
Name Enter a unique IP group name to represent and identify the IP group.
Version
Select IPv4 or IPv6 from the list to specify the version.
Attention: Workloads that require IP caching must be deployed to
cloud groups with only IPv4 IP groups.
Obtain IP addresses from
Select DHCP Server or IP Address Pool to specify from where the IP
group obtains the IP addresses available to the hypervisors. You can
select DHCP Server only for IPv4 IP groups.
3. If you specified to obtain IP addresses from an IP address pool or you are
creating a IPv6 IP group, provide the following information:
Subnet address
Enter a valid subnet address. This subnet address is associated with the
IP group represented as a string in dotted decimal notation, for
example: 192.168.98.0.
Netmask
If you are using IPv4, enter a value for the netmask. This network mask
is associated with the subnet address of the IP group that is represented
as a string in dotted decimal notation, for example: 255.255.255.0.
Gateway
Enter a gateway name. This default gateway is associated with the IP
group represented as a string in dotted decimal notation. For example,
if you are adding IPv4 or IPv6 IP addresses, the IP address might be
192.168.98.1. The gateway information is required.
Note: The gateway must be an IP address that can be resolved by the
address resolution protocol (ARP), even if the network itself is not
routed.
Primary DNS
Provide the primary Domain Name System (DNS) value for the IP
212 IBM SmartCloud Orchestrator 2.3: User's Guide
group. This DNS server is used for the IP group represented as a string
in dotted decimal notation, for example: 192.168.98.2.
Note: If the IP addresses for the DNS servers are not set up correctly,
the deployment can fail. The failure is due to the SSH connection with
the virtual machine failing.
Secondary DNS
Optionally, you can add a secondary DNS value for the IP group. This
secondary DNS server is used for the IP group represented as a string
in dotted decimal notation, for example: 192.168.98.2.
4. Click OK. The left panel of the IP Groups window shows the name of the IP
group you created. The right panel shows the configuration information.
5. If the IP group obtains IP addresses from an IP address pool, add the range of
IP addresses using one of the following methods:
v Add a range of IP addresses on the right panel of the IP Groups window in
the fields provided in IP Addresses: > Add range. Use the two entry fields
to specify the first and last IP addresses in the range of IP addresses to
include in the IP group. Click Add to add the IP address range.
v Add IP addresses as host names instead of the actual IP addresses. Clicking
Add Host Names provides an entry field in which you can enter the
space-delimited list of host names. When a host name is specified for an IP
address, the host name resolves to the IP address. However, what is entered
is what is stored. Therefore, if you enter the host name then the host name is
stored and not the IP address to which it resolves. If any of the host names
you enter cannot be resolved to an IP address, then a warning message is
shown beside any entry that cannot be resolved. If a host name is resolved to
an IP address but the IP address is not valid for the specified subnet, then an
error message is shown and the host name is not added to the IP Group.
Note: If an IP address cannot be resolved, it is marked with a red exclamation
point. The exclamation point indicates an error with the IP addresses you
entered that you must correct.
6. Optional: Add more addresses. Optionally, you can add more IP address ranges
to the IP group by repeating this procedure.
Results
You have defined your IP group with a range or ranges of IP addresses.
What to do next
Assign the IP group to the hypervisor using the Hypervisor panel as described in
Administering hypervisors on page 187.
Related reference:
IP command-line interface reference on page 834
You can work with IP addresses, using the IPs and IP objects on the SmartCloud
Orchestrator command-line interface.
IP group command-line interface reference on page 838
You can work with IP groups on the SmartCloud Orchestrator command-line
interface using the IPgroups and IPgroup objects and attributes.
IP groups REST API on page 977
You can use the representational state transfer (REST) application programming
interface (API) to manage IP groups.
Chapter 4. Administering 213
IP addresses REST API on page 973
You can use the representational state transfer (REST) application programming
interface (API) to manage IP addresses.
Adding IP addresses and IP groups:
You can add ranges of IP addresses to an IP group that obtains IP addresses from
an IP address pool, or add an IP group to a hypervisor. You can use the
SmartCloud Orchestrator user interface to add IP addresses or IP groups.
Before you begin
You must have created the IP group you want to edit or have administrative access
to it.
About this task
IP addresses are only accessible to SmartCloud Orchestrator when they are
included in IP groups. Edit an IP group to add the pools of IP addresses within the
IP group that are available to SmartCloud Orchestrator hypervisors. You can also
add or change the hypervisor to which this IP group is assigned.
Procedure
v Add IP addresses. Use the following steps to add IP addresses to an existing IP
group:
1. Select an IP group that obtains IP addresses from an IP address pool. From
the left panel of the IP Groups window, select the IP group to be edited.
2. Enter a range of IP addresses. On the right panel of the IP Groups window,
add IP addresses under the IP Addresses: section. Use one of the following
methods to add IP addresses under the Add range label:
Use the two entry fields, specifying the first and last IP addresses, and the
Add button to add a range of IP addresses.
Use the entry field and the Add Host Names button to enter space
delimited host names. Host names added are resolved to IP addresses and
checked for validity.
Added IP addresses are shown in the IP address list. If the IP address cannot
be located, an error message is shown beside the entry in the IP address list.
Likewise, if the host name cannot be resolved to an IP address, an error
message is shown beside the entry in the IP address list.
3. Add the IP addresses.
Note: If an IP address cannot be resolved, it is marked with a red exclamation
point. This icon indicates an error with the IP addresses you entered that you
must correct.
v Add an IP group to a hypervisor. You can add an IP group to a hypervisor from
the Hypervisors window using the following steps:
1. Select the hypervisor. Select the hypervisor in the left panel of the
Hypervisors window.
2. Put the hypervisor in maintenance mode. See Administering hypervisors
on page 187, for more information.
3. Select the IP group. Select the IP group to add under Networks > <network
name> > IP Group.
214 IBM SmartCloud Orchestrator 2.3: User's Guide
Results
You edited your IP group or changed the hypervisor to which it is assigned.
What to do next
When you have edited any needed IP group or groups defined to the hypervisor,
and hypervisor configuration is complete, you can start the hypervisor. You can
then run the hypervisor in the cloud. See Administering hypervisors on page 187
for more information about configuring the hypervisor.
Related tasks:
Administering hypervisors on page 187
You can use the SmartCloud Orchestrator user interface to work with the
hypervisors.
Related reference:
IP command-line interface reference on page 834
You can work with IP addresses, using the IPs and IP objects on the SmartCloud
Orchestrator command-line interface.
IP group command-line interface reference on page 838
You can work with IP groups on the SmartCloud Orchestrator command-line
interface using the IPgroups and IPgroup objects and attributes.
IP groups REST API on page 977
You can use the representational state transfer (REST) application programming
interface (API) to manage IP groups.
IP addresses REST API on page 973
You can use the representational state transfer (REST) application programming
interface (API) to manage IP addresses.
Deleting IP addresses and IP groups:
You can delete IP addresses from an IP group that obtains IP addresses from an IP
address pool, delete an IP group, or remove an IP group from a hypervisor. You
can use the SmartCloud Orchestrator user interface to delete IP addresses or IP
groups.
Before you begin
You must have created the IP groups and hypervisors or have administrative
access to them to edit these resources.
About this task
IP addresses are only accessible within IP groups. You can delete IP addresses from
IP groups or delete the entire IP group. When you delete an IP group you delete
the pool of IP addresses within the IP group that was available to SmartCloud
Orchestrator. You can also remove the IP group from the hypervisor. If you remove
the IP group from a hypervisor, the IP group is still available to use with another
hypervisor.
Procedure
v Remove IP addresses from an IP group that obtains IP addresses from an IP
address pool. To continue to use an IP group but to remove an IP address it
contains, use the following steps:
1. Select the IP group to be edited in the left panel of the IP Groups window.
Chapter 4. Administering 215
2. Locate the IP address. If it is not displayed, click the show more link at the
bottom of the list of IP addresses.
3. Remove the address. Click the remove link beside any IP addresses that you
want to remove.
v Remove an IP group from a hypervisor. To remove an IP group from a
hypervisor, use the following steps:
1. Select the IP group to be edited in the left panel of the IP Groups window. If
an IP group has been assigned to one or more hypervisors, the Hypervisor
field displays the hypervisors to which the IP group belongs.
2. Remove the IP group from the hypervisor. Click the remove link beside a
hypervisor in the Hypervisors field to remove the IP group from that
hypervisor. If the hypervisor is in maintenance mode and not started, you
can remove the IP group from a hypervisor. The remove option is
unavailable for started hypervisors.
Note: Hypervisors must have IP groups assigned to run in the cloud. If the
hypervisor is currently running in a cloud and not in maintenance mode,
you cannot remove the IP group from that hypervisor.
If the remove link is unavailable, then the hypervisor is in use. For more
information on stopping a hypervisor and putting it in maintenance mode,
see Administering hypervisors on page 187.
v Delete an IP group. To delete the IP group, you must first have removed it from
all hypervisors to which it was assigned. Active IP group resources cannot be
deleted. To delete the IP group, use the following steps:
1. Select the IP group to be deleted in the left panel of the IP Groups window.
2. Remove the IP group from hypervisors. Click the remove link beside any
hypervisors in the Hypervisors field. IP groups can only be removed from a
hypervisor if the hypervisor is in maintenance mode. If the hypervisor is not
in maintenance mode, you cannot remove the IP group. For more
information about the maintenance mode state, see Hypervisor states on
page 207.
3. Delete the IP group. Click the Delete icon on the top of the IP Groups
window.
Note: If the IP group is automatically defined from an OpenStack network,
the network is not actually deleted in OpenStack environment. If the network
still exists in your OpenStack environment, the IP group is listed again in the
SmartCloud Orchestrator user interface when the automatic synchronization
occurs. For more information about the OpenStack synchronization, see
Configuring OpenStack synchronization on page 146. For more information
about managing networks in OpenStack, see Configuring Networking on the
Compute Node in the OpenStack documentation.
What to do next
After you have removed the IP group or groups from your hypervisor, and the
other hypervisor configuration is complete, you can restart the hypervisor. If the
hypervisor still has an IP group, you can run the hypervisor in the cloud. For more
information about configuring hypervisors, see Administering hypervisors on
page 187.
Related reference:
IP command-line interface reference on page 834
You can work with IP addresses, using the IPs and IP objects on the SmartCloud
216 IBM SmartCloud Orchestrator 2.3: User's Guide
Orchestrator command-line interface.
IP group command-line interface reference on page 838
You can work with IP groups on the SmartCloud Orchestrator command-line
interface using the IPgroups and IPgroup objects and attributes.
IP groups REST API on page 977
You can use the representational state transfer (REST) application programming
interface (API) to manage IP groups.
IP addresses REST API on page 973
You can use the representational state transfer (REST) application programming
interface (API) to manage IP addresses.
Fields on the IP Groups user interface:
You can administer your IP groups and IP addresses within IP groups using the
fields on the IP Groups window of the SmartCloud Orchestrator user interface.
To work with IP groups and IP addresses within those IP groups on the
SmartCloud Orchestrator user interface you can use the IP Groups window. The
left panel of the IP Groups provides the following options to work with IP groups:
Add icon
Use the Add icon to define an IP group to add to SmartCloud Orchestrator.
Clicking Add opens a window in which you can define your new IP
group.
Search
Enter the name of an IP group in this field to search for it. You can use the
up and down arrow keys to sort through the listing of IP groups.
To work with an IP group, first select it from the list in the left panel of the IP
Groups window. Selecting an IP group shows the name of the IP group at the top
of the right panel and the following fields on the right panel.
Note: Some fields might not be available or valid depending on the type of the
hypervisor to which the IP group is assigned.
Version
Displays IPv4 or IPv6 as the version of the IP addresses specified when the
IP group was added.
Attention: Workloads that require IP caching must be deployed to cloud
groups with only IPv4 IP groups.
Description
An optional description of the IP group.
Obtain IP addresses from
Displays DHCP Server or IP Address Pool to specify from where the IP
group obtains the IP addresses available to the hypervisors.
Host name prefix
The prefix to be used in the deployed virtual machine host name. This
information is optional.
Computer name prefix
The prefix to be used in the computer name of the deployed virtual
machines. This information is optional.
Chapter 4. Administering 217
Workgroup
The Windows workgroup name to be used for the deployed virtual
machines. This information is optional and it is valid only for Windows
virtual machines.
Hypervisors
Provides a listing of the hypervisors to which the IP group is assigned. The
name of the hypervisor is a link that you can click to open the Hypervisors
window for that hypervisor. If the hypervisors are in maintenance mode
and not actively running in a cloud, the remove link is also available.
Clicking remove removes the IP group from the hypervisor.
For IP groups that obtain IP addresses from an IP address pool, also the following
fields are displayed in the right panel:
Subnet address
The subnet address for the IP addresses in the IP group. This information
is required when you are creating an IP group.
Netmask
The netmask address for the IP addresses in the IP group. This information
is required when you are creating an IPv4 IP group.
Gateway
The gateway address for the IP addresses in the IP group. This information
is required when you are creating an IP group.
Alternate gateway
The alternate gateway address for the IP addresses in the IP group. This
information is optional.
Primary DNS
The primary DNS for the IP addresses in the IP group. This information is
required when you are creating an IP group.
Secondary DNS
A secondary DNS address might have been provided when the IP group
was created. This information is optional.
DNS suffixes (in order)
A comma separated list of domain suffixes that should be added to the
network settings of the deployed virtual machines. For example:
ibm.com,us.ibm.com. This information is optional.
Domain name
The domain name to be used for the IP group network. This information is
optional.
Primary WINS address
The primary WINS address to be uses for the deployed virtual machines.
This information is optional and it is valid only for Windows virtual
machines.
Secondary WINS address
The secondary WINS address to be uses for the deployed virtual machines.
This information is optional and it is valid only for Windows virtual
machines.
IP Addresses
Provides a numerically sorted list of IP addresses that have been added to
the IP group. Hovering over a resolved host name of a defined IP address
218 IBM SmartCloud Orchestrator 2.3: User's Guide
displays either the IP address or user host name, whichever was used to
create the IP address. This shows how the IP was originally entered, and
therefore what is resolved.
Bold face text in the list of IP addresses also defines how the IP address
was added. The part of the line that is bold face is representative of the
way the IP address is added to the IP Group. For example:
v If the IP address is used when the IP address is added to the IP Group,
the IP address is bold face such as, 172.16.39.236 (esx-v4-039-
236.raleigh.ibm.com).
v If the host name is used when the IP address is added to the IP Group,
the host name is bold face such as, 172.16.39.236 (esx-v4-039-
236.raleigh.ibm.com).
To the left of each IP address is one of the following statuses:
Active The IP address is active.
Inactive
The IP address is not currently active
Locked
The IP address is locked so that it cannot be used. If the IP address
is locked with a correlation ID, then only users with that
correlation ID can use the IP address.
Unavailable
There is an error with the IP address and it is unavailable. Check
your access to the IP address.
The following functions are available to work with IP addresses:
Remove
The remove link is shown to the right of any IP addresses that are
inactive and can be removed.
show more or show less
The show more or show less toggle link controls the number of IP
addresses shown. The list shows either all of the IP addresses in
the IP group or only the first 4, numerically ordered, IP addresses.
Add range
Use the two entry boxes and the Add link to add strings of IP
addresses at a time. Entering the first IP address in the string in
the first box and the final IP address in the second box adds all IP
addresses, numerically, between the two addresses specified.
Add Host Names
You can add IP addresses as host names instead of the actual IP
addresses. Clicking Add Host Names provides an entry field in
which to enter the space-delimited list of host names. When a host
name is specified for an IP address, the host name resolves to the
IP address. However, what is entered is what is stored. Therefore,
if you enter the host name then the host name is stored and not
the IP address to which it resolves. If any of the host names
entered cannot be resolved to IP addresses, then a warning
message is shown beside any entry that cannot be resolved. If a
host name is resolved to an IP address but the IP address is not
valid for the specified subnet, then an error message is shown and
the host name is not added to the IP Group.
Chapter 4. Administering 219
Related tasks:
Administering cloud groups on page 184
In SmartCloud Orchestrator, a cloud group is identified by an availability zone in a
region of the related OpenStack environment.
Related reference:
Cloud group command-line interface reference on page 815
You can work with cloud groups using the SmartCloud Orchestrator command-line
interface.
Managing environment profiles
You can use environment profiles to control some aspects of your deployment. You
can use environment profiles to group related deployment configuration options
together and deploy from a single pattern.
Before you begin
For more information about environment profiles, see Environment profiles
overview on page 221. For information about working with SmartCloud
Orchestrator catalog, see the following information:
v Chapter 5, Managing virtual images, on page 287, for information about
working with virtual images in the catalog.
v Managing script packages on page 234 for information about working with
script packages in the catalog.
About this task
To work with environment profiles, use either the user interface or the
command-line interface.
Procedure
v Use the user interface to work with environment profiles, as described in
Managing environment profiles in the user interface on page 222.
v Use the command-line interface to work with environment profiles, as described
in Environment profiles command-line interface reference on page 819.
Related concepts:
Environment profiles overview on page 221
Environment profiles group related deployment configuration, like virtual machine
names, IP address assignment, and cloud groups. Deploying patterns with
environment profiles enables deployments across tiers from a single pattern.
Related tasks:
Managing environment profiles in the user interface on page 222
You can manage environment profiles with the SmartCloud Orchestrator user
interface from the Environment Profiles window.
Related reference:
Environment profiles command-line interface reference on page 819
You can work with environment profiles on the SmartCloud Orchestrator
command-line interface.
Environment profiles REST API on page 962
You can use the representational state transfer (REST) application programming
interface (API) to manage environment profiles.
220 IBM SmartCloud Orchestrator 2.3: User's Guide
Environment profiles overview
Environment profiles group related deployment configuration, like virtual machine
names, IP address assignment, and cloud groups. Deploying patterns with
environment profiles enables deployments across tiers from a single pattern.
An environment profile provides configuration that can be used when deploying a
pattern. An environment can be specified with multiple clouds, and specific
resources within those clouds, in SmartCloud Orchestrator. Environment profiles
provide the following function:
v Defining the operational environments, for example development, test, or quality
assurance
v Defining virtual machine naming conventions within the operational
environment
v Specifying whether SmartCloud Orchestrator or the pattern deployer provides
the IP address on the deployment
v Segmenting the clouds, and IP groups within the clouds, to specific
environments
v Assigning aliases to the cloud resources such as clouds and IP groups
v Assigning sections within the clouds to specific users or groups
Environment profiles provide an option to deploy a pattern to a specified cloud
group. You can define profile information for the cloud, IP group, and IP address
at a part level in an environment profile. You can select specific IP groups for each
cloud and provide aliases to the cloud and IP groups to better describe the
environment at deployment time. You can use the same pattern and deploy in
different environments without changing the pattern.
The virtual machine name syntax is also specific to the cloud.
Related tasks:
Managing environment profiles on page 220
You can use environment profiles to control some aspects of your deployment. You
can use environment profiles to group related deployment configuration options
together and deploy from a single pattern.
Managing environment profiles in the user interface on page 222
You can manage environment profiles with the SmartCloud Orchestrator user
interface from the Environment Profiles window.
Related reference:
Environment profiles command-line interface reference on page 819
You can work with environment profiles on the SmartCloud Orchestrator
command-line interface.
Environment profiles REST API on page 962
You can use the representational state transfer (REST) application programming
interface (API) to manage environment profiles.
Chapter 4. Administering 221
Managing environment profiles in the user interface
You can manage environment profiles with the SmartCloud Orchestrator user
interface from the Environment Profiles window.
Before you begin
You must have a cloud group configured and ready, with all hypervisors
configured and available to create an environment profile that is ready to be
deployed. For more information about configuring cloud groups, see
Administering cloud groups on page 184. For more information about
configuring hypervisors, see Administering hypervisors on page 187.
About this task
You can use environment profiles to group related deployment configuration, like
virtual machine names, IP address assignment, and cloud groups, with the
SmartCloud Orchestrator user interface.
Procedure
1. Click Configuration > Environment Profiles on the menu bar to open the
Environment Profiles window.
2. Work with a profile. You can perform the following tasks:
v Create an environment profile with the information in Creating an
environment profile on page 223.
v Clone an existing environment profile for reuse with the information in
Cloning an environment profile on page 227.
v Edit an existing environment profile with the information in Editing an
environment profile on page 228.
Related concepts:
Environment profiles overview on page 221
Environment profiles group related deployment configuration, like virtual machine
names, IP address assignment, and cloud groups. Deploying patterns with
environment profiles enables deployments across tiers from a single pattern.
Related tasks:
Creating an environment profile on page 223
You can create an environment profile with the SmartCloud Orchestrator user
interface.
Cloning an environment profile on page 227
You can clone environment profiles that are created in SmartCloud Orchestrator
with the user interface. Cloning an environment profile provides a starting point
for configuring a new environment profile as you can reuse some of the existing
configuration.
Editing an environment profile on page 228
You can edit some of the configuration for any environment profile to which you
have access. You can modify environment profiles to suit the changing needs of
your environment.
Related reference:
Environment Profiles window fields on page 230
The Environment Profiles window provides fields to group related deployment
configuration options, like virtual machine names, IP address assignment, and
cloud groups, together. With this configuration information grouped, you can
manage the configuration in the environment profile without changing the pattern
that is deploying the environment profile.
222 IBM SmartCloud Orchestrator 2.3: User's Guide
Creating an environment profile:
You can create an environment profile with the SmartCloud Orchestrator user
interface.
Before you begin
You must have a cloud group configured and ready, with all hypervisors
configured and available, to create an environment profile that is ready to be
deployed. For more information about configuring cloud groups, see
Administering cloud groups on page 184. For more information about
configuring hypervisors, see Administering hypervisors on page 187.
About this task
You can create an environment profile with the steps in this task.
Procedure
1. From the upper left panel of the Environment profiles window, click add to
add an environment profile.
2. Provide the following basic information about the environment profile you are
creating:
Name Enter a unique name for the profile in the Name field. This information
is required.
Description
Optionally, enter a detailed description to identify the profile in the
Description field.
Hypervisor type
Select OpenStack as the type of hypervisor in the cloud group you are
using.
Environment
Select the environment in which this profile is to be created. The
following options are available:
v All
v Development
v Test
v Quality Assurance
v Performance
v Research
v Production
v Pre-Production
The default value is All.
3. Click OK to create the profile. When the information is processed, you return
to the Environment Profiles view and the profile you created is added to the
list in the left panel. It is selected so that the information about it is shown in
the right panel. For more information about the fields on this panel, see
Environment Profiles window fields on page 230.
4. Complete the configuration. Before the environment profile is ready to use, you
must provide additional configuration information in the following fields:
Chapter 4. Administering 223
Virtual machine name format
It must contain one of the following variables:
${hostname}
Replaced with the host name of the virtual machine, for
example: My${hostname}VM.
Note: Underscores are not valid characters in the virtual
machine hostname.
${vs-name}
Replaced with the name of the virtual system instance, for
example: My${vs-name}VM. This variable cannot be used alone in
the Virtual machine name format field. The ${vs-name}
variable must be used with one of the other formatting
variables. Otherwise, if a cluster pattern is being deployed, all
virtual machines would then have the same name and the
deployment would fail.
${x-counter}
Replaced with a counter of x digits, for example:
MyVM${3-counter}. The x in this example represents the number
of digits for the counter. So if the value of x is two, then it is
represented as 02. This value could be 01, 02 or 03, for example.
IP addresses provided by
Choose whether you want the IP address for a virtual machine to be
provided by SmartCloud Orchestrator or specified when the pattern is
being deployed. Use the following options:
Pattern deployer
To provide the IP address for a virtual machine at deployment,
you must also specify the following information for each part:
v Cloud group
v IP group
v Host name
v IP address
Important: If you choose this option, then you cannot specify
an IP address that is contained within the IP groups that are
defined in SmartCloud Orchestrator at deployment.
IP Groups
If SmartCloud Orchestrator is to provide the IP address for a
virtual machine, then you specify only the cloud group and IP
group. Specify these options when you define the parts to
deploy the pattern. SmartCloud Orchestrator provides the IP
address information.
Deploy to cloud groups
Click this field to select cloud groups that are configured and ready for
use. Only valid cloud groups that are configured with the correct
hypervisor type are available. Selecting a cloud group provides the
following information for the IP groups in that cloud group:
In use Click this check box to use the IP group in the environment
profile.
Name Shows the name of the IP group in the cloud you selected.
224 IBM SmartCloud Orchestrator 2.3: User's Guide
Alias You can specify an alias name for the IP group for use in the
environment profile. The default setting is the actual name of
the IP group.
Subnet address
Shows the subnet address of the IP group.
Gateway
Shows the gateway address of the IP group.
Netmask
Shows the netmask address of the IP group.
Windows domain information
The Windows domain section in the environment profile is optional. If
the Domain name field is empty, other fields in the section will be
ignored, and the deployed system will not be added to a domain. If the
Domain name field is specified, the User name and Password fields
become mandatory. However, the Organizational unit field remains
optional. If the Organizational unit field is not specified, the computer
account will be stored in the default Computers container located under
the Active Directory domain root.
Important: Windows computer names must be 15 characters or less in
length and are derived from the corresponding host names in DNS.
DNS host names, which are more than 15 characters in length, may
cause duplicate computer names by keeping the first 15 characters of
the DNS host names. In the case of a duplicate computer name, when
the computer is joined to an Active Directory domain, it will either
replace the existing computer account or result in an error indicating
that the account already exists. Since both are undesirable results, it is
recommended that DNS host names be 15 characters or less in length.
Provide the following domain information:
Domain name
Specify the name of the domain to join, for example,
smartcloud.company.com.
User name
Specify the user name that is authorized to add a computer
account to the domain. Refer to Microsoft documentation for
details.
Password
Specify the password of the domain user specified in User
name.
Organizational unit
Specify the organizational units where the computer account is
stored. For
example: ou=Computers,ou=ou1,dc=smartcloud,dc=company,dc=com
where Computers and ou1 are the organizational units created
under the Active Directory domain root, and smartcloud,
company, and com are derived from the domain name
smartcloud.company.com.
Windows key management service
Provide the following KMS server information to be used for KMS
client activation:
Chapter 4. Administering 225
KMS server IP address
Specify the IP address of the KMS server in your environment.
KMS server port
Specify the port used for KMS service.
Environment limits
The environment limits section enables you to provide the limits of the
virtual CPU, virtual memory, and storage that this environment profile
can use on the hypervisor. To provide virtual CPU, virtual memory, and
storage limits, click the number in the limit column.
Note: SmartCloud Orchestrator does not report information related to
reserved resources and limits associated to the resource pool in
VMware. By default, the resource pool is considered as unlimited. Use
the environment profile in SmartCloud Orchestrator to manage these
resource limits.
Access granted to...
Click this field to specify access to this environment profile for other
users. Select users to make the environment profile readable or writable
to these users. Initially this field is set to the role of the owner of the
environment profile.
By default, the Add more box contains the Everyone built-in project.
When a project has been added, click the link beside the entry to toggle
between the following access levels:
v Read
v Write
v All
Click the link name of the project to show information about that
project. You can also click the remove link to remove access for a
project.
Results
When you have completed these steps, you have configured basic information
about the environment profile.
What to do next
If there are no errors and all the resources the environment profile contains are
operational, you can deploy it to the cloud or clouds you specified.
Related concepts:
Environment profiles overview on page 221
Environment profiles group related deployment configuration, like virtual machine
names, IP address assignment, and cloud groups. Deploying patterns with
environment profiles enables deployments across tiers from a single pattern.
Related tasks:
Cloning an environment profile on page 227
You can clone environment profiles that are created in SmartCloud Orchestrator
with the user interface. Cloning an environment profile provides a starting point
for configuring a new environment profile as you can reuse some of the existing
configuration.
Related reference:
226 IBM SmartCloud Orchestrator 2.3: User's Guide
Environment Profiles window fields on page 230
The Environment Profiles window provides fields to group related deployment
configuration options, like virtual machine names, IP address assignment, and
cloud groups, together. With this configuration information grouped, you can
manage the configuration in the environment profile without changing the pattern
that is deploying the environment profile.
Cloning an environment profile:
You can clone environment profiles that are created in SmartCloud Orchestrator
with the user interface. Cloning an environment profile provides a starting point
for configuring a new environment profile as you can reuse some of the existing
configuration.
Before you begin
Select an environment profile that most closely meets your needs, with the
hypervisor type you want to use. The hypervisor type cannot be changed when
you clone an environment profile.
If the profile is to deploy in a cloud other than the one specified in the profile you
are cloning, have a cloud group configured and ready. All hypervisors must be
configured and available in a cloud to create an environment profile that is ready
to be deployed. For more information about configuring cloud groups, see
Administering cloud groups on page 184. For more information about
configuring hypervisors, see Administering hypervisors on page 187.
About this task
This task provides the necessary steps to clone an environment profile and then
customize the copy to meet the needs of your environment.
Procedure
1. From the left panel of the Environment Profiles window, click the profile you
want to clone. The description and general information about this environment
profile display in the right panel of the Environment Profiles view.
2. Clone the environment profile. Click the clone icon on the upper right panel of
the Environment Profiles view.
3. Provide the following basic information about the new environment profile you
are cloning:
Name Enter a new unique name for the environment profile in the Name
field. This information is required.
Description
Optionally, enter a detailed description to identify and differentiate the
environment profile in the Description field.
4. Click OK to save your changes. When the information is processed, you return
to the Environment Profiles view and the profile you created is added to the
list in the left panel. It is selected so that the information about it is shown in
the right panel. For more information about the fields on this panel, see
Environment Profiles window fields on page 230.
5. Edit the environment profile. You can edit the fields described in Editing an
environment profile on page 228.
Chapter 4. Administering 227
Results
When you have completed these steps, you have cloned and customized the
environment profile.
Related concepts:
Environment profiles overview on page 221
Environment profiles group related deployment configuration, like virtual machine
names, IP address assignment, and cloud groups. Deploying patterns with
environment profiles enables deployments across tiers from a single pattern.
Related tasks:
Creating an environment profile on page 223
You can create an environment profile with the SmartCloud Orchestrator user
interface.
Editing an environment profile
You can edit some of the configuration for any environment profile to which you
have access. You can modify environment profiles to suit the changing needs of
your environment.
Related reference:
Environment Profiles window fields on page 230
The Environment Profiles window provides fields to group related deployment
configuration options, like virtual machine names, IP address assignment, and
cloud groups, together. With this configuration information grouped, you can
manage the configuration in the environment profile without changing the pattern
that is deploying the environment profile.
Editing an environment profile:
You can edit some of the configuration for any environment profile to which you
have access. You can modify environment profiles to suit the changing needs of
your environment.
About this task
You can use environment profiles to track CPU, memory, storage and stop
deployments at a particular size. If you have administrative permission, you can
change the high water marks accordingly. Each profile can indicate how many
resources of the cloud SmartCloud Orchestrator can consume. This task provides
information about the configuration that you can edit for existing environment
profiles.
Procedure
1. From the left panel of the Environment Profiles window, select the environment
profile to edit. The information about that environment profile is shown in the
right panel of the Environment Profiles view.
2. Optional: Determine your access. If you are not able to edit the environment
profile, check the Access granted to: field on the lower right panel to verify
that you have access. If you do not have access, you can click the link on the
owner, view the contact information, and contact the owner to ask for access.
3. Optional: Edit the following configuration information:
a. Edit the description. Add or change the description of the environment
profile in the Description field.
228 IBM SmartCloud Orchestrator 2.3: User's Guide
a. Change the environment. Select a different environment, in which your
environment profile is to run, in the Environment field. The following
options are available:
v All
v Development
v Test
v Quality Assurance
v Performance
v Research
v Production
v Pre-Production
b. Specify or change the format of the virtual machine name. In the Virtual
machine name format field, you can specify the format for the virtual
machine name, for example d_${hostname}.
c. Specify how the IP addresses are provided. In the IP addresses provided by
field, select one of the following options to specify how the IP addresses are
provided:
Pattern deployer
If you choose to provide the IP address for a virtual machine at
deployment, then you must also specify the cloud group, IP group,
host name, and IP address for each part.
Important: If you choose this option, then the person deploying the
pattern cannot specify an IP address that is contained within the IP
groups that are defined in SmartCloud Orchestrator.
IP Groups
If SmartCloud Orchestrator provides the IP address for a virtual
machine, you only specify the cloud group and IP group for the
pattern parts. SmartCloud Orchestrator provides the IP address
information
d. Add, remove, or change the alias name for the cloud group in which the
environment profile is to run.
Add To add a cloud group, click the entry field under the Deploy to
cloud groups label and select the cloud group to add.
Remove
Click the Remove link beside any listed cloud groups to remove
them from the environment profile.
Change alias name
In the Alias field, change the name of the cloud. This name is
shown at deployment.
e. Add, remove, or rename IP groups. Select or clear the In use box to indicate
the IP groups in each cloud group to be used. You can also change the
name of the IP group, as it is shown at deployment, in the Alias field.
f. Expand the Windows domain information field, to modify the domain
information.
g. Expand the Windows key management service field, to modify the KMS
server information.
h. In the Environment limits field, you can modify the limits of the virtual
CPU, virtual memory, and storage.
Chapter 4. Administering 229
i. Grant or remove access to the environment profile to projects. Use the
Access granted to field to add, remove, or change access to this environment
profile.
Results
If the hypervisors and resources for the cloud group specified are available, the
environment profile can be deployed to the cloud group.
Related concepts:
Environment profiles overview on page 221
Environment profiles group related deployment configuration, like virtual machine
names, IP address assignment, and cloud groups. Deploying patterns with
environment profiles enables deployments across tiers from a single pattern.
Related tasks:
Creating an environment profile on page 223
You can create an environment profile with the SmartCloud Orchestrator user
interface.
Cloning an environment profile on page 227
You can clone environment profiles that are created in SmartCloud Orchestrator
with the user interface. Cloning an environment profile provides a starting point
for configuring a new environment profile as you can reuse some of the existing
configuration.
Related reference:
Environment Profiles window fields
The Environment Profiles window provides fields to group related deployment
configuration options, like virtual machine names, IP address assignment, and
cloud groups, together. With this configuration information grouped, you can
manage the configuration in the environment profile without changing the pattern
that is deploying the environment profile.
Environment Profiles window fields:
The Environment Profiles window provides fields to group related deployment
configuration options, like virtual machine names, IP address assignment, and
cloud groups, together. With this configuration information grouped, you can
manage the configuration in the environment profile without changing the pattern
that is deploying the environment profile.
The following icons are on the upper right top bar of the Environment Profiles
window:
Refresh
Refreshes the profile display in the configuration panel after any changes.
Clone Clones the selected profile. You can clone the profile and then edit the
copy.
Delete Deletes the profile from SmartCloud Orchestrator.
There are two interactive panels of the Environment Profiles window:
Left panel
The left panel provides the following function:
v The add icon to create new environment profiles
v A search function to locate existing environment profiles
v A list of environment profiles that have been created
230 IBM SmartCloud Orchestrator 2.3: User's Guide
Right panel
The right panel provides the fields to define and view details about a
selected environment profile.
The fields on the right panel of the Environment Profiles window provide details
about an environment profile selected from the listing on the left panel. The
following fields define the selected environment profile:
Description
An editable field that provides the description of the profile. The
description can be added or edited after the environment profile is created.
Hypervisor type
Shows OpenStack as the type of hypervisor with which the profile was
created.
Environment
The environment is specified when the environment profile is created but it
can be changed. The following environments can be specified:
v All
v Development
v Test
v Quality Assurance
v Performance
v Research
v Production
v Pre-Production
The default value is All.
Created on
Shows the time stamp when the profile was created.
Current status
Provides the status of the profile. This field shows if the environment
profile is complete or if information is needed.
The success icon
The success icon indicates that the environment profile is complete
and resources are available.
The warning icon
The warning icon indicates that environment profile is incomplete.
A textual explanation, in addition to the warning icon, provides an
explanation of the problem, or problems, with the environment
profile configuration.
Updated on
Shows the timestamp of the most recent update.
Virtual machine name format
This optional field is a free form editing space to indicate the format of the
virtual machine, for example, d_${hostname}. This field displays None
provided initially.
IP addresses provided by
This field provides the following options:
Chapter 4. Administering 231
IP Groups
Indicates that the IP address is to be provided bySmartCloud
Orchestrator at deployment. IP Groups is the default setting.
Pattern deployer
Indicates that the IP address is to be provided by the person
deploying the pattern at the time of deployment.
Important: If this option is selected, the person deploying the
pattern cannot specify an IP address that is contained within IP
groups that are defined in SmartCloud Orchestrator.
Deploy to cloud groups
Shows the following information for each cloud group in the list:
Name Shows the name of the IP group in the selected cloud.
Alias An entry field to specify an alias for the IP group for use in the
environment profile. The default setting is the actual name of the
IP group. Click to change the alias name.
remove
Removes the cloud group from the environment profile.
Clicking the expand icon shows the following additional fields for the
selected cloud group:
Using Environment profile
Selection box to specify the IP group to use.
Name The name of the cloud group.
Deploy to cloud groups
The cloud groups to which this environment profile can deploy.
Subnet address
Shows the subnet address of the IP group.
Gateway
Shows the gateway address of the IP group.
Netmask
Shows the netmask address of the IP group.
Windows domain information
Shows the following domain information:
Domain name
Shows the name of the domain.
User name
Shows the user name that is authorized to add a computer account
to the domain.
Password
Shows the password of the domain user specified in User name.
Organizational unit
Shows the organizational units where the computer account is
stored.
Windows key management service
Shows the following KMS server information:
232 IBM SmartCloud Orchestrator 2.3: User's Guide
KMS server IP address
Shows the IP address of the KMS server in your environment.
KMS server port
Shows the port used for KMS service.
Environment limits
In the table, you can set the following types of environment profile limits:
v Virtual CPU
v Virtual Memory
v Storage
This table also shows the current usage and the reserved usage for each of
these types.
Access granted to
By default, the user who created the environment profile has access to it
and other users cannot edit it. This field can be edited and to provide
access to this environment profile for projects. Selecting projects makes the
environment profile readable or writable to the users belonging to these
projects.
By default, the Add more box contains the Everyone built-in project. When
a project has been added, click the link beside the entry to toggle between
the following access levels:
v Read
v Write
v All
Click the link name of the project to show information about that project.
You can also click the remove link to remove access for a project.
Comments
A comments field is provided to enable administrators to communicate
information with one another regarding environment profiles.
Related reference:
Fields on the Pattern Editor window on page 556
The SmartCloud Orchestrator Pattern Editor window contains lists of parts, scripts,
and add-ons to graphically work with your topology. You can use these parts,
scripts, and add-ons to edit and customize your virtual system pattern topology
and, therefore, your deployment.
Populating the catalog
The SmartCloud Orchestrator catalog contains the application templates, plug-ins,
reusable components, virtual images, virtual system patterns, script packages, and
add-ons that are used to build the virtual environment.
Before you begin
To add content to the catalog you must be assigned the catalogeditor role or the
admin role. To change the catalog content, you must explicitly be granted access to
the content that you want to modify or be assigned the admin role.
About this task
Use the following steps to manage and add content in the catalog.
Chapter 4. Administering 233
Procedure
1. Chapter 5, Managing virtual images, on page 287. Virtual images provide the
operating system and product binary files required to create a virtual system
instance.
2. Working with virtual system patterns on page 511. You can use a virtual
system pattern to describe the topology of a system that you want to deploy.
3. Managing script packages You can use script packages to customize the
behavior of parts by adding script packages to pattern topologies.
4. Managing add-ons on page 254 You can add user, disk and NIC parts to
your catalog and then edit them as parts on your patterns.
Results
After completing these steps, you have expanded the available catalog options to
build the virtual environment.
What to do next
Use the catalog content to create new virtual systems. For more information about
working with virtual system instances, see Managing virtual system instances on
page 562.
Managing script packages
You can use script packages to customize the behavior of parts in SmartCloud
Orchestrator topologies by adding script packages to pattern topologies. You can
create script packages and then add them to the part you want to modify within
the pattern containing that part.
Before you begin
You must create a compressed file in .zip or .tgz (.tar.gz) format that contains
the main executable file and all associated artifacts that support the execution of
the main executable file. This will be uploaded into SmartCloud Orchestrator and
used as input to create the script package. See Script packages overview on page
235 for more information about using script packages with SmartCloud
Orchestrator.
The compressed file includes the script file (script.sh on Linux, or script.bat or
script.cmd on Windows) in addition to the .json file needed to run the script on
the deployed virtual machine. For more information, see Configuring a script
package using a JSON object on page 250.
About this task
You can work with script packages with the user interface or the command-line
interface. Choose the interface with which to work.
For a description of the attributes of the script packages, refer to Script package
command-line interface reference on page 876.
Procedure
v Using script packages with the user interface on page 242, you can perform
the following tasks:
234 IBM SmartCloud Orchestrator 2.3: User's Guide
Add a script package. For information about adding a script package, see
Adding a script package on page 243.
Associate a script package with a pattern. After adding the script package,
you can associate it with a pattern. For information about associating a script
package with a pattern, see Associating a script package with a pattern on
page 247.
Delete a script package. If you determine that a script package is no longer
needed, you can delete it. For information about deleting a script package, see
Deleting a script package on page 248.
v Using the command-line interface. You can work with script packages using the
command-line interface. For information about working with script packages on
the command-line interface, see Script package command-line interface
reference on page 876.
Results
When you have created a script package and associated it with a specific pattern,