Created attachment 1244471 [details] Compressed archive (ZIP) containing screenshots (PNG) of workarounds. Description of problem: This was tested most recently on a Windows Server 2012 R2 (x64) guest. ovirt-guest-tools-setup runs and reports as being complete, but when you go back and check under Services, you'll find that Spice and QEMU services failed to start. This is a result of there being no driver installed for "PCI Device" (requiring VirtIO Balloon Driver) and "PCI Simple Communications Controller" (requiring VirtIO Serial Driver). If setup is going to install those services, it should also install the drivers upon which they depend. At the very least, it should show an error that some services failed to start along with instructions for installing the drivers. The oVirt project is advertised as an alternative to the dominant commercial virtualization solutions such as vSphere. If the aim is to reach a similar level of maturity, the tools should work in an expected manner. In a vSphere environment, when you install vmware-tools on the guest, it installs services *along with the required drivers*. Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1.Setup Windows Server 2012 R2 (x64) guest in oVirt 4.1 2. Attach ovirt-guest-tools ISO version 4.1-1.fc24 (however, same behavior in earlier 4.0.x releases) 3. Run ovirt-guest-tools-setup inside the guest Actual results: The setup reports as being complete, and does not indicate anything being wrong, yet it fails to start all the services it has installed, notable QEMU and Spice. It's unable to start these services due to not installing the required VirtIO Serial and VirtIO Balloon drivers -- which are included in the ISO. Expected results: Setup installs the drivers that are required for running the various services it installs. Setup includes basic checks to ensure all services start as expected, with useful errors when some or all services do not start. Additional info: A workaround: Before running ovirt-guest-tools-setup, go to Device Manager and right-click on the two unknown devices lacking drivers (PCI Device and PCI Simple Communications Controller), selecting 'browse my computer for driver software', selecting the drive letter for the ovirt-guest-tools ISO (typically D:\), clicking Next and confirming the installation of the VirtIO drivers. *This should not be necessary.*
Note a related bug, 1416533 https://bugzilla.redhat.com/show_bug.cgi?id=1416533
(In reply to Daniel Beckman from comment #1) > Note a related bug, 1416533 > https://bugzilla.redhat.com/show_bug.cgi?id=1416533 I think they both have the same root cause, namely that the path used on win2k* is wrong
Sent https://lists.freedesktop.org/archives/spice-devel/2017-January/035215.html upstream which hopefully will fix both bugs.
(In reply to Christophe Fergeau from comment #3) > Sent > https://lists.freedesktop.org/archives/spice-devel/2017-January/035215.html > upstream which hopefully will fix both bugs. Thanks! I pushed this to gerrit [1] and jenkins built it [2]. Daniel - can you please try this build and see if it works? Thanks! [1] https://gerrit.ovirt.org/71226 [2] http://jenkins.ovirt.org/job/ovirt-wgt_master_create-rpms-fc24-x86_64_created/22/
As correctly predicted, it fixes both bugs. I built a new Windows Server 2012 R2 VM, loaded Windows (loading disk drivers with virtio-win virtual floppy), mounted new oVirt Guest Tools ISO, and ran ovirt-guest-tools-setup (*without* going into Device Manager and manually updating drivers). Setup ran without incident and installed the services and drivers. Just to confirm, I power cycled machine. When it came back up all services were running and no devices lacked drivers. Looking good -- thanks! I used the ISO from the second link: http://jenkins.ovirt.org/job/ovirt-wgt_master_create-rpms-fc24-x86_64_created/22/ The Applications tab for this VM shows as follows: Installed Applications Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.17 QEMU guest agent oVirt Guest Tools 4.2-0_master.20170126081651.git44a8701.fc24 Thanks, Daniel
So I went to upgrade a Windows 10 (x64) VM running an older version of oVirt Guest Tools (installed from the standard oVirt repo --- oVirt-toolsSetup_4.0-1.fc23.iso) and setup complained "unsupported Windows version".
(In reply to Daniel Beckman from comment #6) > So I went to upgrade a Windows 10 (x64) VM running an older version of oVirt > Guest Tools (installed from the standard oVirt repo --- > oVirt-toolsSetup_4.0-1.fc23.iso) and setup complained "unsupported Windows > version". Only the latest version of ovirt-guest-tools (4.1* ?) supports win10 as far as I know, so this would be expected.
Let me explain that better. I had an *existing* VM running Windows 10 which *already had* an older oVirt Tools (4.0-1.fc23) installed. That installed fine several months ago with no error. That older version of oVirt Tools includes drivers for Windows 10. What I attempted was to *upgrade* from that older version (which had been working fine -- with the usual workarounds involving manually installing the drivers and correcting the path for the Balloon service), to the newest 4.2 build I just downloaded (4.2-0_master.20170126081651.git44a8701.fc24). That is when I got the message about "unsupported Windows version." This ends with an 'OK' button and there is no way to continue setup. I did not get that message in the earlier version installed some time ago. Only with the new version.
Update: on that same Windows 10 VM, after having waiting a couple of days and going back to it -- still with the same user session and having never power cycled or logged out -- I ran ovirt-guest-tools-setup again and it did *not* through the error this time. Setup completed fine and I was able to switch to QXL drivers. What could have changed between my earlier attempt and now, I do not know [shrug]. I also tested setup with the new ovirt tools on a newly built Windows 10 VM and it worked fine. Whatever is used to detect Windows versions may have had an intermittent problem, or maybe I'm just crazy. :)
Moving to verified according to comment #9