Vmware vmx


Параметры VMX или защита ВМ

Этот перевод навеян шикарной статьей от Robert Patton, посвященной параметрам VMX-файлов виртуальных машин, предназначенным для устранения определенных уязвимостей. Как водится, перевод пристрастный 🙂Если вы немного работали с продуктами VMware, вы, наверное, обратили внимание на VMX файлы. Каждый VMX содержит почти все настройки виртуальной машины, а также имеет несколько дополнительных настроек, которые нельзя добавить из графического интерфейса, а можно только с помощью редактора из консоли. В этом руководстве я опишу несколько параметров, призванных защитить вас от уязвимостей в VMware Tools и прикрыть каналы между гостевой ОС и хостом.Параметры, о которых мы будем говорить, уже не раз встречались в различных источниках. Но почти нет информации о том, что именно они делают и для чего предназначены. Многие из этих параметров неприменимы к ESX 3,5. Поэтому, вместо того, чтобы опубликовать очередной список, я попытаюсь объяснить предназначение этих параметров. Даже если вы и не собираетесь заняться увеличением безопасности, продолжите чтение, и, может быть, мы откроем вам глаза на дыры в безопасности вашей инфраструктуры.Мне нравится использовать связку PUTTY и VI для редактирования VMX файлов. Просто скопируйте в буфер список параметров в конце статьи, откройте VMX файл в VI и нажмите правую кнопку мыши в режиме вставки текста для того, чтобы вставить текст. Если же вы не знакомы с интерфейсом VI, то в самом конце статьи будет краткая справка по нему.Также вы можете добавить эти параметры через VI Client, нажав правой кнопкой мыши на названии ВМ, выбрав пункт Edit Settings…, вкладку Options, Advanced — General, и нажав кнопку Configuration Parameters… Но, в сущности, это гораздо дольше делать, чем использовать VI. Вне зависимости от метода редактирования VMX файла, вам необходимо выключить ВМ. Если вы что-то изменяете в VMX файле, то после выключения ВМ эти изменения удалятся, так как во время работы ВМ все параметры VMX загружены в оперативную память хоста.

Вам действительно необходимо увидеть уязвимости VMware Tools для того, чтобы представить область их действия. Для демонстрации уязвимостей мы возьмем свежую ВМ с установленной ОС Windows Server 2003 Standard и установленными VMware Tools. Создадим локального пользователя testuser, и добавим его в группу Remote Desktop Users. Соответственно, наш пользователь будет членом групп Users и Remote Desktop Users на этом сервере. Заметьте, он не является локальным администратором. 😉 По сути дела, это типичный аккаунт для использования Citrix или же терминальных серверов Microsoft.Если вы думаете, что вы защищены, потому что в правом нижнем углу нет значка VMware Tools, то вы ошибаетесь. Любой пользователь может запустить его с помощью команды «C:\Program Files\VMware\VMware Tools\VMControlPanel.cpl».Отключение устройствНачнем мы с обзора возможностей по подключению и отключению CD-ROM, FDD и сети из панели управления VMware Tools. Создайте RDP сессию к нашему тестовому серверу и войдите в систему под именем testuser. Кликните по значку VMware Tools и перейдите на закладку Devices. Снимите флаг рядом с сетевой платой и нажмите кнопку Apply. Вы можете наблюдать, как ваша RDP сессия повисла, а сервер не отвечает на запросы. Да-да, обычный пользователь только что выдрал с корнем провод из виртуальной сетевой платы, полностью отключив сервер от сети. Если у вас уже есть терминальные сервера, вы можете себе представить масштабы этой угрозы.К счастью для нас, это легко отключается с помощью следующих параметров VMX файла:isolation.device.connectable.disable = «true»isolation.device.edit.disable = «true»Угрозы времениДавайте снова создадим RDP сессию и откроем панель VMware Tools. На вкладке Options снимем флаг Time synchronization between the virtual machine and the host operating system. Нажмем Apply и Ok. Закройте и снова откройте панель VMware Tools – вы увидите, что эти изменения сохраненились.Конечно, если вы используете службу W32Time, вы можете сказать, что это все ерунда. Но когда злобный пользователь включит синхронизацию времени с хостом, вы получите два процесса синхронизации времени, не знающих друг о друге. А если у вас отключена синхронизация времени через W32Time и пользователь отключит\включит синхронизацию времени с хостом, то, возможно, ВМ не сможет авторизоваться в домене.Этот флаг меняет параметр в VMX файле – tools.syncTime. Соответственно, следующий параметр запрещает изменение этого параметра:isolation.tools.setOption.disable = «true»Даже если вы снимете/поставите флаг и нажмете Apply, а затем Ok, после перезапуска панели VMware Tools, вы увидите, что параметр не изменился.Подождите секунду…Я было поставил точку в этой статье, но старый-старый скрипт снова изменил параметр синхронизации. Мог ли непривилегированный пользователь сделать это? Я «вспомнил» команду C:\Program Files\VMware\VMware Tools\VMwareService.exe -cmd «vmx.set_option synctime 0 1» и запустил ее из сеанса testuser и без включенного параметра set.Option.disable мне удалось включить синхронизацию времени с хостом.Хмм, set_option сильно похоже на параметр setOption.disable. Давайте почитаем справку командной строки — VMwareService.exe –helpUsage: c:\Program Files\VMware\VMware Tools\VMwareService.exe {-v,-i,-u,-kill,-cmd ««}Да уж, не особенно понятнее стало. Немного информации есть в SDK, но недостаточно для понимания сути. В конце концов, я скачал исходный код VMware Tools и начал рыться в нем. После долгих трудов я нашел несколько процедур, которые можно отнести к уязвимостям. Следующая команда позволит вам писать в лог ВМ определенный текст:C:\Program Files\VMware\VMware Tools\VMwareService.exe -cmd «log %string %string»А эта позволит создать переменную типа Guestinfo для хранения информации о виртуальной машине в памяти ESX-сервера:C:\Program Files\VMware\VMware Tools\VMwareService.exe -cmd «info-set guestinfo.%variable %string»Ну и чтение из переменной GuestInfo:C:\Program Files\VMware\VMware Tools\VMwareService.exe -cmd «info-get guestinfo.%variable»Обратите внимание на то, что эти переменные не хранятся постоянно. Они запоминают состояние при перезагрузке ВМ, но если вы ее выключаете, то они стираются.Эта информация имеется в руководстве «VI3 Security Hardening» в разделе «Limit Data Flow from the Virtual Machine to the Datastore». И, конечно, все команды может выполнить непривилегированный пользователь.Закрываем дырыДля проверки использования этих дыр я написал несколько скриптов и запустил их от имени testuser. Для спам-атаки на лог-файлы сервера ESX я пытался записать 1KB данных в цикле, повторявшемся миллион раз. Я наблюдал за ростом файла логов и обнаружил, что как только он разрастается до размера в 1МБ, рост прекращается. Расследование показало, что в конце лога имеется сообщение «Log Throttled» (журнал прерван). Это хороший знак, значит, VMware установило ограничение на рост размера файлов. Но я предпочитаю, чтобы вообще не было возможности воспользоваться этой уязвимостью, поэтому использую следующую команду:isolation.tools.log.disable = «true»УРА. Теперь использование этой дыры стало невозможным, зато продолжается запись журналов в файл vmware.log, который можно использовать при наличии проблем с ВМ.После этого я попробовал забросать ОЗУ сервера ненужными значениями переменной. Выяснилось, что на одну ВМ разрешено хранить до 32 двух переменных, на каждую выделяется до 32КБ данных. В результате, с помощью этой уязвимости разрешаено записать в память до 1МБ данных.Руководство «VI3 Security Hardening» предлагает два способа для закрытия этой дыры. Например, мы можем отключить создание переменных GuestInfo с помощью команды isolation.tools.setInfo.disable = «true».Но я не могу с чистым сердцем рекомендовать эту директиву, ведь после этого ВМ не сможет сообщить хосту свой ip-адрес и dns имя. Нет гарантий, что VCB или приложения других компаний продолжат работу. Зато мы можем ограничить размер, выделяемый под хранение переменных GuestInfo с помощью другой команды — tools.setInfo.sizeLimit = «some # in bytes».Вообще говоря, 1МБ – достаточно важная цифра. Если вы можете жить без данных об ip или dns – лучше отключить использование переменных GuestInfo. Так как могут возникнуть проблемы с использованием, я убрал эту рекомендацию из списка команд в конце статьи.Уменьшение диска ВМДавайте снова откроем панель VMware Tools и перейдем на вкладку Shrink. Я не буду объяснять, зачем нужна эта операция. Почему-то компания VMware решила, что эти опции должны быть доступны любому пользователю, даже не администратору. Когда выполняется операция Shrink, процессор ВМ загружается почти на 100% и ВМ перестает отвечать на запросы. Операция Shrink не запустится, если у пользователя нет прав на запись в корневой каталог того логического диска, который он будет уменьшать.Но если другой администратор или приложение предоставит доступ на запись в корневой каталог диска группе Users или Everyone, то вы попали…Если вы не используете Shrink в своей инфраструктуре, то можно устранить эту уязвимость с помощью следующих команд:isolation.tools.diskWiper.disable = «true»isolation.tools.diskShrink.disable = «true»Угроза PXEЯ столкнулся с этой уязвимостью, когда разбирался с одной проблемой, связанной с SAN. Сервера ESX внезапно отключились от iSCSI лунов, и, когда мы открыли консольное подключение к ВМ, мы были удивлены увиденным. Все ВМ были запущены, но автоматически перезагрузились, когда пропал жесткий диск. Так как VMX файлы находились в оперативной памяти, то ESX-сервера не обратили внимания на то, что луны с дисками пропали. Соответственно, ВМ проверили все источники загрузки и запустились с PXE-сервера.Обдумав ситуацию, я решил, что это может быть страшной атакой. Если кто-то сможет подключиться к PXE-серверу в сети и запустить DoS-атаку на сеть iSCSI, они смогут перезапустить ВМ со своими образами ОС, в которых будут все необходимые им инструменты для дальнейшего взлома сети. К счастью, загрузку по PXE через сетевые адаптеры vlance и vmxnet легко отключить:vlance.noOprom = «true»vmxnet.noOprom = «true»Если вы используете адаптер e1000 для виртуальных машин, придется использовать другой метод для отключения загрузки по PXE, так как нет опции .noOprom для этого адаптера. Следующая команда уменьшит объем памяти, который выделяет BIOS для загрузки. Заметьте, это настройка на определенную сетевую карту:ethernet0.opromsize = «0»Запрет общего буфераЧтобы предотвратить возможность утечки конфиденциальной информации, например, паролей, из буфера обмена vClient в буфер обмена ВМ, желательно запретить возможность использования совместного буфера и операций copy/paste. Это легко сделать, и это не должно принести серьезных проблем, если вы не используете vClient для повсеместной работы с ВМ.isolation.tools.copy.disable = «true»isolation.tools.paste.disable = «true»Часто встречается еще и третья команда — isolation.tools.setGUIOptions.enable = «false», но я не смог найти никакой документации по этой команде. Другая интересная? вещь в том, что иногда в контексте она пишется как Gui, с заглавной G. Также есть команда isolation.tools.setGUIOptions.disable, но и для нее я не нашел документации. Также я не нашел разницы в работе при использовании параметров true или false. Давайте все же добавим его в список наших команд, потому что он есть в некоторых руководствах и документах и вроде бы ни на что не влияет.isolation.tools.setGUIOptions.enable = «false»Журналы – это наше всеПоследний набор параметров, который мы рассмотрим, относятся к файлам логов ВМ – vmware.log. Мы уже сталкивались с тем, как этот файл может быть испорчен с помощью уязвимости, но есть еще одна уязвимость. Я столкнулся с этой проблемой лицом к лицу. У нас была ВМ, не подающая никаких признаков беспокойства, но VCB бэкап которой падал каждый вечер. К счастью, мы использовали VCB Wrangler для управления нашими бэкапами; скрипт, который по расписанию запускал vcbmounter.exe, а затем отправлял результат выполнения бэкапа и список скопированных файлов на почту. Расследуя проблему с бэкапами, мы обнаружили, что лог-файлы vmware-####.log достигли значения 7000. Используя в SSH сессии команду ls –la в каталоге ВМ, мы увидели, что лог-файлы были созданы в течение часа. Какой-то процесс вызывал активную запись в журнал логов, к счастью, мы уже использовали следующие команды:log.rotateSize = «100000» (предельный размер файла логов)log.keepOld = «10» (количество логов для хранения)Если бы этих команд не было, файлы логов заняли бы все свободное место и вызвали сбой с неизвестной причиной.Тест-тест-тест 🙂Если вы сделали эти изменения в VMX, и тестируете их на ВМ, то могли заметить, что на вкладке Options в панели VMware Tools по прежнему есть две опции, позволяющие непривилегированному пользователю изменять и сохранять Show VMware Tools in the taskbar и Notify if update is available. Эти параметры хранятся в реестре в ветке HKEY_CURRENT_USER, и хранятся отдельно для каждой учетной записи. Так как это не глобальные параметры, то их можно проигнорировать, ведь непривилегированный пользователь не сможет обновить VMware Tools. Также я слышал совет по ограничению через NTFS прав на каталог C:\Program Files\VMware\VMware Tools. У VMware на эту тему есть статья в базе знаний. Основная проблема заключается в том, что если пользователь где-то раздобудет VMControlPanel.cpl или VMwareService.exe и скопирует их на рабочий стол, то он будет в состоянии использовать панель VMware Tools. Если хотите, то можете это проверить 🙂

Вот список изменений, рекомендованных к внедрению. Если вы займетесь самостоятельным поиском, то обнаружите, что есть много дополнительных параметров, которые здесь не указаны, некоторые из них настоятельно рекомендуются к использованию. Но я рекомендую вам тщательнейшим образом проверять параметры, отсутствующие в этом списке, прежде чем вы добавите их в производственную среду. Все параметры из этой статьи, за исключением isolation.tools.setOption.disable, vlance.noOprom, и vmxnet.noOprom, рекомендуются в документе «VI3 Security Hardening».Долгожданный список 🙂isolation.device.connectable.disable = «true»isolation.device.edit.disable = «true»isolation.tools.setOption.disable = «true»isolation.tools.log.disable = «true»isolation.tools.diskWiper.disable = «true»isolation.tools.diskShrink.disable = «true»isolation.tools.copy.disable = «true»isolation.tools.paste.disable = «true»isolation.tools.setGUIOptions.enable = «false»log.rotateSize = «100000»log.keepOld = «10»vlance.noOprom = «true»vmxnet.noOprom = «true»

# PXE boot on the e1000 vNIC can be disabled with this directive:ethernet0.opromsize = «0»А теперь обещанное howto по VIЭто коротенькая вводная по VI для тех, кто еще не открыл для себя великий потенциал этого редактора. Откройте SSH сессию к вашему ESX серверу и наберите VI в командной строке. Если вы нажмете в окне редактора i, то увидите надпись —INSERT— в левом нижнем углу. Наберите любой текст, а затем нажмите Esc – надпись пропадет, а текст перестанет печататься в файл. VI имеет два режима: режим ввода команд и режим ввода текста, после нажатия клавиши Esc вы попадаете в режим ввода команд. Для ввода текста в формате wysiwyg просто нажмите i и вы увидите надпись —INSERT—.Ну и напоследок — сохранение документов.:wq – сохранение документа;:q! – выход без сохранения.Перед редактированием VMX-файла убедитесь, что ВМ выключена и сделайте ее резервную копию с помощьюcp /vmfs/volumes/somevolume/somevm/somevm.vmx /rootДля редактирования VMX используйтеvi /vmfs/volumes/somevolume/somevm/somevm.vm

vmind.ru

VMware VMX - Builders - Packer by HashiCorp

Type: vmware-vmx

This VMware Packer builder is able to create VMware virtual machines from an existing VMware virtual machine (a VMX file). It currently supports building virtual machines on hosts running VMware Fusion Professional for OS X, VMware Workstation for Linux and Windows, and VMware Player on Linux.

The builder builds a virtual machine by cloning the VMX file using the clone capabilities introduced in VMware Fusion Professional 6, Workstation 10, and Player 6. After cloning the VM, it provisions software within the new machine, shuts it down, and compacts the disks. The resulting folder contains a new VMware virtual machine.

» Basic Example

Here is an example. This example is fully functional as long as the source path points to a real VMX file with the proper settings:

{ "type": "vmware-vmx", "source_path": "/path/to/a/vm.vmx", "ssh_username": "root", "ssh_password": "root", "shutdown_command": "shutdown -P now" }

» Configuration Reference

There are many configuration options available for the VMware builder. They are organized below into two categories: required and optional. Within each category, the available options are alphabetized and described.

In addition to the options listed here, a communicator can be configured for this builder.

» Required:

  • source_path (string) - Path to the source VMX file to clone.

» Optional:

  • boot_command (array of strings) - This is an array of commands to type when the virtual machine is first booted. The goal of these commands should be to type just enough to initialize the operating system installer. Special keys can be typed as well, and are covered in the section below on the boot command. If this is not specified, it is assumed the installer will start itself.

  • boot_wait (string) - The time to wait after booting the initial virtual machine before typing the boot_command. The value of this should be a duration. Examples are "5s" and "1m30s" which will cause Packer to wait five seconds and one minute 30 seconds, respectively. If this isn't specified, the default is 10 seconds.

  • disable_vnc (boolean) - Whether to create a VNC connection or not. A boot_command cannot be used when this is false. Defaults to false.

  • floppy_files (array of strings) - A list of files to place onto a floppy disk that is attached when the VM is booted. This is most useful for unattended Windows installs, which look for an Autounattend.xml file on removable media. By default, no floppy will be attached. All files listed in this setting get placed into the root directory of the floppy and the floppy is attached as the first floppy device. Currently, no support exists for creating sub-directories on the floppy. Wildcard characters (*, ?, and []) are allowed. Directory names are also allowed, which will add all the files found in the directory to the floppy.

  • floppy_dirs (array of strings) - A list of directories to place onto the floppy disk recursively. This is similar to the floppy_files option except that the directory structure is preserved. This is useful for when your floppy disk includes drivers or if you just want to organize it's contents as a hierarchy. Wildcard characters (*, ?, and []) are allowed.

  • fusion_app_path (string) - Path to "VMware Fusion.app". By default this is "/Applications/VMware Fusion.app" but this setting allows you to customize this.

  • headless (boolean) - Packer defaults to building VMware virtual machines by launching a GUI that shows the console of the machine being built. When this value is set to true, the machine will start without a console. For VMware machines, Packer will output VNC connection information in case you need to connect to the console to debug the build process.

  • http_directory (string) - Path to a directory to serve using an HTTP server. The files in this directory will be available over HTTP that will be requestable from the virtual machine. This is useful for hosting kickstart files and so on. By default this is "", which means no HTTP server will be started. The address and port of the HTTP server will be available as variables in boot_command. This is covered in more detail below.

  • http_port_min and http_port_max (number) - These are the minimum and maximum port to use for the HTTP server started to serve the http_directory. Because Packer often runs in parallel, Packer will choose a randomly available port in this range to run the HTTP server. If you want to force the HTTP server to be on one port, make this minimum and maximum port the same. By default the values are 8000 and 9000, respectively.

  • output_directory (string) - This is the path to the directory where the resulting virtual machine will be created. This may be relative or absolute. If relative, the path is relative to the working directory when packer is executed. This directory must not exist or be empty prior to running the builder. By default this is "output-BUILDNAME" where "BUILDNAME" is the name of the build.

  • shutdown_command (string) - The command to use to gracefully shut down the machine once all the provisioning is done. By default this is an empty string, which tells Packer to just forcefully shut down the machine unless a shutdown command takes place inside script so this may safely be omitted. If one or more scripts require a reboot it is suggested to leave this blank since reboots may fail and specify the final shutdown command in your last script.

  • shutdown_timeout (string) - The amount of time to wait after executing the shutdown_command for the virtual machine to actually shut down. If it doesn't shut down in this time, it is an error. By default, the timeout is "5m", or five minutes.

  • skip_compaction (boolean) - VMware-created disks are defragmented and compacted at the end of the build process using vmware-vdiskmanager. In certain rare cases, this might actually end up making the resulting disks slightly larger. If you find this to be the case, you can disable compaction using this configuration value.

  • tools_upload_flavor (string) - The flavor of the VMware Tools ISO to upload into the VM. Valid values are "darwin", "linux", and "windows". By default, this is empty, which means VMware tools won't be uploaded.

  • tools_upload_path (string) - The path in the VM to upload the VMware tools. This only takes effect if tools_upload_flavor is non-empty. This is a configuration template that has a single valid variable: Flavor, which will be the value of tools_upload_flavor. By default the upload path is set to {{.Flavor}}.iso.

  • vm_name (string) - This is the name of the VMX file for the new virtual machine, without the file extension. By default this is "packer-BUILDNAME", where "BUILDNAME" is the name of the build.

  • vmx_data (object of key/value strings) - Arbitrary key/values to enter into the virtual machine VMX file. This is for advanced users who want to set properties such as memory, CPU, etc.

  • vmx_data_post (object of key/value strings) - Identical to vmx_data, except that it is run after the virtual machine is shutdown, and before the virtual machine is exported.

  • vmx_remove_ethernet_interfaces (boolean) - Remove all ethernet interfaces from the VMX file after building. This is for advanced users who understand the ramifications, but is useful for building Vagrant boxes since Vagrant will create ethernet interfaces when provisioning a box.

  • vnc_bind_address (string / IP address) - The IP address that should be binded to for VNC. By default packer will use 127.0.0.1 for this.

  • vnc_disable_password (boolean) - Don't auto-generate a VNC password that is used to secure the VNC communication with the VM.

  • vnc_port_min and vnc_port_max (number) - The minimum and maximum port to use for VNC access to the virtual machine. The builder uses VNC to type the initial boot_command. Because Packer generally runs in parallel, Packer uses a randomly chosen port in this range that appears available. By default this is 5900 to 6000. The minimum and maximum ports are inclusive.

» Boot Command

The boot_command configuration is very important: it specifies the keys to type when the virtual machine is first booted in order to start the OS installer. This command is typed after boot_wait.

As documented above, the boot_command is an array of strings. The strings are all typed in sequence. It is an array only to improve readability within the template.

The boot command is "typed" character for character over a VNC connection to the machine, simulating a human actually typing the keyboard.

Keystrokes are typed as separate key up/down events over VNC with a default 100ms delay. The delay alleviates issues with latency and CPU contention. For local builds you can tune this delay by specifying e.g. PACKER_KEY_INTERVAL=10ms to speed through the boot command.

There are a set of special keys available. If these are in your boot command, they will be replaced by the proper key:

  • <bs> - Backspace

  • <del> - Delete

  • <enter> and <return> - Simulates an actual "enter" or "return" keypress.

  • <esc> - Simulates pressing the escape key.

  • <tab> - Simulates pressing the tab key.

  • <f1> - <f12> - Simulates pressing a function key.

  • <up> <down> <left> <right> - Simulates pressing an arrow key.

  • <spacebar> - Simulates pressing the spacebar.

  • <insert> - Simulates pressing the insert key.

  • <home> <end> - Simulates pressing the home and end keys.

  • <pageUp> <pageDown> - Simulates pressing the page up and page down keys.

  • <leftAlt> <rightAlt> - Simulates pressing the alt key.

  • <leftCtrl> <rightCtrl> - Simulates pressing the ctrl key.

  • <leftShift> <rightShift> - Simulates pressing the shift key.

  • <leftAltOn> <rightAltOn> - Simulates pressing and holding the alt key.

  • <leftCtrlOn> <rightCtrlOn> - Simulates pressing and holding the ctrl key.

  • <leftShiftOn> <rightShiftOn> - Simulates pressing and holding the shift key.

  • <leftAltOff> <rightAltOff> - Simulates releasing a held alt key.

  • <leftCtrlOff> <rightCtrlOff> - Simulates releasing a held ctrl key.

  • <leftShiftOff> <rightShiftOff> - Simulates releasing a held shift key.

  • <wait> <wait5> <wait10> - Adds a 1, 5 or 10 second pause before sending any additional keys. This is useful if you have to generally wait for the UI to update before typing more.

In addition to the special keys, each command to type is treated as a template engine. The available variables are:

  • HTTPIP and HTTPPort - The IP and port, respectively of an HTTP server that is started serving the directory specified by the http_directory configuration parameter. If http_directory isn't specified, these will be blank!

Example boot command. This is actually a working boot command used to start an Ubuntu 12.04 installer:

[ "<esc><esc><enter><wait>", "/install/vmlinuz noapic ", "preseed/url=http://{{ .HTTPIP }}:{{ .HTTPPort }}/preseed.cfg ", "debian-installer=en_US auto locale=en_US kbd-chooser/method=us ", "hostname={{ .Name }} ", "fb=false debconf/frontend=noninteractive ", "keyboard-configuration/modelcode=SKIP keyboard-configuration/layout=USA ", "keyboard-configuration/variant=USA console-setup/ask_detect=false ", "initrd=/install/initrd.gz -- <enter>" ]

For more examples of various boot commands, see the sample projects from our community templates page.

www.packer.io

Understanding VMware VMX Configuration Files

In our article called VMware Disk Files Explained, we talked about the different VMware files on disk. In particular, we talked about the important VMware VMX configuration file. In this article, we’ll go into more details on this critical file.

What are VMX Files?

In our previous article, VMware Disk Files Explained, we covered how a VMX file is the primary configuration file for a virtual machine. When you create a new virtual machine and answer questions about the operating system, disk sizes, and networking, those answers are stored in this file. As you can see from the screenshot below, a VMX file is actually a simple text file that can be edited with Notepad. VMX files are located in each of the folders of each of your virtual machines. For example, my Window XP Professional virtual machine is located in c:’Virtual Machines’Windows XP Professional and it is called Windows XP Professional.vmx.

When I right-click on that file and click Open With and Wordpad, Here is what I see:

If you just double click on the file, it will open in your VMware Server Console.

Exploring a VMX File

If we look into more detail, we can see the syntax of a VMX file and how it is constructed. Here are important tips and syntax of note:

  • A hash (or pound sign, #) are used for comments. Thus, anything that starts with a # sign is ignored and considered a comment.
  • The displayName is what is used on the VMware Tab to identify the virtual machine. This can be whatever you want to make it but I suggest something short that still uniquely identifies the virtual machine. In this case, our virtual machine is called “WinXP”.
  • The memory of the virtual machine is determined by the memsize line. In our case, our memory is 512 because of memsize=512. While you can set the memory to whatever size you want, it must be a multiple of 4.
  • The guestOS is one of these possible values: GUEST OS Options
  • The virtualHW.version is a required parameter. It tells VMware what VMware version this VMX is meant for. All VMware VMX files that run on Workstation, Player, or Server are version 4. Thus, you need virtualHW.version = “4”
  • As VMware disk drives can either be IDE or SCSI, you will see both represented in the VMX file. The VMX doesn’t tell you the size of the virtual hard drives, nor the full path. It does tell you the name of the VMDK, VMware virtual disk file. In our case, this looks like: ide0:0.fileName = “Windows XP Professional.vmdk”
  • The only 3 parameters required to make a VMX file are:
  1. virtualHW.version=”4″
  2. config.version=”4″
  3. guestOS=”winxppro”

Once created, you can double-click on it and it will open in your VMware workstation/player/server, like this:

However, in setting only these 3 parameters, you will get a virtual guest OS that only has 32MB of RAM, a floppy drive, and 1 CPU. The system won’t have any hard drives or CD drives.

  • If you have a line like scsi0.present = “TRUE” or ide0.present = “TRUE”, the vmware product looks for further config for these devices. If this is set to FALSE, then any further config is ignored.

Creating/Downloading VMX Files

You can actually download VMX files, based on answers you create, from the Internet. Here are some websites that allow you to do this: EasyVMX! VM Builder vmx-builder.cmd

One benefit to having a program create a VMX file for you is that there shouldn’t be any typos.

Summary

VMware VMX files are the configuration file for VMware guest operating systems. They can be short of very long. The more devices added, the more they grow. You can, of course, use the VMware GUI yourself to create the virtual guest configurations but, for VMware users who want to learn more about VMware, inner knowledge of the VMX file makes sense. Also, being able to edit these yourself or download one from the Internet can save you a lot of time!

Do you have questions or comments about VMware and the VMware VMX files? Checkout our VMware Discussion Forum!

Related articles

You may find these related articles of interest to you:

Got a question? Post it on our VMware Forums!

www.petri.com

Восстановление данных виртуальной машины VMware Workstation и VMware Player

VMware Workstation и VMware Player – это программное обеспечение виртуализации, которое предназначено для одновременной работы нескольких операционных систем на одном физическом компьютере. В таком случае одна из операционных систем будет работать как виртуальная машина на базе VMware.

VMware – это одна из наиболее стабильных и безопасных платформ для виртуализации компьютера, которая позволяет большому количеству ИТ-специалистов, разработчиков и другим специалистам компаний, быть более гибкими и продуктивными в своей работе.

Системные файлы VMware Workstation

Т.е., VMware Workstation – это ещё одна виртуальная работающая операционная система, внутри операционной системы вашего компьютера. Все файлы данной операционной системы (как системные, так и личные файлы пользователя) сохраняются на жестком диске компьютера, и по умолчанию они расположены в папке: C:\Users\Имя Пользователя\Documents\Virtual Machines\Имя виртуальной машины

Чаще всего, пользователям нет надобности знать название и место расположения файлов виртуальной машины VMware. Программа сама управляет своими файлами. Но бывают ситуации, когда без таких знаний не обойтись, например: если виртуальную машину необходимо восстановить в случае её утери, или восстановить удалённые файлы из неё и т.п.

Как видно из представленного выше скриншота, папка виртуальной машины, состоит из определённого набора файлов. VMware создаёт такую отдельную папку для каждой виртуальной машины и называет её именем виртуальной машины, которое присваивается самим пользователем в процессе установки виртуальной операционной системы.

Основные файлы виртуальной машины имеют такие расширения:

  • *.log – файл журнала ключевой активности VMware Workstation. Он используется для устранения неполадок, в случае их возникновения
  • *.nvram – файл состояния и настроек BIOS виртуальной машины
  • *.vmdk – файл виртуального диска, в котором сохранено содержимое жесткого диска виртуальной машиныПримечание. В зависимости от настроек VMware Workstation, диск виртуальной машины может состоять из одного или нескольких *.vmdk файлов.
  • *.vmem – файл подкачки виртуальной машины. Создаётся и виден только во время работы виртуальной машины
  • *.vmsd – файл параметров текущего снепшота
  • *.vmsn – файл состояния снепшота, который хранит текущее состояние виртуальной машины во время его использования
  • *.vmss – файл состояния приостановленной виртуальной машины
  • *.vmtm – конфигурационный файл, один из файлов параметров виртуальной машины
  • *.vmx – главный конфигурационный файл, в котором хранятся все параметры виртуальной машины
  • *.vmxf – дополнительный конфигурационный файл.

Примечание. Файлы с описанными расширениями являются основными. В папке виртуальной машины могут также присутствовать и другие файлы и папки, в том числе и такие, которые отображаются только во время её работы.

Как восстановить виртуальную машину, которая удалена

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

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

Чтобы восстановить виртуальную машину, которая удалена:

  1. Запустите Hetman Partition Recovery и просканируйте с её помощью жесткий диск, на котором была создана виртуальная машина

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

  3. Переместите все файлы папки в Список восстановления и восстановите их

  4. Откройте .vmx восстановленной виртуальной машины с помощью VMware Workstation

  5. Запустите виртуальную машину

Как восстановить содержимое диска виртуальной машины VMware

Как мы уже оговаривали, все файлы, которые сохраняются на дисках виртуальной машины, располагаются в .vmdk файлах виртуального диска. Программа для восстановления данных жесткого диска Hetman Partition Recovery имеет функцию монтирования виртуальных дисков и восстановления данных из них.

Если по каким-то причинам ваша виртуальная машина потеряла работоспособность, а на её дисках хранились важные файлы – их можно восстановить. Для этого:

  1. Запустите Hetman Partition Recovery и смонтируйте диск виртуальной машины. Если их несколько, можете смонтировать все сразу или поочерёдно.

    Примечание. Чтобы смонтировать виртуальный диск с помощью Hetman Partition Recovery, нажмите кнопку «Монтировать диск» в меню быстрого доступа программы. В результате, откроется окно выбора виртуального диска, в правом нижнем углу которого укажите тип файлов «Все файлы (*.*)», перейдите в папку с виртуальной машиной и выберите необходимый .vmdk файл.

  2. В результате в окне обнаруженных программой дисков добавится раздел «Монтированные диски» с перечнем смонтированных виртуальных дисков. В случае монтирования нескольких дисков, здесь будет отображаться их полный список.

  3. Просканируйте диск с помощью программы кликнув на нём дважды в менеджере дисков

  4. В результате анализа программа отобразит дерево каталогов сканируемого диска. Найдите и восстановите необходимые файлы.

Как восстановить файл диска виртуальной машины VMware, из самой виртуальной машины

В результате проведённых экспериментов было обнаружено, что файлы, которые удалены или утеряны внутри виртуальной машины восстановлению не подлежать.

VMware Workstation хоть и является виртуальной машиной, но на ней могут быть сохранены вполне реальные данные. В связи с этим, утеря доступа к виртуальной машине или её удаление может стать неприятной неожиданностью, а возможность восстановления сохранит данные пользователя от возможной безвозвратной утери.

hetmanrecovery.com

Как понизить версию виртуального аппаратного обеспечения (Virtual Hardware Version) с vmx-10 до vmx-09

В VMware vSphere 5.5 появился новый уровень виртуального аппаратного обеспечения (Virtual Hardware Version) vmx-10. После повышения уровня аппаратного обеспечения (Upgrade Virtual Hardware) с vmx-09 до vmx-10 теряется возможность редактирования настроек виртуальных машин через vSphere client.

При попытке отредактировать настройки виртуальной машины с версией 10, vSphere Client выдает окно с ошибкой:

You cannot use the vSphere client to edit the settings of virtual machines of version 10 or higher.Use the vSphere Web Client to edit the settings of this virtual machine.

Статья VMware KB: Editing virtual machine settings fails with the error: You cannot use the vSphere client to edit the settings of virtual machines of version 10 or higher (2061336) прямо указывает, что это ожидаемое поведение, и требует использовать vSphere Web Client, а если такой возможности нет, то редактировать свойства виртуальных машин при помощи PowerCLI.

Однако иногда проще просто понизить уровень виртуального аппаратного обеспечения.

Официальные способы понизить (downgrade) уровень железа описаны в статье VMware KB: Downgrading the virtual machine hardware version in ESX/ESXi (1028019). Их три:

  • Откатите до снапшота созданного перед повышением уровня;
  • Используйте VMware vCenter Converter Standalone;
  • Создайте новую виртуальную машину, и подключите в нее существующий диск.

Не очень богатый выбор. Если бы у Вас был снапшот, Вы бы эту статью не читали. Создать новую виртуальную машину можно, но будет много головной боли, например из-за смены MAC-адресов, да и точно восстановить конфигурацию виртуальной машины довольно трудоемкий процесс. Использовать конвертер очень и очень долго. Тем более, что есть неофициальный неподдерживаемый, но очень простой способ.

Всё, что делает VMware ESXi при повышении уровня с vmx-09 до vmx-10, это в файле конфигурации виртуальной машины <macine_name>.vmx изменяет значение

virtualHW.version = "9"

на

virtualHW.version = "10"

То есть, всё что нужно сделать, чтобы откатить изменения, это поменять 10 на 9, и сделать так, чтобы хост VMware ESXi узнал об этом изменении.

Способ 1: Virtual Hardware Version уменьшаем загрузкой через vSphere Client на рабочий компьютер, VMware ESXi уведомляем методом удаления/добавления в инвентарь.

  1. Выключите виртуальную машину, если она включена;
  2. Удалите виртуальную машину из инвентаря хоста используя команду Remove from Inventory;
  3. Используя vSphere Client загрузите <machine_name>.vmx к себе на компьютер.
  4. Найдите в загруженном файле строку virtualHW.version = «10» (обычно третья), и исправьте 10 на 9;
  5. Загрузите измененный файл обратно используя vSphere Client;
  6. Добавьте виртуальную машину в инвентарь и запустите при необходимости.

Способ 2. Virtual Hardware Version уменьшаем через SSH, VMware ESXi уведомляем методом его перезагрузки.

  1. Выключите все виртуальные машины на хосте;
  2. Подключитесь к хосту через SSH;
  3. Для каждой виртуальной машины выполните:
    1. Используя SSH подключение выполните: cd /vmfs/volumes/<datastore_name>/<machine_name> vi <machine_name>.vmx
    2. Найдите строку virtualHW.version = «10» (обычно третья), и исправьте 10 на 9;
    3. Сохраните файл.
  4. Перезагрузите VMware ESXi.

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

chmv.allnetic.com

Обходим детектирование виртуальной машины программами в VMWare / Хабрахабр

Разработчики вирусного ПО и просто разработчики, не желающие, чтобы их программу пытались реверсить, на этапе запуска или установки проводят проверки на виртуальную машину, и в случае её обнаружения отказываются работать, а то и вовсе самоликвидируются. Под катом описан способ, как можно попробовать решить эту проблему. Я использовал VMWare Fusion для Mac, однако с тем же успехом способ работает и в Workstation для Win.

1) Для работы необходима заново установленная система, как внести изменения в уже существующую — не нашёл.

Готовите виртуальный диск, указываете систему, как это обычно делаете, и в настройках к устанавливаемой машине, у меня этот пункт назван Isolation, выключаете любой обмен данными с хостовой ОС.

2) Далее надо найти конфигурационный VMX файл, создаваемый на этапе создания машины в VMWare, и в конец добавить строки:

isolation.tools.getPtrLocation.disable = «TRUE» isolation.tools.setPtrLocation.disable = «TRUE» isolation.tools.setVersion.disable = «TRUE» isolation.tools.getVersion.disable = «TRUE» monitor_control.disable_directexec = «TRUE» monitor_control.disable_chksimd = «TRUE» monitor_control.disable_ntreloc = «TRUE» monitor_control.disable_selfmod = «TRUE» monitor_control.disable_reloc = «TRUE» monitor_control.disable_btinout = «TRUE» monitor_control.disable_btmemspace = «TRUE» monitor_control.disable_btpriv = «TRUE» monitor_control.disable_btseg = «TRUE» Эти опции предотвращают детектирование программами виртуального окружения через такие сложные проверки, как отслеживание адресного пространства памяти, счётчиков.

Важно! Если на этапе настройки установки будет опция вроде «Express install», «Быстрая установка» — выключайте их. Также не стоит устанавливать VMWare Tools в установленную систему, т.к. некоторое ПО в проверку включает и наличие этого пакета.

3) Сохраняем файл, указываем для загрузки ISO с установщиком системы, устанавливаем ОС как обычно.

4) Несмотря на то, что подавляющее большинство программ, не любящих виртуальной среды, не заходят дальше проверок, которые мы отсекли на 2 шаге, некоторые особо упорные всё же идут дальше и пытаются искать, к примеру, всё, что похоже на название контроллеров виртуальных дисков.

Чтобы победить и их в Windows, идём в редактор реестра в ветку HKLM\SYSTEM\CurrentControlSet\Services\Disk\Enum. Как видите, там есть вполне явная отсылка к тому, что диск — виртуальный.

Нам нужно изменить его, убрав из параметра VMware, Virtual, Ven, итп, и сохранить её так.

Также имеет смысл заменить в реестре поиском по VMware/Virtual на какой-нибудь Intel или IBM всё, что меняется, а не только дисковые переменные.

После пробуйте запускать ваш упрямый объект экспериментов — в процентах 70 случаев описанные шаги помогут пройти проверки на виртуальное окружение.

Важно! Значение в HKLM\SYSTEM\CurrentControlSet\Services\Disk\Enum перезаписывается после каждой перезагрузки, так что его нужно менять после каждого нового запуска системы.

UPD от @Denisoid:

Естественно, это не исчерпывающее руководство, некоторое ПО также может пытаться определять виртуальную систему следующими методами:

1) Проверками диапазона MAC адресов (просто подменяется в настройках виртуального сетевого адаптера до запускa виртуальной машины) 2) Через WinAPI опросом конфигурации ОС и прочей системной информации (FirmwareTable) 3) Низкоуровневыми трюками.

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

Несмотря на то, что остались места, где можно себя выдать, предложенный метод заставляет обхитрить большинство ПО, которое не желает работать в виртуальной среде, в данном случае, в VMWare.

Как видно, улучшить скрытность можно также выделив виртульной машине больше системных ресурсов. Что касается памяти, выбирать стоит значения, кратные 1024.

Спасибо всем, кто осилил статью и помог в дополнении её толковыми комментариями!

habrahabr.ru


Смотрите также