3a366a9246
I missed the chance to comment on https://review.openstack.org/#/c/149533/. I wanted to suggest this edit to emphasize that one does not require *python* websocket in particular to access the serial console, but that any websocket client library would be appropriate. Change-Id: Iff82deac5adce5811f884ed14daa7c586fed2dd0
573 lines
36 KiB
XML
573 lines
36 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
|
|
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="section_compute-system-admin">
|
|
<title>System administration</title>
|
|
<para>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.</para>
|
|
<para>The Compute cloud works through the interaction of a series of daemon processes named
|
|
<systemitem>nova-*</systemitem> 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:</para>
|
|
<para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Services:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><systemitem class="service">nova-api</systemitem>. 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 <filename>nova-api.conf</filename> file created when
|
|
you install Compute.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><systemitem>nova-cert</systemitem>. Provides the certificate
|
|
manager.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><systemitem class="service">nova-compute</systemitem>. Responsible for
|
|
managing virtual machines. It loads a Service object, which exposes the
|
|
public methods on ComputeManager through Remote Procedure Call
|
|
(RPC).</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><systemitem>nova-conductor</systemitem>. Provides database-access
|
|
support for Compute nodes (thereby reducing security risks).</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><systemitem>nova-consoleauth</systemitem>. Handles console
|
|
authentication.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><systemitem class="service">nova-objectstore</systemitem>: The
|
|
<systemitem class="service">nova-objectstore</systemitem> 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
|
|
<systemitem class="service">nova-compute</systemitem>.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><systemitem class="service">nova-network</systemitem>. 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).</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><systemitem>nova-scheduler</systemitem>. Dispatches requests for new
|
|
virtual machines to the correct node.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><systemitem>nova-novncproxy</systemitem>. Provides a VNC proxy for
|
|
browsers (enabling VNC consoles to access virtual machines).</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Some services have drivers that change how the service implements the core of
|
|
its functionality. For example, the <systemitem>nova-compute</systemitem>
|
|
service supports drivers that let you choose with which hypervisor type it will
|
|
talk. <systemitem>nova-network</systemitem> and
|
|
<systemitem>nova-scheduler</systemitem> also have drivers.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
<section xml:id="section_manage-compute-users">
|
|
<title>Manage Compute users</title>
|
|
<para>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.</para>
|
|
<para>To begin using Compute, you must create a user with the Identity Service.</para>
|
|
</section>
|
|
<xi:include href="../../common/section_cli_nova_volumes.xml"/>
|
|
<xi:include href="../../common/section_cli_nova_customize_flavors.xml"/>
|
|
<xi:include href="section_compute_config-firewalls.xml"/>
|
|
<section xml:id="admin-password-injection">
|
|
<?dbhtml stop-chunking?>
|
|
<title>Inject administrator password</title>
|
|
<para>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
|
|
<command>ssh</command> to an instance without an <command>ssh</command> keypair. The
|
|
random password appears in the output of the <command>nova boot</command> command. You
|
|
can also view and set the <literal>admin</literal> password from the dashboard.</para>
|
|
<simplesect>
|
|
<title>Dashboard</title>
|
|
<para>The dashboard is configured by default to display the <literal>admin</literal>
|
|
password and allow the user to modify it.</para>
|
|
<para>If you do not want to support password injection, we recommend disabling the
|
|
password fields by editing your Dashboard <filename>local_settings</filename> file
|
|
(file location will vary by Linux distribution, on Fedora/RHEL/CentOS: <filename>
|
|
/etc/openstack-dashboard/local_settings</filename>, on Ubuntu and Debian:
|
|
<filename>/etc/openstack-dashboard/local_settings.py</filename> and on openSUSE
|
|
and SUSE Linux Enterprise Server:
|
|
<filename>/srv/www/openstack-dashboard/openstack_dashboard/local/local_settings.py</filename>)
|
|
<programlisting language="ini">OPENSTACK_HYPERVISOR_FEATURE = {
|
|
...
|
|
'can_set_password': False,
|
|
}</programlisting></para>
|
|
</simplesect>
|
|
<simplesect>
|
|
<title>Libvirt-based hypervisors (KVM, QEMU, LXC)</title>
|
|
<para>For hypervisors such as KVM that use the libvirt backend, <literal>admin</literal>
|
|
password injection is disabled by default. To enable it, set the following option in
|
|
<filename>/etc/nova/nova.conf</filename>:</para>
|
|
<para>
|
|
<programlisting language="ini">[libvirt]
|
|
inject_password=true</programlisting>
|
|
</para>
|
|
<para>When enabled, Compute will modify the password of the root account by editing the
|
|
<filename>/etc/shadow</filename> file inside of the virtual machine
|
|
instance.</para>
|
|
<note>
|
|
<para>Users can only ssh to the instance by using the admin password if:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>The virtual machine image is a Linux distribution</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>The virtual machine has been configured to allow users to
|
|
<command>ssh</command> as the root user. This is not the case for
|
|
<link xlink:href="http://cloud-images.ubuntu.com/">Ubuntu cloud
|
|
images</link>, which disallow <command>ssh</command> to the root
|
|
account by default.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</note>
|
|
</simplesect>
|
|
<simplesect>
|
|
<title>XenAPI (XenServer/XCP)</title>
|
|
<para>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.</para>
|
|
</simplesect>
|
|
<simplesect>
|
|
<title>Windows images (all hypervisors)</title>
|
|
<para>To support the <literal>admin</literal> password for Windows virtual machines, you
|
|
must configure the Windows image to retrieve the <literal>admin</literal> password
|
|
on boot by installing an agent such as <link
|
|
xlink:href="https://github.com/cloudbase/cloudbase-init"
|
|
>cloudbase-init</link>.</para>
|
|
</simplesect>
|
|
</section>
|
|
<section xml:id="section_manage-the-cloud">
|
|
<title>Manage the cloud</title>
|
|
<para>A system administrator can use the <command>nova</command> client and the
|
|
<command>Euca2ools</command> commands to manage the cloud.</para>
|
|
<para>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.</para>
|
|
<procedure>
|
|
<title>To use the nova client</title>
|
|
<step>
|
|
<para>Installing the <package>python-novaclient</package> package gives you a
|
|
<code>nova</code> 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.</para>
|
|
<para>To install <package>python-novaclient</package>, download the tarball from
|
|
<link
|
|
xlink:href="http://pypi.python.org/pypi/python-novaclient/#downloads"
|
|
>http://pypi.python.org/pypi/python-novaclient/#downloads</link> and
|
|
then install it in your favorite python environment.</para>
|
|
<screen><prompt>$</prompt> <userinput>curl -O http://pypi.python.org/packages/source/p/python-novaclient/python-novaclient-2.6.3.tar.gz</userinput>
|
|
<prompt>$</prompt> <userinput>tar -zxvf python-novaclient-2.6.3.tar.gz</userinput>
|
|
<prompt>$</prompt> <userinput>cd python-novaclient-2.6.3</userinput></screen>
|
|
<para>As <systemitem class="username">root</systemitem>, run:</para>
|
|
<screen><prompt>#</prompt> <userinput>python setup.py install</userinput></screen>
|
|
</step>
|
|
<step>
|
|
<para>Confirm the installation:</para>
|
|
<screen><prompt>$</prompt> <userinput>nova help</userinput>
|
|
<computeroutput>usage: nova [--version] [--debug] [--os-cache] [--timings]
|
|
[--timeout <replaceable>SECONDS</replaceable>] [--os-username <replaceable>AUTH_USER_NAME</replaceable>]
|
|
[--os-password <replaceable>AUTH_PASSWORD</replaceable>]
|
|
[--os-tenant-name <replaceable>AUTH_TENANT_NAME</replaceable>]
|
|
[--os-tenant-id <replaceable>AUTH_TENANT_ID</replaceable>] [--os-auth-url <replaceable>AUTH_URL</replaceable>]
|
|
[--os-region-name <replaceable>REGION_NAME</replaceable>] [--os-auth-system <replaceable>AUTH_SYSTEM</replaceable>]
|
|
[--service-type <replaceable>SERVICE_TYPE</replaceable>] [--service-name <replaceable>SERVICE_NAME</replaceable>]
|
|
[--volume-service-name <replaceable>VOLUME_SERVICE_NAME</replaceable>]
|
|
[--endpoint-type <replaceable>ENDPOINT_TYPE</replaceable>]
|
|
[--os-compute-api-version <replaceable>COMPUTE_API_VERSION</replaceable>]
|
|
[--os-cacert <replaceable>CA_CERTIFICATE</replaceable>] [--insecure]
|
|
[--bypass-url <replaceable>BYPASS_URL</replaceable>]
|
|
<replaceable>SUBCOMMAND</replaceable> ...</computeroutput></screen>
|
|
<note>
|
|
<para>This command returns a list of <command>nova</command> commands and
|
|
parameters. To obtain help for a subcommand, run:</para>
|
|
<screen><prompt>$</prompt> <userinput>nova help <replaceable>SUBCOMMAND</replaceable></userinput></screen>
|
|
<para>You can also refer to the <link
|
|
xlink:href="http://docs.openstack.org/cli-reference/content/">
|
|
<citetitle>OpenStack Command-Line Reference</citetitle></link> for a
|
|
complete listing of <command>nova</command> commands and parameters.</para>
|
|
</note>
|
|
</step>
|
|
<step>
|
|
<para>Set the required parameters as environment variables to make running commands
|
|
easier. For example, you can add <parameter>--os-username</parameter> as a
|
|
<command>nova</command> option, or set it as an environment variable. To set
|
|
the user name, password, and tenant as environment variables, use:</para>
|
|
<screen><prompt>$</prompt> <userinput>export OS_USERNAME=joecool</userinput>
|
|
<prompt>$</prompt> <userinput>export OS_PASSWORD=coolword</userinput>
|
|
<prompt>$</prompt> <userinput>export OS_TENANT_NAME=coolu</userinput> </screen>
|
|
</step>
|
|
<step>
|
|
<para>Using the Identity Service, you are supplied with an authentication endpoint,
|
|
which Compute recognizes as the <literal>OS_AUTH_URL</literal>.</para>
|
|
<screen><prompt>$</prompt> <userinput>export OS_AUTH_URL=http://hostname:5000/v2.0</userinput>
|
|
<prompt>$</prompt> <userinput>export NOVA_VERSION=1.1</userinput></screen>
|
|
</step>
|
|
</procedure>
|
|
<section xml:id="section_euca2ools">
|
|
<title>Use the euca2ools commands</title>
|
|
<para>For a command-line interface to EC2 API calls, use the
|
|
<command>euca2ools</command> command-line tool. See <link
|
|
xlink:href="http://open.eucalyptus.com/wiki/Euca2oolsGuide_v1.3"
|
|
>http://open.eucalyptus.com/wiki/Euca2oolsGuide_v1.3</link></para>
|
|
</section>
|
|
<xi:include href="../../common/section_cli_nova_usage_statistics.xml"/>
|
|
</section>
|
|
<section xml:id="section_manage-logs">
|
|
<title>Manage logs</title>
|
|
<simplesect>
|
|
<title>Logging module</title>
|
|
<para>To specify a configuration file to change the logging behavior, add this line to
|
|
the <filename>/etc/nova/nova.conf</filename> file . To change the logging level,
|
|
such as (<literal>DEBUG</literal>, <literal>INFO</literal>,
|
|
<literal>WARNING</literal>, <literal>ERROR</literal>), use:
|
|
<programlisting language="ini">log-config=/etc/nova/logging.conf</programlisting></para>
|
|
<para>The logging configuration file is an ini-style configuration file, which must
|
|
contain a section called <literal>logger_nova</literal>, which controls the behavior
|
|
of the logging facility in the <literal>nova-*</literal> services. For
|
|
example:<programlisting language="ini">[logger_nova]
|
|
level = INFO
|
|
handlers = stderr
|
|
qualname = nova</programlisting></para>
|
|
<para>This example sets the debugging level to <literal>INFO</literal> (which is less
|
|
verbose than the default <literal>DEBUG</literal> setting). <itemizedlist>
|
|
<listitem>
|
|
<para>For more details on the logging configuration syntax, including the
|
|
meaning of the <literal>handlers</literal> and
|
|
<literal>quaname</literal> variables, see the <link
|
|
xlink:href="http://docs.python.org/release/2.7/library/logging.html#configuration-file-format"
|
|
>Python documentation on logging configuration file format
|
|
</link>f.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>For an example <filename>logging.conf</filename> file with various
|
|
defined handlers, see the <link
|
|
xlink:href="http://docs.openstack.org/juno/config-reference/content/">
|
|
<citetitle>OpenStack Configuration
|
|
Reference</citetitle></link>.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
</simplesect>
|
|
<simplesect>
|
|
<title>Syslog</title>
|
|
<para>You can configure OpenStack Compute services to send logging information to
|
|
<systemitem>syslog</systemitem>. This is useful if you want to use
|
|
<systemitem>rsyslog</systemitem>, 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 <systemitem>syslog</systemitem>. To do so,
|
|
add the following lines to:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><filename>/etc/nova/nova.conf</filename></para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><filename>/etc/keystone/keystone.conf</filename></para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><filename>/etc/glance/glance-api.conf</filename></para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><filename>/etc/glance/glance-registry.conf</filename></para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><filename>/etc/cinder/cinder.conf</filename></para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<programlisting language="ini">verbose = False
|
|
debug = False
|
|
use_syslog = True
|
|
syslog_log_facility = LOG_LOCAL0</programlisting>
|
|
<para>In addition to enabling <systemitem>syslog</systemitem>, these settings also turn
|
|
off more verbose output and debugging output from the log.<note>
|
|
<para>Although the example above uses the same local facility for each service
|
|
(<literal>LOG_LOCAL0</literal>, which corresponds to
|
|
<systemitem>syslog</systemitem> facility <literal>LOCAL0</literal>), 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. <systemitem>syslog</systemitem> allows you to define up
|
|
to eight local facilities, <literal>LOCAL0, LOCAL1, ..., LOCAL7</literal>.
|
|
For more details, see the <systemitem>syslog</systemitem>
|
|
documentation.</para>
|
|
</note></para>
|
|
</simplesect>
|
|
<simplesect>
|
|
<title>Rsyslog</title>
|
|
<para><systemitem>rsyslog</systemitem> is a useful tool for setting up a centralized log
|
|
server across multiple machines. We briefly describe the configuration to set up an
|
|
<systemitem>rsyslog</systemitem> server; a full treatment of
|
|
<systemitem>rsyslog</systemitem> is beyond the scope of this document. We assume
|
|
<systemitem>rsyslog</systemitem> has already been installed on your hosts
|
|
(default for most Linux distributions).</para>
|
|
<para>This example provides a minimal configuration for
|
|
<filename>/etc/rsyslog.conf</filename> on the log server host, which receives
|
|
the log files:</para>
|
|
<programlisting language="bash"># provides TCP syslog reception
|
|
$ModLoad imtcp
|
|
$InputTCPServerRun 1024</programlisting>
|
|
<para>Add a filter rule to <filename>/etc/rsyslog.conf</filename> which looks for a host
|
|
name. The example below uses <replaceable>COMPUTE_01</replaceable> as an example of
|
|
a compute host name:</para>
|
|
<programlisting language="bash">:hostname, isequal, "<replaceable>COMPUTE_01</replaceable>" /mnt/rsyslog/logs/compute-01.log</programlisting>
|
|
<para>On each compute host, create a file named
|
|
<filename>/etc/rsyslog.d/60-nova.conf</filename>, with the following
|
|
content:</para>
|
|
<programlisting language="bash"># 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</programlisting>
|
|
<para>Once you have created this file, restart your <systemitem>rsyslog</systemitem>
|
|
daemon. Error-level log messages on the compute hosts should now be sent to your log
|
|
server.</para>
|
|
</simplesect>
|
|
<simplesect>
|
|
<title>Serial console</title>
|
|
<para>The serial console provides a useful way to examine kernel
|
|
output and other system messages during troubleshooting in cases
|
|
where an instance lacks network connectivity.</para>
|
|
<para>Releases prior to Juno only support read-only access via the
|
|
serial console using the <command>os-GetSerialOutput</command>
|
|
server action. Most cloud images enable this feature by
|
|
default. For more information, see
|
|
<link linkend="section_compute-empty-log-output">Troubleshoot
|
|
Compute</link>.</para>
|
|
<para>Juno and later releases support read-write access via the
|
|
serial console using the <command>os-GetSerialConsole</command>
|
|
server action. This feature also requires a websocket client to
|
|
access the serial console.</para>
|
|
<procedure>
|
|
<title>To configure read-write serial console access</title>
|
|
<para>On a compute node, edit the
|
|
<filename>/etc/nova/nova.conf</filename> file and complete
|
|
the following actions:</para>
|
|
<step>
|
|
<para>In the <parameter>[serial_console]</parameter> section,
|
|
enable the serial console:</para>
|
|
<programlisting language="ini">[serial_console]
|
|
...
|
|
enabled = true</programlisting>
|
|
</step>
|
|
<step>
|
|
<para>In the same section, configure the serial console proxy
|
|
similar to graphical console proxies:</para>
|
|
<programlisting language="ini">[serial_console]
|
|
...
|
|
base_url = ws://<replaceable>controller</replaceable>:6083/
|
|
listen = 0.0.0.0
|
|
proxyclient_address = <replaceable>MANAGEMENT_INTERFACE_IP_ADDRESS</replaceable></programlisting>
|
|
<para>The <option>base_url</option> option specifies the base
|
|
URL that clients receive from the API upon requesting a
|
|
serial console. Typically, this refers to the hostname of
|
|
the controller node.</para>
|
|
<para>The <option>listen</option> option specifies on
|
|
which network interface the
|
|
<systemitem class="service">nova-compute</systemitem>
|
|
listens for virtual console connections. Typically, this
|
|
uses 0.0.0.0 to enable listening on all interfaces.</para>
|
|
<para>The <option>proxyclient_address</option> specifies
|
|
to which network interface the proxy should connect.
|
|
Typically, this refers to the IP address of the
|
|
management interface.</para>
|
|
</step>
|
|
</procedure>
|
|
<para>Enabling read-write serial console access causes Compute
|
|
to add serial console information to the Libvirt XML file for
|
|
the instance. For example:</para>
|
|
<programlisting language="xml"><console type='tcp'>
|
|
<source mode='bind' host='127.0.0.1' service='10000'/>
|
|
<protocol type='raw'/>
|
|
<target type='serial' port='0'/>
|
|
<alias name='serial0'/>
|
|
</console></programlisting>
|
|
<procedure>
|
|
<title>To access the serial console on an instance</title>
|
|
<step>
|
|
<para>Use the <command>nova get-serial-proxy</command>
|
|
command to retrieve the websocket URL for the
|
|
instance serial console:</para>
|
|
<screen><prompt>$</prompt> <userinput>nova get-serial-proxy <replaceable>INSTANCE_NAME</replaceable></userinput>
|
|
<computeroutput>+--------+-----------------------------------------------------------------+
|
|
| Type | Url |
|
|
+--------+-----------------------------------------------------------------+
|
|
| serial | ws://127.0.0.1:6083/?token=18510769-71ad-4e5a-8348-4218b5613b3d |
|
|
+--------+-----------------------------------------------------------------+</computeroutput></screen>
|
|
<para>Alternatively, use the API directly:</para>
|
|
<screen><prompt>$</prompt> <userinput>curl -i 'http://<controller>:8774/v2/<tenant_uuid>/servers/<instance_uuid>/action' \
|
|
-X POST \
|
|
-H "Accept: application/json" \
|
|
-H "Content-Type: application/json" \
|
|
-H "X-Auth-Project-Id: <project_id>" \
|
|
-H "X-Auth-Token: <auth_token>" \
|
|
-d '{"os-getSerialConsole": {"type": "serial"}}'</userinput></screen>
|
|
</step>
|
|
<step>
|
|
<para>Use Python websocket with the URL to generate
|
|
<literal>.send</literal>, <literal>.recv</literal>,
|
|
and <literal>.fileno</literal> methods for serial
|
|
console access. For example:</para>
|
|
<programlisting language="python">import websocket
|
|
ws = websocket.create_connection(
|
|
'ws://127.0.0.1:6083/?token=18510769-71ad-4e5a-8348-4218b5613b3d',
|
|
subprotocols=['binary', 'base64'])</programlisting>
|
|
<para>Alternatively, use a Python websocket client such as
|
|
<link xlink:href="https://github.com/larsks/novaconsole/"
|
|
/>.</para>
|
|
</step>
|
|
</procedure>
|
|
<note>
|
|
<para>Enabling the serial console disables typical instance logging
|
|
via the <command>nova console-log</command> command.
|
|
Kernel output and other system messages become invisible
|
|
unless actively viewing the serial console.</para>
|
|
</note>
|
|
</simplesect>
|
|
</section>
|
|
<xi:include href="section_compute-rootwrap.xml"/>
|
|
<xi:include href="section_compute-configure-migrations.xml"/>
|
|
<section xml:id="section_live-migration-usage">
|
|
<title>Migrate instances</title>
|
|
<para>Before starting migrations, review the <link
|
|
linkend="section_configuring-compute-migrations">Configure migrations
|
|
section</link>.</para>
|
|
<para>Migration provides a scheme to migrate running instances from one OpenStack Compute
|
|
server to another OpenStack Compute server.</para>
|
|
<procedure>
|
|
<title>To migrate instances</title>
|
|
<step>
|
|
<para>Look at the running instances, to get the ID of the instance you wish to
|
|
migrate.</para>
|
|
<screen><prompt>$</prompt> <userinput>nova list</userinput>
|
|
<computeroutput><![CDATA[+--------------------------------------+------+--------+-----------------+
|
|
| ID | Name | Status |Networks |
|
|
+--------------------------------------+------+--------+-----------------+
|
|
| d1df1b5a-70c4-4fed-98b7-423362f2c47c | vm1 | ACTIVE | private=a.b.c.d |
|
|
| d693db9e-a7cf-45ef-a7c9-b3ecb5f22645 | vm2 | ACTIVE | private=e.f.g.h |
|
|
+--------------------------------------+------+--------+-----------------+]]></computeroutput></screen>
|
|
</step>
|
|
<step>
|
|
<para>Look at information associated with that instance. This example uses 'vm1'
|
|
from above.</para>
|
|
<screen><prompt>$</prompt> <userinput>nova show d1df1b5a-70c4-4fed-98b7-423362f2c47c</userinput>
|
|
<computeroutput><![CDATA[+-------------------------------------+----------------------------------------------------------+
|
|
| Property | Value |
|
|
+-------------------------------------+----------------------------------------------------------+
|
|
...
|
|
| OS-EXT-SRV-ATTR:host | HostB |
|
|
...
|
|
| flavor | m1.tiny |
|
|
| id | d1df1b5a-70c4-4fed-98b7-423362f2c47c |
|
|
| name | vm1 |
|
|
| private network | a.b.c.d |
|
|
| status | ACTIVE |
|
|
...
|
|
+-------------------------------------+----------------------------------------------------------+]]></computeroutput></screen>
|
|
<para>In this example, vm1 is running on HostB.</para>
|
|
</step>
|
|
<step>
|
|
<para>Select the compute node to which instances will be migrated to:</para>
|
|
<screen><prompt>#</prompt> <userinput>nova service-list</userinput>
|
|
<computeroutput>+------------------+------------+----------+---------+-------+----------------------------+-----------------+
|
|
| 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 | - |
|
|
+------------------+------------+----------+---------+-------+----------------------------+-----------------+</computeroutput></screen>
|
|
<para>In this example, HostC can be picked up because <systemitem class="service"
|
|
>nova-compute</systemitem> is running on it.</para>
|
|
</step>
|
|
<step>
|
|
<para>Ensure that HostC has enough resources for migration.</para>
|
|
<screen><prompt>#</prompt> <userinput>nova host-describe HostC</userinput>
|
|
<computeroutput>+-----------+------------+-----+-----------+---------+
|
|
| 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 |
|
|
+-----------+------------+-----+-----------+---------+</computeroutput></screen>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><emphasis role="bold">cpu:</emphasis>the number of cpu</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">memory_mb:</emphasis>total amount of memory (in
|
|
MB)</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">disk_gb:</emphasis>total amount of space for
|
|
NOVA-INST-DIR/instances (in GB)</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">1st line shows </emphasis>total amount of
|
|
resources for the physical server.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">2nd line shows </emphasis>currently used
|
|
resources.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">3rd line shows </emphasis>maximum used
|
|
resources.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">4th line and under</emphasis> shows the resource
|
|
for each project.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</step>
|
|
<step>
|
|
<para>Use the <command>nova live-migration</command> command to migrate the
|
|
instances:<screen><prompt>$</prompt> <userinput>nova live-migration <replaceable>SERVER</replaceable> <replaceable>HOST_NAME</replaceable></userinput></screen></para>
|
|
<para>Where <replaceable>SERVER</replaceable> can be the ID or name of the instance.
|
|
For example:</para>
|
|
<screen><prompt>$</prompt> <userinput>nova live-migration d1df1b5a-70c4-4fed-98b7-423362f2c47c HostC</userinput><computeroutput>
|
|
<![CDATA[Migration of d1df1b5a-70c4-4fed-98b7-423362f2c47c initiated.]]></computeroutput></screen>
|
|
<para>Ensure instances are migrated successfully with <command>nova list</command>.
|
|
If instances are still running on HostB, check log files (src/dest <systemitem
|
|
class="service">nova-compute</systemitem> and <systemitem class="service"
|
|
>nova-scheduler</systemitem>) to determine why.</para>
|
|
<note>
|
|
<para>Although the <command>nova</command> command is called
|
|
<command>live-migration</command>, under the default Compute
|
|
configuration options, the instances are suspended before migration.</para>
|
|
<para>For more details, see <link
|
|
xlink:href="http://docs.openstack.org/juno/config-reference/content/list-of-compute-config-options.html"
|
|
>Configure migrations</link> in <citetitle>OpenStack Configuration
|
|
Reference</citetitle>.</para>
|
|
</note>
|
|
</step>
|
|
</procedure>
|
|
</section>
|
|
<xi:include href="../../common/section_compute-configure-console.xml"/>
|
|
<xi:include href="section_compute-configure-service-groups.xml"/>
|
|
<xi:include href="section_compute-security.xml"/>
|
|
<xi:include href="section_compute-recover-nodes.xml"/>
|
|
</section>
|