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.
Related
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.
When I create a VM in Azure, it is creating an accompanying Cloud Service and Network Resource. I found that the Cloud Service is there as a deployment layer. I have not found why the Network Interface is there.
Since this particular circumstance is not going to have a deployment associated with it as it is used as an Elasticsearch server, I technically will not be needing the Cloud Service. However, when I delete the service, it takes the VM with it even though I do not expressly select it for delete.
My two specific questions:
1st - Why is there a Cloud Service created and not able to be deleted without repercussions when there is not deployment necessary?
2nd - Why is the Network Interface created and not able to be deleted without repercussions?
Both questions are with the understanding that this is an Elasticsearch VM.
A cloud service is a required artefact of an ASM/classic deployment if a VM. It is not needed in an Azure Resource Manager deployment, which is what you should use for new deployments. However, the two types of deployment are orthogonal, so you may need to keep using ASM if you already have VMs deployed that way. If so, you should consider migrating them to ARM.
(Note that I'm using the new "blade" Azure Portal exclusively and use the new terminology, so avoid words like "Azure Website" as they do not apply here).
In the Portal I created two Azure App Services, "foo-production" and "foo-staging" - both exist in the same Subscription and Resource Group, and share the same App Service Plan. These App Services represent the production and staging deployments of a straightforward ASP.NET web application, which runs as a normal website.
The App Service Plan is "Basic: 1 Small".
My understanding is that when you use Azure App Services with a Basic or higher App Service Plan, that the Plan represents a VM which I'm able to host as many IIS websites as I want on - these IIS websites are represented in Azure as Azure App Services.
Given this, one would assume when I access the filesystem of the VM in Kudu ( https://yourwebsite.scm.azurewebsites.net/DebugConsole ) that I would be able to see each website's files under some common root directory.
However when I access the Kudu console for the foo-production website, I see that its files are in D:\home\site\wwwroot and files for foo-staging are not to be found.
If I'm understanding this correctly, it means that Azure actually created a whole new VM just for each website and that websites cannot share a filesystem - and that I cannot have a more advanced Azure-managed IIS configuration - I'd have to create my own self-managed Windows Server VM.
I can understand the motivation behind a separate VM for each website, it just seems wasteful - Windows Server requires at least a gigabyte of memory for each VM, yet my website is largely just static files (but I can't use a Shared App Service Plan because I need some of the more advanced functionality). That can't be economical for Microsoft then.
How can I have multiple Azure App Services in an Azure-managed environment share the same VM? Or am I thinking about it incorrectly?
To avoid an X/Y problem: I'll state that my primary concern is the persistence of files. The web-application I'm deploying stores uploaded files to a subdirectory of the webroot and those files should be there permanently. There is ambiguous information out there: some people suggest websites (and all their files) are actively destroyed and recycled and that Azure Storage Blobs should be used. I would like to use Azure File Shares, unfortunately I get ACCESS_DENIED errors when using WNetAddConnection2 and some users report that Azure File Shares cannot be used from within Azure App Services - though I cannot find anything authoritative from Microsoft about this.
If they are in the same App Service Plan, they are running in the same VM. Try typing hostname in Kudu Console for each and you'll see the same machine name.
But note that they each run in a different sandbox, which prevents them from seeing each other's files. Folders like d:\home are virtualized, and are actually pointing to network shares. So you can't use that to make conclusions as to the machines are the same.
As I answered here, all app services within a plan run in the same set of VMs, sharing all compute resources.
You assumed each app service within a plan shares files with all other app services. This is incorrect: Each app service will have its own set of files, in d:\home for each app service. If you need to share files, you'll need to use something external to App Services, like Azure File Service (an SMB share). Azure File Service is separate from the space created for you on a per-app-service basis.
An Azure "App Service" is analogous to a "Container" (Docker terminology). Although it's based on a VM, it's much lighter weight than a VM itself. For example, you cannot RDP into it.
An Azure "VM" is a full-fledged virtual machine. The OS can be Windows or any of several different flavors of Linux.
You can get more information here:
Azure App Service, Cloud Services, Virtual Machines, and Service Fabric comparison
Here is an excellent article that compares Web Sites (one example of an App Service), Cloud Services, and VMs:
http://www.c-sharpcorner.com/UploadFile/42ddd2/azure-websites-vs-cloud-service-vs-virtual-machines/
Azure Websites
Azure Websites has very little responsibility to complete, and
relatively less control. It is the best choice for most web apps.
Deployment and management are integrated directly into the platform we
get.
Azure Cloud Services
If you want more, web server like environment you might want to go
with Azure Cloud Services. You can remote into your cloud services and
configure startup tasks. Cloud Services provide you more Ease of
Management and Agility than Azure Websites
Azure Virtual Machines
Provides you rich set of features; however, correctly configuring,
securing and maintaining VMs require much more time and more IT
expertise compared to Azure Cloud Services and Azure Websites.
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.
I am developing an Azure application, part of which involves users browsing an online filesystem. TO do this, I am trying to use the Windows Azure drive, but I can't figure out how to access it from client side, or how to make it accessible on the server side.
At the moment, I only know how to make the drive:
CloudStorageAccount devStorage = CloudStorageAccount.DevelopmentStorageAccount;
CloudBlobClient client = devStorage.CreateCloudBlobClient();
CloudBlobContainer container = new CloudBlobContainer("teacher", client);
CloudDrive.InitializeCache(localCache.RootPath,
localCache.MaximumSizeInMegabytes);
CloudDrive drive = new CloudDrive(container.GetPageBlobReference("drive1").Uri, devStorage.Credentials);
drive.Create(50);
I am using C# as my development language.
All help is greatly appreciated!
There are couple of things you need to understand with Windows Azure Cloud Drive:
Cloud drives are actual Page Blobs which are stored on Windows Azure Blob storage and mount as a drive (you will get a drive letter depend on your machine drive statistics) in a machine where you can provide Windows Azure Run time environment.
Programmatic it is very easy to mount a cloud drive in your code as you showed in your example however one thing is missed that is to be sure to have Windows Azure RunTime environment where this code can run.
I have written a utility to mount azure drive within Windows Azure VM (Web, Worker or VM Role) located here:
http://mountvhdazurevm.codeplex.com/
You can run above tool directly in Windows Azure VM and can also this the exact same code in your Compute Emulator (Windows Azure Development Fabric) so the bottom line is as long as you can provide Windows Azure Runtime environment, you can mount a Page blob VHD drive.
I have seen several cases where someone asked me to mount a Windows Azure Page Blob as drive in local machine (client and server, anywhere) and the actual hurdle was to bring Windows Azure Run time in local environment because it is not available. In some cases a few person went ahead and tries to use Windows Azure SDK to have Windows Azure runtime made
available in their desktop, created a dummy web role and then mount the VHD which was mounted in local machine and a drive letter was made available as well. I am not sure about such kind of solution because this is not Windows Azure compute emulator is designed.
Hope this description provide you some guideline.
I'm not sure I understand your question properly, but it sounds like you want multiple client applications - presumably on machines that are not on Azure - to access your Azure drive?
Unfortunately, Azure drives can only be accessed from Azure web/worker or VM role instances.
I've written a WebDAV Server which runs on an Azure Website which will allow clients, including Windows Explorer and Office to connect to Azure Storage. It uses a combination of Table and Blob Storage to store the file structure and files. I've tested it with Windows Explorer and Word 2013. Although this isn't a clouddrive solution it's still using Azure Storage as a backend and it's accessible from WebDAV clients. You might find it useful..
https://github.com/ichivers/AzureDAV
One additional point to the existing answers. You can always download the blob backing your Cloud Drive and mount it on a local system. The blob is really just a VHD. However, the download time isn't going to trivial unless the drive is small.
Erick