Zugriff auf serielle Geräte von virtuellen Maschinen aus

Ja, mit derselben Regel, die für jede gemeinsame Nutzung durch mehrere Clients gilt: Verwenden Sie auf dem Host eine Raw-Serververbindung, die mehrere Client-VMs akzeptiert, und jede VM erhält eine Kopie der Ausgabe des Geräts. Im Modus Telnet (RFC 2217) ist die Verbindung Peer-to-Peer — jeweils nur eine VM —, weil die Remote-Portsteuerung nicht von mehreren Clients gemeinsam genutzt werden kann.

Der Kompromiss ist also Raw (viele VMs, aber keine Remote-Aushandlung von Baudrate/Signalen — den Port auf dem Host einstellen) gegenüber Telnet (eine VM, vollständige Portsteuerung). Und der Hinweis zum Schreiben gilt auch hier: Mehrere VMs können ein Gerät sicher lesen, aber wenn mehrere VMs Befehle an ein einzelnes Befehls-/Antwortgerät senden, werden ihre Bytes auf dem einen physischen Port ineinander verschachtelt. Bestimmen Sie dafür eine steuernde VM oder serialisieren Sie Befehle auf Anwendungsebene.

Beantwortet von Nikolai Svarachevsky · Leitender Entwickler

Ja — das ist im Wesentlichen ein vernetztes Nullmodem zwischen zwei Gastsystemen, und es ist eine saubere Verwendung von SEC. Erstellen Sie in jeder VM einen virtuellen COM-Port und verbinden Sie sie über SEC (eine Seite als Server, die andere als Client, da die beiden Verbindungstypen austauschbar sind). Jedes Programm öffnet seinen lokalen virtuellen COM-Port, als ob ein serielles Kabel zwischen den beiden Maschinen verlaufen würde, und SEC überträgt die Bytes dazwischen über das virtuelle Netzwerk. Es ist keinerlei physische serielle Hardware beteiligt.

Dies ist eine gängige Methode, um zwei Anwendungen zu verbinden, die nur über einen COM-Port kommunizieren können, wenn sie nun in getrennten VMs laufen. Die übliche Empfehlung gilt: Für einen strikten Request/Response-Handshake zwischen ihnen sollte es eine einfache Zwei-Parteien-Verbindung (Peer-to-Peer) bleiben, anstatt zu versuchen, einen gemeinsamen Port auf mehrere Endpunkte zu verteilen, und falls eines der Programme von einem präzisen Timing der Signalleitungen abhängt, testen Sie es — der Netzwerksprung zwischen den Gastsystemen ist keine Leitung mit Null-Latenz.

Beantwortet von Nikolai Svarachevsky · Leitender Entwickler

Die Verbindung wird neu aufgebaut, anstatt sofort fortgesetzt zu werden, und wie schnell das geschieht, liegt weitgehend bei Ihnen: SEC hat ein konfigurierbares Wiederverbindungsintervall, das festlegt, wie oft eine unterbrochene Verbindung erneut versucht wird. Wenn eine VM pausiert oder gespeichert wird, friert das Gastsystem mit einem offenen TCP-Socket ein; beim Fortsetzen ist dieser Socket veraltet, daher trennt SEC ihn und verbindet sich beim nächsten Wiederholungsversuch erneut. Stellen Sie ein kurzes Intervall ein, dann erfolgt die Wiederherstellung schnell — typischerweise innerhalb von Sekunden, nachdem die Netzwerkverbindung im Gastsystem wieder verfügbar ist —, während in diesem kurzen Zeitraum die Anwendung, die den virtuellen COM-Port verwendet, möglicherweise sieht, dass der Port getrennt wird oder einen Fehler meldet, bevor er zurückkehrt.

Zwei praktische Hinweise. SEC war in der Vergangenheit empfindlich gegenüber Suspend/Resume und Windows-Schnellstart, behandeln Sie daher das Fortsetzen des Gastsystems als Wiederverbindungsereignis und stellen Sie sicher, dass Ihre Anwendung eine kurze Portunterbrechung toleriert. Und alle Daten, die ein kontinuierlich streamendes Gerät ausgegeben hat, während die VM pausiert war, werden nicht für eine spätere Zustellung gepuffert — sie sind verloren —, weil SEC live weiterleitet; es speichert nicht und spielt nichts erneut ab.

Beantwortet von Bohdan Miniv · QA Engineering

Neben der standardmäßigen Einzellizenz bietet SEC eine spezielle Einzellizenz für virtuelle Maschinen. Sie existiert, weil im VM-Szenario SEC-Endpunkte innerhalb von Gastinstanzen ausgeführt werden, und die VM-Lizenz deckt dieses Nutzungsmodell ab statt einer einzelnen physischen Installation. Wenn Sie SEC in virtuellen Maschinen bereitstellen, ist dies der Lizenztyp, an dem Sie Ihren Kauf bemessen sollten.

Da sich Lizenzbedingungen und der genaue Umfang ändern können und davon abhängen, wie viele VM-Endpunkte Sie betreiben, bestätigen Sie die aktuellen Details auf der Preisseite oder mit dem Vertriebsteam, bevor Sie in größerem Umfang kaufen — so wird sichergestellt, dass Sie die richtige Lizenz für Ihre Bereitstellung erhalten, anstatt später eine Abweichung festzustellen.

Beantwortet von Bohdan Miniv · QA Engineering

Das ist erwartetes Verhalten, kein Fehler. Wenn die Option Als virtuellen Port erstellen aktiviert ist, werden die Standardeinstellungen des Ports absichtlich ausgegraut: Bei einem virtuellen Port werden die Parameter (Baudrate, Parität, Daten-/Stoppbits) von der Anwendung festgelegt, die den Port öffnet, und nicht fest in SEC. Die Anwendung fordert beim Verbinden den gewünschten Modus an, und der virtuelle Port übernimmt ihn.

Dies ist das richtige Modell für einen virtuellen Port, da die Einstellungen eines echten seriellen Geräts nur am physischen Ende relevant sind. Wenn Sie eine Verbindung zu einem echten Port herstellen und dessen Parameter festlegen möchten, konfigurieren Sie sie auf der Seite des echten Ports; die virtuelle Seite folgt der Anwendung. Wenn Sie erwartet haben, die Rate des virtuellen Ports unabhängig von der Anwendung fest einzustellen, ist das einfach nicht die Funktionsweise virtueller Ports — und es zu erzwingen würde nicht helfen, da der von der Anwendung angeforderte Modus die Sitzung tatsächlich bestimmt.

Beantwortet von Nikolai Svarachevsky · Leitender Entwickler