Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Proposed change(s)
I am still not 100% sure about what a good way would be to approach the last step. The restored control plane still holds the manually uploaded VHD, while all other newly created VMs will have no data disk if you want to scale up again. The problem is that while the one VM holds a disk in LUN 0 (which is hard-coded in the disk-mapper), we cannot add a VMSS global disk definition on LUN 0.
To get back to the original state (which honestly might not be super desirable given that these disks disappear), we would somehow:
I haven't played this though (and honestly don't want to), but I think this is what it roughly would look like. This isn't really needed if you just need one control plane, though. But if you have multiple ones, this likely would need to be done in some way without modifying the disk-mapper.