Azure-Communitysupport
Fragen stellen, Antworten erhalten und mit Microsoft-Technikern und Experten aus der Azure-Community in Verbindung setzen
MSDN-Forum
Antworten von Microsoft auf technische Azure-Fragen
Auto-shutdown did not work on Win 10 VM
Forum: Azure Virtual Machines
Forum: Azure Virtual Machines
Virtual machine RDP is not working on Mac OSX for guest account
Forum: Azure Virtual Machines
Increasing Azure VM Spot price
Forum: Azure Virtual Machines
42
Stimmen
MS Learn/ Sandbox Creation Error
Forum: Azure Virtual Machines
32
Stimmen
Forum: Azure Virtual Machines
27
Stimmen
Multiple IP addresses for a VM to be able to use Multiple HTTPS endpoints
Forum: Azure Virtual Machines
26
Stimmen
Azure VMs no longer see themselves via public virtual IP
Forum: Azure Virtual Machines
73
Antworten
MS Learn/ Sandbox Creation Error
Forum: Azure Virtual Machines
51
Antworten
VM becomes unresponsive or disk becomes read-only
Forum: Azure Virtual Machines
42
Antworten
Question about deploying multiple VMs with template
Forum: Azure Virtual Machines
37
Antworten
Forum: Azure Virtual Machines
StackOverflow
Antworten der Community auf Entwicklungsfragen
35
Stimmen
Server Fault
Antworten der Community auf Fragen zur Verwaltung von System und Netzwerk
15
Stimmen
10
Stimmen
Feedback zu Azure
Möchten Sie aufgrund Ihrer Erfahrung mit Azure neue Ideen oder Vorschläge einbringen?
Daylight Savings not considered in VM
I live in UK. I created a VM, deployed in West US (of course because Azure UK/Europe is facing overloading), so when I logged into VM the time is showing 1 hour behind. I believe the Daylight saving after March 29th is not considered.
Support for live migration for Lsv2 VMs
As per https://docs.microsoft.com/en-us/azure/virtual-machines/lsv2-series?toc=/azure/virtual-machines/linux/toc.json&bc=/azure/virtual-machines/linux/breadcrumb/toc.json, for Lsv2 VMs, premium storage caching, live migration and memory preserving updates are not supported. Is supporting them in the roadmap? If so, are there any timelines that could be shared?
Allow Termination Events to be enabled on VMSS with Low-Priority/Spot
Would like the ability to enable Termination events on Low-Priority/Spot VMSS. Low-Priority/Spot VMs currently have the ability to react to pre-emption events, but lack the ability to handle scale-in events like the regular priority, auto-scaling, Scale Sets do. I'm acknowledging that this appears to be an intentional decision (see examples below), but think that this would be useful. Terminate Notification: https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-terminate-notification#tips-and-best-practices As well as the api response when attempting to enable it via PoSH: "Virtual Machine Scale Sets with extension scheduledEventsProfile must have property priority set to Regular"
共有
5154
Stimmen
Virtual machine console access
There is no VMConnect capability for console access to the VM as there is with Hyper-V. So in the situation where I lost connectivity, by misconfiguration, or system failure, is there only one very time and bandwith consuming way to fix it - download the VHDs on-premise, boot it in Hyper-V and VMConnect to repair VM, then upload all GBs back to the Azure... I requesting console access, also with ability to mount some image for repair and boot from it (as we do it in standard environment).
1435
Stimmen
VM Created from custom image should be able to select storage account for VHD
When we try to create a virtual machine from a custom image the VHD's for the new virtual machine are created in the same storage account as the custom image. This is not ideal because most customers have different environments in different subscriptions so they are forced to copy the image into storage account in each subscriptions. It is not easy to copy the images between the storage accounts either.
1403
Stimmen
Add the ability to rename a VM. The VM name is what appears in Azure, not the DNS name. Changing a VM's name should not affect the VM in any way. If you need a unique identifier for a VM that does not change, I suggest using a GUID rather than the VM's name in Azure.
1201
Stimmen
Live migrate the VMs during maintenance/hardware failures
Right now Azure VM customers experience very frequent restarts that impact the availability of services. As far as I know, these restarts are mostly caused by either host upgrades or hardware failures. Developing a HA setup is pretty straightforward for some scenarios (web servers), complex (database back-ends, notably MySQL) or extremely difficult (back-end applications used by our accounting department, for instance, which were designed to be run on one machine). Of course, HA setups are necessary for any major applications, but most of the setups we see have lots of single-instance roles (and for good reason most of the times). Currently, if you don't have an HA setup, machines are restarted about once per month or even more frequent (some as often as weekly). If this restart occurs during business hours, then this means downtime. Furthermore, for services like MySQL or SQL Server, this also means that the entire buffer pool is emptied and the performance of the application is degraded until the buffer pool fills up again. What we would love to have is something like Google Cloud's Live Migration - the VM would be moved to another host in case of hardware failures or host upgrades without restarts or downtime.
Azure VM limits should be visible on VM Overview page graphs
In a support case I found one of my VMs was being throttled because it was over disk write limit; the performance (other colors, not red) and limits (in red) should be on the graphs on the overview. This seriously impacts availability when VMs are being throttled and makes for an insidious and hard to understand issue. All performance limits should be visible! Please implement?
For the maintenance that doesn't require a reboot, customers can know it only through Scheduled Events API. https://docs.microsoft.com/en-us/azure/virtual-machines/maintenance-and-updates?toc=/azure/virtual-machines/linux/toc.json&bc=/azure/virtual-machines/linux/breadcrumb/toc.json#maintenance-that-doesnt-require-a-reboot Several customer requests easier way to grasp the affected resources and that history (e.g. dashboard).
The target resources affected by planned maintenance
When a planned maintenance is executed, the details and impacted resources are announced toward administrator by mail. I would like to check the target affected resources other methods exept mail.
Currently if you want to change the VM Size of Azure, VM is restarted. VM Resize shouldn't require downtime and it should be done in the backend. As CPU and RAM is still throttle when we use more resources then why can't we just remove the throttling limit and inform customer that VM is resized from A to D series when request is raised of resize?
Supportticket erstellen
Incident erstellenSenden Sie uns über Twitter eine Nachricht: @AzureSupport.
Finden Sie uns auf TwitterHelfen Sie uns bei Verbesserungen. Ist diese Seite hilfreich?