WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple

Update on Intel NUC 7th Gen (Kaby Lake) & ESXi 6.x

02.15.2017 by William Lam // 28 Comments

Intel just started shipping their i3 7th Gen (Kaby Lake) Intel NUCs and no surprise, Florian of virten.net has already gotten his hands on a unit for testing. The Intel NUCs is a very popular platform for running vSphere/vSAN-based home labs, especially for their price point and footprint. Last week, Florian discovered from his testing that the built-in network adapter on the 7th Gen NUC was not being detected by any of the ESXi installers and had published his findings here.

Since the Intel NUC is not an officially supported platform for ESXi, it does not surprise me that these sort of things happen, even if the NUC had a pretty good track record going back to the 5th Gen releases. Nonetheless, I reached out to Florian to see if he can provide me with a vm-support bundle and see if there was anything I could do to help.

A couple of Engineers took a look and quickly identified the issue with the Kabylake NIC (8086:15d8) but before getting to the solution, I did want to clarify something. The Kabylake NIC is actually NOT an officially supported NIC for ESXi and although it currently shows up in the VMware HCL, it is a mistake. I have been told the VMware HCL will be updated shortly to reflect this, apologies for any confusion that this may have caused.

Ok, so the great news is that we do have a solution for getting ESXi to recognize the built-in NIC on the 7th Gen Intel NUCs. The semi-bad news is that we currently do not have a solution in the short term for any released version of ESXi, as the fix will require an updated version of the e1000e Native Driver which will only be available in a future update of ESXi. I can not provide any timelines, but keep an eye on this blog and I will publish more details once they are available.

In the meantime, if you already own a 7th Gen NUC, there is a workaround which Florian has already blogged about here which uses the USB Ethernet Adapter VIB for the initial ESXi installation. If you are planning to purchase the 7th Gen NUC and would like to wait for folks to confirm the fix, then I would recommend holding off or potentially looking at the 6th Gen if you can not wait. Thanks to Florian and others who shared their experiences with the 7th Gen NUC and also to the VMware Engineers who found a quick resolution to the problem.

UPDATE (07/27/17) - The updated e1000e Native Driver that was included in ESXi 6.0 Update 3 is now included in ESXi 6.5 Update 1 which just GA'ed. You should be able to install ESXi without require any additional modifications to the latest Intel NUCs.

UPDATE (02/24/17) - An updated e1000e driver which contains a fix for 7th Gen NUC is now available as part of ESXi 6.0 Update 3, below are several options in how you can consume the driver.

[Read more...]

Categories // ESXi, Home Lab, Not Supported, vSphere 6.0, vSphere 6.5 Tags // Intel NUC, Kaby Lake, ne1000, ne1000e, vSphere 6.5

Exploring new VCSA VAMI API w/PowerCLI: Part 8

02.14.2017 by William Lam // 5 Comments

In Part 8, we are going to take a look how services are managed in a VCSA or PSC node which is provided by the vCenter Server Lifecycle Management system also referred to internally as vMon. You can interact with the vMon service using either the service-control utility which is only available via SSH or the VAMI APIs which are available remotely. As you probably have guessed, we will be using the VAMI APIs 🙂

VAMI UI Area of Focus

There is not a service view in the VAMI UI (https://[VCSA]:5480) for either the VCSA or PSC. However, this information is available as part of the VAMI information when logged into the vSphere Web Client by navigating to System Configuration->Nodes->Related Objects or System Configuration->Services.

VAMI APIs Used

  • GET /appliance/vmon/service
  • POST /appliance/vmon/service/start
  • POST /appliance/vmon/service/stop

PowerCLI Function

  • Get-VAMIService
  • Start-VAMIService
  • Stop-VAMIService

Sample Output

The Get-VAMIService will lists all available services for the given VCSA or PSC node that you are connected to. It provides the exact same output that you would see in the vSphere Web Client such as the name of the service, the current state, the health and whether the service is disabled or configured to start up automatically or manually.


The function also accepts a name parameter if you know the specific service you wish to query, for example here is the syntax for checking the Auto Deploy service which is named rbd:

Get-VAMIService -Name rbd

We can use the Start-VAMISerivce function and given a service name, we can start it as shown in the screenshot below.


Similialy, we can use the Stop-VAMISerivce function and given a service name to stop the service as shown in the screenshot below.

  • Exploring new VCSA VAMI API w/PowerCLI: Part 1
  • Exploring new VCSA VAMI API w/PowerCLI: Part 2
  • Exploring new VCSA VAMI API w/PowerCLI: Part 3
  • Exploring new VCSA VAMI API w/PowerCLI: Part 4
  • Exploring new VCSA VAMI API w/PowerCLI: Part 5
  • Exploring new VCSA VAMI API w/PowerCLI: Part 6
  • Exploring new VCSA VAMI API w/PowerCLI: Part 7
  • Exploring new VCSA VAMI API w/PowerCLI: Part 8
  • Exploring new VCSA VAMI API w/PowerCLI: Part 9
  • Exploring new VCSA VAMI API w/PowerCLI: Part 10

Categories // Automation, PowerCLI, vSphere 6.5 Tags // PowerCLI, vami, vcenter server appliance, vSphere 6.5

How to forward other VCSA 6.5 logs to remote syslog server?

02.09.2017 by William Lam // 6 Comments

As mentioned in my previous article (which I strongly recommend you review before continuing further), the VCSA 6.5 no longer uses syslog-ng as the syslog client and it has been replaced with rsyslog. This means the instructions outlined in my old article here is no longer valid on forwarding logs from a VCSA 6.5 system to a remote syslog server. Luckily, the process to forward logs within VCSA 6.5 is also pretty straight forward using rsyslog.

Disclaimer: This is not officially supported by VMware, please use at your own risk. For very large environments, forwarding additional logs can potentially impact the vCenter Server service, so please take caution in the logs you decide on forwarding and test in a lab environment before applying this across your environment.

To help provide a concrete example, I will be using a real world scenario that often comes up from customers on auditing failed vSphere Web Client login success/failures as well as SSO user creation, deletion and password changes. The following two log files provides us with this information which we will forward to our syslog server:

  • /var/log/vmware/sso/ssoAdminServer.log - Auditing SSO logins
  • /var/log/vmware/sso/vmware-identity-sts.log - Auditing SSO user changes

We will be making using of rsyslog Text File Input Module (imfile) which will allow us to process local log files in the VCSA.

[Read more...]

Categories // Automation, VCSA, vSphere 6.5 Tags // rsyslog, syslog, vSphere 6.5

  • « Previous Page
  • 1
  • …
  • 12
  • 13
  • 14
  • 15
  • 16
  • …
  • 27
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Ultimate Lab Resource for VCF 9.0 06/25/2025
  • VMware Cloud Foundation (VCF) on ASUS NUC 15 Pro (Cyber Canyon) 06/25/2025
  • VMware Cloud Foundation (VCF) on Minisforum MS-A2 06/25/2025
  • VCF 9.0 Offline Depot using Synology 06/25/2025
  • Deploying VCF 9.0 on a single ESXi host? 06/24/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025

 

Loading Comments...