haydibe
-
Posts
705 -
Joined
-
Last visited
-
Days Won
35
Posts posted by haydibe
-
-
I played arround with the vmware converter.
Here are my findings while converting the workstation vm to an infrastruktur vm
- hw version 11: failed, starts with the migration wizzard
- hw version 10: seems good, starts with the configuration wizzard
While converting, be sure to change the network adapter to 1000e, changing the harddisk to thin provisioning has no effect, it will be fat provisioned anyway.
Be sure to change the boot drive to be independent and not persistant.
The hw version 10 conversions works like a charm on esxi!
Made available for download here: https://mega.nz/#!T4gg0TgR!648lMRPslln0kflqejSchpkxSTnvs-G5cmtTFtyRJq0
Please be aware that the harddisks is set to 100gb and will be fat provisioned regardless of the setting while ova import AND the bootdisk need to set to be independent and not persistant before first boot!!!
-
I figured why the package that oktisme provided did not run as expected on esxi. Neither the orignal (=hw version 12, snapshot) , nor the downgraded one (~=hw version 11, no snapshot).
The harddisk "dsm 6.vmdk" is created using hardware version 12, which is not supported by any esxi version (even esxi 6.0u2 does not!).
Even when the provided vm is downgraded to hw version 10 or 11 using "change hardware compatibility" in vmware workstation, the harddisk is still hw version 12! I took a look at the vmdk with a hex editor - the string ddb.virtualHWVersion = "12" is always present. So the harddisk gets not downgraded.
That said: there is no way to use the ootb solution in esxi. It is like oktisme said: if the migration wizard appears on each reboot, it is because the "dsm 6.vmdk" can't be accessed by the esxi...
What can be done is to remove the disk "dsm 6.vmdk", add a new one and use the iso installer to install dsm6.
@oktisme: i know that you provided a hw version 11 version of your vm, but can you recreate a new vm based on hw version 10 - it is a pitty, but downgrading the hw version using vmware workstation is not sufficient here.
@oktisme: converting it to hw version 10 using the vmware converter worked, there is no need to recreate the vm. Thanks for all the efforts you put into making this work!!
-
@optic: did you try to clone the vm and export the clone?
-
Thing is: it works flawless in Workstation and Player.
I had no success yet to run it on ESXi - when try to remove and add the DSM_6.vmx (regardless of version 10 or 11 hardware export) that the vw would not be usable for Procuts that support up to hw version 11.
Pretty odd...
-
Thanks for Sharing a no snapshot version with us, oktisme!
@optic: the vmdk solution actualy plays nice and even allows btfs.
-
@oktisme: I installed vmware player 12 and imported the vm. When i try to edit settings for the vm, i get following error when i click on the second harddrive "the parent of this virtual disk could not be openend." Maybee an existing vm can not be backuped on a machine and restored on another when snapshots are used? Its just a suspicion...
This is the reason why the harddisk wasn't found earlier.
Could you create another version where the installation hard disk does not use snapshots - prefereable created using hardware version 11.
You did a great job oktisme and it would be great if you would iron out the last tiny detail so everyone can use it easily
-
The odd thing is:
I did not boot form the ISO. When i boot with "RUN", the installer starts all over again on every reboot.
If i boot with Install: 1st boot: the installer runs fine, 2nd boot: configuration (and access dsm) , 3rd boot: login to dsm
When i want to create a volume, i am able to see the drives, but the creation throws an error on the last step.
Maybee it's worth mentioning that i am trying to get it up and running on esxi 6.0u2 (which does not support hw version 12).
What worked for me:
- boot install from iso: install
- boot install from iso: configure and create a volume shr/ext4 (btrfs always failed)
i did install the new docker deamon. I guess i will stick with adding permanent shares from my xpe machine to this vm and avoid using physical harddisks for the time beeing..
-
Here, I downgraded it to 10.x since it tells me that 9 doesn't support SATA, which is required, and that 10 is supported by ESXi 6.0.
I haven't tested all packages, but so far they work.
Volumes are accessible and stay mounted.
I just tried the document viewer with pdf, xlsm, docx and it works.
I can configure the indexed search and it tells me that the indexing is done; don't really know how to test if it really works though.
Thank you very much for this. I still can't boot on my setup, but that's my problem
I run esxi on a hp gen8; I copied the vm, added a new hdd and no joy :
"Failed to start the virtual machine.
Module DevicePowerOn power on failed.
Unable to create virtual SCSI device for scsi0:0, './Boot.vmdk.REDO_kF29hq'
Failed to open disk scsi0:0: Unsupported or invalid disk type 2. Ensure that the disk has been imported."
When removing the first (out of two) serial ports (with vSphere Client) , changing the harddisks to be connected to the sata controller (with esxi embedded host client) and changing the nic to 1000e, i am able to boot and start the installert. Though, the installation is starting all over again after each reboot.
To access the "install" item, i had to use the vSphere Client in order to press tab while booting...
The installation went true fine and welcomed me AGAIN with the migration page, but this time i could enter my adminitrator credentials and the setup went fine
-
Wozu willst Du das eigentlich wissen? Du hat eh keinen Einfluss drauf!
Oder willst Du einfach nur rausfinden, wieviele Platten Du ziehen kannst, bevor die DSM Installation "kaputt" ist?
Selbst dann, stellt sich mir die Frage: wozu?
Was macht man mit dem Wissen, dass DSM auf jeder Fesplatte (!, nicht Volume) in einer separaten Partition gespeichert wird?
Diese Partition unterliegt nicht dem von Dir gewählten Raid-Level für den Volume.. Alles managed by DSM
-
Nehmen wir mal an, Du meinst mit Host den XPE Host und keinen Hypervisor a la HyperV oder ESXi und Du meinst mit VM Virtualbox auf XPE.
Dann könntest Du Teamspeak in einem Docker-Container sicher betreiben - in einer VM geht es natürlich auch... aber wozu die zusätzlichen Ressourcen verschwenden? Docker-Container sind über die XPE-IP und den Docker-Container-Port erreichbar. Wenn Du das mit Virtualbox löst, dann solltest Du darauf achten, dass die Virtuelle Netzwerkkarte an einer Bridge/Netzwerkbrücke hängt, dann hat die VM auch eine eigene IP.
Da Du vor hast auch VPN zu nutzen, würde ich weitere Dienste gar nicht erst über das Internet frei zugänglich machen.
Wenn Du per VPN eingewählt bist, kannst Du auf alle XPE-Services wie in deinem lokalen Netzwerk auch zugreifen.
Imho ist das die sicherste Variante.
Ich lasse bei mir ALLE Dienste über Docker-Container laufen und route die externen Ports direkt an DSM:{Port vom Docker-Container} weiter. Allerdings haben meine Docker-Container fast ausschließlich Leserechte auf die Daten-Shares und immer Lese-/Schreibrechte auf Konfigurationsverzeichnisse. Sollte ein Container gehackt werden, dann geht im schlimmsten Fall die Konfig flöten... Aber die kann man ja auch wegspeichern, dann kann man zumindest einen älteren Stand wieder herstellen
-
Wo ist den für Dich den Unterschied ob XPE in einer VM oder auf Blech läuft?
Im Endeffekt würdest Du in beiden Fallen Dein XPE im Internet exponieren.
Wenn Du den Zugriff auf DSM über einen Reverse-Proxy laufen lässt, würdest Du Dein XPE nicht mehr direkt im Internet Zugänglich machen.
Ungefähr so:
Internet <-> Router <-> Reverse-Proxy <-> DSM
Im Router würdest Du den Port dann auf IP:PORT vom Reverse-Proxy weiterleiten.
Der Reverse-Proxy bekommt dann die Anfrage aus dem Internet, Fragt bei DSM an, erhält die Antwort von DSM und schreibt diese so um, so dass es aussieht das er die Daten bereitstellen würde. Aus dem Internet wäre DSM dann nicht erreichbarDein DSM würde immer nur mit dem Reverse-Proxy reden.
Siehe: http://superuser.com/questions/987791/n ... o-url-base
Statt einem Reverse-Proxy könnte man auch ein Application Layer Gateway bzw. eine Application Layer Firewall einsetzen und dort die erlaubten urls, sowie parameter für GET und POST-Zugriffe per Muster erlauben - allerdings ist das keine triviale Sache...
Wenn Du statt DSM/Webstation was anderes über das Internet erreichbar machen willst, dann vergiss das alles und beschreibe genauer was Du am Ende tun können möchtest.
-
Von LSI ist der SAS2008, SAS2308 und SAS3008 Chipsatz sinnvoll für XPE. Hier nochmal das Mapping von Controllern, die den SAS2008 verwenden (auch von OEMs). Wichtig ist nur das der IT-Mode flashbar ist. Der Controller muss ja nicht unbedingt von LSI direkt gelabelt sein
Die anderen LSI Modelle in der Hardware Support List sind durchwegs Raid-Controller
Ich habe hier zwei HP Microserver mit jeweils einem LSI9211-8i (SAS2008 Chip) am laufen - ebenfalls in die XPE VM durchgereicht.
Performance, Smart ... passt alles
-
Irgendwie passt "virtuelles Laufwerk" und "den Raid Controller direkt durch gereicht" nicht zusammen.
Entweder hast Du den Controller durchgereicht oder nicht. Bei ersterem siehst Du die Laufwerke nicht mehr in Deinem Hypervisor, sondern nur noch in der XPE VM.
Aktuellste Firmware von der Hersteller-Homepage (LSI wurde von Avagotech aufgekauft): http://docs.avagotech.com/docs/12.15.0-0239zip
Das was Du vorhast geht mit den HBA-Controllern. Deins ist ein Raid-Controller... dafür gibt es afaik keine IT-Mode Firmware.
Du kannst aber trotzdem in der VM ein RAID über den Controller anlegen (ist dann eben herstellerspezifisch) und dann diese logischen Laufwerke in XPE verwalten. Den Zugriff auf eine direktes physikalisches Laufwerk wirst Du nicht bekommen. Ebensowenig wie die SMART-Informationen.
Der Vorteil ein XPE/DSM ist das das Software-Raid nicht Herstellerabhängig ist und Du zur Datenrettung auch mal an ein belibiges Linux ran kannst.
Wenn Dein Controller dagegen kaput geht, kommst Du nur mit einem Kompatiblen-Kontroller wieder ran. Dafür könnte das HW-Raid performanter sein
Als Nachteil sehe ich, dass Du dann kein SHR einsetzen kannst...
-
Is the "valid internal ip" in the same subnet as your windows host?
You could use a browser and open the url http://"valid internal ip":5000 and get to the installer.
Are you sure the network adapter of your vm (in hyper v) is set to bridged mode?
-
Bei hardwareluxx sind auch nicht Xeons aufgelistet die VT-d unterstützen - ohne VT-d gehts leider nicht. Die sollten günstiger zu schießen sein als die Xeon-Brüder.
Bspw. liegt die Leistung eines i5-3470T leicht über der eines Xeon E3-1220L v2, der Stromverbraucht ist allerdings auch marginal höher
Beide haben 2 Cores mit jeweils HT.
Den embedded Host Client kannte ich noch gar nicht. Das ist der reine HTML5 Web Client - kein generve mit Flash mehr. Nice!
Mit dem vSphere Desktop Client habe ich es mal geschafft die VMs auf Version11 zu hieven. Danach konnte ich die VMs nicht mehr im Desktop Client verändern und musste am Ende die vCenter Appliance installieren.
Der Host Client ist ab ESXi 6.0u2 mit dabei
-
Ich verwende ein vanila ESXi6.0 auf zwei solcher Kisten und den B120i auf SATA gestellt.
Bei mir lief das Custom HP ESXi 6.0 nicht stabil, wenn der B120i im SATA-Modus betrieben wurde.
Das Custom Image lief performant, als ich im B120i je Platte als als eigenes Raid-0 Array angelegt habe.
Hat mir aber nicht gefallen, weil dadurch die SMART-Informationen nicht zum ESXi "durchschlagen"
Am Ende habe ich LSI-Controller eingebaut und die über Direct-IO an eine XPE VM weitergereicht.
Performance, stabilität und SMART-Anzeige passen so
2. Embedded Oberfäche? Man kann weiterhin grundlegende Einstellungen des ESXi Hosts in der Shell durchführen.
Aber für die Verwaltung der VMs wird weiterhin der vSphere Client oder der vSphere Web Client benötigt.
-
würde mich stark wundern, wenn es so wäre...
Ich habe diverse Container schon in diversen Versionen laufen lassen. Port-Kollisionen hatte ich immer nur dann, wenn es sich um einen von DSM belegten Port gehandelt hat. Ein Port kann nur in einem Container verwendet werden - unabhängig davon, ob dieser läuft oder nicht.
Ich könnte mir vorstellen, dass ein nicht richtig gelöschter Container das Problem war.
Auflisten von laufenden und nicht laufenden Containern:
docker ps -a
Dort sieht man auch die Ports die verwendet werden.
Über die Commandline kann man sonst auch die Container stoppen (=graceful), killen (=force stop) und löschen (muss vorher gestopped sein).
Hilft dir das weiter?
-
Selbst wenn die Quellen für Kernel und Toolchain veröffentlich wurden, müssen die notwendigen Anpassungen erst identifiziert werden, bevor man auch nur im Ansatz auf die Idee einen Zeitplan abschätzen zu können. Selbst wenn die Entwickler 8h am Tag (40h/Woche) für die Entwicklung bezahlt werden würden, wäre das noch lange keine Garantie dafür, dass ein solcher Zeitplan dann auch eingehalten werden kann. Da die Entwickler dies in einem Teil ihrer Freizeit machen, stehen Ihnen am Ende dann deutlich weniger Stunden zur Verfügung.
Der Satz "kein Herz schlägt so stark, wie das eines Freiwilligen" gilt auch im Bereich der nicht kommerziellen Opensource-Entwicklung...
-
Gib halt irgendetwas ein.. und nimm als mailadresse einen TrashMailer und gut ist.
Damit wird das Paket trotzdem nicht funktionieren...
-
Ein Oracle OTN Account ist kostenlos.
Einfach registrieren und Du kannst Dich einloggen.
Löst das Dein Problem? Nö!
Die meisten Downloads benötigen bei Oracle einen OTN Account.
Die installation klappt nicht mal, wenn man sich in einem anderen Tab mit einem OTN Account anmeldet.
Das Syno-Paket muss wohl vom Maintaner mal überarbeitet werden...
-
I am currious if somone has a copy of the sources of the SynoCommunity package open-vm-tools made by Sancome?
The last publicly available build of SynoCommunity/open-vm-tools is 9.10.0-2476743-1.
The latest source code of open-vm-tools is 10.0.5-3227872.
It seems like Sancome's open-vm-tools never went into the stable branch of the SyncoCommunity "spksrc" sources.
I searched github and took a look at all spksrc forks and it's branches. The sources of Sancome's SynoCommunity/open-vm-tools
are not available.
I would love to see a new build based on the latest official sources.
Can someone share the sources or create an updated SPK?
-
I know this is not much of a help but: your screenshot does NOT show the DMS root parition, it does show the xpenoboot partition of the bootloader.
The DSM root partition would include the folders /volumen (where n is a number starting with 1).
-
.. An unexpected error occurred: OSError: /usr/local/debian-chroot/var/chroottarget/proc/self/task/8946/root/proc/self/task/8946/root/proc/self/task/8946/root/proc/self/task/8946/root/proc/self/task/8946/root/proc/self/task/8946/root/proc/self/task/8946/root/proc/self/task/8946/root/proc/self/task/8946/root/proc/self/task/8946/root/proc/self/task/8946/root/proc/self/task/8946/root/proc/self/task/8946/root/proc/self/task/8946/root/proc/self/task/8946/root/proc/self/task/8946/root/proc/self/task/8946/root/proc/self/task/8946/root/proc/self/task/8946/root/proc/1/task/1/cwd/volume1/@appstore/letsencrypt/lib/libaugeas.so: cannot open shared object file: Too many levels of symbolic links Please see the logfile 'letsencrypt.log' for more details. 14.05.16 17:58:06: [ DONE ] 14.05.16 17:58:06: [ Copying LetsEncrypt Server Key ] 14.05.16 17:58:06: Creating Backup: /usr/syno/etc/ssl/ssl.key/server.key.bak 14.05.16 17:58:06: Current File: /usr/syno/etc/ssl/ssl.key/server.key 14.05.16 17:58:06: Coping Source to Destination: (/volume1/letsencrypt/data/live/xxxx/privkey.pem) -> (/usr/syno/etc/ssl/ssl.key/server.key) cp: can't stat '/volume1/letsencrypt/data/live/xxxx/privkey.pem': No such file or directory 14.05.16 17:58:06: Current File: /usr/syno/etc/ssl/ssl.key/server.key 14.05.16 17:58:06: [ DONE ] 14.05.16 17:58:06: [ Copying LetsEncrypt Server Cert ] ./letsencrypt-synology.sh: line 230: can't create /volume1/letsencrypt/data/live/xxxx/cert.crt: nonexistent directory ./letsencrypt-synology.sh: line 231: can't create /volume1/letsencrypt/data/live/xxxx/cert.crt: nonexistent directory 14.05.16 17:58:06: Creating Backup: /usr/syno/etc/ssl/ssl.crt/server.crt.bak 14.05.16 17:58:06: Current File: /usr/syno/etc/ssl/ssl.crt/server.crt 14.05.16 17:58:06: Coping Source to Destination: (/volume1/letsencrypt/data/live/xxxx/cert.crt) -> (/usr/syno/etc/ssl/ssl.crt/server.crt) cp: can't stat '/volume1/letsencrypt/data/live/xxxx/cert.crt': No such file or directory 14.05.16 17:58:06: Current File: /usr/syno/etc/ssl/ssl.crt/server.crt 14.05.16 17:58:06: [ DONE ] 14.05.16 17:58:06: [ Copying LetsEncrypt CA Cert ] 14.05.16 17:58:06: Creating Backup: /usr/syno/etc/ssl/ssl.csr/server.csr.bak 14.05.16 17:58:06: Current File: /usr/syno/etc/ssl/ssl.csr/server.csr 14.05.16 17:58:06: Coping Source to Destination: (/volume1/letsencrypt/data/live/xxxx/chain.pem) -> (/usr/syno/etc/ssl/ssl.csr/server.csr) cp: can't stat '/volume1/letsencrypt/data/live/xxxx/chain.pem': No such file or directory 14.05.16 17:58:06: Current File: /usr/syno/etc/ssl/ssl.csr/server.csr 14.05.16 17:58:06: [ DONE ]
Lässt Du das Script zufällig in deinem bebian-chroot laufen? Ich verwende es in dem DSM.ash.
Solche Fehlermeldungen habe ich nicht. Das wird ein Problem mit Deinem debian-chroot sein.
Wenn Du debian-chroot hast, solltest Du mit der anderen Lösung direkt in dem chroot arbeiten können.
-
zunächst einmal vielen Dank für Ihre freundliche Unterstützung!
Gern geschehen.
Die Zertifikate sind erzeugt und gleich nach /usr/syno/etc/ssl.crt,/usr/syno/etc/ssl.csr und /usr/syno/etc/ssl.key kopiert, aber in ordner /volume1/letsencrypt/data immer noch keine spur?
Deine Zertifikate liegen unt er /volume1/letsencrypt/data/live/{domainname}
Aber NUR wenn Let's Encrypt auch sauber durchläuft.
Von dort werden die Daten in die /usr/syno/etc/ssl.* Verzeichnisse kopiert!
diese variante: http://www.synology-forum.de/showthread ... post573165 ist doch einfache
Daher brauchen keine zusätzliche Pakete installieren und werden keine "unkontrollierte" prozesse in dsm laufen.
"Unkontrollierte" Prozesse? Du kannst Doch im Branch genau sehen wie das SPK zusammengebaut wird, was es tut, was für Quellen es verwendet.
Die andere Variante ist das was ich zuerst gemacht habe - dann habe ich festgestellt, dass es mir zu blöd ist alle 90 Tage ein neues Zertifikate auf einem anderen Linux-System zu erzeugen und dann ins DSM zu kopieren und dort einzubunden.
Danach habe ich versucht letsencrypt (wie bei deinem Link beschrieben) direkt auf DSM laufen zu lassen - allerdings hat es nicht funktioniert. Deshalb habe ich ein letsencrypt SPK gesucht und durch Zufall den Quelltext auf Github gefunden und bin dann auf spksrc gestossen, so dass ich es am Ende selber bauen konnte.
Wenn die andere Variante für Dich funktioniert, dann ist das doch super!
Ich persönlich bin zu Faul alle 90 Tage das Zertifikat zwischen den Systemen hin und her zu kopieren.
Insbesondere, da ich dasselbe Zertifikat auch in Docker-Containern einbinde.
Working DSM 6
in Loaders
Posted
During my test, I figured that changes in the vSphere Client get persisted, while those in ui don't.
To be honest: i didn't try to do any config changes in the current vm yet. I am just glad that it works the way it is now
You can always extract the ova file and edit the ovf file, create the sha1 checksum and repace the existing value with the new one.
Then you can use the ofv file to import the vm.