IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Instead of just using it as a warning and then trying to parse an
empty string as json.
For example, trying to parse unsupported vmdks, previously we'd see
something like this:
qemu-img: Could not open
'/run/pve/import/esxi/foo/mnt/ha-datacenter/vsanDatastore/asdf/asdf-000001.vmdk':
Unsupported image type 'vsanSparse'
could not parse qemu-img info command output for
'/run/pve/import/esxi/foo/mnt/ha-datacenter/vsanDatastore/asdf/asdf-000001.vmdk'
- malformed JSON string, neither tag, array, object, number, string
or atom, at character offset 0 (before "(end of string)") at
src/PVE/Storage/Plugin.pm line 962, <DATA> line 960.
Now it simply shows:
qemu-img: Could not open
'/run/pve/import/esxi/foo/mnt/ha-datacenter/vsanDatastore/asdf/asdf-000001.vmdk':
Unsupported image type 'vsanSparse'
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Reduce the time the cache stays valid from 60s to 30s, while this
could double the amount of requests in the worst case, it's still not
that frequent and also halves the maximal time a user has to wait to
see changes on the ESXi side to appear here.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This patch introduces the conversion table for all possible OS Types
that are in the VMWare 'other' family and sets the pve counterpart.
Our default OS Type is 'linux', so including mappings to 'other' makes
sense.
Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
otherwise we get `scsihw: null` from the api, which is not a valid
value, so just omit it.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
we cannot import the state of the efivars (e.g. boot order)
so add a warning for that
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
[ TL: add new warning to return schema ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
to ensure that the next access actually uses the updated config for
accessing the remote ESXi, for both manifest API and FUSE mount.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
following pve-esxi-import-tools's commits:
3ee5c3b ("esxi-folder-fuse: add --insecure option")
c292c67 ("listvms.py: add --insecure parameter, verify cert by
default")
34c87be ("rename --insecure option to --skip-cert-verification")
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
[ TL: rename 'insecure' to 'skip-cert-verification' to better convey
what it means ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
does not really make sense, and if the plugin wants that, it can still
be done, like we do here for the ESXiPlugin
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
[ TL: fix wrong comparison with >= and avoid undef warning if file
does not yet exist at all ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
[ TL: squash removal of both subs into one commit ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This allows the frontends to translate them and avoids somewhat
duplicated info by having some warnings explicitly (ignored-volumes)
while others are in the warnings array.
By passing along the key and the value the frontend can also show the
warnings in-line, e.g. by marking a disk-entry in a grid as having
potential problems.
Ideally we'd have a central list of known types used for the API
return schema enum and to check when calling the $warn closure, but as
we only got three warnings keep this as is and only add a comment.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
and rename the name of the constant for the FUSE tool, as otherwise it
sounds like this was the mountpoint to be used
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
we should actually keep the scsihw even with eg. linux VMs as they
might not have virtio/... in their initrd and then fail to boot
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
This will be used for returning the base meta information of a
external VM that is about to be imported into Proxmox VE.
A front-end can use this endpoint to show the proposed configs with
potential override switches to the user, so that they can adapt the
most important options to ensure that import can work.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
[ TL: add more commit message with some background ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The get_guest_import fn is currently a private/internal API and should
not yet be exposed as a public part of the storage API.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Add a new 'import' content type which will be the corner stone for a
better API and UI integrated way to import virtual guests into Proxmox
VE.
For starters this will be used to implement a ESXi adapter, so that
those VMs can get imported nicely.
Later we want to integrate the OVF/OVA import skeletons we got in
qemu-server to something more usable here.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
[ TL: add more commit message with some background ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
We actually use it already (partially without perl use statement) and
the use of the new Sys.AccessNetwork privilege should be version
guarded too.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The download-url API endpoint has some implications that admins are
unaware of, namely that it basically allow to scan the whole network
via HTTP URLs, and potentially even download some image that the user
should not have access to and adding to a VM that the user controls.
That's why in addition to the Datastore.AllocateTemplate privilege on
the storage, the Sys.Modify on the whole Cluster was required to use
the API call. That design was chosen as we were not fully sure if a
separate privilege is warranted, but user feedback has shown that the
(not so big) cost of adding such a new privilege is justified.
Change the permission check to allow the combination of
Datastore.AllocateTemplate on the storage and either 'Sys.Modify' on
/, for backwards compatibility, or the newer 'Sys.AccessNetwork' on
the node that handles the download.
Using a node-specific ACL path allows admins to e.g. prepare one
specific node's firewall so that pveproxy can access only a safe set
of hosts via outgoing HTTP (not stemming from valid connection
tracking to the PVE API), and thus even further limit the privileges
of users or tools that are trusted to download images to a storage.
Buglink: https://bugzilla.proxmox.com/show_bug.cgi?id=5254
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Tested-by: Hannes Duerr <h.duerr@proxmox.com>
Reviewed-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
It's not clear to users what this property does otherwise. Latest
report from the community forum:
https://forum.proxmox.com/threads/134393
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
The default description doesn't make it clear what the property is
used for in the context of storages.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
