Bug 1519708

1. Proposed title of this feature request
Provide a functionality to apply virtual machine version upgrade (generally triggered through increasing cluster compatibility version) in an automated way.
Currently it's working if the VM got triggered by restart from RHV manager, but there is no way to trigger this from within the virtual machine itself. Using API is not possible, as there is no direct network-connection between virtual machine guest and rhv manager.



3. What is the nature and description of the request?
If a VM requires a virtual machine version upgrade, it's only possible in an automated way, when triggered from RHV manager. In most cases, virtual machine guest upgrades (yum update within the guest) is performed locally on the virtual machine and the required reboot is also triggered from inside. 
4. Why does the customer need this? (List the business requirements here)
Background: 
We have a heterogenous environment with about 4000 VMs. To keep the OS in those VMs up to date, we have a distributed patch system in place. As such we are able to distribute load and have no single point of failure - which turned out to be a good thing in the past. VMs and RHV-Manager are in seperated networks (security reasons) so they can't access each other via network. While most of the VMs are Linux (RHEL) based we have a growing number of appliances running, that don't have any kind of guest tools installed.

Problem:
When we upgrade our RHV-Environment all VMs have to be upgraded, as new features only work with the upgraded vm-"shell". Therefore all VMs have to be shut down and powered up again, as a reboot from within the VM does not trigger the VM upgrade. As getting downtimes for productive VMs is hard, we would like to integrate the procedure of upgrading the VMs into the OS-upgrade that we are doing anyway every three months.

Request:
We would like to have a solution that triggers a VM upgrade from within having a central instance.


5. How would the customer like to achieve this? (List the functional requirements here)
1. If a VM is rebooted, the Hypvervisor should recognize this and powercycle the virtual machine to apply the changes
2. Trigger the cold-boot (reboot with powercycle) from within the virtual machine. (e.g. using guest-agent additions)


6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.
1. Having a VM with outstanding Cluster compatibility upgrades. Login into the VM and run `reboot`. The VM should perform a graceful shutdown, will be powered off. Than it will be powered on again and the reboot has finished.

2. Having a VM with outstanding Cluster compatibility upgrades. Login into the VM and run some command, which will inform the hypervisor or rhv-manager, that this system needs a reboot, will perform this inclusive power-cycle and applying required vm version upgrade.


7. Is there already an existing RFE upstream or in Red Hat Bugzilla?
nothing found


8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?
asap


9. Is the sales team involved in this request and do they have any additional input?
no


10. List any affected packages or components.
possibly?
- vdsm
- ovirt-engine
- qemu-kvm-rhev


11. Would the customer be able to assist in testing this functionality if implemented?
limited, as he does not have a RHV-stage instance