Forum Widgets
Latest Discussions
AKS on AzureLocal: KMSv1 -> KMSv2
Hey, quick question on AKS Arc — we're running moc-kms-plugin:0.2.172-official on an Arc-enabled AKS cluster on Azure Local and currently have KMSv1=true as a feature gate to keep encryption at rest working. KMSv1 is deprecated in 1.28+ and we want to migrate to KMSv2 before it gets removed. Since moc-kms-plugin is a Microsoft-managed component we can't just swap it out ourselves. A few questions: Does version 0.2.172 already support the KMSv2 gRPC API, or is that coming in a later release? Is there a supported migration path for AKS Arc specifically, or does this come automatically through a platform update? Any docs or internal guidance you can point us to? Thanks!
RDMA (RoCE) Test Failed over different Subnet
Hello Everyone, Let's say pSMBNIC1 and pSMBNIC2 are the names of the NICs to be used for RDMA on each node of a 3-node cluster. IP address assignments are as follows: pSMBNIC1 = 192.168.207.31 (N1), 192.168.207.32 (N2), 192.168.207.33 (N3) pSMBNIC2 = 192.168.206.51 (N1), 192.168.206.52 (N2), 192.168.206.53 (N3) RDMA Test is Successful when I run for the following scenarios: From pSMBNIC1 of N1 to pSMBNIC1 of N2 (192.168.207.32) and pSMBNIC1 of N3 (192.168.207.33) From pSMBNIC1 of N2 to pSMBNIC1 of N1 (192.168.207.31) and pSMBNIC1 of N3 (192.168.207.33) From pSMBNIC1 of N3 to pSMBNIC1 of N1 (192.168.207.31) and pSMBNIC1 of N2 (192.168.207.32) From pSMBNIC2 of N1 to pSMBNIC2 of N2 (192.168.206.52) and pSMBNIC2 of N3 (192.168.206.53) From pSMBNIC2 of N2 to pSMBNIC2 of N1 (192.168.206.51) and pSMBNIC2 of N3 (192.168.206.53) From pSMBNIC2 of N3 to pSMBNIC2 of N1 (192.168.206.51) and pSMBNIC2 of N2 (192.168.206.52) However, RDMA Test fails with "ERROR: RDMA traffic test FAILED: Please check ERROR: a) physical switch port configuration for Priority Flow Control. ERROR: b) job owner has write permission at 192.168.206.51 \C$" for the following scenarios: From pSMBNIC1 of N1 to pSMBNIC2 of N2 (192.168.206.52) and pSMBNIC2 of N3 (192.168.206.53) From pSMBNIC1 of N2 to pSMBNIC2 of N1 (192.168.206.51) and pSMBNIC2 of N3 (192.168.206.53) From pSMBNIC1 of N3 to pSMBNIC2 of N1 (192.168.206.51) and pSMBNIC2 of N2 (192.168.206.52) From pSMBNIC2 of N1 to pSMBNIC1 of N2 (192.168.207.32) and pSMBNIC1 of N3 (192.168.207.33) From pSMBNIC2 of N2 to pSMBNIC1 of N1 (192.168.207.31) and pSMBNIC1 of N3 (192.168.207.33) From pSMBNIC2 of N3 to pSMBNIC1 of N1 (192.168.207.31) and pSMBNIC1 of N2 (192.168.207.32) This means that RDMA Tests are passing for the same subnets but failing when run across different subnets. Is it normal? I have already enabled the PFC... But, even if the PFC is not enabled, then how tests are passing for the same subnet? Please guide... Thank you in anticipation.Backup Restore of AKS and SQL MI running on Azure Stack HCI
Hi Everyone, I want to know how to back up AKS & SQL MI running on Azure Stack HCI. Would appreciate any insights or recommended solutions that can effectively address data protection needs within the context of this hybrid environment? Regards Aj
Issue with Hyper-V VM on Tagged VLAN – Traffic Reaches Local Hosts but Not External Networks
Hi everyone, I’m having an issue getting a Hyper-V VM to work correctly when using a tagged VLAN interface. I have a test VM configured with a trunk port and a tagged VLAN. Here is the configuration I’m using: Set-VMNetworkAdapterVlan -VMName "testvlan" -Trunk -NativeVlanId 2 -AllowedVlanIdList "4" The strange part is this: When the VM is on VLAN 4 (tagged), it can reach other resources on the same VLAN as long as those resources are running on the same Hyper-V host. But if the target resource is outside the Hyper-V host, the VM cannot reach it at all. The hardware vendor has already ruled out any issue with the top-of-rack switches interconnecting the hosts. If I reconfigure the VM’s network adapter in access mode on the same VLAN, then all traffic works normally and the VM can reach resources outside the host without any problem. So it seems that traffic leaves the host correctly only when the adapter is in access mode, not when using a trunk with VLAN tagging. Has anyone seen this behavior before or has suggestions on what to check next?
Azure Local
i am trying to install Azure local on nested Hyper-V VM as test environment, 1 DC, 1 HCI VM and unfortunately i am stuck with an error: "Type 'ValidateArcIntegration' of Role 'EnvironmentValidator' raised an exception: { "ExceptionType": "text", "ErrorMessage": "The provided account MSI@50342 does not have access to subscription ID \"7187cfd2-689c-4918-b43b-6e767d2bc1eb\". Please try logging in with different credentials or a different subscription ID. If a subscription is not specified, please check the configs by `Get-AzConfig`"Error No File
I have tried to deploy the Azure Local cluster based on Stack HCI, but are currently stuck on the Creating Cluster portion. However the fault it gives is very unclear and says there is a network configuration error however All previous steps where succesfull including setting up networking where I assume it would have failed if it was a networking issue. The name of the cluster would be something else if I where to configure it manually but this name comes from Azure and was validated there. Error: Type 'ConfigCluster' of Role 'Cluster' raised an exception: Check the spelling of the cluster name. Otherwise, there might be a problem with your network. Make sure the cluster nodes are turned on and connected to the network or contact your network administrator. at SetClusterLiveDumpPolicy, C:\NugetStore\Microsoft.AzureStack.Fabric.Storage.SCPSModule.10.2507.1001.1000\content\CloudDeployment\Classes\Cluster\Cluster.psm1: line 898 at ConfigCluster, C:\NugetStore\Microsoft.AzureStack.Fabric.Storage.SCPSModule.10.2507.1001.1000\content\CloudDeployment\Classes\Cluster\Cluster.psm1: line 322 at <ScriptBlock>, C:\CloudDeployment\ECEngine\InvokeInterfaceInternal.psm1: line 163 at Invoke-EceInterfaceInternal, C:\CloudDeployment\ECEngine\InvokeInterfaceInternal.psm1: line 158 at <ScriptBlock>, <No file>: line 50
ASH Nvidia Tesla T4 GPU Driver issues
I have a Windows 2019 server running on Azure Stack Hub. For some reason we cannot get the Nvidia Tesla T4 GPU driver to work on Windows. In the same set up, running a Linux server, we can get the GPU driver to work. The error says "Windows has stopped this device because it has reported problems (Code 43). Anyone have any ideas? The hardware underneath is Dell.
Azure Stack HCI 23h2 upgrade & Azure local Resource
Good evening, After upgrading from 22H2 to 23H2, we encountered an issue where the Azure Local resource in the Azure portal appears as "not connected recently." Additionally, we are not seeing the "Your cluster can be upgraded to the latest version" option, likely due to this connection issue. Despite successful connectivity tests and extensive troubleshooting, the resource remains unsynchronised with Azure. As a result, we tried deleting the Azure Local resource and re-registering the nodes. Now, while both nodes are successfully registered and connected to Azure and passing the Invoke-AzStackHciUpgradeValidation , we are unable to find a way to re-register the Azure Local resource to proceed with the "Install the solution upgrade via Azure portal" step. The only option I see is going through the "Deploy Azure Local" process in Azure Arc. However, I believe this would overwrite existing settings and VMs, causing significant disruption—especially since this is a production cluster upgraded from 22H2. Is there a way to re-register the cluster and restore the Azure Local resource using existing settings, so we can proceed with deploying the rest of the solution upgrade via the Azure portal? Any guidance would be greatly appreciatedNetworkATC Stuck on Validating
After migrating our three-node Azure Stack HCI cluster to intent-based networking with network ATC, the configuration status for some of the intents remains in the "Validating" status. I have two intents: One management and compute. One storage. I'm not sure how to troubleshoot why the configuration status doesn't progress to "Success" status. Fortunately, the cluster is operating normally, but I fear something must be wrong. A cluster validation test doesn't indicate any issues. All nodes are running 10.0.25398 Get-NetIntentStatus | select IntentName, Host, ConfigurationStatus, ProvisioningStatus | ft IntentName Host ConfigurationStatus ProvisioningStatus ---------- ---- ------------------- ------------------ storage dun-s-hci1 Success Completed storage dun-s-hci2 Success Completed storage dun-s-hci3 Success Completed management_compute dun-s-hci1 Validating management_compute dun-s-hci2 Validating management_compute dun-s-hci3 Validating
