+++ This bug is a downstream clone. The original bug is: +++ +++ bug 1387625 +++ ====================================================================== Description of problem: Deploying virtual machine from template, "Initial Run" -> "Custom Locale" settings it isn't taken by deployment process across sysprep Version-Release number of selected component (if applicable): RHEV 3.6 RHV 4.0 How reproducible: 100% Steps to Reproduce: 1. Create windows 10VM. and then use "Initial Run" -> "Custom Locale" settings 2. Use locale as es_ES, but its not working 3. create template from VM and use custome locale,its not working. Actual results:- We are not able to change the language using custom locale Expected results: Language should get changed if we use custom locale under cloud init option. Additional info: (Originally by Vaibhav Pagar)
Possibly the same issue as bug 1387699 Please add the created Unattend.xml from teh sysprep floppy. Also Windows-side setup event log. You can find the setuperr.log in the Windows\System32\Sysprep\Panther folder. (Originally by michal.skrivanek)
ping? (Originally by michal.skrivanek)
Created attachment 1223462 [details] Unattended .xml (Originally by Vaibhav Pagar)
Hi team, just add in above comment, I have tested with some options in template for locale as: es_ES.UTF-8, es, es_ES all those gives same results. Also in discussion with customer, the workaround is to set the values while first boot only right? Do you have any other suggestions for workaround? (Originally by Ulhas Surse)
Customers update :- "According to our Windows specialist, configuring the values at first boot didn't work either" (Originally by Vaibhav Pagar)
we suspect the architecture is wrong in the sysprep templates. Please try to check amd64 vs x86 arch settings in the file, corresponding to the Windows 32bit vs 64bit. I suppose the versions in question here are 64bit? (Originally by michal.skrivanek)
From what I see it looks like you are trying to use template for 32-bit machine but your architecture is 64-bit. Can you check that you have correct OS set up in the VM properties for the affected VM? It should be "Windows 10 x64". But even if you fix the OS in VM properties you will still be affected by the following bug that we're currently working on: https://bugzilla.redhat.com/show_bug.cgi?id=1387699 (Originally by Tomas Golembiovsky)
I am using ISO Win10_1511_2_English_x64.iso for windows isntallation. its 64-bit architecture of Win10. Can you check that you have correct OS set up in the VM properties for the affected VM? --> Yes. I can confirmed that correct OS is set up for the VM, I am attaching screen shot of the VM configuration on the case. Please check screen shot. (Originally by Vaibhav Pagar)
Created attachment 1229018 [details] Screenshot-Win10 (Originally by Vaibhav Pagar)
Can you check the relevant template as is being fixed in patches of bug 1387699? (Originally by michal.skrivanek)
I have checked for the template as well, operating system is set to "Windows 10 x64" Please find attached screenshot "WinTemp" (Originally by Vaibhav Pagar)
Created attachment 1229352 [details] WinTemp (Originally by Vaibhav Pagar)
Sorry to not being clear enough, I've meant the sysprep template, i.e. /usr/share/ovirt-engine/conf/sysprep/sysprep.w10x64 (Originally by michal.skrivanek)
Verification builds: ovirt-engine-4.0.7-0.1.el7ev qemu-kvm-rhev-2.6.0-28.el7_3.3.x86_64 vdsm-4.18.22-1.el7ev.x86_64 libvirt-client-2.0.0-10.el7_3.4.x86_64 sanlock-3.4.0-1.el7.x86_64
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. https://rhn.redhat.com/errata/RHBA-2017-0542.html