Operating HPE VM Essentials: VM Lifecycle, Storage and High Availability

View the full HPE VM Essentials Fundamentals for VMware Administrators →

Reliable HPE VM Essentials operations depend less on creating a VM than on ensuring that its storage, host networking and placement policy allow it to move, restart or recover when maintenance or failure occurs. For VMware administrators, the core lifecycle is familiar, but HPE VM Essentials combines an HPE-managed KVM cluster with its own management, provisioning and automation model.

VMware administrators will recognise much of the vocabulary: clusters, hosts, datastores, virtual LAN (VLAN)-backed networks, templates, placement rules, live migration and high availability. HPE VM Essentials runs its own Kernel-based Virtual Machine (KVM)-based HVM cluster, managed through HPE Morpheus VM Essentials Manager, rather than another variation of ESXi and vCenter. The day-to-day control plane is familiar enough. Storage and network preparation are more Linux-facing.

The operating model: a VM lifecycle, not a collection of screens

VM Essentials brings provisioning, monitoring, logging, lifecycle actions and automation into the Manager. An HVM host is the HPE-managed KVM runtime where a VM runs; several hosts form an HVM cluster. This instalment starts with operations rather than revisiting management architecture. For that background, read Part 1 of this series, HPE VM Essentials Explained: Architecture, Management and Its Place Alongside VMware.

In practice, administration moves through five layers:

1. Define the service: choose an approved image, compute size, disks, network and ownership context.
2. Place the workload: let the scheduler choose a suitable host, or apply a considered host and affinity policy.
3. Operate it: use power actions, console access, resizing, disk and NIC changes, monitoring and automation.
4. Protect it: set backup, restore and retention arrangements that meet the application’s actual recovery requirement.
5. Retire it: remove the guest only after its records, backups, DNS/IP reservations, disks and dependencies are understood.

The Manager can present a catalogue workflow, but the platform still relies on infrastructure decisions made earlier: host bonds, storage paths, VLAN trunks, Domain Name System (DNS), IP address management and external backup targets. Don’t leave those vague.

Creating a VM: let images and policy handle the repetitive work

A new HVM workload is provisioned through the Manager’s instance workflow. The administrator selects the HPE-VM instance type, then supplies the relevant group, cloud and environment, along with the VM name, image, CPU, memory, disk, target cluster, network and, where appropriate, a preferred host. Supported image formats documented by HPE include ISO, QCOW2, RAW and VMware formats such as VMDK, OVF and OVA.

The VMware mental model is broadly familiar: choose a template, a compute resource, a datastore and a port group. VM Essentials adds more of a service-catalogue model. Images and service plans can narrow the choices exposed to users or junior administrators. A service plan is essentially a sizing tier. Its value is that new VMs don’t turn into bespoke CPU, RAM and disk negotiations.

Treat the image library as production infrastructure. Keep a small set of current, patched and documented Linux and Windows images; define how initial configuration happens; and make image ownership explicit. Cloud-init is useful for Linux guest customisation, while Windows preparation generally needs its own approach. Provisioning scripts, PowerShell or Bash workflows, IP address management (IPAM) and DNS integrations can reduce manual work, but they are optional integrations, not magic inherited from the hypervisor.

After creation, the familiar actions are available: power control, HTML5 console access, cloning, snapshots, resizing, adding or removing disks, and adding or removing network interfaces. HPE documents reconfiguration of running workloads, but normal change practice still applies. The guest OS and, more importantly, the application may require a rescan, reboot or its own maintenance procedure after a virtual hardware change.

Compute placement: useful automation, not capacity management

VM Essentials can automatically place workloads according to cluster load and live-migrate a running VM between hosts in the same cluster. For VMware administrators, this is the closest operational equivalent to Distributed Resource Scheduler (DRS)-style placement combined with vMotion. Don’t assume identical behaviour in every edge case.

The key per-VM setting is placement strategy. Auto permits the platform to manage placement based on host load. Failover keeps a VM on its chosen host in normal operation but allows it to move if that host is taken out of service or fails. Pinned prevents automatic movement from the selected host. Pinning suits VMs that depend on host-specific hardware passthrough, for example, but it is a resilience trade-off, not a harmless preference.

Affinity groups add an application-aware policy. A Keep Together group attempts to place selected VMs on the same host, which can suit tightly coupled workloads where locality matters. A Keep Separate group attempts to spread members across hosts, usually the more valuable setting for redundant components such as domain controllers or application nodes. “Attempts” matters here: availability recovery and resource pressure can override the ideal placement rule.

Compute allocation needs the same discipline it did in vSphere. Size for credible peak demand, leave enough headroom to absorb a host loss, and don’t mistake a successful deployment for proof that the cluster has spare capacity for maintenance or failure. HPE’s scheduler can distribute what exists. It cannot create CPU cycles or memory in a busy incident.

Storage: choose the datastore model before promising migration or HA

Storage is where an HVM cluster can look deceptively simple. VM Essentials supports several datastore approaches, including local directory pools, Network File System (NFS) pools and GFS2 pools. GFS2, or Global File System 2, is a clustered filesystem designed for shared storage access across cluster nodes. HPE also documents integrations with external NFS, Internet Small Computer Systems Interface (iSCSI) and Fibre Channel storage, and storage-server integrations can make array-backed volumes visible through the management interface.

Each choice has operational consequences:

The VMware translation is simple: live migration and automatic restart are not merely cluster features. VM disks must be accessible wherever the workload needs to run. A local directory pool may be reasonable for a lab, a small isolated service or temporary build capacity. It is the wrong foundation for a workload that must survive host failure without a restore operation.

HPE’s documentation is clear that network and external-storage configuration remains an administrator responsibility before or alongside cluster build. Host-level iSCSI configuration, multipathing, bonds and storage presentation are not replaced by clicking “add datastore” in the Manager. If an organisation standardises on an array-backed design, the storage team still needs to own LUN or volume design, path redundancy, performance expectations and firmware/support compatibility. That matters with platforms such as HPE Alletra MP, but it applies to any external storage platform.

Networking: think port groups, then inspect the abstraction underneath

At the VM layer, the mapping is familiar. An HVM network is presented through a network object with a name, CIDR range, gateway, DNS settings, VLAN ID and optionally an IP pool. CIDR, or Classless Inter-Domain Routing, expresses an IP network range. For a VMware administrator, that is close to a port group backed by a VLAN, with IP address and DNS services tied into provisioning.

Underneath, VM Essentials uses Open vSwitch (OVS) and libvirt. An OVS bridge provides the software-switching domain; the Manager creates a logical network, or port-group-like object, against it. During initial cluster provisioning, the necessary OVS bridges and libvirt networks can be created for provisioning. Adding host interfaces later is less abstract: the interface must exist in the host’s Netplan configuration, then be surfaced through the HPE VM tooling and the cluster refreshed before the Manager can use it.

That is a real difference from a mature vSphere estate. A VLAN presented to every ESXi uplink is usually a vCenter configuration exercise. In VM Essentials, validate physical NICs, Linux bonds, switch trunks and host network configuration first. Separate management, VM traffic, storage traffic and migration traffic where the design and available adapters justify it. Don’t collapse everything into one broad network because a small proof of concept worked.

When a guest cannot communicate, work from the outside in: upstream switch VLAN and trunking, host bond and OVS bridge, VM Essentials network object and VLAN ID, guest NIC attachment, then the guest’s own IP configuration and firewall. That is usually faster than starting at the VM console and guessing.

High availability and maintenance: restart protection isn’t fault tolerance

HVM clusters support automatic failover for eligible running workloads when a host is lost. A VM using Auto or Failover placement can restart on another available host, assuming the remaining cluster, network and storage are healthy. A pinned VM is deliberately excluded from that automatic mobility. This is useful high availability, but it is not VMware Fault Tolerance and does not keep an application continuously available through a host failure. The guest restarts; applications with their own clustering or replication remain responsible for tighter recovery objectives.

Maintenance follows the pattern VMware administrators expect. Put one host into maintenance mode, allow movable workloads to drain, confirm that no pinned or otherwise immovable VM is blocking the operation, patch or service the host, validate it, then return it to service before moving to the next node. HPE’s current operating guidance explicitly recommends updating one HVM host at a time and using HPE-provided repositories; adding arbitrary upstream Ubuntu repositories can create an unsupported configuration.

That deserves emphasis. HVM hosts are Linux systems, but treating them as generic Ubuntu servers can create an awkward support case. Use the supported update path, record Manager and host software versions, and maintain a tested rollback and escalation procedure. Platform administration includes knowing when not to improvise.

Monitoring, troubleshooting and protection: where VM Essentials ends

The Manager provides cluster and host views, workload visibility, resource and performance monitoring, logs, task history and console access. That is a first view of a problem. Start by defining its scope: one guest, one host, a datastore, an HVM cluster or the Manager itself. The answer determines whether to investigate the guest OS, VM configuration, host hardware and agent state, storage pathing, cluster services, OVS networking or the management appliance.

For an unavailable VM, the practical sequence is normally:

• Confirm the VM’s power and placement state, recent task history and console behaviour;
• Check host and cluster health, including whether the host is in maintenance or has lost connectivity;
• Verify datastore availability and storage-path health before attempting repeated power-on actions;
• Validate the VM network attachment and relevant OVS/VLAN path if the guest is running but unreachable;
• Only then move into guest operating-system, application and identity/DNS troubleshooting.

VM Essentials includes native backup, restore, snapshot and recovery capabilities, and HPE documents Veeam integration among its supported management features. Neither a snapshot button nor an integrated backup menu is a recovery strategy. Decide separately on application consistency, retention, off-site or immutable copies, encryption, recovery-point objectives, recovery-time objectives and restoration testing. A database crash-consistent image may be useful; it may also be nowhere near sufficient for the application owner.

For organisations moving selected workloads rather than rebuilding everything at once, VMware Exit Strategy: How to Migrate Using HPE VME or Veeam covers conversion and backup-led migration choices. The operational rule is simpler: don’t retire a VMware VM until the replacement has passed a restore test, a network test and an application-owner acceptance check.

Retirement needs as much care as provisioning

A VM at the end of its useful life is a workload, not just an object to delete. Confirm its owner, backup and retention obligations, attached disks, DNS records, IP reservation, monitoring entries, service accounts and dependencies. Take a final approved backup where policy requires one, shut it down, observe whether anything notices, then remove it and reclaim storage only after the agreed retention point.

It isn’t glamorous administration, but this is where capacity and security improvements often come from. A clean catalogue, current images, accurate ownership metadata and a short list of supported VM sizes are more useful than a sprawling estate of one-off machines nobody will delete.

Bottom line

HPE VM Essentials provides VMware administrators with familiar operational outcomes: provision a VM, connect it to storage and a VLAN, place it across hosts, migrate it for maintenance, restart it after host loss, monitor it and protect it. The less familiar part is where responsibility sits. The Manager is the control surface, but host networking, shared storage, recovery design and supported Linux maintenance remain foundational engineering work.

A worthwhile evaluation tests ordinary work as seriously as initial deployment: host drains, failed-host recovery, disk expansion, network addition, restore and a monitored patch cycle. Part 3, Evaluating HPE VM Essentials in Practice: Costs, Dependencies, Coexistence and Migration Readiness, examines the licensing, hardware, ecosystem and support questions that determine whether those workflows fit a particular organisation.