adapted from debian-upstream a149a374057d55ec82d8d9d258105aeb316bb1fb
Signed-off-by: Stoiko Ivanov
---
debian/zfsutils-linux.install | 72 ++-
1 file changed, 71 insertions(+), 1 deletion(-)
diff --git a/debian/zfsutils-linux.install
From: Antonio Russo
(cherry picked from commit 7f3dec474aff811b72220858fb5935054fd58a3c)
Signed-off-by: Stoiko Ivanov
---
debian/zfsutils-linux.install | 2 ++
1 file changed, 2 insertions(+)
diff --git a/debian/zfsutils-linux.install b/debian/zfsutils-linux.install
index c376d537..6a18eab9
Signed-off-by: Stoiko Ivanov
---
debian/rules | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/debian/rules b/debian/rules
index 7c4f9f6..48680f8 100755
--- a/debian/rules
+++ b/debian/rules
@@ -128,7 +128,7 @@ binary: install
${MAKE} -C ${KERNEL_SRC}
adapted from debian-upstream 490ecc37abc7f6759293b90334768d088f2ff98c
Signed-off-by: Stoiko Ivanov
---
Makefile | 8 ++--
debian/control| 48 +--
debian/libnvpair1linux.lintian-overrides | 1 -
Signed-off-by: Stoiko Ivanov
---
.../0002-always-load-ZFS-module-on-boot.patch | 8
...o-the-zed-binary-on-the-systemd-unit.patch | 6 +++---
...ith-d-dev-disk-by-id-in-scan-service.patch | 4 ++--
debian/patches/0005-Enable-zed-emails.patch | 2 +-
adapted from debian-upstream 0be5e4edc2eef9885fd03e9c797b9429da539ce2
Signed-off-by: Stoiko Ivanov
---
debian/control | 12
debian/libzfsbootenv1linux.docs | 2 ++
debian/libzfsbootenv1linux.install | 1 +
The following patchset is meant as a first rc of our packaging for ZFS 2.0
for the greatest part I mirrored the merge request by Antonio Russo over
at salsa.d.o [0], and adapted where needed.
Another change, which was merged at debian, before the merge request, was
the placement of shared
adapted from debian-upstream 8f137b115a89348e7816f60b5e8410fd303fec81
Signed-off-by: Stoiko Ivanov
---
debian/libnvpair1linux.install| 1 -
debian/libnvpair1linux.install.in | 1 +
debian/libuutil1linux.install | 1 -
debian/libuutil1linux.install.in | 1 +
From: Antonio Russo
(cherry picked from commit 3376e22c139b6dcd5774018fc7ebcdff9fac66c3)
Signed-off-by: Stoiko Ivanov
---
debian/zfsutils-linux.install | 2 ++
1 file changed, 2 insertions(+)
diff --git a/debian/zfsutils-linux.install b/debian/zfsutils-linux.install
index 6a18eab9..77b3ab88
From: Antonio Russo
(cherry picked from commit c5b72db53215c2ca7b76c21113f466938517d71b)
Signed-off-by: Stoiko Ivanov
---
debian/zfsutils-linux.install | 1 +
1 file changed, 1 insertion(+)
diff --git a/debian/zfsutils-linux.install b/debian/zfsutils-linux.install
index 229ff2ea..c3a32bcc
On 01.12.20 09:24, Fabian Ebner wrote:
> To get a more complete picture, instead of mocking storage_config,
> PVE::Cluster's get_config is mocked. This ensures that the prune-backups
> validation and the maxfiles conversion are also called.
>
> Signed-off-by: Fabian Ebner
> ---
> test/Makefile
Hello,
We are moving VMs from vmware to proxmox
The process follows:
- export the VM using ovftool
- import using qm importovf
We are facing an issue on multi-disk VM: all the disks are attached as
scsi0 (which fails, and abort the process)
From /usr/share/perl5/PVE/CLI/qm.pm, that value
On 02.12.20 14:19, Dominik Csapak wrote:
> On 12/2/20 2:11 PM, Thomas Lamprecht wrote:
>> On 02.12.20 13:56, Dominik Csapak wrote:
>>> instead of relying on the contentTypeField (which does not need to
>>> exists, e.g. for iscsi), explicitely write it into the panel/icon
>>> mapping and check that
On 12/2/20 2:11 PM, Thomas Lamprecht wrote:
On 02.12.20 13:56, Dominik Csapak wrote:
instead of relying on the contentTypeField (which does not need to
exists, e.g. for iscsi), explicitely write it into the panel/icon
mapping and check that
why not return it for iSCIS? >
i don't understand
On 02.12.20 13:56, Dominik Csapak wrote:
> instead of relying on the contentTypeField (which does not need to
> exists, e.g. for iscsi), explicitely write it into the panel/icon
> mapping and check that
why not return it for iSCIS?
>
> better would be if we query the backend about storage
This thread will inform you :)
https://forum.proxmox.com/threads/openzfs-2-0.79948/
> On 12/02/2020 1:45 PM Graeme Seaton wrote:
>
>
> Hi,
>
> Notice that OpenZFS 2.0 has been officially released at:
> https://github.com/openzfs/zfs/releases/tag/zfs-2.0.0
>
> Is integration into PVE on the
Hi,
On 02.12.20 13:45, Graeme Seaton wrote:
> Notice that OpenZFS 2.0 has been officially released at:
> https://github.com/openzfs/zfs/releases/tag/zfs-2.0.0
yes, we noticed that too :)
> Is integration into PVE on the roadmap? (I'm a sucker for new toys ;-) )
>
Copying over my answer from
Hi,
Notice that OpenZFS 2.0 has been officially released at:
https://github.com/openzfs/zfs/releases/tag/zfs-2.0.0
Is integration into PVE on the roadmap? (I'm a sucker for new toys ;-) )
Regards,
Graeme
___
pve-devel mailing list
instead of relying on the contentTypeField (which does not need to
exists, e.g. for iscsi), explicitely write it into the panel/icon
mapping and check that
better would be if we query the backend about storage capabilities,
but such an api call does not exist yet, so this should be ok for now
We only added the format extension when it was not 'raw'. But on file level
storages we always require it. To fix this, always add the format
extension if the storage provides the 'path' property.
This is the same logic we use in create_disks for cloudinit disks.
Signed-off-by: Mira Limbeck
---
Only fixes the clone_disk case, not the restore from backup one. Will
send a v2 with both fixes.
On 12/1/20 3:53 PM, Mira Limbeck wrote:
We only added the format extension when it was not 'raw'. But on file level
storages we always require it. To fix this, always add the format
extension if
we have a 1:1 copy of that code in pve-manager's PVE::API2::Scan,
which we can avoid by using a common module form pvesm CLI and the
API.
This is the first basic step of dropping the code duplication in
pve-manager.
Signed-off-by: Thomas Lamprecht
---
some very minor differences between both,
As envisioned in[0][1], better late than never.
[0]: commit 3bca5efd9c219d97c2eac5685bf6cac579a3b0f1
[1]: https://lists.proxmox.com/pipermail/pve-devel/2018-November/034694.html
Signed-off-by: Thomas Lamprecht
---
PVE/API2/Hardware.pm | 9 ++-
PVE/API2/Hardware/Makefile | 3 ++-
so that we can sunset the usbscan from pve-storage's scan API, which
was never fitting there anyway.
Signed-off-by: Thomas Lamprecht
---
www/manager6/form/USBSelector.js | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/www/manager6/form/USBSelector.js
Add the missing pieces allowing pve-manager to just point the
/nodes//scan api directory at this module, dropping it's
duplicated copy.
Signed-off-by: Thomas Lamprecht
---
PVE/API2/Storage/Scan.pm | 84
1 file changed, 84 insertions(+)
diff --git
Signed-off-by: Thomas Lamprecht
---
PVE/API2/Storage/Scan.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/PVE/API2/Storage/Scan.pm b/PVE/API2/Storage/Scan.pm
index 0e6fd9a..44d6628 100644
--- a/PVE/API2/Storage/Scan.pm
+++ b/PVE/API2/Storage/Scan.pm
@@ -127,6 +127,7 @@
Finishes the thoughts we had two years ago[0], add usb endpoint in the existing
hardware/ api directory, along side PCI, and use it. This then allows
sunsetting the one in the storage scan api (which never should have been added
there in the first place), and unifying of the pvesm CLI and API
Signed-off-by: Thomas Lamprecht
---
note: I had to do a fixup commit for the first hunk, forgot to add it to
staging area on commit -.- but the actual changes are those showed here.
PVE/API2/Nodes.pm | 4 +-
PVE/API2/Makefile | 1 -
PVE/API2/Scan.pm | 424
needs an organization/bucket (previously db) and an optional token
the http client does not fit exactly in the connect/send/disconnect
scheme, so it simply creates a request in 'connect',
does the actual http connection in 'send' and nothing in 'disconnect'
max-body-size is set to 25.000.000
like we do in it for the storage section configs
we will need this to store the token for influxdbs http api
Signed-off-by: Dominik Csapak
---
PVE/API2/Cluster/MetricServer.pm | 39 +++-
PVE/Status/Plugin.pm | 24
2 files changed, 57
Signed-off-by: Dominik Csapak
---
www/manager6/dc/MetricServerView.js | 4
1 file changed, 4 insertions(+)
diff --git a/www/manager6/dc/MetricServerView.js
b/www/manager6/dc/MetricServerView.js
index dfec8c03..edb40cc5 100644
--- a/www/manager6/dc/MetricServerView.js
+++
like we do in other apis of section configs (e.g. storage)
Signed-off-by: Dominik Csapak
---
PVE/API2/Cluster/MetricServer.pm | 2 ++
1 file changed, 2 insertions(+)
diff --git a/PVE/API2/Cluster/MetricServer.pm b/PVE/API2/Cluster/MetricServer.pm
index 9a14985e..ec3c7b75 100644
---
moved and generalized from pve-storage, since we'll need it
in more places
Signed-off-by: Dominik Csapak
---
src/PVE/Tools.pm | 24
1 file changed, 24 insertions(+)
diff --git a/src/PVE/Tools.pm b/src/PVE/Tools.pm
index 4b445ea..bda236a 100644
--- a/src/PVE/Tools.pm
and en/disable them accordingly to the selected mode
Signed-off-by: Dominik Csapak
---
www/manager6/dc/MetricServerView.js | 101 ++--
1 file changed, 96 insertions(+), 5 deletions(-)
diff --git a/www/manager6/dc/MetricServerView.js
and mention that 1.8.x has a compatible api (and their differences)
Signed-off-by: Dominik Csapak
---
pve-external-metric-server.adoc | 18 ++
1 file changed, 18 insertions(+)
diff --git a/pve-external-metric-server.adoc b/pve-external-metric-server.adoc
index 783e72c..eace999
by providing the id or cfg to have better context in those methods
we will need that for influxdb http api
Signed-off-by: Dominik Csapak
---
PVE/ExtMetric.pm | 4 ++--
PVE/Status/Plugin.pm | 14 +++---
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/PVE/ExtMetric.pm
we have a more general version there
Signed-off-by: Dominik Csapak
---
PVE/API2/Storage/Config.pm | 29 -
1 file changed, 4 insertions(+), 25 deletions(-)
diff --git a/PVE/API2/Storage/Config.pm b/PVE/API2/Storage/Config.pm
index 6e23427..00abd13 100755
---
37 matches
Mail list logo
