По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Сегодня хотим поведать о том, как конвертировать образы дисков виртуальных машин из одного формата в другой. Допустим у нас есть виртуальная машина, развернутая в среде виртуализации VMware, а мы хотим импортировать её в среду Hyper-V. Или же вендор выпускает дистрибутивы только для Hyper-V, а нам обязательно нужно развернуть машину в VMware, потому что у нас вся сеть на нем. Если ты столкнулся с такой проблемой, то обязательно дочитай эту статью и ты найдёшь решение.
Процесс
Существует несколько форматов образов виртуальных жёстких дисков, которые поддерживаются разными средами виртуализации. Рассмотрим некоторые из них:
VMDK (Virtual Machine DisK) - формат образа виртуального жёсткого диска для виртуальных машин, разработанный VMware
VHD (Virtual Hard Disk) - формат файла, использующийся для хранения образов операционных систем, разработанный компанией Connectix, которая позднее была куплена Microsoft и теперь используется для образов Hyper-V. VHDX тоже самое, только все пространство на диске должно быть задано сразу.
VDI (Virtual Disk Images) - формат образа жёсткого диска гостевых виртуальных машин VirtualBox.
Если ты используешь VirtualBox - поздравляю, ты можешь взять любой из имеющихся форматов и создать виртуальную машину.
Но так уж получилось, что форматы VHD и VMDK несовместимы между собой. Поэтому, чтобы можно было использовать VMDK в Hyper-V, а VHD в VMware, их сначала нужно переконвертировать.
Итак, допустим у нас есть виртуальная машина VMware с образом жёсткого диска LOCAL-VM-disk1.vmdk, который находится в папке C:VMDKs. Для того, чтобы перенести его в Hyper-V, создадим папку, куда будет отправлен наш сконвертированный файл VHD – C:VHDs. После этого, скачаем специальную программу от Microsoft - Microsoft Virtual Machine Converter 3.0, она доступна по ссылке https://www.microsoft.com/en-us/download/details.aspx?id=42497.
После нажатия на кнопку Download, нам предложат скачать 2 файла – саму программу и описание команд. Установите программу.
Прежде чем продолжить, убедитесь, что версия PowerShell, которая у вас установлена 3 или выше. Проверить это можно если ввести команду $PSVersiontable
Если версия ниже 3 – обновите PowerShell, если 3 или выше, то продолжаем. Для начала, необходимо указать путь до скрипта конвертера, для этого вводим команду:
Import-Module ‘C:Program FilesMicrosoft Virtual Machine ConverterMvmcCMdlet.psd1’
Расположение скрипта может отличаться от C:Program FilesMicrosoft Virtual Machine Converter, всё зависит от того, какой путь был указан при установке программы
Команда должна выполниться без каких-либо ошибок. Если ошибки всё же появились – проверьте расположение скрипта и правильность ввода. Ну или пишите вывод ошибки в комментарии – мы постараемся помочь :)
Теперь можно приступать к конвертированию. Для этого введите следующую команду:
ConvertTo-MvmcVirtualHardDisk -SourceLiteralPath “C:VMDKsLOCAL-VM-disk1.vmdk”-DestinationLiteralPath “C:VHDS” -VhdType DynamicHardDisk -VhdFormat vhd
Где:
C:VMDKsLOCAL-VM-disk1.vmdk - Путь к конвертируемому образу формата VMDK
C:VHDS - Папка, куда будет помещен сконвертированный образ формата VHD
После этого, можно зайти в папку, куда будет помещен сконвертированный файл и наблюдать за тем как увеличивается его размер.
После того, как файл будет сконвертирован, мы увидим следующий вывод в консоли PowerShell:
Теперь можно использовать сконвертированный файл VHD в подходящей среде виртуализации Hyper-V
В этой статье рассмотрим, как управлять учетными записями пользователей и групп в Linux. Также посмотрим различные базы данных, в которых хранится информация о пользователях и группах и что такое теневые пароли.
Изначально в Linux было 2 файла /etc/password и /etc/group. В первом файле хранилось:
Имя_пользователя : пароль : uid : gid : сведения (поле предназначено для персональных данных) : домашняя_папка : командная оболочк(которая запускается при входе пользователя в систему)
Во втором файле хранилось:
имя_группы : пароль : gid : члены_группы
У группы может быть пароль, но данную функцию очень редко, кто использует, в таком случае пароль будет запрашиваться при смене членства в группе. Данные файлы плохи тем, что у всех пользователей системы, по умолчанию, есть права на чтение. Такие права необходимы потому, что разные пользователи, разные демоны и сервисы обращаются к данным файлам, чтобы брать оттуда информацию. Соответственно в этих файлах хранился пароль пользователя, хотя и в зашифрованном виде, но с помощью различных методов криптографии подбора можно было воспользоваться данным паролем, потому что у всех пользователей был на эти файлы доступ.
Поэтому был создан механизм теневых паролей. Были созданы вот такие 2 файла: /etc/shadow и /etc/gshadow. И к этим двум файлам имеет полный доступ только пользователь root. Следовательно, теперь в файлах passwd и group указываются не пароли, а специальные символы, говорящие что пароли были перенесены в файлы shadow и gshadow.
В новом файле shadow хранится побольше информации о пароле пользователя. Это:
Логин
Пароль
Время после смены пароля – это если пароль сбрасывался после времени установки системы
Минимальный срок действия пароля - как часто можно менять пароль, если, например, стоит 5 дней, то пароль можно менять не чаще, чем раз в 5 дней.
Максимальный срок действия пароля – максимальное количество дней, по прошествии которых обязательно необходимо сменить пароль.
Срок предупреждения – за сколько дней до истечения пароля система предупредит о том, что необходимо сменить пароль.
Время работы с истекшим паролем – это параметр позволяет указанное число дней работать с истекшим паролем.
Срок для блокировки пароля – данный параметр отвечает за время жизни самого пароля, например, пароль будет работать 100 дней, после этого заблокируется.
Соответственно данные параметры можно при необходимости задавать при создании учетной записи пользователя и паролей. Если провести аналогию с операционной системой Windows, то подобные параметры в Windows мы можем задавать через GPO (Group Policy Object - набор правил или настроек, в соответствии с которыми производится настройка рабочей среды в операционных системах Windows). Отличие заключается в том, что в Windows эти параметры выставляются в абсолютных величинах числом, а в операционной системе Linux, относительно даты 1 января 1970 года.
Ну и соответственно gshadow имеет следующую структуру, разделенную символом :.
Имя группы
Пароль зашифрованный
Администраторы, те учетные записи, которые могут менять пароль группы или добавлять другие аккаунты
Члены групп
Следовательно, пароли могут хранится и в тех, и в тех файлах, отличие в том, что у пользователей есть доступ на чтение к файлам passwd и group, а к shadow и gshadow только у пользователя root. Данный механизм называется механизмом теневых паролей, и он присутствует во всех современных Linux системах.
Теперь, посмотрим, как это выглядит в операционной системе.
Заходим в файл passwd любым текстовым редактором, например, nano, без повышения привилегий.
Возьмем пользователя:
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
Логин - list, значок X говорит о том, что пароль хранится в теневом файле. Далее 38 – id пользователя, 38 - gid, прочая информация - Mailing List Manager, домашняя папка пользователя - /var/list и оболочка которая используется при входе - /usr/sbin/nologin.
Можно увидеть, что вместо оболочки у пользователя указан nologin – это означает, что пользователь не может войти, используя стандартный экран входа, используя стандартные средства. На картинке можно найти пользователя siadmin. Можно также увидеть все остальные параметры этого пользователя. У него совпадает uid и gid, это связанно с тем , что при создании пользователя создается одноименная группа. Можно, конечно, при создании указать, что пользователь будет входить в другую группу и не создавать одноименную, но по умолчанию она создается. В конце строчки мы можем увидеть /bin/bash, которая запускается при входе в систему. Можно обратить внимания на uid и gid все реальные пользователи их имеют числом выше 1000. Все пользователи, у которых число ниже – это служебные пользователи или созданные автоматически. В некоторых дистрибутивах Linux нумерация реальных пользователей начинается с 500.
Посмотрим файл с группами, вводим команду nano /etc/group
Данная база очень простая. Указано наименование группы, знак X говорит, о том, что пароль хранится в теневой базе, идентификатор группы и список пользователей в данной группе. Единственный нюанс - если пользователь входит в свою же группу, то после знака двоеточие пользователь не отображается.
Далее файлы /etc/shadow и /etc/gshadow, данные файлы не редактируются с помощью текстовых редакторов, а через специальные команды. Данные файлы — это просто хранилище информации. Эти утилиты будут рассмотрены в следующем уроке.
Зайти в эти файлы могут только пользователи имеющие права root или с помощью команды повышающей привилегии sudo.
sudo nano /etc/shadow
Теперь мы видим в данном файле через двоеточие:
Имя пользователя
* или зашифрованный пароль
Срок с последнего изменения пароля в днях
Минимальный срок изменения пароля, если 0, то сменить пароль можно сразу
99999 - срок действия пароля, 7 - количество дней за которое до истечения пароля придет предупреждение
Символ * говорит о том, что под данным пользователем нельзя зайти стандартным способом, обычно это применяется для служебных аккаунтов, т.е вход вообще заблокирован под данным аккаунтом.
Вот так вот реализуется механизм теневых паролей.
Начиная с Windows Server 2012 R2 в Hyper-v появились машины второго поколения. Они добавляют некоторые преимущества по сравнению с виртуальными машинами первого поколения, поэтому следует подумать о переходе. Хотя автоматического преобразования не существует, есть способ избежать новой установки и настройки виртуальной машины.
Есть несколько причин, по которым рабочие системы до сих пор работают на виртуальных машинах первого поколения. Часто они существуют уже несколько лет и были созданы в версии Hyper-V, которая поддерживает только виртуальные машины 1-го поколения. Их по-прежнему можно использовать в более новой версии гипервизора, и они полностью поддерживаются.
И наоборот, также возможно, что версия Windows была изначально установлена на виртуальной машине, которая поддерживает только виртуальные машины 1-го поколения. Гостевая ОС, возможно, за это время была обновлена, но функции 2-го поколения в старой виртуальной машине заблокированы.
Может случиться и так, что Gen 1 будет случайно выбран при создании виртуальной машины, поскольку это по-прежнему выбирается по умолчанию в диспетчере Hyper-V.
Преимущества 2 поколения
Одним из наиболее важных преимуществ новых виртуальных машин является более высокая производительность, поскольку гостевая ОС «знает», что она работает на гипервизоре, и, следовательно, не требует эмуляции оборудования. Виртуальные машины второго поколения обладают поддержкой UEFI, работают под управлением только 64-разрядной гостевой ОС, могут загружаться с виртуального контроллера SCSI. Подключенные к контроллеру виртуальные жесткие диски можно добавлять, удалять и изменять их размер во время работы. Сетевые адаптеры также могут быть добавлены во время работы системы.
Если вы хотите настроить виртуальную машину с UEFI, вы можете сделать это только с виртуальной машиной поколения 2, т.е. безопасная загрузка доступна только в ней. Виртуальные машины поколения 1 поддерживают только BIOS и, следовательно, ограничены структурой MBR дисков и это основное препятствие при миграции.
Поиск старых виртуальных машин
Первым шагом будет обзор того, какие виртуальные машины относятся к Gen 1 (Поколение 1). С помощью PowerShell это относительно легко узнать:
Get-VM | select vmname, generation
Эта команда выведет вам список всех виртуальных машин на локальном хосте, их имена и поколение.
По сути, теперь вы можете приступить к преобразованию старых виртуальных машин. Однако это невозможно, если гостевая ОС старше Windows Server 2012 R2 или имеет 32-разрядную версию.
Следовательно, вам необходимо выяснить, какая ОС установлена на виртуальной машине. Это можно относительно легко определить через PowerShell:
Get-ComputerInfo -Property WindowsProductName, OsArchitecture
Изменение таблицы разделов на GPT
После того как вы определили, какие виртуальные машины подходят для преобразования, вам следует сначала обновить гостевую ОС до версии Windows, которую вы запланировали для новой среды.
Затем преобразовать системный диск в GPT. Начиная с Windows 10 1703, Microsoft предоставляет для этой цели MBR2GPT.exe. Программа запускается на рабочей системе со следующими параметрами:
mbr2gpt.exe /convert /allowFullOS
Утилита находится в %SystemRoot%system32 и может быть легко скопирована на другие компьютеры, если ее там нет. Это относится, например, и к серверам Windows.
Однако в случае более старых версий ОС Microsoft рекомендует выключить виртуальную машину, загрузиться в среду предустановки Windows и начать преобразование в GPT оттуда. Тогда команда выглядит немного иначе:
mbr2gpt.exe /convert /disk:<disknumber>
Номера дисков можно посмотреть программой diskpart с помощью:
list disk
Перенос виртуального диска на новую виртуальную машину
Поскольку преобразовать виртуальную машину поколения 1 в поколение 2 невозможно, теперь необходимо создать новую виртуальную машину Gen 2 и подключить к ней виртуальный жесткий диск.
Одним из побочных эффектов этого действия является то, что оно также поднимает версию виртуальной машины до текущего уровня. Это необходимо, чтобы воспользоваться преимуществами новых функций Hyper-V, доступных в Server 2016 или 2019. Новая виртуальная машина больше не будет работать на более старом гипервизоре.