Дорогая команде разработчиков PVE,
Как пользователь PVE, я должен выразить серьезное недовольство текущим дизайном и пользовательским опытом. PVE находится в разработке уже 20 лет как платформа виртуализации корпоративного уровня, и она должна иметь более зрелую архитектуру и удобный интерфейс. Однако реальность разочаровывает. Ниже приведены несколько критических проблем, с которыми я столкнулся при использовании PVE, и я искренне надеюсь, что команда воспримет их серьезно и улучшит фундаментально — а не оставит пользователей вручную исправлять проблемы, которые должны были быть решены.
1. **Серьезная разница между UI и Backend при управлении кластером PVE**
UI позволяет легко создавать кластер, но не предоставляет чистого варианта удаления, заставляя пользователей обращаться к командной строке, что часто оставляет остаточные данные, которые нарушают последующие операции. После изменения IP-адреса PVE все еще распознает старый IP из /etc/hosts вместо нового, что затрудняет перенастройку кластера. UI и логика backend полностью не синхронизированы, из-за чего продукт ощущается как незавершенный.
**Предложения:**
* Предоставить полностью функциональный UI для управления кластером, включая создание, изменение и удаление, без необходимости вмешательства командной строки.
* Исправить механизмы распознавания IP-адресов кластера, обеспечив чтение системы текущей конфигурации вместо использования устаревших данных из /etc/hosts.
* Улучшить процесс удаления кластера, обеспечив чистое удаление, которое не оставляет остаточные данные, влияющие на будущие операции.
2. **Плохое управление подкачкой (Swap) и памятью в PVE с ZFS**
PVE использует подкачку даже при наличии достаточной физической памяти, что приводит к ненужной деградации производительности. Kэш ARC ZFS слишком агрессивен, по умолчанию устанавливается на 32 ГБ на 64-ГБ системе, что значительно влияет на другие сервисы. Несмотря на несовместимость ZFS и подкачки, PVE все равно не отключает ее по умолчанию, заставляя пользователей вручную регулировать vm.swappiness или даже запускать swapoff для смягчения проблемы.
**Предложения:**
* Отключить подкачку по умолчанию (или предоставить опцию оптимизации), поскольку ZFS по своей сути не рекомендует использование подкачки.
* Отрегулировать стандартное соотношение использования кэша ARC, предоставив опции UI для пользователей для изменения его вместо принудительного выделения 50% по умолчанию.
* Улучшить управление памятью, чтобы предотвратить преждевременное включение подкачки, что негативно влияет на производительность.
3. **Отсутствие функций корпоративного уровня и плохой пользовательский опыт**
Кластерная HA (высокая доступность) остается нестабильной, требуя частых ручных вмешательств для устранения проблем. Нет настоящей возможности миграции хранилища (storage vMotion), что делает миграцию хранилища VM неэффективной и ограничительной. Недостаточная поддержка хранилища на уровне backend делает PVE менее конкурентоспособным по сравнению со зрелыми корпоративными решениями, такими как ESXi.
**Предложения:**
* Усилить механизмы HA для повышения стабильности, предотвращая ненужные сбои сервисов или неудачные миграции.
* Реализовать более эффективный механизм миграции хранилища, обеспечивающий живую миграцию без снижения производительности.
* Расширить совместимость хранилищ на уровне backend, обеспечив лучшую интеграцию с корпоративными решениями для хранения данных.
**Итоговые мысли**
PVE, как платформа управления виртуализацией корпоративного уровня, находится в разработке уже 20 лет и должна быть зрелым и стабильным продуктом. Однако на самом деле она по-прежнему страдает от дефектов проектирования, несогласованности UI и backend, а также неэффективного управления памятью, что делает ее больше похожей на "едва работоспособную" альтернативу с открытым исходным кодом, а не на действительно конкурентоспособное корпоративное решение. Если PVE действительно стремится быть альтернативой ESXi с открытым исходным кодом, то ей необходимо серьезно доработать эти основные функциональные возможности, а не заставлять пользователей постоянно бороться с обходными путями и исправлениями.
Я надеюсь, что команда PVE признает эти проблемы и внесет значительные улучшения в будущих релизах, а не будет разочаровывать пользователей снова и снова.
Как пользователь PVE, я должен выразить серьезное недовольство текущим дизайном и пользовательским опытом. PVE находится в разработке уже 20 лет как платформа виртуализации корпоративного уровня, и она должна иметь более зрелую архитектуру и удобный интерфейс. Однако реальность разочаровывает. Ниже приведены несколько критических проблем, с которыми я столкнулся при использовании PVE, и я искренне надеюсь, что команда воспримет их серьезно и улучшит фундаментально — а не оставит пользователей вручную исправлять проблемы, которые должны были быть решены.
1. **Серьезная разница между UI и Backend при управлении кластером PVE**
UI позволяет легко создавать кластер, но не предоставляет чистого варианта удаления, заставляя пользователей обращаться к командной строке, что часто оставляет остаточные данные, которые нарушают последующие операции. После изменения IP-адреса PVE все еще распознает старый IP из /etc/hosts вместо нового, что затрудняет перенастройку кластера. UI и логика backend полностью не синхронизированы, из-за чего продукт ощущается как незавершенный.
**Предложения:**
* Предоставить полностью функциональный UI для управления кластером, включая создание, изменение и удаление, без необходимости вмешательства командной строки.
* Исправить механизмы распознавания IP-адресов кластера, обеспечив чтение системы текущей конфигурации вместо использования устаревших данных из /etc/hosts.
* Улучшить процесс удаления кластера, обеспечив чистое удаление, которое не оставляет остаточные данные, влияющие на будущие операции.
2. **Плохое управление подкачкой (Swap) и памятью в PVE с ZFS**
PVE использует подкачку даже при наличии достаточной физической памяти, что приводит к ненужной деградации производительности. Kэш ARC ZFS слишком агрессивен, по умолчанию устанавливается на 32 ГБ на 64-ГБ системе, что значительно влияет на другие сервисы. Несмотря на несовместимость ZFS и подкачки, PVE все равно не отключает ее по умолчанию, заставляя пользователей вручную регулировать vm.swappiness или даже запускать swapoff для смягчения проблемы.
**Предложения:**
* Отключить подкачку по умолчанию (или предоставить опцию оптимизации), поскольку ZFS по своей сути не рекомендует использование подкачки.
* Отрегулировать стандартное соотношение использования кэша ARC, предоставив опции UI для пользователей для изменения его вместо принудительного выделения 50% по умолчанию.
* Улучшить управление памятью, чтобы предотвратить преждевременное включение подкачки, что негативно влияет на производительность.
3. **Отсутствие функций корпоративного уровня и плохой пользовательский опыт**
Кластерная HA (высокая доступность) остается нестабильной, требуя частых ручных вмешательств для устранения проблем. Нет настоящей возможности миграции хранилища (storage vMotion), что делает миграцию хранилища VM неэффективной и ограничительной. Недостаточная поддержка хранилища на уровне backend делает PVE менее конкурентоспособным по сравнению со зрелыми корпоративными решениями, такими как ESXi.
**Предложения:**
* Усилить механизмы HA для повышения стабильности, предотвращая ненужные сбои сервисов или неудачные миграции.
* Реализовать более эффективный механизм миграции хранилища, обеспечивающий живую миграцию без снижения производительности.
* Расширить совместимость хранилищ на уровне backend, обеспечив лучшую интеграцию с корпоративными решениями для хранения данных.
**Итоговые мысли**
PVE, как платформа управления виртуализацией корпоративного уровня, находится в разработке уже 20 лет и должна быть зрелым и стабильным продуктом. Однако на самом деле она по-прежнему страдает от дефектов проектирования, несогласованности UI и backend, а также неэффективного управления памятью, что делает ее больше похожей на "едва работоспособную" альтернативу с открытым исходным кодом, а не на действительно конкурентоспособное корпоративное решение. Если PVE действительно стремится быть альтернативой ESXi с открытым исходным кодом, то ей необходимо серьезно доработать эти основные функциональные возможности, а не заставлять пользователей постоянно бороться с обходными путями и исправлениями.
Я надеюсь, что команда PVE признает эти проблемы и внесет значительные улучшения в будущих релизах, а не будет разочаровывать пользователей снова и снова.
