Bug 1512619

Summary:	[RFE] update cluster compatibility version on reboot triggered inside the virtual machines
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Igor Netkachev <inetkach>
Component:	ovirt-engine	Assignee:	Martin Tessun <mtessun>
Status:	CLOSED CURRENTRELEASE	QA Contact:	meital avital <mavital>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	4.1.7	CC:	klaas, lsurette, michal.skrivanek, mtessun, rbalakri, Rhev-m-bugs, srevivo, ykaul
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---	Flags:	lsvaty: testing_plan_complete-
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-07-03 12:50:09 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Virt	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Igor Netkachev 2017-11-13 16:47:32 UTC

Currently in RHV 4.x after upgrade and change of cluster compatibility level, a warm reboot of VM does not trigger update of cluster compatibility level for this VM, customers have to power-cycle (stop and start) the VM for the changes to take affect as per https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html/upgrade_guide/chap-post-upgrade_tasks#Changing_the_Cluster_Compatibility_Version

This RFE proposes to do a power-cycle of VM instead of warm-reboot once cluster version has been updated, in other words both warm reboot and power-cycle should trigger cluster version update for VM. This should allow better permission granularity (no need to provide access to GUI if simple warm reboot is enough), also version updates in VMWare work this way and customers migrating to RHV from VMWare could get more positive experience from RHV behaving according to their expectations in this part.

Comment 2 Klaas Demter 2018-01-09 07:23:35 UTC

is this already fixed by https://bugzilla.redhat.com/show_bug.cgi?id=1420404 ?

Comment 5 Michal Skrivanek 2018-06-20 11:22:08 UTC

(In reply to Igor Netkachev from comment #3)
> > An ability to choose between 'warm' and 'cold' VM reboot is introduced with
> https://bugzilla.redhat.com/show_bug.cgi?id=1420404 , is it possible to
> benefit from using this feature for this case as well and to mark VM for
> next reboot to be 'cold' in case cluster/DC compatibility level has been
> upgraded?

that's how it behaves. If there's a pending config change and you trigger a reboot from UI it will perform a cold reboot applying the changes

Comment 6 Igor Netkachev 2018-06-29 12:39:39 UTC

Hi Michal,

There's the following feedback form customer who submitted this RFE:

""
The point of this Case is to make have it do a "cold" reboot even when just triggering a reboot from wihtin guest OS, not from RHV UI

The bz to this rfe is https://bugzilla.redhat.com/show_bug.cgi?id=1512619 my question was if volatile run feature from https://bugzilla.redhat.com/show_bug.cgi?id=1420404 fixes this. I don't have a 4.2 yet to test it. So I'm not sure if this is working :)
"""

Does this also work in case of reboot initiated from within guest OS?

Comment 7 Michal Skrivanek 2018-06-29 14:41:56 UTC

(In reply to Igor Netkachev from comment #6)

> Does this also work in case of reboot initiated from within guest OS?

yes, see https://bugzilla.redhat.com/show_bug.cgi?id=1420404#c24

I guess we can close this RFE as CURRENTRELEASE

Comment 8 Klaas Demter 2018-06-30 18:30:33 UTC

the comment you reference is private aswell :) in any case good to hear this is working with 4.2 - I'll give it a try soon. Thanks!

Comment 9 Martin Tessun 2018-07-03 12:50:09 UTC

Feel free to reopen if anything is missing.

Comment 10 Klaas Demter 2019-03-29 10:52:54 UTC

because of another case I noticed this is not reflected inside docs:
https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/html/upgrade_guide/changing_the_cluster_compatibility_version_3-6_local_db
"you must update the cluster compatibility version of all running or suspended virtual machines by restarting them from within the Manager, or using the REST API, instead of within the guest operating system"

Plus I think this has a dependency on guest agents being installed; that should most likely be noted in docs somewhere as well.