An OpenStack Nova compute node flavor is a preconfigured combination of settings for an OpenStack Oracle VM Server for SPARC VM. The flavors serve as a service catalog mechanism for OpenStack.
Use the nova flavor-create command to create a flavor:
cctrl# nova flavor-create "flavor-name" flavor-ID memory-size disk-size vCPU-count
Where you must specify the operands in the following order:
flavor-name is the name of the flavor such as "LDom.medium"
flavor-ID is a unique ID number
memory-size is the amount of RAM in Mbytes
disk-size is the amount of disk space in Gbytes
vCPU-count is the number of virtual CPUs (strands)
By using the –-ephemeral disk-size option, you can optionally add a secondary ephemeral disk with disk-size Gbytes to a logical domain for the last flavor. This disk is a blank disk attached to the domain that uses local storage on the compute node. As such, the use of ephemeral storage blocks live migrations. To perform live migrations, use additional Cinder volumes instead of using the ephemeral storage flag on your flavors.
Version 1.0 of the Oracle VM Server for SPARC OpenStack Nova driver permits you to set “extra_specs” on flavors to specify how to configure logical domains.
You can set these extra_specs by using the nova flavor-key command.
cctrl# nova flavor-key flavor-ID set keyword=value [ keyword=value]...
Available extra_specs are as follows:
ldm:whole-core is a Boolean value that specifies whether to use the whole-core constraint.
ldm:max-core is a Boolean value that specifies whether to use the maximum number of cores constraint.
ldm:live-migrate is a Boolean value that specifies whether to permit live migration for this VM.
ldm:cpu-arch is a string value that specifies the migration class value of the cpu-arch property. See Domain Migration Requirements for CPUs in Oracle VM Server for SPARC 3.4 Administration Guide.
ldm:auto-alt-mac-addrs is an integer value that specifies how many alternate MAC addresses to configure per virtual network for this VM. Use this if you want to create VNICs within a guest domain.
Avoid creating a pool of servers that includes both Fujitsu M10 servers and Oracle SPARC servers when using the whole-core constraint.
Whole core and max core constraints depend on the number of virtual CPUs (or strands) provided by the underlying SPARC server.
For example, a SPARC T7 series server has eight strands per core. So, setting the whole core constraint on a flavor requires that the number of virtual CPUs that you specify is a multiple of eight. While a Fujitsu M10 server has only two strands per core so the flavor requires that the number of virtual CPUs on a Fujitsu M10 server must be divisible by two.
Avoid mixing whole-core and non-whole core configurations as partial CPU allocation might fragment the cores that remain available on a server over time.
For example, a SPARC T7-2 series server might have 30 domains provisioned, each using two strands. If four domains are deleted, eight strands can be freed, however these strands might come from different physical cores. In this instance, a single whole core might be available. In such a case, the Nova driver and the underlying Oracle VM Server for SPARC hypervisor are unable to service a request for CPU resources. The nova-scheduler service might attempt to schedule this VM on another node.