I have a Windows Server running as a Virtual Machine on Azure that I have installed SQL Enterprise on. I installed SQL Server onto a new drive (E:) so that the C: drive would remain for the OS.
I followed the instructions on how to use sysprep and basically capture the image to use going forward for new instances. After following these steps and deploying a new vm with this image, nothing worked. It thought SQL was installed (it wasn't). It also didn't know anything about the additional drives or VHDs.
I came across this Blog post from the Azure team and it references a powershell command Save-AzureVMImage that may be what I'm looking for with the new "Virtual Machine Image".
Ultimately what I want is to have an image that I can use to deploy a new fully functional Windows Server instance with SQL Enterprise installed and the additional VHDs being used... Can someone point me in the right hemisphere on this please...
Save-AzureVMImage until the build 2014 only captures OS disk and not the data disk, since your SQL is installed on a separate mapped drive a data disk. That will not be part of the snapshot\sysprep process.
There is something called VMImages recently launched which captures data disks along side OS disks.You will have to update Azure Commandlets to find more options while capturing Image of a running VM, Refer to the blogs below for more detailed solution
http://vishwanathsrikanth.wordpress.com/2014/04/16/windows-azure-vmimages-updates-to-clonevm-powershell-script/
http://blogs.msdn.com/b/windowsazure/archive/2014/04/14/vm-image-blog-post.aspx
Happy Coding !!
Related
Our development environment has a bunch of virtual machines running different versions of our software. I want to be able to replace the Managed Image that is running on a VM, without having to destroy and recreate it.
The images are created using packer, which provisions them with the correct software and dependencies.
Example of Current Workflow:
Machine A is running on Managed Image v2.5, which runs software with a dependency on Tomcat 10.
To fix a bug in v2.2, which depends on Tomcat 9 and thus cannot run on the same VM without changing the dependencies, I have to:
Destroy the VM
Recreate it using the same arguments (name, size, etc) but based on Managed Image v2.2
Attach the network interface and disks
Restart it
If feel like there should be an easier solution to this, where it is possible to hot-swap the images, without recreating the full virtual machines. I've looked into swapping the OS disk, but I couldn't figure out a solution that would work with Managed Images instead of VHD's.
As per official article, its not Supported.
Microsoft does not support an upgrade of the operating system of a
Microsoft Azure virtual machine. Instead, you should create a new
Azure virtual machine that is running the supported version of the
operating system that is required and then migrate the workload.
Official article : https://support.microsoft.com/en-us/help/2721672/microsoft-server-software-support-for-microsoft-azure-virtual-machines
Instead you can use windows server migration tool that would assist you in roles and feature's migration
Install, use, and remove Windows Server migration tools
Similar issue discussed at Can you do in-place updating/upgrading of Azure VM Operating System?
The default Disk Size when creating a VM in azure is 30GB. I only use around 3GB of it. Now, Azure offers a 4GB disk, at a sixteenth of the cost. They decided to make it SO complicated to make it 4GB or 8GB, instead of just offering as an option when creating a VM.
All I need to do is to create a new 4GB managed disk.
How do I get the VHD file for ubuntu so I can finally make the disk? I was looking everywhere but can't find the answer.
EDIT:
As mentioned in the comments, what you require is the Desktop version of Ubuntu and not the Server one. In addition to Ubuntu NOT providing any Azure-compatible Desktop version of Ubuntu, Azure only endorses the Ubuntu versions below:
Ubuntu Server and Pro. 16.x, 18.x, 20.x
Information about extended support for Ubuntu 12.04 and 14.04 can be found here: Ubuntu Extended Security Maintenance.
Additional distro support info here too.
For the images below, you rightly pointed out (apologies for overlooking) that it will still provide you with a 30GB image after conversion.
Also, because Ubuntu Server and Desktop editions share the same kernel, it should be possible for you to follow the same steps to download and create your custom image by following the same prep steps outlined for non-endorsed distros, convert it to VHD and then upload it. Even if this is successful, it's also possible that it will cause some other issues with underlying Azure services.
One last option I thought of is using Azure Migrate to move an existing on-premises Ubuntu VM to Azure. This option failed when we tried but I should disclose our VM was running a much older version of CentOS. When using Azure Migrate, Azure will analyse your machine and tell you whether your VM is supported.
Original Answer:
So here's the thing - you can only use images that are in an Azure Storage Account. Although it seems you've been through a lot already, I'm afraid it doesn't get any easier but steps are generally clear on how it can be done.
1 - Get the image
The Azure documentation on the topic actually recommends to download it from the official Ubuntu cloud repository.
Note
Before attempting to create your own custom Ubuntu image for Azure, please consider using the pre-built and tested images from https://cloud-images.ubuntu.com/ instead.
You can also just download one of the two versions listed on the documentation - this will provide you with a .VHDX file.
2 - Convert the VHDX to VHD
Azure does not support the .VHDX format. See:
The VHDX format is not supported in Azure, only fixed VHD. You can convert the disk to VHD format using Hyper-V Manager or the Convert-VHD cmdlet.
Here's an article which explains how to do this with both options.
3 - Upload the VHD to Blob
Once you have the file in VHD format, you can now upload it to Azure.
You can use AzCopy which is rather complicated when compared to a direct upload, but just mentioning that this can also be done. It also seems to be the recommended approach from Azure.
The easiest option is to upload manually through the Portal. See this article that goes into details - pick what's relevant to you.
(a) Choose your storage account, create/select a container you want to upload to
(b) Click Upload and select the Ubuntu VHD file to upload.
Ensure that the Blob type is set to Page Blob.
4 - Create a Managed Disk and VM
Once your Ubuntu VHD is uploaded, go to its properties page and get the blob URI.
Use that when creating the disk.
Create a VM from the managed disk.
That should be all - it's very painful but possible
I managed to go as low as to just 3 GB and have Ubuntu 20.04 LTS (Focal Fossa) running as an Azure VM.
Prerequisites are below mentioned images downloaded from https://cloud-images.ubuntu.com/focal/current/, a tool to convert VMDK to VHD (e.g. 2Tware Convert VHD) and Hyper-V Manager installed/turned on under local Windows features.
I couldn’t go that low when using the dedicated focal-server-cloudimg-amd64-azure.vhd.zip. When unpacked the file livecd.ubuntu-cpc.azure.vhd is 30-31 GB large. I didn’t manage to shrink it (only an expansion was possible), so the result would have been worse than the original (30GB) Ubuntu VMs from Azure Marketplace.
I have downloaded focal-server-cloudimg-amd64.vmdk instead. Here a conversion to VHD was needed with help of 2Tware Convert VHD. Unfortunately, if uploaded to Azure this image is not accepted as it is a Dynamic VHD.
I had to use Hyper-V Manager to convert it to fixed. Here however I faced one another issue. When in Hyper-V Manager going through Edit Disks…->Browse…->Convert->VHD->Fixed the file I was getting was 10 GB large (noticeable improvement, but still larger than the final 3 GB).
Instead of going through Edit Disks… I went for Quick Create… of a new Virtual Machine. I chose Local installation source and selected the VHD file converted from VMDK. Finally, I clicked Create Virtual Machine.
The VM is created, but there is no need to connect to it. In fact, it can be deleted right away, as what is really needed is the file (presumably) stored as New Virtual Machine.vhdx under C:\Users\Public\Documents\Hyper-V\Virtual hard disks\.
With help of Hyper-V Manager this time I managed to both convert the file to Fixed VHD as well as to shrink it to 3 GB.
Later the process is as described in #Ked Mardemootoo’s answer (the instruction from IBM). A new Storage account needs to be created in Azure. Then in the Storage Account a new blob Container needs to be created. The VHD file is to be uploaded to the Container. Later a new Image needs to be created from this Storage blob and from this image a new small VM can be successfully created.
I installed a few beta version of some apps and now the functionality of the Windows is broken.
Is there any way I can reset the windows to it's initial state from the portal or I have to remove it and create a new one?
If you have not backup this VM or take a snapshot of this VM, we should re-create a new VM.
As mentioned by Jason, if a backup or a snapshot was taken, you could use them to recover the VM.
You have mentioned, ‘now the functionality of the Windows is broken’, unsure if you are facing some boot issue or something else. Please do let me know if feasible, you could look at fixing the underlying issue. Or just recreate the problematic VM and not the entire Resource Group itself.
I would like to highlight the process of recovering the OS below:
Delete the VM encountering issues, keeping the virtual hard disks.
Attach and mount the virtual hard disk to another Windows VM for troubleshooting purposes.
Connect to the troubleshooting VM. Edit files or run any tools to fix issues on the original virtual hard disk.
Unmount and detach the virtual hard disk from the troubleshooting VM.
Create a VM using the original virtual hard disk.
Refer the document for more details on this process.
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.
I've got 6 web sites, 2 databases and 1 cloud environment setup on my account
I used the cloud to run some tasks via Windows Task Manager, everything was installed on my D drive but between last week and today the 8 of March my folder containing the "exe" to run as been removed.
Also I've installed SVN tortoise to get the files deployed and it not installed anymore
I wonder if somebody has a clue about my problem
Best Regards
Franck merlin
If you're using Cloud Services (web/worker roles), these are stateless virtual machines. That is: Windows Azure provides the operating system, then brings your deployment package into the environment after bootup. Every single virtual machine instance booted this way starts from a clean OS image, along with the exact same set of code bits from you.
Should you RDP into the box and manually install anything, anything you install is going to be temporary at best. Your stuff will likely survive reboots. However, if the OS needs updating (especially the underlying host OS), your changes will be lost as a fresh OS is brought up.
This is why, with Cloud Services, all customizations should be done via startup tasks or the OnStart() event. You should never manually install anything via RDP since:
Your changes will be temporary
Your changes won't propagate to additional instances; you'll be required to RDP into every single box to perform the same changes.
You may want to download the Azure Training Kit and look through some of the Cloud Service labs to get a better feel for startup tasks.
In addition to what David said, check out http://blogs.msdn.com/b/kwill/archive/2012/10/05/windows-azure-disk-partition-preservation.aspx for the scenarios where the different drives will be destroyed.
Also take a look at http://blogs.msdn.com/b/kwill/archive/2012/09/19/role-instance-restarts-due-to-os-upgrades.aspx which points you to the RSS feed and MSDN article where you can see that a new OS is currently being deployed.