server: allow destroy/recover volumes which are attached to removed vms

[weizhouapache]

Description

This PR fixes #5347

Steps to reproduce the issue on KVM
(1) create a vm, and stop it
(2) stop all cloudstack-agent
(3) expunge the vm. vm is removed, but root volume is in 'Destroy' state.
(4) destroy/expunge the volume, fails.
(5) recover the volume, the volume is restored to ROOT disk and attached the removed vm, therefore we cannot attach to any other vms.

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

• Major
• Minor

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

Screenshots (if appropriate):

How Has This Been Tested?

[nvazquez]

LGTM - did not test it

[weizhouapache]

@blueorangutan package

[blueorangutan]

@weizhouapache a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

[blueorangutan]

Packaging result: ✔️ el7 ✔️ el8 ✔️ debian. SL-JID 999

[weizhouapache]

@blueorangutan test

[blueorangutan]

@weizhouapache a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

[blueorangutan]

Trillian Build Failed (tid-1765)

[nvazquez]

@blueorangutan test

[blueorangutan]

@nvazquez a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

[blueorangutan]

Trillian test result (tid-1769)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 31886 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr5364-t1769-kvm-centos7.zip
Smoke tests completed. 87 look OK, 0 have error(s)
Only failed tests results shown below:

Test	Result	Time (s)	Test File

[davidjumani]

After following the steps and destroying a VM, the Volume is in the destroy state
It then can be recovered to a DATADISK or deleted once the agents are brought up

A suggestion - If a root volume is recovered and converted to datadisk, does it make sense to change the name if it contains ROOT ?

[weizhouapache]

After following the steps and destroying a VM, the Volume is in the destroy state
It then can be recovered to a DATADISK or deleted once the agents are brought up

A suggestion - If a root volume is recovered and converted to datadisk, does it make sense to change the name if it contains ROOT ?

thanks for testing @davidjumani

I agree with changing the volume name which sometimes make users confused. Do you have suggestion on the new volume name ?

[davidjumani]

@weizhouapache Perhaps just 'DISK' or the VM-NAME-DISK if possible

[weizhouapache]

@weizhouapache Perhaps just 'DISK' or the VM-NAME-DISK if possible

if vm has datadisk as well, it will be a bit confused (VM-NAME-DISK vs VM-NAME-DATADISK).

we can discuss in another thread, this is not what this pr need to fix I think.