This is the VMware® NSX-T 2.4 & 2.5 Security Configuration Guide.This guide provides prescriptive guidance for customers on how to deploy and operate VMware® NSX-T in a secure manner.

 

Guide is provided in an easy to consume spreadsheet format, with rich metadata (i.e. similar to existing NSX for vSphere & VMware vSphere Security Configuration Guides) to allow for guideline classification and risk assessment.

 

Feedback and Comments to the Authors and the NSX Solution Team can be posted as comments to this community Post (Note: users must login on vmware communities before posting a comment).

 

Other related NSX Security Guide can be found @ https://communities.vmware.com/docs/DOC-37726

 

–The VMware NSX PM/TPM Team

Hello all, wondering if anyone can assist with a few questions. I recently noticed that when exporting VRNI recommended rules as CSV my VRNI seems to summarize physical machines into the CSV as “Other entities”, I’m reading that in order to import recommended rules into NSX I need to use XML exports and the exports have to be based on Security Groups or Application Tiers. A couple questions.

 

1. When we say security groups, do we mean NSX Security groups that VRNI is discovering?

2. When we say application-Tiers, do we mean VRNI configured application Tiers? If so what does this equate do in NSX upon import, do the “Tiers” get created in NSX as security groups?

3. What options are available for importing the XML items into NSX? Is it raw API only, or is there a UI or GUI tool?

 

Thanks in advance.

Looking for suggestions on how people are applying patches…actually handling the reboot post patch with multiple connection servers. They can be temperamental if not rebooted in order.

 

We have heard differing methods for handling reboot:

1. Shut them all down, reboot 1st, wait for it to come all the way up…reboot 2nd, rinse, repeat.
2. Shut them all down, power them all up at the same time

 

Our patch schedule is 1 connection server is considered ‘DEV’ and gets patched(and rebooted) a week prior to the other two, considered ‘PROD’.

 

We recently ran into these servers having sync errors. We were scratching our heads trying to figure out ‘what changed’ and the subject of patching (the reboot) came up.

 

How are you handling the ‘care and feeding’ of these temperamental systems?

 

Thank you and drive fast, take chances.

Workstation Pro 15.0.3

My host crashed over the weekend and now when I try to start my VM I get the error in the title for each of the VM disks and then it ends with a message that the VM failed to start. I’m new to this world so I’m not sure where to begin looking. There are folders inside the VM folder with the name of each disk and then ending in .lck I’m thinking these might be locks. Do I just need to delete those folders?

Hello,

 

I couldn’t find a relevant topic, that’s why I’ve decided to ask this question. How to fix the VCSA 6.7 UI installer? it opens a white page, and the buttons for “Install”, “Restore”, etc. aren’t there, but it used to work fine. I’ve cleared all relevant data from the %appdata%, %programdata%, and even cleared the Windows temp, but didn’t fix it.

 

I’m using Windows 10, it also occur on a Windows Server 2016 when I launch it for the third time.

 

Attached a screenshot.

 

Thanks,

I have been tried for a month to investigate on the GPU passthrugh issue of 6.7, Here is what I found.

 

Motherboard: MX32-L40 （a Gigabyte Serverboard which officially announced support ESXi 6.5, All ESXi passthrough requirements are meet by this MB）

VM OS: Windows 10 1809 Oct

ESXi Version: ESXi6.5u2(with latest patch), ESXi6.7u1(with latest patch)

GPU: I tried both AMD RX590 and Nvidia 1660Ti

Passthroughed Devices: All sub devices of the GPU, including HDMI audio and related bus.

 

Issue:

Basically,

if I start the VM the first time after ESXi host started, the GPU just works like a charm.

If I restart or stop/start the VM, the GPU device stopped working with a warning in device manager, error code 43.

If I disable the GPU before a VM restart/stop-start in device manager, then I’m able to re-enable the GPU after the VM reboot.

 

First, I’m pretty sure all of the following tweak doesn’t help:

 

1. UEFI or Legacy boot of ESXi host
2. UEFI or BIOS boot of Windows 10 VM
3. ESXi 6.5(with latest patch) or ESXi 6.7(with latest patch)
4. AMD Rx590 or Nvidia 1660 Ti
5. pciPassthru.use64bitMMIO
6. hypervisor.cpuid.v0
7. pciHole.start/end
8. svga.present

 

I tried them one by one, with ALL combinations, which took me several days, since server MBs are really slow to boot.

The conclusion is the same,

If it’s the first time starting the VM after ESXi boot, the GPUs just works. If I reboot/stop-start the VM, then the GPUs stopped working with error code 43.

 

Then I realized it’s a PCIe resetting issue. so I tried the following /etc/vmware/passthrough.conf combinations:

 

# NVIDIA

 

10de  ffff  link   false

10de  ffff  bridge   false

10de  ffff  d3d0   false

10de  2182  link   false

10de  2182  bridge   false

10de  2182  d3d0   false

 

# AMD Video Card

 

1002 ffff link false

1002 ffff bridge false

1002 ffff d3d0 false

 

It took me a whole week to try ALL those combinations. Finally, I found that, ONLY ONE combination works for me:

• ESXi 6.5
• 10de  2182  d3d0   false

 

Then I tried to upgrade the ESXi to 6.7u1 with the SAME settings, it just doesn’t work anymore.

 

I found something interesting in the log. When resetting the PCIe devices,

 

ESXi 6.5 resets them ONE BY ONE, with 4 seconds interval:

 

2019-03-07T05:56:29.586Z| vcpu-0| I125: UHCI: HCReset

2019-03-07T05:56:29.593Z| vcpu-0| I125: PCIPassthru: Resetting Device at 0000:50:00.0    // This is my GPU

2019-03-07T05:56:33.603Z| vcpu-0| I125: PCIPassthru: Resetting Device at 0000:50:00.1    // This is my GPU

2019-03-07T05:56:37.613Z| vcpu-0| I125: PCIPassthru: Resetting Device at 0000:50:00.2    // This is my GPU

2019-03-07T05:56:41.622Z| vcpu-0| I125: PCIPassthru: Resetting Device at 0000:50:00.3    // This is my GPU

2019-03-07T05:56:45.632Z| vcpu-0| I125: PCIPassthru: Resetting Device at 0000:72:00.0

2019-03-07T05:56:49.692Z| vcpu-0| I125: NVME-PCI: PCI reset on controller nvme0.

 

while ESXi 6.7 resets them in a batch, without intervals:

 

2019-03-07T09:08:05.219Z| vcpu-0| I125: UHCI: HCReset

2019-03-07T09:08:05.223Z| vcpu-0| I125: PCIPassthru: Resetting Device at 0000:50:00.0    // This is my GPU

2019-03-07T09:08:05.224Z| vcpu-0| I125: PCIPassthru: Resetting Device at 0000:50:00.1    // This is my GPU

2019-03-07T09:08:05.225Z| vcpu-0| I125: PCIPassthru: Resetting Device at 0000:50:00.2    // This is my GPU

2019-03-07T09:08:05.225Z| vcpu-0| I125: PCIPassthru: Resetting Device at 0000:50:00.3    // This is my GPU

2019-03-07T09:08:05.227Z| vcpu-0| I125: PCIPassthru: Resetting Device at 0000:72:00.0

2019-03-07T09:08:09.258Z| vcpu-0| I125: NVME-PCI: PCI reset on controller nvme0.

 

There must be some different between 6.5 and 6.7 the way they reset the PCIe devices.

Anyone know what’s the difference and how to make it work in 6.7?

I’m doing a fresh install on a Windows 2019 server of Vcenter 6.5d.

The installation keeps failing at the VCSServiceManager with a 1603 error.

I’ve seen lots of posts on this before with upgrading Vcenter, but not on clean installations. 

 

The last steps I did was start from scratch with a new OS (with .net 3.5), new SQL build and a new Vcenter ISO download, but I’m still getting that 1603 error on VCSServiceManager.

I then installed VCSSServiceManager.msi first, then did the Vcenter installation and that completed “successfully” but not all services were installed and there was no Vcenter web client.

So now I’m back to square one.

 

I opened a support case and they mentioned it was because of a firewall rule.  I checked, I didn’t install any of our antivirus software yet and the Domain/Public/Private Windows firewalls are on disabled.  I’m still working with support, but getting no where as far as a solution goes.