Вы действительно не должны пытаться найти неиспользованные IP-адреса в сети, которая использует DHCP. Вы не должны делать этого, если Вы не знаете то, что Вы делаете и спрашиваете, как сделать это, предлагает, чтобы Вы не делали.
Управление сетевым адресом является неявно организационным (не техническое) действие. DHCP заставляет администраторов сети часто думать, что это является чисто техническим, но протокол хорошо разработан и может легко поддерживать Ваши потребности с определенными политическими переговорами.
DHCP имеет функцию, где определенным системам можно дать тот же IP-адрес каждый раз, когда (другими словами, механизм присвоения может быть динамичным, но сами присвоения могут быть зафиксированы).
Попросите, чтобы Ваш администратор DHCP создал некоторые записи для Вас. Если они говорят "нет", сделайте некоторую работу, требующую беготни и попросите, чтобы Ваш менеджер попросил, чтобы их менеджер сделал это.
Или попросите, чтобы администратор DHCP выделил диапазон IP-адреса для Вашего персонального использования, но не служил им из DHCP.
Это находится действительно в общих интересах. Если Вы проектируете, ценность небольшого дополнительного усилия, некоторая организационная любовь будет иметь большое значение.
Я не думаю, что другие плакаты думали серьезно о том, что может произойти, и часть опасности - то, что результаты конфликтов IP-адреса непредсказуемы:
Если Вы незаконно охотитесь на адреса, и затем они конфликтуют с чужой системой, результаты могут быть болезненными, как окончание задания.
Системы ведут себя по-другому, когда у них есть конфликты IP. Немного отбрасывают себя быстро. Некоторые просто помещают странные предупреждения на Ваш экран. Потенциально некоторые системы бились бы за IP-адрес.
Вы не знаете, какую систему Вы разъединили бы. Вы могли разъединять важный сервер, или Ваша система могла бы иметь тупиковый сервер, который начинает отвечать на реальный трафик. Или это могли быть Вы ПК босса или некоторый старший технический человек, который был также сидением на корточках IP.
Вот история DNS, которая довольно подобна. Я работал с умным, но иногда неприятным человеком в компании, и он понял большую часть из всего, кроме разрешения DNS. Он настроил приблизительно 80% почтовых систем компаний так, чтобы, если было незначительное отключение электричества, моя лабораторная среда закончила тем, что была исходящим почтовым сервером. Они поймали эту проблему быстро, но можно вообразить, как плохо это могло быть то, если моя система не поставила почту в очередь позади брандмауэра.
Если это - Windows, просто взгляните на аппаратные экраны. Это будет иметь миллиард и пять виртуальных устройств с торговой маркой VMware.
Если это - Unix VM, используйте imvirt. Это - сценарий Perl, который обнаруживает VMware, Xen и несколько других.
Вы могли попробовать "программу" Обнаружения Хоста.
Если это обрабатывается VMware, это не слишком трудно в настоящий момент. Это могло измениться в будущем.
# dmidecode -s system-manufacturer
VMware, Inc.
У меня был тот же вопрос, и я обнаружил, что есть много процессов, работающих с "VM" в имени, например VMWareTray.exe
В Linux вы можете также используйте "virt-what". « virt-what - определить, работаем ли мы на виртуальной машине ».
В окне CMD введите:
SYSTEMINFO
Вы найдете строку со следующим текстом (или аналогичным):
System Manufacturer: VMware, Inc.
System Model: VMware Virtual Platform
Если вы работаете в Windows, как говорит castrocra , вы можете запустить команду systeminfo
из оболочки cmd , затем найдите «Версия BIOS».
Это, вероятно, настоящие машины:
BIOS Version: Dell Inc. A03, 06/12/2010
BIOS Version: Phoenix Technologies, LTD MS7254 1.08, 08/03/2007
Это, с другой стороны, почти наверняка виртуальная машина:
BIOS Version: VMware, Inc. VMW71.00V.0.B64.1201040214, 04/01/2012
nbtstat -a В результате вы увидите, что виртуальные машины имеют специальный префикс 00-50-56-XX-XX-XX. Есть еще один префикс, который он использует, но я не могу вспомнить, но я помню, что Vcenter использует 00-50-56-XX-XX-XX, поэтому я проверяю только этот ios.
Я думаю, что это лучший способ лично.
On Windows, from CMD:
Systeminfo | findstr /i model
returns something like:
System Model: VMware Virtual Platform
[01]: Intel64 Family 6 Model 26 Stepping 5 GenuineInt
Ответ получен, но FWIW вы можете сделать это в powershell:
gwmi -q "select * from win32_computersystem"
"Производитель" будет "Microsoft Corporation", а "Модель" будет "Виртуальная машина", если это виртуальная машина, или она должна отображать обычные данные производителя, если это не так, e. g. "Dell Inc." и "PowerEdge R210 II" соответственно
.Одним (относительно) простым способом обнаружения ключевой информации виртуализации является WMI / WBEM. Вы можете использовать пространство имен root \ CIM2 и получить доступ к классу Baseboard (полный интересной информации о BIOS), чтобы получить описание «физической» системы. Этот класс часто включает информацию о материнской плате и шасси - производитель, модель, серийный номер и т. Д.
Выполните следующую команду из командной строки или сеанса PowerShell:
wmic baseboard get manufacturer, product, Serialnumber, version
Еще проще - wmic / node: bios get serialnumber
Все, что возвращает серийный номер в стиле Dell, является физическим.
Он также возвращает "VMware-42 22 26 a8 dd 6e" e3 b3-2e 03 fc 2c 92 ae 2e 89 ", если это виртуальная машина.
Есть еще один вариант здесь, который описывает официальный способ сделать это:
Для Windows:
Нажмите Пуск > Выполнить. Введите msinfo32 и нажмите Enter. На правой панели найдите «Производитель системы» для «VMware, Inc.»
.