Server Operations¶

Advanced server management operations for virtual machines in HPE Morpheus Software.

Server Migration¶

Overview¶

HPE Morpheus Software supports migrating virtual machines between hosts, clusters, or resource pools within a cloud. The migration (also referred to as VM Move) allows you to relocate a workload to a different compute target without reprovisioning.

Migration is supported for cloud types that provide native VM mobility, such as VMware vSphere (vMotion), Nutanix AHV, and other hypervisor platforms.

Role Requirements¶

• Infrastructure: Compute role permission at Full level is required to perform migrations.

Migrating a Server¶

1. Navigate to Infrastructure > Compute > Virtual Machines or to the server detail page

2. Select the target server

3. Click ACTIONS

4. Select Migrate

5. In the migration dialog, configure:

   TARGET HOST

   Select the destination hypervisor host. Available hosts are filtered based on the server’s current cloud and compatibility.

   TARGET RESOURCE POOL

   Select the destination resource pool or cluster (if applicable). This may be required for cross-cluster migrations.

   TARGET DATASTORE

   Select the destination datastore for the VM’s storage (for storage migrations or combined compute+storage moves).

   PRIORITY

   Migration priority level (where supported by the hypervisor):

   • Low — Background migration with minimal impact

   • Normal — Standard priority

   • High — Prioritized migration

6. Click EXECUTE

The migration operation runs asynchronously. Progress can be monitored on the server’s History tab.

Migration Types¶

Live Migration (vMotion)

The VM is moved while running, with no downtime. Requires shared storage or storage vMotion capability between source and destination hosts.

Cold Migration

The VM is powered off, moved to the new location, and optionally powered back on. Used when live migration prerequisites are not met.

Storage Migration

Only the VM’s storage is relocated to a different datastore. The VM remains on the same host.

For HVM/KVM clusters, use Actions > Move on the Instance or VM detail page to relocate a VM to another host or HVM cluster. Cross-cluster moves map datastores and networks on the destination cluster. This is not a VMware-to-HVM conversion. See VM Migration & Failover.

Monitoring Migration Status¶

Migration operations appear in the server’s History tab with status indicators:

• Running — Migration is in progress

• Complete — Migration finished successfully

• Failed — Migration encountered an error (check event details for the failure reason)

VME Migration: LVM and Source SCSI Disks¶

Before migrating a VM that uses Linux LVM, record the source physical volumes, volume groups, logical volumes, mount points, boot volume, and the controller and unit number for every virtual disk. Confirm that all required source disks are included in the migration plan and mapped to destination datastores with at least the source capacity. The guest must be able to load the destination storage driver and discover every volume required for boot and application data.

The migration planner preserves source controller bus and unit mappings where they are available. When a source VM has any SCSI-backed volume, the HVM destination uses a VirtIO-SCSI controller for the post-conversion disk mapping; otherwise it uses VirtIO Block. Windows migrations that install guest tools boot initially from SATA while VirtIO drivers are registered, then stop the destination VM and move its disks to the selected paravirtual controller. Do not manually change controller mappings while that migration is running.

The legacy LVM Migration backup type is a separate, deprecated workflow. Its implementation requires SSH and sudo access to source and destination, lvm2 and pv, an explicitly selected source logical-volume device, enough free space in the source volume group for an LVM snapshot, a writable destination data device, and key-based transfer connectivity from source to destination. It copies a single selected logical-volume snapshot and is not evidence that arbitrary multi-PV, thin-pool, encrypted, clustered, or nested LVM layouts are supported.

After migration, verify that the destination boots from the expected controller, every expected disk is present at the intended bus/unit mapping, all volume groups and logical volumes activate, filesystems mount, and application data is accessible. If discovery does not match the recorded source layout, stop validation and retain the source VM; do not invent device-renaming or bootloader repair steps.

Server Placement¶

Overview¶

Server Placement in HPE Morpheus Software controls which host, cluster, or resource pool a virtual machine is assigned to within a cloud. Placement configuration can be set during provisioning or updated post-provisioning to optimize resource utilization across the infrastructure.

Placement settings work in conjunction with cloud resource pool configurations and can be influenced by Host-VM Groups (affinity and anti-affinity rules).

Configuring Placement¶

During Provisioning¶

When provisioning a new instance, placement is configured in the Configure step:

CLOUD

The target cloud determines available placement options.

RESOURCE POOL

Select a resource pool or cluster. This defines the boundary within which the VM will be placed.

HOST

(Optional) When manual host selection is enabled, a specific host can be chosen. If left as auto-select, HPE Morpheus Software or the hypervisor will determine optimal placement.

Updating Placement Post-Provisioning¶

To change a server’s placement after provisioning:

1. Navigate to the server detail page

2. Click ACTIONS

3. Select Change Cloud or Placement

4. Update the placement configuration:

   CLOUD

   The target cloud (for cross-cloud placement changes).

   RESOURCE POOL

   The destination resource pool or cluster.

5. Click SAVE

Automatic Placement¶

When no specific host is selected, HPE Morpheus Software works with the underlying hypervisor’s placement engine:

• VMware DRS — When DRS is enabled, VMware handles optimal host placement within a cluster.

• Nutanix ADS — Acropolis Dynamic Scheduling distributes VMs across hosts.

• KVM/MVM — HPE Morpheus Software selects the host with the most available resources in the target pool.

Host-VM Group Integration¶

Server placement can be further controlled through Host-VM Groups, which define affinity and anti-affinity rules. See Host-VM Groups for details on configuring these rules.

Server Devices¶

Overview¶

Server Devices in HPE Morpheus Software represent physical or virtual hardware peripherals (such as GPUs, PCIe devices, USB devices, or other passthrough hardware) that can be attached to or detached from virtual machines. Device management is used for hardware passthrough scenarios where VMs need direct access to physical devices on the host.

Role Requirements¶

• Infrastructure: Compute role permission at Full level is required to attach, detach, or assign devices.

Viewing Devices¶

1. Navigate to the server detail page

2. Select the DEVICES tab (where available)

The Devices tab displays all hardware devices currently associated with the server, including:

• Name — Device name or identifier

• Type — Device type (GPU, PCIe, USB, etc.)

• Status — Connection status (attached/detached)

Attaching a Device¶

1. Navigate to the server detail page

2. Click ACTIONS

3. Select Attach Device

4. In the device dialog, configure:

   DEVICE

   Select from available devices on the host. Only unassigned devices compatible with the VM are shown.

5. Click SAVE

Detaching a Device¶

1. Navigate to the server detail page

2. Select the DEVICES tab

3. Click the detach icon next to the device

4. Confirm the detachment

Assigning a Device to a Server¶

For scenarios where a device needs to be pre-assigned to a server (reserving it for future use):

1. Navigate to the server detail page

2. Click ACTIONS

3. Select Assign Device

4. Select the device to assign

5. Click SAVE

Assigned devices are reserved for the specified server and will not be available for other VMs.

Supported Device Types¶

The availability of device management depends on the cloud and hypervisor type:

• VMware vSphere — PCI/PCIe passthrough, vGPU, DirectPath I/O devices

• HVM/KVM — PCI passthrough, USB devices, whole-GPU passthrough, and NVIDIA SR-IOV vGPU profiles. See NVIDIA vGPU Slicing for vGPU prerequisites and lifecycle constraints

• Nutanix AHV — GPU passthrough devices