AVF VMs fail to boot on Android 17 beta: system crosvm rejects --net (status 35)

[ExTV]

Summary

On the Android 17 beta, AVF (pKVM) VMs fail to boot entirely, looping with STOP_REASON_UNKNOWN regardless of vCPU count (both 8-core and 1-core fail). QEMU is unaffected.

This is a Google beta APEX regression, not a Podroid bug (see proof below), but tracking it here for the workaround.

Environment

• Device: Pixel 10 Pro XL (codename CinnamonBun)
• Build: CP31.260522.006, API 37
• APEX com.google.android.virt build 371899999

Root cause (confirmed)

The system crosvm rejects the --net argument:

E crosvm : arg parsing failed: Unrecognized argument: --net
I virtmgr: crosvm(...) exited with status exit status: 35

crosvm exits at argument parsing, before loading the kernel/initrd/rootfs, so console.log is empty and no guest images are read.

virtmgr emits --net tap-fd=N whenever the app requests networking (setNetworkSupported(true) -> useNetwork(true)), but the crosvm in the same APEX was built without the optional net feature (in crosvm, --net and the deprecated --tap-fd/--tap-name are all part of the net build feature). So virtmgr and crosvm inside Google's own beta APEX disagree.

Proof this is not an app bug

The failure reproduces identically on the shipped v1.2.4 release APK (predating any local change) after a clean uninstall + install + pm grant. Any app/config hits it, because crosvm dies before touching app-supplied images. The app also cannot patch system binaries (/apex/com.android.virt/bin/crosvm is SELinux-blocked).

How to diagnose

1. Clear logcat.
2. Trigger an AVF boot.
3. adb logcat -b all -v threadtime, grep crosvm|virtmgr.
4. Look for Unrecognized argument: --net and exit status: 35.

The in-app diagnostic export (Downloads/log.txt) shows the boot loop but not the crosvm stderr (that lives only in virtmgr logcat).

Workaround options

1. Report to Google (their APEX bug) - the only real fix for full tap networking on the beta.
2. Degraded-AVF: on detecting the signature (VM stopped <~1.5s with empty console.log), relaunch AVF with useNetwork(false). AVF then runs (compute, terminal, vsock forwards) but the guest has no outbound internet. Gated to the failure path only -> zero regression where AVF works.
3. Durable: route guest traffic over vsock into an Android-side userspace netstack (passt/SLIRP-style), removing the dependence on crosvm's tap --net entirely (the VsockPortForwarder/VsockUdpForwarder plumbing already exists). Bigger effort.

Not to be confused with

The Tensor G3/G4 multi-vCPU reboot - that is a guest-kernel topology issue. This is a host VMM arg-parse failure on the Android 17 beta. Different failure, different cause.