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

Bug 1612974

Summary: [RFE] Allow setting different Cloud-init/Sysprep setting for VMs in pools
Product: Red Hat Enterprise Virtualization Manager Reporter: Frank DeLorey <fdelorey>
Component: ovirt-engineAssignee: Nobody <nobody>
Status: CLOSED WONTFIX QA Contact: meital avital <mavital>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.2.4CC: bkorren, bugs, fdelorey, lsurette, masayag, mgoldboi, michal.skrivanek, mtessun, nobody, nsimsolo, paul, rbarry, Rhev-m-bugs, rik.theys, srevivo, tburke, tjelinek
Target Milestone: ---Keywords: FutureFeature
Target Release: ---Flags: lsvaty: testing_plan_complete-
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 1298232 Environment:
Last Closed: 2019-01-03 12:49:57 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1298232    
Bug Blocks:    

Description Frank DeLorey 2018-08-06 16:16:11 UTC
+++ This bug was initially created as a clone of Bug #1298232 +++

Description of problem:
At this time every VM in a VM pool gets the exact same settings set for the pool.
For example, if a hostname is set, it it set the same way for all VMs created in the pool.

Version-Release number of selected component (if applicable):
oVirt Engine Version: 3.6.1.3-1.el7.centos


Expected results:
Allow to set some differences between settings given to VMs in a VM pool for example, allow embedding '??' in the hostname set with clount-init so it will be replaced with the VM's pool number when it is created.

--- Additional comment from Moran Goldboim on 2016-12-14 07:18:31 EST ---

didn't get to 4.1
We will look into it in the future.

--- Additional comment from  on 2017-06-20 05:54:02 EDT ---

I did encounter same issue, any updates on this?

Description:
I would like to automatically set the hostname of a VM to be the same as the ovirt machine name seen in the portal.
This can be done by creating a template and activating cloud-init in the initial run tab. 
A new VM named “test” based in this template is created and the hostname is “test”, works perfect!

But when I create a pool (i.e. “testpool”) based on this template I get machines with names “testpool-1”, “testpool-2”, etc. but the machine name is not present in the metadata and cannot be set as hostname. This is probably due to the fact that the machine names are auto generated by the oVirt Pool.

Is this expected/desired behavior for cloud-init from pools? 
If so, what would be the best way to retrieve the machine name (as seen in the portal) and manually set it to be hostname via cloud-init (i.e. runcmd – hostnamectl set-hostname $(hostname))

--- Additional comment from  on 2017-06-20 09:33:45 EDT ---

Created a workaround for making pool hostnames unique based on the last octet of ip-address from de DHCP after setting it to static. Not sure if it is safe/durable but seems to work enough for me and has at least some logic in the hostname.

initscript:
runcmd:
- ip=$(ip route get 8.8.8.8 | awk '{print $NF;exit}')
- nmcli con mod eth0 ipv4.addresses $ip"/24" ipv4.dns x.x.x.x ipv4.gateway x.x.x.x ipv4.method manual
- hostnamectl set-hostname testpool-"${ip##*.}".example.com

--- Additional comment from Rik Theys on 2017-08-11 04:11:29 EDT ---

Hi,

I'm running into the same problem.

We would like to use cloud-init to set the hostname of the VM's which are created from a pool.

There should be a way to specify variables (or ??) in the cloud-init hostname field so we can reference the VM name (or use the ?? as in the pool definition).

Regards,

Rik

Comment 1 Frank DeLorey 2018-08-06 16:17:30 UTC
Customers are requesting this before 4.3, it would be nice to have this ability in 4.2.X

Frank

Comment 3 Ryan Barry 2019-01-03 12:49:57 UTC
This will not be addressed in a reasonable timeframe. Please re-open if it's still important.