Cloud-init reset network configuration to default dhcp after reboot and regular run
Hi All! I'm trying to configure network in VMs created from template, and see strange behaviour from cloud-init. cloud-init installed and enabled in template. ver cloud-init-0.7.9-24.el7.centos.1.x86_64 guest Centos 7.5 ovirt 4.2.7 from ovirt-releases-42-pre repo 1. I use "run once" with initial run - use cloud-init - networks in-guest net iface : eth0 add new - static enter address, mask, gw ipv6 none Run (once) and cloud-init configure ifcfg-eth0 for that address (successfully). 2. I shutdown that VM and use "Run" (regular) without "use cloud init" in VM properties, awaiting that above configurations are saved (and booted with it). But because "use cloud init" not checked, and cloud-init service enabled, it start, cannot find datasource and drop configuration to default (dhcp). In cloud-init.log 2018-11-20 13:53:24,153 - util.py[WARNING]: No instance datasource found! Likely bad things to come! 2018-11-20 13:53:24,153 - util.py[DEBUG]: No instance datasource found! Likely bad things to come! Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/cloudinit/cmd/main.py", line 236, in main_init init.fetch(existing=existing) File "/usr/lib/python2.7/site-packages/cloudinit/stages.py", line 343, in fetch return self._get_data_source(existing=existing) File "/usr/lib/python2.7/site-packages/cloudinit/stages.py", line 253, in _get_data_source pkg_list, self.reporter) File "/usr/lib/python2.7/site-packages/cloudinit/sources/__init__.py", line 320, in find_source raise DataSourceNotFoundException(msg) DataSourceNotFoundException: Did not find any data source, searched classes: (DataSourceNoCloudNet) 2018-11-20 13:53:24,194 - stages.py[DEBUG]: applying net config names for {'version': 1, 'config': [{'subnets': [{'type': 'dhcp'}], 'type': 'physical', 'name': 'eth0', 'mac_address': '56:6f:21:4a:00:04'}]} It reverts config as in here https://lists.ovirt.org/archives/list/users@ovirt.org/thread/NE27UO4WNZIC27G... 3. then I found bug https://bugzilla.redhat.com/show_bug.cgi?id=1439373#c5 and when "run once" I disable network config as in that comment. Shutdown, Run (not once) and voila! Ip address are static! 2018-11-20 15:07:31,601 - handlers.py[DEBUG]: finish: init-network/search-NoCloudNet: SUCCESS: no network data found from DataSource NoCloudNet ..... 2018-11-20 15:07:31,602 - util.py[WARNING]: No instance datasource found! Likely bad things to come! 2018-11-20 15:07:31,602 - util.py[DEBUG]: No instance datasource found! Likely bad things to come! 2018-11-20 15:07:31,639 - stages.py[DEBUG]: network config disabled by system_cfg 2018-11-20 15:07:31,639 - stages.py[INFO]: network config is disabled by system_cfg 2018-11-20 15:07:31,639 - main.py[DEBUG]: [net] Exiting without datasource in local mode 2018-11-20 15:07:31,640 - util.py[DEBUG]: Reading from /proc/uptime (quiet=False) 2018-11-20 15:07:31,640 - util.py[DEBUG]: Read 12 bytes from /proc/uptime 2018-11-20 15:07:31,640 - util.py[DEBUG]: cloud-init mode 'init' took 0.287 seconds (0.29) 2018-11-20 15:07:31,640 - handlers.py[DEBUG]: finish: init-network: SUCCESS: searching for network datasources "cloud-init used to use a "marker" file that it created on initial execution. If that "marker" file existed it would not rerun on reboot. " - are it not working in ovirt/this cloud-init version ? -- Mike
20.11.2018 15:30, Mike Lykov пишет:
DataSourceNotFoundException: Did not find any data source, searched classes: (DataSourceNoCloudNet) 2018-11-20 13:53:24,194 - stages.py[DEBUG]: applying net config names for {'version': 1, 'config': [{'subnets': [{'type': 'dhcp'}], 'type': 'physical', 'name': 'eth0', 'mac_address': '56:6f:21:4a:00:04'}]}
full message (when cloud-init drop static ip configured previusly to default dhcp) 2018-11-20 14:35:00,334 - stages.py[DEBUG]: applying net config names for {'version': 1, 'config': [{'subnets': [{'type': 'dhcp'}], 'type': 'physical', 'name': 'eth0', 'mac_address': '56:6f:21:4a:00:05'}]} 2018-11-20 14:35:00,334 - util.py[DEBUG]: Reading from /sys/class/net/lo/addr_assign_type (quiet=False) 2018-11-20 14:35:00,334 - util.py[DEBUG]: Read 2 bytes from /sys/class/net/lo/addr_assign_type 2018-11-20 14:35:00,334 - util.py[DEBUG]: Reading from /sys/class/net/lo/address (quiet=False) 2018-11-20 14:35:00,334 - util.py[DEBUG]: Read 18 bytes from /sys/class/net/lo/address 2018-11-20 14:35:00,334 - util.py[DEBUG]: Reading from /sys/class/net/eth0/addr_assign_type (quiet=False) 2018-11-20 14:35:00,334 - util.py[DEBUG]: Read 2 bytes from /sys/class/net/eth0/addr_assign_type 2018-11-20 14:35:00,334 - util.py[DEBUG]: Reading from /sys/class/net/eth0/address (quiet=False) 2018-11-20 14:35:00,335 - util.py[DEBUG]: Read 18 bytes from /sys/class/net/eth0/address 2018-11-20 14:35:00,335 - util.py[DEBUG]: Reading from /sys/class/net/lo/operstate (quiet=False) 2018-11-20 14:35:00,335 - util.py[DEBUG]: Read 8 bytes from /sys/class/net/lo/operstate 2018-11-20 14:35:00,335 - util.py[DEBUG]: Reading from /sys/class/net/eth0/operstate (quiet=False) 2018-11-20 14:35:00,335 - util.py[DEBUG]: Read 3 bytes from /sys/class/net/eth0/operstate 2018-11-20 14:35:00,335 - util.py[DEBUG]: Running command ['ip', '-6', 'addr', 'show', 'permanent', 'scope', 'global'] with allowed return codes [0] (shell=False, capture=True) 2018-11-20 14:35:00,338 - util.py[DEBUG]: Running command ['ip', '-4', 'addr', 'show'] with allowed return codes [0] (shell=False, capture=True) 2018-11-20 14:35:00,340 - __init__.py[DEBUG]: no work necessary for renaming of [['56:6f:21:4a:00:05', 'eth0']] 2018-11-20 14:35:00,341 - stages.py[INFO]: Applying network configuration from fallback bringup=True: {'version': 1, 'config': [{'subnets': [{'type': 'dhcp'}], 'type': 'physical', 'name': 'eth0', 'mac_addre ss': '56:6f:21:4a:00:05'}]} 2018-11-20 14:35:00,343 - util.py[DEBUG]: Writing to /etc/sysconfig/network-scripts/ifcfg-eth0 - wb: [420] 159 bytes last action rewrites config ... -- Mike
20.11.2018 15:30, Mike Lykov пишет:
"cloud-init used to use a "marker" file that it created on initial execution. If that "marker" file existed it would not rerun on reboot. " - are it not working in ovirt/this cloud-init version ?
new restart: ---------- 2018-11-21 12:40:53,314 - main.py[DEBUG]: Checking to see if files that we need already exist from a previous run that would allow us to stop early. 2018-11-21 12:40:53,315 - main.py[DEBUG]: Execution continuing, no previous run detected that would allow us to stop early. ------------- which files it try to find ? -- Mike
According to cloud-init 0.7.9 documentation cloud-init is configured to run by default on each boot [1] and to render the user-selected network configuration on first boot [2]. Also, in absence of a data source to configure the network, it will fall back to configuring DHCP on eth0 [2]. As you noted, if you run a VM once, and then in the next regular run the cloud-init flag is not selected in the VM configuration in engine, there is no data-source and cloud-init falls back to dhcp as documented. The 'marker' file you refer to are also documented as follows: * disabling cloud-init altogether [1] with: touch /etc/cloud/cloud-init.disabled * preventing cloud-init from configuring the network [2] with: echo ‘network: {config: disabled}‘ >> /etc/cloud/cloud.cfg whichever scenario is used to run a VM, this can be accomplished by adding the above commands to the custom_script that cloud-init runs at the last stage of its operation [3]. There is possibly a third 'hack' that would not require any marker file: * assign your static IP to a NIC not named 'eth0' I have not tested it myself but it looks like a corollary of [2] HTH [1] https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#generator [2] https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#local [3] https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#final On Wed, Nov 21, 2018 at 10:51 AM Mike Lykov <combr@ya.ru> wrote:
20.11.2018 15:30, Mike Lykov пишет:
"cloud-init used to use a "marker" file that it created on initial execution. If that "marker" file existed it would not rerun on reboot. " - are it not working in ovirt/this cloud-init version ?
new restart:
---------- 2018-11-21 12:40:53,314 - main.py[DEBUG]: Checking to see if files that we need already exist from a previous run that would allow us to stop early. 2018-11-21 12:40:53,315 - main.py[DEBUG]: Execution continuing, no previous run detected that would allow us to stop early. -------------
which files it try to find ?
-- Mike
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/ACNLTDH55L4YX5...
27.11.2018 16:15, Eitan Raviv пишет:
According to cloud-init 0.7.9 documentation cloud-init is configured to run by default on each boot [1] and to render the user-selected network configuration on first boot [2]. Also, in absence of a data source to configure the network, it will fall back to configuring DHCP on eth0 [2].
As you noted, if you run a VM once, and then in the next regular run the cloud-init flag is not selected in the VM configuration in engine, there is no data-source and cloud-init falls back to dhcp as documented.
Thanks for the explanation. What intended use of this subsystem/feature are supposed to? My setup is not in cloud, it's local and use static IP adresses for VM. I do not want to configure each VM network in console by hand. I create VM from template (template have installed cloud-init package), configure cloud-init hostname/eth0 network in engine, and as "custom script" (at the same moment) I set a "touch /etc/cloud/cloud-init.disabled" ? Then I "Run once" a VM, stop it, and run as usual without data source and fallback. Or I name network interface not "eth0" and therefore without need for custom script?
The 'marker' file you refer to are also documented as follows:
* disabling cloud-init altogether [1] with: touch /etc/cloud/cloud-init.disabled * preventing cloud-init from configuring the network [2] with: echo ‘network: {config: disabled}‘ >> /etc/cloud/cloud.cfg whichever scenario is used to run a VM, this can be accomplished by adding the above commands to the custom_script that cloud-init runs at the last stage of its operation [3].
There is possibly a third 'hack' that would not require any marker file: * assign your static IP to a NIC not named 'eth0' I have not tested it myself but it looks like a corollary of [2]
HTH
[1] https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#generator [2] https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#local [3] https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#final
On Wed, Nov 21, 2018 at 10:51 AM Mike Lykov <combr@ya.ru> wrote:
20.11.2018 15:30, Mike Lykov пишет:
"cloud-init used to use a "marker" file that it created on initial execution. If that "marker" file existed it would not rerun on reboot. " - are it not working in ovirt/this cloud-init version ?
new restart:
---------- 2018-11-21 12:40:53,314 - main.py[DEBUG]: Checking to see if files that we need already exist from a previous run that would allow us to stop early. 2018-11-21 12:40:53,315 - main.py[DEBUG]: Execution continuing, no previous run detected that would allow us to stop early. -------------
which files it try to find ?
-- Mike
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/ACNLTDH55L4YX5...
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/YKHFUAVY7D2DOS...
On Wed, Nov 28, 2018 at 7:29 AM Mike Lykov <combr@ya.ru> wrote:
27.11.2018 16:15, Eitan Raviv пишет:
According to cloud-init 0.7.9 documentation cloud-init is configured to run by default on each boot [1] and to render the user-selected network configuration on first boot [2]. Also, in absence of a data source to configure the network, it will fall back to configuring DHCP on eth0 [2].
As you noted, if you run a VM once, and then in the next regular run the cloud-init flag is not selected in the VM configuration in engine, there is no data-source and cloud-init falls back to dhcp as documented.
Thanks for the explanation. What intended use of this subsystem/feature are supposed to?
My setup is not in cloud, it's local and use static IP adresses for VM. I do not want to configure each VM network in console by hand. I create VM from template (template have installed cloud-init package), configure cloud-init hostname/eth0 network in engine, and as "custom script" (at the same moment) I set a "touch /etc/cloud/cloud-init.disabled" ?
Either that or add custom script to disable just cloud-init network re-config as you did manually. Please consult the documentation for the custom script syntax and format (e.g. search for 'runcmd' in https://cloudinit.readthedocs.io/en/0.7.9/topics/examples.html)
Then I "Run once" a VM, stop it, and run as usual without data source and fallback. Or I name network interface not "eth0" and therefore without need for custom script?
I did not test the outcome of assigning the static IP to another NIC. Just sharing a thought...
The 'marker' file you refer to are also documented as follows:
* disabling cloud-init altogether [1] with: touch /etc/cloud/cloud-init.disabled * preventing cloud-init from configuring the network [2] with: echo ‘network: {config: disabled}‘ >> /etc/cloud/cloud.cfg whichever scenario is used to run a VM, this can be accomplished by adding the above commands to the custom_script that cloud-init runs at the last stage of its operation [3].
There is possibly a third 'hack' that would not require any marker file: * assign your static IP to a NIC not named 'eth0' I have not tested it myself but it looks like a corollary of [2]
HTH
[1] https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#generator [2] https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#local [3] https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#final
On Wed, Nov 21, 2018 at 10:51 AM Mike Lykov <combr@ya.ru> wrote:
20.11.2018 15:30, Mike Lykov пишет:
"cloud-init used to use a "marker" file that it created on initial execution. If that "marker" file existed it would not rerun on reboot. " - are it not working in ovirt/this cloud-init version ?
new restart:
---------- 2018-11-21 12:40:53,314 - main.py[DEBUG]: Checking to see if files that we need already exist from a previous run that would allow us to stop early. 2018-11-21 12:40:53,315 - main.py[DEBUG]: Execution continuing, no previous run detected that would allow us to stop early. -------------
which files it try to find ?
-- Mike
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/ACNLTDH55L4YX5...
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/YKHFUAVY7D2DOS...
After further investigation I would like to share one more important piece of information that explains the "reset" behaviour of the network configuration: When a VM is started in 'Run once' mode, the initialization parameters supplied for that run are always passed by engine to cloud-init in the guest for application. But if a VM is started in 'Run' mode, the initialization parameters are passed to cloud-init on the guest only if this is the first run (be it 'Run' or 'Run once'). On every consecutive run in 'Run' mode no parameters are passed to the guest, and therefore (as I quoted from the cloud-init documentation earlier in this thread) cloud-init falls back to DHCP configuration on the guest. This is not an overlooked occurrence on engine's behalf but rather the designated behaviour. When this behaviour was introduced into engine the reasoning was that after the initial configuration of the VM, there is no reason to resend the configuration on every 'Run' but only on 'Run once'. That's because 'Run once' may be used for out-of the ordinary instantiations of the VM. Due to the behaviour of the current cloud-init package, this causes an unexpected side effect that should be dealt with by disabling cloud-init in one of the methods I described earlier in this thread. HTH On Wed, Nov 28, 2018 at 10:12 AM Eitan Raviv <eraviv@redhat.com> wrote:
On Wed, Nov 28, 2018 at 7:29 AM Mike Lykov <combr@ya.ru> wrote:
27.11.2018 16:15, Eitan Raviv пишет:
According to cloud-init 0.7.9 documentation cloud-init is configured to run by default on each boot [1] and to render the user-selected network configuration on first boot [2]. Also, in absence of a data source to configure the network, it will fall back to configuring DHCP on eth0 [2].
As you noted, if you run a VM once, and then in the next regular run the cloud-init flag is not selected in the VM configuration in engine, there is no data-source and cloud-init falls back to dhcp as documented.
Thanks for the explanation. What intended use of this subsystem/feature are supposed to?
My setup is not in cloud, it's local and use static IP adresses for VM. I do not want to configure each VM network in console by hand. I create VM from template (template have installed cloud-init package), configure cloud-init hostname/eth0 network in engine, and as "custom script" (at the same moment) I set a "touch /etc/cloud/cloud-init.disabled" ?
Either that or add custom script to disable just cloud-init network re-config as you did manually. Please consult the documentation for the custom script syntax and format (e.g. search for 'runcmd' in https://cloudinit.readthedocs.io/en/0.7.9/topics/examples.html)
Then I "Run once" a VM, stop it, and run as usual without data source and fallback. Or I name network interface not "eth0" and therefore without need for custom script?
I did not test the outcome of assigning the static IP to another NIC. Just sharing a thought...
The 'marker' file you refer to are also documented as follows:
* disabling cloud-init altogether [1] with: touch
* preventing cloud-init from configuring the network [2] with: echo ‘network: {config: disabled}‘ >> /etc/cloud/cloud.cfg whichever scenario is used to run a VM, this can be accomplished by adding the above commands to the custom_script that cloud-init runs at the last stage of its operation [3].
There is possibly a third 'hack' that would not require any marker file: * assign your static IP to a NIC not named 'eth0' I have not tested it myself but it looks like a corollary of [2]
HTH
[1] https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#generator [2] https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#local [3] https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#final
On Wed, Nov 21, 2018 at 10:51 AM Mike Lykov <combr@ya.ru> wrote:
20.11.2018 15:30, Mike Lykov пишет:
"cloud-init used to use a "marker" file that it created on initial execution. If that "marker" file existed it would not rerun on
reboot. "
- are it not working in ovirt/this cloud-init version ?
new restart:
---------- 2018-11-21 12:40:53,314 - main.py[DEBUG]: Checking to see if files
/etc/cloud/cloud-init.disabled that
we need already exist from a previous run that would allow us to stop early. 2018-11-21 12:40:53,315 - main.py[DEBUG]: Execution continuing, no previous run detected that would allow us to stop early. -------------
which files it try to find ?
-- Mike
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/ACNLTDH55L4YX5...
Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/YKHFUAVY7D2DOS...
05.12.2018 13:04, Eitan Raviv пишет:
After further investigation I would like to share one more important piece of information that explains the "reset" behaviour of the network configuration:
Thanks for that detailed clarification.
When a VM is started in 'Run once' mode, the initialization parameters supplied for that run are always passed by engine to cloud-init in the guest for application.
It's clear and work as intended.
But if a VM is started in 'Run' mode, the initialization parameters are passed to cloud-init on the guest only if this is the first run (be it 'Run' or 'Run once'). On every consecutive run in 'Run' mode no parameters are passed to the guest, and therefore (as I quoted from the cloud-init documentation earlier in this thread) cloud-init falls back to DHCP configuration on the guest.
When this behaviour was introduced into engine the reasoning was that after the initial configuration of the VM, there is no reason to resend the configuration on every 'Run' but only on 'Run once'.
Yes, there is no reason, but for new user it looks very confusing: - create VM - configure cloud-init parameters (like IP addr) - Run VM (not once), parameters applied (all OK? as it seems) - work with/in VM - Stop VM (maybe after period of time when VM counts as 'configured successfully') for some maintetance - Run VM and try to access it (it is 'configured successfully' some time ago, isn't it?) - NO ACCESS to VM and configurаtion is LOST - try to access via console with 'WTF?' exclamation .... Why cloud-init in this scenario after successful configuration is not turn off/disable himself (by touch that file, for example) ? Instead of it cloud-init+ovirt force user to: - try to figure why configuration is lost, learn "custom script" format - write "custom script" for touch /etc/cloud/cloud-init.disabled and reboot - run once VM to apply parameters - run VM as usual ?
Due to the behaviour of the current cloud-init package, this causes an unexpected side effect that should be dealt with by disabling cloud-init in one of the methods I described earlier in this thread.
Are there use cases when cloud-init (as a service) may require to start repeatedly on consecutive usual VM runs? If will need to change parameters user may use "Run Once" start with new parameters - in this case a 'disabled' file may be ignored. But what reason to finding a configuration while usual run at all? -- BR, Mike
On Wed, Nov 28, 2018 at 10:12 AM Eitan Raviv <eraviv@redhat.com <mailto:eraviv@redhat.com>> wrote:
On Wed, Nov 28, 2018 at 7:29 AM Mike Lykov <combr@ya.ru <mailto:combr@ya.ru>> wrote: > > 27.11.2018 16:15, Eitan Raviv пишет: > > According to cloud-init 0.7.9 documentation cloud-init is configured > > to run by default on each boot [1] and to render the user-selected > > network configuration on first boot [2]. Also, in absence of a data > > source to configure the network, it will fall back to configuring DHCP > > on eth0 [2]. > > > > As you noted, if you run a VM once, and then in the next regular run > > the cloud-init flag is not selected in the VM configuration in engine, > > there is no data-source and cloud-init falls back to dhcp as > > documented. > > Thanks for the explanation. What intended use of this subsystem/feature > are supposed to? > > My setup is not in cloud, it's local and use static IP adresses for VM. > I do not want to configure each VM network in console by hand. > I create VM from template (template have installed cloud-init package), > configure cloud-init hostname/eth0 network in engine, and as "custom > script" (at the same moment) I set a "touch > /etc/cloud/cloud-init.disabled" ?
Either that or add custom script to disable just cloud-init network re-config as you did manually. Please consult the documentation for the custom script syntax and format (e.g. search for 'runcmd' in https://cloudinit.readthedocs.io/en/0.7.9/topics/examples.html)
> Then I "Run once" a VM, stop it, and run as usual without data source > and fallback. > Or I name network interface not "eth0" and therefore without need for > custom script?
I did not test the outcome of assigning the static IP to another NIC. Just sharing a thought...
> > > > The 'marker' file you refer to are also documented as follows: > > > > * disabling cloud-init altogether [1] with: touch /etc/cloud/cloud-init.disabled > > * preventing cloud-init from configuring the network [2] with: echo > > ‘network: {config: disabled}‘ >> /etc/cloud/cloud.cfg > > whichever scenario is used to run a VM, this can be accomplished by > > adding the above commands to the custom_script that cloud-init runs at > > the last stage of its operation [3]. > > > > There is possibly a third 'hack' that would not require any marker file: > > * assign your static IP to a NIC not named 'eth0' > > I have not tested it myself but it looks like a corollary of [2] > > > > HTH > > > > [1] https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#generator > > [2] https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#local > > [3] https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#final > > > > On Wed, Nov 21, 2018 at 10:51 AM Mike Lykov <combr@ya.ru <mailto:combr@ya.ru>> wrote: > >> > >> 20.11.2018 15:30, Mike Lykov пишет: > >> > >>> "cloud-init used to use a "marker" file that it created on initial > >>> execution. If that "marker" file existed it would not rerun on reboot. " > >>> - are it not working in ovirt/this cloud-init version ? > >> > >> new restart: > >> > >> ---------- > >> 2018-11-21 12:40:53,314 - main.py[DEBUG]: Checking to see if files that > >> we need already exist from a previous run that would allow us to stop early. > >> 2018-11-21 12:40:53,315 - main.py[DEBUG]: Execution continuing, no > >> previous run detected that would allow us to stop early. > >> ------------- > >> > >> which files it try to find ? > >> > >> -- > >> Mike > >> > >> _______________________________________________ > >> Users mailing list -- users@ovirt.org <mailto:users@ovirt.org> > >> To unsubscribe send an email to users-leave@ovirt.org <mailto:users-leave@ovirt.org> > >> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > >> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ > >> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/ACNLTDH55L4YX5... > > _______________________________________________ > > Users mailing list -- users@ovirt.org <mailto:users@ovirt.org> > > To unsubscribe send an email to users-leave@ovirt.org <mailto:users-leave@ovirt.org> > > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > > oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ > > List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/YKHFUAVY7D2DOS... > > >
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/ORAWKILE2YBG3V...
We will consider changing the behaviour. This is indeed not intuitive. On Thu, Dec 6, 2018 at 10:24 AM Mike Lykov <combr@ya.ru> wrote:
05.12.2018 13:04, Eitan Raviv пишет:
After further investigation I would like to share one more important piece of information that explains the "reset" behaviour of the network configuration:
Thanks for that detailed clarification.
When a VM is started in 'Run once' mode, the initialization parameters supplied for that run are always passed by engine to cloud-init in the guest for application.
It's clear and work as intended.
But if a VM is started in 'Run' mode, the initialization parameters are passed to cloud-init on the guest only if this is the first run (be it 'Run' or 'Run once'). On every consecutive run in 'Run' mode no parameters are passed to the guest, and therefore (as I quoted from the cloud-init documentation earlier in this thread) cloud-init falls back to DHCP configuration on the guest.
When this behaviour was introduced into engine the reasoning was that after the initial configuration of the VM, there is no reason to resend the configuration on every 'Run' but only on 'Run once'.
Yes, there is no reason, but for new user it looks very confusing: - create VM - configure cloud-init parameters (like IP addr) - Run VM (not once), parameters applied (all OK? as it seems) - work with/in VM - Stop VM (maybe after period of time when VM counts as 'configured successfully') for some maintetance - Run VM and try to access it (it is 'configured successfully' some time ago, isn't it?) - NO ACCESS to VM and configurаtion is LOST - try to access via console with 'WTF?' exclamation ....
Why cloud-init in this scenario after successful configuration is not turn off/disable himself (by touch that file, for example) ?
Instead of it cloud-init+ovirt force user to: - try to figure why configuration is lost, learn "custom script" format - write "custom script" for touch /etc/cloud/cloud-init.disabled and reboot - run once VM to apply parameters - run VM as usual ?
Due to the behaviour of the current cloud-init package, this causes an unexpected side effect that should be dealt with by disabling cloud-init in one of the methods I described earlier in this thread.
Are there use cases when cloud-init (as a service) may require to start repeatedly on consecutive usual VM runs? If will need to change parameters user may use "Run Once" start with new parameters - in this case a 'disabled' file may be ignored. But what reason to finding a configuration while usual run at all?
-- BR, Mike
On Wed, Nov 28, 2018 at 10:12 AM Eitan Raviv <eraviv@redhat.com <mailto:eraviv@redhat.com>> wrote:
On Wed, Nov 28, 2018 at 7:29 AM Mike Lykov <combr@ya.ru <mailto:combr@ya.ru>> wrote: > > 27.11.2018 16:15, Eitan Raviv пишет: > > According to cloud-init 0.7.9 documentation cloud-init is configured > > to run by default on each boot [1] and to render the
user-selected
> > network configuration on first boot [2]. Also, in absence of a
data
> > source to configure the network, it will fall back to configuring DHCP > > on eth0 [2]. > > > > As you noted, if you run a VM once, and then in the next regular run > > the cloud-init flag is not selected in the VM configuration in engine, > > there is no data-source and cloud-init falls back to dhcp as > > documented. > > Thanks for the explanation. What intended use of this subsystem/feature > are supposed to? > > My setup is not in cloud, it's local and use static IP adresses for VM. > I do not want to configure each VM network in console by hand. > I create VM from template (template have installed cloud-init package), > configure cloud-init hostname/eth0 network in engine, and as
"custom
> script" (at the same moment) I set a "touch > /etc/cloud/cloud-init.disabled" ?
Either that or add custom script to disable just cloud-init network re-config as you did manually. Please consult the documentation for the custom script syntax and
format
(e.g. search for 'runcmd' in https://cloudinit.readthedocs.io/en/0.7.9/topics/examples.html)
> Then I "Run once" a VM, stop it, and run as usual without data
source
> and fallback. > Or I name network interface not "eth0" and therefore without need
for
> custom script?
I did not test the outcome of assigning the static IP to another NIC. Just sharing a thought...
> > > > The 'marker' file you refer to are also documented as follows: > > > > * disabling cloud-init altogether [1] with: touch /etc/cloud/cloud-init.disabled > > * preventing cloud-init from configuring the network [2] with:
echo
> > ‘network: {config: disabled}‘ >> /etc/cloud/cloud.cfg > > whichever scenario is used to run a VM, this can be
accomplished by
> > adding the above commands to the custom_script that cloud-init runs at > > the last stage of its operation [3]. > > > > There is possibly a third 'hack' that would not require any marker file: > > * assign your static IP to a NIC not named 'eth0' > > I have not tested it myself but it looks like a corollary of [2] > > > > HTH > > > > [1] https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#generator > > [2] https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#local > > [3] https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#final > > > > On Wed, Nov 21, 2018 at 10:51 AM Mike Lykov <combr@ya.ru <mailto:combr@ya.ru>> wrote: > >> > >> 20.11.2018 15:30, Mike Lykov пишет: > >> > >>> "cloud-init used to use a "marker" file that it created on initial > >>> execution. If that "marker" file existed it would not rerun on reboot. " > >>> - are it not working in ovirt/this cloud-init version ? > >> > >> new restart: > >> > >> ---------- > >> 2018-11-21 12:40:53,314 - main.py[DEBUG]: Checking to see if files that > >> we need already exist from a previous run that would allow us to stop early. > >> 2018-11-21 12:40:53,315 - main.py[DEBUG]: Execution
continuing, no
> >> previous run detected that would allow us to stop early. > >> ------------- > >> > >> which files it try to find ? > >> > >> -- > >> Mike > >> > >> _______________________________________________ > >> Users mailing list -- users@ovirt.org <mailto:users@ovirt.org> > >> To unsubscribe send an email to users-leave@ovirt.org <mailto:users-leave@ovirt.org> > >> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > >> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ > >> List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/ACNLTDH55L4YX5...
> > _______________________________________________ > > Users mailing list -- users@ovirt.org <mailto:users@ovirt.org> > > To unsubscribe send an email to users-leave@ovirt.org <mailto:users-leave@ovirt.org> > > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > > oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ > > List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/YKHFUAVY7D2DOS...
> > >
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/ORAWKILE2YBG3V...
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/UXIU527YFPFD7M...
participants (2)
-
Eitan Raviv -
Mike Lykov