Virtualization Station und QuTScloud

[tiermutter]

Stand dies nicht schon in Post #20 oder so und ein paar anderen, dass dieser Haken erforderlich ist?

Irgendwo stand es ganz im Gegenteil drin. Das war uA ein Auszug von mir, den ich vom Support bekommen habe. Das Ding war zweideutig, Screenshot (vom Support) und deren Aussage stimmten nicht überein, die Aussage lautete aber ganz klar: HTTPS darf nicht erzwungen werden, da die VM sonst nicht erkennt, dass sie in der VS läuft.

Das ist genau das Gegenteil von dem was @rednag nun erfahren hat.....

Edit
Oh gar nicht, hier wird ja noch nicht erzwungen sondern lediglich HTTPS ermöglicht.

 

[rednag]

Richtig. Wichtig ist nach meiner Erkenntnis nur ob es auf dem Host aktiviert ist.
Wie man sich letztendlich bei dem Host oder VM anmeldet spielt keine Geige.
Schaltet man die "Sichere Verbindung" aus, verliert die VM auch ihre Lizenz.
Wobei ich den Zusammenhang grad nicht verstehe. Aber den Spiel hab ich zwei mal durchprobiert. An Zufal will ich hier nicht mehr glauben.

 

[Mavalok2]

Vermutlich läuft die Verifizierung, dass der Host ein QNAP-NAS ist über eben jene HTTPS Schnittstelle. Die Lizenz selbst dann aber über das Internet, vermutlich ebenso HTTPS. Ich glaube, der Haken für HTTPS ist standardmässig drinnen. Bin mir nicht bewusst, ob ich da was umgestellt habe, im Zuge von VS / QuTSCloud auf jeden Fall ganz sicher nicht.

 

[Mavalok2]

Habe nur mal schnell gesucht:

Post #219

Es geht um den Port auf dem NAS, nicht der VM.
Aber nach dem filesystem check und einem shutdown/boot war das Volume wieder ok, also read-write.
Aber es stimmt schon, irgendwie kommt einem das vor, wie mit der heißen Nadel gestrickt.

Gruss

Edit: Letzter Stand: Nur den https-Port auf non-default gesetzt, VM gebootet, keine Lizenz! Während die VM läuft den Port auf default (443) gesetzt, nach einer kleiner Weile ist die VM einsatzbereit (ohne Neustart). Es scheint also doch mit den Porteinstellungen zu tun haben.

Post #209

Ich bin auch einen Schritt weiter...
Nachdem mir der Support einige Screenshots mit seinen Einstellungen gesendet hat, habe ich folgendes gemacht:
Alle bisherigen VMs gelöscht, dann den http und https Port auf Standard (8080/443) geändert und bin soeben am installieren der VM aus dem Marketplace, es wurde keine Lizenz abgefragt!

Ob das mit den Ports zusammenhängt muss ich noch klären. Und auch im License Center ist bei mir keine Lizenz zu sehen, im Screenshot vom Support aber schon.

Gruss

Post #185
Von @tiermutter das sieht man im Screenshot, dass her Haken drinnen ist.

Also, das Thema hatten wir schon. Kam da nur noch nicht so eindeutig raus.

 

[rednag]

Ich bin da eher durch Zufall draufgekommen. Prinzipiell wird bei mir rigoros alles deaktiviert was ich nicht brauche/nutze. So auch die "Sichere Verbindung". Wenn man das NAS auf Werkseinstellung setzt, ist der Haken standardmäßig aktiviert. Sobald man das Deaktiviert wird der Key verlangt.

 

[Barungar]

Ich denke ich habe des Pudels Kern gefunden.
Auf dem Hostsystem muß in den Systemeinstellungen "Sichere Verbindung aktivieren" aktiviert sein.
Wie man sich im Endeffekt dann anmeldet spielt keine Rolle. Ohne verlangt VM einen Key, aktiviert läuft das Setup durch.
Hab das ganze jetzt 2x durchprobiert.

Anhang anzeigen 679

Vielleicht kann das zur Bestätigung jemand nachstellen.

Ich kann es widerlegen... mit den folgenden Einstellungen will die VM eine Lizenz und mag sich nicht mucken.

 

[tiermutter]

Das spricht nun wirklich gegen die Aussage des Supports. Also: das Rätsel ist längst nicht gelöst

 

[Barungar]

Keine Ahnung, ob ihn TLS 1.3 als Mindestversion stört oder die starken Ciphers?
Vielleicht auch Port 8193? Oder das erzwingen einer https-Verbindung?!
Vielleicht ist es aber auch mein Zertifikat, das ich auf das QNAP geladen habe.
Wer weiß das schon...

 

[blurrrr]

Gibt denn evtl. "dmidecode" irgendwas in Richtung QNAP aus (auf der VM)? Irgendwoher muss die VM ja wissen, dass sie über eine VS betrieben wird (QEMU/KVM allein wird da nicht reichen). Vielleicht könnt ihr auch mal schauen, ob es irgendwo eine Config der VM auf dem Hostsystem gibt (muss es ja theoretisch), ggf. wird da noch etwas mit übergeben. Woher soll die VM sonst wissen, dass sie auf einer VS läuft? Also irgendwo "muss" es da schon eine konkrete Information geben...

 

[Mavalok2]

Wo stand, das sichere Verbindung nicht erzwungen werden darf? Irgendwer hat dies gepostet. HTTPS ja, aber Erzwingen nein.

 

[tiermutter]

Wo stand, das sichere Verbindung nicht erzwungen werden darf?

In meinem Ticket und in dem von @swlde bei dem das anschließend auch funktionierte.

das "don't" habe ich markiert und mit dem Pfeil aufgezeigt, dass dies auch an der Stelle nochmal eingesetzt werden muss, damit die Aussage zu dem nachfolgenden Screenshot passt, der der Anrwort vom Support angehangen war:


Bedeutet für mich unterm Strich, dass HTTP zwingend erforderlich ist und HTTPS demnach keinesfalls erzwungen werden darf.

Alles darüber hinaus (Anmelden mit HTTP statt /s etc.) waren Mutmaßungen und Spekulationen, die auch entsprechend deklariert waren.
Irgendwie ist hier ja fast alles Spekulation, außer der Gewissheit die wir mittlerweile haben, dass wirklich eine Internetverbindung erforderlich ist, die der Support zB nie erwähnt hat. Entsprechend hat das Ticket ie folgt geendet:



Die ansonsten genannten DInge waren "als admin anmelden", "Remotesitzung" und "Firmwareupdate" (obwohl mehrfach explizit bestätigt wurde, dass es mir meiner 4.5.3 möglih ist).

 

[Mavalok2]

Könnte es sein, dass beim Screenshot die Markierung verrutscht ist? Http Kompression, ich weiß ja nicht, glaube nicht dass es daran liegen kann.
Also die Einstellungen wie bei Screenshot, zusätzlich Internetverbindung und dann sollte es funktionieren.

 

[blurrrr]

Ich muss jetzt aber schon mal etwas blöde fragen: Was bitte soll die http/https-Einstellung innerhalb der VM mit einer Lizenz zu tun haben? Marketplace-VM mag das vllt noch alles "irgendwie" gedreht sein, zieht man sich ein anderweitiges (QuTSCloud-)Cloud-Image und import jenes einfach, wird der Host auch nicht einfach eigenständig hingehen und irgendwas via http/https an der VM ansprechen. Alternativ wäre es schon ein ziemlicher Klopper, wenn da von innen nach aussen erstmal irgendeine Verbindung geöffnet wird, damit die VM von aussen angesprochen werden kann (was ich auch nicht glaube, da die reguläre Lizenzabfrage (bei gekauften Lizenzen) entweder a) online via license.qnap.com, oder b) offline (via DIF) abläuft).

Die eigentliche Frage (daher auch die Sache bzgl. "dmidecode", vllt hat man da ja rumgefummelt) ist ja eher: Woher weiss die VM, dass sie unter VS betrieben wird (und somit keine Lizenz benötigt wird)? Eine "richtige" Lizenz wird ja auch nicht angezeigt, sondern nur ein "--", von daher geht die Vermutung eher in Richtung "lokaler Check" á la "Worauf laufe ich eigentlich?"... wäre zumindestens meine Vermutung.

Vielleicht sollte man die SSL-Verbindung doch mal aufbrechen und genauer hinschauen... irgendwas ist ja wohl faul im Staate Dänemark Wenn sich da dann nix finden lässt, muss es ja etwas lokales sein. Ansonsten könnte man nochmal mit dem "qlicense_tool" schauen, aber das scheint mir nur für die Verarbeitung von "gekauften" Dingen zu sein.

 

[tiermutter]

Könnte es sein, dass beim Screenshot die Markierung verrutscht ist? Http Kompression

Das ist so verrückt alles... jetzt wo ich es lese war der erste Gedanke "ich sag ja, dass die Kompression weit hergeholt ist". Habe ich das gesagt? Keine Ahnung. Erst jetzt merke ich selbst erst wieder, dass es im Screenshot um die Kompression geht! Wald und Bäume, echt! Das muss wirklich verrutscht sein!

Was bitte soll die http/https-Einstellung innerhalb der VM mit einer Lizenz zu tun haben?

Es geht hier um das Hostsystem....

Woher weiss die VM, dass sie unter VS betrieben wird

... damit genau das klappt.

Was meinst Du mit dmidecode zu erreichen? Was soll man da sehen? Bin doch Mausschubser...

 

[blurrrr]

Es geht hier um das Hostsystem....

Okay, aber was hat eine VM mit dem Zugriff auf ein Hostsystem zu tun? Woher soll die VM überhaupt wissen, welche IP das Hostsystem hat? Greift die VM auf das Hostsystem zu? Wie läuft es dann mit anderweitigen Cloudimages, die ja "anscheinend" auch funktionieren (mit kostenloser Lizenz)? Geht man dann hin und versucht die AWS-Hypervisor zu erreichen? Ich sag mal... "Hm!".

dmidecode gibt Hardware-Infos raus. Im Falle der Virtualisierung kann sowas z.B. so aussehen:

dmidecode | grep -i -e manufacturer -e product -e vendor

Damit werden Filter auf manufacturer, product und vendor gesetzt. Das Ergebnis sieht dann unter QEMU z.B. so aus:

Vendor: SeaBIOS
Manufacturer: QEMU
Product Name: Standard PC (i440FX + PIIX, 1996)
Manufacturer: QEMU
Manufacturer: QEMU
Manufacturer: QEMU

Ist halt einfach nur die Frage, ob QNAP da ggf. etwas an der Ausgabe geändert hat (so dass die VM bei einem Check ("Worauf laufe ich?") irgendwo ein QNAP, VS, o.ä. findet). Keine Ahnung, war jetzt auch nur so ein Schuss ins blaue hinein, aber es ist ja allseits bekannt, dass die NAS-Hersteller gerne alles umfummeln bis der Arzt kommt

Ist aber auch nur so eine Idee, kann alles, muss nix (und so)

 

[tiermutter]

erzähl mir nicht so viel... ein einfaches "mach mal" hätte gereicht

[~] # dmidecode | grep -i -e manufacturer -e product -e vendor
        Vendor: Not Specified
        Manufacturer: QEMU
        Product Name: Standard PC (i440FX + PIIX, 1996)
        Manufacturer: QEMU
        Product Name: Standard PC (i440FX + PIIX, 1996)
        Manufacturer: QEMU
        Manufacturer: QEMU
        Manufacturer: QEMU

 

[blurrrr]

Vielleicht mal ohne die ganzen Filter und durchschauen, vllt lässt sich ja irgendwas bzgl. QNAP / VS finden, oder für einen anderen schnellen Test:

dmidecode | grep -i -e qnap -e virtualization -e vs

Keine Ahnung, auch nur eine dumme Vermutung, aber macht in meinen Augen irgendwo schon Sinn (also etwas in diese Richtung), da es ja heisst, dass man auf QNAP-Geräten bzw. unter Nutzung der "VS" keine Lizenz braucht. @tiermutter Du hattest doch auch mal ein anderes OS auf einer QNAP installiert. Da liesse sich bestimmt auch QEMU installieren, ggf. testet man es mal einfach so (dann wäre es zwar ein QNAP-Gerät, aber eben keine VS)... irgendwo muss der Hase ja im Pfeffer liegen...

EDIT: Auch wenn das etwas lahm wäre... ihr könnt ja mal die MAC-Adressen eurer QuTScloud-VMs vergleichen.

 

[tiermutter]

irgendwo muss der Hase ja im Pfeffer liegen...

Es fängt da an, dass ich gar nicht verstehe was Du von mir willst

Vielleicht mal ohne die ganzen Filter und durchschauen

Habe die VM just zur Sekunde heruntergefahren, weil Du offline warst und ich die CPU grad anderweitig brauche... dachte Du bist im Bett, nachdem Du bestimmt schon frühzeitig für einen normalen IT-Arbeitstag um 0900 aufgestanden bist Fahre die VM nochmal hoch und prüfe...

Du hattest doch auch mal ein anderes OS auf einer QNAP installiert.

Jo, aber auf einem "PC" ein OS zu installieren ist auch kein Hexenwerk Verrate mir nur, in einfach für Schwiegermütter (das wollen wir hier doh ) was ich zu tun habe und warum

 

[tiermutter]

dmidecode | grep -i -e qnap -e virtualization -e vs
bringt keine Ausgabe.

 

[blurrrr]

Es fängt da an, dass ich gar nicht verstehe was Du von mir willst

Es geht darum, dass die VM irgendwoher "weiss", dass sie unter der VirtualizationStation betrieben wird und daher auch keine Lizenz einfordert. Alternativ (daher auch die Sache mit der VM-Config) kann es natürlich sein, dass irgendwas an Identifier in die VM eingebunden wird und diese so feststellen kann, dass sie unter der VirtualizationStation ausgeführt wird. Alternativ dazu eben "nur" die Frage, ob die VM auf einem QNAP-Gerät ausgeführt wird (daher auch die Sache mit dem alternativen OS samt QEMU auf einer QNAP).

Packt man einfach nur "irgendein" Image drauf (mal abgesehen von Marketplace-Image), weiss das Image ja nicht, worunter es ausgeführt wird. Daher wundert es mich auch ein wenig, dass hier berichtet wird, dass auch mit "anderen" Images keine Lizenzabfrage kommt. Das Marketplace-Image mag noch entsprechend modifiziert sein, die regulären Cloud-Images (Hyper-V, ESX, etc.) dürften es hingegen nicht sein (und sollten auf den Online-/Offline-Check begrenzt sein).

bringt keine Ausgabe.

Dann halt einfach nur dmidecode und dort ggf. nach Auffälligkeiten schauen... kann aber auch sein, dass da nix zu finden ist, wie gesagt, ist auch nur eine Vermutung (und die machen ja bekanntlich immer recht viel Arbeit)