We are also facing this error here on Ubuntu/Xenial and for our customers it is a bugger when 20% of the vms are not migrating, when they rather should. It simply means this will break our autoscaling and autoscheduling and update-process on the plattform, because we can't drain hosts of all the VMs.
We're using Quobyte-Latest(currently 1.3.17) here as shared storage.
As Silvan pointed out the extra step of getting the console and then doing a live-migration is nothing more than a desperate kludge and far from feasable for us as operators as well as for our customers.
We could as well place an inotify in place that monitors any file and changes permissions when needed.
Thats the same level of uggly mess and this should be fixed at the root instead: Whoever creates the file with the wrong permissions shouldn't do that in the first place.
We are also facing this error here on Ubuntu/Xenial and for our customers it is a bugger when 20% of the vms are not migrating, when they rather should. It simply means this will break our autoscaling and autoscheduling and update-process on the plattform, because we can't drain hosts of all the VMs.
We're using Quobyte- Latest( currently 1.3.17) here as shared storage.
nova-api: 13.1.3-0ubuntu1
nova-compute: 13.1.3-0ubuntu1
python-novaclient: 3.3.1-2ubuntu1
libvirt0: 1.3.1-1ubuntu10.8
As Silvan pointed out the extra step of getting the console and then doing a live-migration is nothing more than a desperate kludge and far from feasable for us as operators as well as for our customers.
We could as well place an inotify in place that monitors any file and changes permissions when needed.
Thats the same level of uggly mess and this should be fixed at the root instead: Whoever creates the file with the wrong permissions shouldn't do that in the first place.