|
|
|
@ -0,0 +1,701 @@
|
|
|
|
|
|
|
|
|
|
# Driver definition
|
|
|
|
|
[driver.nova-lxd]
|
|
|
|
|
title=Nova-LXD
|
|
|
|
|
|
|
|
|
|
# Functions:
|
|
|
|
|
[operation.attach-volume]
|
|
|
|
|
title=Attach block volume to instance
|
|
|
|
|
status=optional
|
|
|
|
|
notes=The attach volume operation provides a means to hotplug
|
|
|
|
|
additional block storage to a running instance. This allows
|
|
|
|
|
storage capabilities to be expanded without interruption of
|
|
|
|
|
service. In a cloud model it would be more typical to just
|
|
|
|
|
spin up a new instance with large storage, so the ability to
|
|
|
|
|
hotplug extra storage is for those cases where the instance
|
|
|
|
|
is considered to be more of a pet than cattle. Therefore
|
|
|
|
|
this operation is not considered to be mandatory to support.
|
|
|
|
|
cli=nova volume-attach <server> <volume>
|
|
|
|
|
driver.nova-lxd=complete
|
|
|
|
|
|
|
|
|
|
[operation.attach-tagged-volume]
|
|
|
|
|
title=Attach tagged block device to instance
|
|
|
|
|
status=optional
|
|
|
|
|
notes=Attach a block device with a tag to an existing server instance. See
|
|
|
|
|
"Device tags" for more information.
|
|
|
|
|
cli=nova volume-attach <server> <volume> [--tag <tag>]
|
|
|
|
|
driver.nova-lxd=unknown
|
|
|
|
|
|
|
|
|
|
[operation.detach-volume]
|
|
|
|
|
title=Detach block volume from instance
|
|
|
|
|
status=optional
|
|
|
|
|
notes=See notes for attach volume operation.
|
|
|
|
|
cli=nova volume-detach <server> <volume>
|
|
|
|
|
driver.nova-lxd=missing
|
|
|
|
|
|
|
|
|
|
[operation.extend-volume]
|
|
|
|
|
title=Extend block volume attached to instance
|
|
|
|
|
status=optional
|
|
|
|
|
notes=The extend volume operation provides a means to extend
|
|
|
|
|
the size of an attached volume. This allows volume size
|
|
|
|
|
to be expanded without interruption of service.
|
|
|
|
|
In a cloud model it would be more typical to just
|
|
|
|
|
spin up a new instance with large storage, so the ability to
|
|
|
|
|
extend the size of an attached volume is for those cases
|
|
|
|
|
where the instance is considered to be more of a pet than cattle.
|
|
|
|
|
Therefore this operation is not considered to be mandatory to support.
|
|
|
|
|
cli=cinder extend <volume> <new_size>
|
|
|
|
|
driver.nova-lxd=unknown
|
|
|
|
|
|
|
|
|
|
[operation.attach-interface]
|
|
|
|
|
title=Attach virtual network interface to instance
|
|
|
|
|
status=optional
|
|
|
|
|
notes=The attach interface operation provides a means to hotplug
|
|
|
|
|
additional interfaces to a running instance. Hotplug support
|
|
|
|
|
varies between guest OSes and some guests require a reboot for
|
|
|
|
|
new interfaces to be detected. This operation allows interface
|
|
|
|
|
capabilities to be expanded without interruption of service.
|
|
|
|
|
In a cloud model it would be more typical to just spin up a
|
|
|
|
|
new instance with more interfaces.
|
|
|
|
|
cli=nova interface-attach <server>
|
|
|
|
|
driver.nova-lxd=complete
|
|
|
|
|
|
|
|
|
|
[operation.attach-tagged-interface]
|
|
|
|
|
title=Attach tagged virtual network interface to instance
|
|
|
|
|
status=optional
|
|
|
|
|
notes=Attach a virtual network interface with a tag to an existing
|
|
|
|
|
server instance. See "Device tags" for more information.
|
|
|
|
|
cli=nova interface-attach <server> [--tag <tag>]
|
|
|
|
|
driver.nova-lxd=unknown
|
|
|
|
|
|
|
|
|
|
[operation.detach-interface]
|
|
|
|
|
title=Detach virtual network interface from instance
|
|
|
|
|
status=optional
|
|
|
|
|
notes=See notes for attach-interface operation.
|
|
|
|
|
cli=nova interface-detach <server> <port_id>
|
|
|
|
|
driver.nova-lxd=complete
|
|
|
|
|
|
|
|
|
|
[operation.maintenance-mode]
|
|
|
|
|
title=Set the host in a maintenance mode
|
|
|
|
|
status=optional
|
|
|
|
|
notes=This operation allows a host to be placed into maintenance
|
|
|
|
|
mode, automatically triggering migration of any running
|
|
|
|
|
instances to an alternative host and preventing new
|
|
|
|
|
instances from being launched. This is not considered
|
|
|
|
|
to be a mandatory operation to support.
|
|
|
|
|
The driver methods to implement are "host_maintenance_mode" and
|
|
|
|
|
"set_host_enabled".
|
|
|
|
|
cli=nova host-update <host>
|
|
|
|
|
driver.nova-lxd=unknown
|
|
|
|
|
|
|
|
|
|
[operation.evacuate]
|
|
|
|
|
title=Evacuate instances from a host
|
|
|
|
|
status=optional
|
|
|
|
|
notes=A possible failure scenario in a cloud environment is the outage
|
|
|
|
|
of one of the compute nodes. In such a case the instances of the down
|
|
|
|
|
host can be evacuated to another host. It is assumed that the old host
|
|
|
|
|
is unlikely ever to be powered back on, otherwise the evacuation
|
|
|
|
|
attempt will be rejected. When the instances get moved to the new
|
|
|
|
|
host, their volumes get re-attached and the locally stored data is
|
|
|
|
|
dropped. That happens in the same way as a rebuild.
|
|
|
|
|
This is not considered to be a mandatory operation to support.
|
|
|
|
|
cli=nova evacuate <server>;nova host-evacuate <host>
|
|
|
|
|
driver.nova-lxd=complete
|
|
|
|
|
|
|
|
|
|
[operation.rebuild]
|
|
|
|
|
title=Rebuild instance
|
|
|
|
|
status=optional
|
|
|
|
|
notes=A possible use case is additional attributes need to be set
|
|
|
|
|
to the instance, nova will purge all existing data from the system
|
|
|
|
|
and remakes the VM with given information such as 'metadata' and
|
|
|
|
|
'personalities'. Though this is not considered to be a mandatory
|
|
|
|
|
operation to support.
|
|
|
|
|
cli=nova rebuild <server> <image>
|
|
|
|
|
driver.nova-lxd=complete
|
|
|
|
|
|
|
|
|
|
[operation.get-guest-info]
|
|
|
|
|
title=Guest instance status
|
|
|
|
|
status=mandatory
|
|
|
|
|
notes=Provides realtime information about the power state of the guest
|
|
|
|
|
instance. Since the power state is used by the compute manager for
|
|
|
|
|
tracking changes in guests, this operation is considered mandatory to
|
|
|
|
|
support.
|
|
|
|
|
cli=
|
|
|
|
|
driver.nova-lxd=unknown
|
|
|
|
|
|
|
|
|
|
[operation.get-host-uptime]
|
|
|
|
|
title=Guest host uptime
|
|
|
|
|
status=optional
|
|
|
|
|
notes=Returns the result of host uptime since power on,
|
|
|
|
|
it's used to report hypervisor status.
|
|
|
|
|
cli=
|
|
|
|
|
driver.nova-lxd=unknown
|
|
|
|
|
|
|
|
|
|
[operation.get-host-ip]
|
|
|
|
|
title=Guest host ip
|
|
|
|
|
status=optional
|
|
|
|
|
notes=Returns the ip of this host, it's used when doing
|
|
|
|
|
resize and migration.
|
|
|
|
|
cli=
|
|
|
|
|
driver.nova-lxd=unknown
|
|
|
|
|
|
|
|
|
|
[operation.live-migrate]
|
|
|
|
|
title=Live migrate instance across hosts
|
|
|
|
|
status=optional
|
|
|
|
|
notes=Live migration provides a way to move an instance off one
|
|
|
|
|
compute host, to another compute host. Administrators may use
|
|
|
|
|
this to evacuate instances from a host that needs to undergo
|
|
|
|
|
maintenance tasks, though of course this may not help if the
|
|
|
|
|
host is already suffering a failure. In general instances are
|
|
|
|
|
considered cattle rather than pets, so it is expected that an
|
|
|
|
|
instance is liable to be killed if host maintenance is required.
|
|
|
|
|
It is technically challenging for some hypervisors to provide
|
|
|
|
|
support for the live migration operation, particularly those
|
|
|
|
|
built on the container based virtualization. Therefore this
|
|
|
|
|
operation is not considered mandatory to support.
|
|
|
|
|
cli=nova live-migration <server>;nova host-evacuate-live <host>
|
|
|
|
|
driver.nova-lxd=complete
|
|
|
|
|
|
|
|
|
|
[operation.force-live-migration-to-complete]
|
|
|
|
|
title=Force live migration to complete
|
|
|
|
|
status=optional
|
|
|
|
|
notes=Live migration provides a way to move a running instance to another
|
|
|
|
|
compute host. But it can sometimes fail to complete if an instance has
|
|
|
|
|
a high rate of memory or disk page access.
|
|
|
|
|
This operation provides the user with an option to assist the progress
|
|
|
|
|
of the live migration. The mechanism used to complete the live
|
|
|
|
|
migration depends on the underlying virtualization subsystem
|
|
|
|
|
capabilities. If libvirt/qemu is used and the post-copy feature is
|
|
|
|
|
available and enabled then the force complete operation will cause
|
|
|
|
|
a switch to post-copy mode. Otherwise the instance will be suspended
|
|
|
|
|
until the migration is completed or aborted.
|
|
|
|
|
cli=nova live-migration-force-complete <server> <migration>
|
|
|
|
|
driver.nova-lxd=unknown
|
|
|
|
|
|
|
|
|
|
[operation.launch]
|
|
|
|
|
title=Launch instance
|
|
|
|
|
status=mandatory
|
|
|
|
|
notes=Importing pre-existing running virtual machines on a host is
|
|
|
|
|
considered out of scope of the cloud paradigm. Therefore this
|
|
|
|
|
operation is mandatory to support in drivers.
|
|
|
|
|
cli=
|
|
|
|
|
driver.nova-lxd=unknown
|
|
|
|
|
|
|
|
|
|
[operation.pause]
|
|
|
|
|
title=Stop instance CPUs (pause)
|
|
|
|
|
status=optional
|
|
|
|
|
notes=Stopping an instances CPUs can be thought of as roughly
|
|
|
|
|
equivalent to suspend-to-RAM. The instance is still present
|
|
|
|
|
in memory, but execution has stopped. The problem, however,
|
|
|
|
|
is that there is no mechanism to inform the guest OS that
|
|
|
|
|
this takes place, so upon unpausing, its clocks will no
|
|
|
|
|
longer report correct time. For this reason hypervisor vendors
|
|
|
|
|
generally discourage use of this feature and some do not even
|
|
|
|
|
implement it. Therefore this operation is considered optional
|
|
|
|
|
to support in drivers.
|
|
|
|
|
cli=nova pause <server>
|
|
|
|
|
driver.nova-lxd=complete
|
|
|
|
|
|
|
|
|
|
[operation.reboot]
|
|
|
|
|
title=Reboot instance
|
|
|
|
|
status=optional
|
|
|
|
|
notes=It is reasonable for a guest OS administrator to trigger a
|
|
|
|
|
graceful reboot from inside the instance. A host initiated
|
|
|
|
|
graceful reboot requires guest co-operation and a non-graceful
|
|
|
|
|
reboot can be achieved by a combination of stop+start. Therefore
|
|
|
|
|
this operation is considered optional.
|
|
|
|
|
cli=nova reboot <server>
|
|
|
|
|
driver.nova-lxd=complete
|
|
|
|
|
|
|
|
|
|
[operation.rescue]
|
|
|
|
|
title=Rescue instance
|
|
|
|
|
status=optional
|
|
|
|
|
notes=The rescue operation starts an instance in a special
|
|
|
|
|
configuration whereby it is booted from an special root
|
|
|
|
|
disk image. The goal is to allow an administrator to
|
|
|
|
|
recover the state of a broken virtual machine. In general
|
|
|
|
|
the cloud model considers instances to be cattle, so if
|
|
|
|
|
an instance breaks the general expectation is that it be
|
|
|
|
|
thrown away and a new instance created. Therefore this
|
|
|
|
|
operation is considered optional to support in drivers.
|
|
|
|
|
cli=nova rescue <server>
|
|
|
|
|
driver.nova-lxd=complete
|
|
|
|
|
|
|
|
|
|
[operation.resize]
|
|
|
|
|
title=Resize instance
|
|
|
|
|
status=optional
|
|
|
|
|
notes=The resize operation allows the user to change a running
|
|
|
|
|
instance to match the size of a different flavor from the one
|
|
|
|
|
it was initially launched with. There are many different
|
|
|
|
|
flavor attributes that potentially need to be updated. In
|
|
|
|
|
general it is technically challenging for a hypervisor to
|
|
|
|
|
support the alteration of all relevant config settings for a
|
|
|
|
|
running instance. Therefore this operation is considered
|
|
|
|
|
optional to support in drivers.
|
|
|
|
|
cli=nova resize <server> <flavor>
|
|
|
|
|
driver.nova-lxd=missing
|
|
|
|
|
|
|
|
|
|
[operation.resume]
|
|
|
|
|
title=Restore instance
|
|
|
|
|
status=optional
|
|
|
|
|
notes=See notes for the suspend operation
|
|
|
|
|
cli=nova resume <server>
|
|
|
|
|
driver.nova-lxd=complete
|
|
|
|
|
|
|
|
|
|
[operation.set-admin-password]
|
|
|
|
|
title=Set instance admin password
|
|
|
|
|
status=optional
|
|
|
|
|
notes=Provides a mechanism to (re)set the password of the administrator
|
|
|
|
|
account inside the instance operating system. This requires that the
|
|
|
|
|
hypervisor has a way to communicate with the running guest operating
|
|
|
|
|
system. Given the wide range of operating systems in existence it is
|
|
|
|
|
unreasonable to expect this to be practical in the general case. The
|
|
|
|
|
configdrive and metadata service both provide a mechanism for setting
|
|
|
|
|
the administrator password at initial boot time. In the case where this
|
|
|
|
|
operation were not available, the administrator would simply have to
|
|
|
|
|
login to the guest and change the password in the normal manner, so
|
|
|
|
|
this is just a convenient optimization. Therefore this operation is
|
|
|
|
|
not considered mandatory for drivers to support.
|
|
|
|
|
cli=nova set-password <server>
|
|
|
|
|
driver.nova-lxd=unknown
|
|
|
|
|
|
|
|
|
|
[operation.snapshot]
|
|
|
|
|
title=Save snapshot of instance disk
|
|
|
|
|
status=optional
|
|
|
|
|
notes=The snapshot operation allows the current state of the
|
|
|
|
|
instance root disk to be saved and uploaded back into the
|
|
|
|
|
glance image repository. The instance can later be booted
|
|
|
|
|
again using this saved image. This is in effect making
|
|
|
|
|
the ephemeral instance root disk into a semi-persistent
|
|
|
|
|
storage, in so much as it is preserved even though the guest
|
|
|
|
|
is no longer running. In general though, the expectation is
|
|
|
|
|
that the root disks are ephemeral so the ability to take a
|
|
|
|
|
snapshot cannot be assumed. Therefore this operation is not
|
|
|
|
|
considered mandatory to support.
|
|
|
|
|
cli=nova image-create <server> <name>
|
|
|
|
|
driver.nova-lxd=complete
|
|
|
|
|
|
|
|
|
|
[operation.suspend]
|
|
|
|
|
title=Suspend instance
|
|
|
|
|
status=optional
|
|
|
|
|
notes=Suspending an instance can be thought of as roughly
|
|
|
|
|
equivalent to suspend-to-disk. The instance no longer
|
|
|
|
|
consumes any RAM or CPUs, with its live running state
|
|
|
|
|
having been preserved in a file on disk. It can later
|
|
|
|
|
be restored, at which point it should continue execution
|
|
|
|
|
where it left off. As with stopping instance CPUs, it suffers from the fact
|
|
|
|
|
that the guest OS will typically be left with a clock that
|
|
|
|
|
is no longer telling correct time. For container based
|
|
|
|
|
virtualization solutions, this operation is particularly
|
|
|
|
|
technically challenging to implement and is an area of
|
|
|
|
|
active research. This operation tends to make more sense
|
|
|
|
|
when thinking of instances as pets, rather than cattle,
|
|
|
|
|
since with cattle it would be simpler to just terminate
|
|
|
|
|
the instance instead of suspending. Therefore this operation
|
|
|
|
|
is considered optional to support.
|
|
|
|
|
cli=nova suspend <server>
|
|
|
|
|
driver.nova-lxd=complete
|
|
|
|
|
|
|
|
|
|
[operation.swap-volume]
|
|
|
|
|
title=Swap block volumes
|
|
|
|
|
status=optional
|
|
|
|
|
notes=The swap volume operation is a mechanism for changing a running
|
|
|
|
|
instance so that its attached volume(s) are backed by different
|
|
|
|
|
storage in the host. An alternative to this would be to simply
|
|
|
|
|
terminate the existing instance and spawn a new instance with the
|
|
|
|
|
new storage. In other words this operation is primarily targeted towards
|
|
|
|
|
the pet use case rather than cattle, however, it is required for volume
|
|
|
|
|
migration to work in the volume service. This is considered optional to
|
|
|
|
|
support.
|
|
|
|
|
cli=nova volume-update <server> <attachment> <volume>
|
|
|
|
|
driver.nova-lxd=missing
|
|
|
|
|
|
|
|
|
|
[operation.terminate]
|
|
|
|
|
title=Shutdown instance
|
|
|
|
|
status=mandatory
|
|
|
|
|
notes=The ability to terminate a virtual machine is required in
|
|
|
|
|
order for a cloud user to stop utilizing resources and thus
|
|
|
|
|
avoid indefinitely ongoing billing. Therefore this operation
|
|
|
|
|
is mandatory to support in drivers.
|
|
|
|
|
cli=nova delete <server>
|
|
|
|
|
driver.nova-lxd=complete
|
|
|
|
|
|
|
|
|
|
[operation.trigger-crash-dump]
|
|
|
|
|
title=Trigger crash dump
|
|
|
|
|
status=optional
|
|
|
|
|
notes=The trigger crash dump operation is a mechanism for triggering
|
|
|
|
|
a crash dump in an instance. The feature is typically implemented by
|
|
|
|
|
injecting an NMI (Non-maskable Interrupt) into the instance. It provides
|
|
|
|
|
a means to dump the production memory image as a dump file which is useful
|
|
|
|
|
for users. Therefore this operation is considered optional to support.
|
|
|
|
|
cli=nova trigger-crash-dump <server>
|
|
|
|
|
driver.nova-lxd=unknown
|
|
|
|
|
|
|
|
|
|
[operation.unpause]
|
|
|
|
|
title=Resume instance CPUs (unpause)
|
|
|
|
|
status=optional
|
|
|
|
|
notes=See notes for the "Stop instance CPUs" operation
|
|
|
|
|
cli=nova unpause <server>
|
|
|
|
|
driver.nova-lxd=unknown
|
|
|
|
|
|
|
|
|
|
[operation.guest.disk.autoconfig]
|
|
|
|
|
title=[Guest]Auto configure disk
|
|
|
|
|
status=optional
|
|
|
|
|
notes=Partition and resize FS to match the size specified by
|
|
|
|
|
flavors.root_gb, As this is hypervisor specific feature.
|
|
|
|
|
Therefore this operation is considered optional to support.
|
|
|
|
|
cli=
|
|
|
|
|
driver.nova-lxd=complete
|
|
|
|
|
|
|
|
|
|
[operation.guest.disk.rate-limit]
|
|
|
|
|
title=[Guest]Instance disk I/O limits
|
|
|
|
|
status=optional
|
|
|
|
|
notes=The ability to set rate limits on virtual disks allows for
|
|
|
|
|
greater performance isolation between instances running on the
|
|
|
|
|
same host storage. It is valid to delegate scheduling of I/O
|
|
|
|
|
operations to the hypervisor with its default settings, instead
|
|
|
|
|
of doing fine grained tuning. Therefore this is not considered
|
|
|
|
|
to be an mandatory configuration to support.
|
|
|
|
|
cli=nova limits
|
|
|
|
|
driver.nova-lxd=unknown
|
|
|
|
|
|
|
|
|
|
[operation.guest.setup.configdrive]
|
|
|
|
|
title=[Guest]Config drive support
|
|
|
|
|
status=choice(guest.setup)
|
|
|
|
|
notes=The config drive provides an information channel into
|
|
|
|
|
the guest operating system, to enable configuration of the
|
|
|
|
|
administrator password, file injection, registration of
|
|
|
|
|
SSH keys, etc. Since cloud images typically ship with all
|
|
|
|
|
login methods locked, a mechanism to set the administrator
|
|
|
|
|
password or keys is required to get login access. Alternatives
|
|
|
|
|
include the metadata service and disk injection. At least one
|
|
|
|
|
of the guest setup mechanisms is required to be supported by
|
|
|
|
|
drivers, in order to enable login access.
|
|
|
|
|
cli=
|
|
|
|
|
driver.nova-lxd=complete
|
|
|
|
|
|
|
|
|
|
[operation.guest.setup.inject.file]
|
|
|
|
|
title=[Guest]Inject files into disk image
|
|
|
|
|
status=optional
|
|
|
|
|
notes=This allows for the end user to provide data for multiple
|
|
|
|
|
files to be injected into the root filesystem before an instance
|
|
|
|
|
is booted. This requires that the compute node understand the
|
|
|
|
|
format of the filesystem and any partitioning scheme it might
|
|
|
|
|
use on the block device. This is a non-trivial problem considering
|
|
|
|
|
the vast number of filesystems in existence. The problem of injecting
|
|
|
|
|
files to a guest OS is better solved by obtaining via the metadata
|
|
|
|
|
service or config drive. Therefore this operation is considered
|
|
|
|
|
optional to support.
|
|
|
|
|
cli=
|
|
|
|
|
driver.nova-lxd=unknown
|
|
|
|
|
|
|
|
|
|
[operation.guest.setup.inject.networking]
|
|
|
|
|
title=[Guest]Inject guest networking config
|
|
|
|
|
status=optional
|
|
|
|
|
notes=This allows for static networking configuration (IP
|
|
|
|
|
address, netmask, gateway and routes) to be injected directly
|
|
|
|
|
into the root filesystem before an instance is booted. This
|
|
|
|
|
requires that the compute node understand how networking is
|
|
|
|
|
configured in the guest OS which is a non-trivial problem
|
|
|
|
|
considering the vast number of operating system types. The
|
|
|
|
|
problem of configuring networking is better solved by DHCP
|
|
|
|
|
or by obtaining static config via
|
|
|
|
|
config drive. Therefore this operation is considered optional
|
|
|
|
|
to support.
|
|
|
|
|
cli=
|
|
|
|
|
driver.nova-lxd=unknown
|
|
|
|
|
|
|
|
|
|
[operation.console.rdp]
|
|
|
|
|
title=[Console]Remote desktop over RDP
|
|
|
|
|
status=choice(console)
|
|
|
|
|
notes=This allows the administrator to interact with the graphical
|
|
|
|
|
console of the guest OS via RDP. This provides a way to see boot
|
|
|
|
|
up messages and login to the instance when networking configuration
|
|
|
|
|
has failed, thus preventing a network based login. Some operating
|
|
|
|
|
systems may prefer to emit messages via the serial console for
|
|
|
|
|
easier consumption. Therefore support for this operation is not
|
|
|
|
|
mandatory, however, a driver is required to support at least one
|
|
|
|
|
of the listed console access operations.
|
|
|
|
|
cli=nova get-rdp-console <server> <console-type>
|
|
|
|
|
driver.nova-lxd=missing
|
|
|
|
|
|
|
|
|
|
[operation.console.serial.log]
|
|
|
|
|
title=[Console]View serial console logs
|
|
|
|
|
status=choice(console)
|
|
|
|
|
notes=This allows the administrator to query the logs of data
|
|
|
|
|
emitted by the guest OS on its virtualized serial port. For
|
|
|
|
|
UNIX guests this typically includes all boot up messages and
|
|
|
|
|
so is useful for diagnosing problems when an instance fails
|
|
|
|
|
to successfully boot. Not all guest operating systems will be
|
|
|
|
|
able to emit boot information on a serial console, others may
|
|
|
|
|
only support graphical consoles. Therefore support for this
|
|
|
|
|
operation is not mandatory, however, a driver is required to
|
|
|
|
|
support at least one of the listed console access operations.
|
|
|
|
|
cli=nova console-log <server>
|
|
|
|
|
driver.nova-lxd=complete
|
|
|
|
|
|
|
|
|
|
[operation.console.serial.interactive]
|
|
|
|
|
title=[Console]Remote interactive serial console
|
|
|
|
|
status=choice(console)
|
|
|
|
|
notes=This allows the administrator to interact with the serial
|
|
|
|
|
console of the guest OS. This provides a way to see boot
|
|
|
|
|
up messages and login to the instance when networking configuration
|
|
|
|
|
has failed, thus preventing a network based login. Not all guest
|
|
|
|
|
operating systems will be able to emit boot information on a serial
|
|
|
|
|
console, others may only support graphical consoles. Therefore support
|
|
|
|
|
for this operation is not mandatory, however, a driver is required to
|
|
|
|
|
support at least one of the listed console access operations.
|
|
|
|
|
This feature was introduced in the Juno release with blueprint
|
|
|
|
|
https://blueprints.launchpad.net/nova/+spec/serial-ports
|
|
|
|
|
cli=nova get-serial-console <server>
|
|
|
|
|
driver.nova-lxd=unknown
|
|
|
|
|
|
|
|
|
|
[operation.console.spice]
|
|
|
|
|
title=[Console]Remote desktop over SPICE
|
|
|
|
|
status=choice(console)
|
|
|
|
|
notes=This allows the administrator to interact with the graphical
|
|
|
|
|
console of the guest OS via SPICE. This provides a way to see boot
|
|
|
|
|
up messages and login to the instance when networking configuration
|
|
|
|
|
has failed, thus preventing a network based login. Some operating
|
|
|
|
|
systems may prefer to emit messages via the serial console for
|
|
|
|
|
easier consumption. Therefore support for this operation is not
|
|
|
|
|
mandatory, however, a driver is required to support at least one
|
|
|
|
|
of the listed console access operations.
|
|
|
|
|
cli=nova get-spice-console <server> <console-type>
|
|
|
|
|
driver.nova-lxd=missing
|
|
|
|
|
|
|
|
|
|
[operation.console.vnc]
|
|
|
|
|
title=[Console]Remote desktop over VNC
|
|
|
|
|
status=choice(console)
|
|
|
|
|
notes=This allows the administrator to interact with the graphical
|
|
|
|
|
console of the guest OS via VNC. This provides a way to see boot
|
|
|
|
|
up messages and login to the instance when networking configuration
|
|
|
|
|
has failed, thus preventing a network based login. Some operating
|
|
|
|
|
systems may prefer to emit messages via the serial console for
|
|
|
|
|
easier consumption. Therefore support for this operation is not
|
|
|
|
|
mandatory, however, a driver is required to support at least one
|
|
|
|
|
of the listed console access operations.
|
|
|
|
|
cli=nova get-vnc-console <server> <console-type>
|
|
|
|
|
driver.nova-lxd=missing
|
|
|
|
|
|
|
|
|
|
[operation.storage.block]
|
|
|
|
|
title=[Storage]Block storage support
|
|
|
|
|
status=optional
|
|
|
|
|
notes=Block storage provides instances with direct attached
|
|
|
|
|
virtual disks that can be used for persistent storage of data.
|
|
|
|
|
As an alternative to direct attached disks, an instance may
|
|
|
|
|
choose to use network based persistent storage. OpenStack provides
|
|
|
|
|
object storage via the Swift service, or a traditional filesystem
|
|
|
|
|
such as NFS may be used. Some types of instances may
|
|
|
|
|
not require persistent storage at all, being simple transaction
|
|
|
|
|
processing systems reading requests & sending results to and from
|
|
|
|
|
the network. Therefore support for this configuration is not
|
|
|
|
|
considered mandatory for drivers to support.
|
|
|
|
|
cli=
|
|
|
|
|
driver.nova-lxd=partial
|
|
|
|
|
driver-notes.nova-lxd=Booting instances from block storages is not supported.
|
|
|
|
|
|
|
|
|
|
[operation.storage.block.backend.fibrechannel]
|
|
|
|
|
title=[Storage]Block storage over fibre channel
|
|
|
|
|
status=optional
|
|
|
|
|
notes=To maximise performance of the block storage, it may be desirable
|
|
|
|
|
to directly access fibre channel LUNs from the underlying storage
|
|
|
|
|
technology on the compute hosts. Since this is just a performance
|
|
|
|
|
optimization of the I/O path it is not considered mandatory to support.
|
|
|
|
|
cli=
|
|
|
|
|
driver.nova-lxd=unknown
|
|
|
|
|
|
|
|
|
|
[operation.storage.block.backend.iscsi]
|
|
|
|
|
title=[Storage]Block storage over iSCSI
|
|
|
|
|
status=condition(storage.block==complete)
|
|
|
|
|
notes=If the driver wishes to support block storage, it is common to
|
|
|
|
|
provide an iSCSI based backend to access the storage from cinder.
|
|
|
|
|
This isolates the compute layer for knowledge of the specific storage
|
|
|
|
|
technology used by Cinder, albeit at a potential performance cost due
|
|
|
|
|
to the longer I/O path involved. If the driver chooses to support
|
|
|
|
|
block storage, then this is considered mandatory to support, otherwise
|
|
|
|
|
it is considered optional.
|
|
|
|
|
cli=
|
|
|
|
|
driver.nova-lxd=complete
|
|
|
|
|
|
|
|
|
|
[operation.storage.block.backend.iscsi.auth.chap]
|
|
|
|
|
title=[Storage]CHAP authentication for iSCSI
|
|
|
|
|
status=optional
|
|
|
|
|
notes=If accessing the cinder iSCSI service over an untrusted LAN it
|
|
|
|
|
is desirable to be able to enable authentication for the iSCSI
|
|
|
|
|
protocol. CHAP is the commonly used authentication protocol for
|
|
|
|
|
iSCSI. This is not considered mandatory to support. (?)
|
|
|
|
|
cli=
|
|
|
|
|
driver.nova-lxd=unknown
|
|
|
|
|
|
|
|
|
|
[operation.storage.block.ceph]
|
|
|
|
|
title=[Storage]Block storage over RBD(Ceph)
|
|
|
|
|
status=condition(storage.block==complete)
|
|
|
|
|
notes=Ceph is an open source software storage platform based upon RADOS.
|
|
|
|
|
Instances can access to the ceph storage cluster by ceph's RBD(RADOS
|
|
|
|
|
Block Device).
|
|
|
|
|
cli=
|
|
|
|
|
driver.nova-lxd=complete
|
|
|
|
|
|
|
|
|
|
[operation.storage.image]
|
|
|
|
|
title=[Storage]Image storage support
|
|
|
|
|
status=mandatory
|
|
|
|
|
notes=This refers to the ability to boot an instance from an image
|
|
|
|
|
stored in the glance image repository. Without this feature it
|
|
|
|
|
would not be possible to bootstrap from a clean environment, since
|
|
|
|
|
there would be no way to get block volumes populated and reliance
|
|
|
|
|
on external PXE servers is out of scope. Therefore this is considered
|
|
|
|
|
a mandatory storage feature to support.
|
|
|
|
|
cli=nova boot --image <image> <name>
|
|
|
|
|
driver.nova-lxd=complete
|
|
|
|
|
|
|
|
|
|
[operation.networking.firewallrules]
|
|
|
|
|
title=[Networking]Network firewall rules
|
|
|
|
|
status=optional
|
|
|
|
|
notes=Unclear how this is different from security groups
|
|
|
|
|
cli=
|
|
|
|
|
driver.nova-lxd=complete
|
|
|
|
|
|
|
|
|
|
[operation.networking.routing]
|
|
|
|
|
title=Network routing
|
|
|
|
|
status=optional
|
|
|
|
|
notes=Unclear what this refers to
|
|
|
|
|
cli=
|
|
|
|
|
driver.nova-lxd=complete
|
|
|
|
|
|
|
|
|
|
[operation.networking.securitygroups]
|
|
|
|
|
title=[Networking]Network security groups
|
|
|
|
|
status=optional
|
|
|
|
|
notes=The security groups feature provides a way to define rules
|
|
|
|
|
to isolate the network traffic of different instances running
|
|
|
|
|
on a compute host. This would prevent actions such as MAC and
|
|
|
|
|
IP address spoofing, or the ability to setup rogue DHCP servers.
|
|
|
|
|
In a private cloud environment this may be considered to be a
|
|
|
|
|
superfluous requirement. Therefore this is considered to be an
|
|
|
|
|
optional configuration to support.
|
|
|
|
|
cli=
|
|
|
|
|
driver.nova-lxd=complete
|
|
|
|
|
|
|
|
|
|
[operation.networking.topology.flat]
|
|
|
|
|
title=[Networking]Flat networking
|
|
|
|
|
status=choice(networking.topology)
|
|
|
|
|
notes=Provide network connectivity to guests using a
|
|
|
|
|
flat topology across all compute nodes. At least one
|
|
|
|
|
of the networking configurations is mandatory to
|
|
|
|
|
support in the drivers.
|
|
|
|
|
cli=
|
|
|
|
|
driver.nova-lxd=complete
|
|
|
|
|
|
|
|
|
|
[operation.networking.topology.vlan]
|
|
|
|
|
title=[Networking]VLAN networking
|
|
|
|
|
status=choice(networking.topology)
|
|
|
|
|
notes=Provide network connectivity to guests using VLANs to define the
|
|
|
|
|
topology. At least one of the networking configurations is mandatory
|
|
|
|
|
to support in the drivers.
|
|
|
|
|
cli=
|
|
|
|
|
driver.nova-lxd=complete
|
|
|
|
|
|
|
|
|
|
[operation.networking.topology.vxlan]
|
|
|
|
|
title=[Networking]VXLAN networking
|
|
|
|
|
status=choice(networking.topology)
|
|
|
|
|
notes=Provide network connectivity to guests using VXLANs to define the
|
|
|
|
|
topology. At least one of the networking configurations is mandatory
|
|
|
|
|
to support in the drivers.
|
|
|
|
|
cli=
|
|
|
|
|
driver.nova-lxd=complete
|
|
|
|
|
|
|
|
|
|
[operation.uefi-boot]
|
|
|
|
|
title=uefi boot
|
|
|
|
|
status=optional
|
|
|
|
|
notes=This allows users to boot a guest with uefi firmware.
|
|
|
|
|
cli=
|
|
|
|
|
driver.nova-lxd=unknown
|
|
|
|
|
|
|
|
|
|
[operation.device-tags]
|
|
|
|
|
title=Device tags
|
|
|
|
|
status=optional
|
|
|
|
|
notes=This allows users to set tags on virtual devices when creating a
|
|
|
|
|
server instance. Device tags are used to identify virtual device
|
|
|
|
|
metadata, as exposed in the metadata API and on the config drive.
|
|
|
|
|
For example, a network interface tagged with "nic1" will appear in
|
|
|
|
|
the metadata along with its bus (ex: PCI), bus address
|
|
|
|
|
(ex: 0000:00:02.0), MAC address, and tag (nic1). If multiple networks
|
|
|
|
|
are defined, the order in which they appear in the guest operating
|
|
|
|
|
system will not necessarily reflect the order in which they are given
|
|
|
|
|
in the server boot request. Guests should therefore not depend on
|
|
|
|
|
device order to deduce any information about their network devices.
|
|
|
|
|
Instead, device role tags should be used. Device tags can be
|
|
|
|
|
applied to virtual network interfaces and block devices.
|
|
|
|
|
cli=nova boot
|
|
|
|
|
driver.nova-lxd=unknown
|
|
|
|
|
|
|
|
|
|
[operation.quiesce]
|
|
|
|
|
title=quiesce
|
|
|
|
|
status=optional
|
|
|
|
|
notes=Quiesce the specified instance to prepare for snapshots.
|
|
|
|
|
For libvirt, guest filesystems will be frozen through qemu
|
|
|
|
|
agent.
|
|
|
|
|
cli=
|
|
|
|
|
driver.nova-lxd=unknown
|
|
|
|
|
|
|
|
|
|
[operation.unquiesce]
|
|
|
|
|
title=unquiesce
|
|
|
|
|
status=optional
|
|
|
|
|
notes=See notes for the quiesce operation
|
|
|
|
|
cli=
|
|
|
|
|
driver.nova-lxd=unknown
|
|
|
|
|
|
|
|
|
|
[operation.multiattach-volume]
|
|
|
|
|
title=Attach block volume to multiple instances
|
|
|
|
|
status=optional
|
|
|
|
|
notes=The multiattach volume operation is an extension to
|
|
|
|
|
the attach volume operation. It allows to attach a
|
|
|
|
|
single volume to multiple instances. This operation is
|
|
|
|
|
not considered to be mandatory to support.
|
|
|
|
|
Note that for the libvirt driver, this is only supported
|
|
|
|
|
if qemu<2.10 or libvirt>=3.10.
|
|
|
|
|
cli=nova volume-attach <server> <volume>
|
|
|
|
|
driver.nova-lxd=unknown
|
|
|
|
|
|
|
|
|
|
[operation.encrypted-volume]
|
|
|
|
|
title=Attach encrypted block volume to server
|
|
|
|
|
status=optional
|
|
|
|
|
notes=This is the same as the attach volume operation
|
|
|
|
|
except with an encrypted block device. Encrypted
|
|
|
|
|
volumes are controlled via admin-configured volume
|
|
|
|
|
types in the block storage service. Since attach
|
|
|
|
|
volume is optional this feature is also optional for
|
|
|
|
|
compute drivers to support.
|
|
|
|
|
cli=nova volume-attach <server> <volume>
|
|
|
|
|
driver.nova-lxd=unknown
|
|
|
|
|
|
|
|
|
|
[operation.trusted-certs]
|
|
|
|
|
title=Validate image with trusted certificates
|
|
|
|
|
status=optional
|
|
|
|
|
notes=Since trusted image certification validation is configurable
|
|
|
|
|
by the cloud deployer it is considered optional. However, it is
|
|
|
|
|
a virt-agnostic feature so there is no good reason that all virt
|
|
|
|
|
drivers cannot support the feature since it is mostly just plumbing
|
|
|
|
|
user requests through the virt driver when downloading images.
|
|
|
|
|
cli=nova boot --trusted-image-certificate-id ...
|
|
|
|
|
driver.nova-lxd=unknown
|
|
|
|
|
|
|
|
|
|
[operation.file-backed-memory]
|
|
|
|
|
title=File backed memory
|
|
|
|
|
status=optional
|
|
|
|
|
notes=The file backed memory feature in Openstack allows a Nova node to serve
|
|
|
|
|
guest memory from a file backing store. This mechanism uses the libvirt
|
|
|
|
|
file memory source, causing guest instance memory to be allocated as files
|
|
|
|
|
within the libvirt memory backing directory. This is only supported if
|
|
|
|
|
qemu>2.6 and libivrt>4.0.0
|
|
|
|
|
cli=
|
|
|
|
|
driver.nova-lxd=unknown
|
|
|
|
|
|
|
|
|
|
[operation.report-cpu-traits]
|
|
|
|
|
title=Report CPU traits
|
|
|
|
|
status=optional
|
|
|
|
|
notes=The report CPU traits feature in OpenStack allows a Nova node to report
|
|
|
|
|
its CPU traits according to CPU mode configuration. This gives users the ability
|
|
|
|
|
to boot instances based on desired CPU traits.
|
|
|
|
|
cli=
|
|
|
|
|
driver.nova-lxd=unknown
|