By understanding how the different installed nodes interact with each other, you can administer the Compute installation. Compute offers many ways to install using multiple servers but the general idea is that you can have multiple compute nodes that control the virtual servers and a cloud controller node that contains the remaining Compute services. The Compute cloud works through the interaction of a series of daemon processes named nova-* that reside persistently on the host machine or machines. These binaries can all run on the same machine or be spread out on multiple boxes in a large deployment. The responsibilities of services and drivers are: Services: nova-api. Receives xml requests and sends them to the rest of the system. It is a wsgi app that routes and authenticate requests. It supports the EC2 and OpenStack APIs. There is a nova-api.conf file created when you install Compute. nova-cert. Provides the certificate manager. nova-compute. Responsible for managing virtual machines. It loads a Service object, which exposes the public methods on ComputeManager through Remote Procedure Call (RPC). nova-conductor. Provides database-access support for Compute nodes (thereby reducing security risks). nova-consoleauth. Handles console authentication. nova-objectstore: The nova-objectstore service is an ultra simple file-based storage system for images that replicates most of the S3 API. It can be replaced with OpenStack Image Service and a simple image manager or use OpenStack Object Storage as the virtual machine image storage facility. It must reside on the same node as nova-compute. nova-network. Responsible for managing floating and fixed IPs, DHCP, bridging and VLANs. It loads a Service object which exposes the public methods on one of the subclasses of NetworkManager. Different networking strategies are available to the service by changing the network_manager configuration option to FlatManager, FlatDHCPManager, or VlanManager (default is VLAN if no other is specified). nova-scheduler. Dispatches requests for new virtual machines to the correct node. nova-novncproxy. Provides a VNC proxy for browsers (enabling VNC consoles to access virtual machines). Some services have drivers that change how the service implements the core of its functionality. For example, the nova-compute service supports drivers that let you choose with which hypervisor type it will talk. nova-network and nova-scheduler also have drivers.

Access to the Euca2ools (ec2) API is controlled by an access and secret key. The user’s access key needs to be included in the request, and the request must be signed with the secret key. Upon receipt of API requests, Compute verifies the signature and runs commands on behalf of the user. To begin using Compute, you must create a user with the Identity Service.

You can configure Compute to generate a random administrator (root) password and inject that password into the instance. If this feature is enabled, a user can ssh to an instance without an ssh keypair. The random password appears in the output of the nova boot command. You can also view and set the admin password from the dashboard. The dashboard is configured by default to display the admin password and allow the user to modify it. If you do not want to support password injection, we recommend disabling the password fields by editing your Dashboard local_settings file (file location will vary by Linux distribution, on Fedora/RHEL/CentOS: /etc/openstack-dashboard/local_settings, on Ubuntu and Debian: /etc/openstack-dashboard/local_settings.py and on openSUSE and SUSE Linux Enterprise Server: /srv/www/openstack-dashboard/openstack_dashboard/local/local_settings.py) OPENSTACK_HYPERVISOR_FEATURE = { ... 'can_set_password': False, } For hypervisors such as KVM that use the libvirt backend, admin password injection is disabled by default. To enable it, set the following option in /etc/nova/nova.conf: [libvirt] inject_password=true When enabled, Compute will modify the password of the root account by editing the /etc/shadow file inside of the virtual machine instance. Users can only ssh to the instance by using the admin password if: The virtual machine image is a Linux distribution The virtual machine has been configured to allow users to ssh as the root user. This is not the case for Ubuntu cloud images, which disallow ssh to the root account by default. Compute uses the XenAPI agent to inject passwords into guests when using the XenAPI hypervisor backend. The virtual-machine image must be configured with the agent for password injection to work. To support the admin password for Windows virtual machines, you must configure the Windows image to retrieve the admin password on boot by installing an agent such as cloudbase-init.

A system administrator can use the nova client and the Euca2ools commands to manage the cloud. Both nova client and euca2ools can be used by all users, though specific commands might be restricted by Role Based Access Control in the Identity Service. Installing the python-novaclient package gives you a nova shell command that enables Compute API interactions from the command line. Install the client, and then provide your user name and password (typically set as environment variables for convenience), and then you have the ability to send commands to your cloud on the command line. To install python-novaclient, download the tarball from http://pypi.python.org/pypi/python-novaclient/2.6.3#downloads and then install it in your favorite python environment. $ curl -O http://pypi.python.org/packages/source/p/python-novaclient/python-novaclient-2.6.3.tar.gz $ tar -zxvf python-novaclient-2.6.3.tar.gz $ cd python-novaclient-2.6.3 As root execute: # python setup.py install Confirm the installation by running: $ nova help usage: nova [--version] [--debug] [--os-cache] [--timings] [--timeout <seconds>] [--os-username <auth-user-name>] [--os-password <auth-password>] [--os-tenant-name <auth-tenant-name>] [--os-tenant-id <auth-tenant-id>] [--os-auth-url <auth-url>] [--os-region-name <region-name>] [--os-auth-system <auth-system>] [--service-type <service-type>] [--service-name <service-name>] [--volume-service-name <volume-service-name>] [--endpoint-type <endpoint-type>] [--os-compute-api-version <compute-api-ver>] [--os-cacert <ca-certificate>] [--insecure] [--bypass-url <bypass-url>] <subcommand> ... This command returns a list of nova commands and parameters. To obtain help for a subcommand, run: $ nova help subcommand You can also refer to the OpenStack Command-Line Reference for a complete listing of nova commands and parameters. Set the required parameters as environment variables to make running commands easier. For example, you can add --os-username as a nova option, or set it as an environment variable. To set the user name, password, and tenant as environment variables, use: $ export OS_USERNAME=joecool $ export OS_PASSWORD=coolword $ export OS_TENANT_NAME=coolu Using the Identity Service, you are supplied with an authentication endpoint, which Compute recognizes as the OS_AUTH_URL. $ export OS_AUTH_URL=http://hostname:5000/v2.0 $ export NOVA_VERSION=1.1

For a command-line interface to EC2 API calls, use the euca2ools command-line tool. See http://open.eucalyptus.com/wiki/Euca2oolsGuide_v1.3

To specify a configuration file to change the logging behavior, add this line to the /etc/nova/nova.conf file . To change the logging level, such as DEBUG, INFO, WARNING, ERROR), use: log-config=/etc/nova/logging.conf The logging configuration file is an ini-style configuration file, which must contain a section called logger_nova, which controls the behavior of the logging facility in the nova-* services. For example:[logger_nova] level = INFO handlers = stderr qualname = nova This example sets the debugging level to INFO (which less verbose than the default DEBUG setting). For more details on the logging configuration syntax, including the meaning of the handlers and quaname variables, see the Python documentation on logging configuration file format f. For an example logging.conf file with various defined handlers, see the OpenStack Configuration Reference. You can configure OpenStack Compute services to send logging information to syslog. This is useful if you want to use rsyslog, which forwards the logs to a remote machine. You need to separately configure the Compute service (nova), the Identity service (keystone), the Image Service (glance), and, if you are using it, the Block Storage service (cinder) to send log messages to syslog. To do so, add the following lines to: /etc/nova/nova.conf /etc/keystone/keystone.conf /etc/glance/glance-api.conf /etc/glance/glance-registry.conf /etc/cinder/cinder.conf verbose = False debug = False use_syslog = True syslog_log_facility = LOG_LOCAL0 In addition to enabling syslog, these settings also turn off more verbose output and debugging output from the log. Although the example above uses the same local facility for each service (LOG_LOCAL0, which corresponds to syslog facility LOCAL0), we recommend that you configure a separate local facility for each service, as this provides better isolation and more flexibility. For example, you may want to capture logging information at different severity levels for different services. syslog allows you to define up to seven local facilities, LOCAL0, LOCAL1, ..., LOCAL7. For more details, see the syslog documentation. rsyslog is a useful tool for setting up a centralized log server across multiple machines. We briefly describe the configuration to set up an rsyslog server; a full treatment of rsyslog is beyond the scope of this document. We assume rsyslog has already been installed on your hosts (default for most Linux distributions). This example provides a minimal configuration for /etc/rsyslog.conf on the log server host, which receives the log files: # provides TCP syslog reception $ModLoad imtcp $InputTCPServerRun 1024 Add a filter rule to /etc/rsyslog.conf which looks for a host name. The example below uses compute-01 as an example of a compute host name: :hostname, isequal, "compute-01" /mnt/rsyslog/logs/compute-01.log On each compute host, create a file named /etc/rsyslog.d/60-nova.conf, with the following content: # prevent debug from dnsmasq with the daemon.none parameter *.*;auth,authpriv.none,daemon.none,local0.none -/var/log/syslog # Specify a log level of ERROR local0.error @@172.20.1.43:1024 Once you have created this file, restart your rsyslog daemon. Error-level log messages on the compute hosts should now be sent to your log server.

Before starting migrations, review the Configure migrations section. Migration provides a scheme to migrate running instances from one OpenStack Compute server to another OpenStack Compute server. Look at the running instances, to get the ID of the instance you wish to migrate. $ nova list Look at information associated with that instance. This example uses 'vm1' from above. $ nova show d1df1b5a-70c4-4fed-98b7-423362f2c47c In this example, vm1 is running on HostB. Select the server to which instances will be migrated: # nova service-list +------------------+------------+----------+---------+-------+----------------------------+-----------------+ | Binary | Host | Zone | Status | State | Updated_at | Disabled Reason | +------------------+------------+----------+---------+-------+----------------------------+-----------------+ | nova-consoleauth | HostA | internal | enabled | up | 2014-03-25T10:33:25.000000 | - | | nova-scheduler | HostA | internal | enabled | up | 2014-03-25T10:33:25.000000 | - | | nova-conductor | HostA | internal | enabled | up | 2014-03-25T10:33:27.000000 | - | | nova-compute | HostB | nova | enabled | up | 2014-03-25T10:33:31.000000 | - | | nova-compute | HostC | nova | enabled | up | 2014-03-25T10:33:31.000000 | - | | nova-cert | HostA | internal | enabled | up | 2014-03-25T10:33:31.000000 | - | +------------------+-----------------------+----------+---------+-------+----------------------------+-----------------+ In this example, HostC can be picked up because nova-compute is running on it. Ensure that HostC has enough resources for migration. # nova host-describe HostC +-----------+------------+-----+-----------+---------+ | HOST | PROJECT | cpu | memory_mb | disk_gb | +-----------+------------+-----+-----------+---------+ | HostC | (total) | 16 | 32232 | 878 | | HostC | (used_now) | 13 | 21284 | 442 | | HostC | (used_max) | 13 | 21284 | 442 | | HostC | p1 | 13 | 21284 | 442 | | HostC | p2 | 13 | 21284 | 442 | +-----------+------------+-----+-----------+---------+ cpu:the number of cpu memory_mb:total amount of memory (in MB) disk_gb:total amount of space for NOVA-INST-DIR/instances (in GB) 1st line shows total amount of resources for the physical server. 2nd line shows currently used resources. 3rd line shows maximum used resources. 4th line and under shows the resource for each project. Use the nova live-migration command to migrate the instances:$ nova live-migration server host_name Where server can be either the server's ID or name. For example: $ nova live-migration d1df1b5a-70c4-4fed-98b7-423362f2c47c HostC Ensure instances are migrated successfully with nova list. If instances are still running on HostB, check log files (src/dest nova-compute and nova-scheduler) to determine why. Although the nova command is called live-migration, under the default Compute configuration options the instances are suspended before migration. For more details, see Configure migrations in OpenStack Configuration Reference.