Re: [pve-devel] RFC: qemu-server : add cloudinit support
For one, it seems to be started on several points during the init process. There seem to be 5 different systemd units specified for it even. yes, I'm seeing this 4 units. I'm think they are related to different cloud-init stage (init,config,final , see /etc/cloud/cloud.cfg). cloud-config.service loaded active exitedLSB: Cloud init modules --mode config cloud-final.service loaded active exitedLSB: Cloud init modules final jobs cloud-init-local.service loaded active exitedLSB: Cloud init local cloud-init.service loaded active exitedLSB: Cloud init If I remember, init stage is done only at first boot. cloud_init_modules: - migrator - bootcmd - write-files - resizefs - set_hostname - update_hostname - update_etc_hosts - ca-certs - rsyslog - users-groups - ssh I'm not sure about other stage. Then there seems to be a system-wide configuration in /etc/cloud that defines not just datasources but also default configurations, like a default user, and whether root may login with a password, etc. users,keys,password are not defined in /etc/cloud/cloud.cfg but in configdrive They are some system default thing, like admin account for debian for example (but no password) but the main thing is the the datasource provider (I'm using configdrive like openstack|ovirt) other things are list of modules we can call from configdrive At this point I'm wondering whether this configuration will be re-applied on every boot. (The documentation doesn't mention any of this actually, I found this part on the ArchWiki[1]...) And does that mean cloud-init keeps overwriting the systems's regular configuration files? If you don't provide the configdrive (no datasource), it'll do nothing. That's why I remove the configdrive after first init. The documentation only mentions a directory structure in /var. [2] Now I'm left to wonder... does the cloud init process somehow overwride/interfere with the regular initialization process? Does it actually perform physical merging of configuration files from the datasource into /var? (The documentation also mentions merging[3]) I don't see nothing special in /var/lib/cloud, no config cache or something like that Finally: OS support. It seems to only ship with support linux (few specific distros even) and freebsd [4]. For that purpose it seems a little overengineered. linux distro : centos,rhel,fedora,debian,ubuntu,suse,archlinux,gentoo bsd: freebsd windows http://thornelabs.net/2014/06/01/where-to-find-openstack-cloud-images.html don't seem too bad ? - Mail original - De: Wolfgang Bumiller w.bumil...@proxmox.com À: aderumier aderum...@odiso.com Cc: dietmar diet...@proxmox.com, pve-devel pve-devel@pve.proxmox.com Envoyé: Jeudi 11 Juin 2015 10:24:38 Objet: Re: [pve-devel] RFC: qemu-server : add cloudinit support There are a few things that still confuse me about cloud-init, and the documentation lacks a description of the very basic mode of operation of cloud-init. (When does which part start and where does it do what exactly. The source isn't easy to navigate either without more documentation... (it's a big load of python)) For one, it seems to be started on several points during the init process. There seem to be 5 different systemd units specified for it even. Then there seems to be a system-wide configuration in /etc/cloud that defines not just datasources but also default configurations, like a default user, and whether root may login with a password, etc. At this point I'm wondering whether this configuration will be re-applied on every boot. (The documentation doesn't mention any of this actually, I found this part on the ArchWiki[1]...) The documentation only mentions a directory structure in /var. [2] Now I'm left to wonder... does the cloud init process somehow overwride/interfere with the regular initialization process? Does it actually perform physical merging of configuration files from the datasource into /var? (The documentation also mentions merging[3]) And does that mean cloud-init keeps overwriting the systems's regular configuration files? To me the entire thing still seems a bit cloudy. (no pun intended...) Finally: OS support. It seems to only ship with support linux (few specific distros even) and freebsd [4]. For that purpose it seems a little overengineered. [1] https://wiki.archlinux.org/index.php/Cloud-init [2] https://cloudinit.readthedocs.org/en/latest/topics/dir_layout.html [3] https://cloudinit.readthedocs.org/en/latest/topics/merging.html [4] https://cloudinit.readthedocs.org/en/latest/topics/availability.html On Thu, Jun 11, 2015 at 08:11:45AM +0200, Alexandre DERUMIER wrote:
Re: [pve-devel] RFC: qemu-server : add cloudinit support
On Thu, Jun 11, 2015 at 12:51:42PM +0200, Alexandre DERUMIER wrote: For one, it seems to be started on several points during the init process. There seem to be 5 different systemd units specified for it even. yes, I'm seeing this 4 units. I'm think they are related to different cloud-init stage (init,config,final, see /etc/cloud/cloud.cfg). Yes, it's just not immediately clear when each of them happen and what they're _exactly_ doing. If I remember, init stage is done only at first boot. cloud_init_modules: - migrator - bootcmd - write-files - resizefs - set_hostname - update_hostname - update_etc_hosts - ca-certs - rsyslog - users-groups - ssh This part is configured in /etc apparently. So there the list of enabled hooks is configured AFAIU. I'm not sure about other stage. Yeah, I really wish there was a detailed design document somewhere ;-) Then there seems to be a system-wide configuration in /etc/cloud that defines not just datasources but also default configurations, like a default user, and whether root may login with a password, etc. users,keys,password are not defined in /etc/cloud/cloud.cfg but in configdrive They are some system default thing, like admin account for debian for example (but no password) They _can_ be, but I haven't figured out if/how/when they're added if you actually do it in there. At least my test user never came to live on my arch test vm. but the main thing is the the datasource provider (I'm using configdrive like openstack|ovirt) other things are list of modules we can call from configdrive Yes, that much is clear to me by now. At this point I'm wondering whether this configuration will be re-applied on every boot. (The documentation doesn't mention any of this actually, I found this part on the ArchWiki[1]...) And does that mean cloud-init keeps overwriting the systems's regular configuration files? If you don't provide the configdrive (no datasource), it'll do nothing. That's why I remove the configdrive after first init. It doing nothing is what I'm afraid of. I've tested an ubuntu installation just now, and after removing the config drive the cloud-init init-process just sat there, not letting me boot all the way through to the login screen. IOW the entire boot process was hanging around doing nothing. This isn't really ideal. OTOH it may be desirable to keep the config datasource attached. That way the WEB UI's configuration is the permanent one, and changes made in the running VM to /etc/ (eg. /etc/network/interfaces) are only temporary. Otherwise the options in the UI would have to be deleted/greyed out with it to reflect the new situation, while if the config is kept around there'd be some permanently-available settings in the UI. And with the init process hanging dead in my tests (for around 10 minutes, and afterwards errors appear like using sudo shows unable to resolve host somename.localdomain, which tells me cloud-init decided to screw something up...) it means that the only safe way to remove the datasource is to also have it uninstall the cloud-init package on the OS - unless the packaged cloud-init is smarter. (I tried an ubuntu-server 14.10 image) The documentation only mentions a directory structure in /var. [2] Now I'm left to wonder... does the cloud init process somehow overwride/interfere with the regular initialization process? Does it actually perform physical merging of configuration files from the datasource into /var? (The documentation also mentions merging[3]) I don't see nothing special in /var/lib/cloud, no config cache or something like that Yes, this section of the documentation still seems somewhat weird to me. Finally: OS support. It seems to only ship with support linux (few specific distros even) and freebsd [4]. For that purpose it seems a little overengineered. linux distro : centos,rhel,fedora,debian,ubuntu,suse,archlinux,gentoo bsd: freebsd windows http://thornelabs.net/2014/06/01/where-to-find-openstack-cloud-images.html don't seem too bad ? According to this cloud-init doesn't actually run on windows directly, but there's a port named cloudbased-init. It supports a config-disk too, but I doubt it uses the same layout and syntax everywhere. (After all, network interfaces for instance aren't exactly called 'eth0' and 'eth1' on windows ;-) ) ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] RFC: qemu-server : add cloudinit support
I'll try to test with ubuntu to see. I find this about ubuntu prebuild cloud images http://askubuntu.com/questions/461942/fresh-install-ubuntu-14-04-server-slow-boot-due-to-failure-to-connect-169-254-16 You must be running the cloud version of Ubuntu server. cloud-init is attempting to contact 169.254.169.254, a link-local IP address that cloud providers listen on to provide metadata about the VM being initialized I known that openstack support as datasource same protocol than amazon, and also configdrive. Don't know how the 169.254.169.254 trick is working ? - Mail original - De: aderumier aderum...@odiso.com À: Wolfgang Bumiller w.bumil...@proxmox.com Cc: pve-devel pve-devel@pve.proxmox.com Envoyé: Jeudi 11 Juin 2015 15:25:33 Objet: Re: [pve-devel] RFC: qemu-server : add cloudinit support It doing nothing is what I'm afraid of. I've tested an ubuntu installation just now, and after removing the config drive the cloud-init init-process just sat there, not letting me boot all the way through to the login screen. IOW the entire boot process was hanging around doing nothing. This isn't really ideal. I'll try to test with ubuntu to see. OTOH it may be desirable to keep the config datasource attached. That way the WEB UI's configuration is the permanent one, and changes made in the running VM to /etc/ (eg. /etc/network/interfaces) are only temporary. Otherwise the options in the UI would have to be deleted/greyed out with it to reflect the new situation, while if the config is kept around there'd be some permanently-available settings in the UI. I think that Cloud-init should be only use to setup the vm create|provisioning as I said in a previous mail, I think we should simply pass parameters to qm clone -ipddress -gateway -nameserver ... This is what ovirt|rhev are doing currently. http://www.ovirt.org/Features/Cloud-Init_Integration If we would like to manage ips in gui, we could generate a new configdrive, but we can't tell to guest to reforce relaunch of cloud-init. (or maybe with a udev rules trick ?) And with the init process hanging dead in my tests (for around 10 minutes, and afterwards errors appear like using sudo shows unable to resolve host somename.localdomain, which tells me cloud-init decided to screw something up...) it means that the only safe way to remove the datasource is to also have it uninstall the cloud-init package on the OS - unless the packaged cloud-init is smarter. (I tried an ubuntu-server 14.10 image) Maybe the datasource is not configdrive ? They are other datasources for amazon for exemple, which try to connect to amazon to get the config. they are details logs in /var/log/cloudinit/ According to this cloud-init doesn't actually run on windows directly, but there's a port named cloudbased-init. It supports a config-disk too, but I doubt it uses the same layout and syntax everywhere. (After all, network interfaces for instance aren't exactly called 'eth0' and 'eth1' on windows ;-) ) Well, the network config in configdrive is at debian format. But each cloud-init implementation on different guest os, is parsing it and write correct config. So it should work. (I have tested it with fedora, and it's writen in redhat /sysconfig/ format) - Mail original - De: Wolfgang Bumiller w.bumil...@proxmox.com À: aderumier aderum...@odiso.com Cc: dietmar diet...@proxmox.com, pve-devel pve-devel@pve.proxmox.com Envoyé: Jeudi 11 Juin 2015 13:41:32 Objet: Re: [pve-devel] RFC: qemu-server : add cloudinit support On Thu, Jun 11, 2015 at 12:51:42PM +0200, Alexandre DERUMIER wrote: For one, it seems to be started on several points during the init process. There seem to be 5 different systemd units specified for it even. yes, I'm seeing this 4 units. I'm think they are related to different cloud-init stage (init,config,final, see /etc/cloud/cloud.cfg). Yes, it's just not immediately clear when each of them happen and what they're _exactly_ doing. If I remember, init stage is done only at first boot. cloud_init_modules: - migrator - bootcmd - write-files - resizefs - set_hostname - update_hostname - update_etc_hosts - ca-certs - rsyslog - users-groups - ssh This part is configured in /etc apparently. So there the list of enabled hooks is configured AFAIU. I'm not sure about other stage. Yeah, I really wish there was a detailed design document somewhere ;-) Then there seems to be a system-wide configuration in /etc/cloud that defines not just datasources but also default configurations, like a default user, and whether root may login with a password, etc. users,keys,password are not defined in /etc/cloud/cloud.cfg but in configdrive They are some system default thing, like admin account for debian for example (but no password) They _can_ be, but I haven't figured out if/how/when they're added if you actually do it in there. At
Re: [pve-devel] RFC: qemu-server : add cloudinit support
OTOH it may be desirable to keep the config datasource attached. That way the WEB UI's configuration is the permanent one, and changes made in the running VM to /etc/ (eg. /etc/network/interfaces) are only temporary. Otherwise the options in the UI would have to be deleted/greyed out with it to reflect the new situation, while if the config is kept around there'd be some permanently-available settings in the UI. I think that Cloud-init should be only use to setup the vm create|provisioning as I said in a previous mail, I think we should simply pass parameters to qm clone -ipddress -gateway -nameserver ... This is what ovirt|rhev are doing currently. http://www.ovirt.org/Features/Cloud-Init_Integration I am not sure why you want to add such restriction? IMHO, this would make the whole think quite useless. For example, if we have IPs on host side, we can also have better firewall rules by default... If we would like to manage ips in gui, we could generate a new configdrive, but we can't tell to guest to reforce relaunch of cloud-init. (or maybe with a udev rules trick ?) This configuration is simple cold-plug. It is a perfect fit, because we have that 'pending' API now ;-) So you simply need to stop/start to apply new values? ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] RFC: qemu-server : add cloudinit support
It is a perfect fit, because we have that 'pending' API now ;-) Oh, I forgot about this.. ;) So you simply need to stop/start to apply new values? I need to check that, but I think yes. - Mail original - De: dietmar diet...@proxmox.com À: Wolfgang Bumiller w.bumil...@proxmox.com, aderumier aderum...@odiso.com Cc: pve-devel pve-devel@pve.proxmox.com Envoyé: Jeudi 11 Juin 2015 18:00:49 Objet: Re: [pve-devel] RFC: qemu-server : add cloudinit support OTOH it may be desirable to keep the config datasource attached. That way the WEB UI's configuration is the permanent one, and changes made in the running VM to /etc/ (eg. /etc/network/interfaces) are only temporary. Otherwise the options in the UI would have to be deleted/greyed out with it to reflect the new situation, while if the config is kept around there'd be some permanently-available settings in the UI. I think that Cloud-init should be only use to setup the vm create|provisioning as I said in a previous mail, I think we should simply pass parameters to qm clone -ipddress -gateway -nameserver ... This is what ovirt|rhev are doing currently. http://www.ovirt.org/Features/Cloud-Init_Integration I am not sure why you want to add such restriction? IMHO, this would make the whole think quite useless. For example, if we have IPs on host side, we can also have better firewall rules by default... If we would like to manage ips in gui, we could generate a new configdrive, but we can't tell to guest to reforce relaunch of cloud-init. (or maybe with a udev rules trick ?) This configuration is simple cold-plug. It is a perfect fit, because we have that 'pending' API now ;-) So you simply need to stop/start to apply new values? ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] RFC: qemu-server : add cloudinit support
So you simply need to stop/start to apply new values? I need to check that, but I think yes. The config is reapply only if the uuid of the configdrive is changed (they are a uuid symlink with old cloud-init config in /var/lib/cloud/instance) My code is wrong, because I take the smbios1 uuid. The config uuid is just a random uuid. Ah, OK - I already wondered why they use the smbios1 uuid ;-) I'll send new patchs tomorrow. Thanks. ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH 1/4] code cleanup and man
Signed-off-by: Wolfgang Link w.l...@proxmox.com
---
pve-zsync | 54 +-
1 file changed, 29 insertions(+), 25 deletions(-)
diff --git a/pve-zsync b/pve-zsync
index 3c134ce..cd2a228 100644
--- a/pve-zsync
+++ b/pve-zsync
@@ -362,7 +362,7 @@ sub format_job {
my ($job, $line) = @_;
my $text = ;
-if ($job-{state} eq stoped) {
+if ($job-{state} eq stopped) {
$text = #;
}
if ($line) {
@@ -508,7 +508,7 @@ sub sync {
my ($source, $dest, $job, $param, $date) = @_;
($source-{old_snap},$source-{last_snap}) = snapshot_get($source,
$dest, $param-{maxsnap}, $param-{name});
- print Dumper $source, $dest;
+
eval{
snapshot_add($source, $dest, $param-{name}, $date);
@@ -888,7 +888,7 @@ sub disable_job {
my ($param) = @_;
my $job = get_job($param);
-$job-{state} = stoped;
+$job-{state} = stopped;
update_state($job);
update_cron($job);
}
@@ -1122,65 +1122,65 @@ pve-zsync help cmd [OPTIONS]
pve-zsync create -dest string -source string [OPTIONS]
- Create a sync Job
+Create a sync Job
- -dest string
+-dest string
the destination target is like [IP]:Pool[/Path]
- -limit integer
+-limit integer
max sync speed in kBytes/s, default unlimited
- -maxsnap string
+-maxsnap string
how much snapshots will be kept before get erased, default 1
- -name string
+-name string
name of the sync job, if not set it is default
- -skip boolean
+-skip boolean
if this flag is set it will skip the first sync
- -sourcestring
+-sourcestring
the source can be an VMID or [IP:]ZFSPool[/Path]
pve-zsync destroy -source string [OPTIONS]
- remove a sync Job from the scheduler
+remove a sync Job from the scheduler
- -name string
+-name string
name of the sync job, if not set it is default
- -sourcestring
+-sourcestring
the source can be an VMID or [IP:]ZFSPool[/Path]
pve-zsync disable -source string [OPTIONS]
- pause a sync job
+pause a sync job
- -name string
+-name string
name of the sync job, if not set it is default
- -sourcestring
+-sourcestring
the source can be an VMID or [IP:]ZFSPool[/Path]
pve-zsync enable -source string [OPTIONS]
- enable a syncjob and reset error
+enable a syncjob and reset error
- -name string
+-name string
name of the sync job, if not set it is default
- -sourcestring
+-sourcestring
the source can be an VMID or [IP:]ZFSPool[/Path]
pve-zsync list
@@ -1203,16 +1203,16 @@ pve-zsync sync -dest string -source string [OPTIONS]
max sync speed in kBytes/s, default unlimited
- -maxsnap integer
+-maxsnap integer
how much snapshots will be kept before get erased, default 1
- -name string
+-name string
name of the sync job, if not set it is default.
It is only necessary if scheduler allready contains this source.
- -sourcestring
+-sourcestring
the source can be an VMID or [IP:]ZFSPool[/Path]
@@ -1233,10 +1233,14 @@ add sync job from local VM to remote ZFS Server
pve-zsync create -source=100 -dest=192.168.1.2:zfspool
=head1 IMPORTANT FILES
+
+Cron jobs are stored at /etc/cron.d/pve-zsync
+
+The VM config get copied on the destination machine to /var/pve-zsync/
+
+The config is stored at /var/pve-zsync/
-Where the cron jobs are stored/etc/cron.d/pve-zsync
-Where the VM config get copied on the destination machine /var/pve-zsync/
-Where the config is stored/var/pve-zsync/
+=head1 COPYRIGHT AND DISCLAIMER
Copyright (C) 2007-2015 Proxmox Server Solutions GmbH
--
2.1.4
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH 4/4] fix incremental sync
wrong snapshot where be used.
Signed-off-by: Wolfgang Link w.l...@proxmox.com
---
pve-zsync | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pve-zsync b/pve-zsync
index b458826..2575527 100644
--- a/pve-zsync
+++ b/pve-zsync
@@ -797,7 +797,7 @@ sub send_image {
$cmd .= -v if $param-{verbose};
if($source-{last_snap} snapshot_exist($source ,$dest,
$param-{method})) {
- $cmd .= -i $source-{all}\@$source-{old_snap}
$source-{all}\@$source-{new_snap} ;
+ $cmd .= -i $source-{all}\@$source-{last_snap}
$source-{all}\@$source-{new_snap} ;
} else {
$cmd .= $source-{all}\@$source-{new_snap} ;
}
--
2.1.4
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] pve-zsync
This are some fixes for the pve-sync tool ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH 2/4] Add dependencies
Signed-off-by: Wolfgang Link w.l...@proxmox.com --- control.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/control.in b/control.in index e56ab8b..12bd95e 100644 --- a/control.in +++ b/control.in @@ -3,7 +3,7 @@ Version: @@VERSION@@-@@PKGRELEASE@@ Section: perl Priority: optional Architecture: @@ARCH@@ -Depends: perl (= 5.6.0-16) +Depends: perl (= 5.6.0-16), cstream, libcatmandu-importer-getjson-perl Maintainer: Proxmox Support Team supp...@proxmox.com Description: Proxmox VE storage management library This package contains the Proxmox VE ZFS sync Tool. -- 2.1.4 ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] RFC: qemu-server : add cloudinit support
It doing nothing is what I'm afraid of. I've tested an ubuntu installation just now, and after removing the config drive the cloud-init init-process just sat there, not letting me boot all the way through to the login screen. IOW the entire boot process was hanging around doing nothing. This isn't really ideal. I'll try to test with ubuntu to see. OTOH it may be desirable to keep the config datasource attached. That way the WEB UI's configuration is the permanent one, and changes made in the running VM to /etc/ (eg. /etc/network/interfaces) are only temporary. Otherwise the options in the UI would have to be deleted/greyed out with it to reflect the new situation, while if the config is kept around there'd be some permanently-available settings in the UI. I think that Cloud-init should be only use to setup the vm create|provisioning as I said in a previous mail, I think we should simply pass parameters to qm clone -ipddress -gateway -nameserver ... This is what ovirt|rhev are doing currently. http://www.ovirt.org/Features/Cloud-Init_Integration If we would like to manage ips in gui, we could generate a new configdrive, but we can't tell to guest to reforce relaunch of cloud-init. (or maybe with a udev rules trick ?) And with the init process hanging dead in my tests (for around 10 minutes, and afterwards errors appear like using sudo shows unable to resolve host somename.localdomain, which tells me cloud-init decided to screw something up...) it means that the only safe way to remove the datasource is to also have it uninstall the cloud-init package on the OS - unless the packaged cloud-init is smarter. (I tried an ubuntu-server 14.10 image) Maybe the datasource is not configdrive ? They are other datasources for amazon for exemple, which try to connect to amazon to get the config. they are details logs in /var/log/cloudinit/ According to this cloud-init doesn't actually run on windows directly, but there's a port named cloudbased-init. It supports a config-disk too, but I doubt it uses the same layout and syntax everywhere. (After all, network interfaces for instance aren't exactly called 'eth0' and 'eth1' on windows ;-) ) Well, the network config in configdrive is at debian format. But each cloud-init implementation on different guest os, is parsing it and write correct config. So it should work. (I have tested it with fedora, and it's writen in redhat /sysconfig/ format) - Mail original - De: Wolfgang Bumiller w.bumil...@proxmox.com À: aderumier aderum...@odiso.com Cc: dietmar diet...@proxmox.com, pve-devel pve-devel@pve.proxmox.com Envoyé: Jeudi 11 Juin 2015 13:41:32 Objet: Re: [pve-devel] RFC: qemu-server : add cloudinit support On Thu, Jun 11, 2015 at 12:51:42PM +0200, Alexandre DERUMIER wrote: For one, it seems to be started on several points during the init process. There seem to be 5 different systemd units specified for it even. yes, I'm seeing this 4 units. I'm think they are related to different cloud-init stage (init,config,final, see /etc/cloud/cloud.cfg). Yes, it's just not immediately clear when each of them happen and what they're _exactly_ doing. If I remember, init stage is done only at first boot. cloud_init_modules: - migrator - bootcmd - write-files - resizefs - set_hostname - update_hostname - update_etc_hosts - ca-certs - rsyslog - users-groups - ssh This part is configured in /etc apparently. So there the list of enabled hooks is configured AFAIU. I'm not sure about other stage. Yeah, I really wish there was a detailed design document somewhere ;-) Then there seems to be a system-wide configuration in /etc/cloud that defines not just datasources but also default configurations, like a default user, and whether root may login with a password, etc. users,keys,password are not defined in /etc/cloud/cloud.cfg but in configdrive They are some system default thing, like admin account for debian for example (but no password) They _can_ be, but I haven't figured out if/how/when they're added if you actually do it in there. At least my test user never came to live on my arch test vm. but the main thing is the the datasource provider (I'm using configdrive like openstack|ovirt) other things are list of modules we can call from configdrive Yes, that much is clear to me by now. At this point I'm wondering whether this configuration will be re-applied on every boot. (The documentation doesn't mention any of this actually, I found this part on the ArchWiki[1]...) And does that mean cloud-init keeps overwriting the systems's regular configuration files? If you don't provide the configdrive (no datasource), it'll do nothing. That's why I remove the configdrive after first init. It doing nothing is what I'm afraid of. I've tested an ubuntu installation just now, and after removing the config drive the cloud-init init-process just
Re: [pve-devel] RFC: qemu-server : add cloudinit support
There are a few things that still confuse me about cloud-init, and the documentation lacks a description of the very basic mode of operation of cloud-init. (When does which part start and where does it do what exactly. The source isn't easy to navigate either without more documentation... (it's a big load of python)) For one, it seems to be started on several points during the init process. There seem to be 5 different systemd units specified for it even. Then there seems to be a system-wide configuration in /etc/cloud that defines not just datasources but also default configurations, like a default user, and whether root may login with a password, etc. At this point I'm wondering whether this configuration will be re-applied on every boot. (The documentation doesn't mention any of this actually, I found this part on the ArchWiki[1]...) The documentation only mentions a directory structure in /var. [2] Now I'm left to wonder... does the cloud init process somehow overwride/interfere with the regular initialization process? Does it actually perform physical merging of configuration files from the datasource into /var? (The documentation also mentions merging[3]) And does that mean cloud-init keeps overwriting the systems's regular configuration files? To me the entire thing still seems a bit cloudy. (no pun intended...) Finally: OS support. It seems to only ship with support linux (few specific distros even) and freebsd [4]. For that purpose it seems a little overengineered. [1] https://wiki.archlinux.org/index.php/Cloud-init [2] https://cloudinit.readthedocs.org/en/latest/topics/dir_layout.html [3] https://cloudinit.readthedocs.org/en/latest/topics/merging.html [4] https://cloudinit.readthedocs.org/en/latest/topics/availability.html On Thu, Jun 11, 2015 at 08:11:45AM +0200, Alexandre DERUMIER wrote: Also, cloud-init feature is only usefull when creating a new vm, so cloning a clean template with cloud-init support. Maybe we could simply pass options to qm clone -nameserver -searchdoman -eth0 ipaddress gateway start the vm after cloning, and cloud-init shutdown it when finished. (We could also add some kind of import template like for container, they are a lot of cloud-init templates available on the net) - Mail original - De: aderumier aderum...@odiso.com À: dietmar diet...@proxmox.com Cc: pve-devel pve-devel@pve.proxmox.com Envoyé: Jeudi 11 Juin 2015 07:54:06 Objet: Re: [pve-devel] RFC: qemu-server : add cloudinit support And is that reboot necessary? Its a bit clumsy, because the boot-loader is presented 2 times to the user. I forgot to say that I shutdown the vm (with cloudinit) at the end of the setup, not reboot. That's why I setup in pending removal ide3. - Mail original - De: aderumier aderum...@odiso.com À: dietmar diet...@proxmox.com Cc: pve-devel pve-devel@pve.proxmox.com Envoyé: Jeudi 11 Juin 2015 07:17:33 Objet: Re: [pve-devel] RFC: qemu-server : add cloudinit support And is that reboot necessary? Its a bit clumsy, because the boot-loader is presented 2 times to the user. No, but I just want to clean remove the cdrom config. I setup it as ide3. (in case if use have already a cdrom is default ide2). It could be possible to eject cd from guest in cloudinit config, but currently we can't catch qemu events. - Mail original - De: dietmar diet...@proxmox.com À: aderumier aderum...@odiso.com Cc: pve-devel pve-devel@pve.proxmox.com Envoyé: Jeudi 11 Juin 2015 07:13:53 Objet: Re: [pve-devel] RFC: qemu-server : add cloudinit support How long does such configuration cycle run (start/cloudinit/stop)? It's fast, maybe 15s after grub for basic network config. But for example if you want to upgrade packages at first boot or launch puppet/chef, it can take a lot more. And is that reboot necessary? Its a bit clumsy, because the boot-loader is presented 2 times to the user. ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
