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.
is this already fixed by https://bugzilla.redhat.com/show_bug.cgi?id=1420404 ?
(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
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?
(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
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!
Feel free to reopen if anything is missing.
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.