Про эмуляторы виртуальных машин.

[SLEDopit]

Я же сказал, общие папки не катят, они медленно работают, нужен прямой доступ.

А вот img диски qemu можно прям монтировать в хост системе :P

[Kopilov]

Вопрос к zombie и другим пользователям VmWare.
Я впервые познакомился с ним (и с виртуальными машинами вообще) на занятиях по сетевому администрированию, когда мы на VmWare Workstation запускали Windows Server 2003 на XP-хостах (хосты -- аудиторные машины, виртуальные харды с предустановленными системой и гостевыми дополнениями раздавал преподаватель). Тогда меня больше всего удивило, что без всяких общих папок можно перетащить файл с рабочего стола хоста на рабочий стол гостя и обратно.
Вопрос: это стандартная фича VmWare? Зависит ли она от его версии? Работает ли с Linux?

[Davinel]

Я же сказал, общие папки не катят, они медленно работают, нужен прямой доступ.

Прямой доступ к чему? Если к хост системе то это и есть прямой доступ, прямее некуда.
Если к гостевой - vdi в принципе можно примонтировать, если оно фиксированого размера.

[zombie]

Прямой доступ к чему?

К девайсу.

[Davinel]

К девайсу.

Моя понимать вас нет.
К какому девайсу?


btw любые возможные преимущества vmware меркнут перед тем, что оно тупо не смогло скомпилить модули на моей системе.

[zombie]

К какому девайсу?

/dev/sdb3

btw любые возможные преимущества vmware меркнут перед тем, что оно тупо не смогло скомпилить модули на моей системе.

Какое это имеет отношение к vmware? К вашей системе, да, имеет, к vmware - нет.

[Bizdelnick]

Какое это имеет отношение к vmware?

Так её патчить приходится при установке, а не систему. Если Вам повезло, и всё сразу завелось - поздравляю. А теперь подсчитайте, сколько в этой теме сообщений людей, которым пришлось с этим основательно повозиться. И это почти исключительно те, кто осилили, а неосиливших наверняка в разы больше.

[Ali1]

Хороший!

Код: Выделить всё

Using 2.6.x kernel build system.
make: Вход в каталог `/tmp/vmware-root/modules/vmmon-only'
make -C /lib/modules/2.6.35.6-45.fc14.i686/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. \
  MODULEBUILDDIR= modules
make[1]: Вход в каталог `/usr/src/kernels/2.6.35.6-45.fc14.i686'
  CC [M]  /tmp/vmware-root/modules/vmmon-only/linux/iommu.o
/tmp/vmware-root/modules/vmmon-only/linux/iommu.c: В функции ‘IOMMU_SetupMMU’:
/tmp/vmware-root/modules/vmmon-only/linux/iommu.c:103:28: предупреждение: приведение указателя к целому другого размера
/tmp/vmware-root/modules/vmmon-only/linux/iommu.c:113:17: предупреждение: формат ‘%lx’ предполагает тип ‘long unsigned int’, но аргумент 3 имеет тип ‘long long unsigned int’
/tmp/vmware-root/modules/vmmon-only/linux/iommu.c:117:35: предупреждение: приведение к типу указателя от целого другого размера
/tmp/vmware-root/modules/vmmon-only/linux/iommu.c:120:20: предупреждение: формат ‘%lu’ предполагает тип ‘long unsigned int’, но аргумент 3 имеет тип ‘uint64’
/tmp/vmware-root/modules/vmmon-only/linux/iommu.c:156:7: ошибка: неявная декларация функции ‘iommu_map_range’
/tmp/vmware-root/modules/vmmon-only/linux/iommu.c: В функции ‘IOMMU_VMCleanup’:
/tmp/vmware-root/modules/vmmon-only/linux/iommu.c:403:7: ошибка: неявная декларация функции ‘iommu_unmap_range’
/tmp/vmware-root/modules/vmmon-only/linux/iommu.c: В функции ‘IOMMUUnregisterDeviceInt’:
/tmp/vmware-root/modules/vmmon-only/linux/iommu.c:216:17: предупреждение: ignoring return value of ‘device_attach’, declared with attribute warn_unused_result
make[2]: *** [/tmp/vmware-root/modules/vmmon-only/linux/iommu.o] Ошибка 1
make[1]: *** [_module_/tmp/vmware-root/modules/vmmon-only] Ошибка 2
make[1]: Выход из каталога `/usr/src/kernels/2.6.35.6-45.fc14.i686'
make: *** [vmmon.ko] Ошибка 2
make: Выход из каталога `/tmp/vmware-root/modules/vmmon-only'
[root@aliCQ ~]#

[/dev/random]

/dev/sdb3

Прямой доступ к блочным девайсам есть практически везде. Однако должен предупредить: когда с одним и тем же разделом напрямую работают одновременно 2 операционки, это может привести к потере данных. Я бы не стал рисковать. Есть только 2 способа избежать этой проблемы: пока раздел смонтирован в виртуальной машине, держать его отмонтированным на реальной, либо использовать общие каталоги.

[zombie]

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

Я заметил, и тем не менее иду на это.
Потому, что не записываю в этот раздел, когда использую виртуальную систему, потому, что это мне и не надо.

Есть только 2 способа избежать этой проблемы: пока раздел смонтирован в виртуальной машине, держать его отмонтированным на реальной, либо использовать общие каталоги.

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

[watashiwa_daredeska]

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

Вы всё делаете правильно: меньше знаешь — крепче спишь. :)

[Bizdelnick]

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

Интересно, какова будет судьба файла, если он будет изменяться из обеих осей...
Ладно-ладно, дело хозяйское, umount придумали трусы.

[frp]

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

Лучше отмонтировать его в хост-системе. Есть такой момент: в ext3, как и в ext2 (и во многих других ФС) есть специальный флажочек, который указывает, была ли размонтирована ФС. Если ФС не была размонтирована, система (особенно если в ней ФС монтируется как ext2) может счесть нужным fsck. Сами, думаю, понимаете, к чему это может привести. Также есть такая фича, как atime (для каждого файла прописывается время последнего доступа). Тоесть если не хочется отмонтировать, то в обеих системах нужно монтировать только для чтения.

[zombie]

Лучше отмонтировать его в хост-системе. Есть такой момент: в ext3, как и в ext2 (и во многих других ФС) есть специальный флажочек, который указывает, была ли размонтирована ФС. Если ФС не была размонтирована, система (особенно если в ней ФС монтируется как ext2) может счесть нужным fsck. Сами, думаю, понимаете, к чему это может привести.

Не понимаю, не знаю что есть fsck. Но спасибо за обучение) И все же как в vbox организовать доступ к разделу?

[Ali1]

VBoxManage storageattach <uuid|vmname>
--storagectl <name>
--port <number>
--device <number>
[--type dvddrive|hdd|fdd]
[--medium none|emptydrive|
<uuid>|<filename>|host:<drive>]
[--passthrough on|off]
[--forceunmount]

[Warderer]

Ali1
Вы что? Это же на английском! Это же не юзер-френдли!

[frp]

Не понимаю, не знаю что есть fsck.

fsck есть утилита для проверки файловой системы. На ext2 она автоматически запускается каждый n-й запуск системы (n выставляется при форматировании), а также если ФС не была отмонтирована корректно. На ext3 - каждый n-й запуск.
В случае если fsck внесет какие-либо изменения в ФС (а он умеет исправлять ошибки, а также помечает ФС как проверенную) во время записи в эту ФС, может произойти повреждение данных (и это не сказки, проверено ).

И все же как в vbox организовать доступ к разделу?

Как из гуи - не помню. А Ali1 привел правильный способ из консоли.

[zombie]

VBoxManage storageattach <uuid|vmname>
--storagectl <name>
--port <number>
--device <number>
[--type dvddrive|hdd|fdd]
[--medium none|emptydrive|
<uuid>|<filename>|host:<drive>]
[--passthrough on|off]
[--forceunmount]

Ачойто?

[Ali1]

Ачойто?

[Ali1]

Код: Выделить всё

$ sudo ls -l /root/.VirtualBox/my.vmdk
-rw-------. 1 root root 631 Ноя  4 23:50 /root/.VirtualBox/my.vmdk
[ali@aliCQ ~]$

ЗЫ
http://www.virtualbox.org/manual/ch09.html#id485530 Advanced storage configuration
ЗЫЫ
да,я предупреждал

[Davinel]

Какое это имеет отношение к vmware? К вашей системе, да, имеет, к vmware - нет.

Проблемы как раз у vmware. Система у меня замечательно работает и то, что их поделие у меня не собирается(не в первый раз кстати, далеко не в первый) означает, что они теряют потенциального клиента. И это ИХ проблемы - сделать так, чтобы модули собирались на моей системе. Виртуал бокс же собирается. И qemu. И kvm.

[Bizdelnick]

Проблемы как раз у vmware

Я их, честно говоря, вообще не понимаю. Они не могут не знать про существование проблем, и про существование устраняющих их патчей, но фиксить модуль самостоятельно не хотят. Или они исходят из того, что виртуалка будет использоваться только на дистрах типа RHEL с древним ядром?

[/dev/random]

Я их, честно говоря, вообще не понимаю. Они не могут не знать про существование проблем, и про существование устраняющих их патчей, но фиксить модуль самостоятельно не хотят. Или они исходят из того, что виртуалка будет использоваться только на дистрах типа RHEL с древним ядром?

На самом деле, поддержка сторонних модулей для ядра - это ад. Единственный способ обеспечить совместимость модуля со всеми версиями ядра - добиться включения модуля в официальное дерево. Очевидно, что когда модуль является небольшим фрагментом проприетарного продукта, включать его в официальное дерево никто не согласится.

[Bizdelnick]

На самом деле, поддержка сторонних модулей для ядра - это ад. Единственный способ обеспечить совместимость модуля со всеми версиями ядра - добиться включения модуля в официальное дерево. Очевидно, что когда модуль является небольшим фрагментом проприетарного продукта, включать его в официальное дерево никто не согласится.

Интересно всё же, почему для авторов патчей это оказывается проще, чем для разработчиков. Да и с другими сторонними модулями лично у меня проблем не было (хотя и нужны-то всего два - nvidia и VirtualBox).

[strah]

Интересно всё же, почему для авторов патчей это оказывается проще, чем для разработчиков. Да и с другими сторонними модулями лично у меня проблем не было (хотя и нужны-то всего два - nvidia и VirtualBox).

У драйверов nvidia есть проблемы с Xen.

[/dev/random]

Интересно всё же, почему для авторов патчей это оказывается проще, чем для разработчиков.

Эти патчи - уродливые хаки, включение которых в код затрудняет его дальнейшую поддержку. В качестве патчей они имеют право на существование, но прямо в код их включит только идиот.

У драйверов nvidia есть проблемы с Xen.

А также с PaX и многим другим.

[Bluetooth]

У драйверов nvidia есть проблемы с Xen.

А также с PaX и многим другим.

Еще бы. Они исходят из проприетарной модели разработки и от них никуда не деться. Хотя я вот уже делся. Наконец юзаю компьютер с интеловским видео. Правда, в этом компьютере была помимо интеловского интегрированного видео еще и нвидиевская quadro 285, тоже очень интересная модель для рабочей станции, но всилу отсутствия нормальных открытых дров она не пригодилась. Хотя я наверно ее установлю на виндовую рабочую станцию - среди тучи закрытого кода еще один закрытый компонент погоды не сыграет.

Да и с другими сторонними модулями лично у меня проблем не было (хотя и нужны-то всего два - nvidia и VirtualBox).

Сегодня их нет, а завтра эти долбаные модули не соберутся с какой-то нестандартной конфигурацией(которую, как на зло, никак не поменять, иначе не было бы никакой "нестандартной конфигурации"). Это если абстрагироваться от таких костылей, как dkms. И если не брать во внимание такую отвратительную штуку, как то, что, с трудом собранные под xen ядро nvidia дрова, при установке затерли несколько либ на свои. Лично я не знаю, как такое говно, откровенно портящее систему, может рассматриваться как что-то, отличное от "зла, неизбежно приобретенного с неправильной железкой". И, заметьте, я тут не касаюсь идеологических вопросов(чтобы не было обвинений в красноглазии и фанатизме), это чисто практические и технические моменты.

Кстати, из-за этих дров на нвидиа, стоящих у меня в системе когда-то, я не могу запустить 3d ускорение под интел, из-за того, что glx модуль для иксов и еще какие-то либы остались те, что были с нвидией. Разумеется, интеловские дрова к ним не подходят. Собсно, я сам себе злобный буратино. Нехрен тащить всякую каку в рот всякий закрытый говнокод в систему, да еще и в формате "невнятного бинарника". Но, с другой стороны, выбора у меня особого не было - менять железки у меня сейчас денег нет. И мне только повезло, что мне подвернулся брендовый делл 2007 года.

Но чтобы приобрести нвидиа карточку для линукс машины - таких мыслей у меня сейчас нет вообще. И не будет, покуда nouveau не станет стабильным.

[damex]

вы про /var/lib/libGL.so (lib\lib32\lib64) или ему подобное ?

с трудом собранные под xen ядро nvidia дрова, при установке затерли несколько либ на свои.

проблема не дров а маинтенера _сборки_оных_под_xen_ядро_ нетакли?

[Bluetooth]

вы про /var/lib/libGL.so (lib\lib32\lib64) или ему подобное ?

с трудом собранные под xen ядро nvidia дрова, при установке затерли несколько либ на свои.

проблема не дров а маинтенера _сборки_оных_под_xen_ядро_ нетакли?

Сборки никакой нет. Поэтому пришлось собирать самому. Для этого там специальный скрипт. Как и следовало ожидать, ему вообще на все наплевать и он ломает систему, подменяя либы на свои.
И чьи тут проблемы - дело десятое. Их вообще не должно быть.

[damex]

Поэтому пришлось собирать самому.

в этом то и проблема.

тут либо учимся _правильно_ создавать _конкретные_ пакетики либо юзаем готовое.

Для этого там специальный скрипт. Как и следовало ожидать, ему вообще на все наплевать и он ломает систему, подменяя либы на свои.
И чьи тут проблемы - дело десятое. Их вообще не должно быть.

это как ... "чистка зубов вибратором"
> И чьи тут проблемы - дело десятое. Их вообще не должно быть.