как узнать айпи виртуальной машины
Как найти IP-адрес виртуальной машины, работающей на VMware (или других методах использования виртуальной машины)
Я использую VMware Workstation на Linux.
Когда я включаю виртуальную машину CentOS (Linux), я не могу получить контроль над машиной с помощью мыши или клавиатуры. Я подозреваю, что это как-то связано с сообщением об ошибке:
У вас не установлен VMware Tools в этом госте. Выберите «Установить VMware Tools» из меню VM.
Если я нажимаю на эту опцию меню, она вставляет виртуальный компакт-диск с драйверами и т. Д. Это не помогает мне, так как у меня нет управления клавиатурой или мышью над машиной.
Я думал, что если бы я мог выяснить IP-адрес или имя хоста, я мог бы использовать любое количество протоколов, чтобы войти в машину (SSH приходит на ум).
Как я могу получить IP-адрес или имя хоста этой машины?
Примечание: я не создавал эту машину. Создал коллегу, которого больше нет в компании. Это сэкономит мне много времени, если я смогу сесть в машину. У меня есть учетные данные, чтобы не было проблем.
Сначала зайдите в настройки виртуальной машины.
Затем в разделе «Сеть» нажмите кнопку «Дополнительно» и прочитайте MAC-адрес.
Найден MAC-адрес и IP будет на стороне.
В этом случае IP является: 192.168.20.128
в Linux команда выглядит так:
или довольно устаревший:
эквивалентная команда в Windows:
в то время как вывод выглядит примерно так:
В Workstation есть встроенный сервис VNC. Я не использовал его, но конфигурация (ниже), по-видимому, предполагает, что вы можете включить его и использовать IP своего хоста с определенным портом с любым из множества клиентов VNC, чтобы получить контроль над вашей виртуальной машиной.
Попробуйте выбрать подсеть, в которой находится ваша виртуальная машина, подключите другой компьютер к этой подсети (другую виртуальную машину или ваш физический компьютер) и воспользуйтесь услугой «Обозреватель компьютеров» («Сеть» или «Места моей сети»), чтобы найти виртуальную машину.
Вам также следует поискать программное обеспечение для сетевого сканирования.
Кстати, что такое режим сети ВМ? Только для хоста частная сеть (с NAT или без) или мостовая?
Как найти IP-адрес виртуальной машины KVM, чтобы я мог подключиться к ней по SSH?
Я следовал этому руководству ( Виртуализация с KVM в Ubuntu 11.10 ), чтобы настроить KVM (программное обеспечение для виртуальных машин) на моем сервере Ubuntu 11.10. Тем не менее, я не настраивал IP-адрес моей виртуальной машины при создании виртуальной машины вместо того, чтобы использовать:
Я установил сетевой мост в соответствии с инструкциями руководства, и интерфейс новой виртуальной машины подключен к сетевому мосту.
Я предполагаю, что KVM назначит мою виртуальную машину через DHCP, но у меня нет информации об IP-адресе новой виртуальной машины, где я могу найти IP-адрес виртуальной машины и SSH для новой виртуальной машины? Спасибо.
[Примечания: мне удалось войти в виртуальную машину, не зная IP-адрес виртуальной машины. Использование « Xming + SSH с перенаправлением графики X » Но моей виртуальной машине не назначен IP-адрес DHCP. Помимо вышеприведенного вопроса, у меня есть еще один вопрос: как включить DCHP на моей виртуальной машине, чтобы при входе в систему через Xming входить через Xming » Virt Viewer «Я могу по крайней мере увидеть мой IP-адрес там.]
Блог ниже содержит больше деталей и включает в себя Perl-скрипт, который автоматизирует поиск адреса виртуальной машины.
Вы также можете использовать следующую форму, если вы знаете MAC-адрес:
Я думаю, что это старый вопрос, но текущие версии virsh делают это намного проще, если вы используете nat или bridged частную сеть. У меня есть виртуальная машина, названная steak в (маршрутизируемой) частной сети (AKA «NAT»). Это всего лишь две команды, чтобы узнать, какой IP был назначен встроенным механизмом:
Настройка сети VirtualBox
Виртуальные машины VirtualBox очень часто используются для тестирования различного программного обеспечения и его взаимодействия между собой. Обычно, таким программам необходим доступ к интернету. Время от времени возникает необходимость протестировать работу программ по сети или даже создать небольшую тестовую лабораторию из виртуальных машин.
В этой инструкции мы рассмотрим как выполняется настройка сети VirtualBox различными способами. Вы узнаете как объединить машины в одну локальную сеть, как дать им доступ к интернету и как связать их с основной системой. Но сначала поговорим о том, как может работать сеть.
Виды сетевых адаптеров VirtualBox
Существует несколько способов как настроить сеть в virtualbox, и каждый из них подходит для лучше для решения одной задачи и меньше для другой. Рассмотрим основные:
Теперь рассмотрим каждый вариант настройки более подробно.
Настройка сети Virtualbox
1. Настройка сети NAT
Здесь почти нет о чем говорить. Получение доступа к сети через NAT включено по умолчанию. Проброс портов я рассматривал в отдельной статье. Но если вы раньше отключали сетевые адаптеры, то чтобы включить NAT обратно достаточно открыть настройки нужной машины:
Перейти на вкладку «Сеть»:
Выбрать один из адаптеров. К виртуальной машине можно подключить несколько адаптеров и это очень удобно, так как вы можете комбинировать вместе адаптер виртуального хоста и NAT чтобы получить преимущества обоих режимов. Дальше вам нужно выбрать пункт «NAT» в списке «Тип подключения».
На вкладке «Дополнительно» вы можете настроить марку устройства адаптера и MAC адрес:
Если вы собираетесь устанавливать туда в Windows, то лучше будет работать Intel PRO/1000 MT Desktop, а для Linux можно оставить AMD PCNet FAST III, так как он поддерживается всеми операционными системами.
2. Настройка сети NAT
Теперь все машины, подключенные к этой сети, будут доступны друг другу, как в VMWare.
3. Настройка адаптера виртуального хоста
Нажмите кнопку «Создать», затем, в появившемся адаптере, напротив пункта DHCP установите галочку «Включен».
Теперь вернитесь к списку виртуальных машин, зайдите в настройки машины, «Сеть»:
Для всех машин, которые вы хотите объединить в одну сеть нужно выбирать один и тот же адаптер хоста. Если вы захотите добавить машинам также доступ в интернет, просто перейдите на вкладку «Адаптер 2», включите его и настройте NAT, как описано в первом пункте.
4. Настройка сетевого моста VirtualBox
В поле «Имя» вам необходимо выбрать сетевой интерфейс, который будет использоваться для связи с внешним миром. Минус такого способа в том, что внешние компьютеры смогут получить доступ к виртуальной машине, а это не очень хорошо с точки зрения безопасности.
5. Внутренняя сеть VirtualBox
Выводы
В этой небольшой статье мы рассмотрели как выполняется настройка сети VirtualBox, как видите, это не так уж сложно, как может показаться на первый взгляд, несмотря на операционную систему, которую вы используете. В большинстве случаев достаточно сети NAT, но иногда может понадобиться виртуальный адаптер хоста, все же остальные режимы используются намного реже.
Настройка доступа к сети виртуальных машин Hyper-V из разных подсетей
Получилось так, что на днях пришлось побороться с проблемой одного из моих клиентов. Сервер клиента расположен в польском Дата-центре ATMAN. Несмотря на то, что этот Дата-центр крупный, цивилизованный и в 2013 году номинирован на звание лучшего в мире, в его работе тоже есть свои глюки, которые специалисты ATMAN объясняют спецификой построения инфраструктуры для борьбы с DDOS.
Если описывать вкратце — ATMAN распределяет дополнительные сетевые адреса из других под-сетей, что накладывает определенные ограничения на их использование. В том случае, о котором сейчас идет речь, необходимо использовать их не в качестве псевдонимов на сетевом интерфейсе рядом с основным адресом, а в качестве основных IP для виртуальных машин под управлением Hyper-V.
Я попытался найти решение аналогичной проблемы в поисковиках, но не нашел и поэтому решил написать краткую инструкцию для тех, кто может столкнуться с подобной проблемой в будущем.
В нашем примере будут использованы такие сетевые настройки:
Основной IP: ***.189.53.206/30
Дополнительный IP: ***.91.26.173/32
Сервер имеет два сетевых интерфейса, но используется только один. Все операции буду выполняться именно с ним.
Рис.1. Для удобства стандартные имена были изменены на LAN1 (используется для доступа к сети) и LAN2 (отключен).
Рис.2. Основной интерфейс настраиваем согласно предоставленным ДЦ данными.
Далее, необходимо настроить два виртуальных маршрутизатора — первый имеет тип «Внешний» с выходом во внешний мир, второй «Внутренний» для коммутации корневого сервера с виртуальным хостом. Оба виртуальных коммутатора необходимо создать в диспетчере виртуальных сетей консоли управления Hyper-V.
Рис.3. Для внешнего интерфейса необходимо использовать сетевую карту с доступом в интернет.
Рис.4. Для внутреннего виртуального коммутатора используются настройки, как показано на этом рисунке.
На этом подготовка новых сетевых интерфейсов закончена. У нас должно получиться такое:
Рис.5. Два дополнительных интерфейса – внешний и внутренний
При создании внешнего интерфейса произойдет разрыв всех соединений. Убедитесь в том, что у Вас есть другой доступ к серверу (IP-KVM, IPMI или непосредственно физический).
В нашем случае мне повезло и ДЦ дает IPMI по умолчанию.
В настройках внутреннего интерфейса (Internal) укажите настройки схожие с теми, что используются тут, в нашем случае это 192.168.0.1. Этот интерфейс на физическом сервере будет выступать в роли шлюза для виртуальных машин.
Рис.6. Настройки для внутреннего виртуального коммутатора.
Дальнейшие настройки сетевых интерфейсов на корневом сервере завершены. Далее необходимо настроить службу RRAS для перенаправления трафика к виртуальным машинам и обратно.
Для реализации этого необходимо установить роль «Службы политики сети и доступа» в оснастке Диспетчера сервера. Думаю, что расписывать этот процесс нет необходимости – Вы же уже установили роль Hyper-V ранее
Рис.7. Установленная роль RRAS.
После завершения установки данной роли она находится в статусе «Остановлена». По этому, ее нужно изначально настроить перед запуском.
Рис.8. Начальная настройка службы.
Перед Вами откроется окно мастера настройки службы. Выполняйте все действия, как показано на рисунках.
Рис.9. Окно мастера настройки службы.
Рис.10. Выбор особой конфигурации для нашего случая.
Рис.11. Выбираем только преобразование адресов и маршрутизацию локальной сети.
Рис.12. Завершающий этап настройки. Нажимаем «Готово».
Рис.13. Соглашаемся на предложение запустить новую службу.
После этого мы увидим в Диспетчере сервера развернутое дерево элементов этой самой службы RRAS.
Рис.14. Служба готова к настройке.
Для перенаправления трафика к виртуальной машине нужно создать интерфейс через который будут проходить все запросы. ПКМ на элементе «Преобразование сетевых адресов» выбираем пункт «Новый интерфейс».
Рис.15. Создание нового интерфейса.
В окне выбора интерфейсов нам необходимо использовать внешний сетевой интерфейс. Внутрений используется только для связи корневого сервера с виртуальными машинами.
Рис.16. Выбор интерфейса для преобразования сетевых адресов.
В свойствах внешнего интерфейса нам необходимо включить преобразование адресов, как показано ниже:
Рис.17. Включение преобразования адресов.
Далее, добавляем пул адресов, это наши дополнительные адреса запросы от которых будут перенаправляться на внутренние адреса виртуальных машин. ВАЖНО: не указывайте маску 255.255.255.255 для этих целей, работать это не будет. В нашем случае мы имеем три дополнительных адреса, маска указана /24 (особой роли это не играет).
Рис. 18. Заполняем данные в окне пула адресов.
Теперь необходимо зарезервировать дополнительный адрес за внутренним у виртуальной машины. Делается все это очень просто.
Рис.19. Резервирование адресов для виртуальных машин.
В сетевых настройках указываем данные из той подсети, в которой находится шлюз. В нашем случае внутренняя подсеть вида 192.168.0.0/24, дополнительный адрес ***.91.26.173 мы закрепили за внутренним 192.168.0.3. Настройки сети виртуальной машины выглядят таким образом:
Рис.20. Сетевые настройки виртуальной машины.
Если все настроено правильно, то в центре управления сетями виртуальной машины получим такой вид (машина имеет доступ к интернету). В ином случае – проверьте настройки Брендмауэра на серверах.
Рис.21. Центр управления сетями виртуальной машины.
Любым сервисом проверяем корректность наших глобальных настроек. Результат: запрос с виртуальной машины должен показать нам именно внешний адрес, который был зарезервирован нами ранее:
Рис.22. Результат теста на сайте 2ip.ru.
На виртуальной машине, для проверки перенаправления портов, трафика, мигрантов и прочего, была установлена роль IIS. С любого ПК в браузере обращаемся к данному адресу, если видим «заглушку» веб-сервера – все прошло отлично, поставленную задачу мы решили.
Рис.23. То, чего и добивались. Все работает.
Таким образом, мы можем использовать множество разных подсетей на одном физическом сервере. С той лишь разницей, что для разных внутренних подсетей необходимо будет создавать отдельные виртуальные коммутаторы.
Задаём виртуальной машине IP по MAC без использования DHCP
В статье рассказывается о использовании скриптов для CentOS и Windows XP, которые устанавливают IP в соответствии с MAC сетевого интерфейса VM, а также о сложностях управления сетевым интерфейсом в Windows
Система, которую мы разрабатываем, очень активно работает с виртуальными машинами. Когда ядру системы требуется очередная машина, копируется шаблонный образ, и запускается эта копия. Таким образом, одновременно может работать очень много копий по сути одной и той же машины.
Конечно, в момент запуска каждая виртуальная машина идентична шаблонной. В том числе наследуются и установленные параметры сети. Все виртуальные машины работают в одной подсети, а значит, они не должны пользоваться тем статическим IP, который достался им от шаблонной машины — иначе будут возникать конфликты. То есть каждая машина должна получить собственный IP. Казалось бы, решение очень простое — использовать DHCP сервер и динамические IP.
Спойлер: собственно, самое интересное — в пунктах 3) и 5), остальное — для тех, кто захочет увидеть всю картину.
1. Для чего нам нужны виртуальные машины
Наш проект, Nerrvana, выполняет функциональные тесты сайтов в разных браузерах. Тесты эти работают со специальным фреймворком для функционального тестирования — Selenium, который позволяет эмулировать действия пользователя в брaузере (клики по элементам, движения мышью, ввод символов, чтение текста), делать скриншоты страниц и некоторые другие вещи.
Тест сайта представляет собой последовательность действий, которые мог бы сделать на сайте пользователь, и проверок, что результат этих действий — точно такой, как ожидается. Например, простейший тест — логин на сайт. Необходимо открыть страницу логина, ввести логин, пароль, нажать «Ввод», и убедиться, что мы залогинены — скажем, увидев стандартное приветствие. Все знают, что браузеры могут совершенно по-разному отображать и работать с одной и той же страницей, и поэтому имеет смысл выполнить одинаковые тесты в наиболее популярных браузерах. Как уже говорилось, именно этой работой и занимается наша система.
Тесты в выбранных браузерах выполняются одновременно и совершенно независимо друг от друга. Выполнение теста в одном из браузеров мы назвали спеком (speck). То есть, допустим, если я хочу выполнить тест логина на браузерах IE 8 и FF 3.6, наша система сделает два независимых спека — выполнит код тестов с использованием выбранных браузеров. Не сильно вдаваясь в подробности, скажу, что для работы каждого спека мы создаём как минимум две виртуальные машины. Одна машина, «хаб», будет заниматься собственно выполнением тестов — там есть Java и PHP, на которых должны быть написаны тесты. На второй машине, «тестере», работает Selenium RC и нужный браузер. Через Selenium RC происходит взаимодействие между тестами и браузером. После выполнения каждого спека виртуальные машины, на которых он работал, уничтожаются.
Так как одновременно работающих тестов может быть много, и каждый может использовать несколько спеков, виртуальных машин тоже может работать относительно много — 50, к примеру.
2. Проблема одинаковых статических адресов при запуске нескольких клонов VM
Для каждого типа виртуальных машин имеется шаблонный образ. Когда ядру системы требуется очередная машина, этот образ копируется, и запускается копия образа — сам образ остаётся неизменным. Таким образом, одновременно может работать очень много копий по сути одной и той же машины.
И тут появляется некоторая проблема.
Естественно, в момент запуска каждая виртуальная машина абсолютно идентична шаблонной — ведь все данные хранятся в образе, в который нельзя внести изменений. В том числе наследуются и установленные параметры сети. Так как все виртуальные машины работают в одной подсети, совершенно очевидно, что они не должны пользоваться тем статическим IP, который достался им от шаблонной машины — иначе будут возникать конфликты адресов. То есть каждая машина должна динамически получить собственный IP.
Казалось бы, решение очень простое — использовать DHCP сервер, который и выдаст каждой машине уникальный адрес.
Однако, не всё так просто. Дело в том, что ядро системы активно взаимодействует с виртуальными машинами. Оно должно проделать просто кучу работы с ними: например, убедиться, что виртуальные машины успешно стартовали, запустить Selenium RC на тестере, загрузить на хаб и выполнить сами тесты, следить за их выполнением, а потом получить обратно результаты (скриншоты, логи и т.д.). Работа ведётся через ssh.
Т.е. ядро системы, как ни крути, должно знать IP-адреса машин, которые только что были запущены по её требованию.
Мы видели два подхода к решению задачи:
1) После того, как виртуальная машина поднялась, она получает случайный адрес от DHCP, и затем каким-то образом регистрирует себя в базе — т.е. указывает, что я — машина такого-то типа, получила от DHCP такой-то адрес.
2) Каким-то образом ядро даёт понять виртуальной машине, какой адрес ей следует использовать, т.е. соответствие IP — виртуальная машина имеется ещё до запуска машины.
Первый вариант казался нам довольно сложным по нескольким причинам. Этот вариант делал VM слишком независимыми от ядра, появлялась лишняя связь — от виртуальной машины к базе, появлялись сложности с сопоставлением запрошенных и зарегистрированных VM, и некоторые проблемы, связанные с архитектурой ядра.
Второй вариант нам нравился куда больше, потому что ядро сразу получало полный контроль над VM, а не оказывалось в подвешенном состоянии в ожидании, пока VM сама зарегистрируется.
3. Кодируем IP в MAC
Как же воздействовать на ещё не запущенную машину, чтобы сообщить ей будущий ip-адрес? Мы нашли такой способ: при запуске виртуальной машины можно задать MAC-адрес виртуальной сетевой плате. А сама виртуальная машина может в любой момент его узнать. То есть MAC можно использовать как носитель информации о IP (или о чём-нибудь ещё).
Осталось заставить машину получить нужный IP, соответствующий её MAC. Это опять-таки можно сделать двумя способами.
4. Выделение IP по MAC: DHCP
Первый способ довольно очевиден. Мы запустим DHCP сервер, который будет настроен так, чтобы выдавать IP по MAC-адресу в соответствии с описанным способом кодирования.
Сценарий работы будет выглядеть так:
1) Ядру требуется VM.
2) Ядро просматривает пул IP-адресов, выбирает первый незанятый IP (например, 10.4.0.15), и преобразует его в MAC (00:16:3E:04:00:0F)
4) Ядро копирует шаблонный образ VM нужного типа, подготавливает файл конфигурации VM (в котором указывает в том числе и полученный MAC)
5) Ядро запускает VM
6) VM обращается к DHCP за адресом, тот сверяется с таблицей соответствия MAC/IP, и выдаёт IP 10.4.0.15.
7) Ядро в это время периодически пингует 10.4.0.15, и, получив ответ, начинает работать с виртуальной машиной (конечно, предварительно дождавшись старта sshd)
— требуется DHCP сервер
— если мы переедем в другую подсеть или получим другой пул IP-адресов, придётся менять конфигурацию не только ядра, но и DHCP
+ используется стандартный подход к получению IP
5. Выделение IP по MAC: скрипт mac2ip
Второй способ менее очевиден и требует некоторой дополнительной работы.
Он заключается в том, что VM при старте выполнит специальный скрипт, который получит MAC, преобразует его в IP, и назначит сетевой плате. Сценарий работы, таким образом, будет практически таким же — изменится только пункт 6. Он будет выглядеть так:
6) VM вычисляет свой IP на основании своего MAC, и устанавливает его перед стартом интерфейса.
+ не требуется дополнительное звено в виде DHCP и хранения там таблицы соответствия MAC-IP.
— для каждой ОС потребуется свой скрипт mac2ip
Мы реализовали именно этот вариант.
Мы работаем с виртуальными машинами с CentOS 5.6 и Windows XP PRO SP3, и поэтому нам нужно было два скрипта mac2ip — для каждой из систем.
Рассмотрим оба скрипта.
a) Linux
И заставляем запускаться этот скрипт до запуска network.
b) Windows
Та же самая работа в Windows XP делается куда более заумными путями. Возможно, со временем найдётся более эффективный способ преобразования MAC в IP.
Первая проблема, с которой я столкнулся — это невозможность относительно лёгкими путями изменить адрес интерфейса ДО его включения. Таким образом, шаблонная VM должна иметь выключенный по умолчанию «сетевое подключение», иначе две одновременно запущенные копии Windows сразу после запуска попробуют использовать один и тот же адрес (он статический, т.к. для VM мы не используем DHCP).
Для манипуляций с устройствами используется утилита devcon.
Вот как это выглядит:
Добавляем этот скрипт в автозагрузку — например, так (требуется перезагрузка):
Таким образом, после выполнения этих скриптов виртуальная машина получит заданный ядром адрес, и будет готова к работе.
Ядро узнает об этом по заработавшему пингу к этому адресу.
Возможно, эта схема добавит наглядности (по клику — полный размер в новом окне):
6. Замечания
Используемый нами способ — со скриптом mac2ip в автозагрузке — оказался довольно медленным в Win XP. Во всяком случае, текущая его реализация делает свою работу 10-15 секунд. При этом время, которое уходит от старта виртуальной машины до начала выполнения скрипта mac2ip, составляет 15-20 секунд.
Однако мы не спешим перейти на использование первого способа (DHCP с привязкой IP к MAC), потому что:
— во-первых, VM у нас завершаются не штатным для них способом (т.е. centos/windows не выполняют завершение работы), а выполнением virsh destroy для VM (всё равно, что питание выдернуть). Это позволяет экономить много времени, а целостность использованной VM нас всё равно не интересует — она будет немедленно удалена после использования. Так вот, арендованный VM адрес не будет в этом случае освобождён сразу, а будет освобождён по истечении default-lease-time DHCP. Это значит, что мы не сможем сразу же запустить VM с таким же MAC (и таким же IP). Вряд ли установка default-lease-time слишком маленьким (секунды) — хорошая идея. Более реальный вариант — изучение и использование OMAPI/omshell, и с их помощью удалять ненужные записи DHCP сразу после остановки VM.
— во-вторых, для Linux получение адреса от DHCP будет происходить медленнее, чем текущий вариант с назначением статического адреса.
— в третьих — конечно, обнаружатся и другие подводные камни.
Так что относительно медленная работа текущей версии скрипта в Windows — недостаточная причина для того, чтобы перейти на использовать варинанта с DHCP.
Идеальным решением было бы ускорение работы скрипта mac2ip для Windows. Буду рад советам — поскольку это мой первый опыт в управлении сетевым интерфейсом windows из скриптов, то, возможно, уже имеется велосипед.
Update: Во-первых, The_Kf открыл глаза на банальный способ получения MAC на выключенном интерфейсе с помощью ipconfig.
Во-вторых, gribozavr провёл эксперимент, который показал, что заботиться о lease-time арендованного IP вообще не надо, потому что при привязке IP к MAC DHCP выдаст IP в любом случае машине с тем же MAC, даже ели аренда не истекла. Также он указал на stateless autoconfiguration из IPv6.
В-третьих, при общении с akshakirov я внезапно понял, почему сразу более пристально не смотрели в сторону DHCP.
Update 2: в-четвёртых, amarao предложил использовать xenstore для передачи IP в VM. В гостевой Linux-машине для этого просто надо установить xenstore-utils, однако для винды, возможно, потребуется написать утилиту для чтения из xenstore.