Bug 1262011
| Summary: | Persistent cloud-init configuration not work for vms | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Artyom <alukiano> |
| Component: | ovirt-engine | Assignee: | Shahar Havivi <shavivi> |
| Status: | CLOSED ERRATA | QA Contact: | Artyom <alukiano> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.6.0 | CC: | alukiano, bgraveno, erinn.looneytriggs, gklein, lsurette, mavital, michal.skrivanek, rbalakri, Rhev-m-bugs, srevivo, ykaul |
| Target Milestone: | ovirt-4.0.0-alpha | Keywords: | Triaged |
| Target Release: | 4.0.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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: | Environment: | ||
| Last Closed: | 2016-08-23 20:29:22 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: | |||
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) 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. 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. " [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html/Administration_Guide/sect-Sealing_Virtual_Machines_in_Preparation_for_Deployment_as_Templates.html#sect-Using_Cloud-Init_to_Automate_the_Configuration_of_Virtual_Machines Verified on 4.0.0-0.0.master.20160516171427.git0860aa2.el7.centos 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. https://rhn.redhat.com/errata/RHEA-2016-1743.html |
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): rhevm-3.6.0-0.13.master.el6.noarch How reproducible: Always 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 init.fetch() 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 pkg_list) 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 1c1 < <domain type='kvm' id='14'> --- > <domain type='kvm' id='12'> 37a38,47 > <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> 73a84 > <boot order='2'/> 98c109 < <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'>