Chris Engelbert 
Anyone who has run a backup estate on vSphere has read this line in a task pane at three in the morning:
Cannot quiesce the virtual machine because VMware Tools is not currently available.
It is a good error. It is specific, it names the missing component, and above all it is loud: the snapshot task goes red, the backup job reports a failure, and somebody gets paged. The reason failed to quiesce the virtual machine is still a searched phrase years later is that the platform insisted on telling you when the guest could not be quiesced.
That is the part worth holding on to, because it is the part that does not survive the migration. After the exit, the same condition produces no error at all. The snapshot succeeds. The backup job reports success. The restore point exists, it is just a different kind of restore point than the one you had last year, and nothing in the pipeline says so.
This post is about what VMware® Tools was actually doing inside the guest when you ticked that box, where each link of that chain lands after a move to KubeVirt or Red Hat® OpenShift® Virtualization, and which link has no automatic replacement at all.
What VMware Tools was actually doing when you asked for a snapshot
The quiesce option in a vSphere snapshot looks like a storage feature. It is not one. Every interesting thing it did happened inside the guest operating system, and the storage layer was the last participant rather than the first.
The sequence ran roughly like this. The platform asked the guest, through the VMware Tools daemon, to bring its filesystems and its applications to a consistent resting point. On Linux, Tools ran a sync and froze the mounted filesystems so that no new writes could land while the snapshot was taken. On Windows, Tools acted as a Volume Shadow Copy Service requestor: it asked VSS to coordinate, and VSS in turn told each registered writer to flush its state to disk and hold still. A writer is the application’s own code for this, and the important ones are the ones you would expect, including the SQL Server writer, the Exchange writer, and the registry and Active Directory writers. Only once the guest confirmed it was frozen did the platform take the snapshot, and immediately afterwards it told the guest to thaw.
Three properties of that arrangement mattered more than anybody noticed at the time.
It was on by default in most backup products. Nobody chose application consistency per workload. The backup vendor ticked the quiesce box in the job template, and every VM in the estate got the guest-side coordination whether it needed it or not.
It was a single vendor’s problem. The daemon in the guest, the requestor, the snapshot orchestration and the storage all came from one platform. When the versions drifted, you upgraded Tools.
It failed loudly. This is the property that turns out to matter most. unable to quiesce guest file system during snapshot creation is an ugly thing to find in a job log, but it is infinitely better than not finding it. The system refused to quietly hand you a weaker restore point than the one you asked for.
Strip those three away and you have described the destination platform quite accurately.
Where each piece of that chain lands after the exit
The sentence the whole migration turns on is this one: a Kubernetes CSI VolumeSnapshot is crash-consistent by default, and there is no quiesce flag on it.
That is not a criticism of CSI. It is a correct separation of concerns. The CSI driver’s job is to capture the state of a block device at a point in time, and it has no view into the guest operating system running on top of that device, let alone into the applications inside it. Somebody else has to do the freezing, and on the destination platform that somebody is assembled from parts rather than shipped as one.
Here is where each link actually goes.
Table 1: The vSphere quiescing chain, translated
| On vSphere | What it did | Where it lands after the exit | Who owns it now |
|---|---|---|---|
| VMware Tools daemon | In-guest endpoint the platform talked to | qemu-guest-agent, installed in the guest image | Whoever builds the VM images |
| Tools sync driver (Linux) | Froze mounted filesystems | fsfreeze via the guest agent, plus optional freeze and thaw hook scripts | Guest image owner |
| Tools VSS requestor (Windows) | Asked VSS to coordinate the writers | A VSS provider and requestor shipped with the Windows guest agent package | Guest image owner |
| vCenter snapshot task | Ordered the quiesce, then the snapshot, then the thaw | Backup tool or KubeVirt hook calling the agent around a VolumeSnapshot | Platform team |
| Per-VM snapshot atomicity | One consistent point across every VMDK on the VM | Volume group snapshot or a consistency group | Storage layer |
Read the right-hand column on its own and the change is clear. What used to be one vendor’s responsibility is now split across three different teams, and two of those teams are usually not in the room when the migration is planned. The image builders do not know that a package they omitted has anything to do with backups. The storage team does not know that a snapshot completing slowly is now a guest-visible stall. The backup owner assumes the behaviour they had before came along with the data.
The freeze and thaw mechanics on the destination side are covered in more depth in our post on backup and restore for KubeVirt VM workloads, and the multi-volume case is worked through in group snapshots for multi-volume applications. What those posts assume, and what this one is about, is that the chain exists in the first place.
Not sure whether your restore points are still application-consistent after the migration? If you are moving VMs off vSphere and want the snapshot, grouping and freeze-window behaviour underneath them checked before the backup job starts reporting false success, talk to us. Talk to a storage architect
The Windows chain is the one that silently goes missing
If you only audit one thing after a migration, audit the Windows guests, because the Windows chain has the most links and every one of them can be absent without complaint.
On vSphere, a Windows VM with a healthy Tools installation got VSS coordination for free. The chain was: backup product asks vCenter, vCenter asks Tools, Tools acts as the VSS requestor, VSS calls each registered writer, the writers flush, the shadow copy is created, the snapshot is taken. Remove Tools from that picture and the chain breaks in an obvious place.
After the exit the chain is longer and the pieces are separately installable:
- The
qemu-guest-agentservice has to be present and running in the Windows guest. It is not in a stock Windows image. - The agent’s VSS provider and requestor components have to be installed alongside it. On Windows these are a distinct part of the guest tools package, and installing the agent service without them is a normal and easy mistake.
- The VSS writers themselves have to be healthy.
vssadmin list writersreturning a writer in a failed state is a pre-existing condition that the old platform would surface at backup time and the new one will not. - Something has to actually call freeze before the snapshot and thaw after it. A bare
VolumeSnapshotcreated by a schedule does not.
Every one of those four can be missing while the backup job reports green. That is the regression, stated plainly: the failure mode changed from a loud error to a silent downgrade. You do not lose your restore points, you lose the property of them that you were relying on, and you find out during a restore.
It is worth being precise about what Volume Shadow Copy is here, because the term does double duty. The shadow copy that end users know, the one behind Restore previous versions on a file share, is the same service doing a different job. The part that matters for backups is the writer coordination, not the user-facing snapshot feature. A storage snapshot is not a shadow copy, and having one does not give you the other.
The Linux side is genuinely simpler, and it is fair to say so rather than implying symmetry. The guest agent’s fsfreeze support does the filesystem half on its own, and for a great many Linux workloads that is enough. Where Linux gets interesting is the same place Windows does: an application holding state that the filesystem does not know about needs a hook script, and hook scripts are code somebody has to write and keep working.
What the storage layer has to do underneath
The guest-side chain is the visible half of this. The storage layer decides whether the chain is cheap enough to use in production, and there are exactly two properties that matter.
The freeze window is bounded by how long the snapshot takes. This is the constraint people discover late. Between freeze and thaw, the guest’s filesystem is not accepting writes, which means applications are stalled. If the snapshot mechanism copies data, the freeze window scales with the size of the volume, and a freeze window measured in tens of seconds is an outage that your monitoring will report as an application problem. If the snapshot is a metadata operation, redirect-on-write or copy-on-write, it completes in effectively constant time regardless of volume size, and the freeze window collapses to the round trip of the freeze and thaw calls themselves. Simplyblock’s snapshots are metadata operations for exactly this reason, so the quiesce window is bounded by the guest agent’s round trip rather than by data movement. That is what makes quiescing viable on a schedule rather than only in a maintenance window.
A VM with more than one volume needs one point in time, not several. A Windows VM with an OS disk and a separate data disk is two PVCs. Snapshot them independently, even a second apart, and you have two restore points that do not correspond to the same instant. Restore both and the guest sees a state that never actually existed, which is precisely the torn restore point that quiescing was supposed to prevent. On vSphere this was free, because the snapshot was a VM-level operation across every VMDK. On the destination side it is a specific capability: a consistency group, or a volume group snapshot, that captures every volume in the set atomically. Simplyblock does this at the storage layer, so the grouping is a property of the snapshot rather than something the backup tool tries to approximate by going quickly. The CSI snapshot architecture post covers how the snapshot class policy expresses that.
Now the honest part, which most of the search results on this topic skip: crash-consistent is frequently fine, and quiescing is not universally required. Selling application consistency as mandatory for everything is a good way to get it configured badly everywhere and understood nowhere.
Table 2: Is crash-consistent enough for this workload?
| Workload shape | Crash-consistent enough? | What to add if not |
|---|---|---|
| Journaling filesystem, no database (web tier, app servers, stateless VMs) | Yes. The journal replays on boot, which is exactly the power-cut case | Nothing |
| Database with write-ahead logging, fsync honoured (PostgreSQL, MySQL with InnoDB) | Usually. Recovery replays the log, same as after a crash | Filesystem freeze for faster, more predictable recovery |
| Application buffering state outside the filesystem (in-memory queues, some ERP and middleware tiers) | No. The buffered state is simply not on disk to capture | Guest agent plus an application-aware freeze hook |
| Windows application servers with registered VSS writers (SQL Server, Exchange, AD) | No, and this is the case the writers exist for | Guest agent with VSS provider and requestor, writers verified healthy |
| Multi-volume VM, any of the above | Separate issue. Consistency is per volume unless grouped | Consistency group or volume group snapshot |
The distinction that actually separates the rows is whether the application’s state is on disk at the moment the snapshot lands. A journaling filesystem and a log-replaying database both have everything they need on disk, because they were designed for the machine losing power. That is why crash-consistent works for them: a crash-consistent snapshot is a power cut, and these systems already handle power cuts. An application holding state in memory that has not been written yet has no such guarantee, and no amount of storage-layer cleverness can capture something that was never sent to the storage layer.
Which gives a much shorter migration task list than “enable quiescing everywhere”. Find the workloads in rows three and four, make sure the chain is complete for those, verify it by restoring one, and let the rest be crash-consistent on purpose rather than by accident. The difference between a deliberate crash-consistent restore point and an accidental one is entirely in whether you know which you have, which is the same reason it matters what makes a restore point unalterable once you have it.
For the wider picture of what a backup estate looks like after leaving vSphere, see replacing the VMware backup estate, and for the day-two operational view, day 2 storage operations after the VMware exit.
Questions and Answers
Is a Kubernetes CSI snapshot crash-consistent or application-consistent?
Crash-consistent, by default and in every CSI implementation. A VolumeSnapshot captures the block device at a point in time and has no visibility into the guest operating system or the applications above it, so there is no quiesce flag to set. Application consistency is added from the guest side, by having something freeze the filesystem before the snapshot is taken and thaw it afterwards. With simplyblock the snapshot itself is a metadata operation that completes in constant time, which is what keeps the freeze window short enough to do this on a schedule rather than only during a maintenance window.
What replaces VMware Tools quiescing after a migration to KubeVirt or OpenShift Virtualization?
The qemu-guest-agent, installed and running inside the guest, plus something that calls it. On Linux the agent provides fsfreeze support along with freeze and thaw hook scripts for application-level work. On Windows the agent package also ships VSS provider and requestor components, which are what let it drive the same Volume Shadow Copy writers that VMware Tools used to drive. The important difference is that none of this is present by default: it has to be baked into the guest images and verified, whereas on vSphere it arrived with the platform.
What is the difference between crash-consistent and application-consistent backup?
A crash-consistent copy is what you would have if the machine lost power at that instant: the disk is captured exactly as it was, with whatever was still in flight left in flight. An application-consistent copy is taken after the applications have been told to flush their state and hold still, so the data on disk represents a deliberate resting point. For a journaling filesystem or a database with write-ahead logging, crash-consistent is usually sufficient because those systems recover from power cuts by design. For an application that buffers state outside the filesystem, it is not sufficient, because the missing state was never written to the disk being captured.
Why did failed to quiesce the virtual machine happen, and does it still happen after the exit?
On vSphere it meant the platform asked the guest to freeze and the guest did not confirm, usually because VMware Tools was missing, stopped or version-mismatched, or because a Windows VSS writer was in a failed state. After a migration the equivalent conditions still occur, but they usually do not produce an error, because a plain VolumeSnapshot never asked the guest for anything in the first place. It simply returns a crash-consistent snapshot. This is the single biggest behavioural change to plan for: the same underlying fault that used to fail a backup job now silently produces a weaker restore point.
Do I still need VSS writers on Windows VMs after leaving vSphere?
Yes, for any Windows workload that registers one, which includes SQL Server, Exchange and Active Directory. The writers are part of Windows and the applications, not part of the virtualization platform, so they do not go anywhere. What changes is who asks them to run: instead of VMware Tools acting as the requestor, the guest agent’s VSS components take that role. Worth checking vssadmin list writers on your Windows images as part of migration testing, since a writer that has been failing quietly for months will not start working just because the hypervisor changed.
Is Volume Shadow Copy the same thing as a storage snapshot?
No, and conflating them causes real confusion during migrations. Volume Shadow Copy Service is a Windows coordination mechanism that tells applications to flush and hold still, and it can also create a local shadow copy used by features like restoring a previous version of a file. A storage snapshot is a point-in-time capture of the volume taken by the storage layer underneath. Having a storage snapshot does not give you the writer coordination, and running VSS does not give you a restore point that survives the loss of the guest. Application-consistent protection needs both, which is precisely why the chain described in this post has so many links.
