* [pve-devel] [RFC qemu-server] api: create disks: avoid adding secondary cloud-init drives
@ 2022-05-06 10:11 Fabian Ebner
2022-05-16 8:32 ` DERUMIER, Alexandre
` (3 more replies)
0 siblings, 4 replies; 7+ messages in thread
From: Fabian Ebner @ 2022-05-06 10:11 UTC (permalink / raw)
To: pve-devel
This will break possibly existing workflows like
1. add second cloud-init
2. remove first cloud-init
to change the cloud-init storage.
On the other hand, it avoids unintended misconfiguration of having
mutliple cloud-init drives with potentially different settings.
Also in preparation for adding cloud-init-related API calls, where
not being able to assume that there's only one cloud-init drive/state
would complicate things quite a bit.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
---
Are there any scenarios where having multiple cloud-init drives is
useful?
PVE/API2/Qemu.pm | 19 +++++++++++++++++++
PVE/QemuConfig.pm | 15 +++++++++++++++
2 files changed, 34 insertions(+)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index a8246574..74f0181c 100644
--- a/PVE/API2/Qemu.pm
+++ b/PVE/API2/Qemu.pm
@@ -328,6 +328,15 @@ my $create_disks = sub {
} elsif (defined($volname) && $volname eq 'cloudinit') {
$storeid = $storeid // $default_storage;
die "no storage ID specified (and no default storage)\n" if !$storeid;
+
+ if (
+ my $ci_key = PVE::QemuConfig->has_cloudinit($conf, $ds)
+ || PVE::QemuConfig->has_cloudinit($conf->{pending} || {}, $ds)
+ || PVE::QemuConfig->has_cloudinit($res, $ds)
+ ) {
+ die "$ds - cloud-init drive is already attached at '$ci_key'\n";
+ }
+
my $scfg = PVE::Storage::storage_config($storecfg, $storeid);
my $name = "vm-$vmid-cloudinit";
@@ -424,6 +433,16 @@ my $create_disks = sub {
my ($vtype) = PVE::Storage::parse_volname($storecfg, $volid);
die "cannot use volume $volid - content type needs to be 'images' or 'iso'"
if $vtype ne 'images' && $vtype ne 'iso';
+
+ if (PVE::QemuServer::Drive::drive_is_cloudinit($disk)) {
+ if (
+ my $ci_key = PVE::QemuConfig->has_cloudinit($conf, $ds)
+ || PVE::QemuConfig->has_cloudinit($conf->{pending} || {}, $ds)
+ || PVE::QemuConfig->has_cloudinit($res, $ds)
+ ) {
+ die "$ds - cloud-init drive is already attached at '$ci_key'\n";
+ }
+ }
}
PVE::Storage::activate_volumes($storecfg, [ $volid ]) if $storeid;
diff --git a/PVE/QemuConfig.pm b/PVE/QemuConfig.pm
index cfef8d37..f7557613 100644
--- a/PVE/QemuConfig.pm
+++ b/PVE/QemuConfig.pm
@@ -518,4 +518,19 @@ sub __snapshot_rollback_get_unused {
# END implemented abstract methods from PVE::AbstractConfig
+sub has_cloudinit {
+ my ($class, $conf, $skip) = @_;
+
+ my $found;
+
+ $class->foreach_volume($conf, sub {
+ my ($key, $volume) = @_;
+
+ return if ($skip && $skip eq $key) || $found;
+ $found = $key if PVE::QemuServer::Drive::drive_is_cloudinit($volume);
+ });
+
+ return $found;
+}
+
1;
--
2.30.2
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [pve-devel] [RFC qemu-server] api: create disks: avoid adding secondary cloud-init drives
2022-05-06 10:11 [pve-devel] [RFC qemu-server] api: create disks: avoid adding secondary cloud-init drives Fabian Ebner
@ 2022-05-16 8:32 ` DERUMIER, Alexandre
2022-07-04 8:54 ` Mira Limbeck
2022-05-16 11:04 ` DERUMIER, Alexandre
` (2 subsequent siblings)
3 siblings, 1 reply; 7+ messages in thread
From: DERUMIER, Alexandre @ 2022-05-16 8:32 UTC (permalink / raw)
To: pve-devel
> ---
>
> Are there any scenarios where having multiple cloud-init drives is
> useful?
I don't remember exactly how cloud-init daemon is mounting drives,
but I'm pretty sure that with multiple cloud-init drives,
only 1 will be mounted and read.
So,I'm 100% ok with limiting cloud-init to only 1 drive.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [pve-devel] [RFC qemu-server] api: create disks: avoid adding secondary cloud-init drives
2022-05-16 8:32 ` DERUMIER, Alexandre
@ 2022-07-04 8:54 ` Mira Limbeck
0 siblings, 0 replies; 7+ messages in thread
From: Mira Limbeck @ 2022-07-04 8:54 UTC (permalink / raw)
To: pve-devel
On 5/16/22 10:32, DERUMIER, Alexandre wrote:
>> ---
>>
>> Are there any scenarios where having multiple cloud-init drives is
>> useful?
> I don't remember exactly how cloud-init daemon is mounting drives,
> but I'm pretty sure that with multiple cloud-init drives,
> only 1 will be mounted and read.
>
> So,I'm 100% ok with limiting cloud-init to only 1 drive.
>
Yes, only one will be mounted.
We had a support case with exactly that issue, one cloud-init disk
attached to the VM, and host CD-Rom passthrough with another one.
This lead to strange behavior because the wrong one was used by cloud-init.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [pve-devel] [RFC qemu-server] api: create disks: avoid adding secondary cloud-init drives
2022-05-06 10:11 [pve-devel] [RFC qemu-server] api: create disks: avoid adding secondary cloud-init drives Fabian Ebner
2022-05-16 8:32 ` DERUMIER, Alexandre
@ 2022-05-16 11:04 ` DERUMIER, Alexandre
2022-07-04 8:57 ` Mira Limbeck
2022-07-04 7:44 ` Fabian Ebner
2022-09-12 16:06 ` [pve-devel] applied: " Thomas Lamprecht
3 siblings, 1 reply; 7+ messages in thread
From: DERUMIER, Alexandre @ 2022-05-16 11:04 UTC (permalink / raw)
To: pve-devel
Le vendredi 06 mai 2022 à 12:11 +0200, Fabian Ebner a écrit :
> This will break possibly existing workflows like
> 1. add second cloud-init
> 2. remove first cloud-init
> to change the cloud-init storage.
Also, currently, in the gui, we can't add 2 cloud-init drives
currently.
But we could add an "move disk" like feature.
generate current cloudinit config on a new drive and swap isos online.
(If iso is mounted in the guest os, it's not a problem, as it's
readonly, and the mountpoint content is updated too)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [pve-devel] [RFC qemu-server] api: create disks: avoid adding secondary cloud-init drives
2022-05-16 11:04 ` DERUMIER, Alexandre
@ 2022-07-04 8:57 ` Mira Limbeck
0 siblings, 0 replies; 7+ messages in thread
From: Mira Limbeck @ 2022-07-04 8:57 UTC (permalink / raw)
To: pve-devel
On 5/16/22 13:04, DERUMIER, Alexandre wrote:
> Le vendredi 06 mai 2022 à 12:11 +0200, Fabian Ebner a écrit :
>> This will break possibly existing workflows like
>> 1. add second cloud-init
>> 2. remove first cloud-init
>> to change the cloud-init storage.
> Also, currently, in the gui, we can't add 2 cloud-init drives
> currently.
>
> But we could add an "move disk" like feature.
> generate current cloudinit config on a new drive and swap isos online.
> (If iso is mounted in the guest os, it's not a problem, as it's
> readonly, and the mountpoint content is updated too)
>
`Move Disk` while the VM is running, should not recreate the disk from
config as this could lead to a changed cloud-init disk.
Offline should be fine, but online `Move Disk` must re-use the current
cloud-init disk.
We had the same issue in the live migration case. We now offline migrate
the cloud-init disk and pass an argument during start on the target node
to skip generating the cloud-init disk as a workaround.
Live migration the same way all other disks are migrated doesn't work
here because the cloud-init disk is readonly mounted in QEMU.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [pve-devel] [RFC qemu-server] api: create disks: avoid adding secondary cloud-init drives
2022-05-06 10:11 [pve-devel] [RFC qemu-server] api: create disks: avoid adding secondary cloud-init drives Fabian Ebner
2022-05-16 8:32 ` DERUMIER, Alexandre
2022-05-16 11:04 ` DERUMIER, Alexandre
@ 2022-07-04 7:44 ` Fabian Ebner
2022-09-12 16:06 ` [pve-devel] applied: " Thomas Lamprecht
3 siblings, 0 replies; 7+ messages in thread
From: Fabian Ebner @ 2022-07-04 7:44 UTC (permalink / raw)
To: pve-devel
Am 06.05.22 um 12:11 schrieb Fabian Ebner:
> This will break possibly existing workflows like
> 1. add second cloud-init
> 2. remove first cloud-init
> to change the cloud-init storage.
>
> On the other hand, it avoids unintended misconfiguration of having
> mutliple cloud-init drives with potentially different settings.
>
> Also in preparation for adding cloud-init-related API calls, where
> not being able to assume that there's only one cloud-init drive/state
> would complicate things quite a bit.
>
> Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Ping
^ permalink raw reply [flat|nested] 7+ messages in thread
* [pve-devel] applied: [RFC qemu-server] api: create disks: avoid adding secondary cloud-init drives
2022-05-06 10:11 [pve-devel] [RFC qemu-server] api: create disks: avoid adding secondary cloud-init drives Fabian Ebner
` (2 preceding siblings ...)
2022-07-04 7:44 ` Fabian Ebner
@ 2022-09-12 16:06 ` Thomas Lamprecht
3 siblings, 0 replies; 7+ messages in thread
From: Thomas Lamprecht @ 2022-09-12 16:06 UTC (permalink / raw)
To: Proxmox VE development discussion, Fabian Ebner
Am 06/05/2022 um 12:11 schrieb Fabian Ebner:
> This will break possibly existing workflows like
> 1. add second cloud-init
> 2. remove first cloud-init
> to change the cloud-init storage.
>
> On the other hand, it avoids unintended misconfiguration of having
> mutliple cloud-init drives with potentially different settings.
>
> Also in preparation for adding cloud-init-related API calls, where
> not being able to assume that there's only one cloud-init drive/state
> would complicate things quite a bit.
>
> Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
> ---
>
> Are there any scenarios where having multiple cloud-init drives is
> useful?
>
> PVE/API2/Qemu.pm | 19 +++++++++++++++++++
> PVE/QemuConfig.pm | 15 +++++++++++++++
> 2 files changed, 34 insertions(+)
>
>
applied, thanks!
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-09-12 16:06 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-06 10:11 [pve-devel] [RFC qemu-server] api: create disks: avoid adding secondary cloud-init drives Fabian Ebner
2022-05-16 8:32 ` DERUMIER, Alexandre
2022-07-04 8:54 ` Mira Limbeck
2022-05-16 11:04 ` DERUMIER, Alexandre
2022-07-04 8:57 ` Mira Limbeck
2022-07-04 7:44 ` Fabian Ebner
2022-09-12 16:06 ` [pve-devel] applied: " Thomas Lamprecht
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox