Перенос виртуальной машины на реальное железо

dd

Какая система установлена на виртуальную машину? Если Linux / BSD - то перенос возможен, если Windows - то будут проблемы с загрузкой операционной системы на новом «железе».

Способов переноса может быть несколько:

1. Как уже посоветовали dd, загрузившись с Livecd, смонтировать приёмник в /mnt и дать команды:

dd if=/dev/sda of=/mnt/image.img

dd if=/dev/sda1 of=/mnt/image1.img
dd if=/dev/sda2 of=/mnt/image2.img
...
dd if=/dev/sdaN of=/mnt/imageN.img

2. Запаковать в архив целиком систему, только Linux / BSD, агрузиться с Livecd, смонтировать файловые системы в той последовательности, в которой они должны быть подключены, согласно /etc/fstab, к примеру в /mnt/system, в /mnt/backup смонтировать приёмник:

mount /dev/<ROOT> /mnt/system
mount /dev/<USR> /mnt/system/usr
mount /dev/<boot> /mnt/system/boot
...
cd /mnt/system/
tar cjpvf /mnt/backup/system.tar.bz2 ./

mkdir /mnt/system
mount /dev/<ROOT> /mnt/system
mkdir -p /mnt/system/{usr,boot,...}
mount /dev/<USR> /mnt/system/usr
mount /dev/<boot> /mnt/system/boot
...
cd /mnt/system/
tar xjpvf /mnt/backup/system.tar.bz2 -C /mnt/system

3. Вариант, воспользоваться специальным ПО, правда платным, Acronis True Image Home Edition (bootcd можно найти в internet бесплатно.) Создать образ целиком диска и сохранить к примеру на флешку, правда будет долго писаться (флешка медленная). Затем загрузиться с диска с Acronis`ом на новом ПК и развернуть образ диска с флешки, загрузчик восстанавливать не придётся.

Но это всё достаточно сложные варианты, т.к. вы просите всё сделать с помощью флешки, проще подключить жёсткий диск того компьютера, на который вы хотите перенести вашу виртуальну машину к компьютеру, где у вас установлен Virtualbox, пробросить его в виртуальную машину и скопировать систему прямо на него, проще это выполнить всё тем же Acronis`ом, режим клонирование диска / перенос системы. Он так же вам позволит указать другие размеры разделов и правильно увеличит файловые системы, так же не нужно будет переустанавливать загрузчик, да и скорость копирования будет выше за счёт того что вы пишете на жёсткий диск и Acronis не копирует пустое место диска как в случе с dd.

Для того, что бы пробросить реальный жёстки диск в Virtualbox нужно сначала создать (сопоставить ему) файл vmdk.

VBoxManage internalcommands createrawvmdk -filename ~/sdb.vmdk -rawdisk /dev/sdb

Для таких операция ваш пользователь должен находиться в группе disk, /dev/sdb - имя диска, подключенного к вашей системе.
После чего останавливаете виртуальную машину и добавляете в неё жёсткий диск, указав, что диск уже существует и указываете созданный предыдущей командой файл.

Грузитесь с bootcd Acronis True Image Home Edition и осществляете клонирование диска. Затем выключаете виртуальную машину, выключаете компьютер и подключаете диск к целевому компьютеру.

Нашел на просторах интернетов следующую полезность:
VBoxManage internalcommands converttoraw <virtualbox_disk>.vdi
<target_image_name>.img

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

Осталось взять knoppix и из под него развернуть образ. большое спасибо всем отозвавшимся! =)

Разбейте целевой диск на разделы, подмонтируйте образ из виртуальной машины, скопируйте файлы (cp -a), подправьте fstab и переставьте загрузчик. Возможно, нужно будет сделать chroot и перегенерировать initramfs.

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

просто сделайте tar-ом архивы разделов (всех, кроме каталогов /sys, /proc, /mnt, /media, их потом создать надо ручками), затем растарьте на целевой системе. Ну а загрузчик заново надо прописать (для lilo просто chroot && /sbin/lilo)

dd плохо тем, что диск(раздел) в 100Гб она копирует _только_ в диск(раздел) в 100Гб.

>скопируйте файлы (cp -a)

tar-ом быстрее обычно (если использовать tar cz)

Сначала удалите дополнения для виртуальной машины, перенесите диск целиком с помощью dd, подгоните размер разделов после переноса. Может возникнуть необходимость chroot-нуться в перенесённую систему и переустановить GRUB2.

>dd плохо тем, что диск(раздел) в 100Гб она копирует _только_ в диск(раздел) в 100Гб.

Не понял.

Т.е. вот это: «затем на новом диске реального ПК создать таблицу разделов с такими же по размеру разделами, или чуть большими, главное что не меньшими и развернуть всё тем же dd.» лютое 4.2?

Нет. Разве что после развёртывания нужно fsck сделать, чтобы сохранить в ФС информацию о новом размере раздела.

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

>Т.е. вот это: «затем на новом диске реального ПК создать таблицу разделов с такими же по размеру разделами, или чуть большими, главное что не меньшими и развернуть всё тем же dd.» лютое 4.2?

о чём я и говорил - dd переносит 100Гб раздел в 100Гб раздел. И 100Гб диск в 100Гб диск. В последнем случае вообще всё печально - диск на 500Гб видится как диск на 100Гб. :(

А если вы хотите перенести раздел в 100Гб на раздел в 200Гб, то проще воспользоваться cp или лучше tar'ом.

Беда в том, что dd слишком тупая, и переносит всё AS IS.

>Нет. Разве что после развёртывания нужно fsck сделать, чтобы сохранить в ФС информацию о новом размере раздела.

тут resize надо делать, а не fsck. А это может привести к потере всех данных.

тут resize надо делать, а не fsck.
Зачем resize? Если скопировать (dd) например 80-гигабайтый раздел на 160-гигабайтных раздел то достаточно fsck - так как в дополнительных 80 гигабайтах нет ни одного бита данных, достаточно просто поставить ФС в известность о том, что они есть. Вот в случае переноса всего диска с GPT и несколькими разделами скорректировать GPT (parted предлагает это автоматом) нужно ещё до resize, иначе подвигать разделы или изменить их размер не получиться.
> А это может привести к потере всех данных.
О какой потере данных может идти речь, если данные перенесены на новый диск откуда-то (с диска-источника или файла-образа), где точно остаётся их копия?

>Зачем resize? Если скопировать (dd) например 80-гигабайтый раздел на 160-гигабайтных раздел то достаточно fsck - так как в дополнительных 80 гигабайтах нет ни одного бита данных, достаточно просто поставить ФС в известность о том, что они есть.

а вы проверяли? fsck посмотрит в таблицу разделов, где записано, что там 160Гб, а не 80? Ведь в самой FS записано что 80.

О какой потере данных может идти речь, если данные перенесены на новый диск откуда-то (с диска-источника или файла-образа), где точно остаётся их копия?

угу. С образа VM, который на том-же диске :)

а вы проверяли?
Конечно, неоднократно. После развёртывания раздела достаточно fsck. Причём его даже не обязательно делать сразу или же вручную - он будет произведён автоматически при очередной загрузке ОС.
> угу. С образа VM, который на том-же диске :)
В любом случае образ VM во время переноса будет находиться на другом разделе (который, в свою очередь может располагаться где угодно - на том же HDD, на другом HDD или вообще на сетевой шаре).

В любом случае с dd слишком много геморроя на пустом месте. С помощью tar или cp перенести систему гораздо проще и быстрее.

dd удобнее для переноса нескольких разделов. А их обычно как раз несколько.

Сделай несколько разделов, подмонтируй в один корень, а потом tar/cp. Всё равно будет _проще_ и _быстрее_.

Чудесно, только как всё это относится к переносу виртуальной машины на железо?

Размеры физического диска и виртуального не совпадают с вероятностью 99.99999%. Поэтому делаем так. Разбиваем физический диск как нужно, монтируем в один корень, далее монтируем разделы виртуального диска и делаем cp с соответствующими флагами, далее chroot в корень физического диска и восстанавливаем загрузчик. Очевидно, что cp отработает в разы быстрее чем dd, так как данных переливать будет на порядки меньше, да и геморроя потом с resize'ом файловых систем избежим.

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

В виртуальной машине наверняка небольшие диски, ускорение вряд ли будет существенно.

Далеко не факт.

О каком гемморое с ресайзом речь?

Читать man, высчитывать offset'ы и потом не забываем, что resize не увеличит число инодов (по крайней мере на ext3), поэтому в будущем можно огрести геморрой. Может лучше сразу сделать всё правильно?

RussianNeuroMancer> Конечно, неоднократно. После развёртывания раздела достаточно fsck. Причём его даже не обязательно делать сразу или же вручную - он будет произведён автоматически при очередной загрузке ОС.

Наглая ложь. Специально для дебилов привожу доказательства

# lvdisplay vg0/test111 | grep Size
  LV Size                4.00 GiB

# tune2fs -l /dev/vg0/test111 | grep '^Block '
Block count:              524288
Block size:               4096

# echo $((524288 * 4096 / 1024 / 1024 /1024)) GB
2 GB

# fsck.ext4 -f /dev/vg0/test111 
e2fsck 1.42-WIP (16-Oct-2011)
Pass 1: Checking inodes, blocks, and sizes
[skip]
Pass 5: Checking group summary information
/dev/vg0/test111: 11/131072 files (0.0% non-contiguous), 25388/524288 blocks

# tune2fs -l /dev/vg0/test111 | grep '^Block '
Block count:              524288
Block size:               4096

Ничего не изменилось.

Теперь ждем твою демонстрацию или ты понял.

Далеко не факт.
Зависит от размеров диска виртуалки, и всё.
> высчитывать offset'ы и потом не забываем
Этим занимается parted.
> по крайней мере на ext3
Кого ext3 интересует сейчас?

Значит это автоматически делает GParted/parted, а не fsck. Логов под рукой нет, там что-то типа «подправляем размер раздела, чтобы полностью заполнить доступное пространство».

>Если Linux / BSD - то перенос возможен, если Windows - то будут проблемы с загрузкой операционной системы на новом «железе».

Какие, кроме установки дров и загрузки ядра для конкретной архитектуры проца?

Зависит от размеров диска виртуалки, и всё.

Конечно. А кто сказал, что он маленький?

Кого ext3 интересует сейчас?

Ты уверен, что для ext4 не так? я вот не уверен.

Зачем надеяться на какие-то непонятные факторы, если есть 100% рабочий быстрый и железобетонный способ, который вообще не зависит от всяких еслибы да кабы ? Тебе нравятся извращения?

Так то лучше

Конечно. А кто сказал, что он маленький?
Данные обычно хранят на СХД, не?
> Ты уверен, что для ext4 не так? я вот не уверен.
См. наличие resize_inode в Filesystem features вывода tune2fs -l /dev/vdaX. И не нужно никаких абы да кабы.

См. наличие resize_inode в Filesystem features вывода tune2fs -l /dev/vdaX. И не нужно никаких абы да кабы.

Во во. Смотреть на какие-то фичи. Ты прям как упертый баран. Тебе так сложно согласиться с очевидными фактами на счет того, что мой способ 100% рабочий быстрый и не зависит ни от чего?

Я переносом Windows 7 не занимался, но если вы почитаете в Internet, да и здесь то увидите проблемы замены драйверов. К тому же в реестре указан жёстко путь (расположение) системного раздела и файлов реестра:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\hivelist
"\\REGISTRY\\MACHINE\\HARDWARE"=""
"\\REGISTRY\\MACHINE\\SECURITY"="\\Device\\HarddiskVolume1\\WINDOWS\\system32\\config\\SECURITY"
"\\REGISTRY\\MACHINE\\SOFTWARE"="\\Device\\HarddiskVolume1\\WINDOWS\\system32\\config\\software"
"\\REGISTRY\\MACHINE\\SYSTEM"="\\Device\\HarddiskVolume1\\WINDOWS\\system32\\config\\system"
"\\REGISTRY\\USER\\.DEFAULT"="\\Device\\HarddiskVolume1\\WINDOWS\\system32\\config\\default"
"\\REGISTRY\\MACHINE\\SAM"="\\Device\\HarddiskVolume1\\WINDOWS\\system32\\config\\SAM"
"\\REGISTRY\\USER\\S-1-5-20"="\\Device\\HarddiskVolume1\\Documents and Settings\\NetworkService\\NTUSER.DAT"
"\\REGISTRY\\USER\\S-1-5-20_Classes"="\\Device\\HarddiskVolume1\\Documents and Settings\\NetworkService\\Local Settings\\Application Data\\Microsoft\\Windows\\UsrClass.dat"
"\\REGISTRY\\USER\\S-1-5-19"="\\Device\\HarddiskVolume1\\Documents and Settings\\LocalService\\NTUSER.DAT"

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
...
"SystemStartOptions"="NOEXECUTE=OPTIN  FASTDETECT"
"SystemBootDevice"="multi(0)disk(0)rdisk(0)partition(1)"

HKEY_LOCAL_MACHINE\SYSTEM\Setup
"SystemPartition"="\\Device\\HarddiskVolume1"
"OsLoaderPath"="\\"

Вообще данную тему очень интересно, видимо, обсуждать на форуме посвященном Linux / BSD системам.

И ещё раз повторюсь, замены в нужных местах можно попробовать сделать и в Windows, но она для этого не предназначена, в Linux / BSD делается всё куда проще, даже в случае не загружающейся системы (через chroot), попробуйте сделать то же самое в Windows.

Я несколько раз занимался перетаскиванием XP с древней машины с 1 ядром на машину с 2-мя, новым железом и т.д. (аналогично Intel->AMD) - проблем никаких. Многа нажатий кнопачки «Next» и много кофе.

А Win7 в вашем исходном посте
1. Не упоминалась
2. Кто хочет, ищет решение... (Можно? Можно. Какие еще вопросы) Кто не хочет - рассказывает «ужосы» или... предлагает погуглить ;)

>Вообще данную тему очень интересно, видимо, обсуждать на форуме посвященном Linux / BSD системам.

Благородный дон недавно в толксах? Частотность темы про Win 7 на «форуме посвященном» онтопику - цельная темя для исследования. Британскими учеными, например.

При чёс здесь моё сообщение, ТС в шапке темы указал, что у него Windows 7, читайте сначала весь материал, а не ухватами и делайте только после этого выводы.

Тьфу, перепутал темы, пардон, но с переносом Windows XP не всегда тоже гладко проходит.

Да у ТС Linux, наверное, ошибся.

Ну, допустим, определенный % пользователей всегда гарантированно сталкивается с какими-то половыми^W проблемами (независимо от ОСи) :)

Не надо делать намёки.

Не надо все на свой счет принимать - не будете видеть намеки там, где их нет.

на какие-то фичи
> упертый баран
Ну-с, счастливо оставаться. Продолжайте считать resize_inode «какой-то фичей».

тебе просто говорят, что способ с tar'ом лучше, удобнее, быстрее, и надежнее. Вот и все.

Он не лучше и быстрее, если речь о нескольких разделах. Точно не удобнее и не быстрее, если вместо dd использовать Paragon (поддержка ext4 есть в бесплатной версии) или Acronis (поддержка ext4 от пары т.р.). Причём тут надёжность, есть есть resize_inode?

Acronis (поддержка ext4 от пары т.р.).

да, действительно: всего за 29 855,00 руб можно купить версию для Linux сервера. Пруф http://www.acronis.ru/backup-recovery/server-linux/

А вообще - идиотизм юзать какую-то проприентарную НЁХ, с непонятным поведением для таких целей. Хотя дело конечно ваше... ССЗБ.

Причём тут надёжность, есть есть resize_inode?

при том, что tar-ом можно сделать резервную сжатую копию нужных разделов. Достаточно не в поток сжимать, а в обычный файл на каком-нибудь свободном диске.

И что вы скажете про оптимальное распределение файлов и отсутствие фрагментации? Уверен, после resize_inode фрагментация ваших файлов только возрастёт. Да и к чему тут resize_inode? Что она вам даст, если

Reserve space so the block group descriptor table may grow in the future. Tune2fs only supports clearing this filesystem feature.

? Выходит, делать resize_inode надо было раньше... Сейчас уже поздно. Не?

(правда, опасения, что inode кончаться ИМХО неоправданны - их обычно делается слишком много по умолчанию, IRL раз в 10 больше, чем реально используется) например:

#df
/dev/sda3        ext4     12G         7,5G  3,6G           68% /var
#df -i
/dev/sda3        ext4    716K           23K      694K             4% /var
#tune2fs -l
Inode count:              732960
Free inodes:              709794

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

да, действительно: всего за 29 855,00 руб можно купить версию для Linux сервера
А теперь посмотрите цену Workstation-редакции. LiveCD на базе Linux можно слить из личного кабинета после ввода серийного номера.
> А вообще - идиотизм юзать какую-то проприентарную НЁХ, с непонятным поведением для таких целей. Хотя дело конечно ваше... ССЗБ.
Кто вам сказал, что я её юзаю?
> при том, что tar-ом можно сделать резервную сжатую копию нужных разделов. Достаточно не в поток сжимать, а в обычный файл на каком-нибудь свободном диске.
И зачем делать сжатую копию для переноса ОС?
> И что вы скажете про оптимальное распределение файлов и отсутствие фрагментации? Уверен, после resize_inode фрагментация ваших файлов только возрастёт.
Не возрастает.
> правда, опасения, что inode кончаться ИМХО неоправданны
Верно.
> В итоге, ваш метод подходит только для тех, у кого рука к мышке приросла, и которым пару команд в консоли архисложно набрать.
Простите, а dd в каком месте набирается?

>Кто вам сказал, что я её юзаю?
сами не юзаете, а другим советуете?

И зачем делать сжатую копию для переноса ОС?

1. бекап
2. скорость

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

Простите, а dd в каком месте набирается?

в консоли. но как я понял, _ваш_ метод == гуёвые НЁХ.
потому как fsck внезапно не лечит выс*р вашей dd. А лечит какой-то акроникс за 30т.р.

сами не юзаете, а другим советуете?
Почему бы и нет? Ведь для кого-то такой способ более удобен, чем командная строка. Или вы не допускаете, что такие люди могут пользоваться Linux, или там у них может возникнуть необходимость перенести систему из виртуальной машины на железо?
> 1. бекап
Не мешайте тёплое с мягким.
> 2. скорость
Уже шла речь, что обычно у виртуальных машин либо небольшие диски, либо данные лежат где-нибудь на СХД.
> но как я понял
Вы ничего не поняли:
> fsck внезапно не лечит выс*р вашей dd
Выше я указал, что это делает parted. Причём, прошу обратить внимание, это происходит настолько незаметно для пользователя, полностью автоматически, что я даже не обратил внимание на то, какая именно утилита эта делает. Какой ужас, правда?

Я конечно понимаю, что после 34 тех самых более чем стостраничных тредов на ixbt вам очень тяжело нормально общаться, но вы всё же постараайтесь. А вдруг получится снова стать человеком?