vSphere Adding iSCSI Storage

vSphere Adding iSCSI KB ID 0001378

Problem

iSCSI storage is nice and cheap, so adding iSCSI 10/1Gbps storage to your virtual infrastructure is a common occurrence.

vSphere Adding iSCSI Solution (vSphere 7/8)

Add a Software iSCSI Adaptor: Select the host > Configure > Storage Adapters > Add > Software iSCSI adaptor > OK.

After a few seconds you should see it appear at the bottom of the list.

Create a vSwitch and VMKernel:If you already have this configured you can skip this section, but basically you need a vSwitch, with a VMKernel interface (that has an IP address on it that can ‘see’ your iSCSI device), and then you need to connect a physical NIC from that vSwitch the iSCSI network (or VLAN).

With the host still selected > Configure > Virtual Switches > Add Networking.

.

VMKernel Network Adapter > Next.

New Standard Switch > Set the MTU to 9000 to enable jumbo frames > Next.

Note: Make sure the physical switches you are connecting to also support Jumbo Frames. Each vendor will be slightly different to configure.

THIS IS CONFUSING: Select the NIC you want to add the the vSwitch, and then ‘Move Down‘ so that it is listed in Active Adapters > Next.

Give the switch a sensible name (like iSCSI) > Next.

Define the IP address of the VMKernel (this needs to be able to see the iSCSI Target IP addresses) > Next.

Note: Don’t worry about the default gateway, it will display the default gateway of the managment network, that’s fine, unless you need to route to the iSCSI devices).

Review the settings > Finish.

You should now have a new vSwitch for iSCSI.

vSphere Adding iSCSI Storage: Create Port Binging

Back on the Storage Adapters tab > Select the iSCSI adapter > Network Port Binding > Add.

Select the one you’ve just created > OK.

vSphere Adding iSCSI Storage: Add iSCSI Target

Dynamic Discovery > Add.

Add in the iSCSI Target IP for your storage device/provider > OK.

At this point it’s a good idea to do a full storage rescan.

No Storage Has Appeared? Remember at this point your iSCSI storage device probably needs to ‘allow’ this ESX server access to the storage before it will either appear (if it’s already been formatted as VMFS and is in use by other hosts) or if it’s the first host that needs to connect to format the datastore as VFMS.

How this is done varies from vendor to vendor.

If you need to add the storage manually > Host > Storage > New Datastore.

vSphere Adding iSCSI Solution (vSphere 5/6)

Add a Software iSCSI Adaptor: Select the host > Configure > Storage Adaptor > Add > Software iSCSI adaptor.

After a few seconds you should see it appear at the bottom of the list.

Create a vSwitch and VMKernel:If you already have this configured you can skip this section, but basically you need a vSwitch, with a VMKernel interface (that has an IP address on it that can ‘see’ your iSCSI device), and then you need to connect a physical NIC from that vSwitch the iSCSI network (or VLAN).

Note: You can add a port group to an existing switch, (or use a distributed switch!) Here I’m using a standard vSwitch and keeping my storage on its own vSwitch.

With the host still selected > Configure > Virtual Switches > Add.

VMware Kernel Adaptor > Next > New Standard Switch > Next > Add in the Physical NIC that’s connected to your iSCSI network > Next.

Give the VMKernel port a name (i.e. Storage-iSCSI) > Next > Put in the IP details* > Next > Finish.

*Note: You may need to add a gateway if your iSCSI device is on another network.

Jumbo Frames Warning: Edit the properties of the switch and set it’s MTU to 9000 to allow for jumbo frames.

vSphere Adding iSCSI Storage, make sure the physical switches you are connecting to also support Jumbo Frames. Each vendor will be slightly different in my case the switches are Cisco Catalyst 3750-X’s so I just need to enable jumbo frames universally on the switch (which requires a reload/reboot!)

Allow Jumbo Frames Cisco Catalyst 3750-X

Execute the following commands;

[box]

Petes-Switch#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Petes-Switch(config)#system mtu jumbo 9198
Changes to the system jumbo MTU will not take effect until the next reload is done

Then Reboot/Reload the Switch and Check

Petes-Switch#show system mtu

System MTU size is 1500 bytes
System Jumbo MTU size is 9198 bytes
System Alternate MTU size is 1500 bytes
Routing MTU size is 1500 bytes

[/box]

vSphere Configure iSCSI: Back on your vCenter, we need to ‘Bind’ the VMKernel port we created above, to our Software iSCSI adaptor. With the host selected > Configure > Storage Adaptors > Select the iSCSI Adaptor > Network Port Binding > Add.

Select the VMKernel Port  > OK.

Note: If you can’t see/select anything, make sure each iSCSI port group is set to use ONLY ONE physical NIC, (i.e. move the others into ‘unused’). That’s on the port group properties NOT the failover priority of the vSwitch.

Add an iSCSI Target to vSphere: With the iSCSI Adaptor still selected > Targets Add.

Give it the IP address of your iSCSI device.

At this point, I would suggest you perform a ‘Storage Rescan’.


Ensure ALL HOSTS, have had the same procedure carried out on them. Then (assuming you have configured your iSCSI device), presented the storage, and allowed access to it from your ESX hosts. Right click the Cluster > Storage > New Datastore > Follow the instructions.

IBM Storagewize v3700 iSCSI 

This article is just for configuring the VMware side, but just as a placeholder, (and to jog my memory if ever I put in another one.) The process is.

1. iSCSI IP addresses, Note: these are under Settings > Network > Ethernet Ports. (Not iSCSI confusingly.) 

2. Create the Hosts (Note: you can copy the iqn in from vCenter).

 

3. Create MDiscs (RAID groups) from the available disks, Note: Global Spares are allocated here.

4. Create a Pool, I don’t really see the point of these, but you need one to create a volume.

5. Create the Volumes, which you will present to the Hosts, then create host mappings.

 

Related Articles, References, Credits, or External Links

vSphere ESX – Configure Buffalo Terastation 5000 as an iSCSI Target

The Great ‘Cloud Repatriation’

Cloud Repatriation KB ID 0001859

Cloud Repatriation The Great Cloud Migration Reversal

In the fast-paced world of technology, trends often come and go with dizzying speed. One such trend that took the business world by storm was the mass migration to public cloud environments. For years, companies embraced the promise of agility, scalability, and cost-effectiveness offered by the public cloud. However, recent surveys and industry reports indicate a significant shift in this narrative—a growing number of organizations are repatriating their workloads from the public cloud back to on-premises infrastructures. What’s driving this reversal, and what does it mean for the future of cloud computing?

According to the DC Cloud and AI Adoption Survey dating as far back as 2018, a staggering 80% of customers expressed their intentions to repatriate workloads from public cloud environments. This sentiment has only strengthened over time. Citrix’s recent findings further illuminate this trend, reporting that 25% of organizations surveyed in the United Kingdom have already moved half or more of their cloud-based workloads back to on-premises infrastructures. These statistics paint a clear picture of a paradigm shift in cloud adoption strategies.

One of the primary catalysts for this repatriation movement is cost. While the public cloud initially lured businesses with promises of lower operational expenses, many have found themselves grappling with unexpected costs and complex pricing structures. As organisations delve deeper into their cloud usage, they often discover that the anticipated savings are elusive, overshadowed by hidden fees and overprovisioning. The allure of agility, while undeniable, is no longer enough to offset the financial concerns associated with public cloud services.

Moreover, the recent acquisition of VMware by Broadcom has raised concerns, particularly among small businesses, about the future of their cloud infrastructure. With consolidation in the industry, smaller players may find themselves at the mercy of larger corporations, prompting them to explore alternative solutions such as edge computing or investing in their own on-premises infrastructure.

Another significant factor contributing to the repatriation trend is service reliability. While public cloud providers tout impressive uptime guarantees, the reality is that even the largest hyperscalers are not immune to outages. When a major cloud service goes down, the impact can be catastrophic for businesses reliant on that infrastructure. Clients often feel powerless and insignificant during these outages, underscoring the importance of reliability and customer-centric service.

Storage costs also play a pivotal role in the decision to repatriate workloads. While public cloud providers offer convenient storage solutions, the costs can quickly escalate, especially for organizations with large volumes of data. Hybrid cloud, private cloud, or outsourcing to local providers offer more cost-effective alternatives, with the added benefit of greater control over data management and security.

In conclusion, the pendulum of cloud adoption is swinging back towards on-premises infrastructures as organizations reevaluate their priorities and weigh the trade-offs of public cloud services. While the public cloud undoubtedly revolutionized the way we approach IT infrastructure, its limitations and shortcomings have prompted a reexamination of cloud strategies. As businesses seek to optimize costs, enhance reliability, and regain control over their data, the trend of cloud repatriation is likely to continue gaining momentum in the years to come.

Cloud Repatriation: Client Challenges

Undertaking cloud repatriation poses several challenges for clients. These challenges can vary depending on factors such as the size of the organization, the complexity of their IT landscape, and their specific requirements.  Common challenges facing clients undertaking cloud repatriation:

  • Data Transfer and Migration: Moving data and applications from the public cloud to on-premises infrastructure or alternative cloud environments can be a complex and time-consuming process. Clients must carefully plan and execute data transfer and migration strategies to ensure minimal disruption to their operations and data integrity.
  • Integration and Compatibility: Workloads that were designed to run in a public cloud environment may have dependencies on cloud-specific services or technologies. Clients may encounter challenges when integrating these workloads with their on-premises infrastructure or alternative cloud solutions, particularly if there are compatibility issues or differences in architecture.
  • Resource Allocation and Capacity Planning: Repatriating workloads requires clients to allocate sufficient resources and capacity within their on-premises infrastructure to accommodate the migrated applications and data. Proper capacity planning is essential to ensure optimal performance and scalability without over-provisioning or underutilizing resources.
  • Skill Gaps and Training: Managing on-premises infrastructure or alternative cloud environments often requires different skill sets compared to managing public cloud services. Clients may face challenges related to skill gaps among their IT staff and the need for training or hiring resources with expertise in areas such as infrastructure management, networking, and security.
  • Security and Compliance: Security and compliance considerations are paramount when repatriating sensitive data and applications from the public cloud. Clients must ensure that their on-premises infrastructure or alternative cloud solutions meet the necessary security standards and compliance requirements, including data protection, access controls, and regulatory mandates.
  • Cost Management: While cost savings may be a driving factor behind cloud repatriation, clients must carefully evaluate the total cost of ownership (TCO) associated with migrating workloads back on-premises or to alternative cloud solutions. This includes not only the direct costs of infrastructure, but also factors such as licensing, maintenance, and operational expenses.
  • Service Levels and Performance: Clients may have become accustomed to the scalability and performance benefits of public cloud services and expect similar levels of service from their on-premises infrastructure or alternative cloud solutions. Ensuring that the repatriated workloads meet performance requirements and service level agreements (SLAs) can be a challenge, particularly in highly dynamic or resource-intensive environments.
  • Vendor Lock-In and Flexibility: Repatriating workloads from a specific public cloud provider may involve mitigating vendor lock-in and ensuring flexibility to migrate between different environments in the future. Clients should carefully evaluate vendor dependencies and consider strategies for maintaining portability and avoiding vendor lock-in when repatriating their workloads.

To summarise clients undertaking cloud repatriation face a range of challenges related to data migration, integration, resource allocation, skill gaps, security, cost management, service levels, and vendor lock-in. Addressing these challenges requires careful planning, collaboration between IT teams and stakeholders, and a strategic approach to migrating and managing workloads across different environment.

Related Articles, References, Credits, or External Links

NA

Broadcom and Changes to VMware

KB ID 0001858

Broadcom’s Acquisition of VMware Sparks Licensing Shift

In a seismic move for the tech industry, Broadcom’s acquisition of VMware has sent shockwaves through the enterprise landscape. With a track record of acquiring and restructuring tech giants like Symantec and CA (Computer Associates), Broadcom’s takeover of VMware has left many in anticipation of what’s to come.

One of the most significant changes is the departure from perpetual licensing models. Gone are the days of perpetual licenses; instead, the focus is squarely on enterprise solutions. This shift signifies a move towards a subscription-based model, aligning with broader industry trends.

Moreover, the landscape of VMware’s product offerings is undergoing a transformation. Carbon Black and Horizon are among the casualties, as Broadcom streamlines VMware’s portfolio. However, the core elements of the Sphere foundation—vCenter, ESXi, and vSAN—are set to endure, ensuring continuity for VMware’s loyal customer base.

As the dust settles, enterprises are left contemplating their options. Some may consider alternatives like Nutanix or Proxmox, while others eye the rising prominence of Kubernetes and Docker, potentially rendering the traditional hypervisor obsolete.

Yet, amidst these changes, it’s essential to note that VMware’s legacy persists. With Azure’s infrastructure relying heavily on Hyper-V, the hypervisor isn’t going extinct anytime soon. On-premises, Azure Stack HCI, built on Hyper-V, remains a robust solution for organizations invested in Microsoft’s ecosystem.

In this dynamic landscape, adaptation is key. As Broadcom steers VMware into a new era, enterprises must evaluate their strategies and embrace the evolving paradigms of virtualization and cloud computing. Stay tuned as we delve deeper into the implications of Broadcom’s acquisition and its ramifications for the future of enterprise IT.

What do the New Broadcom VMware Licensing Models Look Like?

In only the last few weeks this information has changed, so if it goes out of date please comment below and I will update accordingly.

The following are the new VMware Subscription Licence models.

  • VVEP VMware vSphere Essentials Plus (up to 96 Cores up to three hosts, support, and vMotion ) no vSAN
  • VVS VMware vSphere Standard as above but not limited to three nodes and 96 cores.
  • VVF VMware vSphere Foundation includes vSAN (sub 1Tb), DRS, and Distributed Switching.
  • VCF VMware Cloud Foundation – Everything above and +1Tb vSAN, NSX, Advanced Support, and additional add on licences packages i.e. vSAN per Tb
  • VCF for CSP VMware Cloud Foundation for Cloud Service Providers (includes vCloud Director).

VMware Licensing Timescales

  • 01/02/24 – Termination of all new sales/renewals of end-user ELAs and perpetual licenses.
  • 31/03/24 – End of MSP rental period of VMware Cloud Provider Program (VCPP) vRAM based usage model.
  • 01/04/24 – MSP subscriptions move from metered RAM to Per Core upfront licensing.
  • 30/04/24 – End of transition period, all customers on lapsed ELAs must move to new subscriptions.

UK Service Providers and Licensing

At time of writing Broadcom have nominated seven UK Strategic partners to sell VCF for CSP, three have announced this publicly, those being Redcentric, iOmart, and ANS. With the breakneck speed these changes have been bought in, the remainder are probably still deciding what to do next.

Related Articles, References, Credits, or External Links

NA

Migrate to Microsoft Entra Connect

 Migrate to Microsoft Entra Connect KB ID 0001857

Problem

You want to migrate from Microsoft Azure AD Connect to Microsoft Entra ID connect.

Let me let you into a secret, (at time of writing) Entra ID connect and Azure AD connect ARE THE SAME THING, if you go to download Entra ID connect, the file you will download is called AzureADConnect.msi. So what you want to do is, upgrade Azure AD Connect.

If your existing Azure AD connect is running on Window Server 2016 (or newer) you can simply ‘in place upgrade‘ the existing Azure AD connect to version 2 and there’s no need to migrate anything.

If you MUST Migrate, because you are deploying on a new server for example, the process is straight forward.

  • Install on New Server and put into Staging Mode.
  • Put Old Server into Staging Mode.
  • Take New Server out of  Staging Mode, (ensure there are no errors/problems).
  • Uninstall from Old Server.

Solution: Migrate to Microsoft Entra Connect

So if you simply want to perform an in place upgrade because your OS is Windows Server 2016 (or newer), use the following article.

Upgrade Azure AD Connect

If you’ve made it this far then you are WANTING to Migrate to Microsoft Entra ID Connect, or as previously mentioned migrate to Azure AD connect on another server!

Migrate to Microsoft Entra Connect Step One: Export Settings

On the Old Server, launch the Azure AD connect shortcut > Configure.

Select  ‘View or export current configuration’ > Next.

Export Settings > Save them (by default in C:\ProgramData\AADConnect) > Save > Exit.

Migrate to Microsoft Entra Connect Step Two: Import Settings

Assuming you’ve done nothing other than download the install package on the new server  > Run the installer package > Agree to the EULA > Continue.

Customise.

Select ‘Import synchronisation settings > In the Location section enter \\old-server-name\c$\ProgramData\AADConnect\filename.json >  Install.

From this point forward I will assume you want everything set the same, so other than usernames and passwords accept the defaults > Next.

Enter the password to authenticate to M365/Azure AD.

This next screen can be confusing because you can’t click Next, and it’s not apparent why! Next to your domain there should be a green tick, if there’s a red cross you need to select ‘change password’ > Then enter the (local AD account) account you use for synchronisation > Next.

Next.

Both options should be ticked by default > Install.

Exit.

Migrate to Microsoft Entra Connect Step Three: Put Old Server Into Staging Mode

I find this much easier to do with PowerShell, but I’ll put the graphical procedure below if you prefer. Issue the following two commands.

[box]

$aadSyncSettings=Get-ADSyncGlobalSettings
$aadSyncSettings.parameters

[/box]

Locate the ‘Microsoft.synchronize.StagingMode‘ section and you will see its value is set to ‘False‘ i.e. staging mode is NOT enabled (or it’s in production mode).

To change the value to ‘True‘ i.e. enable staging mode use the following command.

[box]

($aadSyncSettings.parameters | ?{$_.name -eq "Microsoft.Synchronize.StagingMode"}).value="True"
Set-ADSyncGlobalSettings $aadSyncSettings

[/box]

You can then  confirm that the staging mode value is set to ‘True’ with the following command.

[box]

$aadSyncSettings.parameters

[/box]

Migrate to Microsoft Entra Connect Step Four: Take the New Server Out of Staging Mode

On the New Server, use the following two commands.

[box]

$aadSyncSettings=Get-ADSyncGlobalSettings
($aadSyncSettings.parameters | ?{$_.name -eq "Microsoft.Synchronize.StagingMode"}).value="False"
Set-ADSyncGlobalSettings $aadSyncSettings

[/box]

You can then  confirm that the staging mode value is set to ‘False’ with the following command.

[box]

$aadSyncSettings.parameters

[/box]

Migrate to Microsoft Entra Connect Step Five: Check for Errors

On Premises: You can look in ‘Azure AD Connect Synchronisation Service.’

Microsoft 365: The main Admin console will tell you (in the user management pane).

Microsoft Entra Admin Panel: Look under identity > Provision from Active Directory.

Alternate Steps to Enable Staging Mode (From GUI)

On the Old Server, launch the Azure AD connect shortcut > Configure.

Configure Staging Mode > Next.

Enter your admin password > Next.

Tick to select ‘Enable Staging Mode‘ > Next.

Configure.

Exit

Alternate Steps to Disable Staging Mode (From GUI)

On the New Server, launch the Azure AD connect shortcut > Configure.

Configure Staging Mode > Next

Enter your admin password > Next.

Untick to deselect ‘Enable Staging Mode‘ > Next.

Configure.

Exit

Migrate to Microsoft Entra Connect Step Five: Uninstall Microsoft Azure AD Connect

On the Old Server, search for appwiz.cpl > run it > Select Microsoft Azure AD Connect > Uninstall > Yes > Remove.

Exit.

Related Articles, References, Credits, or External Links

Locate Your Azure AD Connect Server

Azure AD Connect: Correct Or Remove Duplicate Values

Cannot Recreate Azure AD ‘Local’ AD Connector

Forcing Azure AD Connect Sync

SSL_ERROR_UNSUPPORTED_VERSION

SSL_ERROR_UNSUPPORTED_VERSION KB ID 0001856

Problem

I get it, older versions of TLS and SSL are insecure and we should not be using them. However I needed to get on an HPE Server iLO management interface last week and I

was met with this.

Firefox Error: SSL_ERROR_UNSUPPORTED_VERSION
Microsoft Edge, Chrome, and Opera Error: ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Microsoft Internet Explorer Error:
This might be because the site uses outdated or unsafe TLS security settings. If this keeps happening, try contacting the website’s owner. Your TLS security settings aren’t set to the defaults, which could also be causing this error.

Firefox Solution : SSL_ERROR_UNSUPPORTED_VERSION

I advise you just do this to get to the page you need to and set it back afterwards. In your browser windows enter about:config, Type TLS into the search bar and locate security.tls.version.min and change its value to 1, Then tick to save.

And now, I can get to where I want to go.

IE Solution : SSL_ERROR_UNSUPPORTED_VERSION

Yeah, I know Internet Explorer is supposed to be dead, but it’s still there and you can utilise it to solve this problem, from your internet options in IE > Advanced  > you can then enable TLS 1.1. and 1.2.

You will still get a warning but now you can click past it.

Related Articles, References, Credits, or External Links

ERR_CERT_WEAK_SIGNATURE_ALGORITHM

ERR_CERT_COMMON_NAME_INVALID

 

Microsoft Edge Notification?

Microsoft Edge Notification KB ID 0001855

Problem

This is the second time I’ve had this problem, luckily it took me so long to figure it out the first time, this time I was fine. On my mac I use Edge as the browser for all the work applications. But when it had a notification for me like this.

Despite my best efforts, it was not obvious what it was telling me.

Solution: Microsoft Edge Notification

Another clue is the ‘blue’ circle around the download logo, Edge is informing me that there is a download problem, in my case a download has failed, I simply need to delete the partially downloaded file and attempt to download again.

 

Related Articles, References, Credits, or External Links

NA

vCenter Domain Authentication

vCenter Domain Authentication KB ID 0001854

Problem

Note: This procedure uses vCenter 8.0 Update 2, (the process is the same for vSphere 7).

When you setup your VCSA you will have configured SSO, in most cases accepting the default SSO domain of vsphere.local. But If you want to log into VMware you probably want your identify source to be AD (to use you existing usernames and passwords).

Note: In this example I will grant administrative access to the domain admins group, in production you probably will want to create some new AD groups and look at the principles of least privilege.

Solution: vCenter Domain Authentication

Once logged into vCenter, changing views is done by clicking the ‘three lines’ at the top left of the screen, navigate to Administration > Single Sign On > Configuration > Identity Provider > Active Directory Domain > Join AD.

Supply the domain name and some credentials that have the rights to join a machine to the domain > Join.

Nothing Happens! Don’t worry that’s normal, nothing will change (and you can’t’ progress) until you’ve rebooted the VCSA.

While its rebooting you can check in you AD and you will see the computer object has been created for the VCSA.

Have some patience, once the VCSA has rebooted and all the services are back online you will see the display has changed to show the domain information, you can now proceed.

Identity Source > Add.

Change the drop down to Active Directory over LDAP.

Enter the details to join the domain, the account you use to ‘bind’ to active directory can be a simple ‘domain user’. Fill in the fields and select ‘Add’.

Now select the domain you just added and ‘set as default > confirm by pressing ‘OK’.

Users and Groups > Groups > Select Administrators > Edit.

Change the domain to your AD domain > Search for Domain Admins > Add that group.

You can now authenticate into the VCSA with an account thata is a member of that AD group.

 

Related Articles, References, Credits, or External Links

(vSphere 6) vSphere – Adding Domain Users/Groups to vCenter

Deploying and Configuring The vCenter Server Appliance

 
 

Change iLO Server Name

Change iLO Server Name KB ID 0001853

Problem

I was rebuilding some servers this week and had changed all the iLO settings including the iLO name. But when I connected to the iLO with a browser, it still displayed the ‘old server name’. Even in the ‘Overview‘ section is still showed both the old server name and the previous domain.

Solution: Change iLO Server Name

An internet search turned up plenty of people with the same problem, but not many people managing to fix it. I stumbled across the answer by simply going to each section until I found it.

Administration > Access Settings > Access Options > Here there is an ‘editable’ value called Server Name > Change accordingly.

Sometimes you may need to reset the iLO (iLO Dedicated Network Port > General Tab > Reset).

Related Articles, References, Credits, or External Links

Find All HP iLOs on your Network

HP iLO Upgrade Stops at 99%

HP iLO – Password Must Contain 8 to 39 Characters