На самом деле я тестирую RHEL 5.3 с Xen между двумя серверами, чтобы иметь решение для аварийного восстановления. Итак, я играю с перемещением моего domU с одного сервера dom0 на другой сервер.
К сожалению, когда кто-то еще перемещает domU, я не имею ни малейшего представления о том, где размещается мой домен. Мне интересно, где я не могу найти свое имя dom0 с внутри domU. Я ищу что-то вроде команды gzonename в разреженной зоне solaris. Я проверяю внутри / proc / xen, но не вижу ничего особенного, кроме выпуска ядра dom0.
Кто-нибудь знает, как долго это найти?
Мы используем xenstore-write /tool/hostname $(uname -n); xenstore-chmod /tool/hostname r на Dom0 а потом xenstore-read /tool/hostname внутри виртуальных машин. Легкий и легкий ...
Я почти уверен, что нет способа найти "имя" dom0 (что в лучшем случае является туманным понятием) внутри domU. Если вы не используете pygrub, вы можете добавить что-нибудь в командную строку загрузки ядра (в файл конфигурации domU, хранящийся на каждом dom0), что вы могли бы запросить из / proc / cmdline, но это немного похоже на взлом.
Что вам действительно нужно сделать, так это иметь сценарий, который может запрашивать dom0, чтобы показать, какие виртуальные машины где находятся. Даже то, что прошло через dom0s и запустило xm list вероятно, подойдет для ваших простых целей.
У SLES11 есть "умное" решение, обеспечиваемое двумя RPM:
Первый запускается на Dom0 и создает небольшой RAM-диск (loop-device в / dev / shm). Этот RAM-диск подключен к DomU в режиме ro / read many. Затем процесс-демон в Dom0 обновляет некоторую информацию на RAM-диске с настраиваемыми интервалами (Dom0-hostname, cpu-load Dom0, ...).
Второй запускается в DomU и считывает значения этого подключенного RAM-диска.
См. Документацию SLES11 XEN для получения дополнительной информации ...
Обновление 2017-01-31: раздел 10.7
Я нашел умное решение (за которое не могу поверить): добавьте параметр в сценарий Xen, чтобы сообщить domU, на каком dom0 он запущен
Я знаю, что это публиковалось уже несколько лет, но я вижу, что это страница с большим доступом, на которой до сих пор нет способа найти ее задним числом, поэтому вот метод, который я использовал:
На виртуальной машине используйте tcpdump, чтобы найти имя коммутатора и номер порта:
[myID@vm001 ~] sudo tcpdump –nn –v –i eth0 –s 1500 –c 1 ‘ether[20:2] == 0x2000’
Подождите несколько минут. бежать; когда это будет сделано, найдите эти две строки в выводе (они будут разделены другими строками вывода):
Device-ID (0x01), length: 26 bytes: ‘Switch001.mydomain.com’
Port-ID (0x03), length: 19 bytes: ‘GigabitEthernet8/17’
Затем вам нужно будет посмотреть на порт вашего коммутатора, чтобы определить, какой физический сервер подключен. Надеюсь, у вас есть физический доступ к коммутатору и вы можете выполнить трассировку кабеля, или вы можете привлечь кого-то, кто может, или у вас есть хорошее описание конфигураций портов коммутатора и вы можете просмотреть эту информацию или привлечь кого-то, кто может. У меня есть доступ для чтения к нашим коммутаторам, и я смог найти свой хост-сервер таким образом:
SWITCH001#sho interface description | inc 8/17
Gi8/17 up up HOST0002
Установите lldpd на Xen Dom0 и DomU. Затем lldpctl сообщит вам, какой сетевой мост и имя хоста моста (то есть имя Dom0). На Dom0 вы также увидите вышестоящие коммутаторы, если у них включен LLDP, что также может быть полезно.
Это работает для PV, PVHVM и т. Д. Фактически, это должно работать для любой платформы виртуализации, которая может запускать LLDP на хосте, если только хост не пересылает пакеты LLDP напрямую (что не должно).