Re: [pve-devel] [RFC qemu-server] api: create disks: avoid adding secondary cloud-init drives

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

[pve-devel] [PATCH v4 manager] ui: vm network: allow to override MTU for virtio devices

we already have the 'mtu' option in the API, so we can just expose that option inside the 'Advanced' menu for virtio network interfaces. Reviewed-By: Aaron Lauterer Tested-By: Aaron Lauterer Tested-By: Dylan Whyte Signed-off-by: Oguz Bektas --- v3->v4: * show tooltip message about inheritance

Re: [pve-devel] [RFC qemu-server] api: create disks: avoid adding secondary cloud-init drives

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

Re: [pve-devel] [PATCH v4 qemu-server 1/6] cloudinit: add cloudinit section for current generated config.

Hi Fabian, sorry to be late, I was very busy last week > Series looks pretty good to me, but there are some issues, all > related > to this patch (number 4 is the big one): > > 1. assemble() in PVE/VZDump/QemuServer.pm requires changes or the > message > INFO: snapshots found (not included into b

Re: [pve-devel] [PATCH v4 qemu-server 1/6] cloudinit: add cloudinit section for current generated config.

> > old doesn't /have/ to keep working, but in this case it doesn't > > completely fail, but quietly messes up the config, which is worse > > than > > failing. > > > > > Are you sure it's a problem ? > I mean, [special:cloudinit], are the current running values in the > cloudinit drive. > > if t

[pve-devel] [PATCH v5 qemu-server 2/9] generate cloudinit drive on offline plug

Currently when only generate it at vm start Signed-off-by: Alexandre Derumier --- PVE/QemuServer.pm | 11 +++ 1 file changed, 11 insertions(+) diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm index b282cfd..ac30769 100644 --- a/PVE/QemuServer.pm +++ b/PVE/QemuServer.pm @@ -5103,6 +510

[pve-devel] [PATCH v5 qemu-server 4/9] api2: add cloudinit config api

Signed-off-by: Alexandre Derumier --- PVE/API2/Qemu.pm| 68 PVE/CLI/qm.pm | 1 + PVE/QemuServer/Cloudinit.pm | 78 + 3 files changed, 147 insertions(+) diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm

[pve-devel] [PATCH v5 qemu-server 8/9] vzdump : skip special:cloudinit section

Signed-off-by: Alexandre Derumier --- PVE/VZDump/QemuServer.pm | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/PVE/VZDump/QemuServer.pm b/PVE/VZDump/QemuServer.pm index 7429508..1d38e63 100644 --- a/PVE/VZDump/QemuServer.pm +++ b/PVE/VZDump/QemuServer.pm @@ -214,17 +214,20

[pve-devel] [PATCH v5 qemu-server 0/9] cloudinit pending behaviour change

Hi, This is an attempt to cleanup current behaviour of cloudinit online changes. Currently, we setup cloudinit options as pending, until we generate the config drive. This is not 100% true, because some option like vm name, nic mac address can be changed, without going to pending, so user can'

[pve-devel] [PATCH v5 qemu-server 7/9] api2: qemu : don't display cloudinit value

Signed-off-by: Alexandre Derumier --- PVE/API2/Qemu.pm | 1 + 1 file changed, 1 insertion(+) diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm index 1d5b66f..57a75fc 100644 --- a/PVE/API2/Qemu.pm +++ b/PVE/API2/Qemu.pm @@ -1227,6 +1227,7 @@ __PACKAGE__->register_method({ $conf = PVE::

[pve-devel] [PATCH v5 qemu-server 1/9] cloudinit: add cloudinit section for current generated config.

Instead using vm pending options for pending cloudinit generated config, write current generated cloudinit config in a new [special:cloudinit] SECTION. Currently, some options like vm name, nic mac address can be hotplugged, so they are not way to know if the cloud-init disk is already updated.

[pve-devel] [PATCH v5 qemu-server 3/9] cloudinit: make cloudnit options fastplug

Signed-off-by: Alexandre Derumier --- PVE/QemuServer.pm | 31 +-- 1 file changed, 5 insertions(+), 26 deletions(-) diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm index ac30769..93ea4cb 100644 --- a/PVE/QemuServer.pm +++ b/PVE/QemuServer.pm @@ -4832,6 +4832,10 @@ m

[pve-devel] [PATCH v5 qemu-server 6/9] add cloudinit hotplug

This allow to regenerate config drive if pending values exist when we change vm options. Signed-off-by: Alexandre Derumier --- PVE/QemuServer.pm | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm index a38ae3e..babc86f 100644

[pve-devel] [PATCH v5 qemu-server 5/9] api2: add cloudinit_update

This allow to regenerate the config drive with 1 api call. This also avoid to delete drive first, and recreate it again. As it's a readonly drive, we can simply live update it, and eject/replace it with qemu monitor Signed-off-by: Alexandre Derumier --- PVE/API2/Qemu.pm | 43 +

[pve-devel] [PATCH v5 qemu-server 9/9] migration: test targetnode min version for cloudinit section

Signed-off-by: Alexandre Derumier --- PVE/QemuMigrate.pm| 36 +++- PVE/QemuServer/Helpers.pm | 1 + 2 files changed, 36 insertions(+), 1 deletion(-) diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm index d52dc8d..29a03e9 100644 --- a/PVE/QemuMigrate.p