Red Hat Bugzilla – Bug 1132191
[Windows sysprep] Run Once: Special characters are not encoded in XML sysprep files for Windows 7, 8, 2008, 2012
Last modified: 2015-07-10 05:08:40 EDT
+++ This bug was initially created as a clone of Bug #1122160 +++ Description of problem: When running a sealed Windows 7/7x64/8/8x64/2008/2008x64/2012x64 VM with sysprep floppy attached, all values provided from Run Once dialog are put in the sysprep file as plain-text, even when these Windows versions are using XML format for sysprep file, thus allowing to create a syntactically incorrect sysprep file. Version-Release number of selected component (if applicable): ovirt-engine-3.5.0-0.0.master.20140629172257.git0b16ed7.el6.noarch (beta) How reproducible: 100% Steps to Reproduce: 1. Have a "sealed" Windows VM, any of version 7, 7x64, 8, 8x64, 2008, 2008x64 or 2012x64 2. In Run Once dialog enter as the Admin Password value 'pass</word>' 3. Run the VM and watch the Windows initialization process Actual results: The Windows initialization fails on a parsing error of the unattend file. If you check it (A:\sysprep.inf), you see the admin password is put in the XML as plain-text: <AdministratorPassword> <Value>pass</word></Value> <PlainText>true</PlainText> </AdministratorPassword> Expected results: For Windows versions using XML sysprep files, all special characters should be encoded, such as: in GUI enter value 'pass</word>' and in sysprep file will be value 'pass</word>'. Additional info: +++ End of cloned data +++ Cloning this to RHEV. This has been seen as far back as 3.2 and in this case 'Run Once' was *not* used.
can you please clone the bug to 3.4.z? also i see the master/3.5 patch is missing from the bug.
(In reply to Eyal Edri from comment #2) patches on 3.5/master are using the corresponding oVirt bug
Verified in rhevm-3.5.0-0.11.beta.el6ev.noarch (vt3). All variables in XML sysprep template files are now placed into CDATA section so all characters are represented the same way as they are entered. For example password 'pass</word>' now doesn't cause parsing error and it's set in the Windows guest. Note that the above doesn't apply to *custom* sysprep file, where user has to take care about the sysprep file validity by himself.
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/RHSA-2015-0158.html