Search the Community

Buenos días, Tengo un HP Proliant Microserver gen8 con Proxmox montado y una de las máquinas virtuales con un Xpenology DSM 6.1. En ese Xpenólogy, la primera bahía (sata0) la tengo con la imagen de arranque synoboot.img y luego las cuatro bahías físicas del servidor están mapeadas directamente como sata1, sata2, sata3, sata4 con un grupo SHR y finalmente un sata5 con un disco virtual mapeado de un SSD como caché SSD por lo que me aparece la primera bahía utilizada sin uso y las siguientes 5 bahías con los discos. He conseguido otro servidor igual y quiero migrarlo con el DSM 6.2 Baremetal físico sin usar máquina virtual y el problema que tengo es que, como no necesito la imagen de arranque como disco ya que lo arranco desde microsd, los discos físicos empiezan a contar desde el principio por lo que quedan todos desplazados un lugar a la izquierda respecto al otro servidor. He procedido a cambiar el sata0 del synoboot.img de arranque del servidor virtual a sata6 para liberar la primera bahía virtual, querría dejar el servidor virtual con las bahías como el físico antes de migrar físicamente los discos al primero por lo que ahora queda como adjunto en la primera imagen. Mi miedo es que si muevo todos los discos una bahía menos al no estar en la bahía que tenían no reconozca el grupo SHR y pierda los datos. Como es un SHR con tolerancia a un disco de fallo, en vez de mover todos los discos podría mover la bahía de 1 de ellos por ejemplo el que está como sata4 la pase al sata0 pero no se si eso funcionará, es decir: si falla el disco de la bahía del sata4, Sinology sólo reconstruye el SHR si el "nuevo disco" lo monto en el sata4 o podría elegir otra bahía para reconstruirlo y así decirle que utilice la sata0? una vez tenga los 4 discos físicos en las 4 primeras posiciones, quitaría la caché SSD y procedería a mover los discos a las 4 bahías del servidor físico Cómo véis mi planteamiento? cómo lo puedo hacer? si de una NAS se jode una bahía y no se puede utilizar para reconstruir un grupo RAID, ¿no se puede asignar otra bahía para ese disco del grupo?

Проблема с Virtual Machine Meneger, есть DSM 6.1.3, стоит последний для нее Virtual Machine Meneger, устанавливаю Windows, первая перезагрузка и все, NoVNC не отвечает, виртуалка уходит в себя, подкидывание или убирание iso не помогает, просто даже снова не грузится! (( В чем может быть причина ?!

Not sure what the issue is. Every time I try to create a VM, VMM puts in reserve 80% of my ram (10gb total) leaving me with less than 2gb (yes i know it should be exactly, but im assuming that system itself is taking up at lease 512mb as well) Which of course leaves me not able to create a VM of any kind. Please, any help would be appreciate it.

Hallo zusammen, Vorab mein Setup : Intel H370 Plattform mit Pentium G5400 Aktueller DS918+ Loader auf ESXI installiert Synoboot.vmdx auf Satacontroller 0:0 Datenfestplatten sind per PCI Passtrough an einen LSI 2008 Controller angeschlossen Ich habe gerade mein XPEnology System in Betrieb genommen und wollte mich nun ans finetuning machen. Dazu gehörte auch direkt im Standard Zustand ohne irgendwelche Pakete zu versuchen dieses lästige Festplatten Ruhezustandsthema hinzubekommen. Dabei entdekte ich folgenden LOG Spam, der das natürlich verhindert und auch sonst durch laufende Schreibvorgänge den Stromverbrauch, und Lautstärke in die Höhe treibt (aus scemd.log): 2019-09-12T17:19:20+02:00 NAS19 scemd: SmartDataRead(102) open device /dev/sdak fail 2019-09-12T17:19:20+02:00 NAS19 scemd: disk/disk_temperature_get.c:104 read value /dev/sdak fail 2019-09-12T17:19:20+02:00 NAS19 scemd: disk_temperature_update.c:63 Temperature Update Fail 2019-09-12T17:19:26+02:00 NAS19 scemd: SmartDataRead(102) open device /dev/sdak fail 2019-09-12T17:19:26+02:00 NAS19 scemd: disk/disk_temperature_get.c:104 read value /dev/sdak fail 2019-09-12T17:19:26+02:00 NAS19 scemd: disk_temperature_update.c:63 Temperature Update Fail Das insterresante ist : ich kann mir kein Reim drauf machen was /dev/sdak sein soll. Wie die smartctl --scan ausgabe mir anzeigt sind die Datenplatten sde,sdf und sdg. Per Ausschlussverfahren muss es also die Synoboot.vmdk sein, welche mir ja auch im Speichermanager angezeigt wird. Ich habe schon Ein wenig probiert mit dem Sata Port Mapping etc. in der Synoboot.img etwas zu erreichen aber das wirkte alles wie zufällig auswürfeln, es kam nie das heraus was herauskommen sollte. Im Anhang ein Screenshot des Speichermanagers und der ESXI Konfiguration. Weiß jemand wie ich die Synoboot.vmdk "los werde" damit dieser Fehler verschwindet? EDIT 1 : Ich habe einmal unter /dev/ nachgesehen und festgestellt, das es gar keine device file sdak gibt. Die Synoboot.vmdk als Ursache würde ich damit nicht mehr definitiv festmachen sondern Probleme beim Sata Port Mapping in der grub.cfg . Welche Einstellungen sollten dort getroffen werden für : Sata Controller 0 mit Synoboot.vmdk auf Sata 0:0 + PCI Passtrough HBA? Vielen Dank!

Hallo zusammen, hier ist eine Anleitung zum Update des Boot Loaders auf Jun's Bootloader V 1.02b.Basiert auf Synology DS3615xs und VMware ESXi v6.5. Upgrade des Jun's Bootloaders von V1.01 auf V.1.02b, damit man DSM 6.1.x (i.d.F. 6.1.5-15254 Update 1) installieren kann. 1. Vorher DSM ausschalten und die betroffene VM mit DSM bzw. Xpenology vom ESXi-Datastore auf lokale Festplatte sichern. Im Falle eines Problem ist somit für Backup vorgesorgt 2. In der gesicherten VM-Ordner befindet sich ein synoboot.img. Diese Datei entpacken und in der "grub.cfg" -Datei (synoboot\boot\grub\grub.cfg) nachschauen, welche Einstellungen aktuell hinterlegt sind. Dieser Textbereich ist relevant: set vid=0x058f set pid=0x6387 set sn=B3Lxxxxx (Eure SN-Nummer!) set mac1=011xxxxxxx (Eure MAC-Adresse!) set rootdev=/dev/md0 set netif_num=1 set extra_args_3615='' 3. Die aktuelle Jun's Bootloader (synoboot.img) in der aktuellen Version (derzeit V.1.02b) für DS3615xs hierüber herunterladen. 4. Die heruntergeladene synoboot.img mit der OSF-Mount Software mounten. Dabei beachten, dass beim Mounten die Optionen " Mount All Volumes" angehackt und "Read Only drive" nicht ausgewählt ist 5. Danach im Windows-Explorer in das gemountete Laufwerk navigieren. In der "grub.cfg" der gemounteten synoboot.img-Datei (\boot\grub\grub.cfg) die Informationen(MAC-Adresse, SN-Nummer usw.) von der alten "grub.cfg" -Datei übernehmen bzw. überschreiben und die Änderungen speichern. Danach die zuvor gemountete Datei wieder über OSF-Mount dismounten (Dismount All & Exit) 6. Die Alte "synoboot.iso" Datei auf dem VMware-ESXi Datastore löschen und durch die aktuelle synoboot.img ersetzen (hochladen) 7. Danach die VM mit DSM bzw. Xpenology auf dem ESXi wieder starten. Wichtig: Über die VMware Konsole unmittelbar nach dem Start mit der Tastatur "Jun's Bootloader for ESXi" auswählen und mit ENTER bestätigen 8. Im Web-Browser "find.synology.com" und mit ENTER bestätigen. Synology Web Assistant sucht jetzt nach der DSM und zeigt den Status als "migrierbar" an. Dort auf "Verbinden" klicken und auf die DSM verbinden. Dort steht jetzt: "Wir haben festgestellt, dass die Festplatten Ihres aktuellen DS3615xs aus einem vorhergehenden DS3615xs entnommen wurden. Bevor Sie fortfahren, müssen Sie einen neueren DSM installieren." 9. Nun kann man die .pat-Datei (DSM-Firmware) hinzufügen und manuell installieren lassen aber oder automatisch die neueste DSM Version vom Synology-Server (online) installieren lassen. Ich empfehle euch die manuelle Installation, da es keine Garantien gibt ob die aktuellste DSM-Version vom Synology-Server (online) mit eurem Xpenology Boot Looder funktiert. Ich habe meine (diese) Installation mit der DSM Version "6.1.5-15254 Update 1" erfolgreich hingekriegt. Hier könnt ihr diese Version herunterladen: DSM_DS3615xs_15254.pat 10. Nun auf "Installieren" anklicken und danach "Migration: Meine Dateien und die meisten Einstellungen behalten" auswählen. Auf "Weiter" und "Jetzt installieren" anklicken 11. DSM wird nun auf dem neuen Jun's Boot Loader installiert (dauert ca. 10 Minuten) 12. Nach der Installation im DSM anmelden und die durch den DHCP-zugewiesenen IP nach Wunsch wieder anpassen bzw. ändern Fertig.

Добрый день устанавливал Windows 7,10 и все зависают после первой перезагрузки. Устанавливаю через драйвера VirtIO (все диск, сеть). то есть сразу подсовываю во время установки, иначе винт не видится. версия vmm 2.2.2-8493, версия DSM 6.1.4-15217 Update 5. Может уже сталкивались с такой проблемой? как ее решить?

Hi, I have a Gen8 running DSM 6.1.4-51217 Update 5. I have been trying to get Virtual Machine manager up and running. The package installs fine, but when I run it, it only allows me to select Volume 3 as the storage for the VMs. I am using PetaSpace to manage volume 1, which is made up of a combination of drives. Am i unable to use this volume for VMM?