It depends on what you mean by "lose a VM." If you have a hardware failure and the VM is effectively powered off, a failover will occur if the failed VM was the primary. When the failed server is moved and rebooted, it will join the cluster before trying to become primary again, and when it does it will discover that the other node is primary, and it then resolves its own state to secondary.
If there is no power off situation, but the VM disappears from the network for several seconds--this can be bad as it can cause failover to occur, but since the VM that is moving is effectively paused, it does rejoin the cluster to resolve its role--it just picks up where it left off. The cluster will quickly detect that there are two primaries and the VM that moved will be forced into a secondary role, but if there was any data committed from the transaction logs, you can end up with the databases out of sync. If this happens, you have to remove the replica database that's out of sync, restore from backup, etc., and then join it back in. See How to remove a secondary database from an availability group and rejoin it.
Another thing with VMs that can result in this mess is VM snapshot backups, or VMotioning--anything that can cause the server to be paused. For servers with 100 GB storage--usually not a problem. But when you start getting into terrabytes, the server can be paused for several seconds to do these operations. So you may need to adjust your backup strategy to accomodate--see this for more.
