Подскажу ещё одну технологию для предотвращения записи концертов (потребуется лишь смена прошивки).
Не требуется никакая дополнительная аппаратура, кроме картона и местного художника.
Технология может быть с успехом применена на стадионах.
Ещё можно, например, снимать фильмы на фоне декораций с qr-кодами.
amarao, скорее всего, вы правы, и использование xenstore — даже при том, что потребуется писать xenstore-read для винды — более красивый и правильный вариант, поэтому я разберусь в том, как его реализовать и насколько сложно это будет для нас.
Рад, что пост получился таким продуктивным — я получил идеи ускорения текущего варианта решения своей задачи (хотя, скорее всего, мы от него и откажемся), и несколько идей, о которых совершенно не имел понятия — спасибо.
К сожалению (или счастью), xen занимается наш админ, и я плохо разбираюсь в том, как происходит виртуализация устройств. Поэтому пока не могу вести диалог с вами на этом уровне.
Однако, даже если виртуализированные устройства читают свои настройки из xenstore, это ничего не меняет в моём утверждении, что MAC можно передать через настройки сетёвки (а потом получить стандартными средствами винды), а IP — нельзя.
Это верно?
Я это понимаю следующим образом.
Xen эмулирует устройство — сетевую карту.
Думаю, что для винды это сэмулированное устройство ничем не отличается от реальной сетёвки.
Сетёвки обязаны иметь параметр «MAC». Раз xen эмулирует устройство, он имеет возможность установить этот параметр для сэмулированной сетёвки, соответственно, мы имеем возможность этот параметр задать в конфиге.
Если это так, то:
1) xenstore тут ни при чём
2) передача IP через параметры сетёвки таким способом невозможна, поскольку стандартные сетёвки не несут на себе сведений об IP
Смотрите, MAC на винде я могу получить стандартными для винды способами. Преобразовать его в IP — пара строчек в скрипте.
Ваш вариант позволит получить сразу IP, однако для этого придётся писать обёртку к xenstore-read. По-моему, это в данном случае совершенно лишнее звено.
>> делать это может скрипт, который машину клонирует
скрипт так и делает, то прописывает MAC, а не IP.
>> Дальше VM при старте смотрит свой IP и назначает его.
Я был уверен, что IP невозможно напрямую передать в VM…
Поясните, пожалуйста, какими именно средствами VM смотрит на свой IP и как назначает его? Кто этим занимается, сама VM или каким-то образом xen? Какой именно атрибут испльзуется для того, чтобы прописать IP? Это имеет отношение к xenstore, или это уже другой вариант?
>> смена алгоритма генерации IP потребует изменения в одном месте и будет применена к существующим машинам (после их перезагрузки
это есть и при текущем подходе, всеми IP заведует ядро системы.
Правильно я понимаю, что предварительно придётся:
1) конфигурировать каждый xen в облаке дополнительно, устанавливая соответствие типа имя домена-IP
2) как следствие, общий пул адресов разобъётся ещё на пулы для каждого из xen-серверов
3) нельзя будет использовать произвольные имена VM?
Кроме того, очевидно, ядро системы опять-таки будет вынуждено знать о настройках каждого из xen.
Чем этот вариант лучше варианта с DHCP?
gribozavr, вот это отличные новости, спасибо за эксперимент!
Я попрошу нашего админа проверить то же самой на нашей конфигурации — если всё так, то тогда mac2ip снимем и повесим на стенку в рамочку. Надеюсь, о нём хотя бы интересно было почитать:)
Нормальное завершение будет занимать несколько дольше, чем 2 секунды. Но ведь mac2ip на винде работает сопоставимое время.
Хм, я только сейчас сообразил, что решение мы выбирали тогда, когда работали только с VM на linux, поэтому mac2ip был идеальным во всех отношениях вариантом.
Собственно, сложность появилась только со временем работы на винде (правда, первый комментарий на пост открывает перспективы для оптимизации скрипта).
Если не удастся радикально сократить время работы скрипта на винде — то в целом получится, что преимущество в mac2ip только в том, что эта схема уже отлажена и надёжно работает.
Не требуется никакая дополнительная аппаратура, кроме картона и местного художника.
Технология может быть с успехом применена на стадионах.
Ещё можно, например, снимать фильмы на фоне декораций с qr-кодами.
Рад, что пост получился таким продуктивным — я получил идеи ускорения текущего варианта решения своей задачи (хотя, скорее всего, мы от него и откажемся), и несколько идей, о которых совершенно не имел понятия — спасибо.
Однако, даже если виртуализированные устройства читают свои настройки из xenstore, это ничего не меняет в моём утверждении, что MAC можно передать через настройки сетёвки (а потом получить стандартными средствами винды), а IP — нельзя.
Это верно?
Xen эмулирует устройство — сетевую карту.
Думаю, что для винды это сэмулированное устройство ничем не отличается от реальной сетёвки.
Сетёвки обязаны иметь параметр «MAC». Раз xen эмулирует устройство, он имеет возможность установить этот параметр для сэмулированной сетёвки, соответственно, мы имеем возможность этот параметр задать в конфиге.
Если это так, то:
1) xenstore тут ни при чём
2) передача IP через параметры сетёвки таким способом невозможна, поскольку стандартные сетёвки не несут на себе сведений об IP
Ваш вариант позволит получить сразу IP, однако для этого придётся писать обёртку к xenstore-read. По-моему, это в данном случае совершенно лишнее звено.
ага, понял, это хороший вариант для Linux.
Но я навскидку не нашёл, поэтому спрошу — есть ли xenstore-utils для Windows?
скрипт так и делает, то прописывает MAC, а не IP.
>> Дальше VM при старте смотрит свой IP и назначает его.
Я был уверен, что IP невозможно напрямую передать в VM…
Поясните, пожалуйста, какими именно средствами VM смотрит на свой IP и как назначает его? Кто этим занимается, сама VM или каким-то образом xen? Какой именно атрибут испльзуется для того, чтобы прописать IP? Это имеет отношение к xenstore, или это уже другой вариант?
>> смена алгоритма генерации IP потребует изменения в одном месте и будет применена к существующим машинам (после их перезагрузки
это есть и при текущем подходе, всеми IP заведует ядро системы.
1) конфигурировать каждый xen в облаке дополнительно, устанавливая соответствие типа имя домена-IP
2) как следствие, общий пул адресов разобъётся ещё на пулы для каждого из xen-серверов
3) нельзя будет использовать произвольные имена VM?
Кроме того, очевидно, ядро системы опять-таки будет вынуждено знать о настройках каждого из xen.
Чем этот вариант лучше варианта с DHCP?
Кстати, на всякий случай, какое значение lease-time сейчас у DHCP?
Даже жалко, что после комментария gribozavr и обсуждению с akshakirov mac2ip, скорее всего, не понадобится.
Я попрошу нашего админа проверить то же самой на нашей конфигурации — если всё так, то тогда mac2ip снимем и повесим на стенку в рамочку. Надеюсь, о нём хотя бы интересно было почитать:)
Хм, я только сейчас сообразил, что решение мы выбирали тогда, когда работали только с VM на linux, поэтому mac2ip был идеальным во всех отношениях вариантом.
Собственно, сложность появилась только со временем работы на винде (правда, первый комментарий на пост открывает перспективы для оптимизации скрипта).
Если не удастся радикально сократить время работы скрипта на винде — то в целом получится, что преимущество в mac2ip только в том, что эта схема уже отлажена и надёжно работает.