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

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(a)redhat.com > <mailto:eraviv@redhat.com>> wrote: > > On Wed, Nov 28, 2018 at 7:29 AM Mike Lykov <combr(a)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(a)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(a)ovirt.org <mailto:users@ovirt.org> > > >> To unsubscribe send an email to users-leave(a)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/ACNLTDH55L4... > > > _______________________________________________ > > > Users mailing list -- users(a)ovirt.org <mailto:users@ovirt.org> > > > To unsubscribe send an email to users-leave(a)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/YKHFUAVY7D2... > > > > > > > > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)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/ORAWKILE2YB... > _______________________________________________ Users mailing list -- users(a)ovirt.org To unsubscribe send an email to users-leave(a)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/UXIU527YFPF...