Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1402822 - [z-stream clone - 4.0.7] Custom Locale settings on deploy of new virtual machine with sysprep option doesn't work
[z-stream clone - 4.0.7] Custom Locale settings on deploy of new virtual mach...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.6.9
Unspecified Unspecified
high Severity medium
: ovirt-4.0.7
: ---
Assigned To: Tomáš Golembiovský
Nisim Simsolo
: ZStream
Depends On: 1387625 1387699
Blocks:
  Show dependency treegraph
 
Reported: 2016-12-08 07:23 EST by rhev-integ
Modified: 2017-03-16 11:30 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
A bug was discovered in the sysprep templates for 64-bit platforms where some parts were improperly marked as "for 32-bit platform" and thus ignored by Windows. This has now been fixed.
Story Points: ---
Clone Of: 1387625
Environment:
Last Closed: 2017-03-16 11:30:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 67987 ovirt-engine-4.0 MERGED engine: various fixes in sysprep XML templates 2016-12-08 10:27 EST
Red Hat Product Errata RHBA-2017:0542 normal SHIPPED_LIVE Red Hat Virtualization Manager 4.0.7 2017-03-16 15:25:04 EDT

  None (edit)
Description rhev-integ 2016-12-08 07:23:07 EST
+++ 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)
Comment 1 rhev-integ 2016-12-08 07:23:15 EST
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)
Comment 3 rhev-integ 2016-12-08 07:23:21 EST
ping?

(Originally by michal.skrivanek)
Comment 6 rhev-integ 2016-12-08 07:23:36 EST
Created attachment 1223462 [details]
Unattended .xml

(Originally by Vaibhav Pagar)
Comment 7 rhev-integ 2016-12-08 07:23:41 EST
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)
Comment 8 rhev-integ 2016-12-08 07:23:46 EST
Customers update :-

"According to our Windows specialist, configuring the values at first boot didn't work either"

(Originally by Vaibhav Pagar)
Comment 14 rhev-integ 2016-12-08 07:24:17 EST
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)
Comment 15 rhev-integ 2016-12-08 07:24:23 EST
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)
Comment 16 rhev-integ 2016-12-08 07:24:28 EST
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)
Comment 17 rhev-integ 2016-12-08 07:24:33 EST
Created attachment 1229018 [details]
Screenshot-Win10

(Originally by Vaibhav Pagar)
Comment 18 rhev-integ 2016-12-08 07:24:37 EST
Can you check the relevant template as is being fixed in patches of bug 1387699?

(Originally by michal.skrivanek)
Comment 19 rhev-integ 2016-12-08 07:24:42 EST
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)
Comment 20 rhev-integ 2016-12-08 07:24:48 EST
Created attachment 1229352 [details]
WinTemp

(Originally by Vaibhav Pagar)
Comment 21 rhev-integ 2016-12-08 07:24:54 EST
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)
Comment 24 Nisim Simsolo 2017-02-01 10:37:31 EST
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
Comment 26 errata-xmlrpc 2017-03-16 11:30:28 EDT
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

Note You need to log in before you can comment on or make changes to this bug.