Bug 1006659 - prestarted VMs in a pool do not use sysprep file [NEEDINFO]
prestarted VMs in a pool do not use sysprep file
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.2.0
Unspecified Unspecified
urgent Severity high
: ---
: 3.3.0
Assigned To: nobody nobody
Artyom
virt
: Reopened, ZStream
Depends On:
Blocks: 1009052
  Show dependency treegraph
 
Reported: 2013-09-11 00:25 EDT by Bryan Yount
Modified: 2015-09-22 09 EDT (History)
18 users (show)

See Also:
Fixed In Version: is14
Doc Type: Bug Fix
Doc Text:
Previously, pre-started Windows virtual machines in a virtual machine pool would not run sysprep when they start for the first time. With this update, pre-started Windows virtual machines in virtual machine pools now run sysprep correctly when they start for the first time.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-21 12:37:04 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
cboyle: needinfo? (nobody)


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 484393 None None None Never

  None (edit)
Description Bryan Yount 2013-09-11 00:25:22 EDT
Description of problem:
When a VM is spun up as part of a "prestarted pool", it does not properly use the appropriate sysprep file and thus the VM does not join the Active Directory domain.

Version-Release number of selected component (if applicable):
3.2.2

Steps to Reproduce:
1. Create a pool
2. Select a Windows 7 template
3. Enable a number of prestarted virtual machines

Actual results:
The resulting VMs are not sysprepped

Expected results:
The VM should sysprep properly
Comment 2 Bryan Yount 2013-09-11 21:49:42 EDT
I tested this on my own environment which isn't connected to an AD domain but the results of the test should still be the same. I am merely observing if the A:\sysprep.inf file is presented to the guest when I log in:

   1. created a pool of 5 Windows 7 VMs
   2. set the prestart number to 2
   3. logged into the User Portal
   4. Checked out a VM from that pool
   5. Connected to the guest
   6. Filled out the Windows Setup questions that you see when there is no sysprep file present
   7. The VM did not reboot; it logged me in automatically
   8. No A:\sysprep.inf file exists

Are the customer and/or myself doing something wrong here?
Comment 5 Michal Skrivanek 2013-09-16 05:00:37 EDT
closing in 3.3 as fixed
Comment 9 Michal Skrivanek 2013-09-16 11:57:45 EDT
should be tested...
Comment 13 Artyom 2013-09-25 05:16:08 EDT
Can you please describe more explicit "The VM should sysprep properly".
If you seal vm from what you do template for vm pool?
Steps that I did:
1) Create vm and installed on it windows7
2) Seal vm above
3) Create template from vm
4) Create new vm pool with template of windows7
5) Check two vms in pool as prerestarted
6) Wait until prerestarted vm is UP and console to this vm

What I need to check?
Comment 14 Bryan Yount 2013-09-25 18:15:49 EDT
(In reply to Artyom from comment #13)
> Can you please describe more explicit "The VM should sysprep properly".
> If you seal vm from what you do template for vm pool?
> Steps that I did:
> 1) Create vm and installed on it windows7
> 2) Seal vm above
> 3) Create template from vm
> 4) Create new vm pool with template of windows7
> 5) Check two vms in pool as prerestarted
> 6) Wait until prerestarted vm is UP and console to this vm
> 
> What I need to check?

Hey sorry I missed a ping about this the other day. So here's what the procedure is for any pool...
1. Create VM with Win7
2. Seal vm
3. Create template from vm
4. Create new vm from pool using template
5. Create a pool of X number of vms

[Steps 6-10 if automatic pool is NOT prestarted]
6. Admin manually powers up X number of vms from the AdminPortal using the runonce feature and attaching the sysprep floppy. This makes any changes to the vm stateful.
7. The vm reads the A:\sysprep.inf file and properly joins the domain
8. vm is powered off
9. User connects to UserPortal and checks out a vm from the pool
10. vm boots and is stateless

[Step 6-9 if automatic pool IS prestarted]
6. Admin selects Y number of vms to be prestarted
7. Y vms automatically boot, sysprep, and reboot
8. User logs into UserPortal and checks out a vm from the pool
9. vm is already booted so is available instantly

Is it not correct that the prestarted vms should automatically also sysprep? If not, what's the point of prestarting them if they don't sysprep ahead of time?
Comment 15 Bryan Yount 2013-09-25 18:19:13 EDT
To specifically answer your question, I would expect that the A:\sysprep file would be automatically presented to the prestarted VM in a pool the first time it boots. I didn't have an Active Directory environment when I tested this but the customer reported the same issue and they do have a proper AD environment.

Without an AD system myself, I wouldn't expect my sysprep process to actually complete. However, as long as the system doesn't power off, I should still see a virtual floppy disk presented to my VM, and I don't.
Comment 16 Artyom 2013-09-27 01:45:04 EDT
In manual write, that prerestarted mode need just for reducing time that user receive vm(vm is power on, so no need to wait until vm will be in up state), so I not sure about sysprep file.
Michael can you please describe whole flow of prerestarted vm?
If vm prerestarted what it must do in time of power on?
Comment 17 Travis Michette 2013-09-27 17:26:36 EDT
Artyom -

You are correct in the purpose of the Pre-Start mode which is why it is a desired feature. However, the reasoning behind this bug is the following:

1. VMs from the pool will sysprep properly from the Power User Portal with either a regular user or elevated user permissions (wasn't working quite right because of another bug that has since been resolved and patched)

2. VMs from the pool will sysprep properly from the WebAdmin Portal with proper administrative login credentials.

3. VMs from the pool that are "pre-started" don't appear to be going through the same sysprep process as in scenarios 1 & 2. The VMs using the prestarted mode should go through the same sysprep process and be 100% ready when they are presented to the users from the User Portal. This behavior is currently not happening and is unexpected behavior for this feature. It appears that the a:\sysprep floppy isn't being properly presented to the system during the pre-start process as it is for the above two methods.

This has been tested multiple times with the same pool. Any "prestarted" VMs are not getting properly sysprepped, while the manual start and wait machines are using the sysprep file and functioning properly.


Thanks,

Travis
Comment 18 Artyom 2013-09-29 02:57:21 EDT
Question about a:\sysprep, it created in time of sealing vm os or I need to create it by myself?
If it created in time of sealing vm os(I do sealing from administrative manual) and I create new vm pool from template with sealing os, I see the same thing, when I start vm from pool by myself or it was started because prerestarted option(also tried create new vm not pool, from sealed template, the same thing), it welcome screen, where I need to save basic settings(language, timezone, user name...) and I don't see any floppy disk in my os.
If I need to create answer file by myself(sysprep.inf) after sealing os, how can I do it?
Comment 19 Bryan Yount 2013-10-01 14:24:29 EDT
(In reply to Artyom from comment #18)
> Question about a:\sysprep, it created in time of sealing vm os or I need to
> create it by myself?

The A:\sysprep.inf is automatically generated when the Admin uses the "Run Once" menu based on templates stored in /etc/ovirt-engine/sysprep/ based on the operating system version selected.

> If it created in time of sealing vm os(I do sealing from administrative
> manual) and I create new vm pool from template with sealing os, I see the
> same thing, when I start vm from pool by myself or it was started because
> prerestarted option(also tried create new vm not pool, from sealed template,
> the same thing), it welcome screen, where I need to save basic
> settings(language, timezone, user name...) and I don't see any floppy disk
> in my os.
> If I need to create answer file by myself(sysprep.inf) after sealing os, how
> can I do it?

If you need to edit the sysprep template(s), see the sysprep directory mentioned above. Not sure if this fully answers the question so I won't clear the needinfo.
Comment 20 Artyom 2013-10-04 02:48:12 EDT
When I run vm that created from sealed template via run once mode, I don't see any sysprep.inf for attach floppy option, so how I understand it attach via some other way(maybe payload), and prerestarted vm and vm that ran manually via run once mode, show me the same welcome screens and options to choose.
So if it enough to verify bug?
Comment 21 Travis Michette 2013-10-04 11:21:29 EDT
Artyom -

Unfortunately that isn't enough to verify the bug or demonstrate functionality. The point of the sysprep.inf file is so it can sysprep the machine and automatically join the domain and set needed settigns with "no user intervention". To properly test this, I would imagine you would need a domain controller that allows the RHEV sysprep files to work with the specified versions of Windows and that your would need to have the RHEV environment integrated with an Windows AD domain and not just IPA. In an enterprise environment, you shouldn't need to go through an initial Windows setup with Welcome screens as the machine should login automatically and join as part of the domain. 

The way the files in /etc/ovirt-engine/sysprep/ work is based on the selections you have for OS to tell which "sysprep" file to select, and then use the credentials and domain information as variables. The sysprep will use a Domain Admin account to allow the machine to register as a member of the AD domain, and it also passes the VM image name as the hostname to the VM and AD to register that computer as the RHEV VM image name as a member of the domain.

If you are getting the welcome screen ... either the sysprep file isn't being used or you aren't actually testing in an environment where a machine can sysprep and join a Windows domain.

-- Travis
Comment 22 Artyom 2013-10-08 01:54:31 EDT
Hi Travis thanks for explanation, but it first time that I encounter with sysprep.inf in RHEVM, so if you have some useful links that's describes whole process of using sysprep.inf in RHEVM or some manual I will glad to receive it.
Thanks
Comment 23 Artyom 2013-10-08 08:52:57 EDT
Verified on is 17.
1) Added ldap server and added user from server to rhevm
2) Created vm with windows 7(operating system windows 7 64-bit) on domain of ldap server
3) Vm sealed and created template from vm
4) Created vms pool with 5 vms from template
5) Set number of prerestarted vms to two
6) Wait until os is up on prerestarted vm
7) No welcome screen, see login screen in ldap domain
8) Entered to OS with user and password from that added to rhevm from ldap domain
9) Also floppy disk with sysprep.inf exist
Comment 24 Travis Michette 2013-10-10 10:44:07 EDT
Artyom -

I imagine the process is the same as from Comment #23 as long as the "LDAP" server is a Windows Domain Controller using Active Directory (AD).

The process we use is exactly the same as the steps described, but with some exceptions:

We are using manage-domains and have RHEVM joined to Windows 2K8 AD domain.

I performed slight modifications to the sysprep.w7x64 to not only allow it to join the domain, but also to place it in a specific AD OU so it gets the correct GPOs and configurations for VDI ... the Win7 Optimized performance tuned settings.

        <component name="Microsoft-Windows-UnattendedJoin" processorArchitecture                                                                                                                                                                                  ="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonS                                                                                                                                                                                  xS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="htt                                                                                                                                                                                  p://www.w3.org/2001/XMLSchema-instance">
            <Identification>
                <Credentials>
                    <Domain>$JoinDomain$</Domain>
                    <Password>$DomainAdminPassword$</Password>
                    <Username>$DomainAdmin$</Username>
                </Credentials>
                <JoinDomain>$JoinDomain$</JoinDomain>
                <MachineObjectOU>OU=VDI,OU=GroupLevel,OU=64BIT,OU=WORKSTATIONS,DC=DomainName,DC=DomainExt</MachineObjectOU>
            </Identification>
        </component>


The <MachineObjectOU> is what I added to the file. The rest of the Red Hat RHEVM macros take the domain, and domain credentials from RHEVM and cause it to join the domain. The line I added, places it in AD in a Machine OU that I had specified ... essentially placing any of our stateless VDI machines in the VDI OU automatically on sysprep and by doing so it gets all my optimized policies which disables "AutoUpdate, various services Bluetooth, Fax, etc ..) as well as the customer sercurity and lockdown policies.


Thanks,

Travis
Comment 26 Artyom 2013-10-16 12:45:54 EDT
All our test cases are run in internal network, so maybe you can speak with some managers staff via email and they will give you test cases statistics or something this, I don't have such permissions in system, sorry.
Comment 27 Charlie 2013-11-27 19:10:34 EST
This bug is currently attached to errata RHEA-2013:15231. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag.

Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information:

* Cause: What actions or circumstances cause this bug to present.
* Consequence: What happens when the bug presents.
* Fix: What was done to fix the bug.
* Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore')

Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug.

For further details on the Cause, Consequence, Fix, Result format please refer to:

https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes 

Thanks in advance.
Comment 28 errata-xmlrpc 2014-01-21 12:37:04 EST
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.

http://rhn.redhat.com/errata/RHSA-2014-0038.html

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