berwhale

I went through a similar transition on an N36L a few years ago. There are some things that you need to bare in mind... Firstly, if the data is important to you and you can't afford to lose it, you should have it backed up. RAID is not a backup solution, it's designed to make your data available in the event of drive failure. It's even more important to have a backup when migrating your server operating system because of the increased risk of data loss. Secondly, the disk formats used in Windows and DSM are not compatible. The disks will need to be wiped when you move them from Windows to DSM which is another reason to have a backup. Lastly, there may be a way of 'juggling' your disks to gradually migrate between Windows and DSM. This is the approach I took, but I also had a complete copy of my data on another drive - with a 3rd copy on another drive for the really important stuff. I think the cheapest approach you could take to move to DSM safely and have a proper backup is: 1. Buy a 3TB external HDD, copy all of your data to it and keep it somewhere safe whilst you... 2. Rebuild your server with DSM. Create an SHR array using the 1TB and both 2TB drives - this will give you approx. a 3TB volume. There's no point using the 250GB drive, you might as well keep a bay free for later upgrades - this also means your current Windows installation is preserved, should you decide to go back to it. 3. Copy all your data from the external drive to the new data volume. 4. Setup DSM to backup your data to the 3TB external drive on a regular basis. Note that there are still risks with the above process. There are several times where you only have one copy of your data - if you make a mistake, you could lose everything.

Did you have a blank password? https://forum.synology.com/enu/viewtopi ... 6&t=107020

Have you used the two missing disks in another system previously? If so, you may need to clean off any existing partitions before DSM will initialize the disks... http://knowledge.seagate.com/articles/e ... Q/005929en

Are you running a vanilla install of ESXi or the HPE customized image? There was a problem with passthrough on HP servers for ESXi 5.1 and 5.5. They say it's been fixed in 6.0, but it's not clear if you have to deploy the custom image to get the fix... http://h20564.www2.hpe.com/hpsc/doc/pub ... n-uk&cc=uk I assume that you've updated the firmware on both the server and HBA?

Have you reserved all guest memory in the VM settings?

That's what I did. I tested by creating an array on bare metal with a couple of spare 1TB drives and moving them to ESXi. This worked fine, so I made sure I had everything backed up to USB drives and moved the my main array to the new server.

I'm using a card with a Marvell 88SE9215 chipset... http://eud.dx.com/product/iocrest-marve ... -844282997

Internet speed is measured in MegaBITS per second (Mbps). File transfer speed is measured in MegaBYTES per second (MBps). There are 8 bits in a byte. If you factor in an extra couple of bits for transmission overheads (headers, error correction, etc.) then you can generally divide the Mbps value by 10 to get an idea of the file transfer speed in MB per second.

What about your friends connection to the internet? What's the result of a speed test on his side, does his ISP throttle connections?

It's been a while since I've done this, but I think you can mount the .img XPEnology boot image with OSFMount and then edit the syslinux.cfg with Notepadd++ to insert SN and MAC. You can then convert the edited .img to a .vmdk using Starwind V2V Converter and boot your VM from that.

What's the link speed for your vmnic? 100Mbps @ half duplex will give you roughly 5MB/Sec...

Try setting the Max protocol for Windows file sharing to SMB2 - You'll find it under Control Panel/File Services/Advanced Settings

Some discussion of this issue here: https://forum.synology.com/enu/viewtopic.php?t=83186

Yes, assuming that the new CPU and motherboard are supported.

Glad to hear that you got it working!

ESXi doesn't need drivers if you're passing the adapter through to a guest OS. You just need to tick the checkbox next to the Marvell controller and then add the adapter to the DSM VM.

I'm running pass-through for the following reasons: 1. I needed to add SATA ports to my T20, using pass-through allowed me to purchase a cheap (£22) SATA adapter, rather than an expensive HBA with ESXi support. 2. I wanted to migrate an existing 4 drive array from a bare metal install to ESXi, connecting the drives to a dedicated adapter and passing that through just worked - DSM isn't even 'aware' that it's been virtualized - everything works exactly as it did before moving the disks. As for performance, I can't really comment. The Xeon in the T20 is an order of magnitude faster than the Celeron SoC in my old bare metal server, DSM and Plex just fly on the new box.

I'm not familiar with running DSM in VirtualBox, but make sure that the boot disk is 'non-persistent' (i.e. changes to the disk are not saved after VM powerdown), power off the DSM VM after install has completed and power it on again (rather than let it reboot itself). Reason: DSM formats all drives during install, including the boot drive - you have to make it non-persistent to reverse the format and restore the boot image.

I migrated my SHR array from bare metal to DSM running under vSphere 6.0 on the hardware in my signature. I didn't lose any data or users or applications settings or anything else. They key is to pass-through a SATA controller to DSM using VMDirectPath IO and connect the array to that - that way the virtualized DSM pickups up all the personality that's stored on the existing array. The Xeon in my T20 supports VMDirectPath I/O (which is why I bought it); unfortunately, I think you might be out of luck with your i3... Intel® Virtualization Technology for Directed I/O (VT-d) ‡ No From: http://ark.intel.com/products/65693/

Firstly, make sure that you set the boot drive to Independent and non-persistent. The boot drive gets wiped during the DSM install - making it non-persistent means that ESXi will undo the wipe after powering off the VM. I see that you're trying to warm reboot after the install, this doesn't give ESXi a chance to undo the wipe, so it's trying to boot of a wiped disk. If you power down the VM at this point and restart, you should find that it works just fine (assuming that you've setup the boot drive correctly).

Updated a test installation of DSM on ESXi, update worked fine from Control Panel.

In general, upgrading the firmware should have no effect. However, I'd keep a copy of the old firmware to be safe. I've never had to downgrade firmware due to incompatibility on a PC and I've been building my own since 1990. I have encountered problems on enterprise servers, generally with FW versions for HBAs and NICs, but the Microserver is closer to a home PC than one of these beasts.

AC3 is fine for plex. Really depends on what you are playing it back on though. I read the passmark to transcode one HEVC stream could be 6000 to 7000. I have a xeon 2630lv3 and it maxes out for a minute or two the falls back to around 50% the remaining time for my x265 stuff. I could probably only do 2 streams if I'm lucky with x265, but x264 could be 5 plus. Some clients can play back x265 without transcoding. Like the Roku 4 or Google Nexus TV. Plex server running on Nvidia Shield TV will transcode H265(HEVC) to H264 using hardware acceleration... https://support.plex.tv/hc/en-us/articl ... DIA-SHIELD That's pretty impressive for a box that was selling for less than £100 recently (Amazon Prime Day).

If you only want one drive and just want to transcode media in Plex, then an Nvidia Shield TV + external HDD might be your best option... https://shield.nvidia.co.uk/android-tv/media-server https://www.plex.tv/apps/tvs-consoles/nvidia-shield/

If it's a T20 server, then it came with ECC (Error Checking and Correcting) RAM. ECC RAM uses Hamming codes to detect 1 and 2 bit errors and correct 1 bit errors (2 bit errors are flagged to the CPU and the server will halt). Errors could be caused by faulty RAM or cosmic rays passing through the RAM chips and flipping bits randomly. This has implications when testing the RAM. For example, MEMTEST86 has to be set to ECC mode to test ECC RAM, otherwise the RAM could 'fix itself' before MEMTEST86 can detect any issue.