On Wed, Jan 31, 2024 at 08:57:04PM +0000, Daniel P. Berrang?? wrote:
On Wed, Jan 31, 2024 at 12:49:50PM -0800, Praveen Paladugu wrote:
Am I right in thinking that "Microsoft Hypervisor" in this context is simply Hyper-V, aka, the same hypervisor you traditionally have under a Windows Dom0 ?
If so then I could think that we probably don't need to have a new virDomainVirt type enum entry. We could simply use the pre-existing VIR_DOMAIN_VIRT_HYPERV to represent this configuration in the cloud-hypervisor configuration.
I considered reusing VIR_DOMAIN_VIRT_HYPERV entry. From what I understand, this hypervisor option implies Libvirt talks to HyperV using WMI. Although the binary bits of the hypervisors may be the same in both configurations, the interfaces to interact with the hypervisors are completely different.
In the context of libvirt XML config, the virDomainVirt enum is very specifically referring to the underlying hypervisor guest ABI. This is distinct from any protocol used for the management of the platform by libvirt.
This is why both the CloudHypervisor and QEMU drivers in libvirt will both support the VIR_DOMAIN_VIRT_KVM for guests, despite being completely different mgmt APIs.
Similarly in the past we have have multiple drivers all use VIR_DOMAIN_VIRT_XEN for the guest, while using completely different mgmt APIs.
So if "mshv" in the context of CloudHypervisor is running HyperV under Dom0 and the guest primarily needs to support the HyperV ABI, then I would say VIR_DOMAIN_VIRT_HYPERV could be the appropriate choice.
With the introduced "mshv" hypervisor option, Libvirt doesn't interact with "/dev/mshv" at all. Libvirt just invokes cloud-hypervisor which in turn talks to mshv via kernel ioctls as necessary.
That's OK. The distinction of control/mgmt API is represented by the different libvirt virConnect URI schemes. virDomainVirt is exclusively about what primary hypervisor guest ABI is exposed.
Thanks for the explanation, Daniel. By "underlying hypervisor guest ABI" I am guessing you are referring to the interfaces used for starting and managing guests. If so, the ABIs available in Hyperv(VIR_DOMAIN_VIRT_HYPERV) and "mshv" configurations are completely different too. This is because the underlying Operating systems: Windows and Linux respectively, provide different interfaces for programs to start and manage guests. So, I'd say the hypervisor guest ABIs are different in these 2 configurations. Above, you called out CloudHypervisor and Qemu drivers in libvirt supporting VIR_DOMAIN_VIRT_KVM. This makes sense to me. In these 2 configruations, both the VMMs (CloudHypervisor, Qemu) use the same/simiar set of interfaces provided by the kernel and hypervisor(KVM) to manage guests. Unfortunately, this isn't the case with VIR_DOMAIN_VIRT_HYPERV and VIR_DOMAIN_VIRT_MSHV types. With VIR_DOMAIN_VIRT_HYPERV and VIR_DOMAIN_VIRT_MSHV, as different hypervisor types, checks on the hosts will be simpler, as each of these types would imply a host OS. Regards, Praveen
With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-leave@lists.libvirt.org