Add addr_to_ip and get_ip_from_hostname helpers to PVE::Network
The first helper, addr_to_ip, is based on Wolfgangs version of this
[0]
I just moved it from PVE::Tools to PVE::Network, as it seems a more
fitting place.
It uses getnameinfo to extract information from the paddr parameter,
which is sockaddr struct
It gets used in the second helper and in a bug fix series from
Wolfgang [1]
The second helper, get_ip_from_hostname, resolves an hostname to an
IP and checks if it isn't one from the for loopback reserved 127/8
subnet. It will be used in get_remote_nodeip from PVE::CLuster and
for a bugfix in pvecm.
[0]: http://pve.proxmox.com/pipermail/pve-devel/2017-April/026099.html
[1]: http://pve.proxmox.com/pipermail/pve-devel/2017-April/026098.html
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
(cherry picked from commit 87aa00de73)
since the "lang" param has not worked, introduce a "keeplocale"
parameter instead.
the default behaviour is the same (set LC_ALL to 'C'), but we can use
the parameter to keep the locale from the host (eg. for the vncshell)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
(cherry picked from commit 0f3f314ed7)
This is important when we convert the result to JSON.
Else the GUI receives booleans as "0", which evaluate to true
in JS!
NOTE: "0" evaluates to false with perl.
when reserving ports, we use lock_file to lock the
reservation file, but then use file_set_content which
writes a new file and renames it, making the lock invalid
and different processes waiting for the lock get inconsistent
data
instead we use a designated lock file for the lock, so that we don't
lose the lock when writing the reservation file
this should fix the problem that sometimes multiple vms get the
same vnc/spice port
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
We shouldn't mix different tool sets on the one hand, and on
the other hand net-tools is an optional package in stretch
and there's no real need for us to depend on it.
When a container stops or hotplug changes are applied we
do a veth_delete() which does not cleanup the firewall
bridges or OVS ports. This is problematic at the next
startup. When creating a network device we usually want to
copy the MTU of the bridge we intend to put it on, however,
with OVS still having the old port lying around the
recreated device gets associated with the bridge before we
read its MTU, potentially reducing it to that of the newly
created device.
This cleanup also gets rid of stale fwbr/fwln devices from
stopped containers.
This introduces a cyclic dependency, so we need to remove this.
PVE::CLI::* classes should instead add ad call to
PVE::RPCEnvironment->setup_default_cli_env();
Signed-off-by: Dietmar Maurer <dietmar@proxmox.com>
unless we are in cleanup mode from a failed snapshot_create,
in which case the config already has a 'snapshot' lock.
this is necessary to prevent concurrent starting of or other
actions on the guest in the windows inbetween holding the
flock, e.g. when removing the volume snapshot (which can
take a bit of time).
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>