openstack-manuals/doc/common/section_cli_nova_customize_flavors.xml

346 lines
17 KiB
XML

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE section[
<!ENTITY % openstack SYSTEM "entities/openstack.ent">
%openstack;
]>
<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="customize-flavors">
<title>Flavors</title>
<para>Admin users can use the <command>nova flavor-</command>
commands to customize and manage flavors. To see the available
flavor-related commands, run:</para>
<screen><prompt>$</prompt> <userinput>nova help | grep flavor-</userinput>
<computeroutput> flavor-access-add Add flavor access for the given tenant.
flavor-access-list Print access information about the given flavor.
flavor-access-remove
Remove flavor access for the given tenant.
flavor-create Create a new flavor
flavor-delete Delete a specific flavor
flavor-key Set or unset extra_spec for a flavor.
flavor-list Print a list of available 'flavors' (sizes of
flavor-show Show details about the given flavor.</computeroutput></screen>
<note>
<itemizedlist>
<listitem>
<para>Configuration rights can be delegated to
additional users by redefining the access controls
for
<option>compute_extension:flavormanage</option>
in <filename>/etc/nova/policy.json</filename> on
the <systemitem class="server"
>nova-api</systemitem> server.</para>
</listitem>
<listitem>
<para>To modify an existing flavor in the dashboard,
you must delete the flavor and create a modified
one with the same name.</para>
</listitem>
</itemizedlist>
</note>
<para>Flavors define these elements:</para>
<table rules="all" width="75%">
<caption>Identity Service configuration file
sections</caption>
<col width="15%"/>
<col width="85%"/>
<thead>
<tr>
<td>Element</td>
<td>Description</td>
</tr>
</thead>
<tbody>
<tr>
<td><literal>Name</literal></td>
<td>A descriptive name.
<replaceable>XX</replaceable>.<replaceable>SIZE_NAME</replaceable>
is typically not required, though some third party
tools may rely on it.</td>
</tr>
<tr>
<td><literal>Memory_MB</literal></td>
<td>Virtual machine memory in megabytes.</td>
</tr>
<tr>
<td><literal>Disk</literal></td>
<td>Virtual root disk size in gigabytes. This is an
ephemeral disk that the base image is copied into.
When booting from a persistent volume it is not
used. The "0" size is a special case which uses
the native base image size as the size of the
ephemeral root volume.</td>
</tr>
<tr>
<td><literal>Ephemeral</literal></td>
<td>Specifies the size of a secondary ephemeral data
disk. This is an empty, unformatted disk and
exists only for the life of the instance.</td>
</tr>
<tr>
<td><literal>Swap</literal></td>
<td>Optional swap space allocation for the
instance.</td>
</tr>
<tr>
<td><literal>VCPUs</literal></td>
<td>Number of virtual CPUs presented to the
instance.</td>
</tr>
<tr>
<td><literal>RXTX_Factor</literal></td>
<td>Optional property allows created servers to have a different bandwidth cap than
that defined in the network they are attached to. This factor is multiplied by
the rxtx_base property of the network. Default value is 1.0. That is, the same
as attached network. This parameter is only available for Xen or NSX based
systems.</td>
</tr>
<tr>
<td><literal>Is_Public</literal></td>
<td>Boolean value, whether flavor is available to all
users or private to the tenant it was created in.
Defaults to True.</td>
</tr>
<tr>
<td><literal>extra_specs</literal></td>
<td><para>Key and value pairs that define on which
compute nodes a flavor can run. These pairs
must match corresponding pairs on the compute
nodes. Use to implement special resources,
such as flavors that run on only compute nodes
with GPU hardware.</para></td>
</tr>
</tbody>
</table>
<para>Flavor customization can be limited by the hypervisor in
use. For example the <systemitem>libvirt</systemitem> driver
enables quotas on CPUs available to a VM, disk tuning,
bandwidth I/O, watchdog behavior, random number generator
device control, and instance VIF traffic control.</para>
<variablelist>
<varlistentry>
<term>CPU limits</term>
<listitem>
<para>You can configure the CPU limits with control
parameters with the <command>nova</command>
client. For example, to configure the I/O limit,
use:</para>
<screen><prompt>$</prompt> <userinput>nova flavor-key m1.small set quota:read_bytes_sec=10240000</userinput>
<prompt>$</prompt> <userinput>nova flavor-key m1.small set quota:write_bytes_sec=10240000</userinput></screen>
<para>Use these optional parameters to control weight
shares, enforcement intervals for runtime quotas,
and a quota for maximum allowed bandwidth:</para>
<itemizedlist>
<listitem>
<para><parameter>cpu_shares</parameter>. Specifies the proportional weighted share
for the domain. If this element is
omitted, the service defaults to the OS
provided defaults. There is no unit for
the value; it is a relative measure based
on the setting of other VMs. For example,
a VM configured with value 2048 gets twice
as much CPU time as a VM configured with
value 1024.</para>
</listitem>
<listitem>
<para><parameter>cpu_period</parameter>. Specifies the enforcement interval (unit:
microseconds) for QEMU and LXC
hypervisors. Within a period, each VCPU of
the domain is not allowed to consume more
than the quota worth of runtime. The value
should be in range <literal>[1000,
1000000]</literal>. A period with
value 0 means no value.</para>
</listitem>
<listitem>
<para><parameter>cpu_quota</parameter>. Specifies the maximum allowed bandwidth
(unit: microseconds). A domain with a
negative-value quota indicates that the
domain has infinite bandwidth, which means
that it is not bandwidth controlled. The
value should be in range <literal>[1000,
18446744073709551]</literal> or less
than 0. A quota with value 0 means no
value. You can use this feature to ensure
that all vCPUs run at the same speed. For
example:</para>
<screen><prompt>$</prompt> <userinput>nova flavor-key m1.low_cpu set quota:cpu_quota=10000</userinput>
<prompt>$</prompt> <userinput>nova flavor-key m1.low_cpu set quota:cpu_period=20000</userinput></screen>
<para>In this example, the instance of
<literal>m1.low_cpu</literal> can only
consume a maximum of 50% CPU of a physical
CPU computing capability.</para>
</listitem>
</itemizedlist>
</listitem>
</varlistentry>
<varlistentry>
<term>Disk tuning</term>
<listitem>
<para>Using disk I/O quotas, you can set maximum disk
write to 10 MB per second for a VM user. For
example:</para>
<screen><prompt>$</prompt> <userinput>nova flavor-key m1.medium set disk_write_bytes_sec=10485760</userinput></screen>
<para>The disk I/O options are:</para>
<itemizedlist>
<listitem>
<para>disk_read_bytes_sec</para>
</listitem>
<listitem>
<para>disk_read_iops_sec</para>
</listitem>
<listitem>
<para>disk_write_bytes_sec</para>
</listitem>
<listitem>
<para>disk_write_iops_sec</para>
</listitem>
<listitem>
<para>disk_total_bytes_sec</para>
</listitem>
<listitem>
<para>disk_total_iops_sec</para>
</listitem>
</itemizedlist>
<para>The vif I/O options are:</para>
<itemizedlist>
<listitem>
<para>vif_inbound_ average</para>
</listitem>
<listitem>
<para>vif_inbound_burst</para>
</listitem>
<listitem>
<para>vif_inbound_peak</para>
</listitem>
<listitem>
<para>vif_outbound_ average</para>
</listitem>
<listitem>
<para>vif_outbound_burst</para>
</listitem>
<listitem>
<para>vif_outbound_peak</para>
</listitem>
</itemizedlist>
</listitem>
</varlistentry>
<varlistentry>
<term>Bandwidth I/O</term>
<listitem>
<para>Incoming and outgoing traffic can be shaped
independently. The bandwidth element can have at
most, one inbound and at most, one outbound child
element. If you leave any of these child elements
out, no quality of service (QoS) is applied on
that traffic direction. So, if you want to shape
only the network's incoming traffic, use inbound
only (and vice versa). Each element has one
mandatory attribute average, which specifies the
average bit rate on the interface being
shaped.</para>
<para>There are also two optional attributes
(integer): <option>peak</option>, which specifies
the maximum rate at which a bridge can send data
(kilobytes/second), and <option>burst</option>,
the amount of bytes that can be burst at peak
speed (kilobytes). The rate is shared equally
within domains connected to the network.</para>
<para>The following example configures a bandwidth
limit for instance network traffic:</para>
<screen><prompt>$</prompt> <userinput>nova flavor-key m1.small set quota:inbound_average=10240</userinput>
<prompt>$</prompt> <userinput>nova flavor-key m1.small set quota:outbound_average=10240</userinput></screen>
</listitem>
</varlistentry>
<varlistentry>
<term>Watchdog behavior</term>
<listitem>
<para>For the <systemitem>libvirt</systemitem> driver,
you can enable and set the behavior of a virtual
hardware watchdog device for each flavor. Watchdog
devices keep an eye on the guest server, and carry
out the configured action, if the server hangs.
The watchdog uses the i6300esb device (emulating a
PCI Intel 6300ESB). If
<literal>hw_watchdog_action</literal> is not
specified, the watchdog is disabled.</para>
<para>To set the behavior, use:</para>
<screen><prompt>$</prompt> <userinput>nova flavor-key <replaceable>FLAVOR-NAME</replaceable> set hw_watchdog_action=<replaceable>ACTION</replaceable></userinput></screen>
<para>Valid <replaceable>ACTION</replaceable> values
are:</para>
<itemizedlist>
<listitem>
<para><literal>disabled</literal>&mdash;(default)
The device is not attached.</para>
</listitem>
<listitem>
<para><literal>reset</literal>&mdash;Forcefully
reset the guest.</para>
</listitem>
<listitem>
<para><literal>poweroff</literal>&mdash;Forcefully
power off the guest.</para>
</listitem>
<listitem>
<para><literal>pause</literal>&mdash;Pause the
guest.</para>
</listitem>
<listitem>
<para><literal>none</literal>&mdash;Only
enable the watchdog; do nothing if the
server hangs.</para>
</listitem>
</itemizedlist>
<note>
<para>Watchdog behavior set using a specific
image's properties will override behavior set
using flavors.</para>
</note>
</listitem>
</varlistentry>
<varlistentry>
<term>Random-number generator</term>
<listitem>
<para>If a random-number generator device has been
added to the instance through its image
properties, the device can be enabled and
configured using:</para>
<screen><prompt>$</prompt> <userinput>nova flavor-key <replaceable>FLAVOR-NAME</replaceable> set hw_rng:allowed=True</userinput>
<prompt>$</prompt> <userinput>nova flavor-key <replaceable>FLAVOR-NAME</replaceable> set hw_rng:rate_bytes=<replaceable>RATE-BYTES</replaceable></userinput>
<prompt>$</prompt> <userinput>nova flavor-key <replaceable>FLAVOR-NAME</replaceable> set hw_rng:rate_period=<replaceable>RATE-PERIOD</replaceable></userinput></screen>
<para>Where:</para>
<itemizedlist>
<listitem>
<para><replaceable>RATE-BYTES</replaceable>&mdash;(Integer)
Allowed amount of bytes that the guest can
read from the host's entropy per
period.</para>
</listitem>
<listitem>
<para><replaceable>RATE-PERIOD</replaceable>&mdash;(Integer)
Duration of the read period in
seconds.</para>
</listitem>
</itemizedlist>
</listitem>
</varlistentry>
<varlistentry>
<term>Instance VIF traffic control</term>
<listitem>
<para>Flavors can also be assigned to particular
projects. By default, a flavor is public and
available to all projects. Private flavors are
only accessible to those on the access list and
are invisible to other projects. To create and
assign a private flavor to a project, run these
commands:</para>
<screen><prompt>$</prompt> <userinput>nova flavor-create --is-public false p1.medium auto 512 40 4</userinput>
<prompt>$</prompt> <userinput>nova flavor-access-add 259d06a0-ba6d-4e60-b42d-ab3144411d58 86f94150ed744e08be565c2ff608eef9</userinput></screen>
</listitem>
</varlistentry>
</variablelist>
</section>