You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using Bastion, in multiple regions tested, in multiple tests, (using paid Azure subscription) performance of the Bastion session to the az801l07a-hv-vm is so poor as to often make the lab unusable due to delays in login/browser page refresh/etc.
Opening a new issue for this specifically - but please see also closed issue #4, description under 'More major issue:' - this problem has definitely been seen before, and doesn't seem to be the kind of rare/intermittent occurrence that we might have hoped.
Repro steps:
After creating az801l07a-hv-vm & its Bastion host, use Bastion to connect to the VMs: while its screen refresh may vary, it bogs down particularly badly on VM login screens (that are not set to a solid color) and any pages in Edge that have any sort of active content, and/or high color graphics. Similar problems when trying to access nested VMs in same Bastion session.
I did some testing/troubleshooting to try and find some setting that would resolve for this issue but at least within Bastion, was unable to find any:
Tests in Eastus/Westus/Centralus, all experienced the issue soon as connected via Bastion to the Azure-hosted VM (az801l07a-hv-vm)
As previously, desktop access in the VM can become passable after one manages to get logged in...but is at its absolute worst when accessing any page (in browser, in particular) where we have high-color graphics/active content.
Bastion: Is 'Basic' tier possibly throttled? Tested switching to 'Standard' tier but made no difference.
Enabling accelerated networking on both NICs had no apparent effect.
-Other networking settings within the VM looked OK to me, uncertain if there is any contributing factors to the issue from them.
The only workaround I could identify was to create a new public IP address & bind to az801l07a-hv-vm NIC1, create an 'AllowRDP' rule to allow inbound RDP connections only from the single IP address of my Lab VM, and then utilize mstsc.exe to connect. Note that I did this in each test (in same instance, with all previous config in place as before) immediately after experiencing abysmal Bastion performance, and then immediately validated that when using old-fashioned RDP w/mstsc.exe perf was fine.
The text was updated successfully, but these errors were encountered:
I can confirm that the experience is so slow that the lab can not be followed. As a workaround I instructed my students to add a public ip and an NSG rule to allow RDP connection to the VM which did a huge difference.
leaving this here as a 'scripted alternative workaround' - and again, I don't know there there is never a Bastion Host that is performant...nor am I experienced enough to know if there is some form of tuning that could be done within the HV VM's default ARM template config to make this generally better...but at least as a "...well, what the heck do we do now, in order to complete the lab?..." kind of answer...this has consistently worked for me, and it sounds like similar workaround has worked for sotiris84 as well:
As an alternative workaround, you may run the following three commands in a Cloudshell Bash session at the beginning of Task 3. They will create a Public IP address and associate it with nic1, and then create an inbound rule allowing RDP access.
Note that before running the commands, browse to https://whatismyipaddress.com/ from a browser on SEA-SVR2.
Replace the placeholder WHATS-MY-IP-ADDRESS in the third cmd below with this IP address.
az network public-ip create --name RDP --resource-group AZ801-L0701-RG
az network nic ip-config update \
--name ipconfig \
--nic-name az801l07a-hv-vm-nic1 \
--resource-group AZ801-L0701-RG \
--public-ip-address RDP
After running these commands, from the Overview page of the az801l07a-hv-vm VM, identify the Public IP address that can be used with mstsc.exe to connect using your Student username and password of Pa55w.rd1234
Module: 07
Lab/Demo: 07
Task: Multiple
Step: Multiple
Description of issue
When using Bastion, in multiple regions tested, in multiple tests, (using paid Azure subscription) performance of the Bastion session to the az801l07a-hv-vm is so poor as to often make the lab unusable due to delays in login/browser page refresh/etc.
Opening a new issue for this specifically - but please see also closed issue #4, description under 'More major issue:' - this problem has definitely been seen before, and doesn't seem to be the kind of rare/intermittent occurrence that we might have hoped.
Repro steps:
After creating az801l07a-hv-vm & its Bastion host, use Bastion to connect to the VMs: while its screen refresh may vary, it bogs down particularly badly on VM login screens (that are not set to a solid color) and any pages in Edge that have any sort of active content, and/or high color graphics. Similar problems when trying to access nested VMs in same Bastion session.
I did some testing/troubleshooting to try and find some setting that would resolve for this issue but at least within Bastion, was unable to find any:
Tests in Eastus/Westus/Centralus, all experienced the issue soon as connected via Bastion to the Azure-hosted VM (az801l07a-hv-vm)
As previously, desktop access in the VM can become passable after one manages to get logged in...but is at its absolute worst when accessing any page (in browser, in particular) where we have high-color graphics/active content.
Bastion: Is 'Basic' tier possibly throttled? Tested switching to 'Standard' tier but made no difference.
Enabling accelerated networking on both NICs had no apparent effect.
-Other networking settings within the VM looked OK to me, uncertain if there is any contributing factors to the issue from them.
The only workaround I could identify was to create a new public IP address & bind to az801l07a-hv-vm NIC1, create an 'AllowRDP' rule to allow inbound RDP connections only from the single IP address of my Lab VM, and then utilize mstsc.exe to connect. Note that I did this in each test (in same instance, with all previous config in place as before) immediately after experiencing abysmal Bastion performance, and then immediately validated that when using old-fashioned RDP w/mstsc.exe perf was fine.
The text was updated successfully, but these errors were encountered: