Proxmox. Подключить существующие разделы к «новой VM»

Коллеги, прошу помочь с вопросом. Умер HDD с Proxmox. Остался SSD, на котором есть 2 раздела. vm-100-disk-1 и vm-101-disk-1

Интересует 101-й. На нём установлен Win2k8r2 с БД. Установил новый Proxmox 4.4, но при попытке создания VM он сразу пытается стереть разделы. Как можно создать VM и подключить к ней уже существующий раздел vm-101-disk-1 ? (по аналогии с Hyper-V) Могу подключить SSD как хранилище, дальше тупик. Тыкаться боюсь — раздел затирать нельзя.

ну если по тупому, то перенеси файлы vm-100-disk-1 и vm-101-disk-1 куда-нибудь в /root

затем создай виртуалку с номером 101, соответственно создастся файл vm-101-disk-1. замени его своим изначальным файлом и запускай.

или у тебя там LVM-thin и имиджи виртуалок не в виде файлов?

Это физически 2 раздела на SSD-ке и нужен 2-й из них. На счет LVM не уверен, вроде просто LVM. И если не сложно, напиши с командами как это сделать, я с виндой больше дружу, а тут прижало, приходится учиться на ходу.

а я вот не уверен, что это физические разделы. на практике, конечно, можно отдавать виртуалкам диски разделами, но это невозможно сделать из ГУИ и вообще это это не практикуется.твоя проблема решается в дюбом случае, но

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

Установил новый Proxmox 4.4, но при попытке создания VM он сразу пытается стереть разделы

Создавай VM с другим ID (102, например), а потом:

• Если используется файловое хранилище (диски VM хранятся как файлы) — копируй файлы поверх новых (cp vm-101-disk-1 vm-102-disk-1)
• Если используется LVM — записывай данные дисков поверх имеющихся (dd if=/dev/mapper/oldvg-vm-101-disk-1 of=/dev/mapper/newvg-vm-102-disk-1). Только сначала уточни расположение старых/новых разделов (lvs и lvdisplay тебе в помощь)

# sudo fdisk -l -bash: sudo: command not found root@host1:

Могу подключить SSD как хранилище

Потому и предлагает почистить.

т.е. можно удалить первый раздел с SSD vm-100-disk-1 (он не нужен) и на его место создать VM? А затем затереть его старым (нужный чуть больше по размеру)? Сейчас картинка такая:

# lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert vm-100-disk-1 Virtual -wi-a—— 50.00g vm-101-disk-1 Virtual -wi-a—— 61.78g data pve twi-a-tz— 13.12g 0.00 0.54 root pve -wi-ao—- 5.00g swap pve -wi-ao—- 8.00g

# lvdisplay — Logical volume — LV Path /dev/Virtual/vm-100-disk-1 LV Name vm-100-disk-1 VG Name Virtual LV UUID YPgXb4-E0V8-a1e2-WHPc-SiQ8-ru1H-W2ddqJ LV Write Access read/write LV Creation host, time host1, 2017-06-12 13:47:16 +0400 LV Status available # open 0 LV Size 50.00 GiB Current LE 12800 Segments 1 Allocation inherit Read ahead sectors auto — currently set to 256 Block device 251:1

— Logical volume — LV Path /dev/Virtual/vm-101-disk-1 LV Name vm-101-disk-1 VG Name Virtual LV UUID y9a8CA-XVK6-JwW3-mDng-LDzV-aYda-FtbNVB LV Write Access read/write LV Creation host, time host1, 2017-06-12 15:09:12 +0400 LV Status available # open 0 LV Size 61.78 GiB Current LE 15816 Segments 1 Allocation inherit Read ahead sectors auto — currently set to 256 Block device 251:2

— Logical volume — LV Path /dev/pve/swap LV Name swap VG Name pve LV UUID ZMrzfX-6jSY-uC48-XXSa-jIWH-jHpM-BSf4eC LV Write Access read/write LV Creation host, time proxmox, 2017-06-13 12:29:53 +0400 LV Status available # open 2 LV Size 8.00 GiB Current LE 2048 Segments 1 Allocation inherit Read ahead sectors auto — currently set to 256 Block device 251:3

— Logical volume — LV Path /dev/pve/root LV Name root VG Name pve LV UUID J1al1n-u0nT-P3p9-Qpnr-NO2B-N0Rp-x8P9tR LV Write Access read/write LV Creation host, time proxmox, 2017-06-13 12:29:53 +0400 LV Status available # open 1 LV Size 5.00 GiB Current LE 1280 Segments 1 Allocation inherit Read ahead sectors auto — currently set to 256 Block device 251:0

— Logical volume — LV Name data VG Name pve LV UUID yVPvjO-bTqf-5lcB-NPgB-q5SG-emAt-mCN16H LV Write Access read/write LV Creation host, time proxmox, 2017-06-13 12:29:54 +0400 LV Pool metadata data_tmeta LV Pool data data_tdata LV Status available # open 0 LV Size 13.12 GiB Allocated pool data 0.00% Allocated metadata 0.54% Current LE 3360 Segments 1 Allocation inherit Read ahead sectors auto — currently set to 256 Block device 251:6

Добавляем жесткий диск в Proxmox

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

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

Подключаем диск в системе

Устанавливаем жесткий диск в корпус нашего сервера. Подключаем шлейфы (если сервер не поддерживает горячую замену дисков, то лучше его остановить ), переходим к терминальной строке или подключаемся по ssh.

1. Смотрим какие диски подключены в системе при помощи команды fdisk -l. У меня он получился таким:

2. Создаем разметку для подключенного жесткого диска (в случае, если на нем хранятся важные данные, то пропускаем 2 и 3 шаг):

Необходимые команды для fdisk:

m — Помощь
p — Показать разделы жесткого диска
n — Создать новый раздел
d — Удалить раздел
q — Выйти без сохранения
w — Записать изменения и выйти

3. Форматируем новый диск при помощи команды mkfs.ext4:

4. Создаем директорию, куда будем монтировать новый диск:

5. Монтируем диск и добавляем его в файл fstab:

6. Перезагружаем систему и проверяем — монтируется ли новый диск автоматически.

Если все прошло удачно, то переходим к панели управления Proxmox.

Добавляем новый каталог в панели управления Proxmox

1. Входим в панель управления нашего сервера, набрав в адресной строке https://[ip-адрес сервера]:8006

2. Выбираем пункт «Датацентр» — «Хранилище» — «Добавить» — «Каталог»:

3. Указываем параметры добавленного хранилища:

Хранилище добавлено. Продолжаем работу

Конвертация дисков qcow2 -> lvm в KVM (Proxmox)

Занимался на днях переносом виртуальных машин с обычного kvm гипервизора на proxmox. На исходном гипервизоре диски виртуальных машин были в формате qcow2. Я решил заодно сконвертировать диски из qcow2 в lvm и написать заметку об этом, чтобы не забыть.

Для тех, кто не знает, в чем разница между разными форматами дисков в гипервизоре KVM, предлагаю почитать об этом в моей статье на тему бэкапа виртуальных машин kvm. В общем случае, сконвертировать диски qcow2 в lvm можно следующим образом. Сначала преобразуем их в raw формат с помощью qemu-img.

Далее raw образ переносим на новый сервер. На нем же к виртуальной машине подключаем новый диск из lvm хранилища такого же размера, как raw образ. Далее в консоли proxmox выполняем конвертацию в lvm с помощью обычного dd.

Все то же самое можно сделать одной командой на новом сервере, перенеся туда диск в формате qcow2.

Последняя команда qemu-img будет работать медленнее, чем dd из предыдущего примера. Каким способом конвертировать — решать вам. Не забудьте изменить путь к lvm разделу. В моем случае он /dev/pve/vm-102-disk-0, у вас имя группы томов может быть другим, не pve.

Я описал общий случай для любого гипервизора KVM. Но конкретно в proxmox это можно сделать проще. Если вам нужно конвертировать qcow2 в lvm на этом же хосте, то достаточно просто через web интерфейс выбрать Move disk и указать в качестве storage хранилище с LVM. Proxmox сам конвертирует диск с помощью того же qemu-img.

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

1. Переносим qcow2 диск со старого гипервизора на новый.
2. На новом создаем виртуальную машину, подключаем к ней диск любого размера на обычном хранилище в виде директории.
3. Запоминаем имя этого диска и удаляем его. Вместо него переносим диск со старого гипервизора и указываем ему такое же имя.
4. Запускаем виртуалку на новом сервере, убеждаемся, что она работает, выключаем.
5. Через web интерфейс proxmox переносим диск на storage с lvm. Proxmox сам выполнит конвертацию.

Я по такой схеме переносил как linux машины, так и windows. Проблем не было. Единственное, надо не забыть зайти через консоль в windows машину и проверить сетевые настройки. Нужно будет заново настроить сеть, иначе по rdp не подключиться. После переноса сетевой адаптер поменяется.

Администрирование и не только

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

Страницы

среда, 11 марта 2020 г.

Руководство администратора Proxmox VE R 6.0 Глава 10.3-7.

Виртуальные машины Qemu/KVM

1. Эмулированные устройства и паравиртуализированные устройства
2. Параметры Виртуальных Машин
3. Миграция
4. Копии и клоны
5. Шаблоны виртуальных машин
6. Generation ID виртуальной машины
7. Импорт виртуальных машин и образов дисков
8. Поддержка Cloud-Init
9. Проброс PCI(e)
10. Hookscripts
11. Гибернация
12. Управление VM с помощью qm
13. Конфигурация
14. Блокировки

1. Миграция

   

   Онлайн-Миграция

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

   Как это работает

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

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

   Для того, чтобы живая миграция работала, есть некоторые требования:

   • Виртуальная машина не имеет локальных ресурсов (например, проброшенные устройства, локальные диски и т. д.).
   • Хосты находятся в одном кластере Proxmox VE.
   • Хосты имеют работающее (и стабильное) сетевое соединение.
   • Целевой хост должен иметь те же или более высокие версии пакетов Proxmox VE. (Это может работать и в другую сторону, но результат не гарантируется)

   Offline Миграция

   Копии и клоны

   

   Установка виртуальной машины обычно выполняется с помощью установочного носителя (CD-ROM) от поставщика операционной системы. В зависимости от операционной системы, это может быть трудоемкой задачей, которую можно избежать.

   Простой способ развернуть множество виртуальных машин одного типа-скопировать существующую виртуальную машину. Мы используем термин «Клон» для таких копий и различаем связанные и полные клоны.

   Полный Клон

   Результатом такой копии является независимая виртуальная машина. Новая виртуальная машина не имеет общих ресурсов хранения с исходной.

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

   Связанный Клон

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

   Они называются связанными, потому что новый образ все еще ссылается на оригинал. Немодифицированные блоки данных считываются из исходного изображения, но изменения записываются (а затем считываются) из нового места. Эта техника называется «Copy-on-write» (копирование на запись).

   Для этого требуется, чтобы исходный том был доступен только для чтения. С помощью Proxmox VE можно преобразовать любую виртуальную машину в шаблон только для чтения). Такие шаблоны впоследствии могут быть использованы для эффективного создания связанных клонов. На заметку Вы не можете удалить исходный шаблон, пока существуют связанные клоны. Изменить целевое хранилище для связанных клонов невозможно, поскольку это внутренняя функция хранилища.

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

   Чтобы избежать конфликтов ресурсов, все MAC-адреса сетевого интерфейса рандомизируются, и мы генерируем новый UUID для настройки VM BIOS (smbios1).

Шаблоны виртуальных машин

Идентификатор поколения виртуальной машины

Proxmox VE поддерживает Virtual Machine Generation ID (vmgenid) 15 для виртуальных машин. Он может быть использован гостевой операционной системой для обнаружения любого события, приводящего к событию сдвига времени, например, восстановления резервной копии или отката моментального снимка.

При создании новых виртуальных машин, vmgenid виртуальной машины будет автоматически сгенерирован и сохранен в файле конфигурации.

Чтобы создать и добавить vmgenid к уже существующей виртуальной машине, можно передать специальное значение ‘1’, чтобы позволить Proxmox VE автоматически сгенерировать vmgenid или вручную установить UUID 16 , используя его в качестве значения, например: На заметку Первоначальное добавление устройства vmgenid к существующей виртуальной машине может привести к тем же последствиям, что и изменение отката моментального снимка, восстановления резервной копии и т. д., поскольку ВМ может интерпретировать это как изменение поколения. В редких случаях, когда механизм vmgenid не требуется, можно передать ‘0’ для его значения при создании виртуальной машины или удалить задним числом свойство в конфигурации с помощью: Наиболее распространенным вариантом использования vmgenid являются более новые операционные системы Microsoft Windows, которые используют его, чтобы избежать проблем с чувствительными ко времени или реплицируеми службами (например, базы данных, контроллер домена 17 ) при откате моментального снимка, восстановлении резервной копии или всей операции клонирования виртуальной машины.

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

Экспорт виртуальной машины из внешнего гипервизора обычно выполняется в виде одного или нескольких образов диска с конфигурационным файлом, описывающим параметры виртуальной машины (ОЗУ, количество ядер).

Образы дисков могут быть в формате vmdk, если диски поступают из VMware или VirtualBox, или qcow2, если диски поступают из гипервизора KVM. Наиболее популярным форматом конфигурации для экспорта виртуальных машин является стандарт OVF, но на практике взаимодействие ограничено, поскольку многие настройки не реализованы в самом стандарте, а гипервизоры экспортируют дополнительную информацию в нестандартные расширения.

Помимо проблемы форматирования, импорт образов дисков из других гипервизоров может завершиться неудачей, если эмулируемое оборудование слишком сильно меняется от одного гипервизора к другому. Виртуальные машины Windows особенно чувствительны к этому, так как ОС очень придирчива к любым изменениям оборудования. Эта проблема может быть решена путем установки утилиты MergeIDE.zip доступной в интернете, перед экспортом и выбором типа жесткого диска IDE, перед загрузкой импортированной виртуальной машины Windows.

Наконец, возникает вопрос о паравиртуализированных драйверах, которые повышают скорость эмулируемой системы и специфичны для гипервизора. GNU/Linux и другие свободные ОС Unix имеют все необходимые драйверы, установленные по умолчанию, и вы можете переключиться на паравиртуализированные драйверы сразу после импорта виртуальной машины. Для виртуальных машин Windows вам необходимо самостоятельно установить паравиртуализированные драйверы Windows.

GNU/Linux и другие свободные Unix обычно можно импортировать без хлопот. Обратите внимание, что мы не можем гарантировать успешный импорт/экспорт виртуальных машин Windows во всех случаях из-за проблем, описанных выше.

Пошаговый пример импорта Windows OVF

Microsoft предоставляет виртуальные машины для загрузки, для быстрого старта разработчиков Windows. Мы собираемся использовать один из них, чтобы продемонстрировать функцию импорта OVF.

Скачать виртуальную машину zip

После получения информации о пользовательском соглашении выберите Windows 10 Enterprise (Evaluation-Build) для платформы VMware и загрузите zip.

Извлеките образ диска из архива zip

Используя утилиту unzip или любой архиватор по вашему выбору, распакуйте zip и скопируйте через ssh/scp файлы ovf и vmdk на ваш хост Proxmox VE.

Импорт виртуальной машины

Это позволит создать новую виртуальную машину, используя ядра, память и имя виртуальной машины, считанные из манифеста OVF и импортировать диски в local-lvm хранилище. Вы должны настроить сеть вручную. Виртуальная машина готова к запуску.

Добавление образа внешнего диска к виртуальной машине

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

Предположим, вы создали образ диска Debian/Ubuntu с помощью инструмента vmdebootstrap: Теперь можно создать новую целевую виртуальную машину для этого образа. Добавьте образ диска как unused0 к виртуальной машине, используя хранилище pvedir: Наконец, подключите неиспользуемый диск к контроллеру SCSI виртуальной машины: Виртуальная машина готова к запуску.

• Параметры VM
• Оглавление
• Поддержка Cloud-Init