> what I'm 100% sure, it that the watchdog have reboot all the servers. (I have
> watchdog trace in ipmi)
So you are using ipmi hardware watchdog?
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinf
> >>So you are using ipmi hardware watchdog?
>
> yes, I'm using dell idrac ipmi card watchdog
But the pve logs look ok, and there is no indication
that we stopped updating the watchdog. So why did the
watchdog trigger? Maybe an IPMI bug?
___
pve-devel
> Sep 3 10:40:51 m6kvm7 pve-ha-lrm[16140]: loop take too long (87 seconds)
> Sep 3 10:40:51 m6kvm7 pve-ha-crm[16196]: loop take too long (92 seconds)
Indeed, this should not happen. Do you use a spearate network for corosync? Or
was there high traffic on the network? What kind of maintenance was
> On 09/06/2020 2:14 PM dietmar wrote:
>
>
> > Sep 3 10:40:51 m6kvm7 pve-ha-lrm[16140]: loop take too long (87 seconds)
> > Sep 3 10:40:51 m6kvm7 pve-ha-crm[16196]: loop take too long (92 seconds)
>
> Indeed, this should not happen. Do you use a spearate network f
node {
> name: m6kvm6
> nodeid: 6
> quorum_votes: 1
> ring0_addr: m6kvm6
> }
> node {
> name: m6kvm7
> nodeid: 7
> quorum_votes: 1
> ring0_addr: m6kvm7
> }
>
> node {
> name: m6kvm8
> nodeid: 8
> quor
> I don't known too much how locks are working in pmxcfs, but when a corosync
> member leave or join, and a new cluster memership is formed, could we have
> some lock lost or hang ?
It would really help if we can reproduce the bug somehow. Do you have and idea
how
to trigger the bug?
> Now, that logging work, I'm also seeeing pmxcfs errors when corosync is
> stopping.
> (But no pmxcfs shutdown log)
>
> Do you think it's possible to have a clean shutdown of pmxcfs first, before
> stopping corosync ?
This is by intention - we do not want to stop pmxcfs only because coorosync
> I ask the question, because the 2 times I have problem, it was when shutting
> down a server.
> So maybe some strange behaviour occur with both corosync && pmxcfs are
> stopped at same time ?
pmxcfs cannot send anything in that case, so it is impossible that this has
effects on other nodes.
> This patch series adds support for a new notification endpoint type,
> smtp. As the name suggests, this new endpoint allows PVE to talk
> to SMTP server directly, without using the system's MTA (postfix).
Isn't this totally unreliable? What if the server responds with a
temporary error code? (A
> On 11/8/23 16:52, Dietmar Maurer wrote:
> >> This patch series adds support for a new notification endpoint type,
> >> smtp. As the name suggests, this new endpoint allows PVE to talk
> >> to SMTP server directly, without using the system's MTA (postfix).
>
> > As a compromise, maybe we could just add a note to the docs
> > that discusses the reliability aspects of 'sendmail' vs 'smtp'
> > endpoints?
> >
>
> Sure, for now adding a general hint to the documentation that they are
> send one-shot only would be good.
Ok for me.
__
Do you also plan to fix those typos in the translation files?
Else we need to re-tralstale them for all languages!
> On 24.11.2023 15:58 CET Maximiliano Sandoval wrote:
>
>
> It would be preferable to use "won't" but I would rather err on the safe
> side when it comes to escapes in gettext.
>
> The string `proxmox.Utils.defaultText + ' (free)'` was inlined as
> `Default (Free)` cutting translatable strings makes them harder or even
> impossible to translate in certain languages.
Well, this also duplicates the number of things to translate!
So what languages are the problem exactly? Pl
To be more clear, I would use:
proxmox.Utils.defaultText + ' (' + gettext('Free') + ')'
> On 28.11.2023 15:39 CET Dietmar Maurer wrote:
>
>
> > The string `proxmox.Utils.defaultText + ' (free)'` was inlined as
> > `Default (
> I'm taking on a lot of contributions to translations and the common complaint
> I hear is that not all can be translated correctly due to such tricks (or just
> missing gettext), most translators care much more about a correct translation
> than some over-optimized ones than then break depending
; Am 28/11/2023 um 15:46 schrieb Dietmar Maurer:
> > To be more clear, I would use:
> >
> > proxmox.Utils.defaultText + ' (' + gettext('Free') + ')'
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> Do note the following examples:
>
> #: pve-manager/www/manager6/qemu/IPConfigEdit.js:97
> #: pve-manager/www/manager6/qemu/IPConfigEdit.js:155
> msgid "DHCP"
> msgstr "بروتوكول التهيئة الآلية للمضيفين (DHCP)"
>
> #: pve-manager/www/manager6/qemu/IPConfigEdit.js:163
> ms
Stupid question: Wouldn't It be much easier to add a simple IO-buffer
with limited capacity, implemented inside the RUST backup code?
> +WARNING: Theoretically, the fleecing image can grow to the same size as the
> +original image, e.g. if the guest re-writes a whole disk while the backup is
> +b
> >>Stupid question: Wouldn't It be much easier to add a simple IO-buffer
> >>with limited capacity, implemented inside the RUST backup code?
>
> At work, we are running a backup cluster on remote location with hdd ,
> and a production cluster with super fast nvme,
> and sometimes I have really b
> The information gathered by the API call comes from the systemd
> journal. While 'Syslog' could be interpreted as a shorthand for
> "System Log", it's better to be explicit to avoid any confusion.
> - title: 'Syslog',
> + title: gettext('System Log'),
From Wikipedia: htt
I can also imaging using "Events" instead of "Syslog".
- title: 'Syslog',
+ title: gettext('Events'),
IMHO this is easier to translate.
> With your change:
>
> - title: 'Syslog',
> + title: gettext('System Log'),
>
> we now need to translate
> while I don't mind (at all!) that that part of the UI/API is labelled syslog
> (I don't think it's hard to understand that it gives you the system logs of
> that node, and "syslog" is a bit like "Kleenex" in that regard ;)) - I do
> have to disagree here ;) journald does a lot more than just c
> On 29.2.2024 16:09 CET Roland Kammerer via pve-devel
> wrote:
> All in all, yes, this is specific for our use case, otherwise
> parse_volname would already have that additional parameter as all the
> other plugin functions, but I don't see where this would hurt existing
> code, and it certain
Because AccountData is exposed via our API (currently as type Object).
Signed-off-by: Dietmar Maurer
---
proxmox-acme/Cargo.toml | 3 +++
proxmox-acme/src/account.rs | 7 +++
proxmox-acme/src/eab.rs | 5 +
3 files changed, 15 insertions(+)
diff --git a/proxmox-acme/Cargo.toml b
Signed-off-by: Dietmar Maurer
---
proxmox-acme/src/account.rs | 2 +-
proxmox-acme/src/eab.rs | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/proxmox-acme/src/account.rs b/proxmox-acme/src/account.rs
index e244c09..7f00143 100644
--- a/proxmox-acme/src/account.rs
+++ b
> On 02/24/2022 3:49 PM Stefan Sterz wrote:
>
>
> To be consistent with PBS's implementation of multi-line comments
> remove "\s*" here too. Since the regex isn't lazy .* matches
> everything \s* would anyway.
But the old regex trimm spaces from the end, so this is quite different!
___
> let response = if let Method::POST = request.method {
> -req.send(&*request.body)
> +let bytes = request.body.as_slice();
> +req.send_bytes(bytes)
Does this have the side effect of changing the transfer encoding? If so, it is
worth to add an inline comment.
Live migration works?
> +Limitations:
> +
> +* Memory usage on host is always wrong and around 82% Usage
> +* Snapshots do not work
> +* edk2-OVMF required
> +* Recommendable: VirtIO RNG for more entropy (VMs sometimes will not
___
pve-devel mailing li
in qemu-server, I wonder why we set $ENV{LC_PVE_TICKET} conditionally? Does not
make any sense to me, because it make all other connection failing...
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index 99b426e..c6a3ac1 100644
--- a/PVE/API2/Qemu.pm
+++ b/PVE/API2/Qemu.pm
@@ -2102,7 +2102,7 @@
> addendum:
>
> 'it doesn't do anything here' is not completely correct
> for 'regular' vm displays it just does not set the ticket which
> breaks the connection
I think this ("break the connection") is important, because otherwise it would
allow unecrypted VNC traffic over the network. I guess
> This is really a blocker for me,I can't use pbs because I'm using nvme
> is production, and a 7200k hdd backup in a remote 200km site with 5ms
> latency.
Why don't you use a local(fast) PBS instance, then sync to the slow remote?
___
pve-devel mail
> Can I use a small local fast PBS instance without need to keep the full
> datastore chunks ?
>
> I have 300TB nvme in production, I don't want to buy 300TB nvme for backup.
no, sorry.
Do you want to use Ceph as temp backup storage, or simply an additional (node
local) nvme?
___
> One could argue that the case for not existent should return undef,
> while an empty file should return an empty string, but for that we
> might want to check all use-sites first.
AFAIR I use this function many times assuming that it does not throw errors in
case of empty files. That is quite c
> One of our users ran into issues with running Ceph on older CPU
> architectures [1]. This is apparently due to a bug in gcc-12 that
> leads to SSE 4.1 instructions always being executed rather than
> dynamically dispatching functions using those instructions.
Cant we fix the GCC bug instead?
_
Remove ureq, because it does not support unix sockets.
Signed-off-by: Dietmar Maurer
---
termproxy/Cargo.toml | 2 +-
termproxy/src/cli.rs | 29 +
termproxy/src/main.rs | 59 +--
3 files changed, 71 insertions(+), 19 deletions
Remove ureq, because it does not support unix sockets.
Signed-off-by: Dietmar Maurer
---
Changes since v1:
- use extra --authsocket cli option
- use single format!() instead of multiple push_str()
- cleanup variable names
termproxy/Cargo.toml | 2 +-
termproxy/src/cli.rs | 26
The need to be the first argument.
Signed-off-by: Dietmar Maurer
---
termproxy/src/cli.rs | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/termproxy/src/cli.rs b/termproxy/src/cli.rs
index cc44655..adfd830 100644
--- a/termproxy/src/cli.rs
+++ b/termproxy/src/cli.rs
@@ -4,7
Remove ureq, because it does not support unix sockets.
Signed-off-by: Dietmar Maurer
---
Changes sinve v2:
split out the command line help text change into patch:
[PATCH pve-xtermjs] termproxy: fix the command line help text
Changes since v1:
- use extra --authsocket cli option
- use
> Would adding support for offloading incremental difference detection
> to the underlying storage be feasible with the API updates? The QEMU
> bitmap strategy works for all storage devices but is far from
> optimal.
Sorry, but why do you think this is far from optimal?
_
> Today, I believe the client is reading the data and pushing it to
> PBS. In the case of CEPH, wouldn't this involve sourcing data from
> multiple nodes and then sending it to PBS? Wouldn't it be more
> efficient for PBS to read it directly from storage? In the case of
> centralized storage, we'd
> The biggest issue we see reported related to QEMU bitmaps is
> persistence. The lack of durability results in unpredictable backup
> behavior at scale. If a host, rack, or data center loses power, you're
> in for a full backup cycle. Even if several VMs are powered off for
> some reason, it can
> In hyper-converged deployments, the node performing the backup is sourcing
> ((nodes-1)/(nodes))*bytes) of backup data (i.e., ingress traffic) and then
> sending 1*bytes to PBS (i.e., egress traffic). If PBS were to pull the data
> from the nodes directly, the maximum load on any one host woul
> Hello, i wan't to make a patch for proxmox to implements DRBD, in a
> different way that LINSTOR do. I want to discuss about its usefulness
> and implementation with the community.
I think you should discuss that with the DRBD people (LINSTOR).
But I am not sure they are on this list.
__
:api::api`
> --> src/api/api_type_macros.rs:6:5
> |
> 4 | use proxmox::api::api;
> | ^ no `api` in `api`
Sorry, this was a bug in the proxmox crate. Please update an test again:
commit fa3b5374ed61da3c40a1fc58070d6a16c877c3af (HEAD -> master, origin/master,
origin/
Hi Julien,
> Hello to all.
>
> I have the plan to implement the SSO authentication feature with the SAML
> protocol.
> However, I have an error that prevents me from validating the authentication
> process.
> It is about the locks.
> The first step is to store the request_saml_id. If I try to
I am trying to test your code, so I need a SAML Identity provider. What is
the best OSS implementation for that?
I tried lemonldap-ng, but there example configuration is a nightmare and
I was unable to get that running. Is there anything else I can use to test?.
- Dietmar
I wonder why you want to store temporary data in /etc/pve/tmp/saml. Wouldn't it
we good enough
to store that on the local file system?
> On 05/27/2021 11:55 PM Julien BLAIS wrote:
>
>
> Added a new endpoint usable by api2/html/access/saml?realm=$DOM
> which allows to initiate a redirection
Unfortunately, your code depends on code not packaged for Debian. Any idea
how to replace that (cpanm Net::SAML2)?
Or better, is there a 'rust' implementaion for SAML2? If so, we could make perl
bindings
for that and reuse the code with Proxmox Backup Server.
Other ideas?
> diff --git a/src/PV
> > I wonder why you want to store temporary data in /etc/pve/tmp/saml.
> > Wouldn't it we good enough
> > to store that on the local file system?
> On the one hand, I enjoyed reusing your work.
> On the other hand, I think it is more secure to put this kind of data in
> /etc/pve/tmp/saml than in
> On 06/02/2021 12:16 PM wb wrote:
>
>
> > I also wonder why SAML? Would it be an option to use OpenId connect instead?
> As I was able to use SAML, I know the functional part and therefore, if I
> used SAML, it is only by ease.
>
> Switch to OpenID, why not. The time I set up a functional P
---
src/PVE/API2/OpenId.pm | 33 ++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/src/PVE/API2/OpenId.pm b/src/PVE/API2/OpenId.pm
index db9f9eb..3814895 100644
--- a/src/PVE/API2/OpenId.pm
+++ b/src/PVE/API2/OpenId.pm
@@ -9,9 +9,10 @@ use PVE::RS::Op
---
PVE/HTTPServer.pm | 4 +-
www/manager6/Utils.js | 8 +++
www/manager6/window/LoginWindow.js | 105 -
3 files changed, 114 insertions(+), 3 deletions(-)
diff --git a/PVE/HTTPServer.pm b/PVE/HTTPServer.pm
index 636b562b..dabdf7f3 100
---
debian/control | 2 ++
1 file changed, 2 insertions(+)
diff --git a/debian/control b/debian/control
index 81a32bd..3ef748b 100644
--- a/debian/control
+++ b/debian/control
@@ -10,6 +10,7 @@ Build-Depends: debhelper (>= 12~),
lintian,
perl,
libpv
---
src/PVE/AccessControl.pm | 2 ++
src/PVE/Auth/Makefile| 3 +-
src/PVE/Auth/OpenId.pm | 67
3 files changed, 71 insertions(+), 1 deletion(-)
create mode 100755 src/PVE/Auth/OpenId.pm
diff --git a/src/PVE/AccessControl.pm b/src/PVE/AccessControl
This moves compute_api_permission() into RPCEnvironment.pm.
---
src/PVE/API2/AccessControl.pm | 60 ++
src/PVE/API2/Makefile | 3 +-
src/PVE/API2/OpenId.pm| 214 ++
src/PVE/RPCEnvironment.pm | 49
4 files changed, 273 inserti
---
src/PVE/AccessControl.pm | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/src/PVE/AccessControl.pm b/src/PVE/AccessControl.pm
index 2569a35..8628678 100644
--- a/src/PVE/AccessControl.pm
+++ b/src/PVE/AccessControl.pm
@@ -428,12 +428,10 @@ sub verify_token {
---
debian/control | 2 ++
1 file changed, 2 insertions(+)
diff --git a/debian/control b/debian/control
index 81a32bd..3ef748b 100644
--- a/debian/control
+++ b/debian/control
@@ -10,6 +10,7 @@ Build-Depends: debhelper (>= 12~),
lintian,
perl,
libpv
Changes in v2:
- also check if user is expired (in check_user_enabled)
- always die with newline
- rename "user-attr" to "username-claim"
Dietmar Maurer (5):
check_user_enabled: also check if user is expired
add OpenId configuration
depend on libpve-rs-perl
api:
---
src/PVE/AccessControl.pm | 2 ++
src/PVE/Auth/Makefile| 3 +-
src/PVE/Auth/OpenId.pm | 68
3 files changed, 72 insertions(+), 1 deletion(-)
create mode 100755 src/PVE/Auth/OpenId.pm
diff --git a/src/PVE/AccessControl.pm b/src/PVE/AccessControl
---
src/PVE/API2/OpenId.pm | 35 +++
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/src/PVE/API2/OpenId.pm b/src/PVE/API2/OpenId.pm
index d0b29fc..8384729 100644
--- a/src/PVE/API2/OpenId.pm
+++ b/src/PVE/API2/OpenId.pm
@@ -9,9 +9,10 @@ use PVE::RS::
This moves compute_api_permission() into RPCEnvironment.pm.
---
src/PVE/API2/AccessControl.pm | 60 ++
src/PVE/API2/Makefile | 3 +-
src/PVE/API2/OpenId.pm| 211 ++
src/PVE/RPCEnvironment.pm | 49
4 files changed, 270 inserti
---
pveum.adoc | 88 +-
1 file changed, 87 insertions(+), 1 deletion(-)
diff --git a/pveum.adoc b/pveum.adoc
index a1adbaa..9329583 100644
--- a/pveum.adoc
+++ b/pveum.adoc
@@ -29,7 +29,7 @@ endif::manvolnum[]
Proxmox VE supports multiple aut
Isn't it easy enough to edit a po file?
I am not particularly keen to setup and maintain another tool/service.
> On 08/18/2021 12:46 PM Claudio Ferreira wrote:
>
>
> Hi for all
>
> My name is Claudio and I did some translations for many open source
> projects, and I want to help in ProxMox f
> I don't know where to find the PVE::RESTHandler module.
Any (working) PVE installation should have that installed...
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Signed-off-by: Dietmar Maurer
---
Cargo.toml | 15 +++
src/backup.rs | 11 +++
src/commands.rs | 15 +--
src/lib.rs | 11 ++-
src/restore.rs | 13 ++---
src/shared_cache.rs | 2 +-
src/upload_queue.rs | 6
> However, is there any support for groups in OpenID Connect, or a similar
> concept?
In OpenID, it is possible to request "scopes" from the server, which can then
send additional data (claims).
But I am unsure if and how people use those system to manage groups. So what
kind of OpenID server
> This endpoint here would be Google Workspace (i.e. Google's OIDC provider).
>
> Currently, in the Proxmox LDAP sync - it translates Google Groups (in the
> Google Workspace domain) into LDAP groups, which is what we want.
>
> I'm not too familiar with the OIDC - I do know that Google Workspace
> Currently both are at 80%,
> that mean that ballooning is vm reducing memory fast, and ksm don't
> have time to run.
>
> as ballooning is a lot more intrusive than ksm, I wonder if it couldn't
> be set to something like 90%.
That sounds reasonable to me, but can you see that theoretical effect
> So how can I get it to build also mips/mipsel qemu-system image?
> That to me did not really tell me how it's disabled but what would be
> needed so I can build the support?
We do not support MIPS, so you need to find out yourself what is required.
applied, thanks!
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> Could you guys tell me how the status of qemu COLO feature regarding
> Proxmox VE?
> Is there any plan for this?
No plans for now ...
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-deve
> For me, I have that need too for a firewall container.
Why does your firewall need more the 10 interface?
> Would you please consider raising the limit?
No, unless someone can explain why that is required ;-)
___
pve-devel mailing list
pve-devel@l
> > For me, I have that need too for a firewall container.
>
> Why does your firewall need more the 10 interface?
Sigh. too early in the morning... I wanted to ask:
Why does your firewall need more than 10 interfaces?
Normally, a firewall uses one interface per zone, and more
than 10 zones ar
> If it would be possible to provide a 'trunk' openvswitch interface to
> the CT, then from within the CT vlan devices could be setup from the
> trunk, but in the end that will still create 10+ interfaces in the
> container itself.
Cant you simply use a single network interface, then configure
> If I don't put a tag on the device, it seems to behave like a trunk. So,
> that would solve my problem. _If_ the hosts where openvswitch enabled.
I am unable to see why you need openvswitch for that? This also works with
standard linux network.
___
> On 08/24/2020 12:54 PM Stephan Leemburg wrote:
>
>
> On 24-08-2020 06:53, Dietmar Maurer wrote:
> >> If I don't put a tag on the device, it seems to behave like a trunk. So,
> >> that would solve my problem. _If_ the hosts where openvswitch enabled.
> If we run out of passed arguments from the user but still had defined
> "arg_params" (those params which went after the command in fixed
> order without option -- dashes) we always errored out with "not
> enough arguments". But, there are situations where the remaining
> arg_params are all mark
> do you think it could be possible to add an extra optionnal layer of security
> check, not related to corosync ?
I would try to find the bug instead.
> I'm still afraid of this corosync bug since years, and still don't use HA.
> (or I have tried to enable it 2months ago,and this give me a dis
depend on proxmox 0.3.7
---
Cargo.toml | 3 +-
examples/download-speed.rs | 4 +-
examples/upload-speed.rs | 2 +-
src/api2/admin/datastore.rs| 28 ++---
src/api2/backup.rs | 2 +-
sr
> I wonder if something like pacemaker sbd could be implemented in proxmox as
> extra layer of protection ?
AFAIK Thomas already has patches to implement active fencing.
But IMHO this will not solve the corosync problems..
___
pve-devel mailing list
- remove chrono dependency
- depend on proxmox 0.3.8
- remove epoch_now, epoch_now_u64 and epoch_now_f64
- remove tm_editor (moved to proxmox crate)
- use new helpers from proxmox 0.3.8
* epoch_i64 and epoch_f64
* parse_rfc3339
* epoch_to_rfc3339_utc
* strftime_local
- BackupDir change
applied
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
applied
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
I wonder if we want to store that information with RRD instead?
> On 10/06/2020 1:58 PM Alexandre Derumier wrote:
>
>
> Signed-off-by: Alexandre Derumier
> ---
> PVE/Service/pvestatd.pm | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/PVE/Service/pvestatd.pm b/PVE/Service/pvesta
> I have notice that it's possible to get pressure info for each vm/ct
> through cgroups
>
> /sys/fs/cgroup/unified/qemu.slice/.scope/cpu.pressure
> /sys/fs/cgroup/unified/lxc//cpu.pressure
>
>
> Maybe it could be great to have some new rrd graphs for each vm/ct ?
> They are very useful counters
> BTW, I'm currently playing with reading the rrd files, and I have notice than
> lower precision is 1minute.
> as pvestatd send values around each 10s, is this 1minute precision an average
> of 6x10s values send by pvestatd ?
Yes (we also store the MAX)
> I'm currently working on a poc of vm b
---
src/window/TaskViewer.js | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/window/TaskViewer.js b/src/window/TaskViewer.js
index 0333472..31e1ebc 100644
--- a/src/window/TaskViewer.js
+++ b/src/window/TaskViewer.js
@@ -14,7 +14,7 @@ Ext.define('Proxmox.window.Task
> I would like also to add some improvement for vm memory/cpu stats.
>
> for cpu, currently, we only monitor the qemu process cpu usage, but
> with virtio-net + vhost-net,
> we are missing vhost-* process cpu usage. (For vms will a lot of
> traffic, this is really signifiant).
>
> I would like t
---
based, on Domink's patch, but with the following changes:
- factor out code into separate function accept_connections()
- no select with shutdown future (no needed)
- remove sender2.send_timeout() - not sure why this was there?
- restict number of spawned tasks
Seems to work, but I get
> > -let connections =
> > proxmox_backup::tools::async_io::HyperAccept(connections);
> > +let connections = accept_connections(listener, acceptor);
> > +let connections =
> > hyper::server::accept::from_stream(connections);
>
> If we move the `from_stream` in
> On Tue, Nov 03, 2020 at 02:25:21PM +0100, Dietmar Maurer wrote:
> > > > -let connections =
> > > > proxmox_backup::tools::async_io::HyperAccept(connections);
> > > > +let connections = accept_connections(listener, acceptor
> > +Ok((sock, _addr)) => {
> > +sock.set_nodelay(true).unwrap();
> > +let _ = set_tcp_keepalive(sock.as_raw_fd(),
> > PROXMOX_BACKUP_TCP_KEEPALIVE_TIME);
> > +let acceptor = Arc::clone(&acceptor);
> > +
Answering myself, this works as expected.
I now simply use Arc::new(()) to count references.
> On 11/03/2020 6:45 PM Dietmar Maurer wrote:
>
>
> > > +Ok((sock, _addr)) => {
> > > +sock.set_nodelay(true).unwrap();
applied
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> Container backup is very slow compared to VM backup. I have a 500 GB
> container (sftp server) with minimal changing files, but even the incremental
> bakcups take 2 hours with heavy disk activity. Almost nothing is transfered
> to the backup server. It seems that it it reads the whole conta
applied
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> proxmox-backup-qemu is missing a not-pushed version bump commit, otherwise
> I'd have applied this.
sorry, just pushed the missing commit.
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-
applied (and built a new proxmox-backup-qemu package)
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
What kind of format is that? RFC2373 does not mention it. Please can
you give me a hint?
> On 11/25/2020 11:36 AM Wolfgang Bumiller wrote:
>
>
> Signed-off-by: Wolfgang Bumiller
> ---
> changes to v2:
> * use `for of` loop in verify_ip64_address_list
>
> www/manager6/Toolkit.js | 17 ++
Answering myself, it is defined in RFC4007.
But "man resolv.conf" say address must be RFC2373 ?
> On 11/25/2020 12:08 PM Dietmar Maurer wrote:
>
>
> What kind of format is that? RFC2373 does not mention it. Please ca
1 - 100 of 121 matches
Mail list logo
