Bug 1888750

Summary:	Provide simple boolean hyperv=on option with reasonable defaults (libvirt)
Product:	Red Hat Enterprise Linux 9	Reporter:	Eduardo Habkost <ehabkost>
Component:	libvirt	Assignee:	Tim Wiederhake <twiederh>
libvirt sub component:	General	QA Contact:	Luyao Huang <lhuang>
Status:	CLOSED WONTFIX	Docs Contact:
Severity:	medium
Priority:	medium	CC:	dyuan, hhan, jsuchane, lmen, virt-maint, vkuznets, xuzhang, yacao, yalzhang
Version:	9.0	Keywords:	FutureFeature, Triaged
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-09-05 15:06:04 UTC	Type:	Feature Request
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1877467
Bug Blocks:

Description Eduardo Habkost 2020-10-15 16:47:58 UTC

Copying BZ for libvirt, as we need libvirt to support the new boolean flag once we implement it.

This bug was initially created as a copy of Bug #1877467


The set of available hyperv options depend on the host kernel, but this doesn't mean we can't provide a reasonable default set of hyperv features with a simple hyperv=on option.

The default set of hyperv features can depend on the machine type, so new upstream machine types can start enabling newer features, and downstream we can define the default set of hyperv features by just adding compat properties to the rhel machine types.

This way, we'll be able to provide a more reasonable interface for enabling hyperv features (just a boolean option) instead of the complex hyperv flag configuration interface we have today.

Comment 3 John Ferlan 2021-09-08 13:31:24 UTC

Bulk update: Move RHEL-AV bugs to RHEL9. If necessary to resolve in RHEL8, then clone to the current RHEL8 release.

Comment 5 Jaroslav Suchanek 2022-09-05 14:04:32 UTC

Vitaly, since the qemu bug 1877467 is closed as wontfix, is there any sense in keeping the libvirt part open? Thanks.

Comment 6 Vitaly Kuznetsov 2022-09-05 14:36:19 UTC

(In reply to Jaroslav Suchanek from comment #5)
> Vitaly, since the qemu bug 1877467 is closed as wontfix, is there any sense
> in keeping the libvirt part open? Thanks.

No, I don't think so. Without a decision on how to do this feature in QEMU
(in a useful way), I don't think there's anything libvirt could do.

Comment 7 Jaroslav Suchanek 2022-09-05 15:06:04 UTC

(In reply to Vitaly Kuznetsov from comment #6)
> (In reply to Jaroslav Suchanek from comment #5)
> > Vitaly, since the qemu bug 1877467 is closed as wontfix, is there any sense
> > in keeping the libvirt part open? Thanks.
> 
> No, I don't think so. Without a decision on how to do this feature in QEMU
> (in a useful way), I don't think there's anything libvirt could do.

Fine. Lets close it accordingly. It can be reopened if needed. Thanks.