I would not imagine that a VM could deprovision itself fully (but that would be a nice feature), but must start a helper VM to do that. I am seeking an example of such for a Linux VM. I would actually like an example where a VM could be completely cleaned up after, deprovision, delete, delete disks (boot included), no trace left, no storage consumed, nada.
If you are running from Linux you can use the Azure CLI which provides the functionality you need.
If you run a force delete on a VM with the option to delete the underlying disk, the command will be registered with Azure before the operation starts, therefore it is perfectly possible to completely delete a running VM from within that VM.
Since you're deleting the entire stack, there's no need to gracefully shutdown beforehand (which would be more challenging - though not impossible) You can just hit the delete button and let Azure figure the rest out.
Related
The Azure portal web interface has several options for creating 'images' of a VM including:
snapshot creates a snapshot of the machine which can presumably be restored or copied (what I am trying to do without much success so far)
capture generalises a VM into an image that can be used to create multiple VMs (in theory)
The capture option makes the original VM unusable. In fact you are prompted about whether you want to keep it as it will no longer run (which indeed it can't).
Why is capture a destructive operation?
When you generalise an image using sysprep it will remove the customisation from your VM and that particular VM be of no use except as a golden image. This golden image then can be used as a template to spin more VM’s by passing on the missing parameters which sysprep removed.
If you like to keep the VM, you are using for capture it is recommended that you make a copy of it first and then use it for capture and sysprep process
Refer below for details
https://learn.microsoft.com/en-us/azure/virtual-machines/windows/capture-image-resource
Snapshot is more of a VM state at a given point in time and. Mostly used for migration to another region or to capture a state of an application running the VM before an application upgrade or patch.
I use azure vm, when vm is restart then failed to start vm error and stay on Updating mode, so I don't use azure recovery services.
Probably more of a server fault question.
Couple of things you can try:
Completely stop the VM to stopped(deallocated) status, then boot it backup, if you have problem stop it from portal, use powershell cmdlet
Re-size the VM, normally would move it to another host and can jump off the problematic host
Delete the VM retain disks, create another VM from the disk.
There is also a good chance all above would fail. If you have a RTO, you might want to start preparing failover/recreate the machine in parallel.
If someone is still experiencing the stuck in the UPDATING status, it's probably your VM's Disk ran out of space, what I did is I increased the size and it boot fine.
I am working on an azure deployment. I am using some templates from github that creates a certain number of VM's based on a 'master image', puts them behind a load balancer, and allows access to them through RDP and ports.
Now, all this is working great. I build my image, then I run sysprep and generalize it, shut it down, and spin up 40 copies.
The issue I am running into is what do I do if I want to update the 'master image'?
It won't let me boot it up, because it says it is generalized. And I am having a hard time setting up a new vm and attaching the OS disk "not sure if this is the right way"
Does anyone have any suggestions? I am coming from a VMware VDI environment, where I would just boot up the master, make changes, shut down, and snapshot and redeploy.
Also I am using the new Azure interface, which I believe is called AzureRM.
Error message: Operation Start VM is not allowed on VM xxx since the VM is generalized.
Like versioning, you have to create a new VM from the image made before, and then repeat the process again after your changes.
Well, its not pretty, but it should work:
Spin up a fresh copy. make your changes, then preform the sysprep / oobe process again, finally, generalize & capture.
I have an Ubuntu 14 VM on Azure to host my developed web sites. (I do not think the OS matters in the point of view the question, but never know)
I've discovered the relatively new Capture button, so for the storage price of a disk size I regularly save a "snapshot" via the Capture function (I am not preparing the image for provisioning, I mean not checking the "I have run 'waagent -deprovision' on the virtual machine" checkbox). Be aware quickly becomes pretty addictive.
The result is an image what I can use when creating new machines, its there in My Images in the wizard. This can function as a backup/rollback worflow. If I delete the VM and create a new from one of resulting image of the previously captured "snapshots". (again, no provisioning will take place)
It is possible to initiate the Capture operation on a running VM. It is not clear for me, if the result will be an image what is a template for a new VM, and that VM will start up and boot, in what state the filesystem etc will be?
Is not it a similar state than sudden power lost? If yes, then it is strongly recommended to always shutdown the VM before capturing, however this such a pain and productivity killer, so no one (including me) wants to do unless it is mandatory.
Accidentally I've switched to the new Azure portal and there the Capture UI says:
Capturing a virtual machine while it's running isn't recommended.
When a Windows Azure worker role instance is rebooted from within the Azure portal, are the contents of the e:\approot folder deleted?
I have an elevated startup task which checks for the existence of a file in this folder before adding some registry settings. This has worked in the past but is now failing because the file it expects to find is no longer there following a portal-induced reboot.
If I perform a 'shutdown' command from within the startup task, the instance reboots but the contents of e:\approot are unaffected.
As others have already said, the contents of the drive are not lost on reboot. What has most likely happened is that you are hardcoding "e:\approot" in your startup task. You should not do this. I would hazard a guess that when you reboot, the drive has moved to f:\ or some other drive. I have seen this quite a bit.
Instead, you should reference %ROLEROOT% environment variable. That will point to the correct drive and path (e.g. "%ROLEROOT%\AppRoot") on reboot regardless of where the drive actually gets moved to.
I don't believe the conent of e:\approot will "disappear". The original content I mean.
This is the location where your role code is located, so it is not being deleted in any way, otherwise your role will not work at all. It might be reinitiated on every reboot, however I really doubt that is true.
If you use startup task to check for something you manually add, I suggest that you use a Local Storage Resource. Keep anything that is not part of your original package deployment in a Local Resource. You have the option to keep the content of this folder(s) (or clean it) upon role "recycle".
If your startup task is checking for some contents of your role code/package to be there, I suggest that you implement some wait logic in the cmd/batch file you are using. And also mark the startup task as "background" type, so it does not block the instance startup. As I said, e:\approot cannot be empty, because this is where your code resides! The content might come there later, but for sure it will not stay empty.
You can't count on local changes surviving (or not surviving) updates or restarts - changes may persist or may be lost.
Your code should be designed to account for that, period. You can store temporary data locally to resume faster, but that data persisting is not guaranteed, so you should have that data in some durable storage like SQL Azure or Azure Storage.
The behavior you see might be caused by installing software updates. I'm not sure that's how it works, but imagine Azure infrastructure decides to roll on Windows updates on some of your instances VMs. Installing updates can take long, so Azure will just stop your instance, then start another (already updated) clean VM and deploy and start your role instance there. If that happens all local changes will of course be lost - your instance will be started on a fresh clean VM and your current VM will be discarded. That's just a speculation, but I imagine it's quite realistic.
Answer is that when the Reboot button is clicked on the Azure portal, the contents of the AppRoot folder are deleted and the package redeployed.
To test, deploy something (anything...) to an Azure instance. RDP onto the instance and create a file (test.txt) in the AppRoot folder (this will be on the E: or F: drive).
Click the Reboot button on the portal. Wait for restart, then RDP onto the instance again - test.txt no longer exists.
Note that if you RDP onto the instance and choose Restart from the Windows UI, then test.txt is not deleted.