daviftorres commented on issue #12171: URL: https://github.com/apache/cloudstack/issues/12171#issuecomment-3755261120
Hey @vladimirpetrov, thanks for looking into this. When we initially deployed the Zones, we were using one storage appliance (I’ll call it “old”). Later, after acquiring larger storage appliances dedicated to CloudStack (I’ll call them “new”), we had to replace them in CS Management. Migrating Primary Storage is straightforward: we add the "new" storage to the zone, live-migrate the instances using “Migrate with storage”, and once nothing is left, CloudStack allows us to remove the "old" storage from the zone via the Web UI. However, this is not what happens with Secondary Storage. Even after removing all assets, CloudStack still blocks its removal, mainly because of System VM templates. For our regular templates, if we set the "old" storage to Read-Only and make sure it’s not in use, we can delete the template reference from the Zone and then copy it back from another Zone. This forces CloudStack to place it on the "new" storage (since there’s no way to choose the target Secondary Storage). What we’ve noticed is that CloudStack seems to prioritize Secondary Storage based on the order in which they were added, always preferring the first one. This makes the first Secondary Storage effectively impossible to remove, forcing us to delete it directly from the database. As you can imagine, this leaves orphaned assets that we later have to locate and clean up manually (see https://github.com/apache/cloudstack/issues/11641#issuecomment-3746236056 for details about the internal tool we built to handle this). So, after that background, here’s the direct answer to your question (as best as I can remember): We discovered that some instances had ISOs attached and were left that way by mistake since deployment. When we later powered them down and tried to start them again, the ISO could not be found. On the UI, the message `Command failed due to Internal Server Error`. In that situation, there was no clear indication that the VM failed to start because the ISO file was missing. We would like either a more descriptive error message, or for CloudStack to automatically detach the missing ISO and continue starting the VM. Another case where auto-detach would make sense is for Compute Offerings with HA enabled, as this would improve the reliability of the HA feature. Please feel free to ask more questions, and I’ll try to respond faster this time. Best regards, -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
