ilovepancakes

Members
  • Content Count

    75
  • Joined

  • Last visited

Community Reputation

5 Neutral

About ilovepancakes

  • Rank
    Regular Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. This is a great point. One time fee would be nice for us.... but not for them. Hopefully the recurring revenue like that will allow them to improve QTS constantly and make it better, faster.
  2. I think their pricing is reasonable for the people who really are going to want to run it in a VM as opposed to buying QNAP hardware. I am also glad they did pricing for different core counts as opposed to one price for all. Although, would be nice if it could be a one time purchase rather than paying yearly especially since buying their hardware is a one time purchase. They could charge $1,000 one time fee for this and make way more than selling a box of theirs for $1,000 with the OS included for "free" already. Heck, charge one time fee for only the current major version and then charge an upgrade fee for each next major version you want after that. I *really* hope Synology follows up with DSM like this. Honestly feel like it would be a big blow to QNAP since DSM seems to be the software favorite between the two.
  3. https://www.qnap.com/solution/qutscloud-hypervisor/en-us/ While I imagine it would kill the point of Xpenology for many, would be nice if Synology follows up and does this for DSM. QNAP not only has those images for private cloud infrastructure but makes images of their OS for VPS hosting too like Digital Ocean.
  4. - Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.2.2-24922-update 4 - Loader version and model: Jun's Loader v1.04 - 918+ - Using custom extra.lzma: No - Installation type: VM - ESXi 7.0.0 - Additional comment : Reboot required. "FixSynoboot.sh" implemented after update.
  5. Anybody got this working with 1.04 and latest DSM 6.2.2? I could only get it working working with the 1.02 loader that comes with it and DSM 6.1.3.
  6. ilovepancakes

    DSM 6.2 Loader

    My guess is DSM is just trying on it's own to activate push then. This could be the result of one of the packages you have installed trying to activate push, like Chat, MailPlus, etc...
  7. ilovepancakes

    DSM 6.2 Loader

    Yes, since your install is not a genuine Synology one, DSM keeps trying to register for push notification server but it can't authorize. Do you have push notifications enabled? Turning off those boxes and disabling it from trying to register might suppress those in the log.
  8. Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.2.2-24922 Update 3 - Loader version and model: JUN'S LOADER v1.03b - DS3615xs and DS3617xs and JUN'S LOADER v1.04b DS918+ - Using custom extra.lzma: No - Installation type: VM - ESXi 6.7u3 - Additional comments: Reboot required
  9. This first method seems to have worked perfectly! Uploading a bunch of data now to fill the increased space to test if volume remains stable. I did not find that tutorial in a forum search, so thank you!
  10. @Kall So after this command I get an error that the type of array cannot have its size adjusted/expanded but if I follow the rest of the steps anyway, it all seems to work and the volume is expanded. What is this non-working command actually supposed to do and do I have any side effects of not being able to use it? EDIT: I was using JBOD mode with a single disk on the volume I tried this with. Confirming that trying this on a Basic mode volume, the above command works and returns a normal output. So I guess on JBOD volumes this command doesn't do anything. That being said, is Basic or JBOD better performing with 1 disk?
  11. Yeah I suppose this doesn't provide for easy expansion but would work. I could even backup the share with HyperBackup to a large cheap external drive and then delete the volume and make a bigger one with new VMDKs that way vSAN storage doesn't have to front all the extra space to have both VMDKs exist at same time, even temporarily. Is there any way to unofficially expand the volume after increasing the VMDK size? The disk shows new bigger size in DSM after simply increasing it in ESXi but the storage pool/volume is locked to only show the original capacity despite those underlying disks showing as bigger. Multiple DSMs in one box is certainly a reason I do it, but recovery I would say is easier if you have it all setup right. I use Veeam to backup the VM and VMDKs so if anything goes wrong at all, a few mouse clicks and DSM is completely restored to a working state. Update testing is another one, because snapshots mean I can super quickly revert back to working state if a new DSM update bricks the install. Performance on any VM I would assume is worse than the same install on bare metal but for DSM running on Dell r730xd which is what I have, the performance is so good with vSAN and 10G networking, it doesn't really matter if I get an extra couple MB/s transfer and stuff on bare metal. I also love the ability to work on DSM installs and bootloaders all remotely over a VPN since I can see the console output anywhere with ESXi, don't have to be physically at the box to change settings in Grub like SN and Mac if needed.
  12. Hi all, What is recommended config/structure in Storage Manager to allow for future expansion/increase in size of VMDK? I believe using 2 VMDKs in RAID 1 in Storage Manager will allow one VMDK to be expanded at a time and then the volume will increase but this won't work in my case because I am using vSAN so two VMDKs in RAID 1 would be a huge waste of space since each VMDK is already being made redundant by vSAN. I also get using JBOD and adding new VMDKs everytime I want to expand could work but would prefer a method of using 1 single VMDK that expands, even if the method involves a little work beyond Storage Manager. Curious for everyone's experience and input.
  13. Update: Realized that more codecs appear as you try to convert them. If hardware transcoding can't work, I'm fine with software however the transcoding quality seems way worse on 918 than my 3617 loader. I am using the same original file but when I change quality to "High" on 918 loader in Video Station, the quality is pixelated and bad, compared to changing the same video to "High" on 3617 loader where quality remains good. Any idea why 918 loader transcodes at lower quality? How can this be fixed?
  14. Just installed DSM 6.2.2 Update 3 1.04 918+. Video Station has the "hardware acceleration" box checked but videos won't transcode, the wheel just spins forever, and if I do an offline transcode it says "Error". If I uncheck hardware acceleration in Video Station settings menu, transcoding works, but even on high its poor quality and all of the codecs that I get activated on 3617 1.03 loader don't show up on this DSM. mpeg4 and hevc are missing, see below. I am using a real 918+ serial and mac pair. root@dsm-test3:/usr/syno/etc# cat /usr/syno/etc/codec/activation.conf {"success":true,"activated_codec":["h264_dec","h264_enc","ac3_dec","aac_dec","aac_enc"],"token":"2db1d7306789e41b5e3d5b0a70d702db"} I know nothing about hardware transcoding on 918, except that it supposedly can work. Do I need to do anything else to make it not return "Error" when transcoding videos? And, if there is no way for it to work, how do I get all of the codecs activated like on 3617?
  15. ilovepancakes

    DSM 6.2 Loader

    I understand there is no guarantee with future support and that who knows if Jun will even do a DSM 7 bootloader, however if I am buying some more used hardware right now for ESXi hosts what is the best CPU to get to have the best chance at continued compatibility? E5-xxxx v3 CPUs which are Haswell I think are needed to run 918 loader right? Are these going to be enough for DSM 7 too or I'll need v4 or higher CPUs?