Цитата:
alexeiЦитата:
"Например, это жёсткий диск с его контроллером." - здесь "жёсткий диск" оевидно означает устройство, а не хранимые данные ( иначе абсурд: данные с их контроллером).
Далее "Контроллер диска действительно разделить нельзя" smile.gif
Понимая "диски" в вышеприведённом контексте, "диски делить приходится постоянно" означает разделение не данных а устройств (а этого никто не делает).
Кто из нас тут говорит глупости? laugh.gif
Кстати, для SCSI это не вегда верно, но не будем лезть в дебри
Вы, уважаемый, говорите глупость, Вы. Делятся именно физические устройства -- диски, а разделение информации на них -- лишь следствие деления контроля над аппаратурой. Например, каждой из виртуальных машин выделяется часть диска (если угодно -- раздел, хотя это вовсе не обязательно). И от того, SCSI диск, ATA или вообще доисторический мэйнфреймовый, ничего принципиально не меняется. И как же Вы собираетесь работать с такими "разделёнными" дисками? Как я понял, Ваш ответ вот:
Цитата:
Ниже "диск" означает не устройство, а совокупность данных на нём.
Отображать виртуальный диск на физический можно либо транслируя LBA, либо " закрывая (делая недоступным) "чужой" раздел в MBR. Оба варианта имеют свои преимущества и недостатки.
И, конечно, ОС, разделяющие диск, никак не могут (и не должны иметь возможности) определить, что имеют дело с виртуальным диском.
Объясняю подробнее. Если нужно, чтобы две ОС имели доступ каждая к своему разделу диска, то этот диск выделяется не им, а серверу диска (третьей ОС), который предоставляет каждой ОС виртуальный диск, так что обращения к секторам виртуального дика преобразуются к обращениям к соответствующим секторам физического диска (кроме нулевого цилиндра). Понятно, или нужно разжевать ещё подробнее?
Кстати, Я предпологаю разделение дсика между ОС как "каждой ОС свой раздел". Это-ли Вы имели в виду? Если нет, то что?
Начну с конца.
"Каждой ОС свой раздел" -- это частный случай. Разделов может не быть вовсе (в конце концов, разделы
в том виде, что мы имеем, обязаны своим появлением небольшой конторе из Редмонда и являются не слишком удачной идеей). Если говорить обобщённо, каждой виртуальной машине предоставляется произвольная часть диска, не обязательно состоящая из смежных секторов. Впрочем, это замечание не меняет картину принципиальным образом.
"И, конечно, ОС, разделяющие диск, никак не могут (и не должны иметь возможности) определить, что имеют дело с виртуальным диском" -- и да, и нет. Обычная ОС не должна знать, что она работает на виртуальной машине, однако, по-хорошему, должны быть средства взаимодействия между "умной" ОС и гипервизором (пусть будет этот термин, если он Вам нравится -- на самом деле он не всегда подходит, ну да ладно, не об этом речь), что способно повысить эффективность работы ОС на виртуальной машине. Но пока оставим вторую возможность и посмотрим на обычные "глупые" ОС, которые должны оставаться в неведении.
"Отображать виртуальный диск на физический можно либо транслируя LBA, либо " закрывая (делая недоступным) "чужой" раздел в MBR" -- насколько я понял, второй способ связан с подсовыванием гостевой ОС фальшивой MBR, чтобы означенная ОС и не догадывалась, что на диске имеются другие разделы, помимо её собственного. В таком случае согласен с обоими вариантами. Однако имеется один маленький вопросик: а как Вы намереваетесь технически их осуществлять? Как, например, отобразите виртуальный диск на физический, т.е. как выполните трансляцию LBA? (кстати говоря, только этот способ и является верным, второй недопустим на практике -- тогда гостевая ОС сможет похерить чужие разделы, поскольку будет считать, что занимаемое ими пространство не используется)
"Объясняю подробнее. Если нужно, чтобы две ОС имели доступ каждая к своему разделу диска, то этот диск выделяется не им, а серверу диска (третьей ОС), который предоставляет каждой ОС виртуальный диск, так что обращения к секторам виртуального дика преобразуются к обращениям к соответствующим секторам физического диска (кроме нулевого цилиндра). Понятно, или нужно разжевать ещё подробнее?" -- вероятно, это Вы считаете ответом на мой заданный выше вопрос. Однако попрошу разжевать поподробнее. Как технически гостевые ОС будут взаимодействовать с "сервером диска"? Не обязательно писать последовательность машинных инструкций, осуществляющих сей процесс (потому что это будет не одна сотня, если не тысячи, строк кода на ассемблере), но обязательно объяснить идиоту (т.е. мне), как Вы собираетесь это сделать.
Цитата:
Про x386 у меня где-то была ссылка с перечислением всех (как помню, 18) проблем (хотя достаточно и одной). Если найду, сообщу. А мне вполне достаточно того, что они есть, что означает невозможность написания простого гипервизора для x86 процессоров которые не имеют аппаратной поддержки виртуализации
Знаете, Ваш ответ показывает, что Вы "слышали звон, да не знаете, где он", ну или говоря проще -- плохо знаете матчасть, в данном случае архитектуру IA32 (она же x86). Прошу не рассматривать это как личный наезд: как человек Вы мне совершенно неизвестны, и делать вывод, что в "общечеловеческом" плане Вы из себя представляете, мне просто не на чем. Мой наезд касается исключительно Вашей... гм... скажем так, квалификации в вопросах системного программирования.
Мне упомянутый список не требуется: если я посижу да подумаю, я и сам его составлю. Сходу могу назвать как минимум две причины: в IA32 есть целый ряд команд, которые сообщают программе
пользовательского режима параметры, напрямую связанные с управлением памятью; кроме того, команды загрузки селекторов сегментов (типа mov ds, ax или там длинных переходов) также являются непривилегированными, что не даёт возможность проконтролировать их использование сколько-нибудь нормальным образом.
Итак, как технически, а не в общих словах, Вы собираетесь предоставлять доступ к одному диску нескольким гостевым системам?
//SII 21.11.2007, 22:22 Ну во-первых спор о том кто глупее по поводу "деления" диска, похоже, чисто лингвистический :) Делить (="share"="совместно использовать") диск в смысле "контроля над аппаратурой" нельзя, т.к. эта аппаратура совместное использование (т.е. параллельное обслуживание запросов), т.е. "разделение" не поддерживает.
Разделение
устройств (например, принтера - shared printer) обеспечивается ОС путём
последовательного использования аппаратуры принтера, при этом аппаратура прнтера не разделяется в смысле "не используется совместно" в смысле "не используется одновременно"..
Можно ли вместе пить из одной бутылки? Оба возможных ответа могут быть названы глупыми (с объясненияим основанными на противоположной интерпретации контекста).
Менять контекст по мере объяснения не приято.
MBR - формат весьма распространённый. См. наприер
http://www.win.tue.nl/~aeb/partitions/partition_types-1.htmlЕстественно иметь хоть какую-то совместимость с другими ОС.
Взаимодействие "гостевых ос" с сервером диска.
Коротко о "гостевых": у меня нет закреплённых Host и Guest "ролей", хотя в отношении конкретного ресурса можно говорить о Host-Guest отношениях.
Итак, Гипервизору (ГП) из описания сервера или от самого сервера известно, какой ресурс этот сервер предоставляет. Аналогично, некая ОС запрашивает и получает этот ресурс.
В ресурсом может быть:
1. виртуальное железо: емулятор на сервере, "обычный" драйвер на ОС
2. отображённое железо: транслятор на сервере, "обычный" драйвер на ОС
3. абстрактное устройство: socket на сервере, специальный драйвер на ОС
Естественно, п.3. может иметь множество разновидностей.
Предвижу вопрос: А какой конкретный протокол?
Ответ: любой, какой сочтёте нужным. ГП предоставляет поддержку для "inter-VM communications", т.е. межмашинного обмена. Предполагается, что автор сервера, использующего собственный протокол, опишет этот протокол и преставит клиента для одной или более ОС (ему он всё-равно нужен для отладки и тестирования).
Предвижу вопрос: А какую ГП предоставляет поддержку?
Ответ: предполагаю: pipes, shared memory, interrupts, read/write traps, хотя детали прояснятся в процессе разработки.
Кроме "квалификации" существуют многое другое. Один запоминает доказательство теоремы, другой помнит идею доказаельства, третий - куда он её положил, и т.д. Я ни ОС ни гипервизор сейчас не пишу, а занимаюсь дизайном системы. С чего-бы это мне вдруг помнить о деталях проблемы, которая просто отсутствует в случае аппаратной виртуализации (а без неё я принципиально не хочу уродоваться).
Кстати, "тогда гостевая ОС сможет похерить чужие разделы, поскольку будет считать, что занимаемое ими пространство не используется)" - неврно, т.к. MBR виртуальная даже в этом случае и сервер диска не даст её в обиду "гостям".
LBA+n, где n - это сешение выделенного раздела от начала диска.Чего тут объяснять?
"Итак, как технически, а не в общих словах, Вы собираетесь предоставлять доступ к одному диску нескольким гостевым системам?"
Я так понимаю, что Вы уже убедились, что это возможно. Какой смысл обсуждать тех. детали сейчас, когда нет ни гипервизора, ни детальной спецификации его сервисных функций?
Повторяю. Здесь обсуждается архитектура и возможности системы. Детали реализации важны только если они существенны для этого обсуждения.
Вообще-то хотел узнать мнение разработчиков "самодельных" ОС к моей концепции. Пока кроме вопросов ничего не получил :(
Управление памятью и распределение процессора гораздо более интересные темы...
Блин, клепают ведь оси на коленке, которые очевидно пойдут коту под хвост, а сделать среду, чтобы каждый не писал всё с начала, никому не интересно. :(