The ip link set command which create the veth pair is not setting mtu on both peers
example:
vm 106 is on a bridge with mtu 9000
222: tap160i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast master fwbr160i1 state UNKNOWN group default qlen 1000
223: fwbr160i1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
224: fwpr160p1@fwln160i1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP group default qlen 1000
225: fwln160i1@fwpr160p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
fwpr160p1@fwln160i1 is correctly created with mtu 9000
but
fwln160i1@fwpr160p1 is created with mtu 1500.
(and then vmbr106i1 is lowered to 1500 too).
This is doing network problem, as tap160i1 is mtu9000.
After this patch:
222: tap160i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast master fwbr160i1 state UNKNOWN group default qlen 1000
223: fwbr160i1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP group default qlen 1000
224: fwpr160p1@fwln160i1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP group default qlen 1000
225: fwln160i1@fwpr160p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP group default qlen 1000
Stoiko Ivanov [Tue, 20 Nov 2018 08:46:32 +0000 (09:46 +0100)]
fix #1956: return controlling terminal to parent
The changes introduced in e97f807c388c10250f442b1f16c5315df2ffc2af let the
child in fork_worker take the controlling terminal of the session, without
returning it after finishing.
This breaks using/reading from the terminal after both parent and child exit
- e.g. when the code is called from within a shellscript.
Dominik Csapak [Fri, 16 Nov 2018 15:17:46 +0000 (16:17 +0100)]
introduce SysFSTools
initially, copy pci related subs from PVE::QemuServer we want to have
it in common, so we can maybe reuse them later, also the code is not
really qemu-server related
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com> Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thomas Lamprecht [Sun, 18 Nov 2018 15:06:19 +0000 (16:06 +0100)]
tools: template_replace: esacpe braces
To avoid warnings (and in the future, errors) like:
> Unescaped left brace in regex is deprecated here (and will be fatal
> in Perl 5.32), passed through in regex; marked by <-- HERE in
> m/([^{]+)?({ <-- HERE ([^}]+)})?/ at /usr/share/perl5/PVE/Tools.pm
> line 673.
with future perl versions, like Debian Buster for example has.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
fix #1963: don't do day-time related math on time stamps
Since our schedules are usually written in local time, we
cannot actually perform calculations using time stamps as
for instance adding 3600 (1 hour) may yield the exact same
local time as before when translated to the current timezone
during a DST change, or might skip an hour. Thus, 2:30am + 1
hour can be all of 2:30am, 3:30am or 4:30am.
Instead, perform the translation to a "day time" array once,
then search for the scheduled time, and only at the end
translate to a time stamp again. This means adding helpers
to wrap around minutes, hours, days (of month)...
Previously, the following code looped endlessly in
compute_next_event under CEST:
my $dst_time = timelocal(0, 0, 0, 28, 9, 2018);
my $t = PVE::CalendarEvent::parse_calendar_event('mon..fri');
my $next = PVE::CalendarEvent::compute_next_event($t, $dst_time);
Afterwards $next will be '2018-10-29 00:00 CET' as expected.
Of course, a day in which 3am appears twice with a scheduled
event for 3am will cause the event to be scheduled twice
now. Ideally we add the ability to make calendar specs use
UTC (and actually use the $utc parameter we have in
compute_next_event()). systemd.time(7) seems to allow simply
suffixing the spec with the string " UTC" for that purpose,
so we should follow this.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com> Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Dominik Csapak [Tue, 21 Aug 2018 13:07:25 +0000 (15:07 +0200)]
run_fork_with_timeout: handle SIGTERM
when stopping a worker while doing a run_fork_with_timeout,
we want to handle that there and send the child the SIGTERM
so that it can clean up
for this we have to use readline_nointr,
because the read from the pipe gets interrupted by the signal
this partially fixes #1874
as we now correctly clean up the new disk, except if it is
on lvm/lvmthin (possibly other storages as well), and use the old disk
in the config
Tools like pvesh and pveclient pass them as normal arguments. We use
a simply heuristic to test if there is an 'output_format' parameter.
If so, we remove all $standard_output_options and display [FORMAT_OPTIONS]
instead.
PVE::CLIFormatter - pass terminal option as separate parameter
This simplifies usage, because we can simple omit the $terminal_opts
parameter in most cases (automatically call query_terminal_option) while
still setting $options.
api dump: do not skip indexed params with only one index
We transform indexed parameters (like scsi0 scsi1 ...) to a single
scsi[n]. The check if we should transform did not handle the case
where a parameter was indexed but (currently) only index 0 existed.
Such definitions where simply skipped and seemed then to miss from
places using the API dump, like the api-viewer.
We now only skip those parameters with an index > 0 where the same
parameter with index 0 is defined.
This fixes a missing efidisk0 entry in an API dump[0].
Thomas Lamprecht [Tue, 17 Jul 2018 14:19:31 +0000 (16:19 +0200)]
cli_handler: make standard options opt-in
The new standard options overwrite some already existing options in
already existing CLI tools, which is surely no good, e.g. vzdump
already has an quiet option which now gets overwritten, thus any
backup triggered by CRON always sents out an (additional) email.
Further, they may even only have an effect if the respective CLI
command uses an CLIFormatter print* method to output things.
And for some commands, like 'pvecm status' they may even never make
sense, as they exec an external program which doesn't honors nor gets
those std options...
Also some internal commands, like 'qm mtunnel' will never use it, as
probably even "normal" commands, as it may simply not make sense for
every command..
So make it opt-in for now, any CLI command can set std-output-opts to
get them.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The previous condition didn't fail tests because it was
always false. The 'exists' property is not actually usable
when writing the interface file. It is merely a hint that
the interface existed in /proc/net/dev while parsing the
interfaces file and is otherwise actually unused here.
Simply check for the existence of the interface in $ifaces.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>