Organizations comparing VMware alternatives may need to preserve suitable resources while preparing for new workloads. ZStack’s white paper frames this value on page 21 and describes an anonymized telecommunications operator’s city AI computing center on page 47. The case covers heterogeneous compute and AI service operations, not a completed VMware migration.
What Did the Operator Need from Its New Infrastructure?
Large models, AI education, and industry digitalization brought new requests. Meeting them meant connecting regional capacity and making that capacity available for rental, with scheduling suited to different workloads.
Meet Growing Demand for AI Computing Services
A city-level AI computing center was the operator’s response to the growing range of AI requests from its customers. The goal was to make regional capacity available through a managed service, with flexible scheduling and commercial operations. That requirement brought together infrastructure, resource allocation, and tenant-facing service delivery.
Combine Existing GPUs with New Heterogeneous Resources
The project needed to continue using suitable existing GPU resources while connecting new devices. CPU, GPU, and domestic accelerator resources fell within the proposed management scope. The documented scale was dozens of compute devices and hundreds of GPU cards. Those are the available figures: neither an exact device inventory nor a card-by-card breakdown was published for this particular deployment.
How Did ZStack AIOS and Zaku Bring Resources Together?
The case states that the operator used ZStack AIOS and ZStack Zaku to build an AI infrastructure platform and a unified resource pool. The described design brings existing and new accelerator resources under common management while leaving room for different workload delivery models.
Pool Different Types of Computing Resources
The white paper names NVIDIA, Huawei Ascend, Hygon DCU, and Cambricon MLU among the managed device types. The platform unified these heterogeneous nodes into a resource pool that operators could manage and schedule. A shared management view leaves chip differences intact; model compatibility and task placement still depend on the accelerator underneath.
For a ZStack AIOS evaluation, start with the intended device list. Driver and framework checks, placement tests, and operating procedures should all refer to those models.
Retain VM Workloads While Adding New Delivery Options
The case says existing virtual-machine business could continue using its original GPU resources. For new AI workloads, the choices were containers, elastic bare metal, GPU passthrough, and GPU virtualization; performance and isolation determined delivery. Existing services could therefore remain while new services used a different delivery model.
How Were GPU Resources Matched to Different Workloads?
Training, inference, and development or testing called for different resource sizes here. The service distinction was the resource offered to each task. No published benchmark quantifies a performance uplift or percentage improvement in utilization.
Dedicated Resources for Performance-Sensitive Training
Training customers had three options: full systems, bare metal, or dedicated GPU resources. Each option puts performance and isolation requirements ahead of sharing capacity between smaller jobs. Dedicated capacity alone cannot settle sizing. A training benchmark needs to show whether the assigned hardware can meet the service objective for that workload.
Flexible Allocation for Inference and Development
For inference and development or testing, the case describes single-GPU allocation and GPU-memory partitioning. Smaller tasks could request an allocation below the whole-system level while using the underlying infrastructure pool. The allocation is more granular; whether it uses capacity efficiently depends on the task, isolation requirements, hardware support, and scheduling decisions.
How Did the Operator Turn Infrastructure into a Computing Service?
An operations portal brought tenant billing, resource monitoring, and resource views into the service. External customers could request capacity through it, while the operator retained a process for allocating resources and accounting for their use.
Monitor Capacity and Allocation from One Operational View
The central view showed node capacity, GPU-card assignments, and their operating status. Operators could use that view to schedule resources or administer the heterogeneous fleet. The monitoring described concerns infrastructure resources. Application-performance monitoring has a different scope, and its depth is not documented in this case.
Support Tenant Requests and Usage-Based Metering
External customers could request computing specifications through a unified entry point. Tenant, resource type, and usage formed the basis of the metering. Onboarding fed the resource pool; scheduling assigned capacity; delivery gave customers access; metering recorded consumption. Together, those steps established a service operation around the AI center’s hardware and resource capacity.
What Does This Case Suggest for VMware Replacement Planning?
Page 21 frames VMware replacement around safe transition, continued value from existing infrastructure, unified management, and a path toward future AI services. Page 47 provides a specific example of existing GPU resources retained alongside new heterogeneous compute. For planning purposes, distinguish the resources actually deployed here from the wider capabilities in that framework.
Preserve Existing Investments Where They Remain Suitable
Page 21 emphasizes enabling existing server, storage, and network resources to continue providing value where appropriate. In the page 47 case, the specific documented example is the continued use of existing GPU resources by VM workloads. It does not establish that the operator reused all servers, SAN systems, or network devices.
Plan for VMs, Containers, Bare Metal, and AI Together
The page 21 unified-platform idea can be read alongside page 47’s VMs, containers, elastic bare metal, passthrough, and virtualized GPU delivery options. A platform shortlist can account for both: the virtualization services needed and the AI capacity being considered next. The deployment sequence can follow demand; all capabilities need not arrive at once.
If VMware replacement is in scope, assess it as its own migration workstream and align it with the future roadmap. ZStack’s VMware migration solution provides a place to review that offering without treating this AI infrastructure case as migration evidence.
Separate Demonstrated Results from Broader Platform Possibilities
Heterogeneous resource management, flexible GPU allocation, and tenant operations are parts of this deployment. The broader framework on page 21 additionally covers model services, AI applications, security, and audit capabilities. For the anonymous operator, those additional capabilities remain outside the documented results. Their inclusion in a platform framework cannot establish deployment.
Which Outcomes Are Supported by the Case?
The white paper’s case summary groups the outcomes under faster computing-resource delivery, refined GPU allocation, and unified AI-computing operations. The detail supports it: different delivery modes, fine-grained allocations, central management, and metering. It supplies no migration success rate, downtime measurement, savings calculation, or ROI figure.
More Flexible Computing Resource Delivery
VMs, containers, elastic bare metal, GPU passthrough, and other described options let the operator address training, inference, and development or testing scenarios with different resource forms. This is evidence of flexible service delivery in the case, not a quantified claim about deployment speed.
More Granular Resource Allocation and Unified Operations
Single-card and memory-level partitioning support more granular GPU allocation, while centralized monitoring, portal access, tenant management, and usage metering support unified operations. That is the service model documented for this computing center. No migration success rate, downtime reduction, savings amount, or return on investment is reported for this project.
The ZStack Zaku overview provides context for the container platform named in the case. Confirm product scope and hardware compatibility for a proposed deployment.
FAQ
Can ZStack Support Existing VM Workloads Alongside AI Services?
The case describes existing VM workloads continuing to use their original GPU resources while new AI services use containers, elastic bare metal, GPU passthrough, or GPU virtualization. Elsewhere, the hardware support and workload requirements would need an assessment.
Can ZStack Manage GPUs from Different Vendors?
NVIDIA, Ascend, Hygon DCU, and Cambricon MLU appear in the deployment. Compatibility testing must cover the selected devices, drivers, frameworks, and intended workloads.
How Do ZStack AIOS and Zaku Work Together in This Case?
The white paper identifies AIOS and Zaku together as the platform used to build the AI infrastructure, unify resources, and support container-based workloads. For another architecture, establish each product’s responsibilities and configuration before selecting components.
Can ZStack Support GPU Rental and Tenant Metering?
The case describes a unified portal for customer resource requests and management that measures usage by tenant, resource type, and consumption. Each deployment needs its own catalog, allocation rules, billing, and governance.
Does This Case Prove a Completed VMware Migration?
No. Page 47 documents a heterogeneous AI computing center and resource operations. A VMware migration process and a completed VMware migration are not documented in the case account. It informs the future infrastructure requirements that can accompany an evaluation of alternative platforms.
Take the Next Step of VMware Migration with ZStack
Reading about migration is one thing — running an enterprise-grade private cloud is another. Whether you're facing VMware licensing renewal pressure, budgeting a hardware refresh, or simply planning a risk-free evaluation, ZStack makes the next step easy:
Download the VMware Alternative Whitepaper — a practicle technical guide covering architecture comparison, TCO analysis, and a step-by-step migration framework.
Book a Free Migration Assessment — our architects will review your current vSphere environment (hosts, VMs, storage, network) and deliver a tailored migration plan with effort estimates — no obligation.
Talk to a ZStack Engineer — get answers on licensing, compatibility, HA/DR design, and support SLAs in a consult session.
Over 1,000 customers have completed VMware replacement with ZStack.Your VMware exit can be a planned, tested, and fully supported journey.