Bug 1262011 - Persistent cloud-init configuration not work for vms
Persistent cloud-init configuration not work for vms
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
All Linux
medium Severity high
: ovirt-4.0.0-alpha
: 4.0.0
Assigned To: Shahar Havivi
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2015-09-10 11:17 EDT by Artyom
Modified: 2016-08-23 16:29 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cloud-init/Sysprep only runs on the first run of the virtual machine. If the virual machine is already running, then any changes to Cloud-init/Sysprep will not re-initialize the virtual machine with the new Cloud-init/Sysprep settings. Only running via Run-Once and explicitly selecting Cloud-Init/Sysprep will re-initialize the virtual machine.
Story Points: ---
Clone Of:
Last Closed: 2016-08-23 16:29:22 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Artyom 2015-09-10 11:17:08 EDT
Description of problem:
Persistent cloud-init configuration not work for vms(cloud-init configuration updated via vm edit window)
Via run-once vm cloud-init configuration work.

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

How reproducible:

Steps to Reproduce:
1. Create vm and update cloud-init configuration(Edit vm -> Init Run)
2. Add some cloud-init configuration for example hostname
3. Run vm(not run once)

Actual results:
Cloud-init configuration not applied and under journalctl I can see:
[CLOUDINIT] util.py[DEBUG]: No instance datasource found! Likely bad things to come!
                                                                      Traceback (most recent call last):
                                                                        File "/usr/bin/cloud-init", line 245, in main_init
                                                                        File "/usr/lib/python2.7/site-packages/cloudinit/stages.py", line 308, in fetch
                                                                          return self._get_data_source()
                                                                        File "/usr/lib/python2.7/site-packages/cloudinit/stages.py", line 236, in _get_data
                                                                        File "/usr/lib/python2.7/site-packages/cloudinit/sources/__init__.py", line 260, in
                                                                          raise DataSourceNotFoundException(msg)
                                                                      DataSourceNotFoundException: Did not find any data source, searched classes: (DataSourceNoCloudNet, DataSourceConfigDriveNet)

Expected results:
cloud-init configuration applied and not any tracebacks from cloud-init in journalctl

Additional info:
Looks like we not send additional cdrom when we start vm not via run once
run.xml - regular run of vm
run_once.xml - run-once of vm

# diff run.xml run_once.xml 
< <domain type='kvm' id='14'>
> <domain type='kvm' id='12'>
>     <disk type='file' device='cdrom'>
>       <driver name='qemu' type='raw'/>
>       <source file='/var/run/vdsm/payload/7b0c71ef-0995-41c5-bd1a-de71cad3fa17.3b3cfb556e13866867eb2f9d940ba884.img' startupPolicy='optional'/>
>       <backingStore/>
>       <target dev='sdb' bus='scsi'/>
>       <readonly/>
>       <serial></serial>
>       <alias name='scsi0-0-0-1'/>
>       <address type='drive' controller='0' bus='0' target='0' unit='1'/>
>     </disk>
>       <boot order='2'/>
<     <graphics type='vnc' port='5900' autoport='yes' listen='0' passwdValidTo='1970-01-01T00:00:01'>
>     <graphics type='vnc' port='5900' autoport='yes' listen='0' passwdValidTo='2015-09-10T14:28:19'>
Comment 1 Omer Frenkel 2015-09-13 05:55:22 EDT
please attach engine and vdsm logs
does this happen also on the first run of the vm?
(i mean, try to create new vm, set the cloud-init data, and run (normal) - in this case, is cloud init missing?)

cloud init is sent automatically only for not-initialized vm, which is on the first run of the vm,
if user want to use it again, he must use run once (this is the same behaviour as for sysprep)
Comment 2 Artyom 2015-09-16 11:40:34 EDT
I checked it on first run and it worked fine:
1) Create vm_for_template with cloud-init package
2) Create template from vm_for_template
3) Create new vm from template with some persistent cloud-init configuration
4) Start vm

All cloud-init configuration appear under guest OS.

So I believe you can close this bug, but if you do not know correct behavior, it a little confusing, because by my opinion, if you have open options to edit, you will expect that it will be applied under guest OS, maybe better just hide cloud-init configuration from vm edit options(or at least give some warning), if vm already was initialized.
Comment 3 Omer Frenkel 2015-09-17 04:02:22 EDT
not sure any warning is needed, this works just like sysprep, for admin that is familiar with cloud init it should be clear that it runs automatically only on the first run, and in order to run it again you need to explicitly ask for it in run once (again just like sysprep).

i dont like hiding stuff from the user as well,
for example, user may want to update the cloud init config in the vm before creating a template..

i think we should fix the documentation [1] because it is saying that 
"...New Virtual Machine, Edit Virtual Machine and Edit Template windows to provide these instructions every time the virtual machine starts. "

Comment 5 Artyom 2016-05-25 04:11:48 EDT
Verified on 4.0.0-0.0.master.20160516171427.git0860aa2.el7.centos
Comment 7 errata-xmlrpc 2016-08-23 16:29:22 EDT
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.


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