machine-list [-a|all] [-v|--versions]
[-s|--status] [-z|--zones] [-r|--racking]
[-n|--network] [-h|--hardware] [-b|--blockdevs]
[-i|--ipmi] [-l|--links]
- List all the computers recorded in the OCI database. This command
understand a few flags as below. Each time, there is a shorter version of
the option using the first letter of the argument and a single minus sign.
- --all | -a
- Display all fields, as if all display options where passed. This usually
doesn't fit on a normal screen, but may be useful when parsing the output
in CSV mode.
- --versions |
-v
- Display BIOS, Dell Lifecycle and IPMI firmware versions.
- --status |
-s
- Display the operating system installation and puppet run statuses. Also
display the time of the last run of openstack-cluster-installer-agent.
Note that the agen only runs when the machine is running in Debian live,
before being installed.
- --zones | -z
- Display the cluster name, swift region and location where the machine has
been installed.
- --network |
-n
- Display the networking information, such as IP addresses.
- --ethernet |
-e
- Display the network interfaces with MAC addresses and speed and the switch
name and interface connected to it.
- --hardware |
-h
- Display the hardware configuration of the machine, including the amount of
available memory, and the detected block and network devices.
- --blockdevs |
-b
- Display the connected block devices.
- --ipmi | -i
- Display the IPMI information.
- --links | -l
- Display the network interfaces without MAC addresses and speed. This is
useful as the -e option can be very wide and not display well on smaller
screens.
machine-show <serial-num|hostname>
- Show the details about a computer in the cluster.
machine-guessed-profile <serial-num|hostname>
[-d / --debug]
- Show the guessed hardware profile according to
/etc/openstack-cluster-installer/hardware-profiles.json. This is useful to
tweak hardware-profiles.json by trials and errors.
The -d or --debug option help designing
hardware-profiles.json, by showing how profiles are filtered.
machine-check-megacli-applied
<serial-num|hostname> [hardware-profile-name]
- Check if the megacli profile is applied or not. If no hardware profile is
given as parameter, it is then guessed.
machine-megacli-apply <machine_serial>
[hardware_profile_name]"
- Apply the MegaCli commands to a machine. If no hardware profile is given
as parameter, it is then guessed.
machine-megacli-reset-raid
<machine_serial>
- Reset the RAID configuration of a machine, removing all RAID devices.
machine-guess-racking <machine_serial>
- Print the datacenter, row, rack and position in the rack, as guessed by
OCI, reading /etc/openstack-cluster-installer/auto-racking.json.
machine-auto-rack <machine_serial>
- Fill-up the racking information as machine-guess-racking would guess it.
machine-auto-add <machine_serial>
- Automatically add a machine to a cluster, guessing its role thanks to the
hardware profiles defined in
/etc/openstack-cluster-installer/hardware-profiles.json (needed to guess
the machine role) and the racking infomation in
/etc/openstack-cluster-installer/auto-racking.json (needed to guess the
machine location name).
machine-to-dns <machine_serial>
- Record the machine hostname into an external DNS service. This works only
if the [dns_plugin] section of openstack-cluster-installer.conf is
configured properly. See the OCI contrib folder in the source of OCI to
see how to write the plugin shell script.
machine-out-of-dns <machine_serial>
- Delete the machine from DNS using the plugin script.
machine-to-monitoring <machine_serial>
- Insert the machine into the monitoring system. This works only if the
[monitoring_plugin] section of openstack-cluster-installer.conf is
configured properly. See the OCI contrib folder in the source of OCI to
see how to write the plugin shell script.
machine-out-of-monitoring <machine_serial>
- Delete the machine from monitoring using the plugin script.
machine-gen-root-pass <machine_serial>
- Generate a random password, ssh into the machine, and set this password
for root. Optionally, if the [root_pass_plugin] section of
openstack-cluster-installer.conf is configured properly, record the root
password using the configured helper script. It is adviced to use
something like Hashicorp Vault or OpenStack Barbican for storing these
root passwords.
machine-forget-root-pass <machine_serial>
- Remove the root password from the password store, using the plugin script.
machine-set <serial-num> [options]
-
Set properties of a computer in the cluster. Options are as
below.
- --hostname
<hostname>
- Overrides the hostname as calculated by OCI when adding a computer in a
cluster. Must be issued before installing a server.
- --install-on-raid
<yes/no>
- Install the operating system using software RAID. See below on how to
configure such a RAID array.
- --raid-type
<0/1/10/5>
- Select RAID type 0, 1, 10 or 5.
- --raid-dev0
<sda>
- Select sda for the RAID device 0.
- --raid-dev1
<sda>
- Select sda for the RAID device 1.
- --raid-dev2
<sda>
- Select sda for the RAID device 2.
- --raid-dev3
<sda>
- Select sda for the RAID device 3.
- --serial-console-device
<ttyS0/ttyS1/none>
- Select the serial console device for the main console output. This is very
useful if one is using IPMI and serial over LAN. This will influence both
the way grub is configured, and systemd configuration for starting up the
serial console. Note that this option must be set before installing the
operating system, it will not be modified after install.
- --dc
<string>
- Data center where the computer is installed. This is seen in machine-show
or machine-list -a.
- --row
<string>
- Data center rack row where the computer is installed. This is seen in
machine-show or machine-list -a.
- --rack
<string>
- Rack where the computer is installed. This is seen in machine-show or
machine-list -a.
- --ustart
<num>
- Rack unit start where the computer is installed. This is seen in
machine-show or machine-list -a.
- --uend
<num>
- Rack unit end where the computer is installed. This is seen in
machine-show or machine-list -a.
- --use_ceph_if_available
<yes/no>
- Set a compute node to use Ceph as the backend for /var/lib/nova/instances.
- --nested-virt
<yes/no>
- Set this to yes if wishing to enable nested virtualization in a compute
node.
- --use-gpu
<yes/no>
- Set this to yes if the compute node is providing a GPU to its guests.
- --gpu-name
<name>
- Set the name of the GPU (free string). This option is only useful is
uising --use-gpu yes.
- --gpu-vendor-id
- Set the PCI ID of the vendor of the GPU, as seen by lspci -nn. This option
is only useful is uising --use-gpu yes.
- --gpu-produc-id
<ID>
- Set the product ID of the GPU, as seen by lspci -nn. This option is only
useful is uising --use-gpu yes.
- --gpu-device-type
<type-PCI/type-PF/type-VF>
- Set the type of GPU to do passthrough with. Note that this depends on the
GPU card and firmware. For example, newer Nvidia Tesla T4 require type-PF
when older firmware required type-PCI.
- --vfio-ids
<IDs>
- VFIO IDs that must be passed to the kernel module when starting. Multiple
ID strings can be passed, separated by the + caracter. A reboot (after
puppet is applied) of the compute node is necessary for this to be
applied. This option is only useful is uising --use-gpu yes.
- --cpu-mode
<host-model/host-passthrough/custom/cluster_value>
- Set the CPU mode of a compute. With host-passthrough, all of the compute
node CPU flags will be exposed to a guest. With custom, the cpu-model must
be set (see below). With cluster_value, the compute node inherit from the
parameter set at the cluster level.
- --cpu-model
<MODEL>
- Set the CPU model exposed to Qemu guests. The full list of supported CPU
model is to be found in the Qemu documentation. This option is
- --cpu-model-extra-flags
<FLAG1,FLAG2>
- Extra CPU flags to pass to the guests.
- --swift-store-account
<yes/no>
- Activate Accounts storage on a swiftproxy or swiftstore node.
- --swift-store-container
<yes/no>
- Activate Containers storage on a swiftproxy or swiftstore node.
- --swift-store-object
<yes/no>
- Activate Objects storage on a swiftproxy or swiftstore node.
- --servers-per-port
<int>
- Number of servers per port for a swift Objects server.
- --disk-chunk-size
<int>
- Disk chunk size for swift objects server.
- --network-chunk-size
<int>
- Network chunk size for swift objects server.
- --lvm-backend-name
- Set the name of the LVM backend. Only applies to Cinder volume nodes. This
can be helpful to distinguish between 2 different backend, for example
with one backend being SSD, the other one being HDD.
- --ipmi-use
<yes/no>
- If set, this computer uses IPMI.
- --ipmi-call-chassis-bootdev
<yes/no>
- If set, this computer supports using IPMI to set the boot device (ie: disk
or PXE).
- --ipmi-username
<username>
- Sets the IPMI username for this computer.
After setting this value, ocicli machine-apply-ipmi must be
called.
- --ipmi-password
<password>
- Sets the IPMI password for this computer.
After setting this value, ocicli machine-apply-ipmi must be
called.
- --ipmi-addr
<ipaddr>
- Sets the IPMI address to contact the IPMI of this computer.
After setting this value, ocicli machine-apply-ipmi must be
called.
- --ipmi-port
<port>
- Sets the IPMI port to contact the IPMI of this computer.
After setting this value, ocicli machine-apply-ipmi must be
called.
- --ipmi-netmask
<netmask>
- Sets the IPMI netmask for this computer. The default value is
255.255.255.0.
After setting this value, ocicli machine-apply-ipmi must be
called.
- --ipmi-default-gw
<gatewayip>
- Sets the IPMI default gateway for this computer. The default value for the
IPMI gateway is the first valid IP address of the network as per the IPMI
address and the IPMI netmask.
After setting this value, ocicli machine-apply-ipmi must be
called.
- --ceph-osd-initial-setup
- When a machine acting as Ceph OSD, its OSDs are setup once on the first
puppet runs, and then automatically, this is disabled. This parameter
makes it possible to force the setup to be ran again, for example if a new
block device is added to the host. It is recommended to leave this not
activated in production, to handle gracefully borken block devices.
- --force-no-bgp2host
- If a cluster is set to use a bgp-to-the-host networking, some servers, for
example network nodes, may need to use L2 connectivity. If this parameter
is set to yes, then L2 connectivity will be forced, instead of
bgp-to-the-host over IPv6 unnumbered.
- --ipmi-vlan
<vlanid|off>
- Sets the IPMI vlan. The default value for the IPMI VLAN is off, meaning no
VLAN is tagged.
After setting this value, ocicli machine-apply-ipmi must be
called.
machine-add [--fixed-ip <ipaddr>]
<serial-num> <cluster-name> <role-name>
<location-name>
- Add a machine to a cluster. The networks attached to location specified
will automatically be assigned to that computer (ie: IP addresses will be
reserved for that machine). If it is a network node (or a controller that
acts as a network node if no network nodes are defined on the cluster) or
a compute node, if it exists, the vm-net will also be added to the
machine. If it is a cephosd node, and a ceph network exist, it will also
be added to the machine.
When the optional parameter --fixed-ip is added, the IP
address must be in the pool that OCI will use automatically when adding
the machine. The IP must also be free.
machine-remove <serial-num>
- Remove a machine from a network, and make it available so it can be added
again in a cluster.
machine-destroy <serial-num>
- Completely remove a computer (and all of its attached network card and
block storage devices) from the OCI database. The only way to have it
re-appear is to run the discovery agent again in the machine (which may
happen immediately if the machine is running the OCI live image).
machine-reboot-on-hdd <serial-num>
- SSH into the machine, and make it (cleanly) reboot on the HDD.
machine-reboot-on-live <serial-num>
- SSH into the machine, and make it (cleanly) reboot on the Debian live
hardware discovery system.
machine-ipmi-reboot-on-hdd <serial-num>
- Issue an IPMI reboot command, and make the computer reboot on its
installed operating system.
machine-ipmi-reboot-on-live <serial-num>
- Issue an IPMI reboot command, and make the computer reboot on the Debian
live hardware discovery system.
machine-hpe-ilo-license-install
<serial-num>
- If there's a /root/License.xml, this installs it as the HPE ILO license.
This file should be installed in the live image here:
/etc/openstack-cluster-installer/live-image-additions/root/License.xml
machine-hpe-activate-ipmi-over-lan
<serial-num>
- This activates HPE IPMI over LAN.
machine-ipmi-cmd <serial-num>
<ipmi-command>
- Runs any IPMI command over LAN using the recorded IPMI credentials.
machine-install-os <serial-num>
- Install Debian on the target computer, reboot the machine, and apply to it
its puppet configuration.
machine-install-log <serial-num>
- Show the installation log of the computer, if the system is installing. If
it has rebooted under its operating system, show its puppet debug log.
machine-apply-ipmi <serial-num>
- Apply the IPMI configuration to a machine (ie: run the ipmitool commands).
machine-set-ipmi [--do-ipmitool-cmds] [--ipmi-defgw
GATEWAY] [--ipmi-netmask NETMASK] [--ipmi-call-chassis-bootdev yes/no]
<serial-num> <use-ipmi:yes/no> <ipmi-ip-addr>
<ipmi-port> <ipmi-username> <ipmi-password>
- Set the IPMI configuration of a computer. If --do-ipmitool-cmds is
used, then ipmitool commands will be issued in the target machine,
effectively setting-up the IPMI configuration.
If --ipmi-call-chassis-bootdev is used, then IPMI will
be used to select the boot device before rebooting the computers.
machine-console <serial-num>
- Display the ipmitool command that must be used to access the serial over
LAN of a computer, as per the information stored with the
machine-set-ipmi.
machine-wipe <serial-num>
- Whipe the begining of all HDDs of the machine with /dev/urandom values.
machine-ip-list <serial-num>
- Display a list of network names and IP address of a computer.
machine-ip-add <serial-num> <network-name>
<ip-address>
- Manually add an IP address to a computer. The IP must be in a range
included in the network-name.
machine-ip-remove <serial-num>
<ip-address>
- Remove an IP address from a computer.
machine-report-counter-reset <serial-num>
- Reset the hardware discovery report counter. This may be useful to restart
the automated installation process.
machine-renew-ipmi-password <serial-num>
- Change the IPMI password of a server, and record it in the OCI db.
machine-replace-hardware <old-serial-num>
<new-serial-num>
- Replace a deffective machine by a new one. This assume that all hard
drives have been moved from the old machine to the new one, and that the
old hardware is being destroyed.
ipmi-assign-check
- This command will check if the currently assigned IPMI address of every
machine match one of the IPMI networks, and if so, check if the IPMI IP
address is recorded in OCI's DB. If the IP address isn't there, a new
record will be added.
This command is particularly useful if migrating from an old
version of OCI, or if the administrator wishes to manually assign IPMI
addresses to machines. It's also useful simply when turning on the
automatic IPMI address numbering feature in
/etc/openstack-cluster-installer/openstack-cluster-installer.conf.
check-all-ipmi [filter]
- This command will iterate through all machines in the OCI database, and
check if the IPMI replies to a "chassis power status" command
(within a 5 seconds timeout).
It is possible to add a filter, matching what's in the output
of ocicli machine-list -a. For example, it's possible to do "ocicli
check-all-ipmi serial LIKE ´D%´" to check that IPMI
is replying on all machines with the serial starting by D.
network-list
- List all networks.
network-set <network-name> [--cidr
MASK] [--iface1 IFDEFINITION] [--iface2 IFDEFINITION]
[--ip IPv4] [--is-public yes/no] [--location
location-name] [--mtu MTU] [--role ROLE] [--vlan
VLAN_NUM] [--bridge-name NAME] [--ipmi-match-addr IPADDR]
[--ipmi-match-cidr CIDR]
- Set attributes of a network.
If --iface1 and --iface2 are used, bonding will
be used on every machine using this network.
The --role parameter can be use to set the role of the
network. These roles are currently available in OCI: ovs-bridge,
ceph-cluster, vm-net and ipmi. If not using one of these network roles,
then OCI will understand that we're talking about a machine role, and
that this network should be assigned only to the machines assigned with
this role.
The [--mtu MTU] and [--vlan VLAN_NUM] are used
to set the MTU and VLAN number of a network, during the installation of
a server. This value doesn't influence servers already installed, which
should then be tweaked manually.
The [--bridge-name NAME] parameter controles the name
of the birdge, in case the network role is set to ovs-bridge.
The [--is-public yes/no] is to be use on the network
used to host the OpenStack API.
The [--ipmi-match-addr IPADDR] and
[--ipmi-match-cidr CIDR] parameters are only for when the network
role is set to "ipmi". If in
/etc/openstack-cluster-installer/openstack-cluster-installer.conf the
parameter automatic_ipmi_numbering=yes is set, then OCI will attempt to
match the DHCP IP address with the network described with these 2
parameters. As the default is 0.0.0.0/0, it will match by default. If
there are more than one DHCP networks, it is possible to assign
different IPMI address ranges depending on which DHCP network is matched
with this rule. For example, if you have a 2 DHCP networks, one set to
PXE boot servers on 10.0.10.0/24, and that for the machines on this DHCP
network, the IPMI addresses should be on the pool 192.168.10.0/24, then
this can be done:
ocicli network-create ipmi 192.168.10.0 24 zone1 no
ocicli network-set ipmi --role ipmi --ipmi-match-addr
10.0.10.0 --ipmi-match-cidr 24
[--ipmi-match-addr IPADDR] [--ipmi-match-cidr
CIDR]
network-create <network-name> <ip>
<cidr-mask> <location-name> <is-public:yes/no>
- Create a new network in the database. Note that after the network is
created, it must be added to a cluster to be effective. Note that
location-name must exist before creating the network.
network-delete <network-name>
- Delete a network from the db.
network-add <network-name> <cluster-name>
<role-name> <iface1> <iface2>
- Add a network to a cluster.
network-remove <network-name>
- Remove a network from a cluster.
location-list
- List all location of the database.
location-create <location-name>
<swiftregion-name>
- Create a new location in the OCI database. Note that swiftregion-name
before creating the location. You still need to create a swiftregion-name
even if your cluster doesn't use swift (then the swiftregion-name will not
be used).
location-delete <location-name>
- Delete a location from the database. Note that no check is being done if
the record is used anywhere.
swift-region-list
- List all swiftregion from the database.
swift-region-create <swiftregion-name>
- Create a new Swift region.
swift-region-delete <swiftregion-name>
- Delete a Swift region. Note that no check is being done if the region is
being used or not (use it at your own risk).
swift-calculate-ring <cluster-name>
[initial-account-weight [--ec-only] [initial-container-weight]
[initial-object-weight]]]
- Calculate the Swift ring for a new cluster. Beware that you should never
call this when a cluster has already been deployed (instead, modify the
existing ring, and distribute it to all nodes).
Eventually, one can set the initial-weight (without it, the
default weight is 1000 for each drive).
If you wish to only create the Erasure Coding ring, add the
--ec-only parameter.
swift-publish-ring <cluster-name>
- Publish a swift ring to all swiftstore and swiftproxy nodes of a cluster.
Note that this command must be issued on the OCI machine itself, as the
command isn't using any API: it just copies the local files to the
cluster.
cluster-list
- List all clusters in the database.
cluster-create <cluster-name>
<example.com>
- Create a new cluster with name cluster-name and with domain name
example.com
cluster-delete <cluster-name>
- Delete a cluster form the database. Beware that no check is being done if
the cluster is still in use. Use at your own risks.
cluster-show <cluster-name>
- Display the information about a cluster and show its variables.
cluster-set <cluster-name>
[--time-server-host <time-server-hostname>] [--vip-hostname
<hostname>] [--swift-part-power <int>]
[--swift-proxy-hostname <hostname>]
[--swift-encryption-key-id <UUID>]
[--swift-disable-encryption <yes/no>] [--amp-secgroup-list
<SECGROUP-UUID-LIST>] [--amp-boot-network-list
<AMP_BOOT_NETWORK_LIST>] [--disable-notifications
<yes/no>] [--enable-monitoring-graphs <yes/no>]
[--monitoring-graphite-host <hostname>]
[--monitoring-graphite-port <port>] [--statsd-hostname
<hostname>] [--extswift-use-external <yes/no>]
[--extswift-auth-url <https://api.example.com/identity/v3>]
[--extswift-proxy-url
<https://prx.example.com/object/v1/AUTH_>]
[--extswift-project-name <myproj>]
[--extswift-project-domain-name <default>]
[--extswift-user-name <myuser>] [--extswift-use-domain-name
<default>] [--extswift-password <password>]
[--self-signed-api-cert <yes/no>] [--use-ovs-ifaces
<yes/no>] [--cpu-mode
<host-model/host-passthrough/custom>] [--cpu-model
<MODEL>] [--cpu-model-extra-flags <FLAG1,FLAG2>]
[--nested-virt <yes/no>] [--first-master <SERIAL>]
[--nameserver-v4-primary <IPv4>] [--nameserver-v4-secondary
<IPv4>] [--nameserver-v6-primary <IPv6>]
[--nameserver-v6-secondary <IPv6>]
[--cephosd-automatic-provisionning <yes/no>]
- Set variables for a cluster.
- --time-server-host
<time-server-hostname>
- Set the time server to be setup in the chrony client of each node.
Defaults to 0.debian.pool.ntp.org if not set.
- [--vip-hostname <hostname>]
- Defines the hostname of the OpenStack API if it is needed to override it.
Default to <cluster-name>-api.example.com.
- [--swift-part-power <int>]
- This parameter controls the total number of partitions in the swift ring
when building the initial swift ring. The integer is a power of 2. For
example, if setting 18 (which is the default), there will be 2^18
partitions in the ring (which is a good enough value for about 7000 disks,
and it's also small enough for smaller clusters).
- [--swift-proxy-hostname <hostname>]
- If not set, the URL of the swift proxies will be the one of the OpenStack
API, and haproxy there will forward to the swift proxies. If you have a
busy swift cluster, then it is recommended to setup more than one swift
proxy, using a round-robin DNS entry to point to them. In such case, you
can then set the swift proxies hostname, and then clients will connect to
them directly instead of going through the HAproxy in the controllers.
With an empty string (which is the default), clients will connect through
the controller nodes.
- [--swift-encryption-key-id <UUID>]
- Set the barbican secret for the swift on-disk encryption. This key must be
stored in Barbican before setting this value.
[--swift-disable-encryption <yes/no>] If set to
yes, there will be no on-disk encryption in the Swift cluster. This is
the default. Set the encryption key before setting-up this to no.
- [--amp-secgroup-list <SECGROUP-UUID-LIST>]
- List of security groups to be assigned to Octavia amphora. These security
groups must be created before setting this value. See the
oci-octavia-amphora-secgroups-sshkey-lbrole-and-network utility to create
this.
- [--amp-boot-network-list <AMP_BOOT_NETWORK_LIST>]
- List of networks to use when booting-up the Octavia Amphora image. See
oci-octavia-amphora-secgroups-sshkey-lbrole-and-network utility to create
this.
- [--disable-notifications <yes/no>]
- If set to yes, there will be no notification transport set in all of the
OpenStack services. This is useful if you don't need the metrics to be
reported back to the Telemetry project (ie: Ceilometer / Gnocchi).
- [--enable-monitoring-graphs <yes/no>]
- Enable Swift reporting of statistics.
- [--monitoring-graphite-host <hostname>]
- Hostname of the graphite server to use in Swift nodes to report
statistics.
- [--monitoring-graphite-port <port>]
- Port number of the graphite server to use in the Swift nodes to report
statistics.
- [--statsd-hostname <hostname>]
- Hostname of the statsd server to use in the Swift nodes to report
statistics. As this improves performances, a collectd server is installed
on each nodes, which then reports to graphite. Therefore localhost is a
correct value here.
- [--extswift-use-external <yes/no>]
- Set to yes to use an external swift for cinder-backup and glance. Use this
if you have setup a swift cluster outside of this cluster.
- [--extswift-auth-url
<https://api.example.com/identity/v3>]
- Auth URL for the external swift.
- [--extswift-proxy-url
<https://prx.example.com/object/v1/AUTH_>]
- URL of the external swift proxy.
- [--extswift-project-name <myproj>]
- Project name of the external swift cluster.
- [--extswift-project-domain-name <default>]
- Project domain name of the external swift cluster.
- [--extswift-user-name <myuser>]
- User name of the external swift cluster.
- [--extswift-user-domain-name <default>]
- User domain name of the external swift cluster.
- [--extswift-password <password>]
- Password of the external swift cluster.
- [--self-signed-api-cert <yes/no>]
- If set to yes (the default), the API URL will use a self-signed
certificate. Therefore, in all of the OpenStack configuration, there will
be added some configuration to use the ROOT CA generated by OCI when
contacting the API. This ROOT CA will also be used as environment variable
by the puppet agent.
- [--use-ovs-ifaces <yes/no>]
- If set to no (the default), the network interfaces of compute and network
nodes (and the controllers if they act as network nodes, which is the case
when no network nodes are provisioned) will use standard kernel network
interfaces. If set to yes, then a OVS bridge (and eventually an OVS bond)
will be setup instead.
- [--cpu-mode <host-model/host-passthrough/custom>]
- This parameter controls the CPU emulation type used in the compute nodes
of the cluster. This can be overriden on each compute node.
- [--cpu-model <MODEL>]
- This parameter controls the CPU model to use if using host-model.
- [--cpu-model-extra-flags <FLAG1,FLAG2>]
- If using host-model, it's possible to add extra CPU features to Qemu. See
the Qemu documentation or lscpu for a list of available CPU features.
- [--nested-virt <yes/no>]
- If set to yes, nested virtualization will be configured in each compute
nodes. Note that with nested virtualization in use, it is impossible to
live migrate a VM.
- [--first-master <SERIAL>]
- Set which of the 3 (or more) controllers is to be considered "first
master".
While the system is fully HA, OCI still needs to have a single
server that it considers as "first master".
The "first master" of the cluster is the machine
where Keystone fernet tokens will be rotated (and then synched to other
controllers), and where the Glance API will be in used (if neither Swift
or Ceph backend is available, other nodes are only Glance API backups if
that one fails). This is also the machine where the initial database
creation happens.
- [--nameserver-v4-primary <IPv4>]
- Configure the primary name server (IPv4) for the cluster. This is
currently not in use yet and has no effect.
- [--nameserver-v4-secondary <IPv4>]
- Configure the secondary name server (IPv4) for the cluster. This is
currently not in use yet and has no effect.
- [--nameserver-v6-primary <IPv6>]
- Configure the primary name server (IPv6) for the cluster. This is
currently not in use yet and has no effect.
- [--nameserver-v6-secondary <IPv6>]
- Configure the secondary name server (IPv6) for the cluster. This is
currently not in use yet and has no effect.
- [--cephosd-automatic-provisionning <yes/no>]
- Should Ceph OSD be automatically setup after the provisionning of the
nodes?
cluster-show-networks <cluster-name>
- Show all networks attached to a cluster
cluster-show-machines <cluster-name>
- Show all machines attached to a cluster (ie: do not display machines
attached to another cluster, or machines not yet attached anywhere).
cluster-show-ips <cluster-name>
- Display a list of IP addresses assigned in a cluster and the matching
hostname where they are assigned.
cluster-install <cluster-name>
- Install the system on all computers of a cluster. The installation is made
in this order: first cephmons, then cephosds, then controllers, then
network nodes, then everything else. ocicli will wait until the
controllers puppet run is done until it installs everyting else.
Note that if for a reason, one of the steps didn't work, it's
ok to restart a cluster-install command to finish the job, as server
install will not be attempted if a machine isn't running live.
cluster-rolecounts-list <cluster-name>
- Display the current role counts for a given cluster.
cluster-rolecounts-set <cluster-name>
<count>
- Set the role count for a given cluster and a given role.
cluster-reset <cluster-name>
- Reset all machines that aren't running Debian live into live mode using
IPMI commands.
role-list
- List all roles currently defined in OCI.
role-create <name>
- Create a new role.
role-delete <name>
- Delete a role.
filebeat-output-host-list <cluster-name>
- List all filebeat output hosts for a given cluster.
filebeat-output-host-create <cluster-name>
<hostname> <port>
- Add a new filebeat output host to a cluster.
filebeat-output-host-delete <cluster-name>
<hostname> <port>
- Delete a new filebeat output host from a cluster.