Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1512619 - [RFE] update cluster compatibility version on reboot triggered inside the virtual machines
Summary: [RFE] update cluster compatibility version on reboot triggered inside the vir...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.1.7
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: ---
Assignee: Martin Tessun
QA Contact: meital avital
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-13 16:47 UTC by Igor Netkachev
Modified: 2019-03-29 10:52 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-07-03 12:50:09 UTC
oVirt Team: Virt


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.