Как правильно делать Migration на Parallels Virtuozzo Containers 4.0 под Linux

Обоснованно на личном опыте.

  1. Первое правило хорошего админа – делаем Backup.
  2. Рекомендую. Обновить virtuozzo на обеих серверах.
  3. Обязательно! Обновить Контейнер и Template для него.
  4. Чтобы не было мучительно больно делаем Clone для Контейнера (необходимо свободное место на диске исходного сервера).
  5. Делаем Migration для клона и проверяем всё ли нормально заработало.
  6. И только потом делаем Migration для самого контейнера.

Так бывает, что некоторые системные файл в контейнере становятся недоступными. Нету этих файлов и в бакапах. Зато есть в Template.

Новый формат шаблонов под Linux который появился в четвёртой версии Виртуозы: EZ Templates (Дока) подразумевает, что common пакеты будут представлены во всех производных контейнерах в виде ссылки на файлы из Шаблона.

Файлы эти хранятся в виде кеша в папке /vz/template/cache/

Только вот Migration необходимые файлы из Шаблона не переместит. Как пишут в форуме на http://forum.parallels.com/ это какой-то неведомый баг в самом Migration который тянется ещё из бох знает какой версии и так быть не должно. Но оно так.

Как результат наша перемещённая WM наполнена битыми ссылками и кучей нерабочих сервисов. Не помогает ни обновление самого контейнера, ни обновление Шаблонов. Не получилось у меня починить такую VM и другими способами. Дело в том, что такие «волшебные файлы» удалить не получиться.

Немного из результата выполнения команды ls -la /etc/apache2/mods-available/
.
.
ls: cannot access /etc/apache2/mods-available/negotiation.load: No such file or directory
ls: cannot access /etc/apache2/mods-available/dir.load: No such file or director
total 32
drwxr-xr-x 2 root root 4096 2009-11-14 13:56 .
drwxr-xr-x 7 root root 1404 2010-01-28 14:13 ..
.
.
?????????? ? ? ? ? ? deflate.conf
?????????? ? ? ? ? ? deflate.load
-rw-r--r-- 1 root root 122 2008-10-01 18:32 dir.conf
?????????? ? ? ? ? ? dir.load
-rw-r--r-- 1 root root 604 2008-10-01 18:32 disk_cache.conf

Решение проблемы с рассинхронизации шаблонов

Перед перемещением контейнера (можно и после но время простоя увеличиться) надо синхронизировать Шаблоны контейнеров.
На стороне виртуозы с которой переносим контейнер, выполняем:

# rsync -avz -e ssh /vz/template/debian DESTANETION_IP:/vz/template

  • пути заменить на свои
  • DESTANETION_IP – заменить на адрес второго сервера

На второй виртуозе выполняем:
# vzpkg update cache debian-4.0-x86_64
debian-4.0-x86_64 заменить на имя вашего шаблона.

Сначала проверяем на клоне.
Потом перемещаем боевой сервер.

Virtuozzo Migrate Error

Собираю сервер.
Устанавливаю последнюю версию CentOS 5 x64 через net install
Обновляю ось через yum
Устанавливаю последованию версию Parallels Virtuozzo Containers 4.0 под Linux
Линкую новый Nod в PIM
Перемешаю первый VPS – всё Ок
Перемешаю второй…

Container start failed

Operation start with the Env(s) vpsname is finished with errors: Error invoking external utility: vzctl start 108 failed: Starting Container ... Container is mounted Setup slm memory limit Setup slm subgroup (default) Setting devperms 20002 dev 0x7d00 Setup ioprio: 4 Adding port redirection to Container(1): 4643 8443 Adding IP address(es) to pool: Adding IP address(es): x.x.x.x/bin/cp: preserving times for `/etc/network/interfaces.5303': Bad address ERROR: Can't copy file /etc/network/interfaces Container is unmounted Container start failed.

Не перемещается…
Выключаю VPS, снова перемещаю – всё Ок.
Теперь стартуем… опять ошибка:
Operation migrate_v2v with the Env(s) "vpsname" is finished with errors: Can not migrate: exec vzmsrc failed [512] : Connection to destination node (x.x.x.x) is successfully established Moving/copying CT#100 -> CT#100, [], [] ... Checking external bind mounts Check cluster ID Checking keep dir for private area copy Checking SLM-only mode Checking license restrictions Checking technologies Checking disk usage space Checking templates for CT copy ez template area directories vzctl failed, exitcode=46 Can't move/copy CT#100 -> CT#100, [], [] : vzctl failed, exitcode=46 vzctl : Hostname for Container set: vpsname vzctl : File resolv.conf was modified Checking caches Checking IP addresses on destination node Check target CT name: cloned novushost Checking RATE parameters in config Tracker started Copy private area '/vz/private/100' done OfflineManagement CT#100 ... done Stopping CT#100 ... done Syncing tracked files from '/vz/private/100/fs' done Starting CT#100 ... done OfflineManagement CT#100 ... done .

пробую ручками:
# vzctl start 101
Starting Container ...
Container is mounted
Setup slm memory limit
Setup slm subgroup (default)
Setting devperms 20002 dev 0x7d00
Setup ioprio: 4
Adding port redirection to Container(1): 4643 8443
Adding IP address(es) to pool:
Adding IP address(es): x.x.x.x
/bin/cp: preserving times for `/etc/network/interfaces.30043': Bad address
ERROR: Can't copy file /etc/network/interfaces
Container is unmounted
Container start failed

Пробую обновить перед перемещением VPS – тот же результат.

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

Ядро после установки: 2.6.18-028stab059.6
Обновилось до: 2.6.18-028stab067.4

Всё работает норм.

VMware workstation 6.5 проблема с загрузкой после установки

Описание

После установки VMware workstation система грузиться несказанно долго. Фактического зависание не происходит, но я смог загрузиться прождав минут 30.

Актуально для:

VMware workstation 6.5 всех сборок включая последнюю VMware workstation 6.5.3 (Для предыдущих не тестировал).

Windows 7, Vindows Vista (для предшествующих не проверял).

Глюк проявляеться не всегда.

Виновник

Windows Служба «VMware Authorization Service» ака VMAuthdService

лежит тут:

«C:\Program Files (x86)\VMware\VMware Workstation\vmware-authd.exe»

Решение:

  1. Перезагружаемся в Safe mode
  2. Изменяем Startup type для службы VMware Authorization Service из Automatic в Automatic (Delayed Start)

Всё.

По материалам:
http://communities.vmware.com/thread/202253