Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1490107

Summary: [Docs][RFE][VMM] Verify (QE) and then Document an alternative method of configuring sysprep that does not require restart
Product: Red Hat Enterprise Virtualization Manager Reporter: Emma Heftman <eheftman>
Component: DocumentationAssignee: rhev-docs <rhev-docs>
Status: CLOSED DUPLICATE QA Contact: rhev-docs <rhev-docs>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 4.1.6CC: lbopf, lsurette, michal.skrivanek, mperina, rbalakri, srevivo, ykaul, ylavi
Target Milestone: ovirt-4.2.0Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1497933 (view as bug list) Environment:
Last Closed: 2017-12-12 02:27:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Docs RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1497933    
Bug Blocks:    

Description Emma Heftman 2017-09-10 11:56:40 UTC
Description of problem:
In bug https://bugzilla.redhat.com/show_bug.cgi?id=1269970 Miguel Martin (comment 11) suggested an alternative method of configuring sysprep (i.e. not using the engine-config) by making a copy of the default sysprep.

This method has the advantage not needing to restart the engine.
This method has been approved by Yaniv Kaul but needs to be verified by QE before it can be added to the documentation.

1. Install a Windows Machine, seal it, and create a template from it, just as described in the KCS.
2. Create a pool based on the previous template with sysprep customization.

For this solution, we will specify the user/pass and the product key using a custom sysprep (in pool 'Initial Run' tab), that is, a copy of the default sysprep.
In case of a Windows 7 x64 os, the default sysprep is in file '/usr/share/ovirt-engine/conf/sysprep/sysprep.w7x64'.

So, once we pasted the content of the file in the 'sysprep' textbox (in the pool 'Inital Run' tab) we modify the following info:

......
                <ProductKey>
                    <Key><![CDATA[$ProductKey$]]></Key>  ----------------------> with <Key>xxxx-xxx-xxx-xxx</Key>
                </ProductKey>
.....
                <Credentials>
                    <Domain><![CDATA[$JoinDomain$]]></Domain>
                    <Password><![CDATA[$DomainAdminPassword$]]></Password>  ----------------------> with the domain password<Password>mypassword</Password>
                    <Username><![CDATA[$DomainAdmin$]]></Username> ----------------------> with the domain admin user<Username>DomainAdministrator</Username>
                </Credentials>
......

There is no need to modify rest of the variables in the xml as they can be filled from the 'Initial Run' tab fields (Domain, OU, Organization Name, Custom Locale..)
Well, maybe I would modify the local user admin named 'user',:

......
           <UserData>
            ..........
                <FullName>"user"</FullName> <----------------------------- with <FullName>"mylocaladmin"</FullName>
            ..........
            </UserData>
......
               <LocalAccounts>
                    <LocalAccount wcm:action="add">
                        <Password>
                            <Value><![CDATA[$AdminPassword$]]></Value>
                            <PlainText>true</PlainText>
                        </Password>
                        <DisplayName>user</DisplayName> <----------------------------- with <DisplayName>mylocaladmin</DisplayName>
                        <Group>administrators</Group>
                        <Name>user</Name> <----------------------------- with <Name>mylocaladmin</Name>
                    </LocalAccount>
                </LocalAccounts>
.........

Comment 1 Lucy Bopf 2017-09-21 05:57:40 UTC
Given that this bug depends on the solution being QE tested first, we either need to change the component to the responsible engineering team, or raise a separate eng TEST ONLY bug to allow QE to schedule this.

Martin/Yaniv, can you help us identify the correct component against which to track this request?

Comment 2 Martin Perina 2017-09-21 09:07:01 UTC
Forwarding question to Michal

Comment 3 Michal Skrivanek 2017-09-21 11:50:08 UTC
IMO it doesn't need much verification, the suggested approach is a regular feature for couple releases already, so should be covered
The suggested procedure makes sense to me

Feel free to just make changes as part of the original bug and turn this one into virt TestOnly bug, or open new one, as you prefer

Comment 4 Lucy Bopf 2017-10-03 07:14:45 UTC
Thanks, Michal. Our policy is that all published documentation must be based on tested procedures, as confirmed by us: we ask for an existing test case, or we raise a new request. Because it's a newly-suggested procedure (though a supported and tested feature), we'd like to proceed with testing.

The original bug is almost complete now, so I'll keep this one for the docs request, and open a new bug for testing.

Comment 5 Lucy Bopf 2017-10-31 00:45:11 UTC
Setting target milestone to match QE test bug target.

Comment 6 Lucy Bopf 2017-12-12 02:27:20 UTC
Closing this one now, as the changes for bug 1269970 have been held pending the QE testing that this bug tracks.

Any changes will be addressed in bug 1269970.

*** This bug has been marked as a duplicate of bug 1269970 ***