Signed-off-by: Alexandre Derumier
---
PVE/QemuMigrate.pm | 420 +++--
1 file changed, 214 insertions(+), 206 deletions(-)
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index 111eeb0..7dd3455 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigrate.pm
@
This patch series allow remote migration between cluster with different cpu
model.
2 new params are introduced: "target-cpu" && "restart"
If target-cpu is defined, this will replace the cpu model of the target vm.
If vm is online/running, an extra "target-reboot" safeguard option is needed.
Ind
This patch add support for migration without memory transfert.
After the optionnal storage migration, we cleanly shutdown source vm
and restart the target vm. (like a virtual restart between source/dest)
Signed-off-by: Alexandre Derumier
---
PVE/API2/Qemu.pm | 19 +++
PVE/CLI/
Signed-off-by: Alexandre Derumier
---
PVE/API2/Qemu.pm | 7 +++
PVE/CLI/qm.pm | 7 +++
PVE/QemuMigrate.pm | 1 +
3 files changed, 15 insertions(+)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index c0ae516..291eb2b 100644
--- a/PVE/API2/Qemu.pm
+++ b/PVE/API2/Qemu.pm
@@ -4597,
Hi Stefan (Lendl),
I'm totally agreed with you, we should have persistent reservation,
at vm create/nic plug, nic delete, vm delete.
At least , for my usage with multiple cluster on different datacenters,
I really can wait to call ipam to api at each start (for scalability or
for security if ipam
also,
about dhcp-ranges in this patch series, I think it could be great to
make it optionnal, as some external couldn't support it.
(netbox seem to support it, but I don't have looked at next_free api
yet , phpipam don't seem to support it).
A lot of external ipam tool only search about free i
Am 24/10/2023 um 10:32 schrieb Fabian Grünbichler:
>> # Optionally pass $tos_url to agree to the given Terms of Service
>> # POST to newAccount endpoint
>> # Expects a '201 Created' reply
>> # Saves and returns the account data
>> sub new_account {
>> -my ($self, $tos_url, %info) = @_;
>>
Am 25/10/2023 um 15:07 schrieb Folke Gleumes:
> Changes v1 -> v2:
> Switched from including the eab credentials in the info hash,
> to passing them in their own variable. This still unfortunately still
> breaks the api, but doesn't potentially expose secrets and is
> cleaner then purging the value
