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).
Thanks for the valid suggestion. Your feedback is now open for the user community to upvote which allows us to effectively prioritize your request against our existing feature list and also gives us insight into the potential impact of implementing the suggested feature
Michael Banks commented
This really is kind of amazing. They have the capability to do this in Hyper-V. Why not in Azure
when something goes wrong you need a console
it would be great to such a task that simulate the connection to a KVM console to monitor the machine during the bootstrap process the same way we see it using ILO management interfaces
This one issue alone makes Azure a non-starter for us.
Brad K commented
This amazes me. A multi billion dollar company like MS can't implement console access even though every paying customer is asking for it. I love my vmware environment but it seems like the bean counters want to move away from a tried and true technology that has worked flawlessly for the last decade to "azure". In the middle of trying to upgrade to windows 2016 which I had no issues doing in my vmware environment only to end up here- searching as to why I can't console in to click an accept button. What a waste of time this exercise was, time to restore.
Did console access every get implemented?
Admin Spotcrowd commented
I need to run one command to re-open the SSH port in my UFW firewall.
How do I do that? I cannot access my VM at the moment
While PowerShell Direct is nice, console access really is a necessity. Something that does not depend on the guest running - to diagnose and repair any pre-boot issues (e.g. resulting from a failed update). Even better if it supports booting from an uploaded (e.g. ISO) image. Something like the out-of-band remote access provided by IPMI/KVM-over-IP (e.g. iDRAC, ILO) and standard hypervisors (VMware/ESXi, Hyper-V, etc.).
Sample on fail on Azure Linux VM and wont boot.
[[0;32m OK [0m] Started ifup for eth0.
[[0;32m OK [0m] Started Raise network interfaces.
[[0;32m OK [0m] Reached target Network.
Starting Initial cloud-init job (metadata service crawler)...
[ 25.364088] blk_update_request: I/O error, dev fd0, sector 0
So how to blacklist floppy (modprob / initramfs) without a console or download and then upload the VM
Dirk Gillis commented
"I don’t have a timeline but we know this is critical" and 1330 days later still nothing. In Exchange we are already waiting 15 years for some feature requests (like OOF automation).
Time for action instead of words.
Most needed feature request which would help us during incidents with VMs would be a proper bi-directional console access to VMs.
At the moment console access is only one way with screenshots & serial output, but it does not help when any config change is needed to get recovered.
Aws does not have console access either. Just a log
Over 3 years later, and you still haven't done this. Even your premier support people claim they can't access the console. I now have hours of work to do, messing around with VHD files.
DISGUSTING. MicroSHAFT strikes again. Once I fix the issue, I think I'll be uploading them into AWS.
Marcus Lachmanez commented
I like the idea of having console Access to the VM.
But especially on Linux there is a simple Mount-option available that allows you to Login in to your VM even in the case that one of your datadisk is out of orderd, or not available. This usually triggers the OS to go into recovery/emergency mode. But with the Option 'nofail' you are able to avoid this critical Situation. You only have to be Aware that you are not able to relay on an existing disk for your application. You have to verify that it is really mounted and useable.
See the following docu for more Details how you hve to use the Option --> https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-add-disk/
This is... insane.
How did you get to market without remote console access on VMs?
You cant possibly deploy without this.
Like other providers provide console access to the VM's then why do Azure has a problem in providing this. Really hard to work with the Azure VM at cases were we lose the access of the server and needs to wait along time!!!
Michal Nečas commented
This is "must have" feature for production. I have spent hours with downloading corrupted VHD machine image to my corporate environment to make "3 clicks change" to repair it and then spent again uploading it back to Azure. Then re-deploy the machine with repaired feature and hope and rpay that licensing of business line application will work.
Can not image to do that more than once again! This is what backup will not solve. Re-deploy when you need to download / modify VHD at first is time consuming, so not a solution as well.
If I had a console, I would solve it within 10 mins.
Mehrdad Z commented
Along with full console access, there should be the ability to boot from a rescue CD/DVD to be able to resolve the issue as well.
Stick it in Azure commented
I've largely ignored this problem/limitation as working with a few dozen deployments now exclusively windows, it seems the Windows 2012 R2 OS works rather well with the Azure portal recovery/troubleshooting tools and the requirement for console access has never left me stranded.
Linux however, is another story. I'm now working on a predominantly Linux deployment and we've had a couple of issues now with VM's that we cannot access, due to booting into emergency/maintenance mode and expecting a prompt from the user at console level.
We get a screenshot telling us exactly what the problem is, but this is just brings an added level of frustration. So close, yet so far.
A further update to this feedback suggestion would be most welcome.