GitHub user Jayd603 closed a discussion: Initial zone set-up does not verify usable secondary storage - leads to issues
Latest cloudstack, I just did a new cloudstack install, set up first zone, I accidentally used the wrong secondary NFS storage path, the set-up process gave no errors. Now, after creating new and correct secondary storage, I cannot migrate and cannot delete the old one. Zone set-up script should test connection and write ability of the secondary storage I'm thinking. Now i'm just looking for best way to fix, might just be easier to destroy the zone and re-create. Oh, and, there are now templates and ISOs in "Not Ready" state with no option to remove them in the UI. I'm trying to fix in the db now. Update: easily removed the Not ready templates in vm_template table, now looking at changing secondary storage path Update 2: I was able to use the UI to remove the old seconary storage after doing, DELETE from template_store_ref WHERE state='Allocated'; DELETE FROM cloud.vm_template WHERE unique_name="<uid/name>"; Testing things now to make sure nothing is broken. Thus far, still cannot register any new ISOs, they stay Not Ready, I tested ability to connect to the NFS share and write from the KVM host and mgmt host 2024-04-26 15:48:07,466 INFO [o.a.c.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-0dc20f4d) (logid:1f8662b9) Unable to start secondary storage VM [333] for standby capacity, it will be recycled and will start a new one. 2024-04-26 15:48:07,466 DEBUG [c.c.a.SecondaryStorageVmAlertAdapter] (secstorage-1:ctx-0dc20f4d) (logid:1f8662b9) received secondary storage vm alert 2024-04-26 15:48:07,476 INFO [o.a.c.s.PremiumSecondaryStorageManagerImpl] (secstorage-1:ctx-0dc20f4d) (logid:1f8662b9) Primary secondary storage is not even started, wait until next turn Hmm, possibly other secondary storage access issues. /usr/bin/mount -o nodev,nosuid,noexec 192.168.22.50:/mnt/SSDStorage1/Cloudstack/template/tmpl/1/3 /mnt/a3313f14-20d0-3952-a7e1-571f5aa1654a) unexpected exit status 32: mount.nfs: Protocol not supported that would be it tried setting secstorage.nfs.version to 3 in cloudstack ui, no luck, going to try to force version on the KVM host - i'm digressing away from the initial bug at this point tho, i'll shutup now GitHub link: https://github.com/apache/cloudstack/discussions/9036 ---- This is an automatically sent email for users@cloudstack.apache.org. To unsubscribe, please send an email to: users-unsubscr...@cloudstack.apache.org
