Description of problem: When creating a VM pool from a Windows template, VMs in the pool do not get a good hostname assignment. This causes problems adding these VMs to the customer Windows domain when they first boot and try to execute a:\sysprep.inf. Version-Release number of selected component (if applicable): 3.5.4 How reproducible: At will Steps to Reproduce: 1. Build a Windows 7 VM and seal it with Sysprep. 2. Build a template based on the newly built VM. 3. Create a pool with VMs based on the template from step 2. Specify Windows Domain, Organization Nam, Active Directory OU, and other attributes in the "Initial Run" section of the pool. 4. Power up a VM in the pool. Actual results: The VM does not join the specified OU. Expected results: The VM should behave as requested when setting up the pool. Additional info: I am working on reproducing the problem in my lab environment. When I run the VM from the admin portal, the VM runs Windows mini-setup on first boot no matter what I put in the "Initial Run" section of the pool. When I try different parameters under "run once" in the Admin portal, another Windows VM in the pool boots, does some automation, but never joins the specified domain. Instead, it joins a Workgroup named after the domain. I marked the severity level high because the problem is preventing Red Hat Consulting and a customer on a tight deadline from performing a RHEV upgrade.
I should have also added above that the customer reports this worked as expected with RHEV 3.5.0, but is now broken with RHEV 3.5.4.
We have an explanation for this behavior. The problem boils down to documentation. There's now a knowledge base article that addresses how this all works at https://access.redhat.com/articles/1979233 As of 10/7/2015 this KB article is not yet visible to customers but we hope to have it published in the next few days.
The KB article in comment 2 is now published. This BZ can close. I filed a new BZ against the documentation at: https://bugzilla.redhat.com/show_bug.cgi?id=1269970
*** This bug has been marked as a duplicate of bug 1269970 ***