Mine don’t. Most don’t.
There is a comment further down the page that goes over the NLA thing.

Delete it from the cluster, then use Storage Migration to move the VM files to the local disk. That’s it.

If someone takes an unencrypted VHDX file, it is safest to assume that they can read everything. Basically, stealing an unencrypted VHDX file is equivalent to stealing an unencrypted hard drive.
Breaking the directory file is relatively simple, although it takes time. You can search for various ways to read or extract data from an NTDS.DIT file.
That said, the only truly secret items in your domain file are the password hashes. The structure of your domain already grants read access to almost everyone. So, if you believe that an NTDS.DIT file has been stolen, you need to change all domain passwords as quickly as you can. If you have an enterprise password management tool, that could be –relatively– simple. Overall steps:

1. Fully decommission the compromised domain controller. That will prevent its computer account from making changes in the domain.
2. Force every computer in the domain to reset its machine password.
3. Reset passwords on enterprise and domain admin accounts
4. Reset non-expiring service user accounts
5. Force all domain users to reset their passwords. This is a good time to clean up unused accounts.

To prevent reading the VHDX in the first place, you need to encrypt it. If your host has a TPM, then you can just enable BitLocker in the guest. If you ever want to move the guest to another host, you’ll need to make certain that you retain its BitLocker key somewhere other than in the domain. Personally, I consider it a good thing to have a domain controller that can only ever run on the host I put it on, but that does mean that you must be absolutely certain that there is no way to ever lose all of your domain controllers. If you want to make an encrypted VM mobile (and REALLY increase its security), then you need to set up Shielded VMs. That’s a non-trivial exercise that I have not yet written anything serious about. I did write up something on non-mobile Shielded VMs. The tech was still kind of new then and I don’t think I mentioned disk encryption.

I don’t see a benefit and don’t like to have DCs dependent on a cluster, but it would work.

Hmm, what about making the DCs HA (“cluster-aware”), setting them to start at once and set them to a / one “Preferred Owner” only?

Thanks. I tried this, but the VM was turned off instead of shut down (possibly a problem with Win2012r2 AD running on Hyper-V Win2019). I’ll try with a PreUpdateScript. I’m running the second AD VM in the cluster so that I’m sure this one is always up during cluster aware updating.

If I remember my testing, CAU will not shut down non-clustered VMs, but the host will when it reboots. Set the DCs’ automatic stop action to stop and their automatic start action to always start. I would also set up a nanny script at the end of the CAU run to make certain that they’re online, as there seems to be a bug in the automatic start code.