Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 29
ну если «оверхед» еще куда ни шло, но вот «гвест» и «скедулинг» — это уже перебор. Зачем так мучить наш язык?
Хост/гвест уже устоявшаяся терминология. насчёт скедулинга — неправ, сейчас поправлю.
вы хотели сказать host/guest? Или хост/гость? Если у вас в голове что-то устоялось, это никак не значит, что у всех вокруг. И если вы произносите английское слово в вербальном общении, то это никак не означает, что писать нужно по принципу «как слышу».
Да, я пишу и произношу «тред» вместо «поток», «стрим» вместо «поток» и «пайп» вместо «конвеер». Извините, это экономит слишком много времени, чтобы отдаваться на растерзание русификации.
Но (чтобы обрадовать), я могу иногда написать МСЭ вместо файрвол.
Но (чтобы обрадовать), я могу иногда написать МСЭ вместо файрвол.
пусть это экономит вам время в личной переписке. В публичных статьях все-таки принято придерживаться норм языка.
А то потом прилетят автоботы и начнут изучать наш язык из Интернета — чему они научатся?
А то потом прилетят автоботы и начнут изучать наш язык из Интернета — чему они научатся?
Много чему. Думаю, не больше, чем военным дотам (вместо точек), панталонам (вместо штанов), рандеву (вместо встречи) и и.д.
Я вот недавно обнаружил, что американцы словом «блог» называют не только блоги, но записи в блоге (я вчера написал блог в блог). А мы слово заимствовали, оно прижилось. Чем больше слов есть, тем богаче язык. От того, что у нас рядом с калькулятором образовался компьютер, только лучше стало (меньше путаницы). Так и тут. Ну будет ещё слово «гвест» помимо «гость» — хуже будет? Было одно слово, стало два.
Я вот недавно обнаружил, что американцы словом «блог» называют не только блоги, но записи в блоге (я вчера написал блог в блог). А мы слово заимствовали, оно прижилось. Чем больше слов есть, тем богаче язык. От того, что у нас рядом с калькулятором образовался компьютер, только лучше стало (меньше путаницы). Так и тут. Ну будет ещё слово «гвест» помимо «гость» — хуже будет? Было одно слово, стало два.
почему гвест то?
guest читается как гест и никак иначе.
А то я пока не прочитал комменты не понял че за гвесты такие. Что за странная технология, которую я не слышал.
guest читается как гест и никак иначе.
А то я пока не прочитал комменты не понял че за гвесты такие. Что за странная технология, которую я не слышал.
«Гвест» не экономит вам времени по сравнению с гостем, читается/произносится сложнее, заимствование неочевидно и просто выглядит уродливо.
Почти ничего не понял о чем вы здесь, но тема интересная, кто бы объяснил доступнее :)
Идея, в принципе, интересная.
С другой стороны — такая кросс-совместимость между разными гипервизорами попросту не нужна: я не представляю задач, когда гостевую ОС придется переносить с одного гипервизора на другой, кроме миграции ИТ-инфраструктуры на другую платформу. А это задача совсем не частая,, и ради этого что-то еще разрабатывать — это уже чересчур.
Теоретически это сделать можно даже сейчас. Но — зачем? Можно и dial-up через VoIP сделать…
С другой стороны — такая кросс-совместимость между разными гипервизорами попросту не нужна: я не представляю задач, когда гостевую ОС придется переносить с одного гипервизора на другой, кроме миграции ИТ-инфраструктуры на другую платформу. А это задача совсем не частая,, и ради этого что-то еще разрабатывать — это уже чересчур.
(улетая в фантазию) а ещё будет тунелирование гипервизоров (примерно как сейчас ip over ip, GRE и т.д.) — будет гипервизор xen, в котором будет гипервизор vmware, который будет способен запустить гипервизор от quest'а,…
Теоретически это сделать можно даже сейчас. Но — зачем? Можно и dial-up через VoIP сделать…
Тут, скорее, вопрос не в том, «зачем нам запускать линукс на hyper-v», а в том, что это будет принципиальная смена вычислительной модели; операционные системы перестанут (хотя бы в одной из конфигураций ядра) думать про железо. Возможно, они же обленятся достаточно серьёзно, чтобы вынести учёт и планирование на гипервизора же (или на формализовавшуюся прослойку, это делающую). Не хотите попробовать винды с планировщиком от какой-нибудь realtime ОС погонять? :)
Получающиеся компоненты будут так же независимы, как, например, независим http от нижележащего уровня. И вопрос стоит даже не «попробовать», а «как удобнее».
Получающиеся компоненты будут так же независимы, как, например, независим http от нижележащего уровня. И вопрос стоит даже не «попробовать», а «как удобнее».
Для этого понадобится очень сильная унификация как железа — так и ПО. При нынешней ситуации это — практически нереально.
Унификация железа идёт во все поля. Классы устройств USB унифицированы, AHCI унифицирован, видеокарты раньше были унифицированы (VESA, VLB), потом разбежались, но никто им не мешает сбежаться обратно (в форме поддержки стандартизированных вызовов opengl).
Стандартизация же ПО (в смысле userspace) не требуется, т.к. существующие ядра как на гипервизоре, так и на железе одинаковый ring-3 делают.
Стандартизация сильно майкрософту жизнь подпортит, да (нафига платить за платный middleware, когда можно взять opensource). Но им жизнь и так активно портят :)
Стандартизация же ПО (в смысле userspace) не требуется, т.к. существующие ядра как на гипервизоре, так и на железе одинаковый ring-3 делают.
Стандартизация сильно майкрософту жизнь подпортит, да (нафига платить за платный middleware, когда можно взять opensource). Но им жизнь и так активно портят :)
В первую очередь необходима унификация процессоров. На данный момент архитектура процессоров разных вендоров, а иногда — даже разных линеек — сильно различается.
Это позволит избавиться от проблем с корявыми драйверами и избавиться от львиной доли кода, связанной с поддержкой разных типов железа. Софт от этого улучшится весь, конкретных преимуществ MS, IBM, Oracle или какому-то другому вендору это не даст.
Стандартизация сильно майкрософту жизнь подпортит, да (нафига платить за платный middleware, когда можно взять opensource).
Это позволит избавиться от проблем с корявыми драйверами и избавиться от львиной доли кода, связанной с поддержкой разных типов железа. Софт от этого улучшится весь, конкретных преимуществ MS, IBM, Oracle или какому-то другому вендору это не даст.
because we can
Виртуализация медленно, но уверенно становиться очень перспективной и быстроразвивающейся отраслью IT, и в этом нет ничего удивительного. Эталонной модель взаимодействия станет тогда, когда производители серверных решений станут выпускать чипсеты с уже встроенным гипервизором, а разработчики ОС научат свои детища нормально с ним работать
А зачем гипервизор встраивать в чипсет? Всё равно и так и так гипервизору нужен dom0, так что в любом случае что-то помимо VM грузится будет. Несколько мегабайт гипервизора в этом месте совершенно не будут мешать.
А что значит, встраивать в чипсет? Производители (HP, IBM, DELL) уже предлагают серверы с предустановленными гипервизороми (на USB-flash'ке или SD карте).
Хотелось бы услышать про схему взаимодействия с периферийными устройствами в рамках данной модели. Разные принтеры, сканеры и прочее железо для которого требуется установка дополнительных драйверов.
принтеры-сканеры имеют две составляющие: во-первых они принтеры/сканеры (высокоуровневый интерфейс, который умеет смотреть на лотки, двустороннюю печать и TWAIN), а во-вторых у них есть физический интерфейс. Как известно, большинство принтеров даже при работе по сети требует установки хотя бы имитации в форме драйвера.
Возможно, хосты будут анонсировать принтеры по сети (внутренней, виртуальной, или, даже, внешней), вплоть до эмуляции PS/PCL для убогих недопринтеров с host-based печатью.
Всякого рода устройства с well-known classes (HID, MSD) будут работать аналогично. Туннелирование openGL вполне представимо; что будет делать MS с директХе? (ну, будет двигать снова свой вендор-лок, в каком-нибудь hyperX). С графикой в линуксе будет проще, чем с остальным — в принципе, никто не мешает иметь несколько dom0 (точнее не 0, а имеющих право работать с железом) — и в одном из них запускать x-server.
Возможно, хосты будут анонсировать принтеры по сети (внутренней, виртуальной, или, даже, внешней), вплоть до эмуляции PS/PCL для убогих недопринтеров с host-based печатью.
Всякого рода устройства с well-known classes (HID, MSD) будут работать аналогично. Туннелирование openGL вполне представимо; что будет делать MS с директХе? (ну, будет двигать снова свой вендор-лок, в каком-нибудь hyperX). С графикой в линуксе будет проще, чем с остальным — в принципе, никто не мешает иметь несколько dom0 (точнее не 0, а имеющих право работать с железом) — и в одном из них запускать x-server.
Золотая идея! Виртуализацию на каждый ПК!
Пусть юзеры покупают новое железо :)
Пусть юзеры покупают новое железо :)
Собственно, к моменту, когда это будет более-менее применимым для десктопа, железо пять поколений как VT поддерживать будет. Кроме того, паравиртуализация ничего от железа не требует (поддержка гипервизора в ядре гвеста программная).
VMware (Client Virtualization Platform) и Citrix (Xen Client) ведут работу в данном направлении.
Какие-то шаги XenCloud уже делает — есть xva формат, который претендует на роль «кроссгипервизорного» формата виртуальных машин.
Уже есть .ovf — вполне себе кроссплатформенный.
Однако, сами ОС всё равно остаются «комбайнами». Виртуализация под них подстраивается, хотя куда более правильным было бы разрабатывать ОС, которые способны работать ТОЛЬКО при участии гипервизора.
Это лишь приведет к тому, что с рынка начнут выдворять производителей гипервизоров у которых нет собственных ОС.
Можно будет взять гипервизор от windows, промежуточный слой от linux и userspace от solaris. Или наоборот — взять xen, ядро linux, а на нём уже несколько различных систем, спокойно сосуществующих друг с другом.…
И какой в этом смысл? Гипервизор — это законченный продукт с вполне определенным функционалом, в отличии от описания стека протоколов как OSI или TCP/IP. Что вы получите, если «губы Никанора Ивановича приставите к носу Ивана Кузьмича»?
Например, возможность переноса вычислительной машины из одной инфраструктуры в другую, без шаманства вида vmware convert. Грубо говоря — в одном дата-центре используют hyper-v. В другом ESX, в третьем xencloud. Берёшь, с одного на другой переносишь свою ОС — и оно всюду работает без доработки напильником.
Разные гипервизоры по-разному эмулируют виртуальное железо. В любом случае, вам потребуется устанавливать компоненты интеграции от соответствующего производителя. Опять же, процедура переноса — это не ежедневная операция и использовать средства v2v конвертации не так уж обременительно. Куда уж сложнее двум хостерам договориться о том, чтобы виртуальную машину можно было скопировать из одного ЦОД в другой.
Во-первых, я говорю про паравиртуализацию. Т.е. никакого «эмулирования железа» там нет, а есть чёткое понимание гестом существования гипервизора (а так же понимания, что всё железо — проблема гипервизора).
Во-вторых, я как раз про это и говорю — стандартизация интерфейсов; без этого дальнейшее развитие будет мучительным тяганием одеяла с мёрзнущего дитяти в свою сторону. Одеяло, может и дотянешь, да дитятя будет хилым.
Во-вторых, я как раз про это и говорю — стандартизация интерфейсов; без этого дальнейшее развитие будет мучительным тяганием одеяла с мёрзнущего дитяти в свою сторону. Одеяло, может и дотянешь, да дитятя будет хилым.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эталонная модель взаимодействия вычислительных систем?