ntpd fails with default (2.6.18) kernel

A

arthurhugo

New Member
Jul 26, 2008
13
0
1
cat /var/log/syslog | grep ntp
on the machine with the default 2.6.18 kernel gives a long list of errors like these:
Jul 8 21:54:00 pm1 ntpd[31507]: kernel time sync error 0001
Jul 8 22:45:13 pm1 ntpd[31507]: kernel time sync error 0001
Jul 8 23:36:29 pm1 ntpd[31507]: kernel time sync error 0001

No such errors on a machine with the 2.6.24 kernel.
 
hi
I just realized we're haunted by this bug too.

this even escalates things as we see the corrections every few minutes and this get's ospf to freak out about it's timings...

As 2.6.18 is the only kernel-path giving us full openvz-control - what would be advised to do on this issue?

regards
hk
 
hi
I got into testing this and primary result is: openvz-2.6.18 stable kernel (ovzkernel-2.6.18-238.9.1.el5.028stab089.1) does have not problem with ntpd (ntp-4.2.2p1-9.el5.centos.2.1).
then I simply tried to downgrade ntp on proxmox to ntp_4.2.2.p4+dfsg-2etch4_amd64.deb - this didn't help so I have to conclude (without reading into the kernel-source) it's a kernel-problem (especially it arose after we went to 2.6.18 everywhere to get stable openvz in proxmox....).

Further evidence can be found at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426238 - but the fix I guess should come via proxmox as it seems fixed/no-problem in openvz-upstream.

regards
hk
 
I think this cause these error in th VM's:
# grep -i 'local clock' /var/log/mail.log.*
/var/log/mail.log.1:May 26 01:32:19 cp2 postfix/cleanup[1401]: warning: file system clock is 223 seconds behind local clock
/var/log/mail.log.1:May 28 01:21:44 cp2 postfix/cleanup[20262]: warning: file system clock is 142 seconds behind local clock
Click to expand...
 
hk@ said:
I simply tried to downgrade ntp on proxmox to ntp_4.2.2.p4+dfsg-2etch4_amd64.deb - this didn't help so I have to conclude (without reading into the kernel-source) it's a kernel-problem (especially it arose after we went to 2.6.18 everywhere to get stable openvz in proxmox....).
Click to expand...

We already use ovzkernel-2.6.18-238.9.1.el5.028stab089.1, so I doubt its a kernel problem. So maybe the problem is inside libc.
 
I tried to reproduce that bug here, but ntp works without problems. So what version do you use exactly?

# pveversion -v
 
proxmox1:~# pveversion -v
pve-manager: 1.8-17 (pve-manager/1.8/5948)
running kernel: 2.6.18-6-pve
proxmox-ve-2.6.18: 1.8-15
pve-kernel-2.6.18-6-pve: 2.6.18-15
qemu-server: 1.1-30
pve-firmware: 1.0-11
libpve-storage-perl: 1.0-17
vncterm: 0.9-2
vzctl: 3.0.26-1pve4
vzdump: 1.2-12
vzprocps: 2.0.11-2
vzquota: 3.0.11-1
pve-qemu-kvm-2.6.18: 0.9.1-15
Click to expand...

ntp works and time synced
proxmox1:~# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
+punck.cpms.ru 93.91.6.81 3 u 166 1024 377 44.044 -5.028 0.036
+jane.telecom.mi 129.69.1.153 2 u 342 1024 377 23.352 -1.977 0.528
-gw-pirogovka.mi 193.67.79.202 2 u 138 1024 377 139.846 13.928 0.579
*194.190.16.51 62.117.76.141 2 u 387 1024 377 33.681 0.864 0.554
Click to expand...

but with strange errors in the syslog
proxmox1:~# grep ntp /var/log/syslog
May 30 06:36:38 proxmox1 ntpd[8959]: kernel time sync error 0001
May 30 07:44:57 proxmox1 ntpd[8959]: kernel time sync error 0001
May 30 09:10:19 proxmox1 ntpd[8959]: kernel time sync error 0001
May 30 09:44:31 proxmox1 ntpd[8959]: kernel time sync error 0001
May 30 10:18:39 proxmox1 ntpd[8959]: kernel time sync error 0001
May 30 11:26:56 proxmox1 ntpd[8959]: kernel time sync error 0001
May 30 13:09:18 proxmox1 ntpd[8959]: kernel time sync error 0001
May 30 13:43:25 proxmox1 ntpd[8959]: kernel time sync error 0001
May 30 14:34:34 proxmox1 ntpd[8959]: kernel time sync error 0001
May 30 15:08:42 proxmox1 ntpd[8959]: kernel time sync error 0001
May 30 15:59:52 proxmox1 ntpd[8959]: kernel time sync error 0001
May 30 17:08:14 proxmox1 ntpd[8959]: kernel time sync error 0001
May 30 18:16:31 proxmox1 ntpd[8959]: kernel time sync error 0001
May 30 18:50:40 proxmox1 ntpd[8959]: kernel time sync error 0001
May 30 19:41:53 proxmox1 ntpd[8959]: kernel time sync error 0001
May 30 20:15:59 proxmox1 ntpd[8959]: kernel time sync error 0001
May 30 21:58:26 proxmox1 ntpd[8959]: kernel time sync error 0001
May 30 23:06:47 proxmox1 ntpd[8959]: kernel time sync error 0001
Click to expand...

and inside VM's for example:
proxmox1:~# vzctl enter 102
entered into CT 102
cp2:/# zgrep -i 'local clock' /var/log/mail.log.*
/var/log/mail.log.1:May 26 01:32:19 cp2 postfix/cleanup[1401]: warning: file system clock is 223 seconds behind local clock
/var/log/mail.log.1:May 28 01:21:44 cp2 postfix/cleanup[20262]: warning: file system clock is 142 seconds behind local clock
/var/log/mail.log.2.gz:May 18 01:09:03 cp2 postfix/cleanup[16049]: warning: file system clock is 267 seconds behind local clock
/var/log/mail.log.2.gz:May 18 01:25:46 cp2 postfix/cleanup[25809]: warning: file system clock is 131 seconds behind local clock
/var/log/mail.log.2.gz:May 18 01:25:46 cp2 postfix/cleanup[22930]: warning: file system clock is 184 seconds behind local clock
/var/log/mail.log.2.gz:May 19 14:13:28 cp2 postfix/cleanup[26379]: warning: file system clock is 113 seconds behind local clock
/var/log/mail.log.2.gz:May 19 14:13:28 cp2 postfix/cleanup[26380]: warning: file system clock is 113 seconds behind local clock
/var/log/mail.log.2.gz:May 19 14:57:49 cp2 postfix/cleanup[6072]: warning: file system clock is 101 seconds behind local clock
/var/log/mail.log.2.gz:May 19 20:59:09 cp2 postfix/cleanup[29856]: warning: file system clock is 108 seconds behind local clock
/var/log/mail.log.2.gz:May 19 21:22:54 cp2 postfix/cleanup[7899]: warning: file system clock is 276 seconds behind local clock
/var/log/mail.log.2.gz:May 19 23:03:15 cp2 postfix/cleanup[18188]: warning: file system clock is 200 seconds behind local clock
/var/log/mail.log.3.gz:May 10 01:12:15 cp2 postfix/cleanup[32355]: warning: file system clock is 117 seconds behind local clock
/var/log/mail.log.3.gz:May 10 03:10:18 cp2 postfix/cleanup[29037]: warning: file system clock is 218 seconds behind local clock
/var/log/mail.log.3.gz:May 10 03:53:43 cp2 postfix/cleanup[32148]: warning: file system clock is 237 seconds behind local clock
/var/log/mail.log.3.gz:May 10 04:16:20 cp2 postfix/cleanup[4628]: warning: file system clock is 161 seconds behind local clock
/var/log/mail.log.3.gz:May 10 05:06:22 cp2 postfix/cleanup[31415]: warning: file system clock is 355 seconds behind local clock
/var/log/mail.log.3.gz:May 10 05:23:47 cp2 postfix/cleanup[2522]: warning: file system clock is 1045 seconds behind local clock
/var/log/mail.log.3.gz:May 10 05:24:11 cp2 postfix/cleanup[3739]: warning: file system clock is 151 seconds behind local clock
/var/log/mail.log.3.gz:May 10 06:03:05 cp2 postfix/cleanup[7627]: warning: file system clock is 132 seconds behind local clock
/var/log/mail.log.3.gz:May 10 06:14:00 cp2 postfix/cleanup[10228]: warning: file system clock is 324 seconds behind local clock
/var/log/mail.log.3.gz:May 10 06:35:13 cp2 postfix/cleanup[11602]: warning: file system clock is 620 seconds behind local clock
/var/log/mail.log.4.gz:May 3 03:11:02 cp2 postfix/cleanup[9616]: warning: file system clock is 269 seconds behind local clock
/var/log/mail.log.4.gz:May 8 01:12:23 cp2 postfix/cleanup[29702]: warning: file system clock is 145 seconds behind local clock
Click to expand...
 
hi
we got here (eg):

~# uname -a
Linux k69 2.6.18-6-pve #1 SMP Mon May 9 13:27:11 CEST 2011 x86_64 GNU/Linux
~# pveversion -v
pve-manager: 1.8-17 (pve-manager/1.8/5948)
running kernel: 2.6.18-6-pve
proxmox-ve-2.6.18: 1.8-15
pve-kernel-2.6.32-4-pve: 2.6.32-33
pve-kernel-2.6.18-6-pve: 2.6.18-15
qemu-server: 1.1-30
pve-firmware: 1.0-11
libpve-storage-perl: 1.0-17
vncterm: 0.9-2
vzctl: 3.0.26-1pve4
vzdump: 1.2-12
vzprocps: 2.0.11-2
vzquota: 3.0.11-1
pve-qemu-kvm-2.6.18: 0.9.1-15

date
Tue May 31 01:17:02 CEST 2011
(though it is really 01:11)

any ideas?

regards
hk
 
and (sorry forgot to add) ntp reports this in syslog:


May 30 22:59:37 k69 ntpd[549771]: adjusting local clock by -299.088784s
May 30 23:07:50 k69 ntpd[549771]: adjusting local clock by 0.710150s
May 30 23:04:27 k69 ntpd[549771]: adjusting local clock by 0.886651s
May 30 23:08:12 k69 ntpd[549771]: adjusting local clock by 0.832577s
May 30 23:16:27 k69 ntpd[549771]: adjusting local clock by 0.540869s
May 30 23:20:42 k69 ntpd[549771]: adjusting local clock by 0.353764s
May 30 23:18:46 k69 ntpd[549771]: adjusting local clock by -299.715055s
May 30 23:41:24 k69 ntpd[549771]: adjusting local clock by 0.329281s
May 30 23:40:04 k69 ntpd[549771]: adjusting local clock by 0.237061s
May 31 00:51:23 k69 ntpd[549771]: adjusting local clock by 0.227311s
May 31 01:00:31 k69 ntpd[549771]: adjusting local clock by -299.551536s
May 31 00:59:12 k69 ntpd[549771]: adjusting local clock by -299.591945s
May 31 01:03:23 k69 ntpd[549771]: adjusting local clock by -299.233914s
May 31 01:11:54 k69 ntpd[549771]: adjusting local clock by 0.876948s
May 31 01:09:51 k69 ntpd[549771]: adjusting local clock by -298.950771s
May 31 01:17:29 k69 ntpd[549771]: adjusting local clock by 0.877069s
 
OK, I also get some error in the logs:

May 31 01:34:01 oahu ntpd[9151]: kernel time sync error 0001
May 31 02:42:16 oahu ntpd[9151]: kernel time sync error 0001
May 31 03:50:36 oahu ntpd[9151]: kernel time sync error 0001

But ntp sync seems to work without problems here.
 
well, I think I got a lead here:
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
cat /sys/devices/system/clocksource/clocksource0/current_clocksource

on pve-2.6.18-6 kernel gives only (for avail and therefore current): jiffies

whereas 2.6.32-4 gives:

:~# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm
:~# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

in the meantime I turned ntp off on the 2.6.18-6 system and time runs away like nuts on this one now.

the ovz-kernel also offers only jiffies as timesource (and doesn't get lost in time).

another old 2.6.24-9-pve I have running here gives:

:~# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
hpet acpi_pm jiffies tsc
:~# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
hpet

but then on the other hand 2.6.18-4-pve has also only:

:~# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
jiffies
(and available only this one too) and seems to have no timing problem anywhere.

I guess I'm back to square one...

regards
hk

PS. moved (still moving) boxes to 2.6.32-4 for this reason (though we would have loved to have full openvz support as in 2.6.18), but ospf simply gets nuts on timewarps like this.
 
Why don´t you used the ntp package suggested by Dietmar?
 
as I already tried that (post #4) I don't see much use in trying again ;)

we now have moved all VEs from those servers having the problem - we'll try to downgrade to 2.6.18-4 and then upgrade to 2.6.32-4 and report what time it is ;)

regards
hk
 
Hi again,
well here is what we gathered enduring some testing and rebooting...

exec summary: pve-2.6.32-4 and pve-2.6.18-4 kernels do work fine.
pve-kernel-2.6.18-5-pve and pve-kernel-2.6.18-6-pve give us trouble.

please don't take it as blame or whatever - we can only try and observe and maybe point the developers into the right direction, as we're definitely no kernel-devs and have no idea why those two kernels give this strange behaviour. the last two kernel docs were shortened/removed out as we hit the text-length-limit of this forum.

----------

all tests were performed on proxmox v1.8 running the proxmox-ve-2.6.18 framework and for the 2.6.32 of course the proxmox-ve-2.6.32 framework was installed.
the lenny ntp package 4.2.4p4+dfsg-8lenny3 was used.

after installing promox we downgraded to 2.6.18-6 kernel and framework and one of the puzzling things is when we do a "watch -n 5 date" we get output like this (this is the watch timestamp is accurate but the date output is wrong (and so is most of the timing in the OS)):

---------
Every 5.0s: date Sun Jun 5 19:01:36 2011

Sun Jun 5 19:06:36 CEST 2011
---------

the kernel used:
uname -a: Linux k71 2.6.18-6-pve #1 SMP Mon May 9 13:27:11 CEST 2011 x86_64 GNU/Linux

pveversion -v
pve-manager: 1.8-17 (pve-manager/1.8/5948)
running kernel: 2.6.18-6-pve
proxmox-ve-2.6.18: 1.8-15
pve-kernel-2.6.32-4-pve: 2.6.32-33
pve-kernel-2.6.18-6-pve: 2.6.18-15
qemu-server: 1.1-30
pve-firmware: 1.0-11
libpve-storage-perl: 1.0-17
vncterm: 0.9-2
vzctl: 3.0.26-1pve4
vzdump: 1.2-12
vzprocps: 2.0.11-2
vzquota: 3.0.11-1
pve-qemu-kvm-2.6.18: 0.9.1-15

we observe the bootprocess of the hardwarenode and soon it seems ntp is getting in and setting things up, but after a few minutes reports servers unreachable and takes an instant timewarp (the following line timestamped 19:05:04 was real time 18:59:04 but the clock just got kicked):

syslog for ntp:
Jun 5 18:57:44 k71 ntpd[8436]: kernel time sync status 0040
Jun 5 18:57:44 k71 ntpd[8436]: frequency initialized 59.309 PPM from /var/lib/ntp/ntp.drift
Jun 5 18:57:44 k71 ntpd[8454]: signal_no_reset: signal 17 had flags 4000000
Jun 5 18:57:46 k71 ntpd_initres[8454]: signal_no_reset: signal 14 had flags 4000000
Jun 5 18:59:04 k71 ntpd[8436]: synchronized to 91.206.8.34, stratum 2
Jun 5 18:59:04 k71 ntpd[8436]: kernel time sync status change 0001
Jun 5 19:05:04 k71 ntpd[8436]: synchronized to 94.136.3.70, stratum 2
Jun 5 19:05:10 k71 ntpd[8436]: no servers reachable
Jun 5 19:05:18 k71 ntpd[8436]: synchronized to 78.46.40.125, stratum 2

but still: ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
k70.vss.kapper. 193.171.23.163 2 u 320 64 3 0.001 -150058 149967.
ntp1.sil.at 62.112.154.21 3 u 312 64 3 0.001 -150054 149967.
*ns4.nosuchhost. 131.130.251.107 2 u 342 64 1 0.001 -150064 2.414
86.59.113.116 193.171.23.163 2 u 305 64 3 0.001 -150054 113364.
svn.mediainvent 131.130.251.107 2 u 326 64 3 0.001 -150060 149967.

then timewarp back to real time:
Jun 5 19:02:43 k71 ntpd[8436]: no servers reachable
ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
k70.vss.kapper. 193.171.23.163 2 u 50 64 37 0.154 -41.817 80183.0
ntp1.sil.at 62.112.154.21 3 u 43 64 37 0.745 -39.808 80182.3
ns4.nosuchhost. 131.130.251.107 2 u 28 64 37 21.993 -40.793 138889.
86.59.113.116 193.171.23.163 2 u 40 64 37 0.901 -40.681 126788.
svn.mediainvent 193.171.23.163 2 u 55 64 37 0.615 -42.902 80183.6

and within seconds another timewarp again five minutes into the future (feeling a bit like Max Headroom here...).

ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
k70.vss.kapper. 131.130.251.107 2 u 330 64 77 0.145 -36.949 80185.6
ntp1.sil.at 62.112.154.21 3 u 324 64 77 0.001 -150017 126729.
ns4.nosuchhost. 131.130.251.107 2 u 308 64 77 0.001 -150018 80164.9
86.59.113.116 193.171.23.163 2 u 319 64 77 0.001 -150018 80164.4
svn.mediainvent 193.171.23.163 2 u 336 64 77 0.717 -37.957 80186.2

this goes on virtually forever five-minutes-warps occur again and again - and of course time-dependent services (especially ospf used here) go nuts.

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

next we tried with 2.6.18-5 (a simple downgrade for the kernel):

the "watch -n 10 date" again gives strange results:
Every 10.0s: date Sun Jun 5 18:21:36 2011

Sun Jun 5 18:26:36 CEST 2011
(in case you wonder why this time is now before the first try it is because we have redocumented the differnt tests in more detail afterwards, so time seems to overlap, but keep in mind we're timewarping too here...)
---------------------------------------------------------------

uname -a: Linux k71 2.6.18-5-pve #1 SMP Mon Mar 28 07:05:51 CEST 2011 x86_64 GNU/Linux

pveversion -v
pve-manager: 1.8-17 (pve-manager/1.8/5948)
running kernel: 2.6.18-5-pve
proxmox-ve-2.6.18: 1.8-15
pve-kernel-2.6.32-4-pve: 2.6.32-33
pve-kernel-2.6.18-5-pve: 2.6.18-14
pve-kernel-2.6.18-6-pve: 2.6.18-15
qemu-server: 1.1-30
pve-firmware: 1.0-11
libpve-storage-perl: 1.0-17
vncterm: 0.9-2
vzctl: 3.0.26-1pve4
vzdump: 1.2-12
vzprocps: 2.0.11-2
vzquota: 3.0.11-1
pve-qemu-kvm-2.6.18: 0.9.1-15

here too strange note in syslog says after a few minutes - no servers reachable....
Jun 5 18:40:46 k71 ntpd[8422]: kernel time sync status 0040
Jun 5 18:40:47 k71 ntpd[8422]: frequency initialized 59.937 PPM from /var/lib/ntp/ntp.drift
Jun 5 18:40:47 k71 ntpd[8435]: signal_no_reset: signal 17 had flags 4000000
Jun 5 18:40:49 k71 ntpd_initres[8435]: signal_no_reset: signal 14 had flags 4000000
Jun 5 18:42:10 k71 ntpd[8422]: synchronized to 86.59.113.117, stratum 2
Jun 5 18:42:10 k71 ntpd[8422]: kernel time sync status change 0001
Jun 5 18:47:37 k71 ntpd[8422]: sendto(91.206.8.70) (fd=24): Network is unreachable
Jun 5 18:48:08 k71 ntpd[8422]: no servers reachable
Jun 5 18:48:09 k71 ntpd[8422]: synchronized to 91.206.8.70, stratum 2
Jun 5 18:45:51 k71 ntpd[8422]: synchronized to 78.41.115.242, stratum 2
Jun 5 18:46:03 k71 ntpd[8422]: no servers reachable


kind of confirmed:
ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
k70.vss.kapper. 131.130.251.107 2 u 27 64 377 0.001 -150024 98181.0
91.206.8.70 193.171.23.163 2 u 62 64 177 0.001 -150024 80168.5
pils.linux-kern 129.132.2.21 3 u 31 64 377 0.001 -150025 113371.
86.59.113.117 193.171.23.163 2 u 29 64 377 0.001 -150024 113371.
boxi.trexler.at 193.171.23.163 2 u 47 64 177 0.001 -150000 80167.8

after a while we get
ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
k70.vss.kapper. 193.171.23.163 2 u 6 64 377 0.156 -47.725 113372.
91.206.8.70 193.171.23.163 2 u 42 64 377 0.877 -46.976 113375.
pils.linux-kern 129.132.2.21 3 u 11 64 377 1.511 -48.431 98183.8
86.59.113.117 193.171.23.163 2 u 10 64 377 1.910 -47.701 98184.1
boxi.trexler.at 193.171.23.163 2 u 29 64 377 2.078 -17.470 113381.

then we get another 5 minute timewarp and we see:
ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
94.136.3.70 193.171.23.163 2 u 307 64 377 0.001 -150032 113380.
91.206.8.70 193.171.23.163 2 u 343 64 377 0.641 -49.776 98182.7
213.129.242.82 129.132.2.21 3 u 376 64 376 1.511 -48.431 98183.8
86.59.113.117 193.171.23.163 2 u 375 64 376 1.910 -47.701 98184.1
78.41.115.242 193.171.23.163 2 u 330 64 377 0.817 -18.200 98188.3

in the syslog we get added:
Jun 5 18:57:47 k71 ntpd[8422]: sendto(86.59.1dto(78.41.115.242) (fd=24): Network is unreachable
Jun 5 18:58:50 k71 ntpd[8422]: sendto(86.59.113.117) (fd=24): Network is unreachable
Jun 5 18:58:54 k71 ntpd[8422]: sendto(213.129.242.82) (fd=24): Network is unreachable

and of course ospf goes nuts.

------------------------------------------------------------------------------------------

then we go back to where it last worked for us on old systems - 2.6.18-4 and yes, "watch -n 10 date" gets consistent:
Every 10.0s: date Sun Jun 5 18:32:03 2011

Sun Jun 5 18:32:03 CEST 2011
------------------------------------------------------------------------------------

here things go fine (and the previous timeerror gets corrected):
Jun 5 18:34:13 k71 ntpd[8403]: signal_no_reset: signal 17 had flags 4000000
Jun 5 18:34:15 k71 ntpd_initres[8403]: signal_no_reset: signal 14 had flags 4000000
Jun 5 18:30:40 k71 ntpd[8390]: synchronized to 86.59.113.115, stratum 2
Jun 5 18:30:40 k71 ntpd[8390]: time reset -300.036970 s
Jun 5 18:30:40 k71 ntpd[8390]: kernel time sync status change 0001
Jun 5 18:30:49 k71 ntpd[8390]: synchronized to 86.59.113.114, stratum 2

regards,
hk
 
hk@ said:
please don't take it as blame or whatever - we can only try and observe and maybe point the developers into the right direction, as we're definitely no kernel-devs and have no idea why those two kernels give this strange behaviour. the last two kernel docs were shortened/removed out as we hit the text-length-limit of this forum.
Click to expand...

It is a error in the ntp kernel code. I already posted the link to the bug report. I think that nobody will fix that bug (read the bug report), so the only option is to use the old ntpd package.
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back