An Azure native disaster recovery service. Previously known as Microsoft Azure Hyper-V Recovery Manager.
ASR Azure-to-Azure on Trusted Launch Ubuntu 24.04: involflt "Root disk not found in driver context for TVM" keeps logging
Aniket Arsade
0
Reputation points
Environment
- Azure-to-Azure replication, East US to West US 2
- Source VM: Trusted Launch (Secure Boot + vTPM), encryption at host enabled, Ubuntu 24.04 LTS
- Kernel 6.11.0-1018-azure (listed as supported in the A2A support matrix), pinned with apt holds
- Mobility service 9.67.7789.1, extension updates set to manual (no newer version is offered)
- Single 30 GB OS disk (StandardSSD), no data disks
Symptom
The kernel log repeatedly shows:
involflt[process_iobarrier_tag_volume_ioctl:3404 (ERR)]: Root disk not found in driver context for TVM and tag commit is pending
involflt[revoke_tags_timeout:3172 (ERR)]: Starting revoke tags timeout procedure
During the worst period, vacp -systemlevel -cc -parallel exited with status 4 after about 6 minutes, and vacp.log showed:
CheckDiskRestoreOrSwap Error: disk id to lun map is empty
Timeline
- The errors started the day replication was enabled, at about 230-360 a day since then.
- Replication later went Critical (errors 153006 and 153007, RPO about 4.5 h) because no crash-consistent points were created.
- We restarted the agent service, killed a hung vacp, fully rebooted the VM, and let ASR resync.
- Since the reboot, replication is Healthy: crash-consistent points every 5 minutes, RPO under 1 minute. However, the involflt errors came back within 1 minute of boot and are still being logged.
Ruled out: disk space (41% used), outbound connectivity to the cache storage account and Entra ID, data change rate (VM is close to idle), kernel version (certified, no drift).
Questions
- What makes involflt lose the root-disk context on a Trusted Launch VM, and is this a known issue with 9.67 on Ubuntu 24.04?
- While crash-consistent points are being created, are these errors a risk to recovery-point consistency or failover?
- Is there a fix (a newer Mobility agent, a driver setting) or a recommended workaround?
Happy to share more logs if needed.
Azure Site Recovery
Azure Site Recovery
Sign in to answer