Umgebungseinstellungen für eine Region mit anderen teilen - funktioniert aber nicht!

Ich möchte gern meine Umgebungseinstellungen von unserer Winterland mit anderen Usern auf der Region teilen.

Alle sollen das gleiche an Nebel, Wasser und Tageslicht sehen. Im Einsatz ist bei mir opensim-0.9.2.0.

Im Singu kann ich unter Region/Estate/Envivoment/Fixed sky meine Einstellungen machen und mit Apply abspeichern.

Dies teilt aber nicht meine Einstellungen mit anderen Usern wenn sie "Gemeinsame Umgebung" verwenden.

OSSL ist in der OpenSim ausgelagert nach Include-osslDefaultEnable = "config-include/osslDefaultEnable.ini"

In dieser Konfig sieht es aber gut aus:

[OSSL]
  ; Allow the use of os* functions (some are always available)
  AllowOSFunctions = true

  ; Allow the user of mod* functions.  This allows a script to pass messages
  ;  to a region module via the modSendCommand() function and is used by some
  ;  modules to extend the scripting language.
  AllowMODFunctions = true

  ; Allow the use of LightShare functions.
  ; The setting enable_windlight = true must also be enabled in the [LightShare] section.
  AllowLightShareFunctions = true


Diese ausgelagerte DefaultEnable.ini hat ganz unten am Ende der Datei einen Verweis zu:                           

Include-osslEnable = "config-include/osslEnable.ini"

Dort steht auch alles auf = true

[OSSL]
  ; Allow the use of os* functions (some are always available)
  AllowOSFunctions = true

  ; Allow the user of mod* functions.  This allows a script to pass messages
  ;  to a region module via the modSendCommand() function and is used by some
  ;  modules to extend the scripting language.
  AllowMODFunctions = true

  ; Allow the use of LightShare functions.
  ; The setting enable_windlight = true must also be enabled in the [LightShare] section.
  AllowLightShareFunctions = true

Unter [XEngine] gibt es in dieser Version von OpenSim KEINEN Eintrag zu "AllowLightShareFunctions = true oder false"

logisch, ist ja ausgelagert.


Hat jemand Ahnung woran das liegen kann?

Ankündigung ganz besonders für die, die nirgendwo sonst OpenSim-News beziehen: Am Samstag, dem 10. Dezember und am Sonntag, dem 11. Dezember findet wieder die jährliche OpenSimulator Community Conference statt.

Zunächst einmal: Wer kein Englisch kann, braucht gar nicht erst weiterzulesen. Die ganze Veranstaltung ist 100% auf Englisch ohne Dolmetscher, ohne Untertitel, ohne Synchro.

Was ist also die OSCC, falls man davon noch nie etwas gehört hat? Wie der Name schon sagt, es ist eine Art Konferenz oder Kongreß. Da gibt es Veranstaltungen verschiedener Art vor Publikum, etwa Präsentationen zu Themen, die OpenSim betreffen, Projektvorstellungen oder Podiumsdiskussionen. Die Veranstaltungen laufen an beiden Tagen von 16 Uhr nachmittags bis 4 Uhr nachts; hier darf man nicht vergessen, daß ein Publikum von halb rund um den Globus angesprochen wird, und wenn es hier 4 Uhr nachts ist, ist es an der US-Westküste 19 Uhr abends.

Am Freitag, dem 9. Dezember ab 21 Uhr (wenn praktisch keiner von uns kann) gibt's vorher drei Stunden Musik von DJs, am Sonntag noch einmal ab 3 Uhr nachts und am Montag ab 3.35 Uhr.

Dieses Jahr mit dabei ist übrigens auch eine zweistündige HG-Safari unter der Leitung von Thirza Ember. Wohin es geht, hat sie noch nicht verraten.

Den genauen Zeitplan findet ihr hier.

Hinter der OSCC steckt AvaCon, eine, wenn ich das richtig gesehen habe, gemeinnützige Organisation, die sich auf vielfache Weise im Metaversum und ganz speziell in OpenSim betätigt, etwa in den Bereichen Bildung, Wissenschaft und Kultur. AvaCon hat ein eigenes Grid, in dem man passenderweise auf einer Adaption von Nebadon Izumis legendärem Universal Campus landet. Möglicherweise gibt's dort dieses Jahr wieder eine Weihnachtsfeier nach der OSCC; die läuft aber immer dienstags von Mitternacht bis 2 Uhr nachts.


Die OSCC findet wiederum auf ihrem eigenen Grid statt. Da gibt es:

• vier baugleiche Keynote-Sims für Präsentationen etc., eins, zwei, drei, vier; normalerweise wird nur eine gebraucht
  
• fünf Expo Zones mit Ausstellungen, von denen man hier und da auch etwas mitnehmen kann, eins, zwei, drei, vier (hier bekommt man Sachen von Kayaker Magic, z. B. die extrem ressourcensparende AO-Steuerung khAOs), fünf (hier bekommt man exklusive Layer-Kleidung von Beth Ghostraven)
  
• die Shopping Zone, wo man vor allem klassische Layer-Kleidung von Linda Kellie und aus dem FleepGrid sowie einige klassische Komplettavatare (auch als Teileträger) bekommt, aber auch eine kleine Auswahl an Ruth2-v4- und Roth2-v2-Boxen
  
• eine Sandbox, falls man mal schnell etwas auspacken oder bauen will
  
• die Music Stage für Musikveranstaltungen
  
• das Surreal Museum für Kunst aus dem Hypergrid
  

Heute zum erstenmal auf unserem brandneuen Grid Offworld .. in der ebenso brandneuen Rock Bude 
2-3 Std Rock Musik vom feinsten .. wir freuen uns auf euch !! 

offworld.eu:8002:Rock Bude

1) Device ermitteln:
Nach dem Ausführen des folgenden Befehls den Stick einstecken. Die Ausgaben enthalten das Device z.B. /dev/sdb.
Danach mit der Tastenkombination Strg+C dmesg beenden.

Teil1: https://service-silberwelten.de/showthread.php?tid=441
Teil2: https://service-silberwelten.de/showthread.php?tid=442
Teil3: https://service-silberwelten.de/showthread.php?tid=443


1 Dateiformate

Es gibt 2 Dateiformate für die virtuellen Maschinen.

qcow2 - Datei deren Größe langsam mit der VM mitwächst.
img - Das RAW-Image belegt sofort den gesamten zugewiesenen Festplattenspeicher

Leider gibt es beim Erstellen einer qcow2-VM ein inkonsistentes Verhalten. Ich hoffe, daß das noch gepatcht wird. Die neuerstellte VM belegt als qcow2 Datei auch sofort den gesamten zugewiesenen Festplattenspeicher. Man sollte diese Datei als erstes auf den bereits belegten Platz schrumpfen, danach wächst die Datei dann langsam mit der Größe der VM. Das passiert mit dem folgenden Befehl:

Teil1: https://service-silberwelten.de/showthread.php?tid=441
Teil2: https://service-silberwelten.de/showthread.php?tid=442
Teil3: https://service-silberwelten.de/showthread.php?tid=443
(Siehe Ergänzung am Ende)

Quelle: https://linuxconfig.org/how-to-use-bridg...rt-and-kvm

Voraussetzung für die folgende Konfiguration ist, das Eurer Rechner über 2 Netzwerkschnittstellen verfügt.
Eure eigentliche Netzwerkschnittstelle solltet ihr nicht mit einer Bridge verbinden, da diese dann ihre IP verliert.
Die Bridge br0 sollte an eine eigene zweite Netzwerkschnittstelle gebunden werden.

Das Ergebnis sollte jedenfalls sein, dass die VMs innerhalb Eures Netzwerkes von anderen Rechnern aus zu erreichen sind.
Wollt ihr das die VM mit dem Opensim-Grid aus dem Internet erreichbar ist, müßt Ihr noch die entsprechenden Ports in Eurer Firewall freigeben (eigenes Thema ;-) ).

The “default” network

1) Check the default NAT network:
$ sudo virsh net-list --all

Name      State    Autostart  Persistent
--------------------------------------------
default  active  yes        yes

2) Check the default network definition:
$ sudo virsh net-edit default

<network>
  <name>default</name>
  <uuid>xxxxxxxxxxxxxxxxxxxx</uuid>
  <forward mode='nat'>
    <nat>
      <port start='1024' end='65535'/>
    </nat>
  </forward>
  <bridge name='virbr0' stp='on' delay='0'/>
  <mac address='xxxxxxxxxxxx'/>
  <ip address='192.168.xxx.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.xxx.2' end='192.168.xxx.254'/>
    </dhcp>
  </ip>
</network>

3) Check the bridge device:
$ ip link show type bridge

4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff

4) Show the interfaces which are part of the bridge:
$ ip link show master virbr0

11: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr0 state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff


Use bridged networking for virtual machines

1) Create a new bridge br0:
With the network manager. (ToDo)

   
   
   

2) Adding a physical ethernet interface to the bridge br0:
With the network manager. Use not the device of the main connection! (ToDo)

2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
3: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    altname enp0s31f6
    inet 192.168.xxx.xxx/24 brd 192.168.xxx.xxx scope global dynamic noprefixroute eno1
      valid_lft 863604sec preferred_lft 863604sec
    inet6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 scope global dynamic noprefixroute
      valid_lft 6807sec preferred_lft 3207sec
    inet6 xxxx::xxxx:xxxx:xxxx:xxxx/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.xx.1/24 brd 192.168.xx.255 scope global virbr0
      valid_lft forever preferred_lft forever
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.xx.xx/24 brd 192.168.xx.xx scope global dynamic noprefixroute br0
      valid_lft 863493sec preferred_lft 863493sec
    inet6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 scope global dynamic noprefixroute
      valid_lft 6807sec preferred_lft 3207sec
    inet6 xxxx::xxxx:xxxx:xxxx:xxxx/64 scope link noprefixroute
      valid_lft forever preferred_lft forever

   
   
   
   

Wird jetzt eine VM gestartet, wird automatisch deren virtuelle Schnittstelle der Bridge hinzugefügt. Der Eintrag Bridge-Verbindung wurde eben gerade manuell erstellt, und steht für die physische Ethernetschnittstelle.
   


3) Disabling netfilter for the bridge:
$ sudo nano /etc/sysctl.d/99-netfilter-bridge.conf
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

$ sudo modprobe br_netfilter

$ sudo nano /etc/modules-load.d/br_netfilter.conf
br_netfilter

$ sudo sysctl -p /etc/sysctl.d/99-netfilter-bridge.conf


Creating a new virtual network
Create file bridged-network.xml
$ nano ~/temp/bridged-network.xml
<network>
    <name>bridged-network</name>
    <forward mode="bridge" />
    <bridge name="br0" />
</network>

Use file bridged-network.xml
$ sudo virsh net-define bridged-network.xml
$ sudo virsh net-start bridged-network
$ sudo virsh net-autostart bridged-network

$ sudo virsh net-list --all
Name              Status  Automatischer Start  Bleibend
------------------------------------------------------------
bridged-network  Aktiv    ja                    ja
default          Aktiv    ja                    ja

Create VM with the Virt-Manager.
Network selection:
Virtual network 'bridged-network': Bridge network
   

Windows Guest Settings
Set the computer name.

Linux Guest Settings

/etc/hosts:
--------------
127.0.0.1 localhost
127.0.1.1 <name>

# The following lines are desirable for IPv6 capable hosts
::1    localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

/etc/hostname:
--------------------
<name>

/etc/network/interfaces:
--------------------------------
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug enp1s0
iface enp1s0 inet dhcp
    hostname <name>

Statt das File "/etc/network/interfaces" wäre hier noch "/etc/dhcpcd.conf" möglich. Das kommt darauf an um welches Linux und welchen Installationsumfang es geht.
Wichtig sind das Aktivieren von DHCP und die Angabe des Hostnamen, damit dieser bei der DHCP-Anfrage mit gesendet wird.


PS: An den Markierungen (ToDo) fehlen Bilder, diese liefere ich noch nach. Diese Stellen weichen auch von der ursprünglichen Anleitung ab. Dort werden die Netzwerkschnittstellen permanent/statisch über Dateien direkt konfiguriert. In der Standardinstallation von Linux-Mint wird das Netzwerk aber grafisch/dynamisch durch den Network-Manager konfiguriert. Beide Konfigurations-Methoden sollte man nicht mischen! Für Notebooks ist es aus meiner Sicht am sinnvollsten beim Network-Manager zu bleiben.

Teil1: https://service-silberwelten.de/showthread.php?tid=441
Teil2: https://service-silberwelten.de/showthread.php?tid=442
Teil3: https://service-silberwelten.de/showthread.php?tid=443

Aktuell möchte ich wieder ein lokal installiertes Testgrid aufsetzen. Da ich aber die Maria-DB Datenbank ausschließlich dafür brauche, und die Datenbank sonst nicht unnütz im Hintergrund laufen lassen möchte, möchte ich das Ganze in einer virtuellen Maschine installieren. An dieser Stelle möchte ich aber nicht auf die Installation des Grids selbst eingehen, sondern Euch eine Alternative neben VirtualBox und VMWare vorstellen. Solltet Ihr Infos zur Einrichtung eines Opensim-Servers suchen, ist die Seite von Mareta Dagostino interessant:

https://hyperweb.eu/

VirtualBox und VMware kenne ich auch von deren Einsatz unter Windows her. Dort funktionieren beide sehr gut, und ich arbeite regelmässig mit mit einem der Beiden. Unter Linux war ich aber nicht so recht zufrieden mit diesen beiden Kandidaten. Punkte die mir nicht so gefielen war die Art und Weise der Systemintegration und in Teilen auch die Performance. Es fasste sich für mich in beiden Fällen etwas hakelig an. Was nicht heisst, daß man mit den Beiden nicht arbeiten kann. Man hat die selben Oberflächen wie unter Windows vor sich, und findet sich daher schnell in die Programme rein. Allerdings suche ich in der Regel unter Linux immer nach einer "nativen" Alternative.

Ok, um welche Programme soll es also gehen. Ich habe dabei eine Kombination von Qemu+KVM und Virt-Manager im Auge. Qemu ist der eigentliche Emulator und KVM der notwendige Unterbau als Bestandteil des Kernels (KVM= Kernel-based Virtual Machine). Um das KVM braucht ihr Euch nicht zu kümmern, das ist bereits Bestandteil des Kernels. Der Virt-Manager ist eine grafische Oberfläche mit der ihr komfortabel eure virtuellen Maschinen verwalten könnt.


Überprüfe die Systemarchitektur und die CPU-Virtualisierungsunterstützung

1. Führe den folgenden Befehl aus, um die Systemarchitektur deines Systems zu überprüfen.
$ uname -m

Du wirst die folgende Ausgabe erhalten.
$ Linux machine1 5.4.134-1 #1 SMP PREEMPT Tue Jul 06 08:10:03 UTC 2021 x86_64 GNU/Linux


2. Als nächstes überprüfe die Unterstützung der Hardwarevirtualisierung, indem du den folgenden Befehl ausführst.
Hier könnte es zu Irritationen kommen jenachdem ob lscpu eine deutsche oder englische Ausgabe liefert.
Wenn ihr keine Ausgabe erhaltet, versucht es mal mit sudo lscpu allein.
$ sudo lscpu | grep Virtualisierung

Für den Intel Prozessor wirst du eine ähnliche Ausgabe wie unten sehen.
$ Virtualisierung: VT-x

Und für AMD Prozessoren, unten ist eine ähnliche Ausgabe
$ Virtualisierung: AMD-V


3. Optional kannst du die verschachtelte Virtualisierung auf deiner Maschine mit dem folgenden Befehl aktivieren.
$ sudo modprobe -r kvm_intel
$ sudo modprobe kvm_intel nested=1

Danach führe den folgenden Befehl aus, um die verschachtelte Virtualisierung zu überprüfen.
$ cat /sys/module/kvm_intel/parameters/nested


Installieren der QEMU und Virt-Manager Pakete

1. Um die Pakete qemu und virt-manager zu installieren, führe die unten stehenden Befehle aus
$ sudo apt update
$ sudo apt install qemu-system-x86 libvirt-daemon-system libvirt-clients bridge-utils virt-viewer virt-manager


2. Als nächstes starte und aktiviere den libvirtd Dienst mit dem folgenden Befehl
$ sudo systemctl enable --now libvirtd


3. Danach führe den folgenden Befehl aus, um den Status des libvirtd-Dienstes zu überprüfen.
$ sudo systemctl status libvirtd


Erlaube Nicht-Root-Benutzern die KVM/QEMU-Virtualisierung zu nutzen

1. Führe den folgenden Befehl aus, um die libvirtd-Konfiguration zu bearbeiten.
$ sudo nano /etc/libvirt/libvirtd.conf

Entkommentiere die Option„unix_sock_group“ und gib den Gruppennamen als„libvirt“ ein.
Danach entkommentiere die Option„unix_sock_rw_perms“ und belasse die Berechtigung als Standard„0770„.


2. Als nächstes füge deinen Benutzer mit dem folgenden Befehl zur Gruppe„libvirt“ hinzu.
$ sudo usermod -a -G libvirt <username>


3. Danach starte den libvirtd Dienst neu, um die neue Konfiguration anzuwenden.
$ sudo systemctl restart libvirtd


-------------------------------------------------------------------------------

Danach weiter unter dem folgenden Link.
Abschnitt: "Überprüfe die QEMU/KVM Installation mit virt-manager"

https://www.howtoforge.de/anleitung/wie-...stalliert/

Dieser Post basiert auch zum grössten Teil auf dieser Anleitung. Achtet darauf, dass die Packages unter Manajaro Linux und Linux Mint zum Teil andere Namen haben!
In einem zweiten Post folgt noch die Konfiguration, wie Ihr die VMs für andere Rechner erreichbar konfigurieren könnt.

-------------------------------------------------------------------------------
Konfigurations-Tip (für langsamere Rechner):
===================================
- Abschnitt "Anpassen von KSM" unter dem folgenden Link:
    https://www.lug-ottobrunn.de/wiki/Virtua...en_von_KSM
- "Kernel same page merging" ist oft zu knapp eingestellt (20ms)
- in /etc/default/qemu-kvm
* KSM_ENABLED=1
* SLEEP_MILLISECS=200
echo 200 > /sys/kernel/mm/ksm/sleep_millisecs

Dieser Tip kam aus einem Youtube-Video  zu einem Vortrag innerhalb von einer Veranstaltung "Linux Tage". War das nun in Leipzig oder Chemnitz? Ich erinnere mich leider nicht mehr. Den Link zu dem Vortrag des entsprechenden Professors finde ich leider nicht mehr. Er hatte dort vorgestellt wie er mit Hilfe von Qemu+KVM in der Uni mit VMs arbeitet die zu Hause bei Ihm auf einem Server laufen. Wenn jemand das entsprechende Video kennt, nehme ich den Link hier gern auf.