We neither need nor want these translated so remove them. A couple of
logs with unnecessary brackets or weird indentation were identified in
the process, and these are also modified. Note that exceptions must
still be translated. Refer to [1] for more details.
[1] https://docs.openstack.org/oslo.i18n/latest/user/guidelines.html
Change-Id: I4573a7c5f3a7b5716a15fbd15ad9336807843a03
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
The inject_file call was removed from the compute RPC at 3.18.
As we have RCP 5.x now it is safe to remove the manager method
handing that call. This removes the last user of the inject_file virt
diver method so that is deleted too.
Change-Id: If257fa301e8c12bb0c5e4d396ccc2c7277b25233
Firewall support is not needed with neutron, which supports both
security groups for per-port filtering and FWaaS for per-network
filtering. Remove both the generic firewalls and the hypervisor-specific
implementations.
This change focuses on removing the firewall-related API calls from the
various virt drivers. The firewall drivers themselves are removed
separately.
Change-Id: I5a9e5532c46a5f7064441ae644125d21efe5fda1
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
I suspect there is more to be removed here, but this is all I could spot
for the moment.
Change-Id: Ifb8dc7de5d4845dd639fba71b853d38cdb851c7d
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
When we had cellsv1, we had two different sets of
[Host|InstanceAction|ComputeCells]API. Now that cellsv1 is gone, we only
need nova.compute.api.API, .HostAPI, and .InstanceActionAPI. This patch
removes the dynamic loader shims from nova/compute/__init__.py and swaps
out all references to directly access the classes in nova.compute.api.
Note that there are a couple of ways we could have done this. One way
would have been to replace
from nova import compute
with
from nova.compute import api
and then change
self.compute_api = compute.API()
to
self.compute_api = api.API()
However, the current approach was preferred because
- smaller delta
- the code reads better as compute.API(), which is more important than
the import being pretty
cleanup for blueprint remove-cells-v1
Change-Id: I84d9692efa3a131d6392dbd1011dfc43e4ac0b53
The vif_driver option was deprecated in Ocata:
I599f3449f18d2821403961fb9d52e9a14dd3366b
And can now be removed. The only supported networking
backend is neutron + ovs.
Related to blueprint remove-nova-network
Co-Authored-By: Naichuan Sun <naichuan.sun@citrix.com>
Change-Id: Ia977f115335f00bc36249fa67437b4336d524251
This commit is to deprecate the config of image_upload_handler
which need to be configured with a class path string. And we
should make download handler be configurable to be consistent
with the upload handler.
So it contains the following changes:
1. deprecate the option of "image_upload_handler".
2. added a new option of "image_handler" which will be used to
choose a short name from the supported image handler plugins.
The proper handler will be loaded at runtime basing on the
option setting.
TODO(jianghuaw): For the legacy handler of VdiThroughDevStore
which has no download function implemented. For downloading, it
is handled in a different way (call xenapi.vm_utils._stream_disk()).
We keep it as it is now. In the future, we should consider to
move _stream_disk to VdiThroughDevStore's download().
Change-Id: I37860e63de32d988525cdc32440fe711777263e6
Blueprint: xenapi-image-handler-option-improvement
CI tests frequently teardown by rolling back interface
attachments and then deleting the server, both of which
are asynchronous. If we're trying to detach an interface
on a guest that is gone, we don't need to log a traceback
exception in the logs, just let the InstanceNotFound
raise up to the ComputeManager which will handle the
error and log it appropriately.
Change-Id: I9428be0e6e5b640fdda00410817925001361fd2c
Closes-Bug: #1759979
xenapi is going to support pool-based multi-hosts OpenStack
environments, this patch is used to remove dependency to the
old aggregate-based-pools and add support to xenapi pool.
Also include unit test changes.
Updated configuring migrations document:
https://docs.openstack.org/nova/latest/admin/configuring-
migrations.html#configuring-migrations-xenserver-shared-storage
Other related documents will be updated in another patch.
Implements: blueprint live-migration-in-xapi-pool
Change-Id: I2c492c46e85c1df96aa7fdc12cdee0b1c7ba775e
The previous implementation doesn't support live migration in
pool-based multi-hosts OpenStack environments. Modify code to
support it.
In this patch we will,
1. Support live migration in XAPI pool:
-Add code to support resource pre-check before live migration.
-Add code to support resource clean after live migration.
-Add code to support using local storage in xapi pool.
Depends-On: I80007bb897a1f7eda47ebda82e08fe270f97ff40
Implements: blueprint live-migration-in-xapi-pool
Change-Id: I6437a315f1400a73f7a149bed5550f6d6dd1406f
This commit aims to correct problems with the resize_up codebase that allows
the snapshot and migration of volume backed VDI/VHDs. Since these are empty
stub disks, and the XenAPI does not allow these VDIs to be snapped, this results
in an SR_OPERATION_NOT_ALLOWED or similar error on attempt.
This change adds a check into the _process_ephemeral_chain_recursive method to
run the current userdevice through volume_utils.is_booted_from_volume. To
achieve this, the method has been opened in scope to accept custom user_device
objects. In a future commit we will need to rename this method for clarity
and correct its dependancies that call it. I have added a TODO for this to be
done by myself. The check will ensure that the userdevice is not volume backed
and then continue to snapshot and migrate the disk as needed, else increment
and move on.
Closes-Bug: #1745072
Change-Id: I7cd2977c8268c1f73062b5d0b2b68ea686db99fe
Changes within XenAPI have enforced a more strict policy when checking
assert_can_migrate. In particular when checking the source_vdi:dest_sr
mapping it insists that the SR actually exist. This is not a problem for
local disks, however this assertation is called extremely early in the
live migration process (check_can_migrate_source) which is called from
conductor, which makes a problem for attached volumes.
This early in the process the host has just barely been chosen and no SR
information has been configured yet for these volumes or their initiators.
Additionally we cannot prepare this SR any earlier as BDM information is
not set up until the pre_live_migration method. With the options to either
skip this assertion completely or swallow the exception, I have chosen to
swallow the exception. My reasons for this are two-fold:
1. --block-migration can be called without regard for whether an iSCSI
volume is attached, and we still want to ensure that VIF, CPU and other
factors are checked, and not just skip all checks entirely.
2. Currently the Assert only exists within the --block-migration code
base but this needs to change. A future commit will remove this logic
to ensure that the commit runs without this flag. Once that is done we
want to be able to continue to use this Exception swallow logic rather
than continuing to skip the assert for all XCP2.1.0+ even without volumes.
This decision should help us handle less work in a future commit and does not
seem to align with the goals of that commit, where it does align properly here.
This commit still changes very little of the current codebase and puts us in
a good position to refactor the way this is handled at a later date, while
adding a TODO note to correct VM.assert_can_migrate only running during a
block migration.
Additionally there seems to be some confusion that the mapping data that is
generated during this initial trip through _call_live_migrate_command is needed
to continue along the code, however this data appears to be purely used to send
the mapping information through the assertation call, and is then discarded.
The only data returned from these methods is the original dest_data which
is carried into the live_migration method. The _call_live_migration method is
called again during the live_migration() method, and during this time it does
need that mapping to send along to XenAPI for the actual migration, but not
yet. Because this codebase is so confusing, I am providing a little bit of
context on the movement of these variables with some psuedocode:
---CONDUCTOR.TASKS.LIVE_MIGRATE---
LiveMigrationTask.Execute()
self._find_destination() <-----
Unrelated Work
compute.live_migration(self, host, instance, destination,
block_migrate, migration, migrate_data)
LiveMigrationTask._find_destination()
Scheduler Things. Gets a Dest ref.
_check_compatible_with_source_hyp
_call_livem_checks_on_host(host) <-----
_check_can_live_migrate_destination()
returns Host Node Name and Host Compute. That's all.
---COMPUTE.MANAGER---
_do / _check_live_migration_destination
dest_check_data = xenops.can_live_migrate_destination
(Checks for the Assert)
try:
migrate_data = check_can_live_migrate_source(dest_check_data)
return migrate_data
---VMOPS--
check_can_migrate_source(self, ctxt, instance_ref, dest_check_data)
if block_migration:
_call_live_migration_command(assert_can_migrate)
_generate_vdi_map()
Does NOT return
ALSO Does NOT return
return dest_check_data
The changes made to address this issue are a fairly simple oslo_utils
version check. To pull this data I created two new host related methods
within VMops as well as a new import of oslo_config.versionutils.
I believe these methods ultimately belong in the xenapi.host class, but
for two very small methods I believed it better to avoid such a large import
to get minimal data.
Finally, an adjustment to the Fake XenAPI driver had to be made as it currently
does not include the host details beyond hostname environment in the
create_host check. The change amends the stub dictionary to include this data.
Change-Id: Ie5295564a68f877fc061376c00f3fa706370a251
Closes-Bug: #1704071
This commit parses the allocation to check if VGPU is
allocated. If yes, maps the allocation to GPU group and
vGPU type which can be understood by XenAPI. Then creates
the vGPU for the instance.
Before booting instance with vGPU, it needs to check if the
GPU group has remaining vGPUs available. So also updates the
function of _get_vgpu_stats_in_group() to report remaining
vGPU capacity.
As we can use vGPU feature since this commit, it also includes
a release note.
blueprint: add-support-for-vgpu
Change-Id: Ie24dde0f1fd4b281d598f4040097d82ad251eb06
If live migration fails, the xenapi driver should pass the
migrate_data object to the recover_method (which is actually
ComputeManager._rollback_live_migration) so it can be used if
necessary.
Change-Id: Id123b1eb3f41a33657012ceeb2169f1b4e0e27bf
This change makes _save_device_metadata only query the database
for the instance BlockDeviceMappingList if there are block
device mappings in the block_device_info dict. If there are none,
then there is no point in making the extra useless query to the
database.
A TODO is left in the code since this could be further optimized
if the DriverVolumeBlockDevice object would proxy the 'tag' attribute
from it's underlying BlockDeviceMapping object, but that is a bigger
change saved for another time.
The existing unit test is fixed up and another unit test is added
to validate that we don't query the database if there are no
block device mappings to process.
Change-Id: Ia879b97775125406bd4134f2438d8b988eabc41d
We found VM can live migrate successfully with XenServer hypervisor,
but after migrating to dest host, we cannot ping the VM's floating
or fixed IP any more. The problem is, during live migration, we only
create the network in dest host which the VM's VIF connect to, but we
don't establish the linux bridge and the corresponding veth pair to
integration bridge br-int.
Closes-Bug: 1677937
Change-Id: I0d69d2ba5b064ef303445892791804608e7f19c5
The i18n team has decided not to translate the logs because it
seems like it not very useful; operators prefer to have them in
English so that they can search for those strings on the internet.
Partially fix on nova/virt other paths will be fixed on next commits
Change-Id: Ie7821aa4a5147cdb0616741bd1a1b1fc22080440
This patch is to change nova project to use os-xenapi 0.2.0 which
has added python interfaces for calling dom0 plugins
1. use os_xenapi.client.host_network
2. use os_xenapi.client.disk_management
3. use os_xenapi.client.vm_management
4. use os_xenapi.client.host_xenstore
5. use os_xenapi.client.host_agent
6. use os_xenapi.client.host_management
7. use os_xenapi.client.host_glance
Change-Id: Id87b83ef3ca496525f63b9c7b731e8a22c693e02
When using neutron polling mode, booting a VM will timeout because cannot
receive network-vif-plugged event. After investigation we found we set
vif['id'](i.e. neutron port uuid from neutron's perspective of view) to
two different OVS ports. One is the Xenserver VIF, the other is tap device
qvo-XXXX which neutron ovs agent will monitor and deal with.
This patch is to deprecate the setting of 'nicira-iface-id' to XenServer
VIF (which will result in 'iface-id' in ovsdb) and use 'neutron-port-id'.
Note: There is no problem if we don't use neutron-ovs-agent polling mode
Change-Id: I878602b5a84106634a211735c0002580293e3c06
The newly released XenServer 7.1 has changed to check vif_map in
its api VM.assert_can_migrate(), if the vif_map isn't set, it will
raise exception with VIF_NOT_IN_MAP, but at this point destination
compute node doesn't have dest_vif_map, this patch is to make code
in xenserver driver be compatible with xenserver's changes
Closes-bug: 1669719
Change-Id: I8fb8d26fbbc12dd4f17b3541968fc16254131b6c
Live migration with XenServer as hypervisor failed with xapi
errors "VIF_NOT_IN_MAP". There are two reasons for this
problem:
(1) Before XS7.0, it supports VM live migration without
setting vif_ref and network_ref explicitly if the destination
host has same network, but since XS7.0, it doesn't support
this way, we must give vif_ref and network_ref mapping.
(2) In nova, XenServer has introduced interim network for
fixing ovs updating wrong port in neutron, see bug 1268955
and also interim network can assist support neutron security
group (linux bridge) as we cannot make VIF connected to
linux bridge directly via XAPI
To achieve this, we will add {src_vif_ref: dest_network_ref}
mapping information, in pre_live_migration, we first create
interim network in destination host and store
{neutron_vif_uuid: dest_network_ref} in migrate_data, then in
source host, before live_migration, we will calculate the
{src_vif_ref: dest_network_ref} and set it as parameters to
xapi when calling VM.migrate_send. Also, we will handle the
case where the destination host is running older code that
doesn't have this new src_vif_ref mapping, like live migrating
from an Ocata compute node to a Newton compute node.
Closes-bug: 1658877
Change-Id: If0fb5d764011521916fbbe15224f524a220052f3
During VM rescue tests, we found nova xenserver driver failed due
to waiting vif-plug-event from neutron timeout. when checking
nova and neutron logs, we found there are several mistakes in
nova driver:
(1) After several rounds of rescuing/unrescuing, it will wait for
vif-plug-event, but actually, it shouldn't wait for such event
(2) Checking neutron log, we found the port status sometimes will
change during rescuing/unrescuing, which also shouldn't happen
(3) Checking nova related code, we found each time when booting a
VM, it will delete and create the tap device, which is used by
neutron security group, this delete/re-create action will cause
the port status change which shouldn't be changed.
(4) When adding/deleting security groups to VM's port, it will
trigger the port status change, e.g. from ACTIVE to BUILDING, but
under rescue scenario, we also depends on VIF's status to determine
whether waiting for vif plug event is not appropriate.
This patch is to fix the above problem and there is another patch
to enable the exclude rescue tests to test this fix
https://review.openstack.org/#/c/416197/
Closes-Bug: #1651650
Change-Id: I32c66733330bc9877caea7e2a2290c02b3906708
Nova already has support for hotplugging neutorn ports in the libvirt
driver. This extends the support to the XenAPI driver, implement
attaching/detaching VIFs
I have made a patch to run releated testcase in xenserver CI
https://review.openstack.org/#/c/416797/
Change-Id: I22f3fe52d07100592015007653c7f8c47c25d22c
Implements: blueprint xenapi-vif-hotplug
1.As mentioned in [1], we should avoid using
six.iteritems to achieve iterators. We can
use dict.items instead, as it will return
iterators in PY3 as well. And dict.items/keys
will more readable. 2.In py2, the performance
about list should be negligible, see the link [2].
[1] https://wiki.openstack.org/wiki/Python3
[2] http://lists.openstack.org/pipermail/openstack-dev/2015-June/066391.html
The patch list:
1. cells.
2. compute api.
3. image.
4. network.
5. objects.
6. scheduler.
7. virt.
8. other resources.
Partial-Implements: blueprint replace-iteritems-with-items
Change-Id: Ic6e469eb80ee1774de1374bb36f38b5134b6b311
With XenServer 7.0 (XCP 2.1.0), VM live migration with iSCSI volume
will fail due to no relax_xsm_sr_check in /etc/xapi.conf in Dom0.
But since XS7.0, the default value of relax_xsm_sr_check is true if
not configured in /etc/xapi.conf in Dom0.
This fix is to add checks on XCP version, if it's equal or greater
than 2.1.0, will treat relax_xsm_sr_check=true if not found in
/etc/xapi.conf
Change-Id: I88d1d384ab7587c428e517d184258bb517dfb4ab
Closes-bug: #1610932
All Python files, except executables, should have a '.py' extension.
This wasn't being done for files in the 'plugins/xenserver' folder,
likely because it seems unnatural to call a "plugin" with a file
extension.
Begin working towards a resolution for this by renaming all files to
include a '.py' extension. To avoid forcing operators to upgrade the
Nova service and per-host plugins at the same time, continue to
reference the old, non-'.py' filenames, using symlinks to ensure the
references continue to work. Once Ocata has been released, these
symlinks can be removed, the API version updated and the reference
updated to include the '.py' extension.
Change-Id: Icf4cf2424c15276a6c01778fb92f76bbdc9b2068
Closes-bug: #1302831
Since mitaka checks before live-migration operates migrate_data objects
not dicts. This patch removes check and conversion from
check_can_live_migrate_source.
Change-Id: Ic1959c5e733014f2e9c16c3c5d270142ac8a966d
The driver function pre_live_migration() has only 1 caller:
ComputeManager.pre_live_migration(), which always passes a
LiveMigrateData object to the driver. This is easy to prove as
ComputeManager.pre_live_migration() explicitly checks if migrate_data
is an object, and assigns it the return value of
LiveMigrateData.detect_implementation() if not.
detect_implementation() can only return a subclass of LiveMigrateData.
It will raise an exception if it is passed None.
This change removes handling of the case where migrate_data is None or
otherwise not a LiveMigrateData object from all driver implementations
of pre_live_migration().
Change-Id: I9d46019e06dc2b59f7b2ddf7c57c333809cbc94b
This patch adds support for passing the user context through to
vendordata2 to all the other drivers. libvirt got this in the
original patch, so this is a catch up for the others.
Change-Id: I1e1f0aa1a41626970ae3291caaf8d1d1661f68e6
Blueprint: vendordata-reboot
LOG.warn is deprecated. It is still used in few modules.
Replaced with non-deprecated LOG.warning.
Change-Id: Ia6acc11eca60c652844175a5742f626732e295e3
Closes-Bug: #1508442
This makes the xenapi driver use instance.flavor.root_gb instead
of the legacy instance.root_gb field (and friends).
The actual change here is very small, but a lot of xenapi tests
around this needed to be object-ified.
Change-Id: I6a45a22207a44e57506bc2171b10ba1df76277e0
Stephen Finucane