On August 30th Vmware announced that vSphere 8 would be with us later on in the year (I even posted about it). Today it has gone GA (General Availability)
I will have a look soon so will post my comments.
VMware has announced that vSphere 8.0 will be released later this year (Probably the back end I would guess at the moment). Some scalability improvements have been announced which we will hopefully get a look into when we all manage to get our hands on when the GA comes about.
Full details can be found on the Announcement Blog
https://blogs.vmware.com/vsphere/2022/08/introducing-vsphere-8-the-enterprise-workload-platform.html
Again Vmware has been kind enough to award me vExpert again for the 5th year in a row.
I can only offer my thanks and congratulations to my fellow vExperts, roll on 2022
Happy and honored to be recognized as a #vExpert for the 4th year in a row. Huge thanks to the vExpert community and Congrats to new and returning vExperts
We have had an issue recently relating to chronyD which primarily affects our redhat 7 servers and not the redhat 6 boxes, seems redhat 6 is a little bit more flexiable with regarding timesources but thats another story.
Typically we get out timesources from our fortigate (Stratum 2) resource (Stratum 1 being fortiguards NTP source where it gets the time form and stratum 0 being atomic clock)
We then cascade that down to the PDC role on the DC which is the stratum 3 source and then this rolls down to the other DCS’s Stratum 4).
Anyway when using time on redhat its always best to go for the fortigates rather than the windows timesource.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | Add-PSSnapin VMware.VimAutomation.Core Connect-VIServer -Server vcenter.local -User username -Password Password $ServerList = Get-Content C:\serverlist.txt Foreach ($vm in $ServerList) { New-AdvancedSetting -Entity $vm -Name tools.syncTime -Value '0' -Confirm:$false -Force:$true New-AdvancedSetting -Entity $vm -Name time.synchronize.continue -Value '0' -Confirm:$false -Force:$true New-AdvancedSetting -Entity $vm -Name time.synchronize.restore -Value '0' -Confirm:$false -Force:$true New-AdvancedSetting -Entity $vm -Name time.synchronize.resume.disk -Value '0' -Confirm:$false -Force:$true New-AdvancedSetting -Entity $vm -Name time.synchronize.shrink -Value '0' -Confirm:$false -Force:$true New-AdvancedSetting -Entity $vm -Name time.synchronize.tools.startup -Value '0' -Confirm:$false -Force:$true New-AdvancedSetting -Entity $vm -Name time.synchronize.tools.enable -Value '0' -Confirm:$false -Force:$true New-AdvancedSetting -Entity $vm -Name time.synchronize.resume.host -Value '0' -Confirm:$false -Force:$true } |
Always remember to make the following vmx changes to the VM’s
And of couse set chronyd with the
1 | maxdistance = 16 |
Another exciting day for VMware, the public release of ESXi on ARM fling, yet another good reason to justify the purchase of a raspberyy pi 4 (8GB version)
I can already see a load of good uses for this , hopefully get some to blog about later.
Im the meantime here are the details on the announcement
https://blogs.vmware.com/vsphere/2020/10/announcing-the-esxi-arm-fling.html
Well its out now after the comments in september to say it was due to be out we now have update 1 released to all.
We have a number updates as listed below from the release notes, the most interesting of all is vSphere with Tanzu which is something im really interested to have a play with.
What’s New
- ESXi 7.0 Update 1 supports vSphere Quick Boot on the following servers:
- HPE ProLiant BL460c Gen9
- HPE ProLiant DL325 Gen10 Plus
- HPE ProLiant DL360 Gen9
- HPE ProLiant DL385 Gen10 Plus
- HPE ProLiant XL225n Gen10 Plus
- HPE Synergy 480 Gen9
- Enhanced vSphere Lifecycle Manager hardware compatibility pre-checks for vSAN environments: ESXi 7.0 Update 1 adds vSphere Lifecycle Manager hardware compatibility pre-checks. The pre-checks automatically trigger after certain change events such as modification of the cluster desired image or addition of a new ESXi host in vSAN environments. Also, the hardware compatibility framework automatically polls the Hardware Compatibility List database at predefined intervals for changes that trigger pre-checks as necessary.
- Increased number of vSphere Lifecycle Manager concurrent operations on clusters: With ESXi 7.0 Update 1, if you initiate remediation at a data center level, the number of clusters on which you can run remediation in parallel, increases from 15 to 64 clusters.
- vSphere Lifecycle Manager support for coordinated updates between availability zones: With ESXi 7.0 Update 1, to prevent overlapping operations, vSphere Lifecycle Manager updates fault domains in vSAN clusters in a sequence. ESXi hosts within each fault domain are still updated in a rolling fashion. For vSAN stretched clusters, the first fault domain is always the preferred site.
- Extended list of supported Red Hat Enterprise Linux and Ubuntu versions for the VMware vSphere Update Manager Download Service (UMDS): ESXi 7.0 Update 1 adds new Red Hat Enterprise Linux and Ubuntu versions that UMDS supports. For the complete list of supported versions, see Supported Linux-Based Operating Systems for Installing UMDS.
- Improved control of VMware Tools time synchronization: With ESXi 7.0 Update 1, you can select a VMware Tools time synchronization mode from the vSphere Client instead of using the command prompt. When you navigate to VM Options > VMware Tools > Synchronize Time with Host, you can select Synchronize at startup and resume (recommended), Synchronize time periodically, or, if no option is selected, you can prevent synchronization.
- Increased Support for Multi-Processor Fault Tolerance (SMP-FT) maximums: With ESXi 7.0 Update 1, you can configure more SMP-FT VMs, and more total SMP-FT vCPUs in an ESXi host, or a cluster, depending on your workloads and capacity planning.
- Virtual hardware version 18: ESXi Update 7.0 Update 1 introduces virtual hardware version 18 to enable support for virtual machines with higher resource maximums, and:
- Secure Encrypted Virtualization – Encrypted State (SEV-ES)
- Virtual remote direct memory access (vRDMA) native endpoints
- EVC Graphics Mode (vSGA).
- Increased resource maximums for virtual machines and performance enhancements:
- With ESXi 7.0 Update 1, you can create virtual machines with three times more virtual CPUs and four times more memory to enable applications with larger memory and CPU footprint to scale in an almost linear fashion, comparable with bare metal. Virtual machine resource maximums are up to 768 vCPUs from 256 vCPUs, and to 24 TB of virtual RAM from 6 TB. Still, not over-committing memory remains a best practice. Only virtual machines with hardware version 18 and operating systems supporting such large configurations can be set up with these resource maximums.
- Performance enhancements in ESXi that support the larger scale of virtual machines include widening of the physical address, address space optimizations, better NUMA awareness for guest virtual machines, and more scalable synchronization techniques. vSphere vMotion is also optimized to work with the larger virtual machine configurations.
- ESXi hosts with AMD processors can support virtual machines with twice more vCPUs, 256, and up to 8 TB of RAM.
- Persistent memory (PMEM) support is up twofold to 12 TB from 6 TB for both Memory Mode and App Direct Mode.
https://blogs.vmware.com/vsphere/2020/10/announcing-general-availability-vsphere-7-update-1.html
One of the issues that we have found is that due to the changes that have been made in both vsphere and windows that volumes appear as hotplug devices in Computer Manager, also this can affect how disks are brought online by windows.
To resolve this add the following setting to the vmx file
1 | devices.hotplug = "false" |
Also within windows make sure your diskpart san policy is set to always on.
1 2 3 4 5 | Diskpart.exe San (This will then show your policy) san policy=onlineall (and your done) |
VMware vSphere 7.0 has been announced and released by VMware. This is a major release that VMware will roll out in Q1 and vSphere 7.0 shall be adopted fast as soon as all the backup and DR vendors update their software
One of the main things is that there is no longer a Windows vCenter options, so only VCSA from now on.
Some of the features useable straight out the door are:
- Improved Distributed Resource Scheduler (DRS)
- Assignable Hardware Framework
- Advanced Dynamic DirectPath I/O
- vSphere Lifecycle Manager
- Greatly Improved vMotion
- Advanced Security – implement multifactor authentication (MFA)
- Precision clock for PTP support
- Even more advanced Content Library
- Essential Services for Modern Hybrid cloud
Here are the release notes from VMware
https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-esxi-vcenter-server-70-release-notes.html
A customer is currently using solarwinds to monitor there virtual infastructure, when they do there patching they need to login to the solarwinds console, and manually step though each of the virtual machines/objects they are going to patch and put them into maintenance mode so the on-call guy doesnt get flooded with alerts.
To help matters and save a bit of time i used the below piece of powershell scripting to take away that manual task and only require a text file with a list of the servers to be modified (this is assuming you have the swisPowershell installed:
1 | Install-Module -Name SwisPowerShell |
swmaintme.ps1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | # Check if the powershell module that is used is actually loaded and if not load it up Import-Module SwisPowerShell # Hours passed when running script e.g (./swmaintme.ps1 12) will set maintance for 12 hours $hours=$args[0] # Where is the server file located (file is a text file with just server names not FQDN) $serverlist = Get-Content -Path "'path to imput text file'\unmanageme.txt" # What is the solarwinds server (can only be ran from here as port 17777 is not open remotely :( ) $strsolarWindServer="Solarwinds Server name Here" # Lets connected to the server listed above nice and trusted $swis = Connect-Swis -Hostname $strsolarWindServer -Trusted # For each time you look at a line in the text file above do this >>>>> foreach($server in $serverlist){ $strQuery = "SELECT uri FROM Orion.Nodes WHERE SysName LIKE '" + "$server" + "%'" $uris = Get-SwisData $swis $strQuery # Important line where we actually set the server to unmanaged and status 9 and then set it to maintance from when script was run to the hours we said at start $uris | ForEach-Object { Set-SwisObject $swis $_ @{Status=9;Unmanaged=$true;UnmanageFrom=[DateTime]::UtcNow;UnmanageUntil=[DateTime]::UtcNow.AddHours($hours)}} } |
Once you maintenance is finished and i the following script will take the same input file and put them back into monitoring mode, unless of course you wish to wait till your maintenance period you specified in the first script ends.
swunmaintme.ps1
1 2 3 4 5 6 7 8 9 10 | Import-Module SwisPowerShell $serverlist = Get-Content -Path "'path to imput text file'"\unmanageme.txt" $strsolarWindServer="Solarwinds Server name Here" $swis = Connect-Swis -Hostname $strsolarWindServer -Trusted foreach($server in $serverlist){ $strQuery = "SELECT uri FROM Orion.Nodes WHERE SysName LIKE '" + "$server" + "%'" $uris = Get-SwisData $swis $strQuery $uris | ForEach-Object { Set-SwisObject $swis $_ @{Status=1;Unmanaged=$false}} } |
Recent Comments