In your first big script block after installing DCB, I notice you are not setting the NetQOSPolicy using the windows Template of “cluster” – you have written “New-NetQosPolicy “Cluster” -PriorityValue8021Action 7″
According to this fellow here – and I confirmed myself – link removed for wordpress approval reasons but he’s darrylvanderpeijl – you might consider wanting to use the flag -Cluster when you are making that New-NetQOSPolicy.
Here’s the difference in results if you run Get-NetAdapterQOS cmdlet with that -Cluster flag, vs without it. I apologize in advance as the formatting will probably be pretty compacted and not tab/space separated, but hopefully will get the gist across.
Without it:
Name : SLOT 2 Port 1
Enabled : True
Capabilities : Hardware Current
——– ——-
MacSecBypass : NotSupported NotSupported
DcbxSupport : None None
NumTCs(Max/ETS/PFC) : 4/4/4 4/4/4
OperationalTrafficClasses : TC TSA Bandwidth Priorities
— — ——— ———-
0 ETS 49% 0-2,4-6
1 ETS 50% 3
2 ETS 1% 7
OperationalFlowControl : Priorities 3,7 Enabled
OperationalClassifications : Protocol Port/Type Priority
——– ——— ——–
Default 7
NetDirect 445 3
With it:
Name : SLOT 2 Port 1
Enabled : True
Capabilities : Hardware Current
——– ——-
MacSecBypass : NotSupported NotSupported
DcbxSupport : None None
NumTCs(Max/ETS/PFC) : 4/4/4 4/4/4
OperationalTrafficClasses : TC TSA Bandwidth Priorities
— — ——— ———-
0 ETS 49% 0-2,4-6
1 ETS 50% 3
2 ETS 1% 7
OperationalFlowControl : Priorities 3,7 Enabled
OperationalClassifications : Protocol Port/Type Priority
——– ——— ——–
Default 0
TCP/UDP 3343 7
NetDirect 445 3
Notice that when -Cluster flag is used, how we have an operation classification of “TCP/UDP 3343 7” – I apologize if I am making a mistake, I’m really new at this and trying to read all the docs on RDMA and the PFC that is recommended to go with it. Would love to hear if you agree with the other website’s usage of -Cluster flag, and if you disagree, your take on it! Cheers and thanks for writing this up!
]]>Yes correct
]]>I am new to SCVMM and I need to add a host group to a logical network site, is this as simple as just editing the logical network and ticking the host group?
I am unsure if doing this affects the clouds in anyway
]]>Thank you Jan
One more question, after the reboot of the cluster were you able to continue patching, without this issue resurfacing ?
No this was on Azure Stack HCI 21H2 but the same things will apply to 2022 as well.
]]>I have a similar issue after installing februar update to my 4 node 2022 s2c cluster.
The first node I updated is stuck on stopping maintenance mode, so I stopped updating 🙂
just to confirm was this a cluster of 2022 windows servers ? I am not very excited to reboot the whole thing with over 50 production vm’s on it.
]]>I had a similar issue when using Enable-StorageMaintenanceMode on a Node of a 2-Node-Cluster in preparation of an OS upgrade : the Node’s disks were stuck in “{Starting Maintenance Mode…..}”
I found your post and thought “Before shutting down all those VMs, lets try a refresh on the active Node, this should suffice if cached information is the problem”, and I simply did a Refresh on Storage -> Disks in Failover Manager on the active Node….
And it worked – so thanks for putting me on the right track…
]]>Yes you can. But if it’s in use i don’t think you can. Id rather create a new logical network for it.
]]>You tried to manually install the agent on the host, then add the host to VMM? That one works for me and everyone else i have spoken with.
Im doing a new VMM 2022 upgrade in a months time. Il update once i have some feedback on that one.
]]>No this was internal MVP Talks. And it’s related to the deployment of the agent to AzHCI.
I have not recived a OK for it yet. Il try and ping the VMM team about it.
]]>No we think we found the issue as i was running a pre release of 2019 UR3 and that was the cause of it.
]]>I ran a Process Monitor against the system while the job was running and then filtered out all the unrelated noise. Finally, I saw a couple lines of interest (one pair of messages):
Process Name = VMMService.exe
Class: FileSystem
Operation = CreateFile
Result: PATH NOT FOUND
Path: C:\Program Files\Microsoft System Center\Virtual Machine Manager\agents\I386\10.22.1287.0\msiInstaller.exe
Process Name = VMMService.exe
Class: FileSystem
Operation = CreateFile
Result: NAME NOT FOUND
Path: \\server-name.domain.tld\ADMIN$\msiInstaller.exe
I verified that the PID was running under the SCVMM RunAs account I was using to send the update agents. It’s interesting it’s trying to locate an i386 version of the installer files and in fact there is no such installer source path on my SCVMM server. I also saw a couple lines complaining about inability to properly talk to the HV server I was pushing the updates to.
I switched over to directly entering creds of another administrative user that is a full domain admin and pushed the update again. This time it worked and the process looked a little different:
Process Name = VMMService.exe
Class: FileSystem
Operation = CreateFile
Result: Success
Path: C:\Program Files\Microsoft System Center\Virtual Machine Manager\agents\amd64\10.22.1287.0\msiInstaller.exe
Process Name = VMMService.exe
Class: FileSystem
Operation = CreateFile
Result: Success
Path: \\server-name.domain.tld\ADMIN$\msiInstaller.exe
This time it seems to know it needs to send the 64bit version of the binary and then successfully does so.
Maybe check this on your side to see if it’s the same issue.
]]>How do you know this?
Is there some VMM Community im not aware of that i could participate in? Its a lonely problem solving with SCVMM sometimes…
]]>