По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Начиная с 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. Новая виртуальная машина больше не будет работать на более старом гипервизоре.
Сегодня мы подробно расскажем про наиболее используемые в сети интернет протоколы – POP3, IMAP и SMTP. Каждый из указанных протоколов имеет определенное назначение и функциональные возможности. Давайте попробуем разобраться.
Как работает электронная почта: SMTP, IMAP, POP3
Протокол POP3 и его порты
Post Office Protocol 3 (POP3) это стандартный протокол почты созданные для получения электронных писем с удаленного сервера на e-mail клиент.POP3 позволяет вам сохранить почтовое сообщение на ваш компьютер и даже прочесть его, в случае, если вы находитесь не в сети. Важно отметить, что если вы решили использовать POP3 для подключения к учетной записи почты, письма, которые уже скачаны на компьютер, будут удалены с почтового сервера. Как пример, если вы используете несколько компьютеров для подключения к одному почтовому аккаунту, то протокол POP3 может быть не лучшим выбором в данной ситуации. С другой стороны, так как почта хранится локально, на ПК конкретного пользователя, это позволяет оптимизировать дисковое пространство на стороне почтового сервера.
По умолчанию, протокол POP3 использует следующие порты:
Порт 110 – это порт протокола POP3 по умолчанию. Не является безопасным.
Порт 995 – этот порт следует использовать в том случае, если вы хотите установить безопасное соединение.
Протокол IMAP и порты
Internet Message Access Protocol (IMAP) – это почтовый протокол, созданный для доступа к почте с локального почтового клиента. IMAP и POP3 – наиболее популярные в сети интернет протоколы, используемые для получения e-mail. Оба этих протокола поддерживается всеми современными почтовыми клиентами (MUA - Mail User Agent) и WEB – серверами.
В то время как POP3 позволяет доступ к почте только с одного приложения, IMAP позволяет доступ из множества клиентов. По этой причине, IMAP наиболее адаптивен в тех случаях, когда доступ к одному почтовому аккаунту необходим для нескольких пользователей.
По умолчанию, протокол IMAP использует следующие порты:
Порт 143 – порт по умолчанию. Не безопасен.
Порт 993 – порт для безопасного соединения.
Протокол SMTP и его порты
Simple Mail Transfer Protocol (SMTP) – это стандартный протокол для отправки почтовых сообщений по сети интернет.
Данный протокол описан в RFC 821 и RFC 822, впервые опубликованных в августе 1982 года. В рамках данных RFC, формат адреса должен быть в формате имя_пользователя@доменное_имя. Доставка почты, аналогична работе обычной почтовой службы: например, письмо на адрес ivan_ivanov@merionet.ru, будет интерпретирован так: ivan_ivanov – адрес, а merionet.ru – почтовый индекс. Если доменное имя получателя отличается от доменного имени отправителя, то MSA (Mail Submission Agent) отправит письмо через Mail Transfer Agent (MTA). Главная идея MTA в том, чтобы перенаправлять письма в другую доменную зону, по аналогии, как традиционная почты отправляет письма в другой город или область. MTA так же получает почту от других MTA.
Протокол SMTP использует следующие порты:
Порт 25 – порт SMTP по умолчанию. Не безопасен.
Порт 2525 – данный порт используется в том случае, если интернет провайдер фильтрует порт 25.
Порт 465 – порт для безопасного соединения.
Вы можете более эффективно запускать и компилировать свои программы с помощью этого удобного средства автоматизации.
Если при обновлении некоторых файлов вы хотите запускать или обновлять весь программный модуль, то для вас может оказаться полезной утилита
make
. Для нее требуется файл
Makefile
(или
makefile
), который определяет набор задач для выполнения. Вы могли уже использовать
make
, когда компилировали программу из исходного кода. Большая часть проектов с открытым исходным кодом использует
make
для того, чтобы скомпилировать конечный исполняемый бинарный файл, который в последствии можно будет установить с помощью команды
make install
.
В этой статье мы посмотрим, что же такое
make
и
Makefile.
Для этого приведем несколько простых и усложненных примерных задач. Прежде чем мы начнем, убедитесь, что
make
уже установлен в вашей системе.
Простые примеры
Давайте начнем с того, что напечатаем в терминале простое «Hello World!». Создайте пустой каталог
myproject
, который будет содержать файл
Makefile
, внутри которого будет записано следующее:
say_hello:
echo "Hello World"
А теперь запустите файл, набрав
make
внутри каталога
myproject
. Результат будет следующий:
$ make
echo "Hello World"
Hello World
В приведенном выше примере
say_hello
выступает в роли имени функции, подобно любому другому языку программирования. Это называется
целью (target)
.
Предварительные условия (prerequisites)
или
зависимости (dependencies)
соответствуют цели. Для простоты мы не определили никаких предварительных условий в данном примере. Команда
echo "Hello World"
называется
рецептом (recipe)
.
Рецепт
использует
предварительные условия
для формирования
цели
. Цель, предварительные условия и рецепты вместе формируют
правило (rule)
.
Подытожим сказанное. Ниже представлен синтаксис обычного правила:
target: prerequisites
recipe
Скажем, целью может быть двоичный файл, который зависит от предварительных условий (файлов с исходным кодом). В свою очередь, предварительное условие тоже может быть целью, которая имеет другие зависимости:
final_target: sub_target final_target.c
Recipe_to_create_final_target
sub_target: sub_target.c
Recipe_to_create_sub_target
Цель – это не обязательно файл; это может быть просто название рецепта, как в нашем примере. Мы это называем «абстрактными целями».
Возвращаясь к примеру выше, при выполнении
make
отображалась целая команда
echo "Hello World"
, а только потом уже фактический вывод команды. Зачастую нам такое не нужно. Чтобы сама команда не отображалась, ввод команды
echo
нужно начать с
@
:
say_hello:
@echo "Hello World"
Теперь попробуйте запустить
make
снова. В выводе останется только следующее:
$ make
Hello World
Давайте добавим несколько абстрактных целей (
generate
и
clean
) в
Makefile
:
say_hello:
@echo "Hello World"
generate:
@echo "Creating empty text files..."
touch file-{1..10}.txt
clean:
@echo "Cleaning up..."
rm *.txt
Если мы попробуем запустить
make
после того, как внесли в него изменения, то увидим, что выполнится только цель
say_hello
. Это происходит по той причине, что только первая цель в make-файле является целью по умолчанию. То, что называется
целью по умолчанию (default goal)
, послужило причиной для того, чтобы в качестве первой цели в большинстве проектов использовалась цель
all
.
all
ответственна за то, чтобы вызывать другие цели. При этом такое развитие событий можно переиграть с помощью специальной абстрактной цели под названием
.DEFAULT_GOAL
.
Давайте добавим ее в начало нашего make-файла:
.DEFAULT_GOAL := generate
Это запустит цель
generate
в качестве цели по умолчанию:
$ make
Creating empty text files...
touch file-{1..10}.txt
Как можно понять из названия, абстрактная цель
.DEFAULT_GOAL
может запустить только одну цель за раз. Именно поэтому большинство make-файлов в качестве цели используют
all
, которая может вызывать столько целей, сколько необходимо.
Давайте добавим абстрактную цель
all
и уберем
.DEFAULT_GOAL
:
all: say_hello generate
say_hello:
@echo "Hello World"
generate:
@echo "Creating empty text files..."
touch file-{1..10}.txt
clean:
@echo "Cleaning up..."
rm *.txt
Прежде чем запустить
make
, давайте добавим еще одну абстрактную цель
.PHONY
, в которой мы определим все цели, которые не являются файлами.
make
запустит свой рецепт вне зависимости от того, есть ли файл с таким именем или каково время его последнего изменения. Вот так будет выглядеть готовый make-файл:
.PHONY: all say_hello generate clean
all: say_hello generate
say_hello:
@echo "Hello World"
generate:
@echo "Creating empty text files..."
touch file-{1..10}.txt
clean:
@echo "Cleaning up..."
rm *.txt
make вызовет say_hello и generate:
$ make
Hello World
Creating empty text files...
touch file-{1..10}.txt
Это обычная практика не вызывать
clean
в
all
или ставить его в качестве первой цели.
clean
должен вызываться вручную только тогда, когда в качестве первого аргумента для
make
нужна очистка:
$ make clean
Cleaning up...
rm *.txt
Теперь, когда вы имеете представление о том, как работает простой make-файл и как его можно написать, давайте рассмотрим несколько более сложных примеров.
Усложненные примеры
Переменные
В примере выше большая часть целевых и предварительных переменных являются неизменяемыми, но в реальных проектах они заменяются переменными и шаблонами.
Самый простой способ определить переменную в make-файле – использовать оператор =. Например, вот так выглядит присваивание команды
gcc
переменной
CC
:
CC = gcc
Также она называется
рекурсивной расширенной переменной (recursive expanded variable)
, и ее можно использовать в правиле:
hello: hello.c
${CC} hello.c -o hello
И как вы уже, наверное, догадались, при передаче в терминал в рецепте появляется дополнительный текст:
gcc hello.c -o hello
И
${CC}
, и
$(CC)
являются допустимыми ссылками для вызова
gcc
. Но если кто-то попробует переприсвоить переменную самой себе, то получится бесконечный цикл. Давайте проверим:
CC = gcc
CC = ${CC}
all:
@echo ${CC}
При запуске
make
получим следующее:
$ make
Makefile:8: *** Recursive variable 'CC' references itself (eventually). Stop.
Чтобы избежать такой ситуации, можно воспользоваться оператором := (это будет называться
простой расширенной переменной (simply expanded variable)
). И у нас не должно возникнуть проблем при запуске следующего make-файла:
CC := gcc
CC := ${CC}
all:
@echo ${CC}
Шаблоны и функции
Следующий make-файл может скомпилировать любую программу на C с помощью переменных, шаблонов и функций. Давайте рассмотрим его, строчку за строчкой:
# Usage:
# make # compile all binary
# make clean # remove ALL binaries and objects
.PHONY = all clean
CC = gcc # compiler to use
LINKERFLAG = -lm
SRCS := $(wildcard *.c)
BINS := $(SRCS:%.c=%)
all: ${BINS}
%: %.o
@echo "Checking.."
${CC} ${LINKERFLAG} $< -o $@
%.o: %.c
@echo "Creating object.."
${CC} -c $<
clean:
@echo "Cleaning up..."
rm -rvf *.o ${BINS}
Строки начинаются с
#
. Это комментарии.
Строка
.PHONY = all clean
определяет абстрактные цели
all
и
clean
.
Переменная
LINKERFLAG
определяет флаги, которые будут использоваться в рецепте вместе с
gcc
.
SRCS := $(wildcard *.c)
:
$(wildcard pattern)
- это одна из
функций для файловых имен
. В данной случае, все файлы с расширением
.c
будут хранится в переменной
SRCS
.
BINS := $(SRCS:%.c=%)
: это называется ссылкой с заменой. В данной случае, если
SRCS
будет иметь значение
'foo.c bar.c'
, то значение для
BINS
будет следующее:
'foo bar'
.
Строка
all: ${BINS}
: абстрактная цель
all
вызывает значения в
${BINS}
как отдельные цели.
Правило:
%: %.o
@echo "Checking.."
${CC} ${LINKERFLAG} $< -o $@
Чтобы понять это правило, давайте взглянем на пример. Предположим, что
foo
- это одно из значений
${BINS}
. Отождествим
%
с
foo
(
%
можно отождествить с любым именем цели). Ниже приведено правило в полной форме:
foo: foo.o
@echo "Checking.."
gcc -lm foo.o -o foo
Как показано выше,
%
заменяется
foo
.
$<
заменяется
foo.o
.
$<
выполняет соответствие по образцу с предварительными условиями, а
$@
отождествляется с целью. Это правило будет вызвано для каждого значения в
${BINS}
.
Правило:
%.o: %.c
@echo "Creating object.."
${CC} -c $<
Каждое предварительное условие в предыдущем правиле считается целью для этого правила. Ниже приведено правило в полной форме:
foo.o: foo.c
@echo "Creating object.."
gcc -c foo.c
И наконец, мы удаляем все двоичные и объектные файлы в цели
clean
.
Ниже приведен переписанный make-файл, который мы рассматривали выше, из расчета, что он находится в каталоге с единственным файлом
foo.c
:
# Usage:
# make # compile all binary
# make clean # remove ALL binaries and objects
.PHONY = all clean
CC = gcc # compiler to use
LINKERFLAG = -lm
SRCS := foo.c
BINS := foo
all: foo
foo: foo.o
@echo "Checking.."
gcc -lm foo.o -o foo
foo.o: foo.c
@echo "Creating object.."
gcc -c foo.c
clean:
@echo "Cleaning up..."
rm -rvf foo.o foo