Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Выпуск Proxmox VE 9.2, дистрибутива для организации работы виртуальных серверов"	+/–
Сообщение от opennews (ok), 22-Май-26, 11:07
Опубликован релиз Proxmox Virtual Environment 9.2, специализированного Linux-дистрибутива на базе Debian GNU/Linux, нацеленного на развертывание и обслуживание виртуальных серверов с использованием LXC и KVM, и способного выступить в роли замены таких продуктов, как VMware vSphere, Microsoft Hyper-V и Citrix Hypervisor. Размер установочного iso-образа 1.7 ГБ... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=65501
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от бочок (ok), 22-Май-26, 11:07	–4 +/–
А запуск LXC с докер образов забили допиливать?(
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3

2. Сообщение от Аноним (2), 22-Май-26, 11:22	–1 +/–
>сотнями или даже тысячами виртуальных машин Миллиардами! Никто это не использует в серьезных дата центрах. Это ниша небольших контор, с серверной максимум на 10-15 сервов
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #5, #6, #8, #12

3. Сообщение от Аноним (3), 22-Май-26, 11:36	+/–
Что-то да, в прошлых 2 версиях было много technology preview (application containers from suitable OCI images, snapshots on thick LVM with snapshots as volume chains, snapshots as volume chains on Directory/NFS/CIFS, nftables firewall) и никаких апдейтов по ним или выходу в GA в этом релизе
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #44

4. Сообщение от isfdskjdhghg (?), 22-Май-26, 11:37	+1 +/–
А что вы лично используете в серьёзных датацентрах?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #9

5. Сообщение от жЫр с монитора (?), 22-Май-26, 11:39	+3 +/–
Дааа? А ты много серьезных датацентров видел? )).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

6. Сообщение от Ярослав Г. (?), 22-Май-26, 11:41	+2 +/–
А Аэрофлот - небольшая контора на 10-15 серверов?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #13, #15

7. Сообщение от ЛетящийГроб (?), 22-Май-26, 11:44	+1 +/–
https://www.proxmox.com/en/products/proxmox-datacenter-manag... С выходом datacenter-manager пропало ограничение на 30 нод !
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11

8. Сообщение от King_Carlo (ok), 22-Май-26, 12:09	+3 +/–
В серьёзных датацентрах надо разворачивать oVirt - технические задания, рабочие проекты, внедрение, эксплуатация, бесконечный бюджет! Вот! А этот ваш proxmox любой пионер может развернуть в кластер, куда это годится? Зарабатывать как?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #10, #45

9. Сообщение от Horo45 (?), 22-Май-26, 12:27	+1 +/–
Опенстак
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

10. Сообщение от Аноним (10), 22-Май-26, 12:36	+1 +/–
https://www.openstack.org/software/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #22

11. Сообщение от theDolphin (ok), 22-Май-26, 12:50	+/–
Ограничение в 30 нод - это ограничение corosync, которому нужна низколатентная связь full mesh. И это даже не ограничение, а рекомендация. Я запускал PVE на 50+ серваках выделив бекбон отдельную сеть. Интересно, как они порешали этот вопрос.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #67

12. Сообщение от theDolphin (ok), 22-Май-26, 12:51	–2 +/–
Ты даже не представляешь, насколько ты не прав )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #16

13. Сообщение от Aliech (ok), 22-Май-26, 13:04	+1 +/–
То есть вы таки хотите сказать, что у Аэрофлота применяется для виртуализации нечто, в котором qemu запущено от рута, да ещё и без ограничения системных вызовов через seccomp? Что-то, что в случае эксплуатации ошибок, типа CVE-2021-3748, даёт взломщикам полный доступ к серверу? Просто именно таков Proxmox VE ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #20, #35, #37

15. Сообщение от 12yoexpert (ok), 22-Май-26, 13:33	+2 +/–
ты бы ещё ГазМяс привёл в пример или Сберкассу
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #21

16. Сообщение от 12yoexpert (ok), 22-Май-26, 13:35	+1 +/–
ты даже не представляешь, насколько он прав
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #17

17. Сообщение от theDolphin (ok), 22-Май-26, 13:42	+/–
Я то как раз немного представляю, у нас несколько сотен (не соврать тысяч, за весь IT компании не скажу) серваков под PVE.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #18

18. Сообщение от Aliech (ok), 22-Май-26, 14:14	+/–
И как вы порешали отсутствие изоляции системных вызовов qemu? Или у вас такие манящие и доступные сервера в проде стоят?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #23, #39

19. Сообщение от Аноним (10), 22-Май-26, 14:36	+/–
>добавлены инструменты для создания, редактирования и удаления собственных моделей виртуальных CPU Для многоядерных камней будет польза: https://servernews.ru/1130635
Ответить | Правка | Наверх | Cообщить модератору

20. Сообщение от жЫр с монитора (?), 22-Май-26, 14:53	+/–
А что, аэрофлот чужие ВМ крутит, как хостинг какой-то и взлом самих ВМ не является уже проблемой? Или Аэрофлот не мониторит активность внутри тех ВМ, которые он крутит?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #24

21. Сообщение от жЫр с монитора (?), 22-Май-26, 14:53	+/–
А что, ГазМяс и Сберкасса это не серьезно? )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #65

22. Сообщение от жЫр с монитора (?), 22-Май-26, 14:54	+2 +/–
Ни Овирт, ни Опенстек уже в серьезных проектах не применяют на этапе проектирования. Только легаси осталось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #68

23. Сообщение от жЫр с монитора (?), 22-Май-26, 14:55	+/–
Поясните нужность этой изоляции.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #25

24. Сообщение от Aliech (ok), 22-Май-26, 14:57	+/–
А что это, безопасность нынче не принято эшелонировать? Хватит только мер на самих ВМ? Сгорел сарай, туда и хату?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #27

25. Сообщение от Aliech (ok), 22-Май-26, 14:58	+/–
А бывает ненужная изоляция? Любая изоляция нужная, если она не вносит критического роста накладных расходов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #26

26. Сообщение от жЫр с монитора (?), 22-Май-26, 15:07	+/–
То есть зачем оно нужно и какие накладные расходы - вы не в курсе. Что-то слышал и мнение имеет. Ясно-понятно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #28

27. Сообщение от жЫр с монитора (?), 22-Май-26, 15:12	+/–
То есть что такое безопасность вы не в курсе. И для чего применяется изоляция процессов, какие накладные расходы оно вызывает, а так же что такое seccomp вы, видимо, где-то слышали. А уж про то, что изоляция и seccomp поможет от эксплуатации вышеприведенной уязвимости...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #29

28. Сообщение от Aliech (ok), 22-Май-26, 15:14	–1 +/–
Ну так просветите, насколько же падает производительность i/o виртуальных машин при включённом seccomp на ваших задачах? Или слив с вопроса засчитывать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #30

29. Сообщение от Aliech (ok), 22-Май-26, 15:16	–1 +/–
Они помогают минимизировать последствия для хоста. Не защитить от эксплуатации. Не надо пытаться придать моим репликам иной смысл.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #31

30. Сообщение от жЫр с монитора (?), 22-Май-26, 15:17	+/–
seccomp это НЕ изоляция. Марш матчасть учить, чудо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #32

31. Сообщение от жЫр с монитора (?), 22-Май-26, 15:18	+/–
То есть пошли пространные размышления. Перечислите три постулата информационной безопасности. После этого подумайте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #36

32. Сообщение от Aliech (ok), 22-Май-26, 15:19	–1 +/–
О, да ладно. Ограничение системных вызовов НЕ ЧАСТЬ изоляции? Марш учить мат. часть, чудо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #33

33. Сообщение от жЫр с монитора (?), 22-Май-26, 15:21	+/–
Нет. Изоляция и ограничение системных вызовов совершенно разные вещи. seccomp может быть ОДНИМ ИЗ механизмов обеспечения изоляции. Но сам по себе изоляцией процессов не является. И, строго говоря, сам по себе seccomp никак не изолирует процессы друг от друга.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #34

34. Сообщение от Aliech (ok), 22-Май-26, 15:24	+/–
"Соломенное чучело", как оно есть. Потому что я об seccomp писал лишь как об одной из мер, призванных минимизировать возможный ущерб. Я уже выше просил не придумывать иных смыслов. Или аргументов нет, и пора перевирать чужие?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #38

35. Сообщение от нах. (?), 22-Май-26, 15:26	+1 +/–
> То есть вы таки хотите сказать, что у Аэрофлота применяется для виртуализации нечто а как по-твоему их поломали, стерев все сервера и все базы? Именно что используется - нечто. И не только для виртуализации, а для всего. аэрофлот паталогически жадная (и т-пая) контора. Все кто там что-то нормальное строил в начале нулевых - сбежали оттуда еще после 2008го.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #59

36. Сообщение от Aliech (ok), 22-Май-26, 15:40	+/–
> То есть пошли пространные размышления. Перечислите три постулата информационной безопасности. > После этого подумайте. Ну да, ну да. Оправдывать отсутствие мер по обеспечению безопасности хоста "тремя постулатами" - это мощно. Это - не пространные размышления. Или вы менеджер Аэрофлота, вот тот самый, который может получить премию за внедрение Proxmox VE (потому что, если бы уже премию получили, то вряд ли бы так переживали)?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #40

37. Сообщение от Анонисссм (?), 22-Май-26, 15:41	+/–
Есть пруфы, что в эрофлоте так всё и сломали? Причём из VM было легко вылезти? Типа, вруть? While the process initialization requires root privileges to configure host-level resources (like network bridges, storage attachments, and hardware passthrough), Proxmox immediately drops privileges or isolates the execution using Linux security modules.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #41, #48

38. Сообщение от жЫр с монитора (?), 22-Май-26, 15:43	+/–
А потом скатился на seccomp. Может тебе самому сначала врать перестать, глядишь и фигню нести меньше будешь? Хотя чей та. Иногда и seccomp приводит к трехкратному снижению производительности. Но ты то об этом не знаешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

39. Сообщение от Анонисссм (?), 22-Май-26, 15:44	+/–
>Или у вас такие манящие и доступные сервера в проде стоят Ты покажешь тулзу, которой я могу на своим proxmox VM вылезти в host? Или она существует в твоем воображении? Или у знакомого сына маминой подруги?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #47

40. Сообщение от жЫр с монитора (?), 22-Май-26, 15:44	+/–
По теме, значит, сказать нечего? Ты даже загуглить не смог?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

41. Сообщение от Aliech (ok), 22-Май-26, 15:44	+/–
> Есть пруфы, что в эрофлоте так всё и сломали? Причём из VM > было легко вылезти? Это к нах. Это он про случившийся взлом писал. > Типа, вруть? > While the process initialization requires root privileges to configure host-level resources > (like network bridges, storage attachments, and hardware passthrough), Proxmox immediately > drops privileges or isolates the execution using Linux security modules. А проверьте сами. Зайдите на хост с работающим PVE и посмотрите, от какого пользователя запущены там все qemu (не части обвязки proxmox'а), и есть ли для тех qemu включённая изоляция вызовов. Спойлер: от рута, изоляции нет. Но не верьте на слово. Проверьте сами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #43

43. Сообщение от нах. (?), 22-Май-26, 15:50	+/–
как бы тебе это объяснить... ну в общем куема - это просто враппер для _ядерных_ вызовов. И тут уж от какого пользователя не запускай... мелкие проблемы в паравиртуализаторе могут тебя лично и не задеть. интересно, кстати, недельной давности баг с доступом в гипервизор хотя бы в редхатоидах уже исправили или опять индус в отпуске?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #46

44. Сообщение от Аноним (44), 22-Май-26, 15:51	+/–
У них ХА и СДН еще не допилен, я думаю они их в первую очередь хотят допилить. Но так то контейнеров хочется нативных, а не держать отдельную виртуалку под них.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

45. Сообщение от нах. (?), 22-Май-26, 15:51	+/–
не хотел бы тебя огорчать, но oVirt - на кладбище редхата. Пока был живой - в общем-то разворачивался несложно, только вот что дальше делать - никто не знал, индусы rhbm, как оказалось - тоже. В сириозных импортозамечательных прожектах ты можешь конечно развернуть z-virt, как патреот, только уволиться задним числом не забудь вовремя.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

46. Сообщение от Aliech (ok), 22-Май-26, 15:54	+/–
> как бы тебе это объяснить... ну в общем куема - это просто > враппер для _ядерных_ вызовов. И тут уж от какого пользователя не > запускай... мелкие проблемы в паравиртуализаторе могут тебя лично и не задеть. > интересно, кстати, недельной давности баг с доступом в гипервизор хотя бы в > редхатоидах уже исправили или опять индус в отпуске? Ага, а ещё там кроме враппера к системным вызовам есть код, обрабатывающий i/o. То есть эмулируемые интерфейсы устройств. И вот с этим есть тоже проблемы. См. например USN-8161-1 от Cannonical. Но к тебе нах., в контексте данной беседы, вообще 0% вопросов. То, что ты поучать начал, - это привычно. У меня вопросы к тем, кто оправдывает забитый болт на меры по уменьшению последствий инцидентов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #49, #51

47. Сообщение от Aliech (ok), 22-Май-26, 15:56	+/–
У меня тулзы нет. Маминых подруг, которые занимаются взятием на приступ виртуалок с дальнейшим выходом в хост, - тоже нет. Так что, от того, что у меня нет эксплойтов, ни знакомых с такими эксплойтами, ты, конечно же, можешь спать спокойно, продолжая игнорировать CVE.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #52

48. Сообщение от нах. (?), 22-Май-26, 15:58	+2 +/–
> Типа, вруть? не вруть, недоговаривають. Это речь о нескучном рест-интерфейсике (то что и есть сам проксмоксь) - он вот действительно дроп привилежес и все такое. Выглядит надежно (нетъ) - ну то есть ты понимаешь, да, что у тебя в сеть торчит нечто работающее от рута потому что хост-левел ресурсес по другому как-то не получается в линуксах настраивать? С этим вот - борются, местами даже и успешно (то есть я не слышал чтобы кого-то именно через вебморду поломали... потому что никто ее разумеется и не высовывает из защищенных сетей) А с тем что там внутре кевеем коровосинкой с цефом погоняет - с этим бороться бесполезно, только возглавить. Но на два хоста и третий запасной в колд-стендбае чтоб за электричество не платить - сойдет. С тех пор как вмварь продалась на кладбище - вариантов у тебя особо и нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

49. Сообщение от нах. (?), 22-Май-26, 16:46	+/–
> У меня вопросы к тем, кто оправдывает забитый болт на меры по уменьшению последствий > инцидентов. сгорела хата - нехай горит и забор... я бы тоже особо напрягаться не стал, если бы мне такое всучили. кстати, мы тут (пока без обещаний оплатить) собрались таки тестировать импортозамещенную виртуализацию. Пока (при очень поверхностном внешнем погляде, еще до установки даже) - выглядит как п-ц. Каковым вероятно и окажется и внутри тоже. Если чудо вдруг произойдет - непременно проинформирую (мои nda ничуть не запрещают информировать о чудесах)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #50

50. Сообщение от Aliech (ok), 22-Май-26, 17:06	+/–
>> У меня вопросы к тем, кто оправдывает забитый болт на меры по уменьшению последствий >> инцидентов. > сгорела хата - нехай горит и забор... я бы тоже особо напрягаться > не стал, если бы мне такое всучили. > кстати, мы тут (пока без обещаний оплатить) собрались таки тестировать импортозамещенную > виртуализацию. Пока (при очень поверхностном внешнем погляде, еще до установки даже) > - выглядит как п-ц. Каковым вероятно и окажется и внутри тоже. > Если чудо вдруг произойдет - непременно проинформирую (мои nda ничуть не запрещают > информировать о чудесах) Интересно. Я из большого Ынтерпраза уже ушёл. Но очень интересно, как оно там движется. Так что, лично я, буду ждать вестей, если таковые будут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

51. Сообщение от жЫр с монитора (?), 22-Май-26, 17:37	+/–
Ты как бы немного теплое с мягким опять путаешь. Ни Ovirt ни Openstack от этих проблем не помогут. И никакая изоляция опять же не поможет. А запуск каждой виртуалки под отдельным пользователем... Ну городи, городи )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #54

52. Сообщение от жЫр с монитора (?), 22-Май-26, 17:39	+/–
Ты щас хочешь сказать, что проксмокс не закрывает CVE? Что ты несешь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #53

53. Сообщение от Aliech (ok), 22-Май-26, 17:57	+1 +/–
То есть ты додумал за меня, якобы я что-то хочу сказать, а потом сам же начал намекать на глупость придуманных тобой для меня аргументов?) А ты хорош! Кстати, не Proxmox закрывает CVE. Разработчики Qemu закрывают CVE в проекте Qemu. И вот от момента, когда появляется информация о CVE, до моменте исправления, проходит время. И ещё время проходит до момента, когда свежая версия Qemu таки попадёт в твою инсталяцию Proxmox. И магия сработает как надо (а вот эти временные лаги - это всё ещё "как надо"), только если информация об уязвимости таки сначала дойдёт до разработчиков, прежде чем эксплойт уверенно начнут торговать где надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #56

54. Сообщение от Aliech (ok), 22-Май-26, 17:58	+/–
> Ты как бы немного теплое с мягким опять путаешь. Ни Ovirt ни > Openstack от этих проблем не помогут. И никакая изоляция опять же > не поможет. А запуск каждой виртуалки под отдельным пользователем... Ну городи, > городи ) OVirt и OpenStack юзают libvirt, там есть отдельный пользователь для запуска ВМ, и запускается оно только с seccomp. И лучше так, чем с рутом и абы как.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #58

55. Сообщение от Аноним (55), 22-Май-26, 18:00	+2 +/–
Для тех, кто в танке по сетям дам несколько уточнений из оригинального Changelog, чтобы всем стало понятно, что Proxmox развивается в отличие от всякого oVirt и иже с ним. 1. Они пошли правильным путём в первую очередь добавляя и отлаживая eBGP-процесс в SDN! При большом масштабировании на локации с несколькими датацентрами укладывать один PoD в одну AS с iBGP вы прочитаете это как лучшую практику. На деле у вас проблемы масштабирования iBGP в связке с SDN и зависимость от вендоров коммутаторов, поэтому начинать именно с eBGP - мудрейшее решение. 2. Поддержка IPv6 Underlay для контроллеров EVPN - это ещё одна форма сетевого экстаза. Фактически это означает, что можно взять Mellanox Spectrum Switch с Cumulus Linux на борту и настроить всё стандартыми настройками да еще и сразу с RDMA QoS! Поймите, обмен соседством через IPv6 Route Advertisement на eBGP-процессе делает конфигурацию и сопровождение конвергентной фабрики тривиальной задачей. 3. FRR! Везде стоит FRR, значит есть тонна физических адаптеров вроде Mellanox и Chelsio, которую львиную долю операций по eBGP переложат на ASIC сетевого адаптера. Судя по тому как именно идёт сетевое развитие Proxmox, я категорически рекомендую ставить Juniper, Mellanox или Arista в качестве основы сетевой фабрики. Cisco же наоборот будет мешаться под ногами. А ну и комментатор выше уже написал, что они работают над гиперкластеризацией... Proxmox не хватает всего-навсего: - нормального открытого высокоскоростного Storage-решения с поддержкой горизонтального масштабирования (нет это не Ceph) - конфедеративного L2 внутри SDN, чтобы можно было растянуть VXLAN между парой PoD-ов. - блочной репликации поверх L3, которая позволит растягивать некоторые кластеры на 2 PoD - и нормальной реализации NFS, но это уже проблема Linux в целом, потому что нет в нём pNFS-сервера на уровне ядра, такими успехами они скорее на SMB перейдут в своём Linux - NUMA-aware кластерные планировщики, опять же... поэтому современные редакции OpenStack рекомендуют Kubernetes вместо Corosync/Pacemaker кластеризации - ни у профили оборудования им надо сертифицировать, чтобы учить сервис-инженеров правильно серваки под Proxmox собирать
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #61

56. Сообщение от жЫр с монитора (?), 22-Май-26, 18:45	–1 +/–
А что ты понимаешь под игнорированием CVE? ммм? Я тебе щас секрет открою: даже админ может большинство из них закрыть по обнаружению. Очень часто достаточно других мероприятий. Ну и обновляются вовремя. А где не обновляются - там и во внешнюю сеть зачастую ничего не торчит и существуют иные меры защиты. Ты же написал так, что по духу можно подумать что использование Proxmox это и есть игнорирование CVE. Вот я и спрашиваю - что ты несешь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #57

57. Сообщение от Aliech (ok), 22-Май-26, 18:50	+/–
"Это у тебя по духу так" - слабое оправдание для самостоятельного приписывания оппоненту тезисов в споре. Игнорирование CVE - не принятие превентивных мер уменьшения возможного урона, с учётом уже выявленных проблем с безопасностью кода. Потому что наличие CVE нам показывает и вектор возможной угрозы, и потенциальный урон, который может быть нанесён. CVE пофиксили - хорошо, но надо быть глупцом, чтобы этот опыт не учесть. Ну или просто ходить за зарплатой, закрывая таски в тикет-системе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

58. Сообщение от жЫр с монитора (?), 22-Май-26, 18:51	+/–
Ээээ.... Я даже не знаю, как бы тебе это сказать... В общем, в proxmox тоже используется libvirt. И точно тот же KVM. И в том же Openstack из коробки нет никакого seccomp. Как, в общем-то, и в OVirt. И отдельного пользователя для виртуалок... Хотя если ты получил доступ к пользователю от которого работают твои виртуалки - рут на сервере тебе уже нахрен не нужОн. Когда ж вы думать научитесь? А запустить в проксмоксе qemu с нужным флагом и лапками настроить профили тебе в общем-то никто не мешает. Если ты понимаешь, что оно делает и зачем )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #60, #62

59. Сообщение от жЫр с монитора (?), 22-Май-26, 18:54	–2 +/–
А ты прямо со свечкой стоял, знаешь, как их поломали? Прям вот взломали виртуалку, из нее пролезли в хост, получили доступ к кластеру проксмокса, и уже там лапками всё стёрли? Или, может, какой-то сотрудник пролюбил где-то свои пароли, коими и воспользовались, ммм? Трепло.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #64

60. Сообщение от Aliech (ok), 22-Май-26, 18:55	+/–
> Ээээ.... Я даже не знаю, как бы тебе это сказать... В общем, > в proxmox тоже используется libvirt. И точно тот же KVM. И > в том же Openstack из коробки нет никакого seccomp. Как, в > общем-то, и в OVirt. И отдельного пользователя для виртуалок... Хотя если > ты получил доступ к пользователю от которого работают твои виртуалки - > рут на сервере тебе уже нахрен не нужОн. Когда ж вы > думать научитесь? А запустить в проксмоксе qemu с нужным флагом и > лапками настроить профили тебе в общем-то никто не мешает. Если ты > понимаешь, что оно делает и зачем ) Серьёзно. А где в Proxmox libvirt? Мне казалось, что это у них один из поводов для гордости, тот факт, что libvirt не используется для запуска qemu, нет? А какие опции libvirt'а отключают запуск qemu с '-sandbox' (а это и есть включение seccomp'а)? Потому что libvirt именно так и запускает qemu. И что-то вот эта часть уже выглядит так, как если бы ты вообще не интересовался, как же оно работает всё...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

61. Сообщение от Ширламырла (?), 22-Май-26, 19:13	+1 +/–
По п.3 какие операции ebgp можно и нужно перекладывать с cpu на asic сетевухи? Сдается мне что никакие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #66, #70

62. Сообщение от Aliech (ok), 22-Май-26, 19:29	+/–
Вообще, конечно, телепердача "Аншлаг" на Опеннет! Кексперд, ранее вписывавшийся за Proxmox, упрекавший собеседника в том, что он не знает того, сего, пятого-десятого и... Кексперд тот не знает, из чего на самом деле состоит тот самый Proxmox, а так же совсем не знает, как там запускаются виртуалки. И про то, как выполнена интеграция вызова seccomp'а в qemu тоже не знает. И об том, как оно выглядит в libvirt - тоже не знает. Но очень хочет пояснить за oVirt и OpenStack, которые запускают всё только через libvirt. Реально. Кроссовер Аншлага и Кривого Зеркала! Спешите видеть!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

64. Сообщение от нах. (?), 22-Май-26, 22:24	+/–
> А ты прямо со свечкой стоял, знаешь, как их поломали? ну ты-то вот точно стоял? > проксмокса, и уже там лапками всё стёрли? Или, может, какой-то сотрудник > пролюбил где-то свои пароли, ага. на опеннет выложил. Такой большой, а все в сказки верит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

65. Сообщение от нах. (?), 22-Май-26, 22:34	+/–
> А что, ГазМяс и Сберкасса это не серьезно? ) ну э... ты вот ихних акциев уже купил ведь, конечно же, да?! Они ведь щас дешооооовые! Надо брать! (или не надо...) Вот по этой причине - в их сторону нужно смотреть вместе с аерофлотом и кто там еще был недавно... а, ВСК - только как делать ни в коем случае не надо, если только тебя дулом автомата еще не тыкают. (и да, pve там был, среди прочих как не надо)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

66. Сообщение от нах. (?), 22-Май-26, 22:41	+/–
> По п.3 какие операции ebgp можно и нужно перекладывать с cpu на > asic сетевухи? тоже не пойму. Наверное отстал за десять лет от прогресса, но мы подпирали свой bgp bfd не потому что процессоры не успевали за всего лишь внутренними маршрутами в изолированных AS, а потому что протокол писали когда маршрутизаторы были большими.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #69

67. Сообщение от ентакусик (?), 22-Май-26, 22:58	+/–
Судя по упоминанию PDM путем распила кластера на несколько поменьше
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

68. Сообщение от Аноним (68), 22-Май-26, 23:14	+/–
...И что применяют тогда в современных проектах, если не секрет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

69. Сообщение от Ширламырла (?), 22-Май-26, 23:44	+/–
Ну как бы эта... Bfd это про быстрое обнаружение отказа линка до соседа. А bgp про держание в башке маршрутов, их всяко-разно фильтрации и всяко-разно отдаванию и приниманию. Ну да, ну да. Вычислению там. Короче. Bgp это по сути приложуха, которой надо ЦПУ и ОЗУ. И чем больше, тем лучше. Но я не пойму как сие уйдет в сетевуху? Если только она не совсем спецушная, т.е. по сути комп в компе. Есть уже такие. Но очень сильно нишевая вещь. Кому это и правда надо, тот знает где брать и с чем есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

70. Сообщение от Аноним (55), 23-Май-26, 02:08	+/–
https://www.nvidia.com/en-us/networking/products/data-proces.../ https://docs.nvidia.com/doca/sdk/doca-hbn-service-guide/inde... > Сдается мне что никакие. Вообще весь eBGP edge c маршрутизацией, IP-маршрутизацию и логику ECMP в том числе сам EVPN. То есть оставить на самом хосте только анонс своих префиксов Я понимаю, что многие упустили эту часть истории "развития" Linux Давным-давно, когда производители сетевых адаптеров и сетевых стеков разных ОС и коммутаторов решали вопрос, как им ускорять обработку пакетов, операционная система Linux всячески сопротивлялась любым методам разгрузки (Offload). Начинается это всё с TCP Offload Engine и тотального нежелания экспертов отдавать контроль и обработку траффика сетевой карте. При этом из ОС выделялись Windows и FreeBSD, которые наоборот всячески этому содействовали, но одновременно конкурировали за реализацию. При этом часть вендоров сетевого оборудования вроде Intel всячески была на стороне MS, в то время как другие интегрировались с FreeBSD и использовали её же код внутри прошивок. Так как реализация в Windows оказалась неконкурентоспособной и проиграла FreeBSD начиная с 2012 R2 в MS полностью отказались от старой логики Offload Engines и начали вдохновляться и портировать в NDIS наработки FreeBSD. При этом вендоры, которые поддерживали MS сейчас либо перепродались либо перестали функционально обновлять драйверы и держат пару адаптеров, которые годятся разве что как LOM (Intel, например). В это время вокруг идей FreeBSD образовались стандартизирующие комитеты вендоров и всё такое прочее. Linux же - отстающий из-за упрямства. Пока в 2007-ом году им на реальном примере не показали, что даже программное Large Receive Offload снижает паразитную нагрузку и улучшает утилизацию, там не почесались. Вообще всё что есть в Linux по сетям до современного Linux Bridge и OVS/OVN лучше просто выкинуть. Всё стало настолько ужасно, что избрели целый фреимворк DPDK, чтобы приложения, которым нужна быстрая сеть могли управлять datapath в обход ядра Linux. Поэтому в мире Linux первое, что вы хотите сделать - избавиться от того недоразумения, которое там в ядре и переложить на иную реализацию на сетевках. Быстрее и качественнее. eBPF, опять же и политики firewall прекрасно уносятся на современные адаптеры, что угодно лишь бы не netfilter c iptables/nftables. Самое удивительное - это то королевство кривых зеркал, которое представляют из себя "анонимные эксперты" линуксоиды. Для них DPDK - это ноухау, а не способ обхода проблем с ядром. Про разгрузки и оптимизацию производительности сети, особенно datapath мало кто знает. Сетевой стек у них лучший, и дальше по тексту... Реальность же в том, что если вы хотите использовать KVM как основной гипервизор, вам нужно построить сетевую и сторадж инфраструктуру вокруг всего этого от правильных вендоров, чтобы сами виртуалки работали с той производительность, что и например на VMware/Hyper-V
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема