Failed live migration and duplicate attachments
Matt Riedemann
mriedemos at gmail.com
Wed Dec 19 19:46:44 UTC 2018
On 12/19/2018 9:09 AM, Torin Woltjer wrote:
> After doing live migrations for some instances, and those migrations
> failing, the attached volumes show duplicates of the same attachment.
> This is the error message I get when the migration fails:
> https://pastebin.com/raw/3mxSVnRR
>
> openstack volume list shows the volume is attached to the instance twice.
> | a424fd41-a72f-4099-9c1a-47114d43c1dc | zktech-wpdb1 |
> in-use | 50 | Attached to ead8ecc3-f473-4672-a67b-c44534c6042d on
> /dev/vda Attached to ead8ecc3-f473-4672-a67b-c44534c6042d on /dev/vda
>
> How do I remove the duplicate attachment, and why could the live
> migration be failing in the first place? Not all migrations fail, but
> sometimes they do and I have multiple volumes with duplicate attachments.
>
> /*Torin Woltjer*/
> *Grand Dial Communications - A ZK Tech Inc. Company*
> *616.776.1066 ext. 2006*
> /*<http://www.granddial.com>www.granddial.com <http://www.granddial.com>*/
From the log, it looks like the live migration is timing out and
aborting itself:
2018-12-17 13:47:12.449 16987 INFO nova.virt.libvirt.driver
[req-7bc758de-b2e4-461b-a971-f79be6cd4703
313d1247d7b845da9c731eec53e50a26 2f693c782fa748c2baece8db95b4ba5b -
default default] [instance: ead8ecc3-f473-4672-a67b-c44534c6042d]
Migration running for 2280 secs, memory 3% remaining; (bytes
processed=2541888418, remaining=126791680, total=3226542080)
2018-12-17 13:47:29.591 16987 WARNING nova.virt.libvirt.migration
[req-7bc758de-b2e4-461b-a971-f79be6cd4703
313d1247d7b845da9c731eec53e50a26 2f693c782fa748c2baece8db95b4ba5b -
default default] [instance: ead8ecc3-f473-4672-a67b-c44534c6042d] Live
migration not completed after 2400 sec
2018-12-17 13:47:30.097 16987 WARNING nova.virt.libvirt.driver
[req-7bc758de-b2e4-461b-a971-f79be6cd4703
313d1247d7b845da9c731eec53e50a26 2f693c782fa748c2baece8db95b4ba5b -
default default] [instance: ead8ecc3-f473-4672-a67b-c44534c6042d]
Migration operation was cancelled
2018-12-17 13:47:30.299 16987 ERROR nova.virt.libvirt.driver
[req-7bc758de-b2e4-461b-a971-f79be6cd4703
313d1247d7b845da9c731eec53e50a26 2f693c782fa748c2baece8db95b4ba5b -
default default] [instance: ead8ecc3-f473-4672-a67b-c44534c6042d] Live
Migration failure: operation aborted: migration job: canceled by client:
libvirtError: operation aborted: migration job: canceled by client
After that, the _rollback_live_migration method is called which is
trying to cleanup volume attachments created against the destination
host (during pre_live_migration). The attachment cleanup is failing
because it looks like the user token has expired:
2018-12-17 13:47:30.685 16987 INFO nova.compute.manager
[req-7bc758de-b2e4-461b-a971-f79be6cd4703
313d1247d7b845da9c731eec53e50a26 2f693c782fa748c2baece8db95b4ba5b -
default default] [instance: ead8ecc3-f473-4672-a67b-c44534c6042d]
Swapping old allocation on 3e32d595-bd1f-4136-a7f4-c6703d2fbe18 held by
migration 17bec61d-544d-47e0-a1c1-37f9d7385286 for instance
2018-12-17 13:47:32.450 16987 ERROR nova.volume.cinder
[req-7bc758de-b2e4-461b-a971-f79be6cd4703
313d1247d7b845da9c731eec53e50a26 2f693c782fa748c2baece8db95b4ba5b -
default default] Delete attachment failed for attachment
58997d5b-24f0-4073-819e-97916fb1ee19. Error: The request you have made
requires authentication. (HTTP 401) Code: 401: Unauthorized: The request
you have made requires authentication. (HTTP 401)
2018-12-17 13:47:32.497 16987 WARNING nova.virt.libvirt.driver
[req-7bc758de-b2e4-461b-a971-f79be6cd4703
313d1247d7b845da9c731eec53e50a26 2f693c782fa748c2baece8db95b4ba5b -
default default] [instance: ead8ecc3-f473-4672-a67b-c44534c6042d] Error
monitoring migration: The request you have made requires authentication.
(HTTP 401): Unauthorized: The request you have made requires
authentication. (HTTP 401)
Given that, you'd probably be interested in configuring nova to use
service user tokens:
https://docs.openstack.org/nova/latest/configuration/config.html#service-user
With that feature, you configure nova with service user credentials so
in the case that the user token times out, keystone automatically
re-authenticates using the service user credentials. More details can be
found in the spec:
https://specs.openstack.org/openstack/nova-specs/specs/ocata/implemented/use-service-tokens.html
--
Thanks,
Matt
More information about the openstack-discuss
mailing list