Description of problem: Windows VMs show 'Actual time zone in guest differs from the configuration' and 'Actual time zone in operating system type differs from the configuration' however the OS is set in the RHEV-M properly as is the timezone Version-Release number of selected component (if applicable): rhevm-3.6.6.2-0.1.el6.noarch How reproducible: Unknown at this time, issue appeared after upgrade to 3.6. Steps to Reproduce: 1. 2. 3. Actual results: Windows VM s have an ! next to them and display the message in the description Expected results: No errors, as the data lines up. Additional info: Customer data coming in a future update.
please updated namely with the ovirt guest agent version running in the VM
Michal, The version of tools is 3.6.6 in the guest. I'll provide some screenshots in just a moment.
Robert, please ensure that the Timezone configured in the Virtual Machine matches the setting in the edit vm System / General / Time Zone setting If those are not matching the exclamation mark is shown.
Vinzenz, the customer noted that if he does a shutdown of the VM, then start the VM again, instead just a reboot, rhevm will clear the time zone error. Is it possible the VM's stats in the manager just didn't refresh until a full shutdown was done?
It's possible that the customer fixed the timezone difference in the 'edit vm' dialog and until a stop and restart of the VM those things aren't applied and that's why it is shown. That's the only explanation that I have. If that is the case, this would be expected. Can you confirm?
Vinzenz, The customer mentioned "I figured out that if I do a shutdown of the VM, then start the VM again, instead just a reboot, rhevm will clear the time zone error." so it appears that's exactly what happened. Thanks for this!
Closed according to Comment #7
It may have been premature to close this. I have a large customer running the latest RHEV Tools, 3.6.6, with a bunch of Windows 7 VMs set to Eastern Time, both in the Virtual Machine attributes and inside the VMs. Yet that "!" still shows up and still says the timezones don't match. But the timezones do match. I also see the problem in my own environment, although I am running RHEV Tools 3.6.5. I'll update my RHEV tools and see what happens to the behavior. - Greg Scot
From Greg's customer: RHEV Tools updated as of last week is 3.6.6 and "!" still exists. We tried all combos. POWER OFF and POWER ON VMs. Stopped and started ovirt-engine. Rebooted the RHEVM. Nothing appears to work. Putting this BZ back to a NEW state.
(In reply to Greg Scott from comment #9) > It may have been premature to close this. I have a large customer running > the latest RHEV Tools, 3.6.6, with a bunch of Windows 7 VMs set to Eastern > Time, both in the Virtual Machine attributes and inside the VMs. Yet that > "!" still shows up and still says the timezones don't match. But the > timezones do match. > > I also see the problem in my own environment, although I am running RHEV > Tools 3.6.5. I'll update my RHEV tools and see what happens to the behavior. You need to have a 3.6 VDSM / RHEVH with a 3.6 engine and 3.6 Guest agents to make this go away. Also the configuration needs really to match. If the configured TimeZone in the windows VM does not match the setting in Edit VM Dialog in the System section it will not work either. The same applies to the configured type of the OS if there's not configured that this is a Windows 7 VM but something else it will also be complaining about that. Once those settings have been saved the VM needs to be completely shutdown and then started so the settings apply in the engine. And only then, the exclamation mark will go away Please ensure that this is really the case. I have not seen a single case where not one of the points above was violated: Problem points: - VDSM/RHEVH lower than 3.6 - Guest Agent on VM either not running or less than 3.6 version - Settings for the timezone in the VM and the Engine differ - Real OS Type differs from configuration in the engine
The customer reports all these are true. RHEVH-7.2.something, RHEVM 3.6.8, RHEV Tools 3.6.6 with updated templates and VMs. The RHEVH hosts are GMT, but VMs and RHEVM are both EDT. And everything in the test lab started multiple times from scratch. I have not yet updated my own stuff to 3.6.8 and I don't remember what my own Windows VMs are running for RHEV Tools drivers. So let me see what happens here with my stuff and I'll report back. - Greg
Thank you Greg, putting the needinfo back to mark we are waiting for this info. Also please provide the ovirt guest agent, vdsm and engine logs. thank you
Well go figure... I updated my own RHEV environment from 3.6.5 to 3.6.8. And I have the RHEV-Tools 3.6.5. Before - two of my Windows server VMs showed the "!" and complained about timezone mismatches. When I edit both VMs, the RHEV setting shows US Central for a time zone. And from inside the VM, both VMs Windows time settings show US Central for a timezone. I upgraded the RHEV tools in each VM to 3.6.5 and rebooted. VM infradc2012 needed to go through a Windows Update. After it finished booting, I shut it down and it powered off. VM mail2013 just rebooted after upgrading RHEV tools. No power off/on. After "power" cycling one VM and a simple reboot of the other, the "!" is still there. But now when I hover my mouse over the "!", it tells me that's a RHEV Tools update. But no timezone mismatch warning. I have no idea why they both think there's an updated RHEV tools. I just installed the updated RHEV tools. - Greg Scott
Hmmmm.... About 7 hours later after comment 14. No more "!" for either of those 2 VMs. Other than the passage of time, what else changed? All I can think of is, I ejected the RHEV Tools ISO from both of them. I just now mounted the RHEV Tools ISO in mail2013 and left it ejected in infradc2012. Let's see if that "!" comes back for mail2013. - Greg
I have a test pool of 5 Windows 7-64 bit VMs. All of them show the "!" and complain that the OS type differs from what's configured and the timezone mismatches. I built the template last fall with 3.5 and the version of RHEV tools at that time - 3.5.9 maybe? And the VM on which I based the template also has the same behavior. So this is another "before" state. The VMs in my test pool are not stateless, so I can make persistent changes. I just booted one of the test pool VMs and I'm updating its RHEV tools. After mounting the 3.6.5 RHEV tools ISO, hovering over the "!" also tells me mew guest tools are available, in addition to the timezone and OS mismatch warnings. The RHEV tools update went in without incident. I'll shut it down and power it off and let's see how it behaves. The instant that it shut down and the console window disappeared, the "!" went away in RHEVM. After powerup, the "!" came back, now with just the new guest tools message. I ejected the RHEV tools ISO and the "!" is still there with the new guest tools message. "Power" cycling again, now with the ISO ejected... Oh wow... On the way back up, now it's showing me the timezone and OS mismatch warnings again! Going into Windows Control Panel...Programs and features - I see those RHEV tools packages were installed this morning. So the VM did not revert (it's persistent so it's not supposed to revert). The newest RHEV tools are still there. But hang on a second - back to RHEVM - now no "!" for that VM at all. I wonder if those warnings show up transiently during VM boot and before all the RHEV tools fire up? Let's try this again, keeping a closer eye on RHEVM instead of going to a console. "Power" cycling again... Yup - the "!" with timezone and OS mismatch warnings do show up as it's booting and all go away once it's fully and running. The new guest tools message is also gone after ejecting the ISO image. Let's try another "power" cycle with the RHEV Tools ISO mounted. I noticed on the way down, it also flashes the OS mismatch and timezone messages. Back up again the "!" came and went as before. Now no "!" and no message about updated guest tools. Going to a console and firing up RHEV-toolsSetup.exe - it "knows" the versions of everything are current. Cancel the setup program. I'll let it sit here idle for a while and let's see what happens. - Greg
10 hours later . . . None of the VMs from my comments above are showing any "!" in the display, neither with or without the RHEVTools ISO mounted. I'm dismounting the RHEV Tools ISO image from everywhere before I forget where I mounted it. I am unable to reproduce this problem in my environment running the newest RHEVM 3.6.8. - Greg
I'm on the phone with John right now. His is still broken with the newest versions of everything. There are few differences between John's broken set up and my good setup. John has a Windows 7 X64 VM running RHEV Tools 3.6.6 in a RHEV 3.6.8 environment. Newer than mine at 3.6.5. His timezone is US Eastern. The timezone and OS version match when editing the VM and from within the VM. Yet when hovering over the "!", John still sees the OS Version and timezone warnings. What's different on John's broken environment and my good environment? John's RHEV Tools are at 3.6.6. Mine are 3.6.5. Could a new bug be in the 3.6.6 RHEV tools? (Doubtful) John's RHEVH hosts are 6.7-20160104.2. Mine are 7.2-20160413.0 Could old RHEVH hosts make a difference? (Maybe. I don't have a feasible way to test this.) - Greg
Tell me if this hunch is true: The newest VDSM has hooks to report conditions such as timezone mismatches and OS mismatches. But the old VDSM had no such hooks. So on hosts with the old VDSM and RHEVM with the new VDSM, we see "!" scenarios because the new RHEVM gets no reports from old hosts on these conditions. Does this hold water? - Greg
(In reply to Greg Scott from comment #19) > Tell me if this hunch is true: > > The newest VDSM has hooks to report conditions such as timezone mismatches > and OS mismatches. But the old VDSM had no such hooks. So on hosts with the > old VDSM and RHEVM with the new VDSM, we see "!" scenarios because the new > RHEVM gets no reports from old hosts on these conditions. > > Does this hold water? That is the first in my list, RHEVH 6.7 is not a 3.6 cluster version since with 3.6 we require RHEL7 hosts in Comment#11 https://bugzilla.redhat.com/show_bug.cgi?id=1344521#c11 > Problem points: > - VDSM/RHEVH lower than 3.6 > - Guest Agent on VM either not running or less than 3.6 version > - Settings for the timezone in the VM and the Engine differ > - Real OS Type differs from configuration in the engine
Sorry Vinzenz, I missed that. Is there a possibility of turning this into an RFE such that if RHEVM doesn't get a report from the host - maybe because it's a lower VDSM version, maybe because an early or missing version of RHEV Tools, add a new popup status code about no VDSM status response from the VM? That way the "!" status tells the truth. I ask because my customer is showing these screens to top managers and they all ask about that "!" and bogus timezone warnings. Wayne tries to explain what's going on, but he reports the behavior hurts their confidence. When they go to production, they'll see it on a couple thousand VMs until all the hosts and everyone's RHEV tools are updated. thanks - Greg
(In reply to Greg Scott from comment #21) > Sorry Vinzenz, I missed that. > > Is there a possibility of turning this into an RFE such that if RHEVM > doesn't get a report from the host - maybe because it's a lower VDSM > version, maybe because an early or missing version of RHEV Tools, add a new > popup status code about no VDSM status response from the VM? That way the > "!" status tells the truth. No, we are not going to implement that, especially if RHEL 7.x hosts report correctly. Upgrade. > > I ask because my customer is showing these screens to top managers and they > all ask about that "!" and bogus timezone warnings. Wayne tries to explain > what's going on, but he reports the behavior hurts their confidence. When > they go to production, they'll see it on a couple thousand VMs until all the > hosts and everyone's RHEV tools are updated. Upgrade is the right solution in this case. Let's assume we do implement this - it'll require an upgrade (of Engine, but still - it's going to be 4.x based, which is a migration + upgrade and doesn't support RHEL 6.x hosts anyway). > > thanks > > - Greg
Agreed, upgrade is the right solution. But this will take at least several months for larger customers and the logistics demand a bridge with 3.6 first before going to 4.0. Even with newer hosts with the latest VDSM, some VMs may not have RHEV Tools installed, or may have an old RHEV Tools. If it's an easy fix to make that popup tell the truth instead of giving a bogus warning, it's a good investment and will save lots of support cases. - Greg
(In reply to Greg Scott from comment #23) > Agreed, upgrade is the right solution. But this will take at least several > months for larger customers and the logistics demand a bridge with 3.6 first > before going to 4.0. > > Even with newer hosts with the latest VDSM, some VMs may not have RHEV Tools > installed, or may have an old RHEV Tools. If it's an easy fix to make that > popup tell the truth instead of giving a bogus warning, it's a good > investment and will save lots of support cases. If there are no tools, there should be no warning. Otherwise, it's a bug that has to be fixed. If there are tools, we'd like them to be up-to-date. > > - Greg
Thanks Yaniv, that works. Is there time to get it into 3.6.9? Also, can they use RHEV Tools 3.6.6 in the 3.5 production RHEV environment? That gets a head-start on the RHEVM 3.6 upgrade. - Greg
(In reply to Greg Scott from comment #25) > Thanks Yaniv, that works. Is there time to get it into 3.6.9? Also, can > they use RHEV Tools 3.6.6 in the 3.5 production RHEV environment? That gets > a head-start on the RHEVM 3.6 upgrade. > > - Greg Did you confirm that when there are no tools, there's still a warning? I believe the tools can be used in 3.5 production - but need to ask QE. Pavel?
> Did you confirm that when there are no tools, there's still a warning? I didn't, no. The bogus warning does happen with old tools. I can get rid of tools on one of my test pool VMs and see what happens with no tools. Even easier - I suppose I can just stop the RHEV agent. Let me see if I can make that happen later tonight. - Greg
> Did you confirm that when there are no tools, there's still a warning? Now I can confirm it. On the same VM where I put 3.6.5 RHEV tools, I removed them. Now RHEMV shows the "!" and hovering over it displays both the timezone and OS mismatch warnings again. - Greg
(In reply to Greg Scott from comment #28) > > Did you confirm that when there are no tools, there's still a warning? > > Now I can confirm it. On the same VM where I put 3.6.5 RHEV tools, I > removed them. Now RHEMV shows the "!" and hovering over it displays both the > timezone and OS mismatch warnings again. > > - Greg That's not a valid test. If you had the tools once, they already reported the data. We have no event for 'tools removed - clear the data' anywhere, and it makes little sense to me to add such logic. Meital - can you perform the relevant tests? 1. Ensure that a VM that is configured with the wrong time zone, but without tools, does not have the ! mark next to it. 2. Ensure that when tools are added, the ! mark is properly added. 3. Ensure that when the timezone is corrected 3a. - in the VM - the ! mark is gone. 3b. - in the Engine - the ! mark is gone. TIA, Y.
OK. I have a Windows 7-64 bit ISO sitting here, so I can set up a brand new VM. I'll keep a running log here. I just now created a brand new VM named cleverly named Win7-64NoTools. It's all set for the initial Windows install but I have not booted it yet. It's showing a "!" with an OS type mismatch warning. Which makes sense since it doesn't have anything installed yet. Booting... forgot to set up boot order.... booting again, this time I mean it. Installation starting. I see I also forgot about tinkering with disk drivers. As long as I'm here, try out virtio-scsi. And Windows doesn't mean it when it says it can't install in disk 0 partition 2. The trick is just install there anyway... And a couple minutes later - a basic Windows 7 install, no patches, no NIC. Just a barebones system. The "!" still shows the OS mismatch warning. Shutting down. VM down, "!" is still there, same warning. Double-checking with "Edit" - the OS type is Windows 7 x64. Powering it up again. Now from inside the VM - Windows 7 Professional, 64-bit Operating System. So they should match. But the OS type mismatch warning is still there in RHEVM. - Greg
As Greg wrote, until you install GT the '!' is there complaining about different OS version. On the other hand timezone setting doesn't care about GT and reports correct information, when I set it to different thing in VM than in engine, '!' is there with timezone mismatch warning, if I set it to the same thing inside a VM and in engine, there is no warning about timezone mismatch. Test steps: 1) Installed Win7 64b, set Windows 7 x64 as OS and a GMT+1 timezone, in Win7 I set GMT+1 timezone as well - there is warning about OS version 2) set GMT in engine and restart the VM - warning about timezone and OS version 3) install GT - warning about timezone 4) set GMT+1 in engine and restart the VM - no warning
ok, so when the GA is properly installed, everything works as expected. Considering all the VMs should have GA installed, I would not consider this to be a bug, just a usability issue. Webadmin should not complain about incorrect timezone/os if the GA is not installed, instead it should complain that it is missing the GA data and advise the user to make sure the GA is installed and running. Not something for z-stream I'd say, changing to 4.1 RFE. But considering this confused quite couple of users, setting it's priority to high.
*** Bug 1334781 has been marked as a duplicate of this bug. ***
Verified on 4.1.0-8