Accesso ai dispositivi seriali dalle macchine virtuali

Sì, con la stessa regola che governa qualsiasi condivisione multi-client: usa una connessione server Raw sull'host, che accetta più VM client, e ogni VM riceve una copia dell'output del dispositivo. In modalità Telnet (RFC 2217) la connessione è peer-to-peer — una VM alla volta — perché il controllo remoto della porta non può essere condiviso tra client.

Quindi il compromesso è Raw (molte VM, ma nessuna negoziazione remota di baud/segnali — imposta la porta sull'host) rispetto a Telnet (una VM, controllo completo della porta). E anche qui vale l'avvertenza sulla scrittura: più VM possono leggere in sicurezza da un dispositivo, ma se più VM inviano comandi a un singolo dispositivo a comandi/risposte, i loro byte si intercaleranno sull'unica porta fisica. Per questo, designa una VM di controllo oppure serializza i comandi a livello di applicazione.

Risposta di Nikolai Svarachevsky · Lead Developer

Sì — questo è di fatto un null-modem di rete tra due guest, ed è un uso pulito di SEC. Crea una porta COM virtuale in ciascuna VM e collegale tramite SEC (un lato come server, l'altro come client, poiché i due tipi di connessione sono intercambiabili). Ogni programma apre la propria porta COM virtuale locale come se un cavo seriale passasse tra le due macchine, e SEC trasporta i byte attraverso la rete virtuale intermedia. Non è coinvolto alcun hardware seriale fisico.

Questo è un modo comune per collegare due applicazioni che sanno comunicare solo tramite una porta COM quando ora si trovano in VM separate. Si applicano le consuete indicazioni: per un rigoroso handshake richiesta/risposta tra loro, mantieni un semplice collegamento a due parti (peer-to-peer) invece di cercare di distribuire una porta condivisa a più endpoint e, se uno dei due programmi dipende da una temporizzazione stretta delle linee di segnale, mettilo alla prova — il salto di rete tra i guest non è un collegamento a latenza zero.

Risposta di Nikolai Svarachevsky · Lead Developer

La connessione viene ristabilita anziché riprendere istantaneamente, e la velocità dipende in gran parte da te: SEC ha un intervallo di riconnessione configurabile che determina con quale frequenza ritenta una connessione interrotta. Quando una VM viene messa in pausa o salvata, il guest si blocca con un socket TCP aperto; alla ripresa quel socket è obsoleto, quindi SEC lo chiude e si riconnette al tentativo successivo. Imposta un intervallo breve e il ripristino sarà rapido — in genere entro pochi secondi dal ritorno della connettività di rete nel guest — mentre durante quella breve finestra l'applicazione che mantiene la porta COM virtuale potrebbe vedere la porta disconnettersi o andare in errore prima che torni disponibile.

Due note pratiche. Storicamente SEC è stato sensibile a sospensione/ripresa e a Windows Fast Startup, quindi considera la ripresa del guest come un evento di riconnessione e assicurati che la tua applicazione tolleri una breve interruzione della porta. Inoltre, tutti i dati emessi da un dispositivo a flusso continuo mentre la VM era in pausa non vengono memorizzati per una consegna successiva — sono persi — perché SEC inoltra in tempo reale, non archivia e riproduce.

Risposta di Bohdan Miniv · QA Engineering

Oltre alla licenza singola standard, SEC offre una Licenza Singola dedicata per Macchina Virtuale. Esiste perché lo scenario VM prevede endpoint SEC in esecuzione all'interno di istanze guest, e la licenza VM copre quel modello di utilizzo anziché una singola installazione fisica. Se stai distribuendo SEC in macchine virtuali, questo è il tipo di licenza in base al quale dimensionare il tuo acquisto.

Poiché i termini di licenza e la copertura esatta possono cambiare e dipendono da quanti endpoint VM stai eseguendo, conferma i dettagli attuali nella pagina dei prezzi o con il team commerciale prima di acquistare su larga scala — in questo modo avrai la licenza giusta per la tua distribuzione invece di scoprire in seguito un'incompatibilità.

Risposta di Bohdan Miniv · QA Engineering

Questo è il comportamento previsto, non un bug. Quando l'opzione Create as virtual port è selezionata, le impostazioni predefinite della porta vengono disattivate apposta: per una porta virtuale, i parametri (baud rate, parità, bit di dati/stop) sono definiti dall'applicazione che apre la porta, non fissati in SEC. L'applicazione richiede la modalità desiderata quando si connette, e la porta virtuale la adotta.

Questo è il modello corretto per una porta virtuale perché le impostazioni di un vero dispositivo seriale contano solo all'estremità fisica. Se stai creando un bridge verso una porta reale e vuoi fissarne i parametri, configurali sul lato della porta reale; il lato virtuale segue l'applicazione. Se ti aspettavi di impostare in modo permanente la velocità della porta virtuale indipendentemente dall'app, semplicemente non è così che funzionano le porte virtuali — e forzarlo non aiuterebbe, poiché è la modalità richiesta dall'app a governare effettivamente la sessione.

Risposta di Nikolai Svarachevsky · Lead Developer