SkyVirtHCI
DocumentationMigrateCompareRoadmapBlogTeamPortalDownloadDatasheet (PDF)

Administration

Virtual machines

The VM is the centre of the platform, and its whole lifecycle lives in one place: create from an image or template, resize, snapshot, clone, migrate, retire. A few details that matter in practice:

  • Live migration moves a running VM between hosts with no interruption. Because storage is shared, only memory state moves — it's quick and safe to do at 2 PM.
  • Snapshots capture a point in time; scheduled snapshot policies keep a rolling window automatically. Application-consistent mode briefly quiesces the guest so databases come back clean.
  • Templates are versioned. Update a template and you can still trace which VMs came from which version.
  • Placement is automatic by default. Affinity and anti-affinity rules pin VMs together or keep them apart (for example, two database replicas on different hosts). A dynamic balancer can spread load continuously if you let it.
  • High availability restarts a failed host's VMs elsewhere. Admission control refuses new workloads that would eat the failover headroom — better to hear "no" at creation time than at 3 AM.

Networking

Networks are defined in software and exist instantly across every host:

  • Virtual networks with built-in address management and optional routers between them.
  • Security groups — per-VM firewall rules, applied at the virtual port, managed as named policies.
  • Load balancers distribute traffic across a set of VMs with health checks.
  • Floating IPs give a VM a stable public-facing address you can move between VMs in one action.
  • VLANs map virtual networks onto your physical network segments where you need them to meet the outside world.
  • Port mirroring copies a VM's traffic to an analysis VM — invaluable for debugging and security work.

Storage — SkyVirtStore

SkyVirtStore is the platform's own software-defined storage engine, built end to end in-house. It turns the data disks in every host into one replicated, self-healing pool — there is no storage appliance to buy and nothing to wire up. A few things worth knowing:

  • Per-disk protection you change live. Each disk chooses single, 2-way or 3-way mirroring, and you can raise or lower it on a running workload with no downtime. Every write lands on more than one host before the application sees success.
  • It heals itself. If a host dies, a synchronized replica takes over within seconds and fences the old primary; when the host returns it re-syncs only the changed blocks and rejoins the mirror. A failed disk re-replicates automatically.
  • It stretches what you buy. Inline deduplication and compression cut real capacity use; a flash tier keeps hot data fast; replication can run on its own dedicated network.
  • Datastores organise the pool into named areas with their own placement and quota policies. Most installations use one default datastore and stop thinking about it.
  • Volumes are standalone disks you attach to and detach from VMs as needed, and the same pool serves persistent volumes to your Kubernetes clusters.
  • External storage — existing NFS shares and block-storage arrays can be attached alongside SkyVirtStore, useful during transitions or for special workloads.
  • Quotas cap how much storage a tenant or project can consume.

Containers and Kubernetes

Containers run beside VMs on the same hosts and networks — handy for small services that don't deserve a whole VM. And Kubernetes is built in: provision a complete cluster in minutes, manage it visually with the included SkyVirt KubeUI dashboard, and back its stateful workloads with persistent volumes from SkyVirtStore. It has its own guide: Kubernetes & KubeUI →

Tenants, projects and quotas

Tenants are hard boundaries: separate users, separate resources, separate networks. Projects subdivide a tenant for teams or applications. Quotas — CPU, memory, storage, network resources — apply at either level. The combination lets one cluster serve many masters without anyone stepping on anyone else.

Resource pools

Where quotas are flat per-project ceilings, resource pools carve the cluster's compute into named, optionally nested slices — a natural fit when several teams, classes or environments share one cluster and each needs a fair, bounded portion.

  • Limits are hard ceilings on a pool's CPU and memory. A virtual machine is admitted to a pool only if it fits — counting what the pool already holds, and checked all the way up through any parent pools. The answer comes at creation time, not after the cluster is already overcommitted.
  • Reservations set a guaranteed minimum a pool can always claim, so a busy neighbour can't starve a pool that was promised capacity.
  • Hierarchy lets a parent pool (say, a department) bound several child pools (its teams): each child is free to organise itself, but the parent's limit caps the whole subtree.
  • Opt-in. A VM placed in no pool is unconstrained, so pools can be introduced on a live cluster without disturbing existing workloads.

Each pool shows live usage against its limit, so it's obvious at a glance how much of a team's allocation is in use.