2026: почему после расширения диска виртуальной машины Proxmox VE 9.2 места не прибавилось?

Версия Proxmox VE 9.2 опубликована 21 мая 2026 года — это указано в официальном объявлении о выпуске. Но номер версии не объясняет, почему после увеличения диска в VM место не появилось: размер виртуального диска, раздела, логического тома и файловой системы — разные величины. На этой неделе сначала проверьте, хватает ли места в хранилище Proxmox, затем проследите всю цепочку внутри гостевой ОС. Не запускайте повторное расширение, пока не выясните, на каком уровне остановилось изменение.

Эта статья для системных администраторов, которые обслуживают Proxmox VE 9.2 и не видят ожидаемой ёмкости в виртуальной машине.
Она также пригодится MSP, ведущим учёт изменений и восстановления для клиентских VM.
Небольшие IT-команды смогут оценить путь расширения до того, как менять разметку работающей системы.

Увеличен виртуальный диск — но это ещё не свободное место

Виртуальную ёмкость полезно представлять как последовательность уровней:

хранилище Proxmox → виртуальный диск VM → блочное устройство в гостевой ОС → раздел → LVM (если используется) → файловая система.

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

Не путайте также свободное место внутри файловой системы с возможностью расширить диск на стороне гипервизора. Для увеличения виртуального диска нужна доступная ёмкость соответствующего хранилища. Проверяйте именно тот storage, в котором расположен этот диск, а не общий объём всех дисков узла. Названия хранилищ и поддерживаемые ими типы содержимого зависят от конфигурации; описание моделей хранения приведено в руководстве Proxmox VE.

Таблица помогает определить следующий объект проверки, но не заменяет подтверждения, что вы выбрали нужную VM и диск. Имена устройств внутри гостевой системы могут отличаться от слотов, которые отображаются в конфигурации Proxmox.

Как выбрать следующий шаг по результатам проверки

Используйте условия, а не одну команду для всех случаев:

• Если в целевом хранилище недостаточно места или его состояние вызывает сомнения, не увеличивайте виртуальный диск. Сначала выясните, как устроено хранилище и какие действия безопасны для него.
• Если конфигурация VM показывает прежнюю ёмкость диска, проверьте, к той ли машине и диску применено изменение. Только после этого решайте, требуется ли корректировка размера виртуального диска.
• Если конфигурация Proxmox показывает новый размер, а lsblk — прежний, исследуйте распознавание устройства гостевой ОС. Не переходите к изменению разделов, пока гостевая система не видит ожидаемый размер.
• Если устройство стало больше, но раздел — нет, сначала определите положение незанятой области и схему разметки. При неизвестной схеме или отсутствии проверенного восстановления остановитесь.
• Если раздел увеличен, но файловая система не показывает прирост, выясните, используется ли LVM, и определите тип файловой системы. Затем расширяйте только недостающий слой.
• Если все уровни уже показывают ожидаемый размер, не повторяйте операцию. Сверьте точку монтирования и проверьте, что приложение смотрит именно на нужную файловую систему.

У «расширить диск VM» нет одного универсального значения. Это может означать увеличить виртуальный диск в Proxmox, расширить раздел в гостевой ОС или дать файловой системе использовать уже доступное место. Эти действия выполняются в разном контексте, а последствия изменения разметки отличаются от последствий изменения настройки виртуального устройства.

Первые проверки: подтвердите VM, диск и состояние гостя

До любых изменений соберите исходные данные. В Linux внутри гостевой системы можно начать с команд:

lsblk
findmnt
df -hT

lsblk помогает сопоставить блочное устройство и разделы, findmnt — увидеть точки монтирования, а df -hT — проверить ёмкость и тип смонтированных файловых систем. Для систем с LVM дополнительно исследуйте физические и логические тома с помощью pvs, vgs и lvs. Эти команды нужны для диагностики; сами по себе они не расширяют диск или файловую систему.

Затем сопоставьте данные гостя с настройкой VM в интерфейсе Proxmox. Подтвердите идентификатор виртуальной машины, слот диска, имя хранилища и текущую ёмкость. Если для проверки используете командную строку, сверяйте синтаксис именно с официальной справкой по команде qm. В документации и примерах встречается поиск по фразе qm resize; перед выполнением ориентируйтесь на актуальную форму команды и параметры в справке, а не на случайный пример для другой версии или устройства.

Полезно записать, какая именно ёмкость показана на каждом уровне до изменения. Это предотвращает ситуацию, когда администратор повторно увеличивает уже расширенный диск, потому что проверял только df, который отражает файловую систему, а не конфигурацию виртуального диска.

Первый шаг: исключите нехватку места на хранилище

Откройте в интерфейсе Proxmox состояние хранилища, где лежит диск VM. Убедитесь, что проверяете нужный storage и видите для него актуальные сведения о доступной ёмкости. Если у вас thin provisioning или иная схема выделения места, не делайте вывод о безопасности операции только по размеру виртуального диска: виртуальная ёмкость и фактически занятое место в хранилище — не одно и то же. Правила зависят от типа и конфигурации хранилища; сверяйте их с соответствующим разделом руководства Proxmox VE.

Если узел или storage близок к исчерпанию доступного пространства, остановитесь и оцените последствия для других VM. Увеличение одного виртуального диска не создаёт дополнительную физическую ёмкость. В многопользовательской среде записывайте, какое хранилище и какая VM затронуты, чтобы не принять локальную нехватку места за проблему гостевой системы.

Второй шаг: проверьте, что изменилось внутри VM

Если конфигурация Proxmox показывает новый размер, но Linux в lsblk — прежний, проверьте распознавание устройства и соответствие выбранного диска. Не запускайте сразу операции изменения таблицы разделов: они не решат ситуацию, если гостевая система пока не видит увеличенную ёмкость устройства.

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

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

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

Для LVM сначала выясните, какой физический том, группа и логический том связаны с нужной файловой системой. Если расширялся раздел, используемый под PV, может потребоваться обновить размер физического тома; затем увеличить целевой LV и, отдельно или подходящим параметром, файловую систему. Синтаксис и порядок зависят от исходной структуры. Подробности о работе с логическими томами описаны в руководстве Red Hat по управлению LVM.

Не копируйте команды для одного имени устройства в другую VM. Перед изменением ещё раз сопоставьте путь к устройству с выводом lsblk, pvs, vgs и lvs. Если вывод не позволяет уверенно установить, какой том содержит нужные данные, остановитесь и обратитесь к администратору, который знает схему гостевой системы.

Расширение файловой системы зависит от её типа

В Linux проверьте тип смонтированной файловой системы в выводе df -hT или по соответствующему пути из findmnt. Для ext4 команда resize2fs изменяет размер файловой системы; её точный порядок применения зависит от того, расширяете ли вы обычный раздел или логический том. Сверьте условия с руководством resize2fs для Debian.

Для XFS применяется другой инструмент — xfs_growfs, работающий с точкой монтирования. Перед его использованием подтвердите тип файловой системы, состояние монтирования и то, что нижележащий раздел или логический том уже предоставляет нужный размер. Синтаксис и применимые условия описаны в справке xfs_growfs. Не запускайте команду для XFS на ext4 или наоборот.

Для Windows откройте управление дисками и сопоставьте диск, раздел и незанятое пространство. Возможность расширить базовый том зависит от расположения незанятого пространства и типа тома. Перед применением действия сверьтесь с инструкцией Microsoft по расширению базового тома. Если расположение или тип раздела не соответствует условиям документации, не пытайтесь обойти ограничение случайной последовательностью изменений.

Безопасный порядок изменений

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

Дальше работайте поэтапно:

1. Запишите идентификатор VM, имя диска, storage и исходную ёмкость.
2. Подтвердите доступное место в соответствующем хранилище Proxmox.
3. Сверьте размер виртуального диска в конфигурации VM с размером блочного устройства внутри гостевой ОС.
4. Определите схему: обычный раздел, LVM или другая конфигурация; отдельно установите тип файловой системы.
5. Меняйте только тот уровень, который отстаёт, и после каждого этапа снова проверяйте размеры.
6. Для Windows или Linux выбирайте процедуру по фактической разметке и официальной документации, а не по общему шаблону.
7. После завершения проверьте файловую систему, точку монтирования и приложение, которому требовалось место; сохраните результаты проверки в записи об изменении.

Если бэкап не проверен, недостаточно места в storage, выбран не тот диск или неизвестен порядок восстановления, отложите изменение. В такой ситуации безопаснее собрать сведения и уточнить схему, чем продолжать по неполному плану.

FAQ: почему ёмкость не видна и что проверить дальше

Почему после расширения диска Proxmox свободное место в Linux не изменилось?
Увеличение виртуального диска меняет доступную ёмкость виртуального устройства, но не обязательно меняет размер раздела, логического тома и файловой системы внутри гостевой ОС. Сначала сравните размер диска в настройках VM с выводом lsblk, затем проверьте разметку, LVM и df -hT. Расширяйте только тот слой, который действительно остался прежнего размера.

Что проверить в Linux после увеличения виртуального диска Proxmox?
Сначала убедитесь, что гостевая система видит увеличенный блочный диск. Затем установите, где находится свободная область и использует ли нужная файловая система обычный раздел или LVM. После расширения раздела для LVM обычно требуется увеличить физический том, затем логический том и файловую систему. Для ext4 и XFS применяются разные команды, поэтому сначала определите тип файловой системы.

Как понять, что осталось прежним: раздел или файловая система?
Сопоставьте размер устройства и разделов по lsblk, проверьте точки монтирования через findmnt, а фактическую ёмкость смонтированной файловой системы — через df -hT. Если устройство больше раздела, дело в разметке. Если раздел или логический том уже увеличен, но файловая система показывает прежний размер, проверяйте её тип и выполняйте подходящую операцию расширения.

Что подготовить перед расширением диска виртуальной машины?
Проверьте свободное место именно в хранилище, где находится виртуальный диск, и подтвердите идентификатор VM и имя диска. Подготовьте проверяемую резервную копию и понятный способ восстановления, согласуйте окно работ для чувствительной нагрузки. Если вы не знаете тип хранилища, схему разделов или порядок восстановления, не меняйте разметку до выяснения этих условий.

Когда проблема в VM, а когда — в ресурсах сервера

Если заполнена только файловая система одной VM, а хранилище Proxmox располагает достаточной ёмкостью, можно рассматривать расширение её виртуального диска и последующее увеличение нужных уровней в гостевой ОС. Если свободного места не хватает самому storage, сначала пересмотрите план хранения: расширение диска VM не решит нехватку ресурсов на стороне узла.

Для нагрузки с несколькими VM важно учитывать не только размер одного виртуального диска, но и то, как хранилище выделяет и использует пространство. Перед покупкой или изменением инфраструктуры сравните предполагаемую схему хранения с реальной структурой VM, резервного копирования и роста данных. Руководство по выбору конфигурации AmdMetal и актуальным тарифам используйте для проверки фактически доступных вариантов, не предполагая заранее определённый тип диска или доступный объём. Доступ к серверу после выбора системы описан в руководстве по подключению.

Общая виртуальная машина или облачный экземпляр могут быть разумны для временной нагрузки и небольших задач, но для постоянного пула VM у них нужно отдельно проверять соседнюю конкуренцию за ресурсы, условия тарификации диска и пределы настройки хранилища. Если вам важны выделенные вычислительные ресурсы и самостоятельное планирование постоянной виртуализационной среды, аренда физического сервера AmdMetal может подойти лучше. Сначала сверяйте фактические дисковые опции и условия на сайте с вашей схемой хранения; если вопрос возник из-за заполненного Proxmox storage, не расширяйте отдельную VM, пока не рассчитали ёмкость всего хранилища.

Часто задаваемые вопросы