I am learning VMSS and have two general questions for my understanding.
Q1 : How new virtual machines gets provisioned in the VMSS?
Does it clone the existing VM from VMSS or use Image every time to provision a new VM?
. If it clone existing VM from VMSS then which VM out of the existing VM’s it clone?
. If it provision new VM from the image then in the case of platform image, do I need to install web server and other changes every time because I do not have a requirement to use a custom image?
How to make changes to the VM’s in VMSS?
. If I need to modify web server settings then how do I make the same settings on the other VM’s in VMSS?
Q1: How new virtual machines get provisioned in the VMSS?
It creates the new VM from the configuration that you set for the VMSS every time, not clone the existing VMs. If you do not use the custom image, then you need to install web server and other changes every time for the new VMs.
Q2: How to make changes to the VM’s in VMSS?
You can use the VM extension to make the changes to the VMs in the VMSS. Or just use the custom image.
Related
The Azure Monitoring Agent is a service that runs on a virtual machine and sends logs and metrics to Azure Analytics. This agent can be installed via multiple ways, for example:
by selecting the option while creating the VMSS, for example in the Azure portal
with an "Enable" button in the monitoring section of a VMSS in case it was not installed while the VMSS was created
by installing the the correct "extension" for all machines in the VMSS
manually or automated as a software installation inside the virtual machine, for example via ansible or actually by hand
There might be more options, but in any case the agent needs to know to which Analytics Workspace it should send its data, and this value is a user input during the installation of the agent.
Now, once installed, how can I change the destination Analytics Workspace for an entire VMSS?
There is no option to change the workspace. for the Virtual machines scale sets this support is limited as of now.
Is it possible to have the vm's in a VMSS be in a deployment group inside of VSTS?
Could I provision a vm with the deployment group, save its disk image, and use that as the image for the vm's in the scale set? That way when a new VM is created it will already have the vsts agent on it. But, will the authentication still work against VSTS? I know it uses a PAT, I feel like there could be issues there.
Also, if new vm's "scale" up, how would they be able to get the latest version of the build? Would I have to run the Release inside of VSTS everytime the scale set scales up?
We have a requirement to Migrate EC2 instance of AWS to Azure as VM, have been trying to implement the same from this source,
unable to complete the process. Tried and stuck on Protection Group.
I'm looking in these other links
Migrating a VM from EC2 to Azure at 300 Mbps For this I'm able to create VM in Classis portal but unable connect to it only port 80 is active all other ports are not working
Migrate virtual machines in Amazon Web Services (AWS) to Azure with Azure Site Recovery
https://learn.microsoft.com/en-us/azure/site-recovery/site-recovery-vmware-to-azure
https://aws.amazon.com/ec2/vm-import/ on trying this I'm getting this unresolved EC2 API export to S3 ACL issue
Can anyone suggest me a workflow on how to implement this?
I achieved this by downloading AWS EC2 VHD to an Hyper-V enabled machine on-premises.
Following are the steps.
Create VM from VHD and Remove AWS related software.
Open Hyper-V manager and create VM from the downloaded VHD.
Log in to the VM and uninstalled AWS related services from control panel (AWS Drivers, EC2configService, AWS Tools for Windows, AWS SSM Agent)
All these changes were affected on the VHD.
Upload the converted VHD to Azure Storage (using the Azure PowerShell cmdlets)
Create av Azure VM-Image from that VHD in Classic Azure Portal
Create an Azure VM using the new Image.
Created a classic VM in Azure portal.
For creating a VM under Resource manager, created VHD of newly migrated VM and using that created a new VM in azure portal.
Mention any workflow other than this.
There are multiple ways to migrate machines.
Azure Migrate: Server Migration is one tool that lets you do that and is the recommended way to rehost x86 machines to Azure. You can treat the EC2 instance (AWS VM) as though it were a Physical machine and migrate it to Azure as long as the Operating System on the machine is supported by the Physical Server Migration flow (also check the kernel version to ensure it is supported) https://learn.microsoft.com/en-us/azure/migrate/tutorial-migrate-physical-virtual-machines
That being said, EC2 VMs may have some changes that you’ll need to make before migrating them, or it may cause issues once in Azure. For example if they are using cloudinit for VM provisioning, you may want to disable cloudinit on the VM before replicating it because the provisioning steps performed by cloudinit on the VM maybe AWS specific and wont be valid after the migration to Azure.
The other thing to note is if the VM is a PV VM (para-virtualized) and not a HVM VM you may not be able to run it as is because paravirtualized VMs use a custom boot sequence in AWS (you may be able to get over this challenge by installing GRUB 2 on the VM and building grub)
The recommendation, if you are using this approach, is to always perform a test migration first to test the process.
I have an existing VM with a configured Sharepoint environment. I would like to use this machine as a base for creating multiple azure VM instances for several developers to work on. Is such scenario possible? Is running 'sysprep' (will ruin my sharepoint) unevitable?
I would also be able to upgrade the 'image' (e.g. install windows updates) and create VM's from it afterwards.
How can I achieve this? I know cloudshare offers similar solution, so I suppose it also can be done in azure.
You certainly can make an image from a Virtual Machine. The entire process is described here. Also look at my other SO answer about a caveat when running sysprep (regarding not letting the VM image shut down after sysprep runs).
Once you have your image, it will be available in your Virtual Machine gallery, where you can choose it as your baseline for new VMs (either via portal or PowerShell / CLI).
If, in the future, you do updates on your master image, you'd need to re-create an image for future deployments. Or... you'd need to install the updates on each deployed VM instance.
Note: With web/worker role instances (which doesn't help for SharePoint but could help with other workloads you have), the Windows Server OS image is maintained by Microsoft. Should there be an OS update, these are taken care of for you.
So I am a little bit confused about the Azure feature to create virtual machines(i.e VMRoles).
When I do a quick create via the managment portal, I am not asked to specify nor a hosted service nor a storage account. After I click 'create' I see that a storage account is generated for me automatically with some unique name, but I don't see the same for a hosted service. Is a hosted service not needed to create a VM?
The thing that is confusing is that it seems like every other method for creating a VM does require me to specify a hosted service (Azure PowerShell, REST API). And indeed after I create the VM using one of these methods I see my VM inside the hosted service...
Anyone can explain this?
Thanks in advance
Please do not confuse Windows Azure Virtual Machines (IaaS, stateful) with Windows Azure VMRole (PaaS, stateless).
As for creation - the process behind the portal is automated. For me, I have a separate Cloud Service for each Virtual Machine I've created (along with the auto generated storage account). However as all operations are asyc, and I also guess the Microsoft teams are using some kind of CQRS pattern behind the portal, it might take some time for all the components behind a Virtual Machine to appear. While the API strictly requires everything to be ready set, before you actually create the Virtual Machine. My guess is that soon you will also see a cloud service created for your VM (it usually is with the name of the Virtual Machine you created). Also, if you have noticed, the public URI for accessing your Virtual Machine (be it RDP or SSH) has the format of [your_vm_name].cloudapp.net - so this is a Cloud Service (formerly known as Hosted Service).
First of all Windows Azure Virtual Machines and VM Role are two separate things. Based on what you have explained it seems you are trying to create a Windows Azure Virtual Machine so I will explain you in short how it works:
Very first: In order to create a Windows Azure Virtual Machine you need a VHD which has OS Image. You can use one from Gallery or you can upload one by yourself to your specific Blob Azure Storage.
When you use Quick create or create the process is exactly same in the background however during quick create lots of settings is already predefined as will quick create you will only get Windows OS VHD to choose. In both cases a storage account is used to copy the OS VHD (if it is not part of your OS image collection). In most of the cases a previously created storage account is used, so you may think in was not created but in fact the storage account was used to copy the VHD from repo. This may not be the case if you create a VM from an image which is already in your OS VHD collection.
With quick create the DNS name you set is become the VM name but with create you have option to create a different DNS name for your application but they needed in both cases. In any case the DNS name will bind to your VM, the same DNS name will distinguish your VM from others and a must to configure for any VM.
I believe that the cloud service is not surfaced for a single quick-create Virtual Machine. This is to make Virtual Machines as easy to use as possible. The cloud service would be created and be displayed on the portal were a second virtual machine to be added to the cloud service.