Adds VNC console information; cleanup
* Adds VNC console document from nova/doc/runnova/vncconsole.rst * Reformat on ch_identity_mgmt.xml * Adds starting images to the identity management * Adds VNC console to the interfaces chapter * Updates the dashboard screenshot to Essex dash * Updates tutorial to use TryStack * Adds docbook conversion of API Programming Guide Change-Id: I403733b8bc19ccf697f98506df6de3d8837ec023
This commit is contained in:
annegentle
parent
4a821e95d4
commit
ef6c90e87b
doc/src/docbkx
common
openstack-api-programming
openstack-compute-admin
@ -43,6 +43,7 @@
|
||||
on the Internet. This store is readonly.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>This chapter assumes you have a working installation of the
|
||||
Image Service, with a working endpoint and users created in
|
||||
the Identity service, plus you have sourced the environment
|
||||
@ -141,6 +142,7 @@ chmod 600 test.pem
|
||||
<literallayout class="monospaced">sudo -i</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="deleting-instances">
|
||||
|
||||
<title>Deleting Instances</title>
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -168,27 +168,54 @@
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<para>Here is a simple example <filename>nova.conf</filename> file for a
|
||||
small private cloud, with all the cloud controller services, database
|
||||
server, and messaging server on the same server.</para>
|
||||
<para>Here is a simple example <filename>nova.conf</filename>
|
||||
file for a small private cloud, with all the cloud controller
|
||||
services, database server, and messaging server on the same
|
||||
server. In this case, CONTROLLER_IP represents the IP address
|
||||
of a central server, BRIDGE_INTERFACE represents the bridge
|
||||
such as br100, the NETWORK_INTERFACE represents an interface
|
||||
to your VLAN setup, and passwords are represented as
|
||||
DB_PASSWORD_COMPUTE for your Compute (nova) database password,
|
||||
and RABBIT PASSWORD represents the password to your rabbit
|
||||
installation.</para>
|
||||
|
||||
<programlisting>
|
||||
--dhcpbridge_flagfile=/etc/nova/nova.conf
|
||||
--dhcpbridge=/bin/nova-dhcpbridge
|
||||
--logdir=/var/log/nova
|
||||
--state_path=/var/lib/nova
|
||||
--verbose
|
||||
--use_deprecated_auth
|
||||
--ec2_host=184.106.239.134
|
||||
--ec2_url=http://184.106.239.134:8773/services/Cloud
|
||||
--osapi_host=http://184.106.239.134
|
||||
--s3_host=184.106.239.134
|
||||
--rabbit_host=184.106.239.134
|
||||
--fixed_range=192.168.0.0/16
|
||||
--network_size=8
|
||||
--glance_api_servers=184.106.239.134:9292
|
||||
--routing_source_ip=184.106.239.134
|
||||
--sql_connection=mysql://nova:notnova@184.106.239.134/nova
|
||||
<programlisting>[DEFAULT]
|
||||
verbose=True
|
||||
instances_path=/var/openstack/compute/instances
|
||||
auth_strategy=keystone
|
||||
allow_resize_to_same_host=True
|
||||
root_helper=sudo /opt/openstack/nova/bin/nova-rootwrap
|
||||
compute_scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler
|
||||
dhcpbridge_flagfile=/etc/openstack/compute.conf
|
||||
fixed_range=192.168.0.0/12
|
||||
s3_host=${CONTROLLER_IP}
|
||||
network_manager=nova.network.manager.FlatManager
|
||||
volume_group=nova-volumes
|
||||
volume_name_template=volume-%08x
|
||||
iscsi_helper=tgtadm
|
||||
osapi_compute_extension=nova.api.openstack.compute.contrib.standard_extensions
|
||||
my_ip=${MY_IP}
|
||||
public_interface=${BRIDGE_INTERFACE}
|
||||
vlan_interface=${NETWORK_INTERFACE}
|
||||
flat_network_bridge=${BRIDGE_INTERFACE}
|
||||
flat_interface=${NETWORK_INTERFACE}
|
||||
sql_connection=postgresql://openstack_compute:${DB_PASSWORD_COMPUTE}@${CONTROLLER_IP}/openstack_compute
|
||||
libvirt_type=kvm
|
||||
instance_name_template=instance-%08x
|
||||
novncproxy_base_url=http://${CONTROLLER_IP}:6080/vnc_auto.html
|
||||
xvpvncproxy_base_url=http://${CONTROLLER_IP}:6081/console
|
||||
vncserver_listen=127.0.0.1
|
||||
vncserver_proxyclient_address=127.0.0.1
|
||||
api_paste_config=/var/openstack/compute/api-paste.ini
|
||||
image_service=nova.image.glance.GlanceImageService
|
||||
ec2_dmz_host=${CONTROLLER_IP}
|
||||
rabbit_host=${CONTROLLER_IP}
|
||||
rabbit_password=${RABBIT_PASSWORD}
|
||||
glance_api_servers=${CONTROLLER_IP}:9292
|
||||
force_dhcp_release=True
|
||||
flat_injected=True
|
||||
connection_type=libvirt
|
||||
firewall_driver=nova.virt.libvirt.firewall.IptablesFirewallDriver
|
||||
</programlisting>
|
||||
|
||||
<para>Create a “nova” group, so you can set permissions on the
|
||||
@ -196,40 +223,35 @@
|
||||
|
||||
<screen><prompt>$</prompt> <userinput>sudo addgroup nova</userinput></screen>
|
||||
|
||||
<para>The <filename>nova.config</filename> file should have its owner
|
||||
set to <literal>root:nova</literal>, and mode set to
|
||||
<literal>0640</literal>, since the file contains your MySQL server’s
|
||||
username and password. You also want to ensure that the
|
||||
<literal>nova</literal> user belongs to the <literal>nova</literal>
|
||||
group.</para>
|
||||
<para>The <filename>nova.config</filename> file should have its
|
||||
owner set to <literal>root:nova</literal>, and mode set to
|
||||
<literal>0640</literal>, since the file could contain your
|
||||
MySQL server’s username and password. You also want to ensure
|
||||
that the <literal>nova</literal> user belongs to the
|
||||
<literal>nova</literal> group.</para>
|
||||
|
||||
<screen><prompt>$</prompt> <userinput>sudo usermod -g nova nova</userinput>
|
||||
<prompt>$</prompt> <userinput>chown -R root:nova /etc/nova</userinput>
|
||||
<prompt>$</prompt> <userinput>chmod 640 /etc/nova/nova.conf</userinput>
|
||||
</screen>
|
||||
<prompt>$</prompt> <userinput>chmod 640 /etc/nova/nova.conf</userinput></screen>
|
||||
</section>
|
||||
|
||||
<section xml:id="setting-up-openstack-compute-environment-on-the-compute-node">
|
||||
<title>Setting Up OpenStack Compute Environment on the Compute
|
||||
Node</title>
|
||||
|
||||
<para>These are the commands you run to ensure the database schema is
|
||||
current, and then set up a user and project, if you are using built-in
|
||||
auth with the <literal>--use_deprecated_auth</literal> flag rather than
|
||||
the Identity Service:</para>
|
||||
<para>These are the commands you run to ensure the database
|
||||
schema is current:</para>
|
||||
|
||||
<screen><prompt>$</prompt> <userinput>nova-manage db sync</userinput>
|
||||
<prompt>$</prompt> <userinput>nova-manage user admin <replaceable><user_name></replaceable></userinput>
|
||||
<prompt>$</prompt> <userinput>nova-manage project create <replaceable><project_name> <user_name></replaceable></userinput>
|
||||
<prompt>$</prompt> <userinput>nova-manage network create <replaceable><network-label> <project-network> <number-of-networks-in-project> <addresses-in-each-network></replaceable></userinput>
|
||||
<screen><prompt>$</prompt> <userinput>nova-manage db sync</userinput></screen>
|
||||
<para>You also need to populate the database with the network configuration information that Compute obtains from the <filename>nova.conf</filename> file.
|
||||
</para>
|
||||
<screen><prompt>$</prompt> <userinput>nova-manage network create <replaceable><network-label> <project-network> <number-of-networks-in-project> <addresses-in-each-network></replaceable></userinput>
|
||||
</screen>
|
||||
|
||||
<para>Here is an example of what this looks like with real values
|
||||
entered:</para>
|
||||
|
||||
<screen><prompt>$</prompt> <userinput>nova-manage db sync</userinput>
|
||||
<prompt>$</prompt> <userinput>nova-manage user admin dub</userinput>
|
||||
<prompt>$</prompt> <userinput>nova-manage project create dubproject dub</userinput>
|
||||
<prompt>$</prompt> <userinput>nova-manage network create novanet 192.168.0.0/24 1 256</userinput></screen>
|
||||
|
||||
<para>For this example, the number of IPs is <literal>/24</literal>
|
||||
@ -883,8 +905,8 @@ xenapi_remap_vbd_dev=true
|
||||
hypervisors and virtualization standards. Configuring and
|
||||
running OpenStack Compute to use a particular hypervisor takes
|
||||
several installation and configuration steps. The
|
||||
<literal>libvirt_type</literal> configuration option
|
||||
indicates which hypervisor will be used. Refer <xref
|
||||
<literal>libvirt_type</literal> configuration option indicates
|
||||
which hypervisor will be used. Refer to <xref
|
||||
linkend="hypervisor-configuration-basics"> Hypervisor
|
||||
configuration basics </xref> for more details.</para>
|
||||
</section>
|
||||
@ -893,35 +915,11 @@ xenapi_remap_vbd_dev=true
|
||||
<title>Configuring Authentication and Authorization</title>
|
||||
|
||||
<para>There are different methods of authentication for the
|
||||
OpenStack Compute project. The default setting is to use the
|
||||
<filename>novarc</filename> file that contains credentials. To
|
||||
do so, set the <literal>use_deprecated_auth</literal>
|
||||
configuration option in your <filename>nova.conf</filename>,
|
||||
which is <literal>True</literal> by default. For no auth, modify
|
||||
the <filename>paste.ini</filename> that is included in the
|
||||
<filename>etc/nova</filename> directory. With additional
|
||||
configuration, you can use the OpenStack Identity Service,
|
||||
code-named Keystone. In Compute, the settings for using Keystone
|
||||
are commented lines in
|
||||
<filename>etc/nova/api-paste.ini</filename>, and Keystone also
|
||||
provides an example file in
|
||||
<filename>keystone/examples/paste/nova-api-paste.ini</filename>.
|
||||
Restart the nova-api service for these settings to be
|
||||
configured. Refer to the Identity Service Starter Guide for
|
||||
additional information.</para>
|
||||
|
||||
<para>OpenStack Compute uses an implementation of an authentication system
|
||||
structured with an Active Directory or other federated LDAP user store
|
||||
that backends to an identity manager or other SAML Policy Controller that
|
||||
then maps to groups. Credentials for API calls are stored in the project
|
||||
zip file when using this auth system. Certificate authority is also
|
||||
customized in nova.conf for the this built-in auth system.</para>
|
||||
|
||||
<para>If you see errors such as "EC2ResponseError: 403 Forbidden" it is
|
||||
likely you are trying to use euca commands without the auth system
|
||||
properly configured. Either install and use the default auth setting, or
|
||||
change out the default <filename>paste.ini</filename> file to use no auth,
|
||||
or configure the Identity Service.</para>
|
||||
OpenStack Compute project, including no authentication,
|
||||
keystone, or deprecated (which uses nova-manage commands to
|
||||
create users). With additional configuration, you can use the
|
||||
OpenStack Identity Service, code-named Keystone. Refer to
|
||||
<xref linkend="ch_identity_mgmt">Identity Management</xref> for additional information.</para>
|
||||
|
||||
<table rules="all">
|
||||
<caption>Description of <filename>nova.conf</filename>
|
||||
@ -961,13 +959,12 @@ xenapi_remap_vbd_dev=true
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td><literal>use_deprecated_auth</literal></td>
|
||||
<td><literal>auth_strategy</literal></td>
|
||||
|
||||
<td><literal>False</literal></td>
|
||||
<td><literal>keystone</literal></td>
|
||||
|
||||
<td><para><literal>True</literal> or <literal>False</literal>; Sets
|
||||
the auth system to use the zip file provided with the project files
|
||||
to store all credentials</para></td>
|
||||
<td><para>The strategy to use for auth. Supports noauth, keystone, and
|
||||
deprecated.</para></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
@ -159,5 +159,7 @@ python tools/install_venv.py
|
||||
format="PNG" />
|
||||
</imageobject>
|
||||
</mediaobject></section></section></section>
|
||||
|
||||
|
||||
<xi:include href="computevncconsole.xml"/>
|
||||
|
||||
</chapter>
|
||||
|
||||
280
doc/src/docbkx/openstack-compute-admin/computevncconsole.xml
Normal file
280
doc/src/docbkx/openstack-compute-admin/computevncconsole.xml
Normal file
@ -0,0 +1,280 @@
|
||||
<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="getting-started-with-vnc-proxy">
|
||||
<title>Using VNC Proxy for Instance Access</title>
|
||||
<?dbhtml stop-chunking?>
|
||||
<para>
|
||||
The VNC Proxy is an OpenStack component that allows users of Compute to
|
||||
access their instances through vnc clients. In Essex and beyond,
|
||||
there is support for both libvirt and XenServer using both Java
|
||||
and WebSocket clients.
|
||||
</para>
|
||||
<para>
|
||||
The VNC console connection works as follows:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
User connects to API and gets an access_url like
|
||||
http://ip:port/?token=xyz.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
User pastes URL in browser or as client parameter.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Browser/Client connects to proxy.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Proxy authorizes users token, maps the token to the -private-
|
||||
host and port of an instance's VNC server, which is located on
|
||||
the compute host. In this way, the VNC proxy works as a bridge
|
||||
between the public network, and the private host network.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Proxy initiates connection to VNC server, and continues proxying
|
||||
until the session ends
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>
|
||||
Note that in general, the VNC proxy performs multiple functions:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Bridges between public network (where clients live) and private
|
||||
network (where vncservers live)
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Mediates token authentication
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Transparently deals with hypervisor-specific connection details
|
||||
to provide a uniform client experience.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>
|
||||
Both client proxies leverage a shared service to manage token auth
|
||||
called nova-consoleauth. This service must be running in order for
|
||||
for either proxy to work. Many proxies of either type can be run
|
||||
against a single nova-consoleauth service in a cluster
|
||||
configuration.
|
||||
</para>
|
||||
<para>
|
||||
nova-consoleauth should not be confused with nova-console, which
|
||||
is a xen-specific service that is not used by the most recent VNC
|
||||
proxy architecture.
|
||||
</para>
|
||||
|
||||
<section xml:id="typical-deployment">
|
||||
<title>Typical Deployment</title>
|
||||
<para>
|
||||
A typical deployment will consist of the following components:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
One nova-consoleauth process. Typically this runs on the
|
||||
controller host.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
One or more nova-novncproxy services. This supports
|
||||
browser-based novnc clients. For simple deployments, this
|
||||
service typically will run on the same machine as nova-api,
|
||||
since it proxies between the public network and the private
|
||||
compute host network.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
One or more nova-xvpvncproxy services. This supports the
|
||||
special Java client discussed in this document. For simple
|
||||
deployments, this service typically will run on the same
|
||||
machine as nova-api, since it proxies between the public
|
||||
network and the private compute host network.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
Nova provides the ability to create access_urls through the
|
||||
os-consoles extension. Support for accessing this url is provided
|
||||
by novaclient:
|
||||
</para>
|
||||
<screen>
|
||||
nova get-vnc-console [server_id] [xvpvnc|novnc]
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
To enable vncproxy in your cloud, in addition to running one or
|
||||
both of the proxies and nova-consoleauth, you need to configure
|
||||
the following flags on your compute hosts.
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
:option:`--[no]vnc_enabled` - defaults to enabled. If this
|
||||
flag is disabled your instances will launch without VNC
|
||||
support.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
:option:`--vncserver_listen` - defaults to 127.0.0.1 This is
|
||||
the address that vncservers will bind, and should be
|
||||
overridden in production deployments as a private address.
|
||||
Applies to libvirt only. For multi-host libvirt deployments
|
||||
this should be set to a host management ip on the same network
|
||||
as the proxies.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
:option:`--vncserver_proxyclient_address` - defaults to
|
||||
127.0.0.1 This is the address of the compute host that nova
|
||||
will instruct proxies to use when connecting to instance
|
||||
vncservers. For all-in-one xen server domU deployments this
|
||||
can be set to 169.254.0.1. For multi-host xen server domU
|
||||
deployments this can be set to a dom0 management ip on the
|
||||
same network as the proxies. For multi-host libvirt
|
||||
deployments this can be set to a host management ip on the
|
||||
same network as the proxies.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
:option:`--novncproxy_base_url=[base url for client
|
||||
connections]` -this is the public base url to which clients
|
||||
will connect. "?token=abc" will be added to this url
|
||||
for the purposes of auth. When using the system as described
|
||||
in this document, an appropriate value is
|
||||
"<link xlink:href="http://$SERVICE_HOST:6080/vnc_auto.html">http://$SERVICE_HOST:6080/vnc_auto.html</link>"
|
||||
where SERVICE_HOST is a public hostname.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
:option:`--xvpvncproxy_base_url=[base url for client
|
||||
connections]` -this is the public base url to which clients
|
||||
will connect. "?token=abc" will be added to this url
|
||||
for the purposes of auth. When using the system as described
|
||||
in this document, an appropriate value is
|
||||
"<link xlink:href="http://$SERVICE_HOST:6081/console">http://$SERVICE_HOST:6081/console</link>"
|
||||
where SERVICE_HOST is a public hostname.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<section xml:id="accessing-vnc-consoles-with-a-java-client">
|
||||
<title>Accessing VNC Consoles with a Java client</title>
|
||||
<para>
|
||||
To enable support for the OpenStack Java VNC client in nova, nova
|
||||
provides the nova-xvpvncproxy service, which you should run to
|
||||
enable this feature.
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
:option:`--xvpvncproxy_port=[port]` - port to bind (defaults
|
||||
to 6081)
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
:option:`--xvpvncproxy_host=[host]` - host to bind (defaults
|
||||
to 0.0.0.0)
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>
|
||||
As a client, you will need a special Java client, which is a
|
||||
version of TightVNC slightly modified to support our token auth:
|
||||
</para>
|
||||
<screen>
|
||||
git clone https://github.com/cloudbuilders/nova-xvpvncviewer
|
||||
cd nova-xvpvncviewer
|
||||
make
|
||||
</screen>
|
||||
<para>
|
||||
Then, to create a session, first request an access url using
|
||||
python-novaclient and then run the client like so:
|
||||
</para>
|
||||
<screen>
|
||||
# Retrieve access url
|
||||
nova get-vnc-console [server_id] xvpvnc
|
||||
# Run client
|
||||
java -jar VncViewer.jar [access_url]
|
||||
</screen>
|
||||
|
||||
<note><para>Note that nova-vncproxy has been replaced with nova-novncproxy.</para>
|
||||
<para>
|
||||
The previous VNC proxy, nova-vncproxy, has been removed from the
|
||||
nova source tree and replaced with an improved server that can be
|
||||
found externally at
|
||||
<link xlink:href="http://github.com/cloudbuilders/noVNC.git">http://github.com/cloudbuilders/noVNC.git</link>
|
||||
(in a branch called vnc_redux while this patch is in review).
|
||||
</para></note>
|
||||
<para>
|
||||
To use this nova-novncproxy:
|
||||
</para>
|
||||
<screen>
|
||||
git clone http://github.com/cloudbuilders/noVNC.git
|
||||
git checkout vnc_redux
|
||||
utils/nova-novncproxy --flagfile=[path to flagfile]
|
||||
</screen>
|
||||
<para>
|
||||
The configuration option param should point to your nova config that
|
||||
includes the rabbit server address and credentials.
|
||||
</para>
|
||||
<para>
|
||||
By default, nova-novncproxy binds 0.0.0.0:6080. This can be
|
||||
configured with:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
novncproxy_port=[port]`
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
novncproxy_host=[host]`
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section xml:id="accessing-a-vnc-console-through-a-web-browser">
|
||||
<title>Accessing a VNC console through a web browser</title>
|
||||
<para>
|
||||
Retrieving an access_url for a web browser is similar to the flow
|
||||
for the Java client:
|
||||
</para>
|
||||
<screen>
|
||||
# Retrieve access url
|
||||
nova get-vnc-console [server_id] novnc
|
||||
# Then, paste the url into your web browser
|
||||
</screen>
|
||||
<para>
|
||||
Additionally, you can use horizon to access browser-based VNC
|
||||
consoles for instances.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
</section>
|
||||
Binary file not shown.
|
Before 
(image error) Size: 87 KiB After 
(image error) Size: 70 KiB
|
Loading…
x
Reference in New Issue
Block a user