On April 7, 2020 2:19 pm, Fabian Ebner wrote:
> On 06.04.20 11:52, Fabian Grünbichler wrote:
>> On April 6, 2020 10:46 am, Fabian Ebner wrote:
>>> On 27.03.20 10:09, Fabian Grünbichler wrote:
with a small follow-up for vzdump (see separate mail), and comment below
On March 23, 2020
On 4/5/20 10:33 AM, Alexandre Derumier wrote:
> Signed-off-by: Alexandre Derumier
> ---
> src/PVE/INotify.pm | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/src/PVE/INotify.pm b/src/PVE/INotify.pm
> index 3fa5af6..871deda 100644
> --- a/src/PVE/INotify.pm
> +++ b/src/PVE/INotify.pm
>
On 4/7/20 9:25 AM, Dominik Csapak wrote:
> Instead of relying on list_volumes of Plugin.pm (which filters by
> the content types set in the config), use our own to always
> show the luns of an iscsi.
>
> This makes sense here, since we need it to show the luns when using
> it as base storage for
On 4/6/20 4:24 PM, Aaron Lauterer wrote:
> This patch adds a new API endpoint that returns a list of included
> guests, their volumes and whether they are included in a backup.
>
> The output is formatted to be used with the extJS tree panel.
>
> Signed-off-by: Aaron Lauterer
> ---
> v1 -> v2:
> Thomas Lamprecht hat am 7. April 2020 17:19
> geschrieben:
>
>
> On 3/30/20 1:41 PM, Fabian Grünbichler wrote:
> > another round of preparatory patches for remote migration.
> >
> > qemu-server's #1 is an unrelated follow-up fix,
> > #2-4 are refactoring,
> > #5+6 are new features/checks,
On 4/7/20 3:56 PM, Stefan Reiter wrote:
> Based on the RFC and following on- and off-list discussion about custom CPU
> models [0].
>
> In essence, this revised patch allows a user to specify custom CPU models in
> /etc/pve/cpu-models.conf (section-config style [1]), where VMs using that CPU
>
On 3/30/20 1:41 PM, Fabian Grünbichler wrote:
> another round of preparatory patches for remote migration.
>
> qemu-server's #1 is an unrelated follow-up fix,
> #2-4 are refactoring,
> #5+6 are new features/checks,
> #7+8 are refactorings as preparation for remote migration which will
> call the
On 4/7/20 1:11 PM, Dominik Csapak wrote:
> Instead of simply requiring it to exist in /etc/pve.
>
> Takes after the password handling of CIFS in pve-storage.
>
> Signed-off-by: Dominik Csapak
> ---
> changes from v1:
> * delete pw when given via 'delete' parameter
> * do not delete pw when
Just like with live-migration, custom CPU models might change after a
snapshot has been taken (or a VM suspended), which would lead to a
different QEMU invocation on rollback/resume.
Save the "-cpu" argument as a new "runningcpu" option into the VM conf
akin to "runningmachine" and use as
If a cputype is custom (check via prefix), try to load options from the
custom CPU model config, and set values accordingly.
While at it, extract currently hardcoded values into seperate sub and add
reasonings.
Since the new flag resolving outputs flags in sorted order for
consistency, adapt the
Can be specified for a particular VM or via a custom CPU model (VM takes
precedence).
QEMU's default limit only allows up to 1TB of RAM per VM. Increasing the
physical address bits available to a VM can fix this.
Signed-off-by: Stefan Reiter
---
Changes in v10:
* Change phys-bits format to
To avoid hardcoding even more CPU-flag related things for custom CPU
models, introduce a dynamic approach to resolving flags.
resolve_cpu_flags takes a list of hashes (as documented in the
comment) and resolves them to a valid "-cpu" argument without
duplicates. This also helps by providing a
Requires a mock CPU-model config, which is given as a raw string to also
test parsing capabilities. Also tests defaulting behaviour.
Signed-off-by: Stefan Reiter
Reviewed-By: Fabian Ebner
Tested-By: Fabian Ebner
---
Changes in v10:
* Added test for new phys-bits format
(Since it's just a
This is required to support custom CPU models, since the
"cpu-models.conf" file is not versioned, and can be changed while a VM
using a custom model is running. Changing the file in such a state can
lead to a different "-cpu" argument on the receiving side.
This patch fixes this by passing the
Based on the RFC and following on- and off-list discussion about custom CPU
models [0].
In essence, this revised patch allows a user to specify custom CPU models in
/etc/pve/cpu-models.conf (section-config style [1]), where VMs using that CPU
model inherit details from the definition. This
ZFS supports the -p flag in the list command since a few years now.
Let us use the real byte values and avoid the error prone calculation
from human readable numbers that can lead to incorrect numbers if the
reported human readable value is a rounded number.
Signed-off-by: Aaron Lauterer
---
Signed-off-by: Aaron Lauterer
---
this was the only other place I found where the use of the -p flag might
be useful
PVE/Storage/ZFSPoolPlugin.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/PVE/Storage/ZFSPoolPlugin.pm b/PVE/Storage/ZFSPoolPlugin.pm
index
Getting the volume sizes as byte values instead of converted to human
readable units helps to avoid rounding errors in the further processing
if the volume size is more on the odd side.
The `zfs list` command supports the -p(arseable) flag since a few years
now.
When returning the size in bytes
On 06.04.20 11:52, Fabian Grünbichler wrote:
On April 6, 2020 10:46 am, Fabian Ebner wrote:
On 27.03.20 10:09, Fabian Grünbichler wrote:
with a small follow-up for vzdump (see separate mail), and comment below
On March 23, 2020 12:18 pm, Fabian Ebner wrote:
With the option
Instead of simply requiring it to exist in /etc/pve.
Takes after the password handling of CIFS in pve-storage.
Signed-off-by: Dominik Csapak
---
changes from v1:
* delete pw when given via 'delete' parameter
* do not delete pw when updating without giving 'password' parameter
Instead of simply requiring it to exist in /etc/pve.
Takes after the password handling of CIFS in pve-storage.
Signed-off-by: Dominik Csapak
---
i guess if we have to add this pattern again somewhere, it would be
useful to refactor it to the SectionConfig, but for now we simply duplicate
On April 7, 2020 11:28 am, Aaron Lauterer wrote:
>
>
> On 4/3/20 5:07 PM, Fabian Grünbichler wrote:
>> there's another instance of 'zfs list ...' in PVE::Storage that could
>> also be switched to '-p'
>
> Which one do you mean? Line 610?
>
>1 if ($format eq 'subvol') {
>
> 610
On 4/3/20 5:07 PM, Fabian Grünbichler wrote:
there's another instance of 'zfs list ...' in PVE::Storage that could
also be switched to '-p'
Which one do you mean? Line 610?
1 if ($format eq 'subvol') {
610 my $size = $class->zfs_request($scfg, undef, 'list', '-H',
'-o',
On 07/04/2020 09:04, Fabian Ebner wrote:
On 06.04.20 15:01, Stefan Reiter wrote:
On 06/04/2020 14:31, Fabian Ebner wrote:
On 26.03.20 16:13, Stefan Reiter wrote:
Just like with live-migration, custom CPU models might change after a
snapshot has been taken (or a VM suspended), which would lead
Instead of relying on list_volumes of Plugin.pm (which filters by
the content types set in the config), use our own to always
show the luns of an iscsi.
This makes sense here, since we need it to show the luns when using
it as base storage for LVM (where we have content type 'none' set).
It does
> Hi I downloaded and did the proxmox-backup cargo build, but now when I try
> to build make dinstall it fails because it can't find the crate on the
> registry, how did you solve this problem you have an internal cargo
> registry ? I tried cargo local registry and also cargo vendor but I can't
>
On 06.04.20 15:01, Stefan Reiter wrote:
On 06/04/2020 14:34, Fabian Ebner wrote:
On 26.03.20 16:13, Stefan Reiter wrote:
Can be specified for a particular VM or via a custom CPU model (VM takes
precedence).
QEMU's default limit only allows up to 1TB of RAM per VM. Increasing the
physical
On 06.04.20 15:01, Stefan Reiter wrote:
On 06/04/2020 14:31, Fabian Ebner wrote:
On 26.03.20 16:13, Stefan Reiter wrote:
Just like with live-migration, custom CPU models might change after a
snapshot has been taken (or a VM suspended), which would lead to a
different QEMU invocation on
Hi I downloaded and did the proxmox-backup cargo build, but now when I try
to build make dinstall it fails because it can't find the crate on the
registry, how did you solve this problem you have an internal cargo
registry ? I tried cargo local registry and also cargo vendor but I can't
get
29 matches
Mail list logo
