We had a similar surprise updating our lab to CentOS 7.3. Even Openstack aside, libvirt itself on 7.3 couldn’t recognize any of our defined VMs - kept giving a message of “ No path to ‘ ‘ “ just trying to do a ‘virsh list’. We ended up adding an additional yum repo definition pointing to the older 7.2 repo and doing a yum history rollback and we’ve stopped pointing to the 7.3 repo altogether. We had other problems with Cent 7.3 as well, unrelated to virtualization. Are others out there successfully using CentOS 7.3 right now with libvirt or is everyone experiencing this similar pain. That’s frightening that the virtio-scsi support is broken as well. Mike Smith Lead Cloud Systems Architect Overstock.com<http://overstock.com> On Dec 20, 2016, at 9:57 AM, Mike Lowe <jomlowe at iu.edu<mailto:jomlowe at iu.edu>> wrote: I got a rather nasty surprise upgrading from CentOS 7.2 to 7.3. As far as I can tell the libvirt 2.0.0 that ships with 7.3 doesn’t behave the same way as the 1.2.17 that ships with 7.2 when using ceph with cephx auth during volume attachment using virtio-scsi. It looks like it fails to add the cephx secret. The telltale signs are "No secret with id 'scsi0-0-0-1-secret0’” in the /var/log/libvirt/qemu instance logs. I’ve filed a bug here https://bugzilla.redhat.com/show_bug.cgi?id=1406442 and there is a libvirt mailing list thread about a fix for libvirt 2.5.0 for what looks like this same problem https://www.redhat.com/archives/libvir-list/2016-October/msg00396.html I’m out of ideas for workarounds having had kind of a disastrous attempt at downgrading to libvirt 1.2.17, so if anybody has any suggestions I’m all ears. _______________________________________________ OpenStack-operators mailing list OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20161221/25b2d4df/attachment.html>