On Fri, Feb 16, 2024 at 03:20:52PM +0000, Daniel P. Berrang?? wrote:
> On Mon, Feb 12, 2024 at 08:38:42AM -0800, Praveen Paladugu wrote:
> > 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.
> > >
> >
> > 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.
>
> Yes, that is correct, but we already have XML attributes tracking the
> device types for storage, network, etc. Probably 50% of the information
> in the guest XML is expressing guest ABI in some way or other. The domain
> virt type is just one part of the story.
>
> So it is OK for 2 XML configs to use VIRT_HYPERV, while having different
> settings for storage/network/etc. We're not trying to make the XML be
> portable across different hypervisors, just trying to use the same
> terminology for the same feature across hypervisors.
>
> > 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?
>
> Yes, I still believe VIRT_HYPERV is the right choice here.
Thanks for the discussion Daniel. This reasoning sounds good to me. I will
refactor this patchset to use VIRT_HYPERV as the hypervisor type.
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
