Mount vmdk disk linux

How to mount VMDK-image in Linux

Обращаюсь к вам за подсказкой, бородатые админы ..

Понадобилось мне Windows в эмуляторе VirtualBox поставить, выбрал VMDK. Теперь хочу вытащить файлы оттуда, подмонтировав VMDK-образ в Дебиане. Пока вижу такой путь: qemu-img convert . && mount -o ro,loop .

Есть ли какой-то другой способ? Утилита xmount, по-моему, такого не умеет.

у тебя qemu за сентябрь 2012 года.

В общем, я решил простым способом — конвертировал образ в raw, затем

Просто интересовали какие-то прямые способы без конвертации. Я нашёл упоминание, что есть проприетарные утилиты для этого под Windows, MacOS (от VMWare).

Странно, что ты не вбил заголовок треда в гугл, вопрос сформулирован абсолютно правильно. И самый первый линк в выдаче дал

Mount a VMware virtual disk (.vmdk) file on a Linux box

Assumes XP/2000/2003. For Server 2008+ try offset=105,906,176 You can find this number in the System Information utility under Partition Starting Offset. UEFI based boxes you want partition 2 since the first is just the boot files (and FAT). This works with (storage side) snapshots which is handy for single file restores on NFS mounted VMware systems

И кучу альтернативных вариантов, без ожидания кучи времени на конвертацию.

И кстати, за это я не люблю Дебиан, полный древними ископаемыми. Взглянув на версии софта, так и хочется заменить «ШГ» на «УГ» рядом со словом Debian на твоей аве.

Источник

Как смонтировать виртуальный жесткий диск?

Можно ли смонтировать виртуальный жесткий диск (VHD, HDD, VDI, VMDK) в Ubuntu? Как это может быть сделано?

4 ответа

Linux и другие Unix-подобные хосты могут монтировать образы, созданные в необработанном формате, с помощью устройства обратной связи. Из имени пользователя root (или с помощью sudo) смонтируйте петлю со смещением 32 256.

Для других типов изображений qemu вы можете использовать qemu-nbd

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

Попробуйте Google, я нашел решение для (VirtualBox) .VDI в одну секунду:

Так же, как команды «Qemu’s way». Нет границ!

Это на Ubuntu 16.04.

Как корень:

Установите и смонтируйте используя affuse.

Проверьте размер сектора

Умножьте сектор и начальный сектор. В примере это будет 2048*512

Смонтировать, используя это смещение

Теперь диск должен быть смонтирован и доступен для чтения в /mnt/vmdisk

За vmdk а также vhd файлы, мне повезло только с kpartx команда ниже:

Проверьте вывод для losetup , он должен содержать петлевое устройство /dev/loop0 ; также проверьте sudo blkid для раздела /dev/mapper/loop0p1 , затем используйте его в команде mount:

Где /mnt/vmdk — ваша точка монтирования, которая будет создана с sudo mkdir /mnt/vmdk если не существует.

Размонтировать с помощью:

Вы также можете использовать qemu:

За .vdi

если они не установлены, вы можете установить их (в Ubuntu эта команда)

а затем смонтировать его

За .vmdk

обратите внимание, что я использую опцию -r это потому, что VMDK версии 3 должен быть доступен только для чтения, чтобы его можно было смонтировать с помощью qemu

а потом я его монтирую

я использую nbd1 так как nbd0 иногда выдает ‘mount: специального устройства /dev/nbd0p1 не существует’

Для.ova

Выше будет извлекать .vmdk диск, а затем смонтировать это.

Источник

Запуск Linux с виртуального диска vmdk на реальном железе и VirtualBox

Возникла необходимость обеспечить работу Linux как на виртуальной машине (VirtualBox), так и на реальном железе. После долгих поисков и попыток запускать Linux с виртуального диска формата VHD, по примеру Windows, которые либо слишком сложны, либо не работают, я пришел к достаточно простому способу сделать это. Правда не из дисков в формате VHD, а из образа раздела диска в формате VMDK.

Linux возможно загрузить из образа раздела. Теперь нужно сделать так, чтобы у нас был и образ диска, который понимает VirtualBox и образ раздела, который может загрузить grub.

Далее расписано, как это можно сделать быстро и без лишней головной боли.

Все что далее, сделано из Windows.

Создаем новый диск фиксированного размера в формате vmdk:

Имеем созданные файлы:

• test1.vmdk — дескриптор диска, текстовый файл
• test1-flat.vmdk — файл с образом диска

Теперь необходимо в начало диска добавить еще один кусок размером 1M.

Создаем файл test1-boot.vmdk размером 1M:

В test1.vmdk меняем createType=»custom» на createType=»monolithicFlat» . Это будет означать, что диск состоит из нескольких файлов.

Добавляем test1-boot.vmdk в test1.vmdk , первым. После добавления test.vmdk должен выглядеть как-то так:

где 2048 — это 2048*512=1048576 байт (1M) для этой части диска.

Создаем виртуальную машину для установки Linux, подключаем к ней диск test1.vmdk и ставим ubuntu/kubuntu/xubunu. Я ставил только эти дистрибутивы, начиная с версий 18.04 до последней (еще не вышедшей) 21.04, все остальное не проверял.

Особенность при установке: должен быть создан только один раздел на виртуальном диске и должен он быть на границе 1M. Это поведение по умолчанию при ручном создании раздела.

Загрузчик должен быть установлен на диск /dev/sda, а не на раздел /dev/sda1. Это тоже поведение по умолчанию.

После того, как все установили, перезагружаемся в VirtualBox, чтобы убедится, что Linux загружается.

Теперь загрузим только что установленный Linux на реальном железе. Проще всего сделать это с использованием загрузочной флешки.

Создаем загрузочную флешку (или usb-диск) с использованием Ventoy (https://www.ventoy.net/).

Создаем файл ventoy\ventoy_grub.cfg на разделе данных флешки со следующим содержимым:

• imgfile=»/mydisks/test1-flat.vmdk» — путь до файла с образом раздела
• d_label=»MYDISK» — метка раздела, где лежит файл с образом раздела test1-flat.vmdk

Загружаемся с этой флешки, нажимаем F6 и попадаем в меню, где выбираем пункт «boot linux from vmdk part». Радуемся запущенному Linux.

Можно вернуться в свою рабочую OS, запустить VirtualBox и загрузить Linux из виртуального диска.

Таким вот, незамысловатым, способом можно иметь возможность сидя в Windows запускать Linux в VirtualBox, настраивать его… А потом запускать на реальном железе.

Стоит иметь ввиду, что если обновления затрагивают grub, то они не корректно будут завершены в системе, запущенной на реальном железе, ибо нет раздела с загрузчиком. Однако это не мешает нормальной работе. А такие обновления можно и через VirtualBox применять.

Источник

Монтирование VMDK дисков в ОС Linux или как достать лог-файлы CUCM

» means nesting-related): — Failed at: @displayUserCertifications user_id [in template «custom.author-acclaim-certifications» at line 4, column 9] ——>

В современном, быстро меняющемся мире, разработка программного обеспечения (ПО) и его выпуск на рынок производителями происходит все быстрее и быстрее. Новые версии продуктов получают новую функциональность и избавление от старых проблем. ПО Cisco Unified Communication Manager (CUCM) не является здесь исключением.

Процедуры установки и обновления CUCM детально документированы и ознакомиться с ними можно на странице по следующей ссылке:

Однако, стоит отметить, что не всегда установка проходит так, как описано в официальном руководстве. В отдельных случаях, установка прекращается до своего логического завершения — «что-то пошло не так». После внезапного завершения процесса установки с демонстрацией на экране, как правило, не совсем понятного сообщения о возникшей ошибке, очень хочется понять, в чем же было дело.

Раньше, когда деревья были большими и ПО устанавливалось на физические сервера, можно было бы загрузиться с Floppy / CD / DVD диска, далее смонтировать файловую систему на HDD в ручном режиме и посмотреть оставшиеся от программы-установщика лог-файлы.

В нашей сегодняшней «виртуальной» реальности, к сожалению, не все так просто. Для получения лог-файлов процесса установки ПО CUCM необходимо заранее создать в нашей виртуальной машине консоль, подключиться к ней и только после этого начинать процесс установки или обновления. Подробности о том как это нужно делать можно прочесть в следующем документе:
http://docwiki.cisco.com/wiki/How_to_Dump_Install_Logs_to_the_Serial_Port_of_the_Virtual_Machine

Часто ли Вы следовали процедуре, описанной выше? Вот, вот, и я тоже 😉

Ниже описан способ с помощью которого можно смонтировать файл VMDK с неудачной установкой CUCM на обычной системе с ОС Linux. В описанном ниже примере, использовался CentOS Linux 7.0.

Шаг 1. Получение доступа к исходному файлу VMDK из ОС Linux.

Для работы с VMDK файлом его можно просто загрузить внутрь ОС Linux с помощью протоколов FTP/SFTP/SCP, в случае, если размеры дисковой подсистемы ОС Linux обладают нужными объемами. В данном случае размер vmdk файла превышал 100 гигабайт и места на локальном диске не хватало для его размещения, поэтому исходный файл был размещен на сетевом хранилище NAS и смонтирован оттуда в недра ОС Linux:

mount –t cifs //192.168.1.1/SharedFolder -o username= user ,password= pass /mnt/nas

• //192.168.0.1/SharedFolder – путь к удаленному ресурсу на сетевом диске;
• user, pass – имя пользователя и пароль для доступа к удаленному ресурсу;
• /mnt/nas – точка монтирования удаленного ресурса в ОС Linux. По этому пути после монтирования будет доступна вся информация с удаленного ресурса (NAS) в локальной системе.

Проверка доступности необходимого VMDK файла:

-rwx—— 1 roor root 7209472 Jul 14 15:50 cucm01-ctk.vmdk
-rwx—— 1 root root 118111600640 Jul 21 23:35 cucm01-flat.vmdk
-rwx—— 1 root root 576 Jul 17 11:22 cucm01.vmdk

нужные нам данные хранятся VMWare в VMDK файле с суффиксом – flat .

Шаг 2. Получение информации о структуре диска VMDK.

Монтируем наш VMDK файл как loopback устройство, указав путь:

losetup /dev/loop0 /mnt/nas/cucm01-flat.vmdk

и смотрим таблицу разделов и характеристики теперь уже смонтированной файловой системы:

fdisk -l /dev/loop0

Disk /dev/loop0: 118.1 GB, 118111600640 bytes, 230686720 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00079338

Device Boot Start End Blocks Id System
/dev/loop0p1 * 2048 41259007 20628480 83 Linux
/dev/loop0p2 41259008 82515967 20628480 83 Linux
/dev/loop0p3 82515968 83040255 262144 83 Linux
/dev/loop0p4 83040256 230686719 73823232 5 Extended
/dev/loop0p5 83042304 87138303 2048000 82 Linux swap / Solaris
/dev/loop0p6 87140352 230686719 71773184 83 Linux

В показанном выше выводе следует обратить внимание на цифры, выделенные красным – это размер блока (unit) — 512 байт и начало раздела в блоках (колонка Start). Эмпирическим путем было выяснено, что представляют интерес только разделы p1 и p6 . В разделе p1 хранятся основные файлы ОС, а в разделе p6 хрянятся нужные нам log-файлы.

Далее, нам необходимо смонтировать разделы p1 и p6 уже отдельно для получения доступа к файлам на них хранящимся.

Шаг 3. Монтирование отдельных разделов и доступ к файлам.

Перед монтированием отдельного раздела необходимо вычислить его смещение в байтах относительно начала VMDK файла. Для этого необходимо цифру из столбца Start соответствующего раздела умножить на размер блока:

/dev/loop0p1 – 2048 x 512 = 1048576
/dev/loop0p6 – 87140352 x 512 = 44615860224

Размеры остальных разделов приведены для справки, в конце каждой строки приведен результат попытки смонтировать раздел:
/dev/loop0p2 – 41259008 x 512 = 21124612096 -> «lost+found only!»
/dev/loop0p3 – 82515968 x 512 = 42248175616 -> «can’t read superblock»
/dev/loop0p4 – 83040256 x 512 = 42516611072 -> «unknown filesystem type ‘(null)'»
/dev/loop0p5 – 83042304 x 512 = 42517659648 -> «can’t read superblock

Создаем точки монтирования для нужных нам разделов:

mkdir /mnt/vmdk1
mkdir /mnt/vmdk6

losetup -o 1048576 /dev/loop1 /dev/loop0
mount /dev/loop1 /mnt/vmdk1

losetup -o 44615860224 /dev/loop2 /dev/loop0
mount /dev/loop2 /mnt/vmdk6

Разделы должны смонтироваться без ошибок. После этого доступ к лог-файлам станет возможным! Теперь можно посмотреть на список файлов:

ls –la /mnt/vmdk1/var/log

total 1164
drwxr-xr-x. 7 root root 4096 Jul 14 00:07 .
drwxr-xr-x. 18 root root 4096 Jul 14 06:55 ..
lrwxrwxrwx. 1 root root 22 Jul 14 06:59 active -> /common/log/taos-log-a
-rw——-. 1 root root 1768 Jul 14 06:57 anaconda.ifcfg.log
-rw——-. 1 root root 24013 Jul 14 06:57 anaconda.log
-rw——-. 1 root root 74350 Jul 14 06:57 anaconda.program.log
-rw——-. 1 root root 2224 Jul 14 06:57 anaconda.storage.log
-rw——-. 1 root root 115630 Jul 14 06:57 anaconda.syslog
-rw——-. 1 root root 1811 Jul 14 06:57 anaconda.yum.log
drwxr-x—. 2 root root 4096 Jul 14 07:00 audit
-rw——-. 1 root utmp 0 Jul 14 06:55 btmp
drwxr-xr-x. 2 root root 4096 Jan 5 2010 ConsoleKit
-rw-r—r—. 1 root root 70582 Jul 14 14:06 dmesg
-rw-r—r—. 1 root root 600908 Jul 14 00:08 dracut.log
lrwxrwxrwx. 1 root root 22 Jul 14 06:59 inactive -> /common/log/taos-log-b
lrwxrwxrwx. 1 root root 19 Jul 14 06:59 install -> /common/log/install
-rw-r—r—. 1 root root 195056 Jul 14 00:09 lastlog
-rw——-. 1 root root 0 Jul 14 06:55 maillog
-rw——-. 1 root root 0 Jul 14 06:55 messages
-rw——-. 1 root root 58 Jul 14 00:07 nbslogpd
drwxr-xr-x. 2 ntp ntp 4096 Dec 19 2014 ntpstats
drwxr-xr-x. 2 root root 4096 Jul 14 14:06 sa
-rw——-. 1 root root 0 Jul 14 06:55 secure
drwxr-xr-x. 2 root root 4096 Mar 21 01:10 setroubleshoot
-rw——-. 1 root root 0 Jul 14 06:55 spooler
-rw——-. 1 root root 0 Jul 14 06:55 tallylog
-rw-r—r—. 1 root root 174908 Jul 14 00:08 vmware-tools-upgrader.log
-rw-rw-r—. 1 root utmp 3072 Jul 14 00:11 wtmp

total 48
drwxr-xr-x. 9 root root 4096 Jul 14 00:08 .
drwxr-xr-x. 9 root root 87 Jul 21 22:19 ..
drwxr-x—. 7 root 582 4096 Jul 14 07:01 adminsftp
-rw-r—r—. 1 root root 1533 Jul 14 07:00 capture.txt
drwxrwxr-x. 2 502 502 4096 Jul 14 07:00 download
drwxrwxrwx. 2 root root 4096 Jul 14 07:01 drf
drwxrwxrwt. 5 root root 4096 Jul 14 06:57 log
drwx——. 2 root root 16384 Jul 14 06:54 lost+found
drwxr-xr-x. 2 root root 4096 Jul 14 00:08 m1_root_dir
drwxrwxrwx. 3 root root 4096 Jul 14 06:57 rpm-archive

Шаг 4. Размонтирование разделов после их использования

После завершения работы с разделами их необходимо размонтировать. Сделать это можно следующим образом:

cd /
umount /mnt/vmdk1
umount /mnt/vmdk6

Успешных Вам новых установок и обновлений CUCM!

Самая свежая информация о продуктах и решениях унифицированных коммуникаций Cisco в потоке «Технологии для совместной работы» на Cisco Connect в Москве (17-18 ноября)

Источник