Please try changing the AddressOnParent values so that they are unique.
As you mentioned, the disks should then be attached with different numbers
scsi0, scsi1, scsi2...
If it still doesn't work, then you can also create a VM and add each disk
manually by using qm importdisk. For example,
qm imp
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 b/debian/zfsutils-linux.insta
From: Antonio Russo
(cherry picked from commit 340f9394c38a78b2530a64746c1518163d7f6970)
Signed-off-by: Stoiko Ivanov
---
debian/rules | 2 ++
debian/zfsutils-linux.install | 2 ++
2 files changed, 4 insertions(+)
diff --git a/debian/rules b/debian/rules
index 0e168ee1..1ce79a
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 10
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}
INSTALL_MOD_PAT
adapted from debian-upstream 490ecc37abc7f6759293b90334768d088f2ff98c
Signed-off-by: Stoiko Ivanov
---
Makefile | 8 ++--
debian/control| 48 +--
debian/libnvpair1linux.lintian-overrides | 1 -
...nvpair1
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 +-
.../0006-dont-symlink-zed-script
adapted from debian-upstream 0be5e4edc2eef9885fd03e9c797b9429da539ce2
Signed-off-by: Stoiko Ivanov
---
debian/control | 12
debian/libzfsbootenv1linux.docs | 2 ++
debian/libzfsbootenv1linux.install | 1 +
debian/libzfsbootenv1l
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 library
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 +
debian/libzfs2linux.insta
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 10
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 100
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
>
> better would be if we query the backend about storage capabilities,
> but such an api call
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 came
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 w
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 capabi
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 a
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
pve-devel@lists
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
Sig
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
---
v
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 the
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, C
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 ++-
PVE
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 b/www/manager6/form/U
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 a/PVE/A
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 @@ __PACKAGE__->registe
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 def
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 bytes
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
+++ b/www/manager6/dc/
this series adds the possibility to write influxdb data via their
v2 api. For influxdb 1.x there is a forwards compatible api since 1.8.0
i am not so sure about how i integrated the http api part into the
existing influxdb plugin, another alternative would be to have
a new InfluxDB2 Plugin that do
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
--- a/PVE/API2/C
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
b/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 1
we already have that information in the reference docs, no need to
have it here as well
Signed-off-by: Dominik Csapak
---
PVE/Status/InfluxDB.pm | 7 ---
1 file changed, 7 deletions(-)
diff --git a/PVE/Status/InfluxDB.pm b/PVE/Status/InfluxDB.pm
index f16af486..9ecce235 100644
--- a/PVE/Sta
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 b
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
--- a/PVE/API
42 matches
Mail list logo
