Q: Windows 7 or windows 2008 R2 guest fails to boot after executing sysprep
A: In these systems the unattended installer can fail when it finds a problem with a windows registry entry. The error message shown is "Windows could not finish configuring the system" (or "Windows no puede finalizar la configuración del sistema" in spanish systems). After clicking "OK", the system reboots to show the error message again.
One of the possible causes is a registry entry with a size over 8KB:
To solve this, update windows to SP1 or install the following Microsoft hotfix before running sysprep:
If it does not solve the problem, the registry entry (or more generally the error cause) can be found following these steps:
- When the error shows, press Shift+F10 to open a command line.
- Go to C:\Windows\Panther
- Run "tracerpt setup.etl -o events.txt", which will generate a events.txt file with the the events produced by the system until that moment.
- Open events.txt with a text editor (like notepad) and search for an event like "Failed to process reg key or one of its descendants" to identify the problematic registry entry.
- Examine the entry in the original system (before executing sysprep) to fix the problem.
Q: Windows 7 guest shows slow keyboard response
A: This problem is caused by a bug in the keyboard device driver, and can appear in virtual, as well as in physical machines. To solve it, you just have to change a registry key as shown in the text below (extracted from: http://keyliner.blogspot.se/2009/11/windows-7-slow-keyboard-response.html)
For desktop computers, there is a PS/2 DIN keyboard bug in Vista and Windows 7 that was originally fixed with a registry change. When Microsoft released Windows automatic update KB977074, the registry change broke and then alternately worked, depending on subsequent Microsoft updates. This is the fix that I am currently running and this resolved my keyboard-speed problem.
Update: Recent Microsoft patches in late April, 2010 or early May, 2010, and again in June, 2010, have done and then undone the changes recommended in this registry hack. I have now switched this solution one way or the other on three separate occasions; each time it fixed the problem. Since June, 2010, it has been solid. Read below for more details.
a. Start, Run, "Regedit"
If the RUN command is not visible, see this link.
b. Tunnel to this key:
c. On the detail side, "other-mouse-click" a blank area and add a new Dword-32 value. Name the key "PollStatusIterations" (no quotes)
Set value to Hex = 1
Caution, there are other registry keys with similar names.
d. Close Regedit and reboot.
e. If this value is already in the Registry, disable the key by renaming it to "xxPollStatusIterations" (Other-mouse-click, Rename). Reboot and test.
Reason: Depending on which MS patch has been applied, this registry change can re-introduce a slow keyboard problem. You will have to experiment with adding or removing this patch. I've switched this value on or (x) off three times. This is unfortunate. But in each case, it has dramatically fixed scrolling problems.
(Click image for larger view, "Back" to return)
Clearly, Microsoft is having troubles in this area. Expect to return to this value as Microsoft continues to work on this.
Q: In KDE 5, plasma shell 5.4 fails when changing screen resolution.
A: It is a known bug of KDE 5.
Symptoms: When the guest screen resolution is changed (when the flexVDI Client window is resized), the desktop becomes black and the pannels with launchers, main menu, task bar, etc. disappear. Alt+F2 shortcut still allows to run programs.
Temporary workaround: after changing resolution, open a terminal, kill "plasmashell" process and launch it again.
Q: A guest cannot be run because the user and group of one of the disk images or ISOs cannot be set
A: Guests are usually run as unprivileged user and group "qemu", to avoid security problems. As a result, libvirt automatically changes the ownership of disk images to this user to ensure that they can be read and written. Trying to run a Guest will fail if the ownership cannot be changed for any reason. In that case, you can modify the file
/etc/libvirt/qemu.conf to change this behavior:
- Change the "user" and "group" entries if you want to run Guests as another user, like root.
- Set dynamic_ownership to 0 if you do not want the ownership of the disk images to be changed by libvirt. In this case, you should also set the user and group to root.