×

Предупреждение

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

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

Документ

пт, 10/23/2015 - 03:06
окт 22nd, 2015
User Badges:
  • Cisco Employee,

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

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

http://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-installation-guides-list.html

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

Раньше, когда деревья были большими и ПО устанавливалось на физические сервера, можно было бы загрузиться с 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 файла:

ls –la /mnt/nas

-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

ls –la /mnt/vmdk6

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 ноября)

 

Loading.

Действия

Информация о документе