[Devel] [Задача 7856] Недоступны виртуальные машины проекта Яуза

[Evgeny Sinelnikov]

12 ноября 2011 г. 13:08 пользователь Vitaly Lipatov <lav на etersoft.ru> написал:
> On Thu, 10 Nov 2011 20:08:22 +0400, Evgeny Sinelnikov wrote:
> ...
>>
>> Рабочее решение заключается в том, чтобы:
>> а) закомментировать в списке машин на автозагрузку пока не нужные и
>> начать разбираться с задачей 7717
>
> Половину машин Яузы? Давно пора, если это возможно.

А что нужно делать когда он всё вместе потребуется? Или в эту сторону
нормально костыли забивать? В смысле, это ведь тоже не решение, или
здесь можно закрыть глаза?

>> б) переместить виртуальный стенд на отдельный компьютер, освободив от
>> него virtualbox
>
> 1. Отдельный компьютер для стенда называется virtualbox
> 2. Проблему не решает, поскольку завтра будет задача запустить все виртуалки
> для нового проекта (буксира).

Тем более, вопрос не запускать часть виртуальных машин становится ещё
более неудобным.


>> в) переместить часть задач по запуску ВМ на локальные станции,
>> предоставив им в совместный доступ по сети копии образов.
>
> Это не решает проблему, а что будет, если VB не умеет блокировать
> используемые образы, страшно представить.

Что значит если? И почему образами должны пользоваться не согласованно?
Я вот регулярно подумываю над тем, чтобы посмотреть как то или иное
работает с разных вариантах дистрибутивов, но я не могу себе позволить
что-то кому-то ломать.

То есть virtualbox, для меня, в этом смысле  как бы недоступен:
- архивных образов никто не делает;
- достать оригинальный вариант установленной системы из первого снимка
(если его вообще делали)
 непонятно как;
- заново ставить систему некогда.


>> Причём третий вариант предполагает избавление от глюков GUI-обёртки и
>
> От локального запуска глюки вряд ли куда-то денутся.

Те глюки, о которых шла речь (оригинальную цитату ты убрал), локальный
вариант решает:
 "Стоит добавить что GUI обертка самого virtualbox довольно глючная
штука, особенно когда ей параллельно пользуется несколько человек."

Совершенно некорректно, я полагаю, применять такую риторику, при
которой суть ответа перестаёт рассматриваться в исходном контексте...

>> не просто хранение образов, которые постоянно меняются, а хранение
>> архива образов. Честно говоря, мне как-то странно, когда однажды
>> установленный образ Fedora 14, например, доступен всем на запись и
>> потенциально может быть убит почти любым. Что неужели никого не
>> смущает, что если образ сломают, то потребуется повторно тратить время
>> на его установку? А если не сломают, а обновят и ядро старое уже так
>> просто не вернуть?
>
> На эту тему у нас давно есть инструкция создавать снимки, так что не должно
> быть проблемой.

Это не то... Снимки только ухудшают проблему.

Вот, например, я хочу попробовать что-то на федоре (установить
FreeIPA, например). Мне нужен для этого установленный образ. Чтобы его
получить я могу установить его сам, но для этого нужно скачать образ
установочного диска и некоторое время потратить на установку.

Предположим, что нужный выпуск федоры есть у нас на virtualbox'е. Я не
хочу его оккупировать под свою задачу, я хочу сделать клон и, возможно
не один (сервер и клиенты). Как мне с этим быть, если у нас сделаны
снимки?

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

В связи с этим необходим архив образов. Требования здесь следующие:
- требуется иметь "чистую систему":
 - для того, чтобы иметь возможность проверить так, как всё выглядит
после установки (включая ядро);
 - для того, чтобы не перемешивать настройки сделанные в рамках
решения одной задачи, с настройками новой задачи;
 - для того, чтобы не думать о том, что стоит всё установить с нуля
для полноценной проверки.
- требуется иметь возможность скопировать образ для локального запуска:
 - для того, чтобы запустить и локально проверить своё решение не
только в офисе, но мне в Саратове;
 - для того, чтобы быстро восстановить нужный образ из архива, а не
искать виртуальную машину, которую кто-то удалил;
 - для того, чтобы сделать на основе архивных образов новые тестовые
решения, не боясь, их сломать.

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

>
> И, главное, я не понимаю, почему рабочее решение не заключается в
> исправлении очевидной баги?

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

> Как извернуться из ситуации, все и так знают, и то или иное решение для себя
> нашли.

Не вижу в нахождении рабочих решений ничего плохого. Не понимаю почему
их нужно называть изворачиванием.

> Но мне казалось, сейчас времена общих сервисов, а не запуска программ на
> персоналках.

Это всё кажущееся...
У меня студенты на нетбуках Idea запускают, которая на Core 2 Duo, без
двух гигов памяти еле шевелится, и ничего так - работают...

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



-- 
Sin (Sinelnikov Evgeny)
Etersoft