VMware Player e systemd.

Visualizzazione dei risultati da 1 a 3 su 3

Hybrid View

Messaggio precedente Messaggio precedente   Prossimo messaggio Prossimo messaggio
  1. #1
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    44
    Messaggi
    23,415
    configurazione

    Predefinito VMware Player e systemd.

    Systemd è il nuovo gestore di sistema e di servizi candidato a diventare lo standard le prossime distribuzioni Linux, dato che molte delle maggiori distro si stanno convertendo a questo sistema, abbandonando progressivamente il vecchio sysvinit (per diversi motivi). Ovviamente questa transizione richiede alcuni adattamenti, non ultimo il fatto che tutti gli script che gestivano lo startup dei demoni in esecuzione devono essere riscritti.

    La mia Arch è recentemente migrata a questo nuovo sistema e, approfittando di un cambio hardware, ho reinstallato il sistema per avere un'installazione "full systemd" senza dover migrare l'installazione dal sistema sysvinit.
    Uso vmware Player per le mie virtual machine e avevo già riscontrato in passato il problema noto della mancanza dello script "vmware-USBArbitrator" necessario per passare alla vm in esecuzione le periferiche USB connesse al sistema fisico. Il problema può essere facilmente risolto seguendo le istruzioni del post linkato ma è poi necessario fare in modo che questo servizio si avvi automaticamente al boot ma solo dopo i servizi vmware, altrimenti il supporto USB alle VM sarà comunque non disponibile...
    Non ho trovato alcuna indicazione in merito a come creare il file ".service" che costituisce lo script di avvio "systemd compliant" per avviare questo servizio automaticamente e soprattutto in modo da rispettare il requisito di priorità degli altri servizi vmware.
    Di seguito, il modo in cui mi sono arrangiato.


    Il sistema utilizza per impostazioni predefinite due directory per i files ".service" (detti "unit"): Il percorso per le unit di sistema (gestite quindi dalla distro) è in "/usr/lib/systemd/system/" mentre i files .service personalizzati o modificati dall'utente dovrebbero essere archiviati nel percorso "/etc/systemd/system/". Questi ultimi hanno precedenza, quindi è possibile creare in questa directory un ".service" personalizzato senza alterare quello predefinito o fornito dalla distro.
    L'installazione di vmware player (eseguita con il binario scaricato direttamente dal sito) ha creato solo il file "/etc/systemd/system/vmware.service" che non prevede l'avvio dei servizi USB. E' quindi sufficiente creare ex-novo il file .service per il demone vmware-usbarbitrator e aggiungervi il requisito di priorità dei servizi vmware.

    Ho quindi creato il seguente file "/etc/systemd/system/vmware-USBArbitrator.service" (non è necessario assegnargli l'attributo "x"):
    codice:
    [Unit]
    Description=VMware USBArbitrator daemon
    Requires=vmware.service
    After=vmware.service
    [Service]
    ExecStart=/etc/rc.d/vmware-USBArbitrator start
    ExecStop=/etc/rc.d/vmware-USBArbitrator stop
    PIDFile=/var/lock/subsys/vmware-USBArbitrator
    TimeoutSec=0
    RemainAfterExit=yes
    [Install]
    WantedBy=multi-user.target
    e l'ho avviato con il comando:

    codice:
    [root@arch-uefi /]# systemctl start vmware-USBArbitrator.service
    Verificato che ora è possibile passare le periferiche USB alle vm ho abilitato il servizio per l'avvio automatico al boot con il comando:

    codice:
    [root@arch-uefi /]# systemctl enable vmware-USBArbitrator.service
    che non fà altro che creare un collegamento simbolico a questo files nel percorso "/etc/systemd/system/multi-user.target.wants/" (ln -s '/etc/systemd/system/vmware-USBArbitrator.service' '/etc/systemd/system/multi-user.target.wants/vmware-USBArbitrator.service')

    That's all, folks!


    Per rimuovere il demone dall'avvio automatico è sufficiente usare il comando :
    codice:
    [root@arch-uefi /]# systemctl disable vmware-USBArbitrator.service
    rm '/etc/systemd/system/multi-user.target.wants/vmware-USBArbitrator.service'
    Avvio e arresto del servizio si possono gestire con i comandi:
    codice:
    [root@arch-uefi /]# systemctl stop vmware-USBArbitrator.service
    codice:
    [root@arch-uefi /]# systemctl start vmware-USBArbitrator.service
    Lo stato del servizio si può verificare con il seguente comando (che mostra anche le relative informazioni recenti presenti nel log di sistema):
    codice:
    [root@arch-uefi /]# systemctl status vmware-USBArbitrator.service
    vmware-USBArbitrator.service - VMware USBArbitrator daemon
              Loaded: loaded (/etc/systemd/system/vmware-USBArbitrator.service; enabled)
              Active: active (exited) since dom, 2013-01-13 17:10:53 CET; 5min ago
             Process: 2632 ExecStop=/etc/rc.d/vmware-USBArbitrator stop (code=exited, status=0/SUCCESS)
             Process: 2644 ExecStart=/etc/rc.d/vmware-USBArbitrator start (code=exited, status=0/SUCCESS)
              CGroup: name=systemd:/system/vmware-USBArbitrator.service
                      └─2649 /usr/bin/vmware-usbarbitrator
    
    gen 13 17:10:53 arch-uefi systemd[1]: Starting VMware USBArbitrator daemon...
    gen 13 17:10:53 arch-uefi systemd[1]: Started VMware USBArbitrator daemon.

    Ref:
    systemd (dal wiki di Arch Linux)
    VMware su Arch Linux (sempre dal wiki di Arch Linux)

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  2. #2
    Supervisore Straordinario L'avatar di tHeGoOd
    Registrato
    Sep 2000
    Località
    Cenaia, Toscana, Italy, Italy
    Età
    39
    Messaggi
    1,669

    Predefinito

    Grande lavoro frakka! Io lavoro su fedora e li, se non sbaglio, danno un layer di compatibilità per poter eseguire comunque i servizi in /etc/init.d, anche se quelli delle applicazioni impacchettate da loro usano il nuovo sistema.
    Cmq per quando rimuoveranno questo supporto, ora so cosa fare!
    It is common knowledge that old school hackers all have large beards. Alan Cox,RMS and maddog are brilliant examples. The reason for this is that growing a beard is the most interesting use of one's time when the computer is waiting for fsck to finish messing around after a system crash, and on large filesystems, you'll have plenty of time to waste (this might also be why there are so few female hackers; they can't grow beards).

  3. #3
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    44
    Messaggi
    23,415
    configurazione

    Predefinito

    Grazie!
    Anche su Arch c'è, per completare la transizione. Ma dovendo reinstallare per il cambio hardware ho preferito fare direttamente un'implementazione "full-systemd".


    Ogni volta che vedo il tuo speedtest mi viene sempre male...

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

Informazioni Thread

Users Browsing this Thread

Ci sono attualmente 1 utenti che stanno visualizzando questa discussione. (0 utenti e 1 ospiti)

Tags

Regole d'invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
nexthardware.com - © 2002-2022