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
Currently when only generate it at vm start
---
PVE/QemuServer.pm | 10 ++
1 file changed, 10 insertions(+)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index 9a7add5..5092b49 100644
--- a/PVE/QemuServer.pm
+++ b/PVE/QemuServer.pm
@@ -4702,6 +4702,8 @@ sub vmconfig_apply_pending {
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/QemuServer.pm | 30 +++---
1 file changed, 3 insertions(+), 27 deletions(-)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index 5092b49..900e227 100644
--- a/PVE/QemuServer.pm
+++ b/PVE/QemuServer.pm
@@ -4456,9 +4456,10 @@ sub vmconfig_hotplug_pending {
This allow to regenerate config drive if pending values exist
when we change vm options.
---
PVE/QemuServer.pm | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index 59f90c9..eaad21a 100644
--- a/PVE/QemuServer.pm
+++
---
PVE/API2/Qemu.pm| 73 +
PVE/CLI/qm.pm | 1 +
PVE/QemuServer/Cloudinit.pm | 70 +++
3 files changed, 144 insertions(+)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index ea74c69..b6122fe 100644
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
---
PVE/API2/Qemu.pm | 44
Le mercredi 31 mars 2021 à 19:32 +0200, aderum...@odiso.com a écrit :
> hi,
>
> > Why do you add the macaddress here? I couldn't find anything in
> > this
> > nor
> > in the previous patch series explaining why this is done.
>
> This is mostly to show to user that config drive need to be
>
hi,
> Why do you add the macaddress here? I couldn't find anything in this
> nor
> in the previous patch series explaining why this is done.
This is mostly to show to user that config drive need to be
regenereted.
cloud-init agent use mac address to map ip to correct interface,
so if you
this is starting to shape up nicely. as promised, I now took a stab at
(roughly!) integrating this into our regular flow (see diff below):
- IMPORT_DISK_RE now uses -1, as 0 actually can be mismatched by
NEW_DISK_RE
- the actual import happens in create_disks
- only the basic checks (match of
Pinned machine versions like "pc-i440fx-4.2+pve2.pxe" would otherwise
get a second "+pve0" suffix, which is incorrect.
Also deal with non-pve pinned versions correctly, i.e.
"pc-i440fx-5.2.pxe" becomes "pc-i440fx-5.2+pve0.pxe".
Handle .pxe suffixes in Machine.pm as well, and add two test cases.
Why do you add the macaddress here? I couldn't find anything in this nor
in the previous patch series explaining why this is done.
On 3/28/21 5:12 PM, Alexandre Derumier wrote:
---
PVE/API2/Qemu.pm| 73 +
PVE/CLI/qm.pm | 1 +
Thank you for the patch series and the GUI patches.
Some comments inline.
On 3/28/21 5:11 PM, Alexandre Derumier wrote:
Instead using vm pending options for pending cloudinit generated config,
write current generated cloudinit config in a new [special:cloudinit] SECTION.
Currently, some
On 29.03.21 14:07, Mira Limbeck wrote:
> Now that SLAAC is supported, we can revert commit 76fdf552.
> SLAAC requires cloud-init 19.4 or newer.
>
> Signed-off-by: Mira Limbeck
> ---
> www/manager6/qemu/IPConfigEdit.js | 8
> 1 file changed, 8 insertions(+)
>
>
applied, thanks!
On 31.03.21 11:52, Stoiko Ivanov wrote:
> primarily in order to warn users booting from ZFS with grub.
>
> Signed-off-by: Stoiko Ivanov
> Reviewed-By: Aaron Lauterer
> ---
> * incorporated Dylan's excellent and almost sed'able feedback
> * added Aaron's Reviewed-By tag despite sending a v2,
did not looked at all, so just a single comment.
On 31.03.21 14:06, Stefan Reiter wrote:
>> +my $wearout = 100.0 -
>> $json_result->{nvme_smart_health_information_log}->{percentage_used} if
>> !$healthonly;
>
> too long even for my liking, needs a line break somewhere :)
Yeah, there's
hi,
thank you for the comments!
On Wed, Mar 31, 2021 at 02:06:42PM +0200, Stefan Reiter wrote:
> Not familiar with smartctl, but I can comment on the code at least :)
>
> First off, quick smoke test shows me this in the GUI on an NVMe device:
>
> available_spare : 100
>
Not familiar with smartctl, but I can comment on the code at least :)
First off, quick smoke test shows me this in the GUI on an NVMe device:
available_spare : 100
available_spare_threshold : 10
controller_busy_time : 4089
critical_comp_time : 0
critical_warning : 0
data_units_read : 10402470
primarily in order to warn users booting from ZFS with grub.
Signed-off-by: Stoiko Ivanov
Reviewed-By: Aaron Lauterer
---
* incorporated Dylan's excellent and almost sed'able feedback
* added Aaron's Reviewed-By tag despite sending a v2, since the content
did not change - hope that's ok
maybe I am missing something, but AFAICT the volume_has_feature check
for the dir based plugins could also be moved to Plugin.pm, since it is
always identical:
> +sub volume_has_feature {
> +my ($class, $scfg, $feature, $storeid, $volname, $snapname, $running,
> $opts) = @_;
> +
> +my
sorry for the long pause - haven't checked the GUI part, but that should
be unaffected by my comments in-line.
On December 15, 2020 1:48 pm, Aaron Lauterer wrote:
> The goal of this new API endpoint is to provide an easy way to move a
> disk between VMs as this was only possible with manual
Hi,
I've just made some small corrections and wording changes that sounded
right.
Reviewed-by: Dylan Whyte
On 3/30/21 8:26 PM, Stoiko Ivanov wrote:
primarily in order to warn users booting from ZFS with grub.
Signed-off-by: Stoiko Ivanov
---
local-zfs.adoc | 36
On 22.03.21 15:32, Fabian Ebner wrote:
> This reverts commit a44c18925d223a971296801a0985db34707ada4d and adds a
> reminder
> comment.
>
> The mentioned commit is actually a backwards-incompatible change that leads to
> slightly different behavior when migrating a VM with volumes on a
>
On 22.03.21 15:32, Fabian Ebner wrote:
> and only scan storages that support it if specified.
>
> Signed-off-by: Fabian Ebner
> ---
> PVE/Storage.pm | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
>
applied, thanks!
___
pve-devel
On 17.03.21 13:49, Fabian Ebner wrote:
> Suggested-by: Thomas Lamprecht
> Signed-off-by: Fabian Ebner
> ---
>
> Changes from v1:
> * use existing helper functions to determine the correct transport type
>
> PVE/Storage/NFSPlugin.pm | 11 ++-
> 1 file changed, 10 insertions(+), 1
On 19.03.21 14:58, Dylan Whyte wrote:
> use DirPlugin's get/update_volume_notes implementation (which all the
> other supported file systems use)
>
> Signed-off-by: Dylan Whyte
> ---
> PVE/Storage/CephFSPlugin.pm | 10 ++
> 1 file changed, 10 insertions(+)
>
>
applied, thanks!
On 24.03.21 13:24, Fabian Grünbichler wrote:
> it is optional after all, and missing (/None) for files stored in the
> snapshot dir but not referenced in the manifest for whatever reason.
>
> Signed-off-by: Fabian Grünbichler
> ---
> PVE/Storage/PBSPlugin.pm | 2 +-
> 1 file changed, 1
Looks good to me.
Reviewed-By: Aaron Lauterer
On 3/30/21 8:26 PM, Stoiko Ivanov wrote:
primarily in order to warn users booting from ZFS with grub.
Signed-off-by: Stoiko Ivanov
---
local-zfs.adoc | 36
1 file changed, 36 insertions(+)
diff --git
28 matches
Mail list logo
