cuspess

I am beginning to think case like this, if you still had your old loader 1.01 with you, you could still boot with 1.01 and have your DSM 6 working like before the upgrade. Someone please confirm if my thought is right, otherwise I think it is fair to say it is safe to try upgrading. cheers

I think Xpenology 6.0 has already been widely used without too much problem, not so much that I know off anyway. It is not "Offically" released, for whatever reason those developers thinks not suitable, maybe there is in fact some bugs that they still not able to fix to call it final. But I have a feeling that Xpenology has started to fall, from the drop of discussion and relative absent of post from developers. The last progress for Xpenology 6.0 beta was back in November 2016. So far I have been using that bootloader without any issue, sucessed to update DSM 6 to update 9. I hold little hope to further development if I am honest. In the same time I repect all the work developers put into xpenology and there is no reason to force them to work on it if they don't want to. Nonetheless, I would still be glad if the project would progress further, be DSM 6.1 releases a driving motion to ignite the developers eager again. I will come back and forth to check things out from time to time. Cheers.

I do have another raid card added for my ssd and additional hdds for use of other virtual machines.

All cores are recognized and used, but i3 and 2 cores displayed by interface. Its a bug, but only cosmetic. Apologies to dig up an old post. Regarding xpenology cpu usage when running plex, I had a similar issue as the quoted person above. My xpenology is running on esxi 6.0 with a e3 1240 v2 4c8t cpu. That translate into 8 cores in esxi I believe. I first assigned 2 of the cores to run my xpenology and had reached 100% cpu usage (in dsm resource monitor) when running plex server to dine mkv movie to my android box; the movie is in 1080 and played with occasion lag or pause. I then thought 2 cores is not enough so I up it to 4 cores. The same lag and pause still exist and not imported a t all with cpu usage 100% as well. For both 2 and 4 cores setup, I had to change the playback to 720 to ensure a smooth playback. I am thinking the change if vm cores number does not get transfer to dsm, or xpenology is not coded to accommodate the change? Or once 2 cores is recognised at first setup, it will not change even 4 cores is provided after?

I have not tried rdm or internal raid so I can't provide solution to your problem. However the way I set it up work flawlessly so you may take it a a reference. I got the internal B120 controller in ACHI mode, then passthrough it to my DSM virtual machine. All HDD connected to this will see as connected directly to my "Synology Box" without the layer of vmdk or rdm (which rdm is kind of a virtual disk layer to me. I know very little about virtualisation so I could be wrong, but I think rdm is a software mapping of the drive). My setup will means the hdd will work like a normal Synology NAS, therefore less likely to face error or data loss caused by esxi.

Want to add that, because VMware is like a windows operating system. Despite the variant of win7 vista win10, once you had it installed, compatibility will almost be the same on any pc/servers from different brand/make/vendor; less compatible problem versus baremetal. That is not to say baremetal will have issues, but dsm updating error all over this forum seem to be less likely if it is on vmware than baremetal.

You don't need to use USB drive for bootloading into xpenology under esxi. That is just the way I wanted it to work, so to a) save space on my SSD even though it is only few hundred MBs, b) making use of the already there internal usb port, in fact I even use the MircoSD slot for running esxi, c) in relation to previous point, booting from USB drive means I could easily backup and replace bootloader in case anything went wrong. The entire concept of my setup is to isolate Xpenology as much as possible from the other VMs on the same Gen8 physical machine, so to up the reliability and increase revival chance. To do so I also passthrough the entire B120i (ran in AHCI mode) for Xpenology use only; that way the drives connected to B120i works just as a proper Synology drive without the layer of vmdk or use of RDM. Touch wood, if my Gen8 decide to not work, I can still unplug my drives and use Linux to read all data directly. This is abit off topic but I hope you get the idea. Now I know there are ways to overcome the 50MB issue, especially when bootloader running from vmdk on SSD and such. Mine is just a way that I worked out and find suitable for my requirement. I think there are still things that I could fine tune, but my xpenology is running smooth and stable that I would rather stick with it for now. A side note that I happened to try upgrading my esxi 6 to 6.5 yesterday and for some reason it didn't work out well. I could not downgrade from 6.5 to 6 either, so I did a reinstallation of esxi 6. From this exercise, I have been able to add my xpenology back to esxi easily and everything runs as if I never upgraded; that proofs the reliability that I am after.

As much as I appreciate the effort I do now run DSM without the use of any flashdrive what so ever I created a new VM where I added the VMDK (same folder as the IMG) as SATA device and a Marvel Sata card in PCI passthrough. Started the VM and all is working perfectly except that the 50MB drive is there. No need for any external device. All is inside the ESXi box Using a J3455-ITX board Good that you are pleased with your set up. Everyone has their own way of doing it, I just couldn't stand having the odd 50MB drive there, kind of bugs me not getting rid of it.

I just got it finally working and you have to put the VMDK and IMG file in the same datastore folder for it to work. I do see the 50MB drive now as a HDD in DSM and think I need to edit the grub file to hide it from there. But, don't know how to get the correct VID/PID For now, i only have 4 real disks so, no issue of having an extra drive in there. I am glad to see someone using the same setup as I do, and although I didn't get much respond when I faced the 50MB drive issue I solved it eventually by keep digging the web and trial n error. And I am here to provide a solution so you can save some time, and to make my 2 days of digging around more worthy! lol And I must say I don't like being asked to look up old post when I posted a question, but I do feel that it is more annoying if the same questions comes up every 4~5 pages. So please try your best to use the search function or take your time to read through the entire thread. Now, how a true DSM actually works in a Synology machine is by booting up from its built in flash memory or DOM (in our xpenology case that would be the USB drive). At this phase, find.synology.com became accessible for the setup procedure, which intended to install the actual DSM OS onto all connected HDD (where each HDD will be partitioned to store the OS and you storage separately. It is mandatory step). Once the installation is all done, everytime when we start up the machine, the bootloader on built in flash memory (our usb drive) will run the DSM OS off the HDD. To sum up, the minimum hardware requirement would be only 1 flash memory for boot up and 1 HDD for running DSM (for our xpenology that would be 1 USB drive and 1 HDD respectively). With the above concept in mind, when you add vmdk and img file to your datastore aka vm hdd, what it does is became the booting device (replacing the role of USB drive). So when first start up, it boot from vm hdd, initiated the setup procedure and wiped both your USB drive and hdd (worth noting there would be 3 partitions on the USB when created with rufus or related software; only the 50MB partition on USB is being wiped and the other 2 will remain. Possibly due to DSM not able to detect those 2 partitions.) For that reason there will be the 50MB HDD as well as your proper HDD appear on your DSM system. That also lead to a problem that your USB drive is not actually used for booting up; meaning any changes to PID/VID, serial no, etc, had no effect to your DSM. To get round this, you have to ensure you are actually booting from the USB drive. From what I learnt from the internet, esxi could not boot from USB drives but you can get round this with Plop Boot Manager. While Plop has lot of great features, all we need is the bootup iso. Mount the iso to your esxi virtual CD/DVD drive and when bootup it will provide you the function of boot from usb. From there you can truely access and boot from Jun's loader off your prepared USB drive, with all the PID/VID etc config. Once all setup you will also find only the actuall HDD on DSM system; the 50MB HDD is gone as it gets ignored by the PID/VID config. One last thing to note; you don't need the "vmdk and img file to your datastore" because all you do is boot up Plop > boot up Jun's loader from USB > DSM runs off actual HDD. Now I mentioned Plop has lot of great features, for instance you can alter it to auto boot after 5 secs count down, disable Plop's floppy drive boot option, etc. From my understanding we can only use the default settings because we can't save the changes we make on a virtual CD/DVD. Therefore by default we have to manually select "boot from usb" on plop every boot up. While it is not an issue for myself as once my NAS is on i rarely reboot or turn it off. But I would love to know if there is any work around for this, so that I could set it to auto boot after 5 secs, and potentially any other good feature too. Thanks and hope whoever using Gen8 + esxi combination find this useful. Cheers.

ESXi does not support VM booting from USB. You can work around the issue with "plop boot manager". Basically, you use CDROM iso as a boot drive in your VM, which then points to the USB stick. I am not sure it's worth the trouble. If you want to edit the config file on the VM, you can just do that, there's no need to use a USB image as a work around. Dynax, great to hear your advice again! In fact I came across plop boot manager just now and got it running. Now my DSM is running as I wanted! Superb stuff that is. Main reason to use this method is that without booting from USB, I get the 50MB HDD issue I mentioned previously, and that kind of bugged me not working like a bare bone would. Though not sure if I was the only one who faced that problem with Gen8+esxi as I have not seen anyone talks about it, maybe everyone use a Gen8 with bare bone. The only niggle I still have is that when using plop boot manager I have to manually select "USB" from the menu, as any settings such as auto countdown, floppy disabling, etc would not saved (far as I understand it is due to the nature of "CD/DVDs" could not be edited and saved, hence any altered settings would not save for next boot). Would be great if there is a way to fix this small thing, perhaps edit the iso would do the trick. i will look into that anyway, but if anyone got some previous experience on this, I would greatly appreciate some words too. Cheers

I refer to my previous question posted here, I tried to diagnosis the cause of additional unwanted HDD in my DSM and realise the DSM is actually not booting from the USB drive I prepared (plugged inside MicroServer Gen8 internal USB port). Instead it boot from the 50MB vmdk file created (and saved on my SSD) when I deploy the OVF file. That also explains why the serial number and MAC number I edited in the grub and burnt to USB drive didn't change and show up when I set up the DSM when connected to find.synology.com. The plugged USB drive simply did nothing. Problem is, I tried to remove the 50MB vmdk from virtual machine settings, added USB controller and USB xHCI controller to virtual machine settings. With the actual USB drive plugged in, I also added such USB drive to the virtual machine settings. However when I power the virtual machine on, I could not select it from the BIOS boot order, nor would it auto boot up. So, sincerely, can someone running xpenology 6.0 under esxi on a HP Microserver Gen8 could share you thoughts and setup to help me out here?? Thanks so much Hey people, while I am hoping to hear some experience sharing regarding the problem I faced, I have been researching and came across a statement saying "USB boot is not supported in ESXi". Can someone with related knowledge confirm that?? Thanks

I refer to my previous question posted here, I tried to diagnosis the cause of additional unwanted HDD in my DSM and realise the DSM is actually not booting from the USB drive I prepared (plugged inside MicroServer Gen8 internal USB port). Instead it boot from the 50MB vmdk file created (and saved on my SSD) when I deploy the OVF file. That also explains why the serial number and MAC number I edited in the grub and burnt to USB drive didn't change and show up when I set up the DSM when connected to find.synology.com. The plugged USB drive simply did nothing. Problem is, I tried to remove the 50MB vmdk from virtual machine settings, added USB controller and USB xHCI controller to virtual machine settings. With the actual USB drive plugged in, I also added such USB drive to the virtual machine settings. However when I power the virtual machine on, I could not select it from the BIOS boot order, nor would it auto boot up. So, sincerely, can someone running xpenology 6.0 under esxi on a HP Microserver Gen8 could share you thoughts and setup to help me out here?? Thanks so much

That new feature about editing grub for vid pid, is it already integrated in the exisitng Jun V.1.01? Such a convenient feature, could have saved me earlier. But perhaps I was installing via esxi using ovf, don't remember seeing that many options when I boot into xpenology.

From there onwards, you need to go to your web browser, type in find.synology.com that will lead you to setting DSM up.

Refer to my previous question, I was able to install DSM 6 on my SSD drive. But the OVF file had a 50MB virtual Disk default setting (assume thats where the DSM install to) which also recognized by DSM itself as a HDD in Disk Manager (See attached photos). I am wondering if I have done anything step wrong to cause this issue? Don't seem to see other people experience the same. Any thing I can do to disable it from Disk Manager? Thanks.

If you are talking about the ESXi 5.5 OVF that I uploaded then it's the same as jun 1.01 OVF. I only made it compatible with ESXi 5.5 and the Classic vSphere Client since I don't like the web client. Yes dynax, thanks for your input, really helped me out of the puzzle! While everything is working fine now, including the update to 6.0.2-8451 Update 4, I am looking to streamline / enhance my set up and would appreciate some opinion related to jun's OVF file. My Gen8 is currently set up with ESXi 6.0 installed on a 16GB microSD. Jun's synoboot.img is burned to a 2GB USB drive plugged in in the motherboard USB. When deploy Jun's OVF and vmdk for the first time, a 50MB vmdk virtual HDD image is set up by defualt. Without much knowledge, I guess this is DSM's system drive. But because the entire Xpenology (including the 50MB vmdk) has to save to a datastore, I had it saved on the datastore created on my SSD drive. Now in my DSM I can see 2 drives; one 3TB HDD which is a passthrough drive, then it is this 50MB HDD (= the defult 50MB vmdk) which supposed to be for the DSM system. For sure I can't format it for use for storage as it contains the DSM system itself, but the way it shows in my DSM Disk manager seems abnormal as I have not seen anyone having this issue. May some enlighten me if I got any part of my setup wrong to cause this? Thanks.

Your post count maybe too low to add images? Have you tried adding a disk group and then adding the volume after that? Anyone have this problem? The option to create new volume is greyed out. This is a drive that was a volume2 before with the DSM5.2. I could try formatting the drive in an external and then sticking it in the system but I would lose the data on it. Just wanted to find out if anyone else had this issue? I am sure there is a way to go in CLI and mount or change some setting so storage manager will see this. I think you have to first create a Raid Group before you create a volume. I am kind of new to DSM but from the playing around of DSM 6 as my first encountered version, I was searching very hard to try creating a volume before grouping it as it was how they teach you doing it on the SynoWiki. I believe they turn the process around from DSM 6 and I am not sure how you should set it up if you are upgrading from DSM 5.x; sure others with more experience can share their thought on this.

1 - With Jun's loader v1.0 and V1.01 if you are under Windows 10, after you burn the image to the flash drive the partition with the content should normally show in your file explorer. If you are in Windows 7/XP or basically anything under Windows 10 then you will need to edit the grub file in the .img file first then burn it to the flash dirve. Or if you have a MAC you can mount the EFI partition of the flash drive through a few commands that I will omit here for the sake of simplicity. I have already made a post about it so you can search the thread. 2 - If you wish to modify directly the .img file then you need to use OSFmount. Launch OSFmount, select Mount New, then select the .img to open, then select partition 0 (the one that is 30 MB). Click ok. Then at the bottom of the window make sure to untick the "Read only drive". Click ok. The EFI partition should now be mounted in file explorer. You can now edit the grub.cfg file. Save any changes you made. Done. Easy-peasy-lemon-squeezy. I shall be more specific. When I use vsphere client to deploy the ovf file, i received and error message "Failed to deploy OVF package", "IO error", etc. To test if it is hardware issue or not, I have just created a OSX vm which run beautifully. That kind of proofs my HDD and Gen8, SSD drives are normal and lead to the suspect of OVF file, or another scenario of my lack of knowledge in xpenology. Again, Thanks. Updates! I succeed and got it Xpenology setup finally. Enlighten by post from above I came across the OVF file made and shared for use in ESXi 5.5, take a shot and use it instead of the one from op, and everything setup normally without a glitch. Worth noting I am on ESXi 6.0 not 5.5, so I am not sure if there is any issue to use that OVF, but as long as it works I am very pleased now. Thank you everyone here. Superb effort guys! cheers

1 - With Jun's loader v1.0 and V1.01 if you are under Windows 10, after you burn the image to the flash drive the partition with the content should normally show in your file explorer. If you are in Windows 7/XP or basically anything under Windows 10 then you will need to edit the grub file in the .img file first then burn it to the flash dirve. Or if you have a MAC you can mount the EFI partition of the flash drive through a few commands that I will omit here for the sake of simplicity. I have already made a post about it so you can search the thread. 2 - If you wish to modify directly the .img file then you need to use OSFmount. Launch OSFmount, select Mount New, then select the .img to open, then select partition 0 (the one that is 30 MB). Click ok. Then at the bottom of the window make sure to untick the "Read only drive". Click ok. The EFI partition should now be mounted in file explorer. You can now edit the grub.cfg file. Save any changes you made. Done. Easy-peasy-lemon-squeezy. Hey Polanskimanm, it worked!!!! Thanks so much for your explanation. Now I advanced few steps further and got stuck again! Basically this time I am creating the VM on esxi 6. During my previous test run on Workstation, simply drag and drop the ds3615.ovf and synoboot.vmdk into the create new VM procedure and the vm will be all setup and ready to turn on; I had no problem there. But this time on the Gen8, the ovf + vmdk just don't work. I tried on both the web client and the downloaded vsphere client but neither create the vm successfully. Seeing many people had it worked makes me wonder if there is anything thing wrong with my machine even it is like few days old. I installed esxi 6 and updated to the latest service pack both obtained from HPE website, so they should be legit and theoretically nothing could go wrong. Really appreciate your input here. Thanks. I shall be more specific. When I use vsphere client to deploy the ovf file, i received and error message "Failed to deploy OVF package", "IO error", etc. To test if it is hardware issue or not, I have just created a OSX vm which run beautifully. That kind of proofs my HDD and Gen8, SSD drives are normal and lead to the suspect of OVF file, or another scenario of my lack of knowledge in xpenology. Again, Thanks.

1 - With Jun's loader v1.0 and V1.01 if you are under Windows 10, after you burn the image to the flash drive the partition with the content should normally show in your file explorer. If you are in Windows 7/XP or basically anything under Windows 10 then you will need to edit the grub file in the .img file first then burn it to the flash dirve. Or if you have a MAC you can mount the EFI partition of the flash drive through a few commands that I will omit here for the sake of simplicity. I have already made a post about it so you can search the thread. 2 - If you wish to modify directly the .img file then you need to use OSFmount. Launch OSFmount, select Mount New, then select the .img to open, then select partition 0 (the one that is 30 MB). Click ok. Then at the bottom of the window make sure to untick the "Read only drive". Click ok. The EFI partition should now be mounted in file explorer. You can now edit the grub.cfg file. Save any changes you made. Done. Easy-peasy-lemon-squeezy. Hey Polanskimanm, it worked!!!! Thanks so much for your explanation. Now I advanced few steps further and got stuck again! Basically this time I am creating the VM on esxi 6. During my previous test run on Workstation, simply drag and drop the ds3615.ovf and synoboot.vmdk into the create new VM procedure and the vm will be all setup and ready to turn on; I had no problem there. But this time on the Gen8, the ovf + vmdk just don't work. I tried on both the web client and the downloaded vsphere client but neither create the vm successfully. Seeing many people had it worked makes me wonder if there is anything thing wrong with my machine even it is like few days old. I installed esxi 6 and updated to the latest service pack both obtained from HPE website, so they should be legit and theoretically nothing could go wrong. Really appreciate your input here. Thanks.

Thank you Jun for developing this amazing bootloader. I recently bought a Gen8 and wanted to install xpenology to it under esxi. Prior to the actual installation I ran the same setup (ie xpenology on esxi on a virtual machine) on VMWare Workstation to experiment and it all worked fine. However when I try to do the same on the actual Gen8, I got stuck at the stage where I had to burn the bootloader to USB drive and edit the grub file. I tried 2 different computers to do the burn to usb procedure, and tried 2 different USB drive to burn to, but still not success. The problem is that after burned to the usb drive, both computers no longer can read the usb drive's content. The drive is basically not displayed on the "Computer" where you usually see all your C: D: etc. When check using Disk Manager, the USB drive does show it has 4 partitions but you cannot access it. I went and plug the USB drive to my Gen8 and it does boot up correctly and I could start the DSM setup with not problem using find.synology.com (however I didn't proceed further because I have not changed the VID PID and sata_map on the grub file yet). I suspect it was the synoboot.img file i downloaded causing all these problem, so I tried to extract it with WinRAR and osfmount (as another post here mentioned) but could not open with error saying the file may be corrupted. To verify, I downloaded the same file with different computer and even tried the v1.0 but all remain not working. Can someone point me to the right direction? I really have tried but I think the problem is something outside of my current knowledge and really want to get it sorted as I see many people have succeed and only me who faces such issue. Thanks.