[ovirt-users] Cloud-init reset network configuration to default dhcp after reboot and regular run

[Mike Lykov]

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/***@ovirt.org/thread/NE27UO4WNZIC27GZY4D2DCFX4DIYFBQP/

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 Lykov]

Post by 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



_______________________________________________
Users mailing list -- ***@ovirt.org
To unsubscribe send an email to users-***@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/***@ovirt.org/message/JACYAEF

[Mike Lykov]

Post by 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 ?

[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.

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

Post by Mike Lykov

Post by 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 ?

----------
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
_______________________________________________
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/

_______________________________________________
Users mailing list -- ***@ovirt.org
To unsubscribe send an email to users-***@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/***@ovirt.org/message/YKHFUAVY7D2DOS2TA2B6FILC

[Mike Lykov]

Post by 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?

Post by Eitan Raviv
* 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].
* 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

Post by Mike Lykov

Post by 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 ?

----------
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
_______________________________________________
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/

_______________________________________________
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/

_______________________________________________
Users mailing list -- ***@ovirt.org
To unsubscribe send an email to users-***@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@

[Eitan Raviv]

Post by Mike Lykov

Post by 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)

Post by Mike Lykov
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...

Post by Mike Lykov

Post by Eitan Raviv
* 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].
* 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

Post by Mike Lykov

Post by 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 ?

----------
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
_______________________________________________
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/

_______________________________________________
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/

_______________________________________________
Users mailing list -- ***@ovirt.org
To unsubscribe send an email to users-***@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/***@ovirt.org/message/DZE7VFQFOUFU6MWN6P

[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:

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

Post by Eitan Raviv

Post by Mike Lykov

Post by 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)

Post by Mike Lykov
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...

Post by Mike Lykov

Post by Eitan Raviv
* disabling cloud-init altogether [1] with: touch

/etc/cloud/cloud-init.disabled

Post by Mike Lykov

Post by Eitan Raviv
* 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
* 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

Post by Mike Lykov

Post by Eitan Raviv
[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

Post by Mike Lykov

Post by 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. "

Post by Mike Lykov

Post by Eitan Raviv

Post by Mike Lykov

Post by Mike Lykov
- are it not working in ovirt/this cloud-init version ?

----------
2018-11-21 12:40:53,314 - main.py[DEBUG]: Checking to see if files

that

Post by Mike Lykov

Post by Eitan Raviv

Post by Mike Lykov
we need already exist from a previous run that would allow us to stop

early.

Post by Mike Lykov

Post by Eitan Raviv

Post by Mike Lykov
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
_______________________________________________
Privacy Statement: https://www.ovirt.org/site/privacy-policy/

https://www.ovirt.org/community/about/community-guidelines/

Post by Mike Lykov

Post by Eitan Raviv
_______________________________________________
Privacy Statement: https://www.ovirt.org/site/privacy-policy/

https://www.ovirt.org/community/about/community-guidelines/

[Mike Lykov]

Post by Eitan Raviv
After further investigation I would like to share one more important
piece of information that explains the "reset" behaviour of the network

Thanks for that detailed clarification.

Post by Eitan Raviv
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.

Post by Eitan Raviv
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 ?

Post by Eitan Raviv
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

Post by Eitan Raviv

Post by Mike Lykov

Post by Eitan Raviv
According to cloud-init 0.7.9 documentation cloud-init is

configured

Post by Mike Lykov

Post by Eitan Raviv
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

Post by Mike Lykov

Post by Eitan Raviv
on eth0 [2].
As you noted, if you run a VM once, and then in the next

regular run

Post by Mike Lykov

Post by Eitan Raviv
the cloud-init flag is not selected in the VM configuration in

engine,

Post by Mike Lykov

Post by Eitan Raviv
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

Post by Mike Lykov
are supposed to?
My setup is not in cloud, it's local and use static IP adresses

for VM.

Post by Mike Lykov
I do not want to configure each VM network in console by hand.
I create VM from template (template have installed cloud-init

package),

Post by Mike Lykov
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)

Post by Mike Lykov
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...

Post by Mike Lykov

Post by Eitan Raviv
* disabling cloud-init altogether [1] with: touch

/etc/cloud/cloud-init.disabled

Post by Mike Lykov

Post by Eitan Raviv
* 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

Post by Mike Lykov

Post by Eitan Raviv
the last stage of its operation [3].
There is possibly a third 'hack' that would not require any
* 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

Post by Mike Lykov

Post by Eitan Raviv
[2]

https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#local

Post by Mike Lykov

Post by Eitan Raviv
[3]

https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#final

Post by Mike Lykov

Post by Eitan Raviv

Post by Mike Lykov

Post by Mike Lykov
"cloud-init used to use a "marker" file that it created on

initial

Post by Mike Lykov

Post by Eitan Raviv

Post by Mike Lykov

Post by Mike Lykov
execution. If that "marker" file existed it would not rerun

on reboot. "

Post by Mike Lykov

Post by Eitan Raviv

Post by Mike Lykov

Post by Mike Lykov
- are it not working  in ovirt/this cloud-init version ?

----------
2018-11-21 12:40:53,314 - main.py[DEBUG]: Checking to see if

files that

Post by Mike Lykov

Post by Eitan Raviv

Post by Mike Lykov
we need already exist from a previous run that would allow us

to stop early.

Post by Mike Lykov

Post by Eitan Raviv

Post by Mike Lykov
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
_______________________________________________
Privacy Statement: https://www.ovirt.org/site/privacy-policy/

https://www.ovirt.org/community/about/community-guidelines/

Post by Mike Lykov

Post by Eitan Raviv
_______________________________________________
Privacy Statement: https://www.ovirt.org/site/privacy-policy/

https://www.ovirt.org/community/about/community-guidelines/
_______________________________________________
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/

_______________________________________________
Users mailing list -- ***@ovirt.org
To unsubscribe send an email to users-***@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/***@ovirt.org/message/UXIU527YFPFD7MAWEMNO4V72DYOH

[Eitan Raviv]

We will consider changing the behaviour. This is indeed not intuitive.

Post by Mike Lykov

Post by Eitan Raviv
After further investigation I would like to share one more important
piece of information that explains the "reset" behaviour of the network

Thanks for that detailed clarification.

Post by Eitan Raviv
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.

Post by Eitan Raviv
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'.

- 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) ?
- 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 ?

Post by Eitan Raviv
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

Post by Eitan Raviv

Post by Mike Lykov

Post by Eitan Raviv
According to cloud-init 0.7.9 documentation cloud-init is

configured

Post by Mike Lykov

Post by Eitan Raviv
to run by default on each boot [1] and to render the

user-selected

Post by Eitan Raviv

Post by Mike Lykov

Post by Eitan Raviv
network configuration on first boot [2]. Also, in absence of a

data

Post by Eitan Raviv

Post by Mike Lykov

Post by Eitan Raviv
source to configure the network, it will fall back to

configuring DHCP

Post by Mike Lykov

Post by Eitan Raviv
on eth0 [2].
As you noted, if you run a VM once, and then in the next

regular run

Post by Mike Lykov

Post by Eitan Raviv
the cloud-init flag is not selected in the VM configuration in

engine,

Post by Mike Lykov

Post by Eitan Raviv
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

Post by Mike Lykov
are supposed to?
My setup is not in cloud, it's local and use static IP adresses

for VM.

Post by Mike Lykov
I do not want to configure each VM network in console by hand.
I create VM from template (template have installed cloud-init

package),

Post by Mike Lykov
configure cloud-init hostname/eth0 network in engine, and as

"custom

Post by Eitan Raviv

Post by Mike Lykov
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

Post by Eitan Raviv
(e.g. search for 'runcmd' in
https://cloudinit.readthedocs.io/en/0.7.9/topics/examples.html)

Post by Mike Lykov
Then I "Run once" a VM, stop it, and run as usual without data

source

Post by Eitan Raviv

Post by Mike Lykov
and fallback.
Or I name network interface not "eth0" and therefore without need

for

Post by Eitan Raviv

Post by Mike Lykov
custom script?

I did not test the outcome of assigning the static IP to another NIC.
Just sharing a thought...

Post by Mike Lykov

Post by Eitan Raviv
* disabling cloud-init altogether [1] with: touch

/etc/cloud/cloud-init.disabled

echo

Post by Eitan Raviv

Post by Mike Lykov

Post by Eitan Raviv
‘network: {config: disabled}‘ >> /etc/cloud/cloud.cfg
whichever scenario is used to run a VM, this can be

accomplished by

Post by Eitan Raviv

Post by Mike Lykov

Post by Eitan Raviv
adding the above commands to the custom_script that cloud-init

runs at

Post by Mike Lykov

Post by Eitan Raviv
the last stage of its operation [3].
There is possibly a third 'hack' that would not require any
* 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

Post by Mike Lykov

Post by Eitan Raviv
[2]

https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#local

Post by Mike Lykov

Post by Eitan Raviv
[3]

https://cloudinit.readthedocs.io/en/0.7.9/topics/boot.html#final

Post by Mike Lykov

Post by Eitan Raviv

Post by Mike Lykov

Post by Mike Lykov
"cloud-init used to use a "marker" file that it created on

initial

Post by Mike Lykov

Post by Eitan Raviv

Post by Mike Lykov

Post by Mike Lykov
execution. If that "marker" file existed it would not rerun

on reboot. "

Post by Mike Lykov

Post by Eitan Raviv

Post by Mike Lykov

Post by Mike Lykov
- are it not working in ovirt/this cloud-init version ?

----------
2018-11-21 12:40:53,314 - main.py[DEBUG]: Checking to see if

files that

Post by Mike Lykov

Post by Eitan Raviv

Post by Mike Lykov
we need already exist from a previous run that would allow us

to stop early.

Post by Mike Lykov

Post by Eitan Raviv

Post by Mike Lykov
2018-11-21 12:40:53,315 - main.py[DEBUG]: Execution

continuing, no

Post by Eitan Raviv

Post by Mike Lykov

Post by Eitan Raviv

Post by Mike Lykov
previous run detected that would allow us to stop early.
-------------
which files it try to find ?
--
Mike
_______________________________________________
Privacy Statement: https://www.ovirt.org/site/privacy-policy/

https://www.ovirt.org/community/about/community-guidelines/

Post by Mike Lykov

Post by Eitan Raviv
_______________________________________________
Privacy Statement: https://www.ovirt.org/site/privacy-policy/

https://www.ovirt.org/community/about/community-guidelines/
_______________________________________________
Privacy Statement: https://www.ovirt.org/site/privacy-policy/

https://www.ovirt.org/community/about/community-guidelines/
_______________________________________________
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
https://www.ovirt.org/community/about/community-guidelines/