Repository navigation
restore vm does not attach back data disks #4462
Description
ISSUE TYPE
- Bug Report
COMPONENT NAME
API
CLOUDSTACK VERSION
4.15
CONFIGURATION
OS / ENVIRONMENT
SUMMARY
data disks are left detached
STEPS TO REPRODUCE
Steps: 1. Create a VM with at least 1 volume
2. Destroy the VM without expunging anything
3. Restore the VM
Observe the VM is being restored with it's root disk only, the data disk(s) are being left aside
EXPECTED RESULTS
One should expect if a vm is restored, then it should end up in the same state as when it was deleted
ACTUAL RESULTS
VM has only root disk no data disks attached
Activity
DaanHoogland commentedon Nov 11, 2020
@borisstoyanov any idea if this is a regression or a 'missing feature'?
weizhouapache commentedon Nov 11, 2020
@borisstoyanov
I tested with 4.14 and cannot reproduce the issue.
what env do you use ?
DaanHoogland commentedon Nov 11, 2020
@weizhouapache that would answer my question, @borisstoyanov reported 4.15 (master)
borisstoyanov commentedon Nov 13, 2020
Sounds to me as a bug to the restore functionality. Further if @weizhouapache cannot reproduce in 4.14 maybe it's a regerssion, since I've tested with latest Master.
yadvr commentedon Nov 18, 2020
@harikrishna-patnala @nvazquez any comments?
weizhouapache commentedon Nov 19, 2020
@borisstoyanov might it be caused by #4307 ?
it has huge changes
harikrishna-patnala commentedon Nov 19, 2020
Seems like a regression to me based on the changes made in destroy VM workflow in VMware. I'll verify and come back with a fix.
2 remaining items
andrijapanicsb commentedon Nov 26, 2020
Was this tested to NOT be happening on VMware + 4.14? - so that we can see something is / is not different now in 4.15.
I also do recall that when VM is destroyed that disks are detached - this is an old behaviour for ages.
andrijapanicsb commentedon Nov 26, 2020
I guess I can answer my own questions - in 4.14/vmware disk are NOT detached on VM destroy, but they are on expunge.
From the functional point of view, that is LGTM - you are reverting back to the old behaviour, as in 4.14
From the PR4307 (and that is a complex one....) point of view - can you guarantee that this revert doesn't break anything now (is the gain worth the risk - this is the question)?
harikrishna-patnala commentedon Nov 26, 2020
This will not harm or break anything as we are not reverting the detach operations but moving the detach operations from destroy workflow to expunge workflow. I'll kick off test matrix on the PR.
server: Fix for the issue of recover VM not able to attach the data d…
yadvr commentedon Apr 15, 2021
Fixed #4493
yadvr commentedon Apr 15, 2021
New improvement issue #4902