Ubuntu Cloud Archive

Inconsistency in data stored in libvirt.xml file

  1. Series mitaka
  2. Bug #1607313
Bug #1607313 reported by AJAY KUMAR MAHTO
36
This bug affects 6 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Fix Released
Low
Danil Akhmetov
Ocata
Fix Released
Low
György Szombathelyi
Ubuntu Cloud Archive
Fix Released
Low
Unassigned
Mitaka
Incomplete
Low
Unassigned
Ocata
Fix Released
Medium
Unassigned
nova (Ubuntu)
Fix Released
Low
Unassigned
Xenial
Incomplete
Low
Unassigned

Bug Description

Operations involved :
nova migrate
nova evacuate
nova live-migration

The above mentioned operations on instances lead to creation of a new instance on a new compute host. It has been observed that the 'owner' information in the libvirt.xml file is populated with the username/projectname(tenantname) of the user performing any of the above operations.

For instance,

There's an instance 'ins-1' in project/tenant 'pro-1' owned by user 'user01' launched on compute host 'compute-101'.
Now, an admin user named 'osadmin' from project 'admin', performs operation
`nova live-migration asdfghi123xyz compute-102`
* AD-123 (ID if ins-1)

This leads to a live migration of ins-1 from compute-101 to compute-102.
Now, the file /var/lib/nova/instances/asdfghi123xyz/libvirt.xml in compute-102 will have

<nova:owner>
        <nova:user uuid="osadmin">osadmin</nova:user>
        <nova:project uuid="ff5883e5fa9147a78e6d1b7815">admin</nova:project>
</nova:owner>

which ideally should be,

<nova:owner>
        <nova:user uuid="user01">user01</nova:user>
        <nova:project uuid="aa5883e5fa9147a78e6d1b7815">pro-1</nova:project>
</nova:owner>

This inconsistency is seen in all the operations mentioned, i.e. evacuate, migrate, live-
migration.

Related commands :
nova live-migration SERVER HOST_NAME
nova evacuate EVACUATED_SERVER_NAME HOST_B
nova migrate VM_ID

AJAY KUMAR MAHTO (ajay.mahto)
tags: added: libvirt nova-manage
Revision history for this message
Sean Dague (sdague) wrote :

This information is only advisory right? We never do anything with it again. So I'm not sure it's super important that it's accurate.

Changed in nova:
status: New → Incomplete
importance: Undecided → Low
Revision history for this message
AJAY KUMAR MAHTO (ajay.mahto) wrote :

Yes, it's accuracy is not super important in perspective of openstack operations. But since many monitoring systems may use this file as a source of information to build out effective solutions, we might want to find a resolution. Or atleast, just to keep everything consistent.

Danil Akhmetov (dinobot)
Changed in nova:
assignee: nobody → Danil Akhmetov (dinobot)
Revision history for this message
Danil Akhmetov (dinobot) wrote :

I have reproduced this issue. Let's see what I can suggest.

Changed in nova:
status: Incomplete → Confirmed
Revision history for this message
AJAY KUMAR MAHTO (ajay.mahto) wrote :

The workaround that I used - I made two keystone-api calls for owner name and project/tenant. Please suggest if that's the right way to go, or I can expect a fix in the future releases.

Thanks,

Danil Akhmetov (dinobot)
Changed in nova:
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova (master)

Fix proposed to branch: master
Review: https://review.openstack.org/399679

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to nova (master)

Reviewed: https://review.openstack.org/399679
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=3f2935872da311f79b5fd4d51fb50b4fcf8d2bcd
Submitter: Jenkins
Branch: master

commit 3f2935872da311f79b5fd4d51fb50b4fcf8d2bcd
Author: Danil Akhmetov <email address hidden>
Date: Fri Nov 18 19:27:37 2016 +0300

    Use proper user and tenant in the owner section of libvirt.xml.

    Nova takes instance ownership info from request context when it updates
    libvirt.xml, which is not always correct. A real instance owner should
    be used to avoid inconsistency in the data stored in the XML file.

    Change-Id: Ib1e4803ba4ff17894a0905bcf116225defa5b58a
    Closes-Bug: #1607313

Changed in nova:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/nova 16.0.0.0b1

This issue was fixed in the openstack/nova 16.0.0.0b1 development milestone.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova (stable/ocata)

Fix proposed to branch: stable/ocata
Review: https://review.openstack.org/525997

James Page (james-page)
Changed in nova (Ubuntu):
status: New → Fix Released
Changed in nova (Ubuntu Xenial):
importance: Undecided → Low
Changed in nova (Ubuntu):
importance: Undecided → Low
Changed in nova (Ubuntu Xenial):
status: New → Incomplete
Changed in cloud-archive:
status: New → Fix Released
importance: Undecided → Low
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to nova (stable/ocata)

Reviewed: https://review.openstack.org/525997
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=c4d700dc20de831eaabfddaf5554319fd0d997ab
Submitter: Zuul
Branch: stable/ocata

commit c4d700dc20de831eaabfddaf5554319fd0d997ab
Author: Danil Akhmetov <email address hidden>
Date: Fri Nov 18 19:27:37 2016 +0300

    Use proper user and tenant in the owner section of libvirt.xml.

    Nova takes instance ownership info from request context when it updates
    libvirt.xml, which is not always correct. A real instance owner should
    be used to avoid inconsistency in the data stored in the XML file.

    Change-Id: Ib1e4803ba4ff17894a0905bcf116225defa5b58a
    Closes-Bug: #1607313
    (cherry picked from commit 3f2935872da311f79b5fd4d51fb50b4fcf8d2bcd)

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/nova 15.1.1

This issue was fixed in the openstack/nova 15.1.1 release.

Revision history for this message
Corey Bryant (corey.bryant) wrote :

Marking as Fix Released for Ubuntu Ocata as it has nova 15.1.3.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.