Public bug reported:
Gate check failed on https://review.openstack.org/#/c/59049/
http://logs.openstack.org/49/59049/1/gate/gate-tempest-dsvm-postgres-
full/a1934fd/
2013-12-08 14:30:09.915 |
2013-12-08 14:30:09.915 |
==
Public bug reported:
By default libguestfs will register an atexit() handler to cleanup any
open libguestfs handles when the process exits. Since libguestfs does
not provide any mutex locking in its APIs, the atexit handlers are not
safe in multi-threaded processes. If they run they are liable to
Public bug reported:
The code within each virt driver's directory nova/virt// is
considered to be private to that virt driver.
The baremetal driver, however, imports and depends on libvirt volume
driver code
$ grep libvirt volume_driver.py
from nova.virt.libvirt import utils as
Public bug reported:
The code within each virt driver's directory nova/virt// is
considered to be private to that virt driver.
The baremetal driver, however, imports and depends on libvirt image
caching code
$ grep imagecache driver.py
from nova.virt.libvirt import imagecache
Public bug reported:
There have been 2 bugs where the bare metal driver is accessing libvirt
private code
https://bugs.launchpad.net/nova/+bug/1261826
https://bugs.launchpad.net/nova/+bug/1261827
This kind of mistake could be prevented using a custom pep8 hacking rule
for Nova.
Arguably the
Public bug reported:
In this thread the topic of deprecating and removing config parameters
related to extension points for non-public APIs was discussed. The
consensus was that such extension points should not be exposed and that
instead people wishing to develop extensions should be doing so on
._get_dev_retry_helper()
File nova/virt/disk/mount/api.py, line 121, in _get_dev_retry_helper
time.sleep(2)
** Affects: nova
Importance: High
Assignee: Daniel Berrange (berrange)
Status: In Progress
** Changed in: nova
Status: New = Confirmed
** Changed in: nova
Public bug reported:
A followup from
https://bugs.launchpad.net/nova/+bug/1362191
This bug is to track the actual deletion of the volume_drivers config
parameter.
** Affects: nova
Importance: Low
Status: Confirmed
** Changed in: nova
Status: New = Confirmed
** Changed
Libvirt 0.9.8 is no longer a supported version for Juno or later. You
must have libvirt = 0.9.11. If you really must stay on such old Ubuntu
releases then enable their cloud archive repository which provides newer
libvirt + QEMU
** Changed in: nova
Status: In Progress = Won't Fix
--
You
Public bug reported:
In a number of cases now users are reporting bugs for features that
don't work in Nova with versions of libvirt that are older than the
minimum supported version. Most recently in Juno libvirt 0.9.11 is
required but user reported bugs about a problem in 0.9.8
Public bug reported:
Setup credentials to allow access to Nova as an administrator account
[root@localhost ] # . keystonerc_admin
[root@localhost ~(keystone_admin)]#
Now create a new flavor but mark it as non-public
[root@localhost ~(keystone_admin)] # nova flavor-create --is-public False
The problem turns out to be on the client side.
In novaclient/v1_1/flavors.py the FlavorManager.list method defaults to
is_public=True, which means that it will only ever resolve flavours
which are marked public, even if the user has permission to access non-
public flavours.
If we change this
Assignee: Daniel Berrange (berrange)
Status: New
--
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/1333219
Title:
Virt driver impls don't match ComputeDriver base
Public bug reported:
http://logs.openstack.org/76/101876/1/gate/gate-tempest-dsvm-
full/1543d84/
https://review.openstack.org/#/c/101876/
2014-06-24 22:40:12.195 | ==
2014-06-24 22:40:12.196 | Failed 1 tests - output below:
2014-06-24 22:40:12.196 |
Public bug reported:
http://logs.openstack.org/76/101876/1/check/check-tempest-dsvm-
full/4d54979/console.html
https://review.openstack.org/#/c/101876/
2014-06-25 08:46:20.228 | ==
2014-06-25 08:46:20.228 | Failed 1 tests - output below:
2014-06-25 08:46:20.228 |
Public bug reported:
http://logs.openstack.org/23/95723/8/gate/gate-nova-
python26/6856934/console.html
https://review.openstack.org/#/c/95723/
2014-06-23 20:02:02.020 | Traceback (most recent call last):
2014-06-23 20:02:02.021 | File nova/tests/api/ec2/test_cloud.py, line 350,
in
Public bug reported:
http://logs.openstack.org/23/95723/8/check/check-tempest-dsvm-postgres-
full/e1494ef/console.html
https://review.openstack.org/#/c/95723/
2014-06-25 11:28:22.947 | ==
2014-06-25 11:28:22.947 | Failed 1 tests - output below:
2014-06-25
Public bug reported:
http://logs.openstack.org/83/101883/3/check/check-tempest-dsvm-postgres-
full/4effbe3/
2014-07-01 16:22:41.275 |
tempest.api.telemetry.test_telemetry_notification_api.TelemetryNotificationAPITestXML.test_check_nova_notification[gate]
2014-07-01 16:22:41.275 |
Proposing a blueprint/nova-specs is only appropriate if the submitter
actually intends to provide a solution. We're not wanting nova-specs for
arbitrary user reported wish-list items.
For user wish list items like this, they should be status:
confirmed/triaged, importance: wishlist
** Changed
Public bug reported:
In the nova/virt/libvirt/driver.py file, the '_live_snapshot' and
'_swap_volume' methods have the following code flow
xml = dom.XMLDesc(0)
dom.undefine()
dom.blockRebase()
dom.defineXML(xml)
The reason for this is that 'blockRebase' requires the guest to be
Public bug reported:
Neither the swap_volume or live_snapshot methods in the libvirt driver
have any corresponding coverage in the test_driver.py unit test suite.
** Affects: nova
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of
Public bug reported:
The XenAPI driver reports a hypervisor type of 'xapi' for supported
instances. This is confusing the hypervisor type, which should be 'xen',
with the management API type which is 'xapi'.
The Baremetal driver reports a hypervisor type of 'baremetal' for
supported instances.
Public bug reported:
When runing the test suite with a random hash seed, eg
PYTHONHASHSEED=666 ./run_tests.sh
many tests will fail as iterators over hash keys/values change their
ordering. For example there are many failures in libvirt like
Ok that log is interesting as it shows that Ubuntu have re-named the
QEMU machine types
... -machine trusty,accel=tcg,usb=off ...
See 'trusty' is the machine type there instead of the more usual pc-
i440fx-1.6
This unfortunately breaks the ability of libvirt to figure out what type
of base
are pinned to the
union of host CPUs that all vCPUs are pinned to.
** Affects: nova
Importance: Medium
Assignee: Daniel Berrange (berrange)
Status: In Progress
** Changed in: nova
Assignee: (unassigned) = Daniel Berrange (berrange)
** Changed in: nova
Importance
Marked this as wontfix, because this is not a problem we can resolve in
Nova codebase. The fix either has to be in upstream Python runtime, or
in a workaround in libguestfs (available in current libguestfs
releases)
** Changed in: nova
Status: Confirmed = Won't Fix
--
You received this
Since I upgraded my deployment from Havana to Icehouse, I can no
longer launch VMs when the hypervisor is KVM. However, with QEMU it
works perfectly.
I can see the qemu-system-x86_64 process taking up 100% CPU. I can't
find any relevant logs to further understand what's happening.
These are
Marking as Invalid since there's been no response from reporter in 6
months and others confirmed it works for them.
** Changed in: nova
Status: Incomplete = Invalid
** Changed in: cinder
Status: Incomplete = Opinion
** Changed in: cinder
Status: Opinion = Invalid
--
You
Public bug reported:
Back in Folsom we added some special timer settings to improve the
reliability of guest time keeping and performance
https://bugs.launchpad.net/nova/+bug/1011848
These were useful for both Windows and Linux guests, but since that
time, KVM has gained support for a number
Indeed, it is not appropriate to post bug reports for code which is not
even merged yet. Put your feedback in gerrit if you have found problems
with the proposed code.
** Changed in: nova
Status: Confirmed = Invalid
--
You received this bug notification because you are a member of
Public bug reported:
While running the nova.tests.unit.compute.test_compute unit test, I
noticed that it throws a lot of exceptions, which don't actually cause
the test suite to report failure. It appears that these are caused by
some periodic background task being executed. Such tasks should be
all callers are forced to pass it, which should reduce
the scale of the problem
** Affects: nova
Importance: Medium
Assignee: Daniel Berrange (berrange)
Status: Confirmed
** Tags: libvirt
** Tags added: libvirt
** Changed in: nova
Assignee: (unassigned) = Daniel Berrange
Public bug reported:
The following change has been getting random failures in the py27 test
job where it would time out after 50 minutes.
https://review.openstack.org/#/c/140725/
eg this test run:
http://logs.openstack.org/25/140725/11/gate/gate-nova-python27/0dabb50/
Strangely other stuff
Upstream code uses
'numa_node': fields.IntegerField(nullable=True),
So this extra_info['numa_node'] must be a RHEL specific fork, so closing this
as invalid.
** Changed in: nova
Status: New = Invalid
--
You received this bug notification because you are a member of Yahoo!
: High
Assignee: Daniel Berrange (berrange)
Status: In Progress
** Changed in: nova
Importance: Undecided = High
** Changed in: nova
Assignee: (unassigned) = Daniel Berrange (berrange)
** Changed in: nova
Status: New = Confirmed
--
You received this bug notification
Public bug reported:
There is a fairly serious bug in VM state handling during live
migration, with a result that if libvirt raises an error *after* the VM
has successfully live migrated to the target host, Nova can end up
thinking the VM is shutoff everywhere, despite it still being active.
The
Public bug reported:
By default, when a KVM guest is setup using huge pages, the pages are
mapped using the MAP_PRIVATE flag to mmap().
The vhostuser VIF backend is designed to allow an external process to
provide the QEMU network driver functionality. For some usecases of
vhostuser, this
Public bug reported:
Back in July 20, there was a 'non_inheritable_image_properties' flag
added which filtered out a couple of image metadata properties when the
XenAPI driver uploaded images to glance.
commit ae7adbb92babf2dfc928daa76474aaba8e325d9c
Author: Rick Harris rconradhar...@gmail.com
Public bug reported:
When an instance is first created, a copy of the metadata from the
image/volume is saved into the instance system metadata. This provides
an accurate point in time record of the metadata used to configure
operate instance, even if the metadata on the image is later changed.
Public bug reported:
Consider a flavour with 4 vcpus, and image property hw:cpu_threads==2.
Now the NUMA topology may prefer a thread count of 4, but best of the
thread preference set, the guest will end up with 2 sockets, 1 core and
2 threads.
Now consider a flavour with 4 vcpus, and image
Public bug reported:
In this thread:
http://lists.openstack.org/pipermail/openstack/2015-August/013614.html
[qote]
Running cmd (subprocess): sudo nova-rootwrap /etc/nova/rootwrap.conf qemu-img
convert -O raw
/var/lib/nova/instances/_base/999f7fff2521e4a7243c9e1d21599fd64a19b42e
Public bug reported:
The nova/virt/libvirt/imagebackend.py file contains code for pre-
allocating image files, so that sufficient space is guaranteed available
for the VM's full disk size. As well as preventing accidental out-of-
space conditions, this is important for maximising performance.
It
Public bug reported:
Since yesterday we see a spike in qemu-img info calls failing:
ged in the
immediate known locations, but this could continue to crop up so we
should change the design such that the block_device_info dict doesn't
contain the password but rather a key to a store that nova can
retrieve the password for use.
Comment from Daniel Berrange in the patch ab
** Changed in: nova
Status: Won't Fix => New
--
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/1331537
Title:
nova service-list shows nova-compute as down and is
> If we boot a VM with one vCPU with m1.tiny flavor, it will be allowed:
>
> nova boot test --flavor 1 --image cirros --nic net-id=$NET_ID
This is invalid test scenario. When using strict CPU pinning, you are
*required* to setup host-aggregates to split your compute hosts into 2
groups. One
This isn't a bug - its a feature request to switch to using a new
library from Nova. I'm fine with that as a suggestion, but it should be
file as a blueprint - probably can be a specless blueprint.
** Changed in: nova
Status: Confirmed => Invalid
--
You received this bug notification
Fixed in Nova by https://review.openstack.org/#/c/354143/
** Changed in: nova
Importance: Undecided => Critical
** Changed in: nova
Status: New => Fix Committed
** Changed in: neutron
Status: New => Invalid
** Changed in: os-vif
Status: New => Invalid
--
You received
*** This bug is a duplicate of bug 1612812 ***
https://bugs.launchpad.net/bugs/1612812
** This bug has been marked a duplicate of bug 1612812
OS-VIF: Interface missing from Route Object. (OVS)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team,
Nova fully fills each node before considering placing a guest on the
next node. This isn't a bug - its expected behaviour intended to
maximise number of guests that can be packed onto each compute host. If
you want to suggest alternative strategies please submit a blueprint +
spec with the
** Changed in: nova
Status: Invalid => Confirmed
--
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/1601994
Title:
instances always packed to NUMA node 0
Status in
This is not a bug - there are two completely independent settings here
- nova.conf hw_disk_discard is applicable to compute node local ephemeral
storage
- cinder 'discard' property is applicable to cinder volume storage
Using hw_disk_discard when configuring cinder volumes is not
Mixing guests with huge pages and non-huge pages on the same host opens
up a huge can of worms, adding complexity to nova, and resulting in a
much unreliable system overall. With our current requirement that guests
using huge pages must run on hosts dedicated to the use of huge pages,
we can setup
by this
libvirt bug - it merely causes mis-leading log messages to be emitted. None the
less we should fix the libvirt reporting so that it is possible to have
resource tracker honour this data in the future.
** Affects: nova
Importance: Undecided
Assignee: Daniel Berrange (berrange
Public bug reported:
The CryptsetupEncryptor impl for volume encryption uses the cryptsetup
'plain' mode for encrypting the volumes.
When opening a volume it treats cipher and key_size as optional
parameters:
cipher = kwargs.get("cipher", None)
if cipher is not None:
Public bug reported:
When making an API call to Cinder to get the volume encryption metadata:
2016-10-25 05:30:47.048 6699 DEBUG cinderclient.v2.client [req-7fe1959f-
36f6-4dd6-bf47-f5e550d59530 3fdb4fc839fc44a9a99006d3fb75ac4d
c6b14fd5fffa48aa8eb869f30c80e409 - - -] REQ: curl -g -i -X GET
Sorry, I didn't mean to suggest we should abandon the change/bug, as not
all distros have crypto policy support systemwide.
Rather, that we should
1. make sure the out of the box behaviour is to honour openssl defaults
2. provide a nova.conf setting for the protocol version, which allows an
Public bug reported:
As the name suggests, the "system-serial-number" field in SMBIOS is
intended for exposing a serial number identifying the hardware, to the
operating system.
The NoCloud data source is mis-using this field for receiving metadata
for initializing cloud-init.
Admittedly there
58 matches
Mail list logo
