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

Вопрос, возможно, глупый, но всё же: Есть полностью сконфигурированная ВМ, созданная в Virtualbox 4.1.6 Задача — перенести её на реальное железо, причем, желательно, с использованием флэш-накопителя.

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

Если ход мыслей верен — прошу расписать каждый шаг и ПО, необходимое для реализации (или отослать к руководствам, если таковые имеются =) ), если же неверен — опять-таки, наставить на путь истинный.

Заранее благодарен за любую помощь! =)

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

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

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

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

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

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

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

Для таких операция ваш пользователь должен находиться в группе 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. Причём его даже не обязательно делать сразу или же вручную - он будет произведён автоматически при очередной загрузке ОС.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вообще данную тему очень интересно, видимо, обсуждать на форуме посвященном 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 проблемами (независимо от ОСи) :)