meta: please send v2 together with v2 of pve-container (and future) patches.
On September 4, 2019 6:00 pm, Oguz Bektas wrote:
> some functions from Qemu w.r.t. pending changes can be moved to
> AbstractConfig, in order to make them available for both QemuConfig and
> LXC::Config.
>
> Signed-off-b
On September 5, 2019 4:11 pm, Oguz Bektas wrote:
> the default behaviour is the same as in Qemu, so without the 'current'
> flag set, current values will be replaced with their respective pending
> counterparts.
>
> Signed-off-by: Oguz Bektas
> ---
> src/PVE/API2/LXC/Config.pm | 23 +
NAK, this breaks existing configs with a snapshot called pending (which
is an allowed snapshot name, and not such an uncommon word that we can
confidently say that noone would be affected). we could do _PENDING_ or
__PENDING__ (similar to what we do with __base__ and __replicate__ and
__migrati
the commit message is misleading - this just adds two parameters, but no
code that handles them? the code/change that adds handling only comes in
patch #8. either merge these two, or put this one after the other
please.
On September 5, 2019 4:11 pm, Oguz Bektas wrote:
> Signed-off-by: Oguz Bekt
On September 5, 2019 4:11 pm, Oguz Bektas wrote:
> analog to Qemu, it returns an array of elements, which shows the
> current value, pending value, and delete requests.
and again, this is completely identical to the Qemu API path (modulo
comments, one superfluous next statement) except for the ci
On September 5, 2019 4:11 pm, Oguz Bektas wrote:
> analog to 'qm pending', it shows a list of keys and values defined in
> configuration.
copied verbatim from qm.pm, maybe we could move this code to
GuestHelpers.pm (format_pending)?
>
> cur: current change
> new: pending change
> del: pending d
On September 5, 2019 4:11 pm, Oguz Bektas wrote:
> vmconfig_hotplug_pending is responsible for checking if a key in the
> pending section is hotpluggable, if yes; perform a generic config value
> replace or perform specific actions if a special case.
>
> vmconfig_apply_pending is only supposed to
On September 5, 2019 4:11 pm, Oguz Bektas wrote:
> Signed-off-by: Oguz Bektas
> ---
> src/PVE/LXC.pm | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/src/PVE/LXC.pm b/src/PVE/LXC.pm
> index 475d9be..9dd5bc9 100644
> --- a/src/PVE/LXC.pm
> +++ b/src/PVE/LXC.pm
> @@ -1939,6 +1939,13
On September 5, 2019 4:11 pm, Oguz Bektas wrote:
> this series makes it possible to add/revert/delete pending changes in
> the backend.
>
> it depends on my previous patch for pve-guest-common, for enabling
> inheritance of pending changes related methods into PVE::LXC::Config
thanks for these pa
On September 5, 2019 4:11 pm, Oguz Bektas wrote:
> use vmconfig_hotplug_pending (when ct up) and vmconfig_apply_pending
> (when ct down) to apply or write pending changes.
>
> Signed-off-by: Oguz Bektas
> ---
> src/PVE/API2/LXC/Config.pm | 52 +-
> src/PVE/LXC/Config.pm | 328 +
Migration with --targetstorage was broken because of this.
Signed-off-by: Fabian Ebner
---
PVE/Storage.pm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/PVE/Storage.pm b/PVE/Storage.pm
index 755eca8..31eeb21 100755
--- a/PVE/Storage.pm
+++ b/PVE/Storage.pm
@@ -586,7 +586
this conflicts with our syntax of pending changes, so we have to forbid it
the check must be case-insensitive since we parse it that way from the config
this may be reverted again sometime with 7.0 if we decide to change the
name of the pending section
Signed-off-by: Dominik Csapak
---
PVE/API2
On 11.09.19 11:46, Fabian Ebner wrote:
> Migration with --targetstorage was broken because of this.
>
> Signed-off-by: Fabian Ebner
> ---
> PVE/Storage.pm | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/PVE/Storage.pm b/PVE/Storage.pm
> index 755eca8..31eeb21 100755
On 11.09.19 12:14, Dominik Csapak wrote:
> this conflicts with our syntax of pending changes, so we have to forbid it
> the check must be case-insensitive since we parse it that way from the config
>
> this may be reverted again sometime with 7.0 if we decide to change the
> name of the pending se
On 11.09.19 09:39, Fabian Grünbichler wrote:
> NAK, this breaks existing configs with a snapshot called pending (which
> is an allowed snapshot name, and not such an uncommon word that we can
> confidently say that noone would be affected). we could do _PENDING_ or
naming it pending for VMs was
Signed-off-by: Dominik Csapak
---
changes from v3:
* use ENOENT to check for existance
PVE/QemuServer.pm | 19 +++
1 file changed, 19 insertions(+)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index 7128723..367d080 100644
--- a/PVE/QemuServer.pm
+++ b/PVE/QemuServer.pm
@@
this adds a reboot api call for vms, which uses a reboot request file
that gets detected by the qm cleanup call to start the vm again
this api call is useful when users want to apply pending hardware changes
without waiting for the vm to shutdown
changes from v3:
* rebased on master
* used ENOENT
if the reboot trigger file was set, start the vm again
also cleanup the reboot trigger on vm startup, to prevent
leftover files to trigger a reboot at the next shutdown
Signed-off-by: Dominik Csapak
---
changes from v3:
* use shorter eval and warn
PVE/CLI/qm.pm | 12
PVE/QemuSer
this creates a reboot request file (inspired by pve-container)
and relies on the 'qm cleanup' call by the qmeventd to detect
and restart the vm afterwards
Signed-off-by: Dominik Csapak
---
changes from v3:
* add note about pending changes in api description
* move storecfg into vm_reboot
* improv
we want to reuse most of the code in the locked context of vm_stop
for vm_reboot (since it really is just a vm_stop with a
create_reboot_request in there) so we factor that out into
_do_vm_stop
and note that it has to be called in a locked context
Signed-off-by: Dominik Csapak
---
new in v4 (spli
On 11.09.19 09:39, Fabian Grünbichler wrote:
> On September 5, 2019 4:11 pm, Oguz Bektas wrote:
>> +# take pending changes in
>> +if (!$param->{current}) {
>> +foreach my $opt (keys %{$conf->{pending}}) {
>> +next if $opt eq 'delete';
>> +my $value = $conf->{
On 05.09.19 16:11, Oguz Bektas wrote:
> Signed-off-by: Oguz Bektas
> ---
> src/PVE/API2/LXC.pm | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/PVE/API2/LXC.pm b/src/PVE/API2/LXC.pm
> index 6ddff9c..9ddaf58 100644
> --- a/src/PVE/API2/LXC.pm
> +++ b/src/PVE/API2/LXC.p
On 9/11/19 1:26 PM, Thomas Lamprecht wrote:
On 11.09.19 12:14, Dominik Csapak wrote:
this conflicts with our syntax of pending changes, so we have to forbid it
the check must be case-insensitive since we parse it that way from the config
this may be reverted again sometime with 7.0 if we decide
To not change current behaviour and thus breaking live migration USB3
for a Spice USB device requires Qemu v4.1.
The old behavior was that even though technically it was possible to
the set `usb3=1` setting, it was ignored. The bus was hardcoded to
ehci. If another USB2 device was added or the mac
The check relied on the fact that in a regular use case a usb device of
type spice would not have any other settings like `usb3=1`. An exact
match worked fine for this.
This patch changes the behaviour and makes it possible to migrate VMs
with Spice USB devices that have additional usb options set
Signed-off-by: Aaron Lauterer
---
PVE/QemuServer/USB.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/PVE/QemuServer/USB.pm b/PVE/QemuServer/USB.pm
index a2097b9..2c09490 100644
--- a/PVE/QemuServer/USB.pm
+++ b/PVE/QemuServer/USB.pm
@@ -86,7 +86,7 @@ sub get_usb_devices {
This patch series enables USB3 for the passthrough / redirection of USB
devices via the Spice client.
v3 -> v4:
* cleanup of redundant if condition
* avoiding cyclic module dependency from USB.pm to QemuServer.pm
* fixing regex check for migration to match if spice is at beginning
alone or with
Instead of having two times the check if the USB3 setting needs to be
added to the config string it is now checked at one place only.
If USB3 is checked for a non USB3 device it will be attached to the USB2
root hub of the xhci controller.
Signed-off-by: Aaron Lauterer
---
www/manager6/qemu/USB
On 11.09.19 14:07, Dominik Csapak wrote:
> this adds a reboot api call for vms, which uses a reboot request file
> that gets detected by the qm cleanup call to start the vm again
>
> this api call is useful when users want to apply pending hardware changes
> without waiting for the vm to shutdown
29 matches
Mail list logo
