--- title: "STACKIT VM Target Sizing and Storage Selection" description: "Translate measured VMware demand into STACKIT machine types and Block Storage profiles with explicit headroom, availability, and post-cutover review gates." scfAsset: managed: false category: "guide" external: false tags: ["design-and-mobilize", "design", "relocate", "vmware", "vm", "sizing", "block-storage"] maintainers: - user: "lukas.weberruss" source_url: "https://framework.stackit.cloud/migration/assetcontainer/stackit/stackit-vm-target-sizing-and-storage/" source_file: "docs/migration/assetcontainer/stackit/stackit-vm-target-sizing-and-storage.mdx" --- ## Purpose Use this guide to define the initial STACKIT compute and storage profile for VMware workloads that will be relocated as virtual machines. It converts measured demand into an explicit target mapping without copying provisioned vCPU, memory, or datastore capacity one to one. Initial target sizing protects the migration and cutover. It is not the final optimization decision. Review the profile again after the workload has produced representative telemetry on STACKIT. ## Required evidence Collect measurements over a period that includes normal operation, peak windows, batch processing, backup activity, month-end or seasonal events, and known incidents. - **CPU**: Capture consumed CPU, peak and p95 demand, ready or contention time, and sustained load duration. Do not use provisioned vCPU count as the sole input. - **Memory**: Capture active and consumed memory, working-set peaks, ballooning, swapping, and cache behavior. Do not assume allocated VMware memory is continuously required. - **Storage capacity**: Capture used capacity, growth rate, retention, snapshot, backup, and temporary workspace needs. Do not migrate abandoned snapshots or unused disks without review. - **Storage performance**: Capture read and write IOPS, throughput, latency, queue depth, block size, and peak duration per disk. Do not select a class from capacity or average IOPS alone. - **Network**: Capture ingress, egress, connection count, burst profile, latency, and packet-loss sensitivity. Include backup and replication traffic. - **Availability**: Capture recovery objectives, failure-domain requirements, maintenance tolerance, and restart behavior. Do not treat a larger VM as an availability design. Document the source, time range, percentile, missing samples, growth assumptions, and confidence for every measurement. Apply a named safety margin where the evidence is incomplete instead of hiding uncertainty in an oversized target. ## Select a STACKIT machine type STACKIT machine types are predefined hardware configurations. Individual vCPU and RAM combinations cannot be assembled beyond the offered variants, so selection is a two-dimensional fit rather than a direct conversion of the VMware configuration. ### Understand the type name > From the STACKIT docs: [Machine types - EU01 › Machine type names](https://docs.stackit.cloud/products/compute-engine/server/basics/machine-types/#machine-type-names) (Source updated 24.07.2026, copied 05.10.2026) Example of a machine type name: `c1a.8d` The first part of the name, e.g. “**c**1a.8d”, is the variant of a machine type. Currently, there are the following variants: | Variant | Description | | --- | --- | | t | Smaller instances with smaller CPU and less RAM | | s | Processor-optimized instances with a CPU/RAM-ratio of 1:1 | | c | Processor-optimized instances with a CPU/RAM-ratio of 1:2 | | g | General instances with a CPU/RAM-ratio of 1:4 | | m | Memory-optimized instances with a CPU/RAM-ratio of 1:8 | | b | Large, memory-optimized instances with CPU/RAM-ratio of 1:16 or higher | | n | Instances with NVIDIA GPUs | The generation, processor architecture, available sizes, and exact memory values vary by region and can change over time. Resolve the current catalog in the target region before approving a wave. ### Selection method 1. Convert CPU measurements into required target cores for the design load, then add explicit peak, growth, and measurement-confidence headroom. 2. Convert the observed memory working set into required RAM and add headroom for guest overhead, cache behavior, growth, and cutover uncertainty. 3. Identify the machine-type family whose CPU-to-memory ratio wastes the least capacity while meeting both requirements. 4. Select the smallest current type in that family that satisfies CPU and RAM simultaneously; record which dimension determines the size. 5. Decide explicitly between CPU-overprovisioned and `d` types. Prefer a non-overprovisioned type when sustained CPU demand, latency sensitivity, or observed contention makes predictable CPU access a requirement. 6. Validate processor architecture, operating-system support, licensing, availability-zone placement, quotas, and maintenance behavior. 7. Test the selected type with a representative pilot and preserve the next larger and smaller valid types for rollback and later rightsizing decisions. Do not infer equivalent performance from vCPU count alone. Processor generation, overprovisioning, guest drivers, workload concurrency, and source contention all influence the observed result. ## Select Block Storage Treat storage capacity, performance, and availability as separate decisions. ### Capacity and placement 1. Size each root and data volume from used data, expected growth, file-system needs, snapshots, backup behavior, and temporary migration workspace. 2. Keep disks separate where workload consistency, backup policy, performance isolation, or future growth requires independent control. 3. Choose Single AZ or Metro according to the workload's failure-domain design. Metro volumes are mirrored across availability zones; this does not remove the need for backups or application-level recovery design. ### Performance class A STACKIT Block Storage performance class defines the maximum IOPS and throughput for the complete volume. The class is independent of volume size, and all consumers of that volume, including VM and backup reads, share its performance envelope. 1. Establish required read and write IOPS, throughput, latency, block-size distribution, and concurrency for each target volume. 2. Add explicit peak, backup, recovery, and growth headroom to IOPS and throughput independently. 3. Select the lowest current performance class that satisfies both limits. A class that passes IOPS but fails throughput, or the reverse, is not sufficient. 4. Validate the choice during replication and isolated test migration, when copy traffic may expose a different bottleneck from normal application operation. 5. Record observed latency, I/O wait, queue depth, IOPS, and throughput after cutover for the Optimize review. > From the STACKIT docs: [Service plans › Currently available Service Plans (performance classes)](https://docs.stackit.cloud/products/storage/block-storage/basics/service-plans/#currently-available-service-plans-performance-classes) (Source updated 22.04.2026, copied 05.10.2026) The following table lists currently available performance classes for the EU01 region: | Performance class | Name | Max. IOPS | Max. Throughput (MB/s) | | --- | --- | --- | --- | | Performance class 0 | storage_premium_perf0 | 120 | 25 | | Performance class 1 | storage_premium_perf1 | 500 | 50 | | Performance class 2 | storage_premium_perf2 | 1000 | 100 | | Performance class 4 | storage_premium_perf4 | 2000 | 150 | | Performance class 6 | storage_premium_perf6 | 5000 | 200 | | Performance class 8 | storage_premium_perf8 | 10000 | 250 | | Performance class 10 | storage_premium_perf10 | 15000 | 300 | | Performance class 12 | storage_premium_perf12 | 20000 | 350 | | Performance class 13 | storage_premium_perf13 | 20000 | 700 | | Performance class 14 | storage_premium_perf14 | 25000 | 400 | | Performance class 15 | storage_premium_perf15 | 25000 | 800 | | Performance class 16 | storage_premium_perf16 | 30000 | 450 | | Performance class 17 | storage_premium_perf17 | 30000 | 900 | | Performance class 18 | storage_premium_perf18 | 35000 | 500 | | Performance class 19 | storage_premium_perf19 | 35000 | 1000 | | Performance class 20 | storage_premium_perf20 | 40000 | 550 | | Performance class 21 | storage_premium_perf21 | 40000 | 1100 | | Performance class 29 | storage_premium_perf29 | 60000 | 1500 | IOPS - Input/Output Operations per second Throughput - Throughput in Megabytes per second Thus, the classes used can be distinguished in detail based on the naming. Example: “Block Storage Premium - Performance Class 2” corresponds to SSD hard disks with max. 1000 IOPS and max. 100 Mbyte/s throughput. The table shows the EU01 catalog. Always resolve the current values for the target region. ## Target mapping record Create one version-controlled mapping row per VM and volume. - **Source VM and workload**: Stable inventory identifier and application mapping. - **Target region and placement**: Region, availability zone or Metro requirement, and quota result. - **Machine type**: Exact type, CPU and RAM requirement, governing dimension, headroom, and overprovisioning decision. - **Root volume**: Capacity, performance class, boot assumptions, and recovery assumptions. - **Data volumes**: Source-to-target disk mapping, capacity, performance class, and consistency group. - **Network**: Target network, addresses, security groups, DNS, and bandwidth expectation. - **Validation thresholds**: CPU, memory, latency, IOPS, throughput, application SLO, and observation window. - **Adjustment options**: Approved larger and smaller type, storage alternative, change method, and rollback condition. Approve the mapping only when the target profile, expected cost, quota, tool mapping, and acceptance thresholds are all known. Feed the exact mapping into the Coriolis or Acura test migration rather than choosing target resources during cutover. ## Primary references