SYNOPSIS

use Net::Proxmox::VE;

%args = (
    host     => 'proxmox.local.domain',
    password => 'barpassword',
    username => 'root', # optional
    port     => 8006,   # optional
    realm    => 'pam',  # optional
);

$host = Net::Proxmox::VE->new(%args);

$host->login() or die ('Couldn\'t log in to proxmox host');

DESCRIPTION

This Class provides the framework for talking to Proxmox VE 2.0 API instances. This just provides a get/delete/put/post abstraction layer as methods on Proxmox VE REST API This also handles the ticket headers required for authentication

This class provides the building blocks for someone wanting to use Perl to talk to Proxmox PVE. It provides a get/put/post/delete abstraction layer as methods on top of Proxmox's REST API, while also handling the Login Ticket headers required for authentication.

Object representations of the Proxmox VE REST API are included in seperate modules.

WARNING

We are still moving things around and trying to come up with something that makes sense. We havent yet implemented all the API functions, so far we only have a basic internal abstraction of the REST interface and a few modules for each function tree within the API.

Any enchancements are greatly appreciated ! (use github, link below)

Please dont be offended if we refactor and rework submissions. Perltidy with default settings is prefered style.

Oh, our tests are all against a running server. Care to help make them better?

METHODS

action

This calls raw actions against your proxmox server. Ideally you don't use this directly.

api_version

Returns the API version of the proxmox server we are talking to

api_version_check

Checks that the api we are talking to is at least version 2.0

Returns true if the api version is at least 2.0 (perl style true or false)

debug

Has a single optional argument of 1 or 0 representing enable or disable debugging.

Undef (ie no argument) leaves the debug status untouched, making this method call simply a query.

Returns the resultant debug status (perl style true or false)

delete

An action helper method that just takes a path as an argument and returns the value of action() with the DELETE method

get

An action helper method that just takes a path as an argument and returns the value of action with the GET method

new

Creates the Net::Proxmox::VE object and returns it.

Examples...

my $obj = Net::Proxmox::VE->new(%args);
my $obj = Net::Proxmox::VE->new(\%args);

Valid arguments are...

host

Proxmox host instance to interact with. Required so no default.

username

User name used for authentication. Defaults to 'root', optional.

password

Pass word user for authentication. Required so no default.

port

TCP port number used to by the Proxmox host instance. Defaults to 8006, optional.

realm

Authentication realm to request against. Defaults to 'pam' (local auth), optional.

ssl_opts

If you're using a self-signed certificate, SSL verification is going to fail, and we need to tell IO::Socket::SSL not to attempt certificate verification.

This option is passed on as ssl_opts options to LWP::UserAgent->new(), ultimately for IO::Socket::SSL.

Using it like this, causes LWP::UserAgent and IO::Socket::SSL not to attempt SSL verification:

use IO::Socket::SSL qw(SSL_VERIFY_NONE);
..
%args = (
    ...
    ssl_opts => {
        SSL_verify_mode => SSL_VERIFY_NONE,
        verify_hostname => 0
    },
    ...
);
my $proxmox = Net::Proxmox::VE->new(%args);

Your connection will work now, but beware: you are now susceptible to a man-in-the-middle attack.

debug

Enabling debugging of this API (not related to proxmox debugging in any way). Defaults to false, optional.

post

An action helper method that takes two parameters: $path, \%post_data $path to post to, hash ref to %post_data

You are returned what action() with the POST method returns

put

An action helper method that takes two parameters: $path, hash ref to \%put_data

You are returned what action() with the PUT method returns

url_prefix

Returns the url prefix used in the rest api calls

PVE VERSIONS SUPPORT

Firstly, there isn't currently any handling of different versions of the API.

Secondly, Proxmox API reference documentation is also, frustratingly, published only alongside the current release. This makes it difficult to support older versions of the API or different versions of the API concurrently.

Fortunately the API is relatively stable.

Based on the above the bug reporting policy is as follows:

A function in this module doesn't work against the current published API? This a bug and hope to fix it. Pull requests welcome.

A function in this module doesn't exist in the current published API? Pull requests welcomes and promptly merged.

A function in this module doesn't work against a previous version of the API? A note will be made in the pod only.

A function in this module doesn't exist against a previous version of the API? Pull requests will be merged on a case per case basis.

As such breaking changes may be made to this module to support the current API when necessary.

DESIGN NOTE

This API would be far nicer if it returned nice objects representing different aspects of the system. Such an arrangement would be far better than how this module is currently layed out. It might also be less repetitive code.

SEE ALSO

Proxmox Website

http://www.proxmox.com

API Reference

More details on the API can be found at http://pve.proxmox.com/wiki/Proxmox_VE_API and https://pve.proxmox.com/pve-docs/api-viewer/