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.
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
