My specific situation with Azure necessitates high-bandwidth processing of many small tasks. As such, Azure's new GPU VMs (N-Series) sound great to my team, except we're not sure if we're paying for a Tesla M60 or for 56GB of RAM.

The point of GPUs in Azure is providing direct access to CUDA, and splitting processing into 4096 cores instead of 6. As such, a 6-core CPU and 56GB of RAM is highly unnecessary for the tasks I wish to execute on an NV6.

Microsoft, please provide other GPU instances that have the same amount of GPU power, but less RAM and less CPU cores. For example: NV1, NV2, NV3. 1 M60, 2 M60s, and 4 M60s respectively, just like their higher counterparts. The difference would be less RAM, and less cores, making this a cheap GPU option for all subscribers.

Thanks!

When SQL Server is purchased as part of an Azure VM and a subscription is setup to pay for SQL Server & the VM by the minute, it is not possible to upgrade the SQL Server Edition. The entire VM must be rebuilt which, while possible, can be very time consuming.

Request is to allow SQL Server edition upgrades within Azure VMs when paying by the minute for service. For example, a VM may be initially built with SQL Server Standard edition. This is my situation. I now have the need to use an enterprise edition feature (data driven SSRS subscriptions). I have no choice but to rebuild the VM from scratch.

I have been researching the Microsoft Antimalware for Azure which is currently in preview. I think that the idea behind this product is fantastic. There was a real gap in the market for customers who want to run VMs on Microsoft Azure. So I am glad to see that Microsoft is offering a service which addresses the need to protect Azure VMs from viruses.

Unfortunately, the current release of Microsoft Antimalware for Azure is extremely difficult to deploy, configure, and manage. The main reason for this is the lack of any UI for the administrator or end user. To do any type of meaningful administration of the service requires the use of Powershell. I do not believe it is an exaggeration to say that Microsoft Antimalware for Azure is the most difficult to use product on the market today. I realize that the product is in preview and that it will mature over time.

I am frankly surprised that Microsoft has taken the approach of building an entirely new service to provide antimalware to Microsoft Azure VMs. This seems like an enormous engineering effort for an organization that already have four different antimalware solutions (Microsoft Security Essentials, Windows Defender, System Center Endpoint Protection, and Windows Intune). Instead of creating a 5th service to protect against antimalware, it would seem far more logical to take one of the existing services and adapt it to protect Azure VMs. I would have thought that extending Windows Intune Endpoint Protection (WIEP) to run on Azure VMs was the most sensible approach. One of the nice benefits of WIEP is that it has a very simple UI which is ideal for businesses that lack the technical expertise to run System Center Endpoint Protection. But Microsoft chose to build an entirely new antimalware product instead which make System Center Endpoint Protection look simple by comparison.

I sincerely hope that Microsoft will take this feedback in the spirit in which it is intended. The concept behind Microsoft Antimalware for Azure is terrific. It is a fantastic idea whose time has come. But Microsoft needs to prioritize their investment in a user interface so that the major of administrators can deploy and use the product successfully. Otherwise, it offers no real benefit to customers.

Each Azure virtual machine comes by default with a Free and temporary drive, that is mounted in 'D:'
We all whish that Microsoft gives us the possibility to choose the letter of this temporary drive before deploying the VM.
Why ? Becasue the D: drive is the most used letter for data disks. This is a huge issue when migrating workloads from on-prem to Azure, and this is a real limitation.
I know there is a workaround to change the letter, but in case of unplanned fail over or host change, the temporary drive will be assigned the 'D:' drive, and it will cause service interruptions and issues.
Please, think about it. Great team you are!!

We are working on Azure Public and checking nested VM for this we have created one instance "Standard E4s v3 (4 vcpus, 32 GB memory)". Hyper-V role has been installed successfully and also we have created 3 VMs successfully, now when we are setting networking for these created VM per MS KB "https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/nested-virtualization" everything is working fine but our objective is still not getting solved with this.

We wanted to MAP a public IP on these VMs but per KB NAT is only solving purpose if we need to run internet only on created VMs or forwarding working when there is only specific port need to forward with main instance public IP.

These VM's would be hosted with public applications so how we can map direct public IP like we are doing for other public Azure instances, if that is not possible this feature is useless.

The Azure VM internal DNS domain names are too long.

Azure IaaS VM's created using the Preview Portal using the
"Resource Manager" deployment model generate DNS domain names
that are too long, for example:

03v3fn0ewrau5aiydhfewgpjza.cx.internal.cloudapp.net

Since the FQDN max length, in Linux at least is 64 chars, that
leaves only 12 chars for the "Computer Name". There are no
warnings or protections on creating a VM with a length longer
than 12, so when the host comes up, and DHCP sets the hostname
based on the "Computer Name" it finds that it has an illegal
FQDN length.

It seems that some unique internal DNS name other than
something like '03v3fn0ewrau5aiydhfewgpjza' could generated.
There does not appear to be a way to change
'03v3fn0ewrau5aiydhfewgpjza' to something shorter, and more
meaningful. Since you cannot change the name of the VM once it
is created, the user should be given more guidance on an
acceptable length name given the long length of the dnsdomain
names.