Bug 1267504 - When creating Windows 7 VM from template pool, VMs in the pool do not receive unique hostnames
When creating Windows 7 VM from template pool, VMs in the pool do not receive...
Status: CLOSED DUPLICATE of bug 1269970
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
All Windows
high Severity high
: ---
: ---
Assigned To: nobody nobody
Depends On:
  Show dependency treegraph
Reported: 2015-09-30 04:21 EDT by Greg Scott
Modified: 2016-01-11 11:08 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-10-08 12:20:58 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 1269970 None None None Never

  None (edit)
Description Greg Scott 2015-09-30 04:21:24 EDT
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):

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.
Comment 1 Greg Scott 2015-09-30 04:37:56 EDT
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.
Comment 2 Greg Scott 2015-10-07 23:07:31 EDT
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


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.
Comment 3 Greg Scott 2015-10-08 12:17:56 EDT
The KB article in comment 2 is now published.  This BZ can close.  I filed a new BZ against the documentation at:

Comment 4 Greg Scott 2015-10-08 12:20:58 EDT

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

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