Страница 1 из 1

VmWare. Внимание, опасный баг! (vmware workstation/player + kernel 4.xx + ext4)

Добавлено: 29 ноя 2017, 20:10
slant
Точные причины возникновения не нашел, хотя по найденной информации - вроде как кивают друг на друга разработчики vmware и ядра. Но столкнулся лично, при попытке посмотреть на Antegros (ядро 4.13). То же самое происходит с Manjaro. Есть серьезные подозрения, что минт 18.3 с ядром 4.10 может быть зацеплен тоже (кроме того, в него уже можно установить 4.13 через менеджер обновлений). Посему счел необходимым отписаться здесь. Баг присутствует во всех версиях vmware - и под linux, и под windows. Есть свидетельства, что проявляется даже на ESXi (bare-metal). К сожалению, баг из разряда плавающих (проявляется не у всех), но привязан видимо к железу (если проявился, то повторить можно).

Итак, баг заключается в следующем:
1. Создаем виртуальную машину с настройками по умолчанию для Linux x64. (Ключевой момент - предлагается SCSI диск.)
2. Ставим систему, настройки по умолчанию, файловая система EXT4. Не важно, будет это BIOS или EFI установка (MBR или GPT).
3. Перегружаемся в установленную систему, ставим обновления, несколько программ. Ставим open-vm-tools (драйвера на дисплей и Shared Folders).
4. Выключаем виртуальную машину. Не reboot, а именно power off.
5. При следующем запуске VM получаем неработоспособную систему гостя, и кучу ошибок на его разделе EXT4. После попытки лечения раздела работоспособность не восстановится, а часть файлов пропадет. Разрушения качественные.

Что делать чтобы не поиметь такого "счастья"? Ответ довольно прост: не использовать предлагаемый SCSI как тип эмулируемого контроллера дисков для виртуальной машины. Используем вместо него SATA.

Так же, судя по информации из сети, в случае установки гостя на btrfs, баг тоже не проявляется. (Непроверенно лично т.к. Антегрос не умеет ее использовать при установке. Но очень похоже, т.к. виртуалка с минт, с ядром 4.10 установленным вручную, и на btrfs у меня работает без проблем.)

UPD: перечитал, и решил уточнить прямо: хосту ничего не грозит. Проблемы возникают исключительно у гостевой VM.

VmWare. Внимание, опасный баг! (vmware workstation/player + kernel 4.xx + ext4)

Добавлено: 29 ноя 2017, 20:15
BadBird
Хорошо что я не пользуюсь этой вм....

VmWare. Внимание, опасный баг! (vmware workstation/player + kernel 4.xx + ext4)

Добавлено: 29 ноя 2017, 20:28
slant
При всем богатстве выбора, если нужна ускоренная графика, альтернативы нету. Лучше них никто 3D ускорение DirectX не эмулирует. (Прямой проброс видеокарты не рассматриваем).

VmWare. Внимание, опасный баг! (vmware workstation/player + kernel 4.xx + ext4)

Добавлено: 29 ноя 2017, 20:33
root
В чем опасность то заключается? После этих действий систему, из которой запускали VM хакнут бандосы, стырят пароли от личного кабинета пользователя какого-либо банка, подключатся с вашего компа к телефону через вафлю, заразят его и будут перенаправлять все входящие СМС-ки к себе? :-D Весьма раздутое название.

VmWare. Внимание, опасный баг! (vmware workstation/player + kernel 4.xx + ext4)

Добавлено: 29 ноя 2017, 20:35
BadBird
slant писал(а):
29 ноя 2017, 20:28
если нужна ускоренная графика, альтернативы нету.
Ничего себе.
в вб в линукс всего 128 мб памяти можно взять, в винде 256.
ВК имеет гиг памяти.
То есть, при использовании данных вм можно утянуть больше видеопамяти?

VmWare. Внимание, опасный баг! (vmware workstation/player + kernel 4.xx + ext4)

Добавлено: 29 ноя 2017, 20:55
Chocobo
root, Убитые данные, учитывая что указана и ESXi - может стать довольно опасной штукой

VmWare. Внимание, опасный баг! (vmware workstation/player + kernel 4.xx + ext4)

Добавлено: 29 ноя 2017, 21:07
slant
root писал(а):
29 ноя 2017, 20:33
В чем опасность то заключается?
В том, что к vmware можно подключить физические диски с уже установленной рабочей системой. У меня так одно время существовали две системы - винда хост для игрушек, и рабочее место на линкусе внутри VM. Которое, однако, можно было загрузить и на голом железе. Как думаете - приятно мне было бы потерять свою рабочие наработки и настроенное окружение?
Не считая того, что баг имеет подлую природу, и проявляется только после полного выключения VM (не после перезагрузок). Т.е. настроили почтовый сервер скажем, работает он без выключений, неделю, месяц... И тут понадобилось его виртуалку перекинуть на другой хост оффлайном. Выключаем (впервые), и... Правда весело?
BadBird писал(а):
29 ноя 2017, 20:35
То есть, при использовании данных вм можно утянуть больше видеопамяти?
Да. И главное - варя имеет полноценную поддержку DirectX 10. На ней даже идут практически любые игры которым больше 10-го DirectX не нужно. Причем очень многие с приемлемыми FPS. В среднем потери на виртуализацию графики - 30-40%. (Именно графики, сами приложения как и у конкурентов - не более 5% на железе с аппаратной поддержкой виртуализации.)
Старые игры вообще можно запускать без проблем. Причем сейчас старые - это уже первый Crysis, скажем. :)

VmWare. Внимание, опасный баг! (vmware workstation/player + kernel 4.xx + ext4)

Добавлено: 29 ноя 2017, 21:09
BadBird
Эх, нунифигасебе )))))
Надо засматриваться на VmWare )))

VmWare. Внимание, опасный баг! (vmware workstation/player + kernel 4.xx + ext4)

Добавлено: 29 ноя 2017, 21:13
root
slant, тогда понятно, согласен, извините. Вот этот пример, наверное, и стоило в шапку пихать, а не типо "установил голую систему, подкатил обновы, выключил - ниче не работает" - не видно же отчетливо, в чем трагедия заключается :-D

VmWare. Внимание, опасный баг! (vmware workstation/player + kernel 4.xx + ext4)

Добавлено: 29 ноя 2017, 21:20
slant
В шапку запихнуто именно то, что позволяет максимально быстро повторить, и убедится в наличии/отсутствии бага. Не рискуя данными. А примеров когда он может оказаться реально опасным - множество, достатчно немного задуматься. Мой - тут еще не самый главный будет...