tq libvirt role fails to mark ooo_pool autostart

Bug #1657232 reported by wes hayutin
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
tripleo-quickstart
Fix Released
High
wes hayutin

Bug Description

<weshay> [stack@localhost ~]$ virsh -c qemu:///session pool-autostart oooq_pool
<weshay> error: failed to mark pool oooq_pool as autostarted
<weshay> error: internal error: pool has no config file

<weshay> [stack@localhost ~]$ virsh -c qemu:///session pool-list
<weshay> Name State Autostart
<weshay> -------------------------------------------
<weshay> oooq_pool active no

In these cases if one dumps the xml, defines the pool again and then marks the pool as autostart it will work.

[stack@localhost ~]$ virsh -c qemu:///session pool-dumpxml oooq_pool
<pool type='dir'>
  <name>oooq_pool</name>
  <uuid>6bef89c8-4496-4dc7-9e6a-ce49034a2b4c</uuid>
  <capacity unit='bytes'>429287014400</capacity>
  <allocation unit='bytes'>157383102464</allocation>
  <available unit='bytes'>271903911936</available>
  <source>
  </source>
  <target>
    <path>/home/stack/pool</path>
    <permissions>
      <mode>0755</mode>
      <owner>1011</owner>
      <group>1012</group>
      <label>unconfined_u:object_r:user_home_t:s0</label>
    </permissions>
  </target>
</pool>

[stack@localhost ~]$ virsh -c qemu:///session pool-dumpxml oooq_pool > oooq_pool.xml
[stack@localhost ~]$ virsh -c qemu:///session pool-define oooq_pool.xml
Pool oooq_pool defined from oooq_pool.xml

[stack@localhost ~]$ virsh -c qemu:///session pool-autostart oooq_pool
Pool oooq_pool marked as autostarted

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to tripleo-quickstart (master)

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

Changed in tripleo-quickstart:
assignee: nobody → wes hayutin (weshayutin)
status: New → In Progress
Changed in tripleo-quickstart:
assignee: wes hayutin (weshayutin) → John Trowbridge (trown)
John Trowbridge (trown)
Changed in tripleo-quickstart:
importance: Undecided → High
assignee: John Trowbridge (trown) → wes hayutin (weshayutin)
Revision history for this message
Gabriele Cerami (gcerami) wrote :

This happens when the

{{ ansible_user.HOME }}.config/libvirt/storage

directory has been deleted and the session libvirtd has been killed, but the directory

/run/user/<user_id>/libvirt/storage/run/

is still present, so the informations about the active pool are still present, but the static configuration file has been deleted, and cannot be updated to add autostart configuration.

the workaround proposed works, but if we can't stop wiping completely user home, an "easier" workaround would be to just copy /run/user/<user_id>/libvirt/storage/run/pool.xml to
{{ ansible_user.HOME }}.config/libvirt/storage

given we get the user id some common place, because we already need it for other roles...

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

Reviewed: https://review.openstack.org/421467
Committed: https://git.openstack.org/cgit/openstack/tripleo-quickstart/commit/?id=8ae6f050a523c8e8af0cb4d71165e31140b66985
Submitter: Jenkins
Branch: master

commit 8ae6f050a523c8e8af0cb4d71165e31140b66985
Author: Wes Hayutin <email address hidden>
Date: Tue Jan 17 14:39:20 2017 -0500

    ensure the volume pool can be marked autostart in all cases

    In some cases after rerunning the workflow it is possible to
    get into a state where the oooq pool is running but not
    autostarted. In this case the pool_check will pass and pool
    autostart will fail. This should provide the steps required
    for autostart to work in either case.

    Closes-Bug: #1657232

    Change-Id: Ieba0caa40290c9e03740cef337c6a3f3fa04db30

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

This issue was fixed in the openstack/tripleo-quickstart 2.0.0 release.

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

Other bug subscribers

Remote bug watches

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