Bug 1006659

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?

closing in 3.3 as fixed

should be tested...

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?

(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?

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.

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?

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

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?

(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.

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?

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

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

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

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

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.

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.

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

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days