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@xxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
