TOORCE HV
Technology & Business Proposition
Key features · Added value · Competitive positioning
1. Executive summary
TOORCE HV is a Type-1 (bare-metal) hypervisor with an integrated web console. It targets organizations that want enterprise-grade isolation and resilience without forcing homogeneous server fleets, expensive shared-storage clusters, or complex multi-product stacks for tenancy and licensing control.
Six capabilities define the product story:
- Type-1 hypervisor — guests run on Permital Hypervisor; the control plane is a thin management domain.
- Resource profiles — per-account caps on RAM, CPU, disk, and ISO usage.
- Folder-based storage — labeled folders inside datastores for disks and media.
- Toorce Virtual Disk (TVD) — guest disk mirrored/synced across 2–8 physical paths.
- Clustering over non-identical servers — datacenter clusters without identical SKUs.
- CPU core isolation — hard pin guest vCPUs to selected host cores (Oracle license hygiene).
Together they reduce CapEx (reuse mixed hardware), OpEx (one console), and software license risk (bounded cores), while offering storage resilience without buying a separate HCI or SAN product for every workload.
2. Technology foundation
2.1 Type-1 hypervisor
| Aspect | TOORCE HV |
|---|---|
| Class | Type-1 (bare metal) |
| Core | Permital Hypervisor + Debian-based appliance |
| Control plane | Hosts the console, storage, and networking |
| Guests | HVM guests (64-bit and 32-bit variants as exposed by the host) |
| Management | Built-in HTTPS console on the host |
Added value vs Type-2 / nested stacks
- Lower overhead and clearer performance ceiling than “hypervisor inside a general-purpose OS.”
- Stronger isolation boundary for multi-tenant or regulated workloads.
- Appliance model: install once, manage from the browser—no separate vCenter-class server required to start.
Compared with others
| Approach | Typical products | Trade-off | TOORCE position |
|---|---|---|---|
| Type-1 commercial | VMware ESXi, Citrix Hypervisor / XenServer | Mature ecosystem; license and hardware certification cost | Same class of isolation; simpler appliance packaging |
| Type-1 open | Proxmox (KVM), XCP-ng | Flexible; ops skill and DIY integration | Guided console + product features (TVD, profiles, folders) |
| Type-2 / hosted | Workstation, nested clouds | Easy desktop use; not a server platform | Not the target; TOORCE is for hosts |
2.2 Resource profiles
A resource profile caps the total memory, processors, disk, and ISO storage of every virtual machine an account owns. Profiles also scope bridges and which ISO/templates from the main datastore the account may use. Console users are assigned a profile (and optionally a VM management role for broader pages).
Business value
- Safe self-service: give developers or departments a login without over-consuming the host.
- Chargeback / showback ready: clear numeric caps per tenant.
- Less admin toil: no need to babysit every VM create when caps are enforced.
Compared with others
| Platform | Tenancy / quotas | Gap TOORCE closes |
|---|---|---|
| VMware | Resource pools, vSphere permissions, often needs vCenter + design | Profiles are first-class in the host console for account-owned VM totals |
| Proxmox | Users/ACLs; quotas vary by setup | Opinionated “profile = caps” without assembling ACL + pool recipes |
| Public cloud | Hard quotas by design | Same idea, on-prem and under your control |
2.3 Folder-based storage
Datastores remain separate devices or shares. Inside each mounted datastore, operators create folders with display names. VM disks, ISOs, and templates can be placed in a folder rather than only at the root. Moves and backups can target datastore + folder.
Business value
- Organize by project, customer, or environment without carving new LUNs for every team.
- Cleaner ISO libraries and fewer “mystery files” at the datastore root.
- Works with mixed backends (local disk, USB, NFS, iSCSI, FC, NVMe)—folders are a layout convention on top of whatever you already attach.
Compared with others
| Platform | Organization model | TOORCE difference |
|---|---|---|
| VMware | Datastores + folders/tags in inventory | Folder layout lives with the files on the datastore the operator opens |
| Proxmox | Storage + directories / content types | Explicit folder UX for disks and media placement |
| Pure SAN/HCI | Volumes / vVols / policies | No forced cluster filesystem; folders work on ordinary mounts |
2.4 Toorce Virtual Disk (TVD)
TVD presents one virtual disk to the guest while writing across 2 to 8 storage paths on different physical disks, kept in sync:
- 2 paths → mirrored sync (RAID1): survive one path failure.
- 3+ paths → synced stripe with single failure tolerance (RAID5).
- 4+ paths → option to survive two failures (RAID6), with less usable capacity for the guest.
Paths must sit on different physical disks. They may use different datastores/folders (local or attached). Snapshot and backup can copy the assembled volume or each leg.
Business value
- Resilience without a SAN: protect important VMs using disks you already have.
- No guest-side RAID: the OS sees one disk; TOORCE handles sync.
- Cost control: avoid buying HCI or dual-controller arrays only for a handful of critical guests.
Compared with others
| Approach | Examples | Cost / complexity | TOORCE TVD |
|---|---|---|---|
| Shared SAN/NAS | Fibre Channel, iSCSI arrays | High CapEx; array skills | Optional; TVD can use local + attached paths |
| HCI / vSAN-class | VMware vSAN, similar | Cluster licensing, identical nodes often preferred | Per-VM sync across paths; no full-cluster HCI tax |
| Guest RAID / mdadm in VM | DIY | Guest complexity; wrong failure domain | Hypervisor-managed; guest stays simple |
| Replication products | Storage vendor mirror | Extra SKUs | Built into VM disk choice |
2.5 Clustering over non-identical servers
Datacenter clusters group hosts with a shared UUID, secret, cluster interfaces, optional VIP, and coordinator. Members join without requiring identical CPU models, memory sizes, or matching server SKUs.
Business value
- Reuse existing hardware: refresh one node at a time; mix generations.
- Lower barrier to HA-style operations: start clustering without a forklift upgrade to a uniform blade chassis.
- Realistic SMB / mid-market fit: most sites do not have two identical servers sitting idle.
Compared with others
| Platform | Homogeneity pressure | TOORCE position |
|---|---|---|
| VMware clusters | EVC, compatible CPUs, certified HCL; mixed fleets need careful design | Clustering does not demand identical servers as a product prerequisite |
| HCI stacks | Often want matched nodes for balance | Mixed hosts remain first-class |
| Proxmox / XCP-ng clusters | Possible on mixed HW; ops must know limits | Product messaging and console flow assume mixed fleets |
> Note: Live migration and advanced HA still depend on CPU features, shared storage, and workload constraints. Non-identical clustering removes the “buy two of the same” barrier for joining the datacenter fabric; capacity planning remains the operator’s job.
2.6 CPU core isolation (Oracle licensing)
Enable Pin processors to selected host cores on the VM. Each guest vCPU stays on a chosen host logical core (numeric order) and does not float across the rest of the package.
Why Oracle buyers care
Oracle Processor licensing often keys off processors/cores available to the software. Soft affinity or unrestricted scheduling can make auditors count a wider core set. Hard pinning to a documented subset of host cores supports a clearer licensing boundary when your agreement and Oracle’s policies allow sub-capacity style control on that platform.
Business value
- Reduce risk of over-counting cores for Oracle Database and related products.
- Pair with sockets/cores topology settings so the guest presents a believable CPU layout.
- Evidence-friendly: pin map is stored with the VM configuration (
# toorce_cpupin).
Compared with others
| Platform | Isolation tools | TOORCE angle |
|---|---|---|
| VMware | CPU affinity (often restricted; cluster features vary) | Explicit pin UI on the appliance VM form |
| KVM/Proxmox | cpuset / affinity via config | Same class of control; TOORCE exposes it as a first-class checkbox + core picker |
| Bare metal Oracle | Physical server = full socket count | Virtualization + pin can shrink the licensed set when policy allows |
Compliance disclaimer: Licensing rules change and depend on contract, edition, and Oracle’s partitioning policy. TOORCE HV supplies technical isolation; customers must validate the licensing outcome with Oracle or a qualified advisor.
3. Feature → value map
| Feature | Technical outcome | Business outcome |
|---|---|---|
| Type-1 hypervisor | Bare-metal isolation, control plane | Performance + security posture of a real hypervisor |
| Resource profiles | Hard caps per account | Safe multi-team use; predictable capacity |
| Folder-based storage | Labeled dirs on datastores | Organize without extra LUNs |
| Toorce Virtual Disk | md-backed multi-path guest disk | Resilience without mandatory SAN/HCI |
| Non-identical clustering | Cluster join across mixed hosts | CapEx flexibility; gradual refresh |
| CPU core isolation | Hard pin to host cores | Oracle / processor-license hygiene |
4. Competitive snapshot
| Need | Typical alternative | TOORCE HV answer |
|---|---|---|
| Enterprise Type-1 | ESXi + vCenter | Permital Hypervisor Type-1 + on-box console |
| Tenant quotas | Resource pools + IAM design | Resource profiles on users |
| Disk/layout hygiene | Tags, content types, extra volumes | Folder-based storage |
| VM disk resilience | SAN mirror / vSAN / guest RAID | Toorce Virtual Disk (2–8 paths) |
| Cluster of old + new servers | Buy matched pairs or fight EVC | Cluster over non-identical servers |
| Oracle core control | Affinity docs + hope | Pin processors to selected host cores |
5. Business proposition (one-pager)
For mid-market and enterprise teams that run Oracle or other core-licensed software on virtual machines, and that own mixed server hardware,
TOORCE HV is a Type-1 hypervisor appliance that
- isolates guests on Permital Hypervisor with a single web console,
- enforces resource profiles for self-service without overcommit chaos,
- organizes capacity with folder-based storage,
- protects critical disks with Toorce Virtual Disk across ordinary disks and datastores,
- forms datacenter clusters on non-identical servers, and
- pins CPU cores so Oracle-style processor licensing can be bounded and documented,
Unlike stacks that push homogeneous HCI nodes, mandatory shared SAN, or heavyweight management servers,
We deliver resilience, tenancy, and license-aware CPU isolation as product features of the hypervisor itself—so customers stretch existing hardware further and keep license and storage spend under control.
6. Proof points to show in demos
- Sign in → Hypervisor status (Type-1 host live).
- Create folders on a datastore; place an ISO and a disk path.
- Create two console users with different resource profiles; show a cap rejection.
- Create a VM disk as Toorce Virtual Disk across two physical paths; show sync layout.
- Pin a guest to a subset of host cores; show the pin list on the hardware form.
- Create a cluster on host A; join host B with a different CPU/memory size using UUID + secret.
Screenshots for these flows live in docs/images/ and are narrated in 01-product-guide.md.