Configuration¶
In addition to the Nova config options, compute-hyperv has a few extra configuration options. For a sample configuration file, refer to Configuration sample.
Driver configuration¶
In order to use the compute-hyperv Nova driver, the following configuration
option will have to be set in the nova.conf
file:
[DEFAULT]
compute_driver = compute_hyperv.driver.HyperVDriver
And for Hyper-V Clusters, the following:
[DEFAULT]
compute_driver = compute_hyperv.cluster.driver.HyperVClusterDriver
instances_path = path\to\cluster\wide\storage\location
sync_power_state_interval = -1
[workarounds]
handle_virt_lifecycle_events = False
By default, the OpenStack Hyper-V installer will configure the nova-compute
service to use the compute_hyperv.driver.HyperVDriver
driver.
Storage configuration¶
When spawning instances, nova-compute
will create the VM related files (
VM configuration file, ephemerals, configdrive, console.log, etc.) in the
location specified by the instances_path
configuration option, even if
the instance is volume-backed.
It is not recommended for Nova and Cinder to use the same storage location, as that can create scheduling and disk overcommitment issues.
Nova instance files location¶
By default, the OpenStack Hyper-V installer will configure nova-compute
to
use the following path as the instances_path
:
[DEFAULT]
instances_path = C:\OpenStack\Instances
instances_path
can be set to an SMB share, mounted or unmounted:
[DEFAULT]
# in this case, X is a persistently mounted SMB share.
instances_path = X:\OpenStack\Instances
# or
instances_path = \\SMB_SERVER\share_name\OpenStack\Instances
Alternatively, CSVs can be used:
[DEFAULT]
instances_path = C:\ClusterStorage\Volume1\OpenStack\Instances
When the compute hosts are using different CSVs, Nova must be configured not to delete unused images since its image caching mechanism can’t properly track the image file usage in this case.
[image_cache]
remove_unused_base_images = False
Block Storage (Cinder) configuration¶
This section describes Nova configuration options that handle the way in which Cinder volumes are consumed.
When having multiple paths connecting the host to the storage backend, make sure to enable the following config option:
[hyperv]
use_multipath_io = True
This will ensure that the available paths are actually leveraged. Also, before attempting any volume connection, it will ensure that the MPIO service is enabled and that passthrough block devices (iSCSI / FC) are claimed by MPIO. SMB backed volumes are not affected by this option.
In some cases, Nova may fail to attach volumes due to transient connectivity issues. The following options specify how many and how often retries should be performed.
[hyperv]
# Those are the default values.
volume_attach_retry_count = 10
volume_attach_retry_interval = 5
# The following options only apply to disk scan retries.
mounted_disk_query_retry_count = 10
mounted_disk_query_retry_interval = 5
When having one or more hardware iSCSI initiators, you may use the following config option, explicitly telling Nova which iSCSI initiator to use:
[hyperv]
iscsi_initiator_list = PCI\VEN_1077&DEV_2031&SUBSYS_17E8103C&REV_02\\4&257301f0&0&0010_0, PCI\VEN_1077&DEV_2031&SUBSYS_17E8103C&REV_02\4&257301f0&0&0010_1
The list of available initiators may be retrieved using:
Get-InitiatorPort
If no iSCSI initiator is specified, the MS iSCSI Initiator service will only pick one of the available ones when establishing iSCSI sessions.
Live migration configuration¶
For live migrating virtual machines to hosts with different CPU features the
following configuration option must be set in the compute node’s nova.conf
file:
[hyperv]
limit_cpu_features = True
Keep in mind that changing this configuration option will not affect the instances that are already spawned, meaning that instances spawned with this flag set to False will not be able to live migrate to hosts with different CPU features, and that they will have to be shut down and rebuilt, or have the setting manually set.
Whitelisting PCI devices¶
After the assignable PCI devices have been prepared for Hyper-V
(PCI passthrough host configuration), the next step is whitelist them in the compute
node’s nova.conf
.
[pci]
# this is a list of dictionaries, more dictionaries can be added.
passthrough_whitelist = [{"vendor_id": "<dev_vendor_id>", "product_id": "<dev_product_id>"}]
The vendor_id
and product_id
necessary for the passthrough_whitelist
can be obtained from assignable PCI device’s InstanceId
:
Get-VMHostAssignableDevice
The InstanceId
should have the following format:
PCIP\VEN_<vendor_id>&DEV_<product_id>
The <vendor_id>
and <product_id>
can be extracted and used in the
nova.conf
file. After the configuration file has been changed, the
nova-compute
service will have to be restarted.
Afterwards, the nova-api
and nova-scheduler
services will have to be
configured. For this, check the nova PCI passthrough configuration guide.
Distributed locking configuration¶
In order to avoid race conditions, our driver relies on distributed locks. A distributed lock backend such as etcd, mysql or a file share will have to be configured.
The following configuration will use etcd 3 as a lock backend:
[coordination]
backend_url = etcd3+http://etcd_address:2379
Note
The etcd3gw
python package is required when using etcd 3. This does not
apply to the v2 etcd API, which may be requested through
etcd://etcd_address:2379
.
In order to use a file share, set the following:
[coordination]
backend_url = file:////share_addr/share_name