The hypervisor ID in path parameters have been fixed to 'integer'.
In "Search Hypervisor" and "List Hypervisor Servers",
the hypervisor IDs have been fixed to a string for searching
hypervisor host names.
Change-Id: I2260f0c4ca82d5a2ae5a46bcf8f48f9eaaf09f2f
Closes-Bug: #1654197
Currently if Nova is using the libvirt LXC driver, it is
hardcoded to report 1 vCPU used on the host, regardless
of how many containers are running.
Meanwhile for QEMU (aka TCG) guests, the guest.get_vcpu_info
method is throwing an exception, since QEMU does not use
a dedicated thread per vCPU currently. The effect is that
on QEMU hosts, we're reporting 0 vCPUs used on the host
regardless of how many guests are running
This causes the 'get_available_resources' method to report
incorrect 'vcpus_used' values for the compute node. By a
stroke of luck, the resource tracker merely logs this
value and then throws it away, instead counting vcpu
usage based on vcpus declared against the flavour. Now
ignoring the hypervisor reported data is arguably a bug
in the resource tracker, because it means it is overcounting
resource consumption for plain QEMU guests (they can only
ever consume 1 pCPU of time, regardless of vCPU count).
Fixing the resource tracker is out of scope for now, but
we should at least ensure we're reporting accurate data
to it, even if it is only used for logging at this time.
If a host does not report detailed vCPU usage from libvirt
then we should default to reporting 1 vCPU per guest, so
that the 'vcpus_used' field reports some reasonably
meaningful data on host CPU usage.
Closes-bug: #1638889
Change-Id: I627d30d61f8ead6211f78a1c79ffd79b81333f86
Handle the network interface new vlans field and expose it in the devices
metadata
The vlan tag will be exposed to the instance through the metadata API and
on the config drive.
Implements: blueprint sriov-pf-passthrough-neutron-port-vlan
Change-Id: Id7b9f3f1c2107ec604e7f0ef4fbfd31a9e05d0b0
Enhance the _build_device_metadata method to expose virtual interface with vlan
to the devices metadata. Previously, only interfaces with tags could be
exposed.
Implements: blueprint sriov-pf-passthrough-neutron-port-vlan
Change-Id: I7abf16b996bd68aa7fa1e3a121eae3147a244284
Adding a new 'vlan' field to the NetworkInterfaceMetadata object
to expose the vlan assigned to a virtual interface, to devices metadata.
Implements: blueprint sriov-pf-passthrough-neutron-port-vlan
Change-Id: I0071474191b6304a87661f73c63e6eeef9a01ac7
This reworks a big chunk of the instance boot flow. A new method has
been added to the conductor which will handle the initial scheduling and
creation of an instance in the cell db. At that point the request moves
to the compute as normal. A reschedule will call back to the cell
conductor as normal and can not result in a host from another cell being
selected.
Co-Authored-By: Dan Smith <dansmith@redhat.com>
Implements: bp cells-scheduling-interaction
Change-Id: I8742071b55f018f864f5a382de20075a5b444a79
Depends-On: I8938fd37f71498e87aa348a81c357eef5c1a8093
Given we will use the placement API for the next change, we need to verify
all the filters like we already do for other functional tests, and just
use large allocation ratios for cpu and disk instead of disabling the
corresponding filters.
Given we wanted to keep the same test coverage which asserts that instances
are only RAM-bound (because it was only verifying RAMFilter previously),
we are providing a new FakeDriver for having large resources for CPU and disk
so we are sure we are not limited by that.
Change-Id: I92afc017146792968130cf4ad238d67ed1dfa308
Current algorithm to calculate maximum tolerable downtime uses
exponential function. It means that initially max downtime is
increased by small amounts and as time goes by it is increased
by larger amounts.
Let's assume we have an instance with 8GBs of memory and 10Gb
private dedicated network just for live migration purposes and
that there will be 10 steps, 30 second step delay and 400ms
target maximum downtime. A single iteration of live migration
will take about 6.5 seconds (8GBs / (10Gb / 8)). According to
LM configuration nova will increase downtime for the first time
after 240 seconds. It means that hypervisor will be able to do
about 37 memory iterations. After that many iterations nova will
increase maximum tolerable downtime by just 1ms, which means
that during the downtime of an instance hypervisor will be able
to transfer only 1.25MB more. After that many iterations, if
live migration is still in progress, 1ms probably will not help
at all. The conclusion here is that live migration needs to run
for at least 20 minutes, and after that time nova will increase
maximum tolerable downtime by a reasonable amount.
The same applies for live migrations running on 1Gb interface.
In such case it is even more critical to increase maximum
tolerable downtime by a reasonable amount, as the network is
way slower and, therefore, hypervisor will have less chances to
finish live migration at all.
This change slightly affects liveness of instances but it
increases chances of finishing any live migration.
Change-Id: I178aa90ecf9530913b5c82b9726722040445da4b
Some external vendordata services want to provide metadata
based on the role of the user who started the instance. It
would be confusing if the metadata returned changed later
if the role of the user changed, so we cache the boot time
roles and then pass those to the external vendordata
service.
Change-Id: Ieb84c945f4f9a21c2b7b892f9b1ead84dca441e9
Some operators would like instance starts to fail if we cannot
fetch dynamic vendordata. Add an option to do that.
Change-Id: I0c31465c5c52cd4c7e4bb229a4452bc4c8df0e88
We should use a service account to make requests to external
vendordata services. This something which we got wrong in the
newton cycle, and discussed how to resolve at the ocata summit.
It is intended that this fix be backported to newton as well.
There is a sample external vendordata server which has been
tested with this implementat at:
https://github.com/mikalstill/vendordata
Change-Id: I7d29ecc00f99724731d120ff94b4bf3210f3a64e
Co-Authored-By: Stephen Finucane <sfinucan@redhat.com>
For virtuozzo containers we create ephemeral disk based on ploop format.
After we create ploop disk, we should add 'read 'permission for all users.
It's necessary because openstack user query info of this disk by qemu-img.
Change-Id: I2d6dd043340322d4c4ac1efd38f993f08932a483
Implements: blueprint ephemeral-disk-ploop
The check and subsequent hard failure for HostMapping records in
API migration 30 is inconvenient at times during a new setup where
we have flavors in place but no hosts yet. Since we can now check
for and warn about missing HostMapping records in our upgrade
status command, this patch lowers the lack of host mappings check
from a failure to a warning. This migration was really just to make
sure you ran the simple setup command, and the cell mapping check
does that for us.
Change-Id: I8b757fa7c805ec6f4d578ecb6f33d3f1ceff29fc
Document the `nova-manage cell_v2 map_instances` command.
This is part of a series to document the nova-manage cells
commands.
Change-Id: Ie7b8a3b54ca851485393e279d2355f57a097b4d2
Document the `nova-manage cell_v2 map_cell0` command.
This is part of a series to document the nova-manage cells
commands.
Change-Id: I088c959ee5e20e754c2bcfc4a3698db83abc570c
Document the `nova-manage cell_v2 simple_cell_setup` command.
This is part of a series to document the nova-manage cells
commands.
Change-Id: I236d47595b29dbfa18c2c26902301e764d086556
Jenkins