** Also affects: nova
Importance: Undecided
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/1380742
Title:
Mulitpath scsi devices are not removed
** Also affects: cinder
Importance: Undecided
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/1401799
Title:
Attach Volume to instance running on
Public bug reported:
multipath device action incorrectly being parsed as the device name.
The first word on the first line of `multipath -l $path` is currently
being used as the name of a given multipath device.
https://github.com/openstack/nova/blob/master/nova/storage/linuxscsi.py#L118
This
@apahim we are actually trying to traverse the other way, starting with
a single path device and working out the virtual mpath dm device
details. We could actually use a glob to do this instead of `multipath
-l /dev/path` :
~~~
# ll /sys/devices/virtual/block/*/slaves/sdk
lrwxrwxrwx. 1 root root
** Also affects: cinder
Importance: Undecided
Status: New
** Also affects: os-brick
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
Public bug reported:
Description
===
Attempts to cleanup a volume backed instance resize leaves behind the instance
directory and additional disk files. This seems to relate to the following
change and the additional imagebackend calls made in _cleanup_resize :
libvirt:
ce from the host to a new host.
Expected result:
The instance is evacuated to a new host.
Actual result:
The instance fails to evacuate as Nova asks Cinder to terminate the connection
of the volume using the connector information from the current host we are
evacuating to and not the original
** No longer affects: nova
--
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/1466444
Title:
multipath device action incorrectly being parsed as the device name
Status in
Public bug reported:
The fix for OSSA 2016-007 / CVE-2016-2140 in f302bf04 assumed that
disk_info is always a plain, decoded list. However prior to Liberty when
preforming a live block migration the compute manager populates
disk_info with an encoded JSON string when calling
Moving to os-brick that now handles the mpath device lookup for Nova.
Previously Nova would call `multipath -ll $path` that would often miss
the actual creation of an mpath device when attaching thus causing the
issues outlined in this bug when detaching. The new path lookup approach
improves this
Public bug reported:
After a prolonged outage of >= 24 hours any cached images stored on
shared instance storage are prone to removal as compute nodes race to
complete a pass of the cache manager once the storage returns.
This pass of the cache manager first registers the current node as an
Closing this out as WONTFIX assuming that only migrateToURI3 will
continue to be used for libvirt versions >= 1.2.17
** Changed in: nova
Status: New => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack
did you use?
(For example: Ceph, LVM, GPFS, ...)
What's the version of that?
LVM/iSCSI
3. Which networking type did you use?
(For example: nova-network, Neutron with OpenVSwitch, ...)
N/A
** Affects: nova
Importance: Undecided
Assignee: Lee Yarwood (lyarwood
Moving to invalid as this should no longer reproduce against Liberty or
Mitaka after the move os-brick. Please reopen and reassign to os-brick
if this issue persists.
** Changed in: nova
Status: Incomplete => Invalid
** Changed in: nova
Assignee: Jorge Niedbalski (niedbalski) =>
Moving to invalid given that a valid reproducer has not been provided
for some time now. Please feel free to reopen if one is found against a
supported release in the future.
** Changed in: nova
Status: Incomplete => Invalid
--
You received this bug notification because you are a member
Closing this out as invalid, as highlighted already in the bug we only
use the UUID and escaped disk name when creating LVs locally.
** Changed in: nova
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
Moving to invalid as this should no longer reproduce against Liberty or
Mitaka after the move os-brick. Please reopen and reassign to os-brick
if this issue persists.
** Changed in: nova
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of
** Changed in: nova
Status: Expired => Confirmed
** Changed in: nova
Importance: Undecided => Medium
--
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/1415778
** Changed in: nova
Status: Expired => Confirmed
** Changed in: nova
Assignee: (unassigned) => Lee Yarwood (lyarwood)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
Public bug reported:
Description
===
I931421ea688641e2ceb212c6dc099639c53433f2 introduced a callback to
_create_configdrive from _create_domain that recreates the config disk
of an instance during a rescue.
However neither the original or this recreated config disk are used by
the
Public bug reported:
Description
===
Iab5afdf1b5b8d107ea0e5895c24d50712e7dc7b1 [1] ensured that
_cleanup_failed_start is always called if we encounter VIF plugging failures in
_create_domain_and_network. However this currently leads to any local instance
files being removed as cleanup
Public bug reported:
Description
===
The second and any future attempts to swap volumes using volume-update fail due
to a BDM lookup failure using the original volume id (see Logs & Configs for an
example).
A previous attempt to fix this was made in bug#1490236 and reverted by
Why was this bug created against Nova? AFAICT this behaviour appears
correct assuming the two volume types have differing encryption or QoS
properties :
https://github.com/openstack/cinder/blob/362062935b87d97a2ce94a648c6dea67f9afe37e/cinder/volume/api.py#L176
> I'm not sure if this bug should be recorded with Nova or Ubuntu..
Thanks for the report, IMHO this needs to be addressed by Ubuntu or who
ever is providing libvirt packages as these apparmor profiles are not
shipped within the nova project.
** Changed in: nova
Status: New => Invalid
--
** No longer affects: os-brick
--
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/1640506
Title:
Switch to os-brick encryptor provider implementations
Status in OpenStack
Public bug reported:
Description
===
The following trace was seen multiple times during a CI run for
https://review.openstack.org/#/c/383859/ :
Public bug reported:
Description
===
The following was noticed during a CI run for
https://review.openstack.org/#/c/383859/ :
http://logs.openstack.org/09/395709/7/check/gate-tempest-dsvm-full-
devstack-plugin-nfs-
nv/a4c1057/logs/screen-n-cpu.txt.gz?level=ERROR#_2017-02-07_19_17_41_994
*** This bug is a duplicate of bug 1648840 ***
https://bugs.launchpad.net/bugs/1648840
Marking this as a duplicate of bug 1648840.
** This bug has been marked a duplicate of bug 1648840
libvirt driver leaves interface residue after failed start
--
You received this bug notification
*** This bug is a duplicate of bug 1643017 ***
https://bugs.launchpad.net/bugs/1643017
** This bug has been marked a duplicate of bug 1643017
libvirtError: block copy still active: disk 'vdb' not ready for pivot yet
--
You received this bug notification because you are a member of Yahoo!
** Changed in: os-brick
Status: In Progress => Fix Released
--
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/1633518
Title:
The passphrase used to encrypt or
Public bug reported:
Description
===
The following findmnt behaviour change present in util-linux-2.23.2-33 causes
libvirt_utils.is_mounted to incorrectly return True when a share is already
mounted on a host but not by Nova, for example in an allinone/devstack
environment where
sing these implementations at
present.
2. Which storage type did you use?
N/A
3. Which networking type did you use?
N/A
Logs & Configs
==
N/A
** Affects: nova
Importance: Undecided
Assignee: Lee Yarwood (lyarwood)
Status: New
** Changed in: nova
Documenting the additional fixes that have landed in os-brick since the
original copy. Note that the original copy itself refactored a few
things so re-syncing is going to be FUN!
# cd os-brick
# git rev-parse HEAD
fb0b7e3e3ef32d46a5c4dbc2604d008b80864d8a
# git log os_brick/encryptors/
commit
Public bug reported:
Description
===
tl;dr hex(x) previously stripped leading 0's from individual hex numbers
while encoding the passphrase back to a hex string before use to
encrypt/decrypt a luks volume.
Prior to Newton the following method was used to encode passphrases when
This also impacts os-brick that has recently copied the encryptor
codebase with change :
Copy encryptors from Nova to os-brick
https://review.openstack.org/#/c/247372/
We should really try to remove the Nova encryptors this cycle I
guess
** Also affects: os-brick
Importance: Undecided
Thanks for the report, however direct manipulation of the DB like this
isn't something nova supports. Use the `nova evacuate` command to move
the instance from the down tripoli node instead of hacking around in the
DB.
** Changed in: nova
Status: New => Invalid
--
You received this bug
Public bug reported:
Description
===
gate-grenade-dsvm-ubuntu-xenial failing on stable/newton due to devstack not
supporting xenial during Mitaka.
Steps to reproduce
==
Attempt to run gate-grenade-dsvm-ubuntu-xenial against stable/newton.
Expected result
===
Public bug reported:
Description
===
Detaching encryptors from volumes that are still attached to domains can result
in failure.
Steps to reproduce
==
- Attach an encrypted volume to an instance.
- Mount and use the volume within the instance.
- Attempt to detach the
Public bug reported:
This is an additional corner case for swap_volume not covered by
bug#1630600.
The following failure is taken from the devstack change enabling the new
swap_volume tempest test :
tempest: configure compute-feature-enabled.swap_volume if libvirt
Public bug reported:
Description
===
I385c36e0af1a8a785c02e21ba4efa6046cde6366 introduced a new requirement of
WebOb>=1.6.1 that has not been reflected in requirements.txt either globally or
within Nova.
Steps to reproduce
==
# tox -e py27
** Changed in: nova
Status: In Progress => Fix Released
** Changed in: nova
Status: Fix Released => Fix Committed
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
** Changed in: nova/mitaka
Status: In Progress => Won't Fix
** Changed in: nova/newton
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
This doesn't appear to be a nova issue, the keystone error in c#2
suggesting an issue with memcached in your environment that in turn is
bubbling back up to Glance and finally Nova.
Liberty is also an unsupported release at present so I'm marking this as
invalid for now but feel free to change
Public bug reported:
Description
===
I'm not entirely convinced that this is a bug but wanted to document and
discuss this upstream.
When using the rbd imagebackend, snapshots used to shelve an instance
cannot be removed after unshelving as they are cloned and as a result
are now the
Unfortunately this isn't a valid or supported method for deploying nova-
compute.
That said are you sure virt_type is qemu and not kvm?
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
*** This bug is a duplicate of bug 1587802 ***
https://bugs.launchpad.net/bugs/1587802
My apologies, I assumed we were talking about resizing up and I had to
re-read your description to see that this was actually about resizing
down. The following review moved _is_booted_from_volume to use
rtError:
internal error: unable to execute QEMU command 'drive-mirror': Could not open
'/dev/disk/by-id/dm-uuid-mpath-360014053aac4f90daef4d76baa773169': Permission
denied
2017-04-12 09:37:53.744 3077 ERROR oslo_messaging.rpc.dispatcher
** Affects: nova
Importance: Undecided
Assignee: Lee Yarwo
tion
https://bugzilla.redhat.com/show_bug.cgi?id=1424481
** Affects: nova
Importance: Undecided
Assignee: Lee Yarwood (lyarwood)
Status: In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Com
Public bug reported:
Description
===
Swapping encrypted volumes via `nova volume-update` currently results in the
new volume being attached to the instance still encrypted and the original
volume still connected to the host.
Steps to reproduce
==
# cinder type-create
I'd also suggest providing `multipath -ll` output from the compute node
after an attempted delete.
In any case this will likely end up being an os-brick issue so I'm
looping them in now.
** Also affects: os-brick
Importance: Undecided
Status: New
--
You received this bug
*** This bug is a duplicate of bug 1686116 ***
https://bugs.launchpad.net/bugs/1686116
I've marked this as a duplicate of bug #1686116, if this is still
required for Newton then please request a stable backport there.
** This bug has been marked a duplicate of bug 1686116
domain xml not
Appears you are just missing the tgtadm utility on the node running
cinder-volume :
Apr 22 14:31:42 storage cinder-volume: 2017-04-22 14:31:42.284 50710
ERROR oslo_messaging.rpc.server Stderr: u'/usr/bin/cinder-rootwrap:
Executable not found: tgtadm (filter match = tgtadm)\n'
** Changed in: nova
Public bug reported:
Description
===
$ cat /etc/redhat-release
Fedora release 25 (Twenty Five)
$ /usr/bin/nova-manage --config-file /etc/nova/nova.conf api_db sync
Exception AttributeError: "'_SocketDuckForFd' object has no attribute
'_closed'" in
ignored
Exception AttributeError:
** Also affects: os-brick
Importance: Undecided
Status: New
** Changed in: os-brick
Assignee: (unassigned) => Lee Yarwood (lyarwood)
** No longer affects: nova
** Also affects: tempest
Importance: Undecided
Status: New
** Changed in: tempest
Assignee: (unassig
> 1. [version] My environment is actually Kilo
> (openstack-nova-compute-2015.1.1-1.el7.noarch),
> but I belive the implementation is not much
Actually it has, os-brick now handles disconnect_volume calls for
multipath iSCSI volumes. The code within os-brick is also being heavily
refactored at
Public bug reported:
Description
===
When using resume_guests_state_on_host_boot encrypted volumes are
directly attached to instances after a host reboot. These volumes should
be decrypted by the os-brick encryptors that provide libvirt with
decrypted dm devices for use by the
9b-432e-b0b7-859dfe4c1cb3]
ImageBadRequest: Request of image 75d1a99d-a19e-42fe-a766-6311fc57f583 got
BadRequest response: 400 Bad Request: Signature verification failed for image
75d1a99d-a19e-42fe-a766-6311fc57f583: Signature verification failed (HTTP 400)
Dec 07 09:02:21 signature-test.rdoclo
Thanks to Tzach I was able to get access to an env downstream and
confirm whats going on here.
c-vol appears to be creating a fresh secret for the new volume that
isn't capable of unlocking the volume. IMHO c-vol should just copy the
associated secret UUID during the creation process from an
Public bug reported:
Description
===
During a P to Q upgrade n-cpu processes still running P will be unable to find
the volumev2 endpoint when running alongside Q n-api processes due to the
following change:
Update cinder in RequestContext service catalog
The config-ref makes it clear that this needs to be configured on the
individual compute hosts:
https://docs.openstack.org/nova/pike/configuration/config.html#libvirt
https://docs.openstack.org/nova/pike/configuration/config.html#libvirt.volume_use_multipath
Further as this is devstack you
Public bug reported:
All references should be to pike documentation.
** Affects: nova
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
to rebase the
into the encrypted disk.
** Affects: nova
Importance: Undecided
Assignee: Lee Yarwood (lyarwood)
Status: In Progress
** Summary changed:
- swap volume not blocked between an decrypted and encrypted volume while using
QEMU to natively decrypt
+ swap volume not blocked between an un
Public bug reported:
Description
===
When attempting to attach an encrypted volume the following trace is logged [1]:
File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py",
line 1463, in attach_volume
guest.attach_device(conf, persistent=True, live=live)
File
Public bug reported:
Description
===
This is caused by the cleanup code within the compute layer
(_shutdown_instance) removing all volume attachments associated with an
instance with no attempt being made to recreate these ahead of the instance
being rescheduled.
Steps to reproduce
rking type did you use?
(For example: nova-network, Neutron with OpenVSwitch, ...)
N/A
Logs & Configs
==
** Affects: nova
Importance: Undecided
Assignee: Lee Yarwood (lyarwood)
Status: In Progress
--
You received this bug notification because you are a m
Public bug reported:
Description
===
When creating more than a single instance in the same request the filter
scheduler will skip any host that has already been selected when
attempting to find alternates. The lack of alternates will lead to
instances not being rescheduled and entering
*** This bug is a duplicate of bug 1669857 ***
https://bugs.launchpad.net/bugs/1669857
** This bug has been marked a duplicate of bug 1669857
libvirt.VIR_DOMAIN_AFFECT_CONFIG provided when detaching volumes during LM
rollback
--
You received this bug notification because you are a
Public bug reported:
https://docs.openstack.org/nova/latest/configuration/config.html#pci
For example, an alias example line renders as:
alias = { “name”: “QuickAssist”, “product_id”: “0443”, “vendor_id”:
“8086”, “device_type”: “type-PCI”, “numa_policy”: “required” }
Instead of the valid:
cts: cinder
Importance: Undecided
Status: New
** Affects: nova
Importance: Undecided
Assignee: Lee Yarwood (lyarwood)
Status: New
** Tags: cinder volumes
** Description changed:
Description
===
- Discovered this by chase earlier today, at first glance t
Public bug reported:
Description
===
When using preallocated file based disks (preallocate_images = space) with the
Libvirt virt driver the reported allocation for each disk appears doubled,
leaving disk_available_least under reporting the amount of available resources
on a compute
Public bug reported:
Description
===
If the migration is in a 'pre-migrating' state this can result in the
source compute manager not removing the evacuating instances in question
during _destroy_evacuated_instances.
More importantly the source host returning online early allows
?
(For example: nova-network, Neutron with OpenVSwitch, ...)
N/A
** Affects: nova
Importance: Undecided
Assignee: Lee Yarwood (lyarwood)
Status: In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed
Public bug reported:
Description
===
Instance stuck in resize_prep when migrating from down compute, moves to ERROR
when compute returns later.
Steps to reproduce
==
- Launch an instance:
- Stop compute service on the host:
$ sudo systemctl stop devstack@n-cpu
$
I've attached a simple script to reproduce this behaviour outside of
placement.
I'm struggling to find where but AFAICT the oslo.config code parsing the
command line args is failing and defaulting to the default help func for
the top level command parser.
# cat /etc/redhat-release
Fedora
** No longer affects: oslo.config
--
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/1804420
Title:
placement unit test
Okay thanks so that is definitely a Kolla bug, it needs to persist
/etc/libvirt/secrets/ somewhere and ensure it's injected back into the
container on restart.
FWIW TripleO maps /etc/libvirt directly from the host into the container
to work around this:
https://github.com/openstack/tripleo-heat-
Public bug reported:
Description
===
I've been working on introducing basic upgrade check calls in TripleO
but have encountered the following issue now template based db
connection strings are being used by TripleO in support of cellsv2:
$ nova-status upgrade check
[..]
ArgumentError:
Public bug reported:
Description
===
Idc5cecffa9129d600c36e332c97f01f1e5ff1f9f introduced a simple check to
ensure disconnect_volume is only called when detaching a multi-attach
volume from the final instance using it on a given host.
That change however doesn't take LM into account and
Public bug reported:
tempest.api.compute.servers.test_servers.ServerShowV263Test aims to test
the optional trusted_image_certificates parameter introduced into n-api
in microversion 2.63:
Add trusted_image_certificates to REST API
https://review.opendev.org/#/c/486204/
Add new schema for Nova
** No longer affects: nova
--
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/1831866
Title:
tempest.api.compute.servers.test_servers.ServerShowV263Test only
passing when
/var/log/cinder/api.log:2019-06-19 15:23:02.316 10647 ERROR
cinder.api.middleware.fault [req-a350dc82-f052-48b5-a834-dcf550fd5089
be29df3f4eae49c789232c0921d3fe90 04d0321b6b9f4f17bf093f0c1c919a30 -
default default] Caught error: Timed out waiting for a
reply to message ID
Public bug reported:
Description
===
tempest.api.volume.test_volumes_extend.VolumesExtendAttachedTest.test_extend_attached_volume
is failing when using the Q35 machine type as configured as part of the
following DNM test change:
DNM: Run tempest-full-py3 with q35 machine type
** Changed in: nova
Status: Confirmed => Fix Released
--
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/1678694
Title:
Can't attach volume to volume-backed instance
Try increasing ``[libvirt]/num_pcie_ports``?
FWIW this isn't a valid upstream bug as you have backported a change
that is unmerged in master and another that is unmerged in stable/rocky.
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a
** Also affects: os-brick
Importance: Undecided
Status: New
** No longer affects: os-brick
** Project changed: nova => os-brick
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
** Changed in: nova
Status: In Progress => Fix Released
--
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/1522233
Title:
Failed to migrate encrypted volume
Status
Released in 17.0.10.
** Changed in: nova/queens
Status: In Progress => Fix Released
--
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/1809454
Title:
[SRU] nova rbd
Public bug reported:
Description
===
In addition to bug #1825882 where libvirtError exceptions are not raised
correctly when attaching volumes to domains the underlying volumes are
not disconnected from the host.
Steps to reproduce
==
- virsh detach-disk vdb
- update
Public bug reported:
Description
===
At present any exceptions encountered during post_live_migration on the source
after an instance has successfully migrated result in the overall failure of
the migration and the instance being listed as running on the source while
actually being on
nova
Importance: Undecided
Assignee: Lee Yarwood (lyarwood)
Status: In Progress
** Tags: compute volumes
** Tags added: compute
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
h
Public bug reported:
Description
===
Simultaneous requests to reboot and delete an instance _will_ race as only the
call to delete takes a lock against the instance.uuid.
One possible outcome of this seen in the wild with the Libvirt driver is
that the request to soft reboot will
** Changed in: nova
Status: Confirmed => 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/1651898
Title:
Key manager configuration for ephemeral storage
https://review.opendev.org/#/c/400384/ landed back in Queens.
** Changed in: nova
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
Public bug reported:
Description
===
Nova is currently unable to create and then boot from volumes from encrypted
volume snapshots when the original volume_type is not provided as part of the
block_device_mapping request to n-api. Failure to provide this will result in
the following
89cdeb13f58de1c5f/log
/job-output.txt#4056
** Affects: nova
Importance: Undecided
Assignee: Lee Yarwood (lyarwood)
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
So this is a Glance bug at this point, Nova has no concept of
cinder_encryption_key_id and that's why the instance booted at step 2
isn't able to load an OS from the encrypted image.
Moving the bug to Glance so they can decide how to handle delete
requests where the same cinder_encryption_key_id
ating this field and depending on
the outcome of the thread upstream in Libvirt also potentially handle
the upgrade case where we may need to rebase existing disks in order to
update the metadata.
[1]
https://github.com/libvirt/libvirt/commit/3615e8b39badf2a526996a69dc91a92b04cf262e
[2] https://ww
*** This bug is a duplicate of bug 1856925 ***
https://bugs.launchpad.net/bugs/1856925
** This bug has been marked a duplicate of bug 1856925
Nova compute service exception that performs cold migration virtual machine
stuck in resize state.
--
You received this bug notification because
** Changed in: nova
Status: Confirmed => 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/1554093
Title:
Cached images incorrectly removed after instance
** Changed in: nova
Status: In Progress => 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/1787606
Title:
Multi instance creation rescheduling fails due
1 - 100 of 284 matches
Mail list logo
