e2e: nothing evicts a VM launcher pod, so drain and workload-update behaviour is untested #4422

Nothing in e2e evicts a VM launcher pod, so the platform's KubeVirt eviction behaviour is untested. That behaviour decides whether a node drain completes or hangs, and whether a KubeVirt upgrade restarts VMs, and today both are known only from reading the KubeVirt source.

#4403 changes the cluster evictionStrategy to LiveMigrateIfPossible and keeps Evict in workloadUpdateMethods. Its claims come from KubeVirt v1.9.0: a non-migratable VMI is let through by the eviction webhook, a migratable one is migrated, and a VMI created before the change keeps LiveMigrate in its spec and still gets 429. The vminstance chainsaw suite starts a VM but never evicts it, and no suite drains a node.

A cheap first check would not need a real drain. A dry-run eviction of the vminstance launcher pod goes through the same admission webhook and returns its decision without deleting anything. Asserting on that response, together with the VMI's LiveMigratable condition, would pin which way the platform answers for the storage class the suite uses. I have not checked which answer that class gives today, so the test would have to read the condition rather than assume it.

A full drain with a non-migratable VM, and a workload update after a KubeVirt bump, would cover the rest but cost a lot more CI time. That part probably belongs in the upgrade suite, if one appears.