Bytes of virtualization with bits of other technology.

Zerto Duplicate MoRef Issue

Today, Zerto released a field notice for customers running Zerto 5.0 or 5.5 in VMware vSphere environments. The issue pertains to duplicate MoRef entries residing in the Zerto Virtual Manager database. These duplicate entries are being created by the ZVM or by the installer during an installation. Alone the presence of duplicate MoRefs doesn’t cause the issue. However, certain tasks or changes on the duplicated object can cause disruptions to synchronization or replication. This could force VPGs into an error state; consequently, rendering them unrecoverable. Zerto states that some environments may contain duplicated MoRefs, but not be impacted. Regardless, they recommend users on ZVR version 5.0 or 5.5 to upgrade to version 5.5U2P2. P2 will identify and delete duplicate entries. If you are unable to upgrade, Zerto Support can aid in identification and further mitigation of the issue.

ZVR Affected Versions: 5.0, 5.0 U1, 5.0 U2, 5.0 U3, 5.0 U4, 5.5, 5.5 U1, 5.5 U2

What is a MoRef?

Managed Object References are unique identifiers given to all objects in a vSphere environment for identification and tracking purposes. MoRef’s are designated by the object type followed by an identification number. For example, vm-110 or host-95.

Related Posts

Downgrade VMware VM Hardware Version

A few weeks back, we discussed how to downgrade ESXi versions. These downgrades or rollbacks will often time bring compatibility issues into play. One such issue is the compatibility between the ESXi version and virtual machine hardware version. If a virtual machine with a higher version of hardware resides on an unsupported (lower) ESXi version, you will receive an error and not be able to start the machine. The error will state – This virtual machine uses hardware version x, which is no longer supported. Upgrade is recommended.

Hardware Version Unsupported

To address such issues, VMware supports three ways of downgrading virtual machine hardware.

  • Revert to a pre-upgrade snapshot.
  • Convert the virtual machine with VMware vCenter Converter Standalone and specify the appropriate destination hardware version.
  • Create a new VM with a compatible hardware version and attach existing disks.

In this post, we will perform the latter; specifically, downgrading virtual machine hardware 13 to 11.

Continue reading

How to Downgrade/Roll Back ESXi 6.5

Occasionally, an issue or bug will require admins to revert to a previous build or version of ESXi. In the event you patch your hosts (as opposed to fresh installs), it is possible to rollback to a prior installed version via the GUI. Rollbacks should not be taken lightly. If you are reverting in a production environment, discuss options with support first.

A few housekeeping items before we jump into the rollback process.

Compatibility – If you are leveraging new features introduced in vSphere 6.5, ensure you check compatibility against vSphere 6.0. Two main features to be cognizant of when reverting from 6.5 to 6.0 are VMFS and virtual machine hardware versions.

  • VMFS 6: VMFS 6 was introduced with vSphere 6.5. However, vSphere 6.0 utilized VMFS 5. If you created a VMFS 6 version with ESXi 6.5, you will not be able to access the datastore after rollback.
  • VM Hardware Version: vSphere 6.5 also introduced version 13 virtual machine hardware. Version 13 hardware is not compatible with ESXi 6.0. Version 11 or lower is compatible.  However, there are a few supported options for downgrading virtual machine hardware versions.

Back Up Host Configuration – Before making any changes, back up the ESXi Configuration.

Continue reading

Install Nested ESXi 6.5 on Ravello

Recently, I had the opportunity to test a nested lab deployment on Oracle’s Ravello Cloud Service. If you are unfamiliar with Oracle’s Ravello offering, it enables you to deploy your VMware or KVM workloads on Oracle Public Cloud, AWS, or Google Cloud. Ravello seamlessly runs your environment on top of their own nested hypervisor, HVX. HVX, in turn, is run on resources provisioned by Oracle, AWS, or Google Cloud. Utilizing Ravello’s HVX hypervisor allows the underlying cloud infrastructure to behave like your traditional datacenter; thus, enabling you to run your VMware workloads without modification.

Due to additional layers of abstraction, nested environments are prone to performance bottlenecks compared to bare metal offerings like VMware Cloud on AWS. To address this issue, Oracle recently announced the ability to run HVX on top of bare metal servers with the Oracle Cloud Infrastructure (OCI); therefore, eliminating a layer of abstraction.

Ravello on OCI or AWS/Google Cloud

Depending on the cloud region used for deployment, one of three nested virtualization approaches are used for running your workload; software-assisted, hardware-assisted, and direct on bare metal.

Software-assisted nested virtualization is Ravello’s traditional approach to running workloads on AWS or Google Cloud. In these instances, the underlying hardware virtualization extensions are not typically exposed to Ravello. Therefore, HVX uses binary translation with direct execution to run workloads.

Hardware-assisted nested virtualization leverages exposed virtualization extensions on the underlying cloud hardware. Running on Oracle’s Cloud Infrastructure (OCI), HVX has complete access to these hardware extensions, which increases performance over software-assisted nested virtualization.

Oracle Cloud Infrastructure (OCI) also supports the ability to run directly on bare metal servers. This results in increased performance as there is no need for any additional software or hardware translations.

Regardless of region or performance, Ravello provides a variety of use-cases for your workloads including development, testing, sales demos, POCs, and even VCAP lab preparations.

In this post, we are going to install VMware ESXi 6.5 on Ravello’s Cloud Service for testing purposes. The ability to run additional hypervisors (Nested²) such as VMware ESXi, KVM, or Hyper-V is beneficial in testing or lab prep scenarios.

Continue reading

Reset vCenter SSO Administrator Password vSphere 6.5

By default, the vCenter Single Sign-On password expires every 90 days. To prevent unexpected expiration, the vSphere Client issues a warning when the password is about to expire; however, if you find yourself in a situation where you cannot recall the password or the password has expired, it can be reset. The reset process is performed from an SSH session to vCenter.

Reset SSO Administrator Password

To begin, SSH to the vCenter Server Appliance and log in with the root account.

vCenter Root Log In

Continue reading

« Older posts

© 2017 VirtuBytes

Theme by Anders NorenUp ↑