Unterschied Hardware-Server zu VM für Client
Hallo zusammen,
ich hab da mal eine Frage an euch, ob ihr euch darauf einen Reim machen könnt.
Ich habe einen Kunden für den ich seinen Techniker unterstütze/im Urlaubsfall vertrete usw. Geht da eher um Drucker, bisschen PC - jedenfalls hab ich i.d.R. nichts mit deren Server oder so zu tun. Der wird von der Firma gestellt und betreut, die auch das Warenwirtschaftssystem bereit stellt.
Ich hatte allerdings doch schon mehrmals mit dem Teil zu tun, weil diese externe Firma ... sagen wir ... nicht die schnellsten sind. Der alte Server hat das WWS und ist der DC. Fileserver ist ein uraltes NAS, Printserver gibts nicht (ca. 30 Mitarbeiter, alle Drucker lokal installiert, wie auch Virenscanner etc.).
Jetzt kam ein neuer Server und ich hatte angeregt, dass man das Warenwirtschaftssystem doch auf eine VM installieren könnte. So könnte man eine zweite VM einrichten, die das NAS als Fileserver ablösen könnte und könnte auch noch einen Printserver installieren. Zu dem WWS darf jedenfalls nix dazu - außer DC (was ja auch nicht optimal ist, aber wenn es eben nur einen Server gibt).
Der Server wurde letzte Woche in Betrieb genommen. Sie haben den aber von der VM runter direkt auf die Hardware machen müssen. Begründung: Die Kassenschublade konnte von der VM nicht angesteuert werden. Nachdem es von der VM aufs Blech umgezogen worden wäre, hätte es sofort geklappt.
Am Server steckt kein Dongle oder so drin. Der hat nur die üblichen Verbindungen (LAN, Tastatur, Maus, Bildschirm)
Die Kasse ist ein PC an dem so eine Kassenschublade angeschlossen ist. Dort läuft ebenfalls das WWS und wenn ein Bezahlvorgang beendet wird, öffnet das Teil dann die Kassenschublade. Und es wäre nicht möglich gewesen, dass der PC diese Schublade öffnet, so lange der Server als VM lief.
Mir fällt nichts ein, was der Unterschied zu einer VM sein könnte, dass der Kassenrechner die Schublade nicht ansteuern konnte.
Habt ihr eine Idee?
Der Bär ist gelutscht, das ist jetzt so. Auch nicht mein Problem, aber würde mich trotzdem interessieren. Wäre klar, wenn diese Schublade irgendwie direkt mit dem Server verbunden wäre. Oder ein Dongle drin stecken würde, der sozusagen die Authorisierung ist. Ist aber nicht so. Es gibt einen TSE-Dongle, aber der steckt im PC. Das WWS schickt vom Server via LAN einen Befehl an den Kassen-PC "Schublade öffnen" und der PC schickt über seine lokale Schnittstelle (keine Ahnung welche) den Befehl an die Schublade und die springt dann auf.
ich hab da mal eine Frage an euch, ob ihr euch darauf einen Reim machen könnt.
Ich habe einen Kunden für den ich seinen Techniker unterstütze/im Urlaubsfall vertrete usw. Geht da eher um Drucker, bisschen PC - jedenfalls hab ich i.d.R. nichts mit deren Server oder so zu tun. Der wird von der Firma gestellt und betreut, die auch das Warenwirtschaftssystem bereit stellt.
Ich hatte allerdings doch schon mehrmals mit dem Teil zu tun, weil diese externe Firma ... sagen wir ... nicht die schnellsten sind. Der alte Server hat das WWS und ist der DC. Fileserver ist ein uraltes NAS, Printserver gibts nicht (ca. 30 Mitarbeiter, alle Drucker lokal installiert, wie auch Virenscanner etc.).
Jetzt kam ein neuer Server und ich hatte angeregt, dass man das Warenwirtschaftssystem doch auf eine VM installieren könnte. So könnte man eine zweite VM einrichten, die das NAS als Fileserver ablösen könnte und könnte auch noch einen Printserver installieren. Zu dem WWS darf jedenfalls nix dazu - außer DC (was ja auch nicht optimal ist, aber wenn es eben nur einen Server gibt).
Der Server wurde letzte Woche in Betrieb genommen. Sie haben den aber von der VM runter direkt auf die Hardware machen müssen. Begründung: Die Kassenschublade konnte von der VM nicht angesteuert werden. Nachdem es von der VM aufs Blech umgezogen worden wäre, hätte es sofort geklappt.
Am Server steckt kein Dongle oder so drin. Der hat nur die üblichen Verbindungen (LAN, Tastatur, Maus, Bildschirm)
Die Kasse ist ein PC an dem so eine Kassenschublade angeschlossen ist. Dort läuft ebenfalls das WWS und wenn ein Bezahlvorgang beendet wird, öffnet das Teil dann die Kassenschublade. Und es wäre nicht möglich gewesen, dass der PC diese Schublade öffnet, so lange der Server als VM lief.
Mir fällt nichts ein, was der Unterschied zu einer VM sein könnte, dass der Kassenrechner die Schublade nicht ansteuern konnte.
Habt ihr eine Idee?
Der Bär ist gelutscht, das ist jetzt so. Auch nicht mein Problem, aber würde mich trotzdem interessieren. Wäre klar, wenn diese Schublade irgendwie direkt mit dem Server verbunden wäre. Oder ein Dongle drin stecken würde, der sozusagen die Authorisierung ist. Ist aber nicht so. Es gibt einen TSE-Dongle, aber der steckt im PC. Das WWS schickt vom Server via LAN einen Befehl an den Kassen-PC "Schublade öffnen" und der PC schickt über seine lokale Schnittstelle (keine Ahnung welche) den Befehl an die Schublade und die springt dann auf.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 672194
Url: https://administrator.de/forum/unterschied-hardware-server-zu-vm-fuer-client-672194.html
Ausgedruckt am: 30.03.2025 um 15:03 Uhr
15 Kommentare
Neuester Kommentar
Das was @godlie sagt. Wenn die KassenHW nicht direkt mit dem Server verbunden ist, was soll die HW-Schicht der WaWi Servers damit zu tun haben? Mir fällt nichts ein
Ich denke auch dass die da keine Lust drauf hatten und auch kein Know How...
Evtl. mal die WaWi überdenken...
Ich kenne einen Anbieter (geht aber eher in die Gastro / Hotel Richtung) da geht das auch. Ich kenne auch den Dienstleister persönlich und weiß dass er nur noch mit VM's arbeitet, von daher läuft das. Auch TSE konform...
Gruß
Evtl. mal die WaWi überdenken...
Ich kenne einen Anbieter (geht aber eher in die Gastro / Hotel Richtung) da geht das auch. Ich kenne auch den Dienstleister persönlich und weiß dass er nur noch mit VM's arbeitet, von daher läuft das. Auch TSE konform...
Gruß
Moin,
was für ein HyperVisor war zuvor installiert? Wie wird die Schublade angebunden? via COM-Port? USB? LAN?
Wenn bspw. HyperV installiert war, kann man bspw. kein USB durchreichen - da wäre also was Wahres dran. Gibt aber auch dafür Lösung wie bspw. einen UTN.
IdR. sagt der KassenPC: "Vorgang abgeschlossen, bitte Schublade öffnen" - nicht der Server.
Andererseits: Wenn die Anbieter sagen: keine VM, dann keine VM. Weil wenn VM, dann u.U. kein Support mehr - auch blöd.
Gruß
Mir fällt nichts ein, was der Unterschied zu einer VM sein könnte, dass der Kassenrechner die Schublade nicht ansteuern konnte.
was für ein HyperVisor war zuvor installiert? Wie wird die Schublade angebunden? via COM-Port? USB? LAN?
Wenn bspw. HyperV installiert war, kann man bspw. kein USB durchreichen - da wäre also was Wahres dran. Gibt aber auch dafür Lösung wie bspw. einen UTN.
IdR. sagt der KassenPC: "Vorgang abgeschlossen, bitte Schublade öffnen" - nicht der Server.
Ich vermute mal die Wollen keine VM, oder es fehlt ihnen am KnowHow
Vermutlich wurde der Server über die bezogen(?) - dann möchte man natürlich nicht, dass man Geld spart weil man weitere VMs aufsetzen könnte.Andererseits: Wenn die Anbieter sagen: keine VM, dann keine VM. Weil wenn VM, dann u.U. kein Support mehr - auch blöd.
Gruß
So wie ich das verstehe, hängt die Kassen-Hardware komplett am Client, der nur über Netzwerk mit dem Server spricht. Dann ist es eigentlich egal, ob der Server eine VM oder ein OS auf Blech als Unterbau hat. Auch kann das eigentlich kein Bug sein, der zufällig in der Konstellation auftritt. Einzig wenn der Entwickler will, das die Software sich anders verhält, wenn sie in einer VM läuft, dann wäre vieles denkbar. Wenn z.B. irgend ein kruder Kopierschutz, eine Sicherheitsmaßnahme, oder etwas anderes dafür sorgen soll, das VMs bewusst nicht gehen. Vielleicht war jemand bei der Entwicklung der Meinung, das eine Kasse nicht auf eine VM darf, weil...
...das nicht GoBD-konform ist (ich wüsste jetzt keinen Grund, warum nicht, aber ist ja nur eine Idee).
...das das in einem anderen Land als DE, in dem das System auch genutzt wird, gegen Regeln für Kassen Soft- und Hardware verstößt.
...wegen der Sichert, denkt doch nur an die Kinder.
...weil der Hersteller auch gern Hardware verkaufen möchte (vermutlich nicht, sonst hätten sie keine AD auf dem selben OS erlaubt - fuibä).
...als Kopierschutz, weil Lizenzen davon abhängen.
...weil der Code uralt ist und irgendwas ganz fies gefrickelt wurde.
...das nicht GoBD-konform ist (ich wüsste jetzt keinen Grund, warum nicht, aber ist ja nur eine Idee).
...das das in einem anderen Land als DE, in dem das System auch genutzt wird, gegen Regeln für Kassen Soft- und Hardware verstößt.
...wegen der Sichert, denkt doch nur an die Kinder.
...weil der Hersteller auch gern Hardware verkaufen möchte (vermutlich nicht, sonst hätten sie keine AD auf dem selben OS erlaubt - fuibä).
...als Kopierschutz, weil Lizenzen davon abhängen.
...weil der Code uralt ist und irgendwas ganz fies gefrickelt wurde.
Sehe es auch so, entweder ist da softwareseitig etwas eingebaut, was bewusst testet und sperrt, oder es ist schlicht eine Behauptung, dass das eine mit dem anderen zusammenhängt, sprich: die Kassenschublade hätte es dann auch mit der VM getan und das Problem mit der Schublade lag woanders (wurde also zufällig mit dem Umzug von VM auf Blech mitgelöst).
Naja - es lässt halt viele Optionen offen ... und hängt auch davon ab was der Hersteller eben will. Ggf. WILL der Hersteller eben auch einfach nicht das es als VM läuft - um zu verhindern das du in X Filialen dieselbe Lizenz nutzt und hat das zB. an ne MAC-Adresse oder andere HW-Identifier gebunden. Und da wäre dann eben das sperren einer Kassenschublade natürlich ein durchaus guter Weg für die Sicherung, eine Kasse deren Schublade nich öffnet is ja vermutlich eher generell sinnfrei.
Am Ende kann dir die Frage eben nur der Hersteller beantworten -> es muss ja nicht zwingend technisch nötig sein, Kopierschutz wäre eine option. Eine andere wäre der Support das der Hersteller keine Lust hat sich damit rumzuschlagen was ggf. aufm Host-System noch so läuft und sich damit rumzuärgern das du irgendeine tolle "perfect security" sw aufm host hast die dann beim Gast-OS alles zerlegt und der das aber eben auch nicht sehen kann.. Oder einfach weil der Hersteller das "Wort" VM nich mag... Am Ende entscheidet nunmal der Hersteller worauf seine SW laufen soll - und der Kunde hat die Wahl das zu akzeptieren oder nen anderes Produkt zu kaufen...
Am Ende kann dir die Frage eben nur der Hersteller beantworten -> es muss ja nicht zwingend technisch nötig sein, Kopierschutz wäre eine option. Eine andere wäre der Support das der Hersteller keine Lust hat sich damit rumzuschlagen was ggf. aufm Host-System noch so läuft und sich damit rumzuärgern das du irgendeine tolle "perfect security" sw aufm host hast die dann beim Gast-OS alles zerlegt und der das aber eben auch nicht sehen kann.. Oder einfach weil der Hersteller das "Wort" VM nich mag... Am Ende entscheidet nunmal der Hersteller worauf seine SW laufen soll - und der Kunde hat die Wahl das zu akzeptieren oder nen anderes Produkt zu kaufen...
Moin @mpanzi,
😯 ... 😵💫 ... 🙊🙈
Ich behaupte jetzt mal ganz frecht, dass das entsprechende auf die WaWi Software spezialisierte Systemhaus, das mit der Hardware besser einem sich auch mit Hardware auskennendem Systemhaus überlassen sollte, bevor es so einen Murks behauptet/baut.
Gruss Alex
Der Server wurde letzte Woche in Betrieb genommen. Sie haben den aber von der VM runter direkt auf die Hardware machen müssen. Begründung: Die Kassenschublade konnte von der VM nicht angesteuert werden. Nachdem es von der VM aufs Blech umgezogen worden wäre, hätte es sofort geklappt.
Am Server steckt kein Dongle oder so drin. Der hat nur die üblichen Verbindungen (LAN, Tastatur, Maus, Bildschirm)
Am Server steckt kein Dongle oder so drin. Der hat nur die üblichen Verbindungen (LAN, Tastatur, Maus, Bildschirm)
😯 ... 😵💫 ... 🙊🙈
Ich behaupte jetzt mal ganz frecht, dass das entsprechende auf die WaWi Software spezialisierte Systemhaus, das mit der Hardware besser einem sich auch mit Hardware auskennendem Systemhaus überlassen sollte, bevor es so einen Murks behauptet/baut.
Gruss Alex