Compute Disks and images field-manual-complete field-manual operator-field-manual

VM host caching

VM host caching is a setting on a VM disk attachment that decides whether Azure should use cache storage near the host for that disk. ReadOnly caching can help read-heavy workloads, None is common for write-heavy or log disks, and ReadWrite requires applications that safely handle cached writes. It is not a universal speed switch. The right choice depends on the workload, disk role, VM size cache limits, and whether losing or delaying cached writes would harm data integrity.

Back to glossary browser Open Microsoft Learn source
Aliases
Azure disk host caching, disk caching, VM disk caching, ReadOnly caching, ReadWrite caching
Difficulty
intermediate
CLI mappings
5
Last verified
2026-05-28

Microsoft Learn

VM host caching is a disk setting that lets an attached Azure VM disk use cache storage on the host for selected read or write paths. Common modes are None, ReadOnly, and ReadWrite, and the right choice depends on disk role, workload I/O pattern, and durability needs.

Microsoft Learn: Virtual machine and disk performance2026-05-28

Technical context

In Azure architecture, host caching belongs to the compute and managed-disk performance path. The setting is stored with the VM storage profile for OS and data disks, and it affects how I/O uses host cache versus durable disk storage. It appears during VM creation, disk attach, Bicep or ARM deployment, and performance troubleshooting. Database, analytics, and file-server workloads often treat OS disks, data disks, and log disks differently because their read and write patterns create different caching risks and benefits.

Why it matters

Host caching matters because storage performance problems are often blamed on disk SKU alone when the VM cache path is part of the real limit. A read-heavy disk can benefit from cache hits, while a write-heavy log disk can be harmed by the wrong mode or by misleading benchmark results. The term also matters for reliability because ReadWrite caching is not appropriate for every application. Engineers need to understand VM cached versus uncached IOPS limits, disk role, database guidance, and change procedures before toggling caching on production data disks. It also gives platform, security, finance, and application teams a shared checklist for ownership, evidence, rollback, and production readiness review.

Where you see it

Signals, screens, and Azure surfaces where this term usually becomes operational.

Signal 01

In the VM disk settings blade, each attached OS or data disk exposes a Host caching value such as None, ReadOnly, or ReadWrite for review.

Signal 02

In ARM, Bicep, or Terraform definitions, storageProfile.osDisk and storageProfile.dataDisks include the caching property for repeatable disk configuration across environments, subscriptions, and release stages.

Signal 03

In Azure CLI show output, storageProfile.dataDisks entries list LUN, managed disk reference, size, and caching mode for performance reviews and change records after updates.

When this becomes relevant

Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.

  • Tune read-heavy database or application data disks where cache hits can reduce latency without unsafe write behavior.
  • Keep transaction-log or write-heavy disks on None when product guidance warns against cached writes.
  • Compare on-premises disk layouts to Azure LUN, SKU, and caching choices during migration performance testing.
  • Document approved caching patterns in VM templates so production builds do not drift from tested storage design.
  • Diagnose why a premium disk upgrade did not improve performance because the VM cached or uncached limit is the real bottleneck.

Real-world case studies

Different enterprise-style examples that show the term being used to hit measurable objectives.

Case study 01

Logistics platform fixes slow read-heavy route planning

Logistics platform fixes slow read-heavy route planning: Host caching pays off when it is matched to disk role and measured against the real workload, not applied as a blanket tuning switch.

Scenario

A logistics SaaS provider moved route-planning databases to Azure VMs and saw read latency spike during morning dispatch calculations.

Business/Technical Objectives
  • Reduce read latency without increasing database VM size immediately.
  • Keep transaction-log disks on a safe write-heavy configuration.
  • Map every LUN to the correct database file role.
  • Document a repeatable storage pattern for new regional deployments.
Solution Using VM host caching

The database and platform teams reviewed VM host caching disk by disk. They mapped Linux mount points to Azure LUNs, found that read-heavy reference-data disks were set to None, and changed those disks to ReadOnly during a maintenance window. Transaction logs stayed on None, following database guidance. CLI captured storageProfile caching values before and after the change, while Azure Monitor tracked disk latency, IOPS, and query duration. The final Bicep module encoded the caching mode by disk role so future deployments matched the tested design. The team also recorded ownership, approval history, rollback criteria, and verification evidence so later changes followed the same operating model.

Results & Business Impact
  • Average reference-data read latency dropped 34 percent during dispatch peaks.
  • No transaction-log disks were changed, avoiding unsafe cached-write behavior.
  • The team deferred a planned VM upsizing for two quarters.
  • New regional builds now include LUN-to-role documentation and automated drift checks.
Key Takeaway for Glossary Readers

Host caching pays off when it is matched to disk role and measured against the real workload, not applied as a blanket tuning switch.

Case study 02

Financial reporting team stops a risky ReadWrite shortcut

Financial reporting team stops a risky ReadWrite shortcut: VM host caching is a reliability decision as much as a performance setting, especially on systems where writes must be durable.

Scenario

A finance department used a vendor reporting appliance on Azure VMs, and a support contractor enabled ReadWrite caching on data and log disks to improve exports.

Business/Technical Objectives
  • Verify whether caching changes created data-integrity risk.
  • Return disk settings to a vendor-supported pattern.
  • Preserve evidence of who changed the VM configuration.
  • Improve change control for future performance tuning.
Solution Using VM host caching

Operations used VM host caching inventory to reconstruct the change. Azure CLI showed each disk LUN, caching mode, and activity-log timestamps for the VM update. The vendor confirmed that transaction-log disks required None and data disks supported ReadOnly only for the reporting workload. During a scheduled outage, the team stopped services, changed log disks back to None, set read-heavy data disks to ReadOnly, and restarted the appliance. The change request included before-after metrics and a policy initiative that flagged unsupported caching patterns on tagged finance VMs.

Results & Business Impact
  • The unsupported ReadWrite setting was removed from all five reporting VMs.
  • Export runtime remained 18 percent faster than baseline after safer ReadOnly data caching.
  • Audit evidence identified the contractor account and the exact change window.
  • Future drift alerts notify operations within 30 minutes of an unsupported caching value.
Key Takeaway for Glossary Readers

VM host caching is a reliability decision as much as a performance setting, especially on systems where writes must be durable.

Case study 03

Game studio improves build-farm consistency

Game studio improves build-farm consistency: Host caching becomes operationally useful when every disk has a role, a tested mode, and a template that prevents quiet drift.

Scenario

A game studio ran Windows build workers on Azure VMs and saw inconsistent build times after teams attached extra data disks manually.

Business/Technical Objectives
  • Find caching drift across build-worker disks.
  • Reduce build asset read times without increasing every worker size.
  • Keep template-defined disk settings consistent across ephemeral workers.
  • Give developers a simple reason for each caching choice.
Solution Using VM host caching

The platform team inventoried VM host caching across the build farm with CLI queries against storageProfile dataDisks. Workers with asset-cache disks set to None were compared with workers using ReadOnly. After testing representative builds, ReadOnly was standardized for asset-cache disks, while temporary output and write-heavy package disks stayed on None. The VM template added explicit caching values and a pipeline check that failed if a new disk lacked a documented role. Developers received a short mapping from drive letter to disk purpose and caching mode. The team also recorded ownership, approval history, rollback criteria, and verification evidence so later changes followed the same operating model.

Results & Business Impact
  • Median asset-read phase time improved 27 percent on large builds.
  • Build-time variance between workers dropped by 31 percent.
  • Manual disk attachments without explicit caching disappeared after the pipeline check.
  • The team avoided buying larger disks for 120 workers during the release crunch.
Key Takeaway for Glossary Readers

Host caching becomes operationally useful when every disk has a role, a tested mode, and a template that prevents quiet drift.

Why use Azure CLI for this?

I use Azure CLI for host caching because the important truth is in the VM storage profile, not in a screenshot of one disk blade. CLI can show every attached disk with LUN, name, SKU, caching mode, size, and related IDs, which makes audits and change reviews much faster. It is also useful for comparing production against test before a performance change. A seasoned engineer does not casually flip caching on a busy database disk; CLI lets you script evidence, stop services when guidance requires it, apply one change, and capture before-after metrics. It also gives platform, security, finance, and application teams a shared checklist for ownership, evidence, rollback, and production readiness review.

CLI use cases

  • List every attached disk with LUN, managed disk ID, size, SKU, and current caching mode.
  • Attach a new data disk with an explicit caching value instead of accepting an accidental default.
  • Update a test VM disk caching mode and collect before-after performance metrics.
  • Compare caching settings across production and disaster-recovery VMs for configuration drift.
  • Export disk and VM size data before a storage tuning change review.

Before you run CLI

  • Confirm subscription, resource group, VM name, disk LUN, disk role, workload owner, and approved maintenance window.
  • Check vendor guidance for databases or write-heavy applications before using ReadWrite or changing log-disk settings.
  • Record current caching, disk SKU, VM size, and metrics so rollback and comparison are possible.
  • Verify whether services must be stopped before a caching change and whether the change triggers VM disruption.
  • Use precise JSON queries because selecting the wrong LUN can change the wrong production disk.

What output tells you

  • Storage profile output maps each LUN to a disk name, managed disk ID, size, and caching value.
  • Disk show output confirms SKU and size, but the VM storage profile shows the attachment caching mode.
  • Metric output helps separate disk latency from application, queue-depth, or VM-size bottlenecks.
  • Deployment validation output reveals whether templates set caching explicitly or rely on defaults.
  • Activity logs show who changed the VM model when caching drift appears after manual portal edits.

Mapped Azure CLI commands

VM host caching CLI operations

direct
az vm show --resource-group <resource-group> --name <vm-name> --query "storageProfile.{os:osDisk.caching,data:dataDisks[].{lun:lun,name:name,caching:caching}}"
az vmdiscoverCompute
read-only Microsoft docs
az vm disk attach --resource-group <resource-group> --vm-name <vm-name> --name <disk-name> --caching ReadOnly
az vm diskoperateCompute
state-changing Microsoft docs
az vm update --resource-group <resource-group> --name <vm-name> --set storageProfile.dataDisks[0].caching=None
az vmconfigureCompute
state-changing Microsoft docs
az disk show --resource-group <resource-group> --name <disk-name> --query "{sku:sku.name,size:diskSizeGb,id:id}"
az diskdiscoverCompute
read-only Microsoft docs
az monitor metrics list --resource <vm-resource-id> --metric "Data Disk Read Operations/Sec"
az monitor metricsdiscoverCompute
read-only Microsoft docs

Architecture context

Architecturally, host caching is a per-disk performance and consistency decision inside an IaaS workload design. I think about it by disk role: operating system disk, application binaries, read-heavy data, write-heavy logs, temporary files, and database transaction logs each deserve different treatment. The setting also intersects with VM size because cached IOPS and cache storage limits are properties of the VM, not only the managed disk. Architects should document cache mode beside disk SKU, LUN mapping, file layout, backup strategy, and benchmark evidence so future operators understand why the setting exists. It also gives platform, security, finance, and application teams a shared checklist for ownership, evidence, rollback, and production readiness review.

Security

Security impact is mostly indirect. Host caching does not grant access or expose a public endpoint, but it changes where recent I/O may be serviced and can affect how teams reason about data handling. The main security risk is operational: administrators making unsupervised disk changes on regulated workloads, or using performance workarounds instead of fixing encryption, backup, or access boundaries. Managed disks should still use encryption, RBAC should limit disk and VM update permissions, and change records should capture who changed caching on sensitive database, identity, or financial systems. It also gives platform, security, finance, and application teams a shared checklist for ownership, evidence, rollback, and production readiness review.

Cost

Host caching is not usually a separate meter, but it influences cost decisions around VM size, disk SKU, and overprovisioning. If caching helps a read-heavy workload meet latency targets, the team might avoid a larger disk or VM. If the wrong mode hides or worsens I/O problems, teams may buy premium capacity that does not solve the bottleneck. Testing costs also matter: benchmark VMs, temporary replicas, and monitoring retention should be planned. FinOps reviews should connect caching choices to measured workload performance, not to hopeful assumptions about cheaper storage. It also gives platform, security, finance, and application teams a shared checklist for ownership, evidence, rollback, and production readiness review.

Reliability

Reliability is directly tied to choosing the right caching mode for the disk workload. ReadOnly is safer for data that benefits from cached reads, while write-heavy or log disks usually need None unless product guidance says otherwise. ReadWrite caching can improve some workloads but requires the application to handle write persistence correctly. Changing caching on a live system without stopping services or following vendor guidance can cause downtime or data-risk incidents. Reliable teams test cache changes on replicas, document rollback, monitor errors, and verify recovery procedures after storage tuning. It also gives platform, security, finance, and application teams a shared checklist for ownership, evidence, rollback, and production readiness review.

Performance

Performance is the main reason host caching exists. Read cache hits can reduce latency and reduce pressure on uncached disk paths, while uncached writes may be necessary for correctness on log-heavy workloads. The VM size has cached and uncached limits, so adding cached disks does not create unlimited IOPS. Benchmarking must match real read/write mix, block size, queue depth, and file layout. Measure disk latency, IOPS, throughput, and application response time before and after any change; synthetic wins are not enough if the application becomes less reliable. It also gives platform, security, finance, and application teams a shared checklist for ownership, evidence, rollback, and production readiness review.

Operations

Operators inspect host caching during performance investigations, database reviews, migration testing, and VM build validation. They list disks by LUN, map each disk to an application role, compare caching against approved patterns, and correlate changes with latency, IOPS, queue depth, and application errors. Operational work also includes updating Bicep templates, confirming drift after manual portal changes, coordinating service stops when required, and recording why a disk uses None, ReadOnly, or ReadWrite. Without that documentation, future tuning becomes guesswork during an outage. It also gives platform, security, finance, and application teams a shared checklist for ownership, evidence, rollback, and production readiness review.

Common mistakes

  • Treating ReadWrite caching as a universal performance upgrade without checking application durability requirements.
  • Changing the wrong disk because LUN mapping was not compared with the operating-system mount or drive letter.
  • Buying larger disks before checking whether cached or uncached VM limits are constraining I/O.
  • Leaving caching decisions undocumented so future operators cannot tell why data and log disks differ.
  • Benchmarking with tiny test files and assuming the results represent real database or application workload patterns.