Proxmox connection failure network error or proxmox ve services not running

I have already reinstall ProxmoxVE 6.3(clean way: format the disk and install), BUT Now I can't access the GUI webpage. It says "Connection failure. Network error or Proxmox VE services not running?".But VMs are still working. I can access logging through SSH. --------- update: problem solved...

  • #1

I have already reinstall ProxmoxVE 6.3(clean way: format the disk and install), BUT Now I can’t access the GUI webpage. It says «Connection failure. Network error or Proxmox VE services not running?».But VMs are still working. I can access logging through SSH.
———
update:
problem solved.
here is the code

Last edited: Dec 22, 2020

oguz

oguz

Proxmox Retired Staff

Retired Staff

Nov 19, 2018

5,207

708

118


  • #2

hi,

does systemctl restart pveproxy pvedaemon fix the problem?

  • #3

problem solved.
here is the code
pvecm updatecerts

  • #4

hi,

does systemctl restart pveproxy pvedaemon fix the problem?

This command solved my problem with

Connection failure. Network error or Proxmox VE services not running?

The VMs were working, the server was dripping, but the admin interface was not working.

  • #1

Hi, after rebooting my main node I’ve been unable to login to the webui, i get «Network error or Proxmox VE services not running?». I’ve checked other threads here and have followed them to no avail. My setup consists of two nodes. I can login to the secondary node, but nothing shows and i get «Connection error 401: permission denied — invalid PVE ticket» Following other threads i’ve tried systemctl restart pveproxy pvedaemon and it did nothing, pvecm updatecerts but it returns with «got timeout».

my pvedaemon status looks fine.

Code:

● pvedaemon.service - PVE API Daemon
   Loaded: loaded (/lib/systemd/system/pvedaemon.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2021-05-28 02:49:06 CDT; 3min 18s ago
  Process: 5227 ExecStart=/usr/bin/pvedaemon start (code=exited, status=0/SUCCESS)
 Main PID: 5229 (pvedaemon)
    Tasks: 4 (limit: 4915)
   Memory: 135.4M
   CGroup: /system.slice/pvedaemon.service
           ├─5229 pvedaemon
           ├─5230 pvedaemon worker
           ├─5231 pvedaemon worker
           └─5232 pvedaemon worker

May 28 02:49:06 nexus systemd[1]: Starting PVE API Daemon...
May 28 02:49:06 nexus pvedaemon[5229]: starting server
May 28 02:49:06 nexus pvedaemon[5229]: starting 3 worker(s)
May 28 02:49:06 nexus pvedaemon[5229]: worker 5230 started
May 28 02:49:06 nexus pvedaemon[5229]: worker 5231 started
May 28 02:49:06 nexus pvedaemon[5229]: worker 5232 started
May 28 02:49:06 nexus systemd[1]: Started PVE API Daemon.

pvecm status looks good to my knowledge

Code:

Cluster information
-------------------
Name:             Home
Config Version:   7
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Fri May 28 02:53:10 2021
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          0x00000001
Ring ID:          1.3694
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      2
Quorum:           2
Flags:            Quorate

Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 10.0.0.135 (local)
0x00000002          1 10.0.0.134

I’ve check journalctl and I do see an error that might be causing the issue but I honestly have no clue what to do.

Code:

May 28 02:35:41 nexus kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
May 28 02:35:41 nexus kernel:       Tainted: P           O      5.4.114-1-pve #1
May 28 02:35:41 nexus kernel: INFO: task pvedaemon:2246 blocked for more than 120 seconds.
May 28 02:35:41 nexus kernel: R13: 000055de6de61230 R14: 000055de6ddfd388 R15: 00000000000001ff
May 28 02:35:41 nexus kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 000055de6b0cea98
May 28 02:35:41 nexus kernel: RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000006
May 28 02:35:41 nexus kernel: RDX: 000055de684bd3d4 RSI: 00000000000001ff RDI: 000055de6de61230
May 28 02:35:41 nexus kernel: RAX: ffffffffffffffda RBX: 000055de69c85260 RCX: 00007f76782740d7
May 28 02:35:41 nexus kernel: RSP: 002b:00007ffdba2c1288 EFLAGS: 00000246 ORIG_RAX: 0000000000000053
May 28 02:35:41 nexus kernel: Code: Bad RIP value.
May 28 02:35:41 nexus kernel: RIP: 0033:0x7f76782740d7
May 28 02:35:41 nexus kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xa9
May 28 02:35:41 nexus kernel:  do_syscall_64+0x57/0x190
May 28 02:35:41 nexus kernel:  __x64_sys_mkdir+0x1b/0x20
May 28 02:35:41 nexus kernel:  do_mkdirat+0x59/0x110
May 28 02:35:41 nexus kernel:  filename_create+0x8e/0x180
May 28 02:35:41 nexus kernel:  down_write+0x3d/0x40
May 28 02:35:41 nexus kernel:  rwsem_down_write_slowpath+0x2ed/0x4a0
May 28 02:35:41 nexus kernel:  schedule+0x33/0xa0
May 28 02:35:41 nexus kernel:  ? filename_parentat.isra.55.part.56+0xf7/0x180
May 28 02:35:41 nexus kernel:  __schedule+0x2e6/0x700
May 28 02:35:41 nexus kernel: Call Trace:
May 28 02:35:41 nexus kernel: pvesr           D    0  2007      1 0x00000000

I’m currently running pve-manager/6.4-6/be2fa32c (running kernel: 5.4.114-1-pve)

Thanks, in advanced for any help, I’m unsure what to do.

Stoiko Ivanov


  • #2

* Make sure that the system-time is in sync between both nodes (e.g. by installing chrony)
* let `journalctl -f` run in one shell then
* try restarting corosync and pve-cluster (`systemctl restart corosync pve-cluster`
* afterwards restart pvedaemon and pveproxy
* then check the journal output (this should give a more complete picture)

I hope this helps!

  • #3

Hi, unfortunately syncing the system time didn’t work. Journalctl -f shows some errors which I attached below, but eventually it seems to sort itself out and everything starts. I did find some «no quorum» errors but right after it would say «[status] notice: node has quorum». I did however notice that pvesr had failed to start while checking the logs. systemd show it started but im not sure if this is what its supposed to look like

Code:

root@nexus ~# systemctl status pvesr
● pvesr.service - Proxmox VE replication runner
   Loaded: loaded (/lib/systemd/system/pvesr.service; static; vendor preset: enabled)
   Active: activating (start) since Fri 2021-05-28 12:48:23 CDT; 9min ago
 Main PID: 73510 (pvesr)
    Tasks: 1 (limit: 4915)
   Memory: 77.7M
   CGroup: /system.slice/pvesr.service
           └─73510 /usr/bin/perl -T /usr/bin/pvesr run --mail 1

May 28 12:48:23 nexus systemd[1]: Starting Proxmox VE replication runner...
May 28 12:48:23 nexus pvesr[73510]: trying to acquire cfs lock 'file-replication_cfg' ...
May 28 12:48:24 nexus pvesr[73510]: trying to acquire cfs lock 'file-replication_cfg' ...
May 28 12:48:25 nexus pvesr[73510]: trying to acquire cfs lock 'file-replication_cfg' ...
May 28 12:48:26 nexus pvesr[73510]: trying to acquire cfs lock 'file-replication_cfg' ...
May 28 12:48:27 nexus pvesr[73510]: trying to acquire cfs lock 'file-replication_cfg' ...

Journalctl -f

Code:

May 28 12:48:18 nexus systemd[1]: Stopping Corosync Cluster Engine...
May 28 12:48:18 nexus corosync-cfgtool[73474]: Shutting down corosync
May 28 12:48:18 nexus corosync[72132]:   [MAIN  ] Node was shut down by a signal
May 28 12:48:18 nexus corosync[72132]:   [SERV  ] Unloading all Corosync service engines.
May 28 12:48:18 nexus corosync[72132]:   [QB    ] withdrawing server sockets
May 28 12:48:18 nexus corosync[72132]:   [SERV  ] Service engine unloaded: corosync vote quorum service v1.0
May 28 12:48:18 nexus pmxcfs[72123]: [confdb] crit: cmap_dispatch failed: 2
May 28 12:48:18 nexus corosync[72132]:   [QB    ] withdrawing server sockets
May 28 12:48:18 nexus corosync[72132]:   [SERV  ] Service engine unloaded: corosync configuration map access
May 28 12:48:18 nexus corosync[72132]:   [QB    ] withdrawing server sockets
May 28 12:48:18 nexus corosync[72132]:   [SERV  ] Service engine unloaded: corosync configuration service
May 28 12:48:18 nexus pmxcfs[72123]: [status] crit: cpg_dispatch failed: 2
May 28 12:48:18 nexus pmxcfs[72123]: [status] crit: cpg_leave failed: 2
May 28 12:48:18 nexus pmxcfs[72123]: [dcdb] crit: cpg_dispatch failed: 2
May 28 12:48:18 nexus pmxcfs[72123]: [dcdb] crit: cpg_leave failed: 2
May 28 12:48:18 nexus pmxcfs[72123]: [dcdb] crit: cpg_send_message failed: 9
May 28 12:48:18 nexus pmxcfs[72123]: [dcdb] crit: cpg_send_message failed: 9
May 28 12:48:18 nexus pmxcfs[72123]: [dcdb] crit: cpg_send_message failed: 9
May 28 12:48:18 nexus pmxcfs[72123]: [dcdb] crit: cpg_send_message failed: 9
May 28 12:48:18 nexus pmxcfs[72123]: [dcdb] crit: cpg_send_message failed: 9
May 28 12:48:18 nexus pmxcfs[72123]: [dcdb] crit: cpg_send_message failed: 9
May 28 12:48:18 nexus pmxcfs[72123]: [dcdb] crit: cpg_send_message failed: 9
May 28 12:48:18 nexus pmxcfs[72123]: [dcdb] crit: cpg_send_message failed: 9
May 28 12:48:18 nexus pmxcfs[72123]: [dcdb] crit: cpg_send_message failed: 9
May 28 12:48:18 nexus pmxcfs[72123]: [dcdb] crit: cpg_send_message failed: 9
May 28 12:48:18 nexus pmxcfs[72123]: [dcdb] crit: cpg_send_message failed: 9
May 28 12:48:18 nexus pmxcfs[72123]: [dcdb] crit: cpg_send_message failed: 9
May 28 12:48:18 nexus pve-ha-lrm[1638]: unable to write lrm status file - unable to open file '/etc/pve/nodes/nexus/lrm_status.tmp.1638' - Device or resource busy
May 28 12:48:18 nexus corosync[72132]:   [QB    ] withdrawing server sockets
May 28 12:48:18 nexus corosync[72132]:   [SERV  ] Service engine unloaded: corosync cluster closed process group service v1.01
May 28 12:48:18 nexus pmxcfs[72123]: [quorum] crit: quorum_dispatch failed: 2
May 28 12:48:18 nexus pmxcfs[72123]: [status] notice: node lost quorum
May 28 12:48:18 nexus corosync[72132]:   [QB    ] withdrawing server sockets
May 28 12:48:18 nexus corosync[72132]:   [SERV  ] Service engine unloaded: corosync cluster quorum service v0.1
May 28 12:48:18 nexus corosync[72132]:   [SERV  ] Service engine unloaded: corosync profile loading service
May 28 12:48:18 nexus corosync[72132]:   [SERV  ] Service engine unloaded: corosync resource monitoring service
May 28 12:48:18 nexus corosync[72132]:   [SERV  ] Service engine unloaded: corosync watchdog service
May 28 12:48:19 nexus pmxcfs[72123]: [quorum] crit: quorum_initialize failed: 2
May 28 12:48:19 nexus pmxcfs[72123]: [quorum] crit: can't initialize service
May 28 12:48:19 nexus pmxcfs[72123]: [confdb] crit: cmap_initialize failed: 2
May 28 12:48:19 nexus pmxcfs[72123]: [confdb] crit: can't initialize service
May 28 12:48:19 nexus pmxcfs[72123]: [dcdb] notice: start cluster connection
May 28 12:48:19 nexus pmxcfs[72123]: [dcdb] crit: cpg_initialize failed: 2
May 28 12:48:19 nexus pmxcfs[72123]: [dcdb] crit: can't initialize service
May 28 12:48:19 nexus pmxcfs[72123]: [status] notice: start cluster connection
May 28 12:48:19 nexus pmxcfs[72123]: [status] crit: cpg_initialize failed: 2
May 28 12:48:19 nexus pmxcfs[72123]: [status] crit: can't initialize service
May 28 12:48:19 nexus corosync[72132]:   [MAIN  ] Corosync Cluster Engine exiting normally
May 28 12:48:19 nexus systemd[1]: corosync.service: Succeeded.
May 28 12:48:19 nexus systemd[1]: Stopped Corosync Cluster Engine.
May 28 12:48:19 nexus systemd[1]: Stopping The Proxmox VE cluster filesystem...
May 28 12:48:19 nexus pmxcfs[72123]: [main] notice: teardown filesystem
May 28 12:48:20 nexus pvesr[72154]: trying to acquire cfs lock 'file-replication_cfg' ...
May 28 12:48:20 nexus systemd[1865]: etc-pve.mount: Succeeded.
May 28 12:48:20 nexus systemd[1]: etc-pve.mount: Succeeded.
May 28 12:48:21 nexus pmxcfs[72123]: [quorum] crit: quorum_finalize failed: 9
May 28 12:48:21 nexus pmxcfs[72123]: [confdb] crit: cmap_track_delete nodelist failed: 9
May 28 12:48:21 nexus pmxcfs[72123]: [confdb] crit: cmap_track_delete version failed: 9
May 28 12:48:21 nexus pmxcfs[72123]: [confdb] crit: cmap_finalize failed: 9
May 28 12:48:21 nexus pmxcfs[72123]: [main] notice: exit proxmox configuration filesystem (0)
May 28 12:48:21 nexus systemd[1]: pve-cluster.service: Succeeded.
May 28 12:48:21 nexus systemd[1]: Stopped The Proxmox VE cluster filesystem.
May 28 12:48:21 nexus systemd[1]: Starting The Proxmox VE cluster filesystem...
May 28 12:48:21 nexus pmxcfs[73492]: [quorum] crit: quorum_initialize failed: 2
May 28 12:48:21 nexus pmxcfs[73492]: [quorum] crit: can't initialize service
May 28 12:48:21 nexus pmxcfs[73492]: [confdb] crit: cmap_initialize failed: 2
May 28 12:48:21 nexus pmxcfs[73492]: [confdb] crit: can't initialize service
May 28 12:48:21 nexus pmxcfs[73492]: [dcdb] crit: cpg_initialize failed: 2
May 28 12:48:21 nexus pmxcfs[73492]: [dcdb] crit: can't initialize service
May 28 12:48:21 nexus pmxcfs[73492]: [status] crit: cpg_initialize failed: 2
May 28 12:48:21 nexus pmxcfs[73492]: [status] crit: can't initialize service
May 28 12:48:22 nexus pvesr[72154]: trying to acquire cfs lock 'file-replication_cfg' ...
May 28 12:48:22 nexus systemd[1]: Started The Proxmox VE cluster filesystem.
May 28 12:48:22 nexus systemd[1]: Starting Corosync Cluster Engine...

  • #4

I rebooted both nodes and my router and now I can login! but i get kicked out immediately with Connection error 401: permission denied - invalid PVE ticket. Some progress at last!
edit: I was previously unable to use the qm command to manually start my vms but it’s working again. I’ve check both nodes and their times are both synced, but at least i can start my vms.

Last edited: May 28, 2021

  • #5

Solved: Fixed itself lmao.

  • #1

I have 1 cluster and 1 of nodes got error on web gui, and error said «Connection failure. Network error or Proxmox VE Service not running?»

already tried systemctl restart pveproxy pvedaemon and pvecm updatecerts / pvecm updatecerts --force
but when after updatecert was got error (re)generate node files generate new node certificate got timeout
i still can access using ssh, but i can’t access it from gui and my main cluster, already see This one

and my when i check pvedaemon.service was

Code:

root@SVR-27:~# systemctl status pvedaemon.service
● pvedaemon.service - PVE API Daemon
   Loaded: loaded (/lib/systemd/system/pvedaemon.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2021-04-08 09:33:33 WIB; 58min ago
  Process: 1089 ExecStart=/usr/bin/pvedaemon start (code=exited, status=0/SUCCESS)
 Main PID: 1246 (pvedaemon)
    Tasks: 4 (limit: 4915)
   Memory: 144.7M
   CGroup: /system.slice/pvedaemon.service
           ├─1246 pvedaemon
           ├─1247 pvedaemon worker
           ├─1248 pvedaemon worker
           └─1249 pvedaemon worker

Apr 08 09:36:19 SVR-27 pvedaemon[1247]: authentication failure; rhost=10.10.30.1 user=root@pam msg=error during cfs-locked 'authkey' operation: no quorum!
Apr 08 09:52:41 SVR-27 pvedaemon[1249]: authentication failure; rhost=10.10.30.1 user=root@pam msg=error during cfs-locked 'authkey' operation: got lock request timeout
Apr 08 09:53:44 SVR-27 pvedaemon[1247]: authentication failure; rhost=10.10.30.1 user=root@pam msg=error during cfs-locked 'authkey' operation: no quorum!
Apr 08 09:53:44 SVR-27 pvedaemon[1249]: authentication failure; rhost=10.10.30.1 user=root@pam msg=error during cfs-locked 'authkey' operation: no quorum!
Apr 08 09:53:44 SVR-27 pvedaemon[1248]: authentication failure; rhost=10.10.30.1 user=root@pam msg=error during cfs-locked 'authkey' operation: no quorum!
Apr 08 09:54:52 SVR-27 pvedaemon[1247]: authentication failure; rhost=10.10.30.1 user=root@pam msg=error during cfs-locked 'authkey' operation: got lock request timeout
Apr 08 09:56:54 SVR-27 pvedaemon[1248]: authentication failure; rhost=10.10.30.1 user=root@pam msg=error during cfs-locked 'authkey' operation: no quorum!
Apr 08 10:14:29 SVR-27 pvedaemon[1249]: authentication failure; rhost=10.10.30.1 user=root@pam msg=error during cfs-locked 'authkey' operation: got lock request timeout
Apr 08 10:21:58 SVR-27 pvedaemon[1248]: authentication failure; rhost=10.10.30.1 user=root@pam msg=error during cfs-locked 'authkey' operation: no quorum!
Apr 08 10:24:52 SVR-27 pvedaemon[1249]: authentication failure; rhost=10.10.30.1 user=root@pam msg=error during cfs-locked 'authkey' operation: no quorum!

any help please?

Last edited: Apr 8, 2021

Dominic


  • #2

It looks to me like this

is your problem.
What is the status of your cluster?

  • #3

It looks to me like this

is your problem.
What is the status of your cluster?

Hey thank you staff for your reply, currently my nodes was recovery by it self (without using HA)
my pvecm status on my nodes now

Code:

root@SVR-27:~# pvecm status
Cluster information
-------------------
Name:             mycluster
Config Version:   18
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Fri Apr  9 13:53:06 2021
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000003
Ring ID:          1.b542
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2
Flags:            Quorate

Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 10.10.30.20
0x00000002          1 10.10.30.22
0x00000003          1 10.10.30.27 (local)

May i know why my nodes like that before? i thought quorum was using voting system each nodes?

Dominic


Время прочтения
13 мин

Просмотры 105K

За последние несколько лет я очень тесно работаю с кластерами Proxmox: многим клиентам требуется своя собственная инфраструктура, где они могут развивать свой проект. Именно поэтому я могу рассказать про самые распространенные ошибки и проблемы, с которыми также можете столкнуться и вы. Помимо этого мы конечно же настроим кластер из трех нод с нуля.

Proxmox кластер может состоять из двух и более серверов. Максимальное количество нод в кластере равняется 32 штукам. Наш собственный кластер будет состоять из трех нод на мультикасте (в статье я также опишу, как поднять кластер на уникасте — это важно, если вы базируете свою кластерную инфраструктуру на Hetzner или OVH, например). Коротко говоря, мультикаст позволяет осуществлять передачу данных одновременно на несколько нод. При мультикасте мы можем не задумываться о количестве нод в кластере (ориентируясь на ограничения выше).

Сам кластер строится на внутренней сети (важно, чтобы IP адреса были в одной подсети), у тех же Hetzner и OVH есть возможность объединять в кластер ноды в разных датацентрах с помощью технологии Virtual Switch (Hetzner) и vRack (OVH) — о Virtual Switch мы также поговорим в статье. Если ваш хостинг-провайдер не имеет похожие технологии в работе, то вы можете использовать OVS (Open Virtual Switch), которая нативно поддерживается Proxmox, или использовать VPN. Однако, я рекомендую в данном случае использовать именно юникаст с небольшим количеством нод — часто возникают ситуации, где кластер просто “разваливается” на основе такой сетевой инфраструктуры и его приходится восстанавливать. Поэтому я стараюсь использовать именно OVH и Hetzner в работе — подобных инцидентов наблюдал в меньшем количестве, но в первую очередь изучайте хостинг-провайдера, у которого будете размещаться: есть ли у него альтернативная технология, какие решения он предлагает, поддерживает ли мультикаст и так далее.

Установка Proxmox

Proxmox может быть установлен двумя способами: ISO-инсталлятор и установка через shell. Мы выбираем второй способ, поэтому установите Debian на сервер.

Перейдем непосредственно к установке Proxmox на каждый сервер. Установка предельно простая и описана в официальной документации здесь.

Добавим репозиторий Proxmox и ключ этого репозитория:

echo "deb http://download.proxmox.com/debian/pve stretch pve-no-subscription" > /etc/apt/sources.list.d/pve-install-repo.list
wget http://download.proxmox.com/debian/proxmox-ve-release-5.x.gpg -O /etc/apt/trusted.gpg.d/proxmox-ve-release-5.x.gpg
chmod +r /etc/apt/trusted.gpg.d/proxmox-ve-release-5.x.gpg  # optional, if you have a changed default umask

Обновляем репозитории и саму систему:

apt update && apt dist-upgrade

После успешного обновления установим необходимые пакеты Proxmox:

apt install proxmox-ve postfix open-iscsi

Заметка: во время установки будет настраиваться Postfix и grub — одна из них может завершиться с ошибкой. Возможно, это будет вызвано тем, что хостнейм не резолвится по имени. Отредактируйте hosts записи и выполните apt-get update

С этого момента мы можем авторизоваться в веб-интерфейс Proxmox по адресу https://<внешний-ip-адрес>:8006 (столкнетесь с недоверенным сертификатом во время подключения).


Изображение 1. Веб-интерфейс ноды Proxmox

Установка Nginx и Let’s Encrypt сертификата

Мне не очень нравится ситуация с сертификатом и IP адресом, поэтому я предлагаю установить Nginx и настроить Let’s Encrypt сертификат. Установку Nginx описывать не буду, оставлю лишь важные файлы для работы Let’s encrypt сертификата:

/etc/nginx/snippets/letsencrypt.conf

location ^~ /.well-known/acme-challenge/ {
  allow all;
  root /var/lib/letsencrypt/;
  default_type "text/plain";
  try_files $uri =404;
}

Команда для выпуска SSL сертификата:

certbot certonly --agree-tos --email sos@livelinux.info --webroot -w /var/lib/letsencrypt/ -d proxmox1.domain.name

Конфигурация сайта в NGINX

upstream proxmox1.domain.name  {
      server 127.0.0.1:8006;
}

server {
    listen 80;
    server_name proxmox1.domain.name;

    include snippets/letsencrypt.conf;
    return 301 https://$host$request_uri;
}


server {
    listen 443 ssl;

    server_name  proxmox1.domain.name;

    access_log  /var/log/nginx/proxmox1.domain.name.access.log;
    error_log  /var/log/nginx/proxmox1.domain.name.error.log;

    include snippets/letsencrypt.conf;

    ssl_certificate /etc/letsencrypt/live/proxmox1.domain.name/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/proxmox1.domain.name/privkey.pem;

    location / {
        proxy_pass  https://proxmox1.domain.name;
        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503                                                                              http_504;
        proxy_redirect off;
        proxy_buffering off;
        proxy_set_header        Host            $host;
        proxy_set_header        X-Real-IP       $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
   
}

Не забываем после установки SSL сертификата поставить его на автообновление через cron:

0 */12 * * * /usr/bin/certbot -a ! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew --renew-hook "systemctl reload nginx"

Отлично! Теперь мы можем обращаться к нашему домену по HTTPS.

Заметка: чтобы отключить информационное окно о подписке, выполните данную команду:

sed -i.bak "s/data.status !== 'Active'/false/g" /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js && systemctl restart pveproxy.service

Сетевые настройки

Перед подключением в кластер настроим сетевые интерфейсы на гипервизоре. Стоит отметить, что настройка остальных нод ничем не отличается, кроме IP адресов и названия серверов, поэтому дублировать их настройку я не буду.

Создадим сетевой мост для внутренней сети, чтобы наши виртуальные машины (в моем варианте будет LXC контейнер для удобства) во-первых, были подключены к внутренней сети гипервизора и могли взаимодействовать друг с другом. Во-вторых, чуть позже мы добавим мост для внешней сети, чтобы виртуальные машины имели свой внешний IP адрес. Соответственно, контейнеры будут на данный момент за NAT’ом у нас.

Работать с сетевой конфигурацией Proxmox можно двумя способами: через веб-интерфейс или через конфигурационный файл /etc/network/interfaces. В первом варианте вам потребуется перезагрузка сервера (или можно просто переименовать файл interfaces.new в interfaces и сделать перезапуск networking сервиса через systemd). Если вы только начинаете настройку и еще нет виртуальных машин или LXC контейнеров, то желательно перезапускать гипервизор после изменений.

Теперь создадим сетевой мост под названием vmbr1 во вкладке network в веб-панели Proxmox.


Изображение 2. Сетевые интерфейсы ноды proxmox1


Изображение 3. Создание сетевого моста


Изображение 4. Настройка сетевой конфигурации vmbr1

Настройка предельно простая — vmbr1 нам нужен для того, чтобы инстансы получали доступ в Интернет.

Теперь перезапускаем наш гипервизор и проверяем, создался ли интерфейс:


Изображение 5. Сетевой интерфейс vmbr1 в выводе команды ip a

Заметьте: у меня уже есть интерфейс ens19 — это интерфейс с внутренней сетью, на основе ее будет создан кластер.

Повторите данные этапы на остальных двух гипервизорах, после чего приступите к следующему шагу — подготовке кластера.

Также важный этап сейчас заключается во включении форвардинга пакетов — без нее инстансы не будут получать доступ к внешней сети. Открываем файл sysctl.conf и изменяем значение параметра net.ipv4.ip_forward на 1, после чего вводим следующую команду:

sysctl -p

В выводе вы должны увидеть директиву net.ipv4.ip_forward (если не меняли ее до этого)

Настройка Proxmox кластера

Теперь перейдем непосредственно к кластеру. Каждая нода должна резолвить себя и другие ноды по внутренней сети, для этого требуется изменить значения в hosts записях следующих образом (на каждой ноде должна быть запись о других):

172.30.0.15 proxmox1.livelinux.info proxmox1
172.30.0.16 proxmox2.livelinux.info proxmox2
172.30.0.17 proxmox3.livelinux.info proxmox3

Также требуется добавить публичные ключи каждой ноды к остальным — это требуется для создания кластера.

Создадим кластер через веб-панель:


Изображение 6. Создание кластера через веб-интерфейс

После создания кластера нам необходимо получить информацию о нем. Переходим в ту же вкладку кластера и нажимаем кнопку “Join Information”:


Изображение 7. Информация о созданном кластере

Данная информация пригодится нам во время присоединения второй и третьей ноды в кластер. Подключаемся к второй ноде и во вкладке Cluster нажимаем кнопку “Join Cluster”:


Изображение 8. Подключение к кластеру ноды

Разберем подробнее параметры для подключения:

  1. Peer Address: IP адрес первого сервера (к тому, к которому мы подключаемся)
  2. Password: пароль первого сервера
  3. Fingerprint: данное значение мы получаем из информации о кластере


Изображение 9. Состояние кластера после подключения второй ноды

Вторая нода успешно подключена! Однако, такое бывает не всегда. Если вы неправильно выполните шаги или возникнут сетевые проблемы, то присоединение в кластер будет провалено, а сам кластер будет “развален”. Лучшее решение — это отсоединить ноду от кластера, удалить на ней всю информацию о самом кластере, после чего сделать перезапуск сервера и проверить предыдущие шаги. Как же безопасно отключить ноду из кластера? Для начала удалим ее из кластера на первом сервере:

pvecm del proxmox2

После чего нода будет отсоединена от кластера. Теперь переходим на сломанную ноду и отключаем на ней следующие сервисы:

systemctl stop pvestatd.service
systemctl stop pvedaemon.service
systemctl stop pve-cluster.service
systemctl stop corosync
systemctl stop pve-cluster

Proxmox кластер хранит информацию о себе в sqlite базе, ее также необходимо очистить:

sqlite3 /var/lib/pve-cluster/config.db
delete from tree where name = 'corosync.conf';
.quit

Данные о коросинке успешно удалены. Удалим оставшиеся файлы, для этого необходимо запустить кластерную файловую систему в standalone режиме:

pmxcfs -l
rm /etc/pve/corosync.conf
rm /etc/corosync/*
rm /var/lib/corosync/*
rm -rf /etc/pve/nodes/*

Перезапускаем сервер (это необязательно, но перестрахуемся: все сервисы по итогу должны быть запущены и работать корректно. Чтобы ничего не упустить делаем перезапуск). После включения мы получим пустую ноду без какой-либо информации о предыдущем кластере и можем начать подключение вновь.

Установка и настройка ZFS

ZFS — это файловая система, которая может использоваться совместно с Proxmox. С помощью нее можно позволить себе репликацию данных на другой гипервизор, миграцию виртуальной машины/LXC контейнера, доступ к LXC контейнеру с хост-системы и так далее. Установка ее достаточно простая, приступим к разбору. На моих серверах доступно три SSD диска, которые мы объединим в RAID массив.

Добавляем репозитории:

nano /etc/apt/sources.list.d/stretch-backports.list

deb http://deb.debian.org/debian stretch-backports main contrib
deb-src http://deb.debian.org/debian stretch-backports main contrib

nano /etc/apt/preferences.d/90_zfs

Package: libnvpair1linux libuutil1linux libzfs2linux libzpool2linux spl-dkms zfs-dkms zfs-test zfsutils-linux zfsutils-linux-dev zfs-zed
Pin: release n=stretch-backports
Pin-Priority: 990

Обновляем список пакетов:

apt update

Устанавливаем требуемые зависимости:

 apt install --yes dpkg-dev linux-headers-$(uname -r) linux-image-amd64

Устанавливаем сам ZFS:

apt-get install zfs-dkms zfsutils-linux

Если вы в будущем получите ошибку fusermount: fuse device not found, try ‘modprobe fuse’ first, то выполните следующую команду:

modprobe fuse

Теперь приступим непосредственно к настройке. Для начала нам требуется отформатировать SSD и настроить их через parted:

Настройка /dev/sda

parted /dev/sda

(parted) print
Model: ATA SAMSUNG MZ7LM480 (scsi)
Disk /dev/sda: 480GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  4296MB  4295MB  primary               raid
 2      4296MB  4833MB  537MB   primary               raid
 3      4833MB  37,0GB  32,2GB  primary               raid

(parted) mkpart
Partition type?  primary/extended? primary
File system type?  [ext2]? zfs
Start? 33GB
End? 480GB
Warning: You requested a partition from 33,0GB to 480GB (sectors 64453125..937500000).
The closest location we can manage is 37,0GB to 480GB (sectors 72353792..937703087).
Is this still acceptable to you?
Yes/No? yes

Аналогичные действия необходимо произвести и для других дисков. После того, как все диски подготовлены, приступаем к следующему шагу:

zpool create -f -o ashift=12 rpool /dev/sda4 /dev/sdb4 /dev/sdc4

Мы выбираем ashift=12 из соображений производительности — это рекомендация самого zfsonlinux, подробнее про это можно почитать в их вики: github.com/zfsonlinux/zfs/wiki/faq#performance-considerations

Применим некоторые настройки для ZFS:

zfs set atime=off rpool
zfs set compression=lz4 rpool
zfs set dedup=off rpool
zfs set snapdir=visible rpool
zfs set primarycache=all rpool
zfs set aclinherit=passthrough rpool
zfs inherit acltype rpool
zfs get -r acltype rpool
zfs get all rpool | grep compressratio

Теперь нам надо рассчитать некоторые переменные для вычисления zfs_arc_max, я это делаю следующим образом:

mem =`free --giga | grep Mem | awk '{print $2}'`
partofmem=$(($mem/10))
echo $setzfscache > /sys/module/zfs/parameters/zfs_arc_max
grep c_max /proc/spl/kstat/zfs/arcstats

zfs create rpool/data
cat > /etc/modprobe.d/zfs.conf << EOL
options zfs zfs_arc_max=$setzfscache
EOL

echo $setzfscache > /sys/module/zfs/parameters/zfs_arc_max
grep c_max /proc/spl/kstat/zfs/arcstats

В данный момент пул успешно создан, также мы создали сабпул data. Проверить состояние вашего пула можно командой zpool status. Данное действие необходимо провести на всех гипервизорах, после чего приступить к следующему шагу.

Теперь добавим ZFS в Proxmox. Переходим в настройки датацентра (именно его, а не отдельной ноды) в раздел «Storage», кликаем на кнопку «Add» и выбираем опцию «ZFS», после чего мы увидим следующие параметры:

ID: Название стораджа. Я дал ему название local-zfs
ZFS Pool: Мы создали rpool/data, его и добавляем сюда.
Nodes: указываем все доступные ноды

Данная команда создает новый пул с выбранными нами дисками. На каждом гипервизоре должен появится новый storage под названием local-zfs, после чего вы сможете смигрировать свои виртуальные машины с локального storage на ZFS.

Репликация инстансов на соседний гипервизор

В кластере Proxmox есть возможность репликации данных с одного гипервизора на другой: данный вариант позволяет осуществлять переключение инстанса с одного сервера на другой. Данные будут актуальны на момент последней синхронизации — ее время можно выставить при создании репликации (стандартно ставится 15 минут). Существует два способа миграции инстанса на другую ноду Proxmox: ручной и автоматический. Давайте рассмотрим в первую очередь ручной вариант, а в конце я предоставлю вам Python скрипт, который позволит создавать виртуальную машину на доступном гипервизоре при недоступности одного из гипервизоров.

Для создания репликации необходимо перейти в веб-панель Proxmox и создать виртуальную машину или LXC контейнер. В предыдущих пунктах мы с вами настроили vmbr1 мост с NAT, что позволит нам выходить во внешнюю сеть. Я создам LXC контейнер с MySQL, Nginx и PHP-FPM с тестовым сайтом, чтобы проверить работу репликации. Ниже будет пошаговая инструкция.

Загружаем подходящий темплейт (переходим в storage —> Content —> Templates), пример на скриншоте:


Изображение 10. Local storage с шаблонами и образами ВМ

Нажимаем кнопку “Templates” и загружаем необходимый нам шаблон LXC контейнера:


Изображение 11. Выбор и загрузка шаблона

Теперь мы можем использовать его при создании новых LXC контейнеров. Выбираем первый гипервизор и нажимаем кнопку “Create CT” в правом верхнем углу: мы увидим панель создания нового инстанса. Этапы установки достаточно просты и я приведу лишь конфигурационный файл данного LXC контейнера:

arch: amd64
cores: 3
memory: 2048
nameserver: 8.8.8.8
net0: name=eth0,bridge=vmbr1,firewall=1,gw=172.16.0.1,hwaddr=D6:60:C5:39:98:A0,ip=172.16.0.2/24,type=veth
ostype: centos
rootfs: local:100/vm-100-disk-1.raw,size=10G
swap: 512
unprivileged: 

Контейнер успешно создан. К LXC контейнерам можно подключаться через команду pct enter , я также перед установкой добавил SSH ключ гипервизора, чтобы подключаться напрямую через SSH (в PCT есть небольшие проблемы с отображением терминала). Я подготовил сервер и установил туда все необходимые серверные приложения, теперь можно перейти к созданию репликации.

Кликаем на LXC контейнер и переходим во вкладку “Replication”, где создаем параметр репликации с помощью кнопки “Add”:


Изображение 12. Создание репликации в интерфейсе Proxmox


Изображение 13. Окно создания Replication job

Я создал задачу реплицировать контейнер на вторую ноду, как видно на следующем скриншоте репликация прошла успешно — обращайте внимание на поле “Status”, она оповещает о статусе репликации, также стоит обращать внимание на поле “Duration”, чтобы знать, сколько длится репликация данных.


Изображение 14. Список синхронизаций ВМ

Теперь попробуем смигрировать машину на вторую ноду с помощью кнопки “Migrate”

Начнется миграция контейнера, лог можно просмотреть в списке задач — там будет наша миграция. После этого контейнер будет перемещен на вторую ноду.

Ошибка “Host Key Verification Failed”

Иногда при настройке кластера может возникать подобная проблема — она мешает мигрировать машины и создавать репликацию, что нивелирует преимущества кластерных решений. Для исправления этой ошибки удалите файл known_hosts и подключитесь по SSH к конфликтной ноде:

/usr/bin/ssh -o 'HostKeyAlias=proxmox2' root@172.30.0.16

Примите Hostkey и попробуйте ввести эту команду, она должна подключить вас к серверу:

/usr/bin/ssh -o 'BatchMode=yes' -o 'HostKeyAlias=proxmox2' root@172.30.0.16

Особенности сетевых настроек на Hetzner

Переходим в панель Robot и нажимаем на кнопку “Virtual Switches”. На следующей странице вы увидите панель создания и управления интерфейсов Virtual Switch: для начала его необходимо создать, а после “подключить” выделенные сервера к нему. В поиске добавляем необходимые сервера для подключения — их не не нужно перезагружать, только придется подождать до 10-15 минут, когда подключение к Virtual Switch будет активно.

После добавления серверов в Virtual Switch через веб-панель подключаемся к серверам и открываем конфигурационные файлы сетевых интерфейсов, где создаем новый сетевой интерфейс:

auto enp4s0.4000
iface enp4s0.4000 inet static
        address  10.1.0.11/24
        mtu 1400
        vlan-raw-device enp4s0

Давайте разберем подробнее, что это такое. По своей сути — это VLAN, который подключается к единственному физическому интерфейсу под названием enp4s0 (он у вас может отличаться), с указанием номера VLAN — это номер Virtual Switch’a, который вы создавали в веб-панели Hetzner Robot. Адрес можете указать любой, главное, чтобы он был локальный.

Отмечу, что конфигурировать enp4s0 следует как обычно, по сути он должен содержать внешний IP адрес, который был выдан вашему физическому серверу. Повторите данные шаги на других гипервизорах, после чего перезагрузите на них networking сервис, сделайте пинг до соседней ноды по IP адресу Virtual Switch. Если пинг прошел успешно, то вы успешно установили соединение между серверами по Virtual Switch.

Я также приложу конфигурационный файл sysctl.conf, он понадобится, если у вас будут проблемы с форвардингом пакетом и прочими сетевыми параметрами:

net.ipv6.conf.all.disable_ipv6=0
net.ipv6.conf.default.disable_ipv6 = 0
net.ipv6.conf.all.forwarding=1
net.ipv4.conf.all.rp_filter=1
net.ipv4.tcp_syncookies=1
net.ipv4.ip_forward=1
net.ipv4.conf.all.send_redirects=0

Добавление IPv4 подсети в Hetzner

Перед началом работ вам необходимо заказать подсеть в Hetzner, сделать это можно через панель Robot.

Создадим сетевой мост с адресом, который будет из этой подсети. Пример конфигурации:

auto vmbr2
iface vmbr2 inet static
        address ip-address
        netmask 29
        bridge-ports none
        bridge-stp off
        bridge-fd 0

Теперь переходим в настройки виртуальной машины в Proxmox и создаем новый сетевой интерфейс, который будет прикреплен к мосту vmbr2. Я использую LXC контейнер, его конфигурацию можно изменять сразу же в Proxmox. Итоговая конфигурация для Debian:

auto eth0
iface eth0 inet static
        address ip-address
        netmask 26
        gateway bridge-address

Обратите внимание: я указал 26 маску, а не 29 — это требуется для того, чтобы сеть на виртуальной машине работала.

Добавление IPv4 адреса в Hetzner

Ситуация с одиночным IP адресом отличается — обычно Hetzner дает нам дополнительный адрес из подсети сервера. Это означает, что вместо vmbr2 нам требуется использоваться vmbr0, но на данный момент его у нас нет. Суть в том, что vmbr0 должен содержать IP адрес железного сервера (то есть использовать тот адрес, который использовал физический сетевой интерфейс enp2s0). Адрес необходимо переместить на vmbr0, для этого подойдет следующая конфигурация (советую заказать KVM, чтобы в случае чего возобновить работу сети):

auto enp2s0
iface enp2s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address  ip-address
        netmask  255.255.255.192
        gateway  ip-gateway
        bridge-ports enp2s0
        bridge-stp off
        bridge-fd 0

Перезапустите сервер, если это возможно (если нет, перезапустите сервис networking), после чего проверьте сетевые интерфейсы через ip a:

2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UP group default qlen 1000
    link/ether 44:8a:5b:2c:30:c2 brd ff:ff:ff:ff:ff:ff

Как здесь видно, enp2s0 подключен к vmbr0 и не имеет IP адрес, так как он был переназначен на vmbr0.

Теперь в настройках виртуальной машины добавляем сетевой интерфейс, который будет подключен к vmbr0. В качестве gateway укажите адрес, прикрепленный к vmbr0.

В завершении

Надеюсь, что данная статья пригодится вам, когда вы будете настраивать Proxmox кластер в Hetzner. Если позволит время, то я расширю статью и добавлю инструкцию для OVH — там тоже не все очевидно, как кажется на первый взгляд. Материал получился достаточно объемным, если найдете ошибки, то, пожалуйста, напишите в комментарии, я их исправлю. Всем спасибо за уделенное внимание.

Автор: Илья Андреев, под редакцией Алексея Жадан и команды «Лайв Линукс»

Recommend Projects

  • React photo

    React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo

    Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo

    Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo

    TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo

    Django

    The Web framework for perfectionists with deadlines.

  • Laravel photo

    Laravel

    A PHP framework for web artisans

  • D3 photo

    D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Visualization

    Some thing interesting about visualization, use data art

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo

    Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo

    Microsoft

    Open source projects and samples from Microsoft.

  • Google photo

    Google

    Google ❤️ Open Source for everyone.

  • Alibaba photo

    Alibaba

    Alibaba Open Source for everyone

  • D3 photo

    D3

    Data-Driven Documents codes.

  • Tencent photo

    Tencent

    China tencent open source team.

  • Печать

Страницы: [1]   Вниз

Тема: Proxmox умер ВЭБ интерфейс  (Прочитано 8284 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн
di_ger

День добрый.
помогите ламеру….
такая ситуевина
на сервере стоит proxmox 2.2
на нем 2 гостевых машины вин7 и сервер 2008 АД
вэб интерфейс на проксмоксе перестал работать, гостевые машины пашут без проблем, удаленно на них захожу.

сейчас нужно сделать бекапы виртуалок, переустановить проксмокс. и поднять виртуалки из бекапов.
но нужно делать все через командную строку, а у меня с ней… тока через гугл…

поиски толком ничего не дали, самая толковая статья с похожей проблемой вот
http://habrahabr.ru/sandbox/68310/

и все бы нормально было… но как всегда
в статье указано что бекапы делаются в архиве ХХХ.tgz
у меня же одна машина  ххх.vma и к ней xxx.log
(vzdump-qemu-100-2015_01_05-19_57_38.vma и vzdump-qemu-100-2015_01_05-19_57_38.log)
вторая xxx.dat и к ней xxx.tmp

при запуске бекапов (как в статье написано)
——————
Первый пункт
vzdump —compress —dumpdir=/backup —mailto xxx@yyy.com 516
где /backup — папка куда класть бекап, xxx@yyy.com — куда послать отчёт 516 — номер виртуалки которую бекапим
——————-
вроде проблем не возникло, кроме того что бекапиться захотело только в /var/lib/vz/dump
в другие места никак
возможно потому что в веб интерфейсе прописано было хранилище по этому пути

правильно ли сделались бекапы?
получится ли из них поднять машины и что за расширения такие получились?

я так подозреваю что нет… была бы машина на которую можно поставить и потестировать… но нет ее… :(

как правильно запустит бекап из командной строки? с остановкой и без остановки виртуалок

если можно напишите пошагово… для тех кто в танке…

З.Ы. лобовая броня очень толстая… но постепенно уменьшается
надеюсь свести ее до минимума  :)


Оффлайн
di_ger

ну вот, танцы продолжаются
архивы наконец-то сделаны…. почему-то второй раз не захотело делаться как было описано выше, пришлось долго вчитываться в мануалы….
за мануал отдельное спасибо  oermolaev

для начала подключил к серверу сетевое хранилище
после отредактировал конфиг VZDUMP
/etc/vzdump.conf

вот так теперь он у меня выглядет

#tmpdir: DIR
dumpdir: /var/lib/vz/nat
#storage: STORAGE_ID
#mode: snapshot|suspend|stop
#bwlimit: KBPS
#ionice: PRI
#lockwait: MINUTES
#stopwait: MINUTES
#size: MB
size: 300000
maxfiles: 2
#maxfiles: N
#script: FILENAME
#exclude-path: PATHLIST

т.е. по умолчанию назначена папка для бекапов и их количество

теперь бекап запускается командой
# vzdump 101

дальше по желанию добавляем ключи…
https://pve.proxmox.com/wiki/Vzdump_manual
тут их сколько угодно, я же добавил только —compress gzip
а то 300 гигов бекапа многовато было бы
да, сервер я выключил принудительно поэтому ключей для остановки, приостановки и т.п. добавлять не пришлось

в итоге в сетевом хранилище у меня два файла
vzdump-qemu-101-дата_время.log   13кб
vzdump-qemu-101-дата_время.vma.gz   45гб

на очереди восстановление….
отпишусь как что получится

« Последнее редактирование: 23 Января 2015, 07:07:02 от di_ger »


Оффлайн
kalinin.alex

Привет, аналогичная проблема была (нужно было поднять почтовик на единственном белом ip с pve вместе, похоже грохнул что-то лишнее, хотя только postfix убивал )…
Мне помогло следующее после кучи вариантов:
выключил виртуалки и перегрузил сервер с pve
— попробовал переустановить pve-manager и получил:
aptitude reinstall pve-manager
pve-manager is not currently installed, so it will not be reinstalled.

— соответственно после aptitude install pve-manager все заработало, сразу)
правда и постфикс воскрес… пожалуй перенесу почтовик на другой сервер…

Unpacking postfix (from …/postfix_2.9.6-2_amd64.deb) …
Selecting previously unselected package pve-manager.
Unpacking pve-manager (from …/pve-manager_3.3-5_amd64.deb) …
Processing triggers for man-db …
Processing triggers for pve-firewall …
Restarting Proxmox VE firewall: pve-firewall.
Setting up postfix (2.9.6-2) …

Postfix configuration was untouched.  If you need to make changes, edit
/etc/postfix/main.cf (and others) as needed.  To view Postfix configuration
values, see postconf(1).

After modifying main.cf, be sure to run ‘/etc/init.d/postfix reload’.

Running newaliases
Stopping Postfix Mail Transport Agent: postfix.
Starting Postfix Mail Transport Agent: postfix.
Setting up pve-manager (3.3-5) …
Restarting PVE Daemon: pvedaemon.
Restarting PVE API Proxy Server: pveproxy.
Restarting PVE SPICE Proxy Server: spiceproxy.
Restarting PVE Status Daemon: pvestatd.

может поможет…


  • Печать

Страницы: [1]   Вверх

[Решено] не открывается web интерфейс

12
Посты

2
Пользователи

0
Likes

18.6 Тыс.
Просмотры

GoProg

(@goprog)

Active Member

Присоединился: 3 года назад

Всем добрый день

Не открывается web интерфейс, белая страница.

proxmox-ve: 5.2-2 (running kernel: 4.15.17-1-pve)
pve-manager: 5.2-1 (running version: 5.2-1/0fcd7879)

очистка кэша браузера, другие браузеры та же картина

systemctl restart pveproxy — без результата

# netstat -an | grep 8006
tcp 0 0 0.0.0.0:8006 0.0.0.0:* LISTEN

ssh работает, виртуальные машины работают, мобильная версия открывается

STALKER_SLX

(@stalker_slx)

Estimable Member

Присоединился: 4 года назад

@goprog

Для начала попробуйте в браузере ввести IP-адрес Вашего proxmox вместо DNS-имени, чтобы получилось так (192.168.10.152 замените на свой IP-адрес):

https://192.168.10.152:8006

STALKER_SLX

(@stalker_slx)

Estimable Member

Присоединился: 4 года назад

@goprog

Если Вы не установили на свой proxmox сертификат — купленный или выпущенный своими силами и добавлен на Ваш компьютер в корневые сертификаты, то в браузере «Opera» появится сообщение :«Ваше подключение не является приватным. Не удалось подтвердить, что это сервер. Операционная система компьютера не доверяет его сертификату безопасности. Возможно, сервер настроен неправильно или кто-то пытается перехватить ваши данные. NET:ERR_CERT_AUTHORITY_INVALID».

Дальше у Вас будет две кнопки «Не продолжать» и «Помогите мне разобраться» — нажимаем вторую., а потом — «Перейти к 192.168.10.152 (небезопасно)»

Ну, а дальше уже Вас встретить знакомый Вам веб-интерфейс proxmox, где нужно вводить свои данные для авторизации — логин и пароль.

Если Вы используете иной браузер, то текст приведённого выше сообщения может быть другим, но суть и действия будут такими же.

STALKER_SLX

(@stalker_slx)

Estimable Member

Присоединился: 4 года назад

@goprog

Похоже, что у Вашего proxmox некоторые системные файлы повреждены — попробуйте в его консоли (через SSH) обновить систему:

apt update && apt upgrade

А потом исправить все зависимости пакетов:

apt install -f

Это сообщение было изменено 3 года назад от STALKER_SLX

STALKER_SLX

(@stalker_slx)

Estimable Member

Присоединился: 4 года назад

Если проблема останется, тогда выполните в терминале последовательно три команды:

apt dist-upgrade

pvecm updatecerts —force

service pveproxy restart

Это сообщение было изменено 3 года назад 3 раз от STALKER_SLX

Понравилась статья? Поделить с друзьями:
  • Proxmox acpi error
  • Proximity sensor test error
  • Provisional headers are shown ошибка
  • Province updater ошибка
  • Provider tcp provider error 35 an internal exception was caught