I have resolved this issue. I'll document what I did here in case someone else finds this through Google or something. I basically found this note on this form (I believe) which outlined the steps: The following procedure should provide the solution:
1. set the storage domain to maintenance (via webadmin UI, for example) 2. copy/sync the contents of the storage domain including the metadata, to ensure that data in both locations (the old and the new mount points) is the same. 3. run modification query on ovirt engine database (please replace the values 'yournewmountpoint' and 'therelevantconnectionid' with the correct ones: UPDATE storage_server_connections SET connection='yournewmountpoint' WHERE id='therelevantconnectionid'; 4. There is a bug related to storage domain caching in VDSM (host) , so it needs to be workarounded by restarting vdsm (service name is 'vdsmd') 5. activate storage domain (via webadmin UI, for example). So, since this was the storage domain that had the hosted_storage on it, I had to do more steps for safety: - stop all VMs - shutdown all hosts except for the one running hosted-engine - enter global maintenance - log into the hosted-engine VM - systemctl stop ovirt-engine - use psql as above to edit the connection information for the storage domain I was interested in - reboot the host running the hosted-engine - exit global maintenance - reboot all the other hosts and bring them back into the cluster - restart all VMs It certainly is possible that this global shutdown wasn't totally necessary, but this cluster isn't in production yet and I thought this was the safest course of action. Tod Pike _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/SCSEX62AU3QOE7KS5DHXNM72B4H5MWBS/
