WilliamLam.com

Search Results for: nested esxi

vSphere Datasets - New Virtual Machine Metadata Service in vSphere 8

by // 1 Comment

Since the early days of Virtual Center and ESX, the only method for creating and sharing arbitrary metadata between the vSphere Management layer and the guest operating system was to use either guest variables (guestinfo) or the OVF runtime environment.

While both of these capabilities have enabled a ton of interesting use cases and have even inspired creative solutions such as this, this, this, this and this to just name a few, it certainly has its challenges and nuances from an end user experience perspective.

For example, the persistency or the non-persistency of guest variables solely depended on when it was applied to a Virtual Machine and the power state it was in, which can be very frustrating to discover for the first time and the inconsistent behavior for end users. The lack of security and access control in both guest variables and the OVF runtime environment also means the metadata could easily be overwritten or removed by users in either the vSphere Management layer or guest operating system, making this challenging to scale for larger organizations.

This is why I am excited for vSphere 8 and the new vSphere Dataset feature!

[Read more...]

Closer look at vSphere Permissions for vSphere with Tanzu 

by // 3 Comments

Questions regarding vSphere Permissions for vSphere with Tanzu has been frequently brought up more lately and the majority of questions that I have seen, has primarily focused on the behavior of the vSphere UI Inventory. After taking a closer look and experimenting with a few permutations within my lab, I realized that most folks were simply focusing on what they were most familiar with, which is using the vSphere UI to interact with vSphere.

Although vSphere with Tanzu is tightly integrated with vSphere and the vSphere UI is certainly a primary interface, it is certainly not the only interface nor is it always the interface for end users like a developer. Depending on the needs of your end users and how your organization wishes to grant access to a vSphere Namespace, there are actually a few options that are available to you. In fact, users can interact with vSphere with Tanzu without ever logging into the vSphere UI and that is completely valid and may even be desirable for some organizations.

Note: The custom kubectl plugin for vSphere (kubectl-vsphere) which is needed to interact with vSphere with Tanzu can be downloaded by simply opening a browser (or use wget) to following URL: https://[SUPERVISOR-CLUSTER-IP]/wcp/plugin/[OS]-amd64/vsphere-plugin.zip, where OS is darwin, linux or windows (e.g. https://172.17.33.33/wcp/plugin/darwin-amd64/vsphere-plugin.zip)

Below are the results of my testing using the various vSphere Roles and Groups including the various behavior across the different consumption interfaces including the vSphere UI. To help better illustrate the results, I am also using some example personas, these are purely used as an example and may differ based on your organizational needs.

Persona: VI/Cloud Admin

In this scenario, the user is a vSphere Administrator and has the following memberships:

  • vSphere Role: Administrator
  • vSphere SSO Group: Administrators
  • vSphere Namespace: SSO User and/or Active Directory User

The user will be able to view and manage all vSphere infrastructure including the vSphere Namespaces and the respective workloads including TKG Workload Clusters and/or VMs via the VM Service.

Here is a summary of this users access:

[Read more...]

OVFTool 4.4.1 - Upload OVF/OVA from URL using upcoming "pull" mechanism

by // 12 Comments

I was helping a fellow colleague yesterday with an OVA question and I came to learn about an upcoming feature in the popular OVFTool utility that would allow for a new method of uploading a remote OVF/OVA to either a vCenter and/or ESXi endpoint.

Historically, when you upload an OVF/OVA whether that is stored locally or remotely from a URL, the data path will actually transfer through the system running the OVFTool between the source and destination, which is ultimately the ESXi host which performs the actual download. Although the OVF/OVA data is not actually stored on your local system, the traffic is proxied through your system and can add an unnecessary hop if the remote OVF/OVA URL can directly be accessed by ESXi host.

A new --pullUploadMode flag has been introduced in the latest OVFTool 4.4.1 release, which will allow ESXi host to directly download (pull) from the remote OVF/OVA URL, assuming it has connectivity. In addition to version of OVFTool, you will also need to have either ESXi 6.7 or 7.0 environment for this new feature to work.

Disclaimer: Although this feature is available in latest OVFTool release, it is still under development and should be considered a Beta feature in case folks are interested in trying it out.

Since the ESXi host is directly downloading from the remote source, there are two additional security verification that has already been implemented. The first is an additional vSphere Privilege called "Pull from URL" which is under the vApp section. Without this, you will get a permission denied error.


Secondly, in addition to specifying the new CLI option, you will also need to provide another flag called --sourceSSLThumbprint which should include the SHA1 hash of endpoint hosting the OVF/OVA. This is an additional verification to ensure the validity of the server hosting the OVF/OVA.

Here is an example of deploying my latest ESXi 7.0 Update 1 Virtual Appliance OVA which is remotely hosted. The quickest way to obtain the SHA1 thumbprint is simply opening browser to based URL which is https://download3.vmware.com/


You will need to replace the space with ":" (colon), so the final string should look like BA:C6:4E:D9:AD:D4:53:B5:86:5A:5D:70:36:CF:89:93:D1:6C:F9:63

Note: The SHA1 thumbprint example shown above is only valid as of Oct 2020, as TLS certificates are replaced periodically, the SHA1 hash will change.

Here is an example OVFTool command to deploy from the remote URL

ovftool \
--X:logFile="ovftool.log" \
--acceptAllEulas \
--allowAllExtraConfig \
--allowExtraConfig \
--noSSLVerify \
--sourceSSLThumbprint="B2:52:9E:4D:57:9F:EA:53:4D:A0:0B:7F:D4:7E:55:91:56:C0:64:BB" \
--name="Nested-ESXi-7.0-Update-1-Appliance" \
--datastore=sm-vsanDatastore \
--net:"VM Network"="VM Network" \
--pullUploadMode \
https://download3.vmware.com/software/vmw-tools/nested-esxi/Nested_ESXi7.0u1_Appliance_Template_v1.ova \
'vi://*protected email*:[email protected]/Primp-Datacenter/host/Supermicro-Cluster'

If we switch over to the vSphere UI, we should see a new task called "Download remote files" which indicates the new pull method is being leveraged. One thing to note is that because ESXi is now performing the download directly, progress may not be known by the OVFTool client, since it is not longer the source for the data transfer. Another thing to be aware of is that OVFTool itself has built-in retry logic in case there is a slight interruption during the data transfer with the current mechanisms. In the "pull" scenario, there is no retry by ESXi and so depending on connectivity, its possible deployments can fail and complete re-transfer would be required.