Public bug reported:
Description
===
Latest devstack fails to start nova-serialproxy.
Steps to reproduce
==
Start devstack with latest master.
Expected result
===
Successfully start devstack.
Actual result
=
Failed to spawn Start devstack
Public bug reported:
Description
===
If the audit hasn’t been triggered and confirm resize is executed, the
resources aren't dropped because the itype stored in the
self.tracked_migrations correspond to new flavor.
But if the audit got executed, it correspond to the old flavor,
Issue is with devstack default config.
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1644891
Title:
Guest shouldn't
Public bug reported:
Description
===
Issuing a migrate (not live migrate) on a guest can get it to be
scheduled on the same host.
Some hypervisor allows resize on the same host, but not libvirt.
Anyhow, by definition, migrate should be scheduled on a different host.
Steps to reproduce
Public bug reported:
Description
===
This bug was found during stress testing cold migration revert for an
instance with an SR-IOV PCI device. Migrate then revert migrate are
executed in a loop for the same guest.
The exact problem was found to be a race condition with the resource
ffects: nova
Importance: Undecided
Assignee: Ludovic Beliveau (ludovic-beliveau)
Status: In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1
Public bug reported:
Description
===
I observed this issue a few times, mainly while doing stress testing of
cold migration.
Neutron returns this error (see stack trace):
Unauthorized: Authentication required
Steps to reproduce
==
1) Boot multiple vms (5-6)
2) Stress
Public bug reported:
Description
===
Suspending a guest with direct-physical ports (PCI passthrough) is
failing and the guest is set in error.
Steps to reproduce
==
1) NETID=`neutron net-list | grep private | awk '{print $2}'`
2) PORTID=`neutron port-create $NETID
Public bug reported:
Description
===
Booting a guest with a PF passthrough device that is specified in the
pci_passthrough_whitelist using it's full PCI address (such as
":05:00.1") is failing to schedule. This used to work in kilo.
It appears that the PCI device is not recognized
*** This bug is a duplicate of bug 1512880 ***
https://bugs.launchpad.net/bugs/1512880
** This bug has been marked a duplicate of bug 1512880
Failed cold migration with SR-IOV
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed
Public bug reported:
This bug also affect nova and is described in details there:
https://bugs.launchpad.net/nova/+bug/1617429
Nova needs to be fixed in order to update the MAC address of the neutron
ports of type direct-physical.
A fix has been proposed for the nova issue. However, sending a
Public bug reported:
Description:
Booting a guest with a neutron port of type 'direct-physical' will cause
nova to allocate a PCI passthrough device for the port. The MAC address
of the PCI passthrough device in the guest is not a virtual MAC address
(fa:16:...) but the MAC address
Public bug reported:
Description:
This method:
def get_pci_device_devspec(pci_dev):
dev_filter = Whitelist(CONF.pci_passthrough_whitelist)
return dev_filter.get_devspec(pci_dev)
is parsing the PCI whitelist eveytime it is called. It's not possible
to change the whitelist
Public bug reported:
But found in latest master.
It has been observed that a failed cold migration for an instance with
PCI devices cause those PCI devices to not be freed (still in used) by
the PciDevTracker.
The audit task (ResourceTracker.update_available_resource) gets the list
of in
Public bug reported:
Nova code doesn't currently support defining multiple pci_alias using an
array.
This is not aligned with packstack. See manifests/api.pp:
# [*pci_alias*]
# (optional) Pci passthrough for controller:
Public bug reported:
Cold migration of an instance that has an SR-IOV interface fails to
migrate because on migrated compute's nova is trying to use the PCI
device/address that has been allocated from the incoming compute.
Obviously this is failing since the PCI device is not present on the
Public bug reported:
Issue has been reproduced in kilo.
There is a limitation when using VFIO with some PCI devices. Some PCI
devices with multiple hardware components are places in the same IOMMU
group (for example a NIC with multiple ports). In this case, the
multiple PCI devices in that
17 matches
Mail list logo
