From 105b4f7ae5b1c0a51bf7494856cb3a2293b270bb Mon Sep 17 00:00:00 2001 From: Summer Long Date: Mon, 14 Apr 2014 15:39:59 +1000 Subject: [PATCH] Added watchdog property key and flavor-key info Added hw_watchdog_action property key and watchdog info for flavor_key section (plus minor edits). Added note about authorized users, and reference to the page in the Admin User Guide. Closes-bug: #1287406 Closes-bug: #1287450 Change-Id: Ib404d98ce504883ae22733f681e205c641720f5a --- .../ch_cli_glance_property_keys.xml | 128 ++++---- .../section_cli_nova_customize_flavors.xml | 299 +++++++++++------- .../section_cli_nova_manage_flavors.xml | 6 + 3 files changed, 258 insertions(+), 175 deletions(-) diff --git a/doc/cli-reference/ch_cli_glance_property_keys.xml b/doc/cli-reference/ch_cli_glance_property_keys.xml index e9092b93c1..575a22d06c 100644 --- a/doc/cli-reference/ch_cli_glance_property_keys.xml +++ b/doc/cli-reference/ch_cli_glance_property_keys.xml @@ -16,6 +16,8 @@ image-update and glance image-create commands. For example: $ glance image-update img-uuid --property architecture=x86_64 + Behavior set using image properties overrides + behavior set using flavors. @@ -43,65 +45,65 @@ for this purpose. @@ -231,6 +233,26 @@ hw_video_ram. + + + + + + diff --git a/doc/common/section_cli_nova_customize_flavors.xml b/doc/common/section_cli_nova_customize_flavors.xml index eee2a9137b..c107dccd78 100644 --- a/doc/common/section_cli_nova_customize_flavors.xml +++ b/doc/common/section_cli_nova_customize_flavors.xml @@ -1,26 +1,34 @@ -
+ + + + +]> +
Flavors - Authorized users can use the nova - flavor-create command to create flavors. To see - the available flavor-related commands, run: + Admin users can use the nova flavor- commands to customize and manage + flavors. To see the available flavor-related commands, run: $ nova help | grep flavor- - flavor-access-add Add flavor access for the given tenant. + 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. + 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. - To modify an existing flavor in the dashboard, you must - delete the flavor and create a modified one with the same - name. + + Configuration rights can be delegated to additional users + by redefining the access controls for + in /etc/nova/policy.json on the + nova-api server. + To modify an existing flavor in the dashboard, you must + delete the flavor and create a modified one with the same + name. + Flavors define these elements:
Property keys
- alpha — alpha—DEC 64-bit RISC - armv7l — armv7l—ARM Cortex-A7 MPCore - cris — Ethernet, Token Ring, AXis — Code Reduced Instruction Set - i686 — cris—Ethernet, Token Ring, AXis—Code Reduced Instruction Set + i686—Intel sixth-generation x86 (P6 micro architecture) - ia64 — ia64—Itanium - lm32 — lm32—Lattice Micro32 - m68k — m68k—Motorola 68000 - microblaze — microblaze—Xilinx 32-bit FPGA (Big Endian) - microblazeel — microblazeel—Xilinx 32-bit FPGA (Little Endian) - mips — mips—MIPS 32-bit RISC (Big Endian) - mipsel — mipsel—MIPS 32-bit RISC (Little Endian) - mips64 — mips64—MIPS 64-bit RISC (Big Endian) - mips64el — mips64el—MIPS 64-bit RISC (Little Endian) - openrisc — openrisc—OpenCores RISC - parisc — parisc—HP Precision Architecture RISC - parisc64 — parisc64—HP Precision Architecture 64-bit RISC - ppc — ppc—PowerPC 32-bit - ppc64 — ppc64—PowerPC 64-bit - ppcemb — ppcemb—PowerPC (Embedded 32-bit) - s390 — s390—IBM Enterprise Systems Architecture/390 - s390x — s390x—S/390 64-bit - sh4 — sh4—SuperH SH-4 (Little Endian) - sh4eb — sh4eb—SuperH SH-4 (Big Endian) - sparc — sparc—Scalable Processor Architecture, 32-bit - sparc64 — sparc64—Scalable Processor Architecture, 64-bit - unicore32 — unicore32—Microprocessor Research and Development Center RISC Unicore32 - x86_64 — x86_64—64-bit extension of IA-32 - xtensa — xtensa—Tensilica Xtensa configurable microprocessor core - xtensaeb — xtensaeb—Tensilica Xtensa configurable microprocessor core (Big Endian) @@ -137,50 +139,50 @@ values are listed to assist you in searching for the recognized value. - arch — Arch Linux. Do not use archlinux or + arch—Arch Linux. Do not use archlinux or org.archlinux - centos — Community Enterprise Operating System. Do not use + centos—Community Enterprise Operating System. Do not use org.centos or CentOS - debian — Debian. Do not use Debian or + debian—Debian. Do not use Debian or org.debian - fedora — Fedora. Do not use Fedora, + fedora—Fedora. Do not use Fedora, org.fedora, or org.fedoraproject - freebsd — FreeBSD. Do not use org.freebsd, + freebsd—FreeBSD. Do not use org.freebsd, freeBSD, or FreeBSD - gentoo — Gentoo Linux. Do not use Gentoo or + gentoo—Gentoo Linux. Do not use Gentoo or org.gentoo - mandrake — Mandrakelinux (MandrakeSoft) distribution. Do not use + mandrake—Mandrakelinux (MandrakeSoft) distribution. Do not use mandrakelinux or MandrakeLinux - mandriva — Mandriva Linux. Do not use + mandriva—Mandriva Linux. Do not use mandrivalinux - mes — Mandriva Enterprise Server. Do not use + mes—Mandriva Enterprise Server. Do not use mandrivaent or mandrivaES - msdos — Microsoft Disc Operating System. Do not use + msdos—Microsoft Disc Operating System. Do not use ms-dos - netbsd — NetBSD. Do not use NetBSD or + netbsd—NetBSD. Do not use NetBSD or org.netbsd - netware — Novell NetWare. Do not use novell or + netware—Novell NetWare. Do not use novell or NetWare - openbsd — OpenBSD. Do not use OpenBSD or + openbsd—OpenBSD. Do not use OpenBSD or org.openbsd - opensolaris — OpenSolaris. Do not use OpenSolaris + opensolaris—OpenSolaris. Do not use OpenSolaris or org.opensolaris - opensuse — openSUSE. Do not use suse, + opensuse—openSUSE. Do not use suse, SuSE, or org.opensuse - rhel — Red Hat Enterprise Linux. Do not use + rhel—Red Hat Enterprise Linux. Do not use redhat, RedHat, or com.redhat - sled — SUSE Linux Enterprise Desktop. Do not use + sled—SUSE Linux Enterprise Desktop. Do not use com.suse - ubuntu — Ubuntu. Do not use Ubuntu, + ubuntu—Ubuntu. Do not use Ubuntu, com.ubuntu, org.ubuntu, or canonical - windows — Microsoft Windows. Do not use + windows—Microsoft Windows. Do not use com.microsoft.server or windoze @@ -206,11 +208,11 @@ interface) used for the virtual machine. - hvm — Fully virtualized. This is the mode used by QEMU and + hvm—Fully virtualized. This is the mode used by QEMU and KVM. - xen — Xen 3.0 paravirtualized. - uml — User Mode Linux paravirtualized. - exe — Executables in containers. This is the mode used by + xen—Xen 3.0 paravirtualized. + uml—User Mode Linux paravirtualized. + exe—Executables in containers. This is the mode used by LXC. Integer in MB (for example, '64')
libvirt API driverhw_watchdog_actionEnables a virtual hardware watchdog device that carries out the specified action + if the server hangs. The watchdog uses the i6300esb device (emulating a PCI + Intel 6300ESB). If hw_watchdog_action is not specified, the + watchdog is disabled. + disabled—(default) The device is not + attached. Allows the user to disable the watchdog + for the image, even if it has been enabled using the image's flavor. + + reset—Forcefully reset the guest. + poweroff—Forcefully power off the guest. + pause—Pause the guest. + none—Only enable the watchdog; do nothing if the server + hangs. + +
libvirt API driver os_command_line
@@ -88,122 +96,169 @@ - + run on only compute nodes with GPU hardware.
extra_specsKey and value pairs that define on which compute + 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.
- Flavor customization can be limited by the hypervisor in - use, for example the libvirt driver enables quotas on CPUs - available to a VM, disk tuning, bandwidth I/O, and instance - VIF traffic control. - You can configure the CPU limits with control parameters - with the nova tool. For example, to configure the I/O - limit: - $ nova flavor-key m1.small set quota:read_bytes_sec=10240000 + Flavor customization can be limited by the hypervisor in use. For example the + libvirt driver enables quotas on CPUs available to a VM, disk + tuning, bandwidth I/O, watchdog behavior, and instance VIF traffic control. + + CPU limits + You can configure the CPU limits with control parameters with the nova + client. For example, to configure the I/O limit, use: + $ nova flavor-key m1.small set quota:read_bytes_sec=10240000 $ nova flavor-key m1.small set quota:write_bytes_sec=10240000 - There are CPU control parameters for weight shares, - enforcement intervals for runtime quotas, and a quota for - maximum allowed bandwidth. - The optional cpu_shares element 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. - The optional cpu_period element 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 [1000, 1000000]. A - period with value 0 means no value. - The optional cpu_quota element specifies - the maximum allowed bandwidth (unit: microseconds). A domain - with a quota with a negative value indicates that the domain - has infinite bandwidth, which means that it is not bandwidth - controlled. The value should be in range [1000, - 18446744073709551] 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: - $ nova flavor-key m1.low_cpu set quota:cpu_quota=10000 + There are optional CPU control parameters for weight shares, enforcement + intervals for runtime quotas, and a quota for maximum allowed + bandwidth: + + + + cpu_shares 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. + + + cpu_period 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 [1000, 1000000]. A period with + value 0 means no value. + + + cpu_quota 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 + [1000, 18446744073709551] 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: + $ nova flavor-key m1.low_cpu set quota:cpu_quota=10000 $ nova flavor-key m1.low_cpu set quota:cpu_period=20000 - In this example, the instance of - m1.low_cpu can only consume a maximum - of 50% CPU of a physical CPU computing capability. - Through disk I/O quotas, you can set maximum disk write to - 10 MB per second for a VM user. For example: - $ nova flavor-key m1.medium set disk_write_bytes_sec=10485760 - The disk I/O options are: - - - disk_read_bytes_sec - - - disk_read_iops_sec - - - disk_write_bytes_sec - - - disk_write_iops_sec - - - disk_total_bytes_sec - - - disk_total_iops_sec - - - The vif I/O options are: - - - vif_inbound_ average - - - vif_inbound_burst - - - vif_inbound_peak - - - vif_outbound_ average - - - vif_outbound_burst - - - vif_outbound_peak - - - Incoming and outgoing traffic can be shaped independently. - The bandwidth element can have at most one inbound and at most - one outbound child element. Leaving any of these children - element out result in no quality of service (QoS) applied on - that traffic direction. So, when you want to shape only the - network's incoming traffic, use inbound only, and vice versa. - Each of these elements have one mandatory attribute - average. - It specifies average bit rate on the interface being shaped. - Then there are two optional attributes: peak, which specifies - maximum rate at which bridge can send data, and burst, amount - of bytes that can be burst at peak speed. Accepted values for - attributes are integer numbers, The units for average and peak - attributes are kilobytes per second, and for the burst just - kilobytes. The rate is shared equally within domains connected - to the network. - This example configures a bandwidth limit for instance - network traffic: - $ nova flavor-key m1.small set quota:inbound_average=10240 -$ nova flavor-key m1.small set quota:outbound_average=10240 - 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: - $ nova flavor-create --is-public false p1.medium auto 512 40 4 -$ nova flavor-access-add 259d06a0-ba6d-4e60-b42d-ab3144411d58 86f94150ed744e08be565c2ff608eef9 + In this example, the instance of + m1.low_cpu can only consume a maximum + of 50% CPU of a physical CPU computing capability. + + + + + + Disk tuning + Using disk I/O quotas, you can set maximum disk write to 10 MB per second for a VM user. For + example: + $ nova flavor-key m1.medium set disk_write_bytes_sec=10485760 + The disk I/O options are: + + + disk_read_bytes_sec + + + disk_read_iops_sec + + + disk_write_bytes_sec + + + disk_write_iops_sec + + + disk_total_bytes_sec + + + disk_total_iops_sec + + + The vif I/O options are: + + + vif_inbound_ average + + + vif_inbound_burst + + + vif_inbound_peak + + + vif_outbound_ average + + + vif_outbound_burst + + + vif_outbound_peak + + + + Bandwidth I/O + 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 children element 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. + There are also two optional attributes (integer): , which + specifies maximum rate at which bridge can send data (kilobytes/second), and + , the amount of bytes that can be burst at peak speed + (kilobytes). The rate is shared equally within domains connected to the + network. + The following example configures a bandwidth limit for instance network + traffic: + $ nova flavor-key m1.small set quota:inbound_average=10240 +$ nova flavor-key m1.small set quota:outbound_average=10240 + + Watchdog behavior + For the libvirt 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 + hw_watchdog_action is not specified, the watchdog is + disabled. + To set the behavior, use: + $ nova flavor-key flavorName set hw_watchdog_action=action + Valid action values are: + + + disabled—(default) The device is not + attached. + + reset—Forcefully reset the guest. + + + + poweroff—Forcefully power off the + guest. + + + pause—Pause the guest. + + + none—Only enable the watchdog; do + nothing if the server hangs. + + + Watchdog behavior set using a specific image's properties will override behavior set using + flavors. + + + Instance VIF traffic control + 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: + $ nova flavor-create --is-public false p1.medium auto 512 40 4 +$ nova flavor-access-add 259d06a0-ba6d-4e60-b42d-ab3144411d58 86f94150ed744e08be565c2ff608eef9 + + diff --git a/doc/user-guide-admin/section_cli_nova_manage_flavors.xml b/doc/user-guide-admin/section_cli_nova_manage_flavors.xml index 86dafd0f9e..7e7470aba6 100644 --- a/doc/user-guide-admin/section_cli_nova_manage_flavors.xml +++ b/doc/user-guide-admin/section_cli_nova_manage_flavors.xml @@ -10,6 +10,12 @@ simply, a flavor is an available hardware configuration for a server. It defines the size of a virtual server that can be launched. + + Flavors can also determine on which compute host a flavor + can be used to launch an instance. For information + about customizing flavors, refer to the OpenStack Cloud Administrator Guide. A flavor consists of the following parameters: