Follow

Alright, I have read a bunch of best practice guides on setting up storage and networks for a Hyper-V cluster. The issue is, hardly any of them explain
how to accomplish this, step by step.

I have one iSCSI target, with two Hyper-V host iSCSI initiators connecting to it. The iSCSI virtual disk has been set up as a CSV for Hyper-V storage. I understand that I need to have this iSCSI storage communication running on a dedicated network. I also
understand that I should enable/configure MPIO for iSCSI storage communication as well. I only have one physical NIC at this time to configure, and an external virtual switch created in Hyper-V. Currently, I have three networks recognized by my cluster, each
in their own subnet:

- ‘VDI-Switch’ - the name of the external virtual switch used for management communications and virtual machine access. Untagged.

- ‘Cluster’ network for heartbeat, etc. communications using vlan ID 11

- ‘Live Migration’ network using vlan ID 12

How do I make sure that iSCSI has it’s own dedicated storage communications network, and that MPIO is also enabled?

The best practice guides that I have read through are here, here, and here.

Read full post . . . .

Follow

Hello,

i have two nodes (WS2019 Datacenter) connected directly to storage array via iSCSI 10G SFP+

when im trying to validate cluster, i get error:

Network interfaces NODE1 - NIC 6 iSCSI B0 and NODE2 - NIC 5 iSCSI A2 are on the same cluster network, yet address 10.10.201.5 is not reachable from 10.10.201.6 using UDP on port 3343.

its not reachable because of directly attached to storage array.

Do you have any idea how to resolve it without using switch ?

Greetings

Read full post . . . .

Follow

Hi,

I have a 2008R2 guest server hosted on the 2012R2 hypervisor. Until now version 6.3.9600.16384 of Integration Services was installed on it. Then I installed updates on the hypervisor (2012R2). After that I installed the new version of Integration Services
on guest systems (6.3.9600.19456), but after restart the error 0xc0000428 vmbus.sys "Windows cannot verify the digital signature for this file" occur and the server did not start. Of course I had a snapshot so I did a revert. Since the guest
server (2008R2) did not have all updates installed, I installed them with Windows Update. After that I reinstalled the latest Integration Services again and this time there were no problems - 2008R2 starts up properly.

My question is: which update may be necessary before installing the latest Integration Services? I am asking because I have other servers on which I cannot install all updates and I would like to install only those that will allow me to upgrade Integration
Services.

Read full post . . . .

Follow

Hi,

We are having som network issues regarding our Nested Virtualization setup.

* The Physical host have no problem regarding retransmission of TCP packages to the network
* The Nested Virtualization host have no problem regarding retransmission of TCP packages to the network
* The VM on the Nested Virtualization host have problem regarding retransmission of TCP packages to the network (3-6% retransmission - the rest of the packages is behaving just fine).

Do any of you guys know why this is and how to fix it?

Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Read full post . . . .

Follow

After turning on hyper-v, the computer starts to blue screen frequently, sometimes the computer will black screen and then restart

Read full post . . . .

Follow

Hi,

We are using HNS to support container Networking. The vSwitch Extension is Open vSwitch Extension. When I invoke HNS.psm1 to attach an existing HNS Endpoint to a container, the request doesn’t return. The process never stops, even if I input ctrl+Z
or ctrl+C, no response returns. The issue also happens in deleting HNS Endpoint or deleting HNS Network.

It is found in Windows Server 2019(1809), and all possible KBs are updated on March 16th, 2020.

Please help give some guidance on such issue.

Thanks,

Wenying

Read full post . . . .