In the KubeVirt architecture, scheduling as well as network and storage management is completely delegated to the underlying Kubernetes cluster, with KubeVirt extending it with virtualization functions. When developing KubeVirt, we are often faced with a dilemma: should we solve a problem in KubeVirt in a way that is best optimized for VMs, or should we take a more general path and develop or rely on solutions that are also suitable for generic pod-based workloads? The KubeVirt razor that states "if something is useful for Pods, we should not implement it only for VMs” is our guiding principle and has proven to be a wise and smart idea over the years. However, we still frequently receive questions from experienced users coming from other more traditional virtualization solutions who want to know how they can perform certain scheduling/maintenance activities following patterns that have proven successful for them in the past. An example of these questions is live migrating one of my VMs to a named node as and when I wish bypassing the cluster scheduler decision, or how to automatically and regularly rebalance the cluster according to the real-time resource consumption of my long-lived VMs. In the past, such questions have not found an easy answer in KubeVirt. In this session, we will discuss how to extend the VirtualMachineIstanceMigration object to allow the cluster administrator to specify a desired target node. We will then move on to a more advanced use case and discuss why PSI (Pressure Stall Information) metrics collected at node and workload level (cgroupv2) are like barometers that provide fair warning of impending resource shortages (memory, CPU, IO), and how we can proactively leverage this information by using a novel load-aware plugin for the Kubernetes descheduler that can trigger evictions and live migrations (for VMs) to automatically manage and balance resource utilisation on cluster nodes. Please note that these novel proposals are still controversial and the subject of an interesting discussion between KubeVirt developers. So this talk may be an interesting opportunity for discussion to influence the future development of your preferred virtualization solution.