Come trovare dom0 nome da domu ospitato

Sto veramente testando RHEL 5.3 con Xen tra due server per avere una soluzione di ripristino di emergenza. Quindi sto giocando a spostare il mio domU da un server dom0 all'altro server.

Sfortunatamente quando qualcun altro si muove il domU non ho alcun indizio where il mio dominio è ospitato. Mi chiedo where non riesco a trovare il mio nome dom0 con domu dentro. Sto cercando qualcosa come il command gzonename su una zona sparsa solaris. Io controllo all'interno / proc / xen ma non vedo niente di speciale tranne la release del kernel dom0.

  • Xen trova ID VBD per i dischi fisici
  • La connessione SSL si blocca come client hello (curl, openssl client, apt-get, wget, tutto)
  • Posso automatizzare XEN? E in che misura
  • Ubuntu upstart si blocca su start & stop interattivo
  • Sync tempo NTP non funziona in un server DOMU Centos 5.5
  • Come evitare che venga salvato un dominio XenU
  • Qualcuno sa un'attesa per trovare questo?

    6 Solutions collect form web for “Come trovare dom0 nome da domu ospitato”

    Usiamo xenstore-write /tool/hostname $(uname -n); xenstore-chmod /tool/hostname r xenstore-write /tool/hostname $(uname -n); xenstore-chmod /tool/hostname r su Dom0 e poi xenstore-read /tool/hostname all'interno delle VM. Facile e leggero …

    Sono abbastanza sicuro che non c'è modo di trovare il dom0 "nome" (che è un concetto nebuloso nel migliore dei casi) dall'interno del domU. Se non si sta eseguendo pygrub, è ansible aggiungere qualcosa alla row di command di avvio del kernel (nel file di configuration domU memorizzato in each dom0) che si potrebbe chiedere da / proc / cmdline, ma è un po 'un hack.

    Quello che dovresti realmente fare è avere uno script che possa interrogare dom0s per mostrare quali sono le VM. Anche qualcosa che ha attraversato il domo e l' xm list sarebbe probabilmente per i tuoi scopi semplici.

    SLES11 ha una soluzione "intelligente" fornita da due rpms:

    Il primo viene eseguito sul Dom0 e crea un piccolo ram-disk (loop-device in / dev / shm). Quel ram-disk è collegato in ro / read multi-mode al DomU. Quindi un process daemon in Dom0 aggiorna alcune informazioni nel ram-disk ad intervalli configurabili (Dom0-hostname, cpu-load del Dom0, …).

    Il secondo funziona nel DomU e legge i valori di quel ram-disk allegato.

    Vedere la documentazione SLES11 XEN per ulteriori dettagli …

    Aggiornamento 2017-01-31: Sezione 10.7

    Ho trovato una soluzione intelligente (che non posso credere): aggiungere un parametro allo script Xen per indicare il domU dom0 in cui è in esecuzione

    So che questo è stato pubblicato da alcuni anni ma vedo che questa è una pagina fortemente accessibile che ancora non ha un modo per trovare questo retroattivo, quindi ecco il metodo che ho usato:

    Dal VM, utilizzare tcpdump per trovare il nome dell'interruttore e il numero di port:

     [myID@vm001 ~] sudo tcpdump –nn –v –i eth0 –s 1500 –c 1 'ether[20:2] == 0x2000' 

    Dare qualche minuto. correre; quando è finito, cercare queste due righe nell'output (saranno separate da altre linee di output):

     Device-ID (0x01), length: 26 bytes: 'Switch001.mydomain.com' Port-ID (0x03), length: 19 bytes: 'GigabitEthernet8/17' 

    Dovresti quindi esaminare la port switch per determinare quale server fisico è collegato. Speriamo che tu abbia l'accesso fisico all'interruttore e sia in grado di eseguire una traccia di cavi o di impegnare qualcuno che possa o abbia delle buone descrizioni sulle configurazioni delle porte di interface e possa visualizzare tali informazioni o impegnare qualcuno che possa. Ho letto l'accesso ai nostri switch ed è stato in grado di trovare il mio server host in questo modo:

     SWITCH001#sho interface description | inc 8/17 Gi8/17 up up HOST0002 

    Installare lldpd su Xen Dom0 e DomUs. Poi lldpctl ti dirà quale ponte di networking e il nome host del ponte (cioè il nome del Dom0). Sul Dom0 vednetworking anche gli switch a monte se hanno LLDP abilitato, che può anche essere utile.

    Questo funziona per PV, PVHVM, ecc. Infatti, dovrebbe funzionare per qualsiasi piattaforma di virtualizzazione in grado di eseguire LLDP nell'host, a less che l'host inoltri i pacchetti LLDP direttamente (cosa che non dovrebbe).

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.