On Mon, Feb 05, 2024 at 11:15:21AM -0800, Praveen Paladugu wrote:
> On Mon, Feb 05, 2024 at 04:57:28PM +0000, Daniel P. Berrang?? wrote:
> > On Mon, Feb 05, 2024 at 08:12:15AM -0800, Praveen Paladugu wrote:
> > > On Wed, Jan 31, 2024 at 08:57:04PM +0000, Daniel P. Berrang?? wrote:
> > > > > 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.
> >
> > By 'hypervisor guest ABI' I'm referring to the general virtualization
> > ABI that the hypervisor exposes to guest OS.
> >
> > ie the functionality that a Linux guest enables with CONFIG_HYPERV,
> > or with CONFIG_KVM Kconfig build options.
> >
> > IIUC, there is no new CONFIG_MSHV in Linux guests, and they would
> > be expected to be built with CONFIG_HYPERV enabled, or am I wrong
> > in that respect ?
> >
> You are correct Daniel. The guest needs CONFIG_HYPERV and a few other HYPERV_*
> configs enabled. The host on the other hand needs CONFIG_MSHV_ROOT enabled.
>
> Regards,
> Praveen
>
I understand your recommendation now Daniel. By assigning a hypervisor
type based on 'hypervisor guest ABI', users will be able move 'Domain XML' with
corresponding guest images across hosts that expose the same hypervisor
guest ABI, irrespective of what the underlying OS is. Such a setting
would potentially also allow Live Migration of guests across platforms
supporting the same hypervisor guest ABI.
In this particular case though, CONFIG_HYPERV is only part of the story. In
order for guests to run on top of Hyperv, they usually need
CONFIG_HYPERV_{STORAGE,NET} and other drivers.
The guests running in Mshv need virtio drivers. This is because the
underlying VMMs in these cases: Hyperv, Cloud-Hypervisor expose
different sets of paravirtualized devices to guests. Although the core
hypervisor guest ABI is the same in both cases, guests will not be able to
move across 'Hyperv' and 'mshv' configs seemlessly.
It is less likely for these two VMMs to converge on a common set of
paravirtualized and emulated devices to allow seamless migration of
guests between Hyperv and Mshv configs. Do you still see value in
converging both these configs under the hypervisor type,
VIR_DOMAIN_VIRT_HYPERV?
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
_______________________________________________
Devel mailing list -- devel@xxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
