Simplify Lifecycle Management with Dell EMC PowerEdge & VMware

Co-author: Damon Earley

IT Admins can realize significant time savings with up to 98% less hands-on time to update hypervisor and firmware¹

We’ve often heard that the most precious resource is time. What if we told you that Dell EMC PowerEdge and VMware have teamed up to help your IT staff get a little more time back in their day? No, it’s not magic, although you may feel compelled to work on your next virtual party trick with all of the time savings that your IT staff will reap from using Dell EMC OpenManage Integration for VMware vCenter (OMIVV) and vSphere Lifecycle Manager (vLCM). Better yet, use the time saved to access more exciting content from the first-ever virtual VMworld 2020, including the PowerEdge and VMware on-demand technical session.

Dell EMC PowerEdge and VMware have jointly innovated to give your IT staff the virtualization mathematics that really add up to true time savings. Earlier this year, VMware launched VMware vSphere 7 as vSphere Lifecycle Manager (vLCM), which enables IT to deploy, manage and update both software and drivers in conjunction with a hardware support manager for hardware firmware using a desired state model. Dell EMC PowerEdge was one of the first server manufacturers to implement this epic new feature with our own hardware support manager, Dell EMC OpenManage Integration for VMware vCenter (OMIVV). The results include some pretty impressive time savings for your IT staff, who like the rest of the world, are strapped for time. We’ll dive into those time savings but first, let’s talk about OMIVV.

OMIVV is the systems management plug-in from Dell for vCenter, providing a unified view of physical and virtual servers for PowerEdge hosts running vSphere. With it, monitoring and lifecycle management of the physical server can be brought into the native vCenter user interface, helping provide a holistic view of your server resources. With vLCM and OMIVV, you can see a significant decrease in the total time it takes to run these updates. Benefits include:

  • Reduced manual steps by setting up templates
  • Repositories that can be used repeatedly across many servers
  • Communication with vCenter to work with its software policies, like ProActive HA, DRS, and vSAN
  • Capability to leverage live migration policies, including for VMware vSAN

Customers have maximum flexibility and control when patches and updates are deployed, with unified software and firmware lifecycle management. And they can do it simply within vCenter, a familiar and comfortable tool. With Cluster Profiles, both for legacy vSphere and with vLCM, monitor for compliance and drift automatically, and schedule updates from within vCenter.

Based on this report by Principled Technologies, with vLCM and OMIVV, it took 98% fewer steps to update the hypervisor and firmware on an 8-node PowerEdge cluster.

Number of steps to update both hypervisor and firmware across a cluster. Fewer steps are better. Source: Principled Technologies

A lot of the steps to this process – defining the software image, what drivers are needed, what firmware needs to be applied – are generally done only a handful of times based on the specific servers are in the cluster. Leveraging vLCM’s new functions for setting the ESXi baseline and driver add-ons, along with hardware templates for server firmware, lets you set these things once, then use them across the environment. The overall time, as well as hands-on time, was also significantly reduced, per the chart below. Essentially, the admin time was reduced to under 4 minutes versus 3.5 hours manually.

Time (h::mm:ss) to update both the hypervisor and firmware across a cluster. Less time is better. Source: Principled Technologies

While we cannot jointly innovate or engineer more hours in the day, our commitment to our PowerEdge server customers using VMware vSphere, vSAN and Cloud Foundation is to help simplify and accelerate your hybrid cloud with new features such as vLCM. Learn more about our approach to lifecycle management with this on-demand PowerEdge and VMware breakout session at VMworld 2020, or visit our PowerEdge and VMware website.

¹Principled Technologies report commissioned by Dell EMC, “New VMware vSphere 7.0 features reduced the time and complexity of routine update and hardware compliance tasks,” August 2020.

Related:

VMware vSphere 7 Now Available on Dell EMC PowerEdge

With PowerEdge & vSphere 7, it’s full speed ahead on your journey to the modern hybrid cloud When VMware announced Project Pacific at VMworld last fall, Kit Colbert, Chief Technology Officer of Cloud Platform at VMware, described it as “the biggest evolution of vSphere in easily the last decade.” Now that it’s here, we see that it lives up to the hype. vSphere 7 is truly a game-changer, bringing native support for Kubernetes into vSphere so organizations can run containers and virtual machines on the same platform. Not to mention, in addition to the new Kubernetes capabilities, … READ MORE

Related:

VM's Power State Does Not Update And Shows As “Unknown” After vCenter Server Reboots

This is an issue with Citrix hypervisor communication library plugin since version Xenapp/XenDesktop version 7.16.

When vCenter server goes alive after reboot i.e “https://<vCenter FQDN>/sdk” becomes accessible, BrokerHostingPlugin still fails to login the vCenter server with exception “The session is not authenticated.”.

CDF Traces from Delivery Controller

,BrokerHostingPlugin,,0,,1,Information,”Attempting connection”,””

,BrokerHostingPlugin,,0,,1,Information,”***** Get Hypervisor Certificate for Connection to ‘https://<vCenter FQDN>/sdk​​​​​​​’ *****”,””

,BrokerHostingPlugin,,0,,1,Information,”Certificate is untrusted: False”,””

,BrokerHostingPlugin,,0,,1,Information,”Time elapsed to get the hypervisor certificate: xxms”,””

,BrokerHostingPlugin,,0,,1,Information,”***** Login Connection – 0 to ‘​​​​​​​https://<vCenter FQDN>/sdk’ as ‘#login_name#‘ *****”,””

,BrokerHostingPlugin,,0,,1,Information,”VMware plugin initialisation times: create service xms, content time xxxms, total xxxms”,””

,BrokerHostingPlugin,,0,,1,Information,”Connected to ‘VMware vCenter Server #vCenter version info#’“,””

,BrokerHostingPlugin,,0,,1,Error,”System.Web.Services.Protocols.SoapException: The session is not authenticated.

,BrokerHostingPlugin,,0,,1,Information,”Connection attempt threw exception System.Web.Services.Protocols.SoapException: The session is not authenticated.

,BrokerHostingPlugin,,0,,1,Information,”Connection is still down”,””

,BrokerHostingPlugin,,0,,1,Information,”Sleeping for 00:00:30 before trying to reconnect again”,””

Related:

VxRail: PTAgent upgrade failure, ESXi error “Can not delete non-empty group: dellptagent”[3]

Article Number: 516314 Article Version: 6 Article Type: Break Fix



VxRail 460 and 470 Nodes,VxRail E Series Nodes,VxRail P Series Nodes,VxRail S Series Nodes,VxRail V Series Nodes,VxRail Software 4.0,VxRail Software 4.5

VxRail upgrade process fails when upgrading PTAgent from older version 1.4 (and below) to newer 1.6 (and above).

Error message

[LiveInstallationError]

Error in running [‘/etc/init.d/DellPTAgent’, ‘start’, ‘upgrade’]:

Return code: 1

Output: ERROR: ld.so: object ‘/lib/libMallocArenaFix.so’ from LD_PRELOAD cannot be preloaded: ignored.

ERROR: ld.so: object ‘/lib/libMallocArenaFix.so’ from LD_PRELOAD cannot be preloaded: ignored.

ERROR: ld.so: object ‘/lib/libMallocArenaFix.so’ from LD_PRELOAD cannot be preloaded: ignored.

Errors:

Can not delete non-empty group: dellptagent

It is not safe to continue. Please reboot the host immediately to discard the unfinished update.

Please refer to the log file for more details.

Dell ptAgent upgrade failed on target: <hostname> failed due to Bad script return code:1

PTAgent can’t be removed without ESXi asking for a reboot, due to earlier version of PTAgent (lower than 1.6) had problem dealing with process signals, ESXi is unable to stop it no matter what signal is sent or what method is attempted to kill the process. Rebooting ESXi si required to kill the defunct process so the upgrade can proceed.

PTAgent 1.6 (and above) had this issue fixed, but upgrading from 1.4 to 1.6 can’t be done without human intervene once the issue is encountered.


Impacted VxRail versions (Dell platform only):

  • 4.0.x: VxRail 4.0.310 and below
  • 4.5.x: VxRail 4.5.101 and below

This issue is fixed in recent VxRail releases, but upgrade from earlier VxRail releases are greatly impacted. It’s strongly suggested customer to contact Dell EMC Technical Support to upgrade to PTAgent 1.7-4 which is included in below VxRail releases:

  • VxRail 4.0.500 for customer who stays on vSphere 6.0
  • VxRail 4.5.211 or above for customers who choose vSphere 6.5

Manual workaround if experiencing the PTAgent upgrade failure

  • Enter maintenance mode and reboot the host mentioned in error message
  • Wait until the host is available and showing proper state in vCenter, click retry button in VxRail Manager to retry upgrade.

Related:

ViPR Controller: How to migrate an ESX cluster from one vCenter to another while retaining the existing storage.[2]

Article Number: 524225 Article Version: 6 Article Type: How To



ViPR Controller Controller 3.6,ViPR Controller

Procedure to migrate a VIPR Controller managed ESX cluster to a new vCenter and retain the same volumes/ExportGroup.

1. Switch off auto-discovery for vCenter within the ViPR-C UI.

Method 1 : (ViPR Controller UI > System > General Configuration > Discovery > Enable Auto-Discovery ( Set to False)
Note: This will require a reboot of VIPR Controller.

Method 2 : Disable discovery in ViPR Controller by updating both vCenters with the wrong credentials.

(ViPR Controller UI > Physical > vCenters)

This prevents discovery from running while the customer is moving hosts/cluster to the new vCenter.

2. In a vSphere client, migrate the cluster/hosts from the original (source) vCenter & configure on the target vCenter (using the same cluster name as the original).

3. Use viprcli commands to align the ESX hosts to the new target vCenter and VirtualDataCenter:

viprcli host update -hl “Hostname” -ndc “new_vCenterDataCenter” -vc “new_vCenter”

4. Configure the cluster in ViPR Controller to align with the target Datacenter & vCenter:

viprcli cluster update -name “clustername” -dc “old_vCenterDataCenter” -vc “Old_vCenter” -ndc “new_vCenterDataCenter” -nvc “new_vCenter”



5. Enable discoveries in VIPR Controller again (reversal of Step 1).

6. No actionable events related to the migration should be generated as the VIPR-C DB has been modified to reflect the changes.

Related:

  • No Related Posts

Re: RecoverPoint for vm on different site but same Vcenter

Hi there,

Just to reiterate, as Rich stated, they can deploy a single vRPA cluster which would allow them to do local replication and RPVM doesn’t have any issue with replicating to RPVM clusters within the same vCenter (and ESX cluster).

That said, If they need a DR solution, it would be recommended to configure 2 RPVM clusters w/ remote replication. Finally, it would be recommended to protect vCenter with vCenter HA as vCenter is a management SPOF and if production site failure causes vCenter failure then management of the secondary site would be impacted, unless vCenter HA, which RPVM fully supports, is deployed.

Regards,

Idan Kentor

RecoverPoint Corporate Systems Engineering

@IdanKentor

Related:

VM’s Power State Does Not Update And Shows As “Unknown” After vCenter Server Reboots

This is an issue with Citrix hypervisor communication library plugin since version Xenapp/XenDesktop version 7.16.

When vCenter server goes alive after reboot i.e “https://<vCenter FQDN>/sdk” becomes accessible, BrokerHostingPlugin still fails to login the vCenter server with exception “The session is not authenticated.”.

CDF Traces from Delivery Controller

109369,0,2018/09/05 11:35:54:09721,1972,8384,1,BrokerHostingPlugin,,0,,1,Information,”Attempting connection”,””

109370,0,2018/09/05 11:35:54:09729,1972,8384,1,BrokerHostingPlugin,,0,,1,Information,”***** Get Hypervisor Certificate for Connection to ‘https://vcenter.***.***/sdk‘ *****”,””

109371,1,2018/09/05 11:35:54:17750,1972,8384,1,BrokerHostingPlugin,,0,,1,Information,”Certificate is untrusted: False”,””

109372,1,2018/09/05 11:35:54:17761,1972,8384,1,BrokerHostingPlugin,,0,,1,Information,”Time elapsed to get the hypervisor certificate: 80ms”,””

109373,1,2018/09/05 11:35:54:17770,1972,8384,1,BrokerHostingPlugin,,0,,1,Information,”***** Login Connection – 0 to ‘https://vcenter.***.***/sdk‘ as ‘administrator’ *****”,””

109374,0,2018/09/05 11:35:54:49296,1972,8384,1,BrokerHostingPlugin,,0,,1,Information,”VMware plugin initialisation times: create service 0ms, content time 315ms, total 315ms”,””

109375,0,2018/09/05 11:35:54:49301,1972,8384,1,BrokerHostingPlugin,,0,,1,Information,”Connected to ‘VMware vCenter Server 6.0.0 build-3018524′”,””

109376,0,2018/09/05 11:35:54:51280,1972,8384,1,BrokerHostingPlugin,,0,,1,Error,”System.Web.Services.Protocols.SoapException: The session is not authenticated.

109377,0,2018/09/05 11:35:54:51541,1972,8384,1,BrokerHostingPlugin,,0,,1,Information,”Connection attempt threw exception System.Web.Services.Protocols.SoapException: The session is not authenticated.

109378,0,2018/09/05 11:35:54:51548,1972,8384,1,BrokerHostingPlugin,,0,,1,Information,”Connection is still down”,””

109379,0,2018/09/05 11:35:54:51554,1972,8384,1,BrokerHostingPlugin,,0,,1,Information,”Sleeping for 00:00:30 before trying to reconnect again”,””

Related:

Re: vCenter Server and ESXi host communication issue with Unity 300

You need to open an SR for this. We can’t troubleshoot this here.

Sounds like the upgrade triggered either network changes or loss of access.

If you imported the hosts via a Vcenter import on Unity, make sure the vcenter is being seen properly etc.

But as I said, an SR is the way to go here. Needles to say, if you only upgraded vCenter / hosts, I would be looking there first and not on the Unity side.

Related:

VxRail: During upgrade from 4.0.x to 4.5.x, instant cloning in VMware Horizon may fail,

Article Number: 524627 Article Version: 3 Article Type: Break Fix



VxRail Software 4.0

The issue occurs if:

  1. The cluster is using instant cloning in VMware Horizon
  2. The attached vCenter is at 6.5 and the hosts are at 6.0 and a build lower than 6921384. The likely situation for this scenario is a cluster being upgraded directly from 4.0.3xx to 4.5.x.

Symptoms:

  • Adding instant-clone desktop fails.
  • On vCenter Server the VitualMachine.createForkChild.label task fails with the error: The resource ‘<number>’ is in use.

This issue occurs because of an internal design incompatibility in port binding between ESXi 6.0 and vCenter Server 6.5 when instant clone deployment is used. Currently, instant clone works when the versions of ESXi and vCenter Server are the same. (i.e. ESXi 6.0 with vCenter Server 6.0 or ESXi 6.5 with vCenter Server 6.5 is used)

See VMware KB 2150925

Option 1: Upgrade the ESXi hosts to match the code version of the vCenter server or revert the vCenter code to match that of ESXI.

Option 2: The ESXi for this issue was included in release 4.0.400 and above. As such, the cluster could be upgraded from 4.0.3xx to 4.0.4xx and then to 4.5.x to avoid the issue.

Related:

VxRail: After upgrading to 4.5.218, an alert is reported on the hosts: esx.problem.hyperthreading.unmitigated

Article Number: 525114 Article Version: 4 Article Type: Break Fix



VxRail Appliance Series,VxRail Software

VxRail Appliance software 4.5.218 contains vSphere 6.5 EP8/U2c which addresses the L1 Terminal Fault vulnerability. Refer to VMware KB reference 55636 for a centralized source of information

For more details from the release notes, check: https://support.emc.com/docu86659_VxRail-Appliance-Software-4.5.x-Release-Notes.pdf?language=en_US

vCenter must be upgraded to 6.5 U2c prior to patching the nodes. When the appliance is using internal vCenter, the regular upgrade workflow will upgrade vCenter and the nodes after. For external vCenter scenarios, customer will need to upgrade vCenter first.

Both Internal and External vCenter implementations will show an alert after the cluster is upgrade to 4.5.218

If vCenter was upgraded first, automatically on internal vCenter implementation, and then the hosts, customer will see these alerts on the nodes:

User-added image

If vCenter was not upgraded, but the nodes were (external vCenter appliances), customers will see these alerts on the nodes:

User-added image

Make sure to review the following KB carefully. Choosing to ignore the alerts or disabling hyper-threading may affect the security or performance of your appliance.

If your vCenter is not running version 6.5 U2c, be sure to upgrade it. Then, review https://kb.vmware.com/s/article/55806 for the next steps to take on this issue.

Before upgrading clusters with External vCenter, check this kb: VxRail: VxRail and external vCenter interoperability matrix

Related: