2. Who is the customer behind the request?
Account name: Red Hat IT
Customer segment: 1
TAM/SRM customer: yes/no
Strategic Customer: yes
3. What is the nature and description of the request?
If we create a VM and specify some OS (i.e. RHEL 6 x86_64) for it (this influences settings of libvirt, qemu-kvm, etc.), then install a completely different OS such as Windows 7 64-bit, RHEV-M should correct its entry for what's being reported back from the guest agent.
We already have info from the agent so we should go ahead and use it. The guest OS could be changed whenever VM is in down status.
4. Why does the customer need this? (List the business requirements here)
Settings in RHEV-M influences which parameters and settings of VM libvirt passes to KVM, i.e. it's default virtual graphic adapter,
some Vmemory and VCPU tweaks, etc. So this actually influences performance of the guest itself.
5. How would the customer like to achieve this? (List the functional
Have the guest agent's data be used to modify the entry within RHEV-M if the OS level and Arch type is different that what's initially set.
6. For each functional requirement listed in question 5, specify how Red Hat
and the customer can test to confirm the requirement is successfully
Set the OS to RHEL 6 x86_64 in RHEV-M and install Windows 7 64-bit. Install the guest agent on the Windows box. Either the RHEV-M should be updated then, or when the VM is in a down status.
7. Is there already an existing RFE upstream or in Red Hat bugzilla?
8. Does the customer have any specific timeline dependencies?
9. Is the sales team involved in this request and do they have any additional input?
10. List any affected packages or components.
11. Would the customer be able to assist in testing this functionality if
maybe have the guest report the guest OS, and compare/warn when guest moves to 'up' if they do not match?
(I'd limit to audit log warning for user to take the corrective action)
(In reply to comment #1)
> maybe have the guest report the guest OS, and compare/warn when guest moves
> to 'up' if they do not match?
> (I'd limit to audit log warning for user to take the corrective action)
The guest agent is reporting partially the guest OS already, if it is running on windows it is reporting for example 'Win 8', 'Win 7', 'Win 2008', 'Win 2008 R2' etc
On Linux it's reporting the kernel-release 'uname -r'
(In reply to comment #2)
> (In reply to comment #1)
> > maybe have the guest report the guest OS, and compare/warn when guest moves
> > to 'up' if they do not match?
> > (I'd limit to audit log warning for user to take the corrective action)
> The guest agent is reporting partially the guest OS already, if it is
> running on windows it is reporting for example 'Win 8', 'Win 7', 'Win 2008',
> 'Win 2008 R2' etc
> On Linux it's reporting the kernel-release 'uname -r'
It's reported as 'guestOs' in VmStats
report TZ as well
didn't make it for 3.5
we want to report the OS to distinguish at least Linux/Windows, architecture, and TZ settings (TZ offset in guest should match offset in configured TZ)
Verified with rhevm-3.6.0-0.18.el6.noarch.
link to polarion test run:
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.