Jump to content
XPEnology Community

Tutorial: Install DSM 7.x with TinyCore RedPill (TCRP) Loader on ESXi


flyride

Recommended Posts

Polanskiman
This post was recognized by Polanskiman!

flyride was awarded the badge 'Great Content' and 5 points.

Introduction

 

This tutorial is a supplement to the main TCRP installation tutorial located here:

https://xpenology.com/forum/topic/62221-tutorial-installmigrate-to-dsm-7x-with-tinycore-redpill-tcrp-loader/

 

You should be familiar with all the concepts and procedures in that tutorial, and general knowledge of VMware ESXi installation and virtual machine management. The focus here is on differences between installing on baremetal (with DSM as the only OS on the NAS), and as a virtual machine using VMware ESXi as the hypervisor. However, much of the conceptual information applies to other hypervisors.

 

Some reasons to install DSM using a hypervisor:

  • virtualize unsupported network card
  • virtualize NVMe or other storage and present to DSM as SATA
  • run other VMs in parallel on the same hardware (as an alternative to Synology VMM)
  • share storage or network cards with other non-XPEnology VMs
  • testing and rollback of updates

About VMware ESXi

 

ESXi (currently branded as the "VMware vSphere Hypervisor") is a stand-alone hypervisor that is part of the VMware enterprise computing platform. ESXi's strength includes robust testing and support, good compatibility with modern hardware platforms, and very flexible control over the hypervisor configuration.

 

The core hypervisor is free to use, all that is needed is to sign up to receive a lifetime free license key. Key limitations of the free license are 8 vCPU's (8 threads, same as DS918+) and no serial port virtualization. To use the serial console, a physical connection is needed from the motherboard to your personal computer, or if the motherboard has IPMI features, intercepting the physical serial data with the IPMI remote access tools works as well.

 

There is also a trial ESXi license that offers 256 vCPUs and serial port virtualization.

 

ESXi and DSM Platform/Architecture

 

All currently supported DSM platforms can run as virtual machines. As of this writing, the Device Tree platforms (DS920+ and DS1621+) are not supported by the TCRP device tree patcher when ESXi virtual SATA controllers are used. The problem is understood but currently the only way to make these platforms work is to manually patch the DTS.

 

Transcoding platforms are supported with a compatible CPU, but actual transcoding requires a passthrough configuration of the VGA display adapter, which is somewhat complicated to set up, and beyond the scope of a basic tutorial.

 

As DSM is run as a workload inside ESXi, there is an overhead tax, so the minimum requirements are somewhat higher:

  • x86-64 CPU with two cores or more
    • Hardware virtualization features enabled in the BIOS (Intel VT-x or AMD RVI)
  • 4GB of RAM or more
  • Dedicated 138GB or larger boot and storage device for ESXi system files, run-time files and datastore containing VM configuration files and virtual disks
  • Block storage/controllers on ESXi's compatibility list OR compatible with DSM for passthrough
  • Storage for use with DSM (either as backing storage for virtual disks, or passthrough devices)

Creating a DSM Virtual Machine, Part 1

 

When we create a virtual machine we are defining its hardware characteristics. This machine must be compatible with DSM. For the purposes of the tutorial, we'll create a simple DSM VM with a 21GB virtual SATA drive. 

 

First the hardware profile must be selected. The recommended options are illustrated below. Other 3.x Linux (64-bit) is best even when installing a DSM platform with 4.x kernel. The selection here doesn't actually have anything to do with the OS being installed - it's just defining the behavior of the emulated hardware.

 

image.thumb.png.2155a1d1bf989a0607a41b5a79cbd3d8.png

 

Here's the initial complement of hardware created with Other 3.x Linux (64-bit):

 

image.thumb.png.15924444446b25306bcb7f7a536e7758.png

 

The pre-configured Network Adapter is VMware 10Gbe virtual vmxnet3 and is directly supported by TCRP.

 

However, some changes need to be made to the virtual machine:

  • Change the CPU vCore count to 2 or more
  • Change the memory amount to 2048 or more
  • Change the virtual hard disk size to 21GB or larger (see minimum spec here)
    • If desired, open the drop-down menu and change the virtual disk type to Thin if the VM is only for testing
  • Delete the USB controller
  • Delete the CD/DVD Drive
  • Add a second SATA controller - this will initially be called "New SATA Controller"

Save the virtual machine. This creates a virtual machine folder on the datastore, and provisions the VM configuration file and virtual disk in that folder.  It is not ready for use yet; some additional preparatory steps need to be completed.

 

Preparing the TCRP Image

 

ESXi VMs cannot boot virtualized USB flash drive images. A passthrough physical USB can be used, but is not recommended. Instead, a special version of the loader is used as a bootable virtual SATA drive. When the TCRP loader boots in this manner, it is called SATABOOT.

 

Download the tinycore-redpill 7.x loader and save it to your personal computer. Then, open it with a zip manager to show the boot images:

 

tinycore-redpill.vX.X.X.img.gz                    (for BIOS/CSM/Legacy boot from USB flash drive)
tinycore-redpill-uefi.vX.X.X.img.gz            (for UEFI/EFI boot from USB flash drive)
tinycore-redpill.vX.X.X.vmdk.gz              (for virtual machine SATABOOT from disk image)

 

Save the vmdk gzip file to your personal computer. Then, upload it to the new virtual machine folder contained in the datastore:

 

image.thumb.png.58f3760c887a85a63016f22082e38c4d.png

 

For the next step, ESXi console access is required. From the web GUI, enable both SSH and the console shell.

 

image.thumb.png.5a13193ef3923fbe24a3e6a6670c0a3f.png

 

SSH into the ESXi host and navigate to the new VM's folder:

 

[root@esxi:] cd /vmfs/volumes
[root@esxi:] cd <datastore>
[root@esxi:] cd MyNewNAS
[root@esxi:] ls -la
total 65664
drwxr-xr-x    1 root     root         73728 May 28 09:02 .
drwxr-xr-t    1 root     root         81920 May 28 08:58 ..
-rw-------    1 root     root     22548578304 May 28 08:58 MyNewNAS-flat.vmdk
-rw-------    1 root     root           474 May 28 08:58 MyNewNAS.vmdk
-rw-r--r--    1 root     root             0 May 28 08:58 MyNewNAS.vmsd
-rwxr-xr-x    1 root     root          1941 May 28 08:58 MyNewNAS.vmx
-rw-r--r--    1 root     root      65260813 May 28 09:02 tinycore-redpill.v0.4.6.vmdk.gz

 

The TCRP SATABOOT image is provided compressed and in VMware Workstation format. These commands prepare it for use with ESXi:

 

[root@esxi:] gunzip tinycore-redpill.v0.4.6.vmdk.gz
[root@esxi:] vmkfstools -i tinycore-redpill.v0.4.6.vmdk MyNewNAS-TCRP.vmdk
Destination disk format: VMFS zeroedthick
Cloning disk 'tinycore-redpill.v0.4.6.vmdk'...
Clone: 100% done.

 

Creating a DSM Virtual Machine, Part 2

 

From the GUI console, select the DSM virtual machine and Edit. This is what things look like now:

 

image.thumb.png.56cc3a40732f536f94aee75a1eb30039.png

 

Now the SATABOOT loader must be added to the virtual machine. 

  • Select Add hard disk (existing hard disk) and choose the TCRP vmdk created in the previous step
  • It will be displayed as "New hard disk" - expand the dropdown
    • Change the controller to SATA Controller 0
    • The disk address should be SATA0:0
  • Save the changes to the VM

The default for the Other 3.x Linux (64-bit) hardware profile is to create a SCSI virtual controller and attach all new virtual disks to it. DSM works better with the virtual SATA controller, so we need to move the DSM virtual data disk to it.

  • Edit the virtual machine
  • Expand the dropdown for Hard disk 1 (note that it is 21GB or whatever size we selected)
    • Change the controller to SATA Controller 1
    • The disk address should be SATA1:0
  • Save the changes to the VM

VMWare has an odd behavior in that it renumbers all the hard disks based on the last edit. This is cosmetic, and only affects the VM configuration screen. It does not change the disk addressing order in any way. The VM edit window now looks like this:

 

image.thumb.png.fb211326009089ac0ce9bbb6dde23897.png

 

Now that no disks are attached to the SCSI controller, we can (and should) delete it. 

 

The final configuration of controllers and disks is:

SATA Controller 0: SATABOOT (SATA0:0)

SATA Controller 1: DSM Data DIsk (SATA1:0)

 

Any additional virtual DSM data disks should be added to SATA1 (i.e. SATA1:1, SATA1:2, etc).

SATA0 should be reserved only for SATABOOT.

 

The VM is now ready for the TinyCore boot (main tutorial, Step 3).

 

System-Specific Parameters and SATABOOT

 

ESXi requires minor adjustments to the basic tutorial configuration steps:

  • The USB flash drive VID/PID configuration step (./rploader.sh identifyusb) is invalid and can be skipped when using SATABOOT.
     
  • When using a virtual network adapter (such as VMXNET 3), its MAC address and the loader's MAC address setting must match.  When a virtual machine is booted for the first time, a random address is assigned to each virtual adapter. Unless your primary network interface is a passthrough device, the serialgen configuration step requires the realmac argument to match the virtual NIC's random address to TCRP. Example:
    ./rploader.sh serialgen DS3622xs+ realmac

     

  • The Drive Slot Mapping configuration step is the same, but the outcome is different when SATABOOT is in use.
    • ./rploader.sh satamap will enforce the prohibition on data disks attached to SATA0 and warn if this configuration exists.
    • SataPortMap and DiskIdxMap are configured to remove a blank slot between the SATA0 and SATA1 controllers.
    • SCSI/SAS controllers or HBAs (either passthrough or virtual) ignore satamap functionality. When SATABOOT is also in use, there is an unavoidable blank slot between the last SATA controller and the first SCSI/SAS controller or HBA.

Boot DSM with GRUB

 

When the GRUB Menu is displayed: if necessary, use the arrow keys to ensure that SATA is selected and press ENTER.

image.png

 

Advanced Configuration Examples: Passthrough and Raw Device Mapping (RDM)

 

Spoiler

While not needed for a basic tutorial on how to configure DSM via TCRP on ESXi, passthrough and RDM are important tools that may be factors in the decision to use ESXi (or another virtualization platform). The ability to mix virtual and physical resources within the same virtual machine is an incredibly powerful tool that can solve many problems.

 

Passthrough attaches a physical hardware device to a virtual machine, giving it exclusive access. The virtual SATA controllers and virtual network controller in the configuration example above are software fabrications, emulating the behaviors of real devices. But we can also "pass through" a real, physical PCI device by identifying it, reserving it, and then attaching the device to the VM. This is set up with the Manage tab under the ESXi host. For example, a Mellanox ConnectX-3 10Gbe network adapter is reserved.

 

image.thumb.png.9556b80eb4f6455888c93af6c49c7c03.png

 

Then the NIC is attached to a virtual machine by editing the VM configuration, and adding a PCI device.

 

image.thumb.png.e7c71fb4be00041a545567b18daebfe2.png

 

The Mellanox NIC now can ONLY be used by that virtual machine. DSM must be able to directly support the passthrough device with internal drivers, because ESXi is no longer involved.

 

When a disk controller (such as an motherboard embedded SATA controller or a SCSI HBA) is passed through, all the attached disks pass through with it and are not visible to or shareable by ESXi. Passthrough of the disk controller is a practical method for a full XPEnology conversion from baremetal to virtualized, as a virtualized DSM will then see the disks in the exact same condition as the baremetal system. Disk controller passthrough also maximizes DSM's SATA drive management technology, and performance with a multi-disk array.

 

Raw Device Mapping (RDM) blends virtual and physical characteristics for block storage (drives). With a passthrough disk controller, all drives attached to that disk controller are no longer available to ESXi or other VMs. Functionally, RDM acts as a passthrough for an individual drive, while the controller and the other drives attached to that controller can remain managed and shared under ESXi. In reality, RDM is a virtualization and translation/emulation layer. It appears to offer direct access to the disk hardware, but ESXi remains active managing the real device in the background.

 

Once configured, a RDM drive can then be attached to the DSM virtual machine and presented in any form that is needed. This can be very useful!  For example, when a NVMe SSD is configured with Raw Device Mapping and attached to a virtual SATA controller, it appears to DSM as a SATA device, which can then be used as regular storage within Storage Manager.

 

There is no GUI configuration for RDM. This VMware article explains how to create a local raw device mapping from the console shell command line, which results in a virtual disk pointer in the VM folder. Here's the example of creating an RDM for an attached NVMe drive:

 

[root@esxi:] cd /vmfs/volumes
[root@esxi:] cd <datastore>
[root@esxi:] cd MyNewNAS
[root@esxi:] ls -l /vmfs/devices/disks
-rw-------    1 root     root     2000398934016 May 30 09:03 t10.NVMe____INTEL_SSDPE2MX020T4_CVPD609542HM2P0TGN__00000001
-rw-------    1 root     root     2000398934016 May 30 09:03 t10.NVMe____INTEL_SSDPE2MX020T4_CVPD6123403F2P0TGN__00000001
[root@esxi:] vmkfstools -z /vmfs/devices/disks/t10.NVMe____INTEL_SSDPE2MX020T4_CVPD609542HM2P0TGN__00000001 nvme0.vmdk
[root@esxi:] ls -la
total 65664
drwxr-xr-x    1 root     root         73728 May 28 09:02 .
drwxr-xr-t    1 root     root         81920 May 28 08:58 ..
-rw-------    1 root     root     22548578304 May 28 08:58 MyNewNAS-flat.vmdk
-rw-------    1 root     root           474 May 28 08:58 MyNewNAS.vmdk
-rw-r--r--    1 root     root             0 May 28 08:58 MyNewNAS.vmsd
-rwxr-xr-x    1 root     root          1941 May 28 08:58 MyNewNAS.vmx
-rw-------    1 root     root     2000398934016 Jan 20 13:56 nvme0-rdmp.vmdk
-rw-------    1 root     root           534 May 12 17:33 nvme0.vmdk
-rw-r--r--    1 root     root      65260813 May 28 09:02 tinycore-redpill.v0.4.6.vmdk.gz

 

Now the RDM drive can be attached to the VM with Add New Hard Disk (existing) just like the TCRP loader image.

 

image.thumb.png.e2e96051883ff1683bef292c004d1122.png

 

Finally, the RDM drive is then assigned to a virtual SATA controller:

 

image.thumb.png.b8f32f008f8685f54c95b9992121d880.png

 

And now the NVMe drive appears to DSM as regular SATA storage

 

image.thumb.png.2c2f1fcaa549c74fa43f717ebcd6638e.png

 

CAUTION: Because of the virtualization layer, TRIM may not be supported across device types.
Test with a non-production workload prior to enabling TRIM with RDM.

 

  • Like 9
  • Thanks 2
Link to comment
Share on other sites

About the nic card , like the mellanox you quote, was it you pass it and it appear directly as an extra nic ? Like on ds918 we put 2 nic as per the system, then adding the pci nic will give a 3 nic in 'autodetect' mode ..  Or it should be done manually or set the mac id somewhere.. ?

  thanks and indeed good guide

Link to comment
Share on other sites

19 minutes ago, docop1 said:

About the nic card , like the mellanox you quote, was it you pass it and it appear directly as an extra nic ? Like on ds918 we put 2 nic as per the system, then adding the pci nic will give a 3 nic in 'autodetect' mode ..  Or it should be done manually or set the mac id somewhere.. ?

  thanks and indeed good guide

 

It is no different than if you inserted a card into baremetal system.  DS918+ has 2 NICs maximum as a platform default.  So on that platform, to support more cards (or multi-port cards), add maxlanport to user_config.json and set it to match the NIC count. MAC id does not explicitly need to be set; its purpose is to 1) ensure uniqueness among DSM instances, and 2) enable Wake-On-LAN features if you want to use them.

Link to comment
Share on other sites

If you passthrough the NIC, DSM must have a driver to support it. Again, no different than baremetal.

Alternatively, if ESXi has internal driver support for the card and DSM doesn't work with it, you can just provide the VM a vmxnet3 interface.

 

The point is that you have the choice.

Link to comment
Share on other sites

Hi, I am trying to get it running on ESXI 7.0 Update 1. Building at the end by using command: "./rploader.sh build apollolake-7.1.0-42661 manual"

All steps done as per instruction and VM settings are all the same except NIC is VMXNET3. However by checking optional drivers I do have it installed.

After booting up with SATA option, it does not get IP address. I see on the router that device 00:11:32:2b:fa:64 shows up on the network, but it does not ask DHCP for IP.

 

Result of command: ./rploader.sh listmods apollolake-7.1.0-42661 :

 

It looks that you will need the following modules :


Found IDE Controller : pciid 8086d00007111  Required Extension :
No matching extension
Found VGA Controller : pciid 15add00000405  Required Extension : vmwgfx
Searching for matching extension for vmwgfx
Found SATA Controller : pciid 15add000007e0  Required Extension :
No matching extension
Found SATA Controller : pciid 15add000007e0  Required Extension :
No matching extension

 

[#] Checking runtime for required tools... [OK]
[#] Adding new extension from https://raw.githubusercontent.com/pocopico/rp-ext/master/vmxnet3/rpext-index.json...
[#] Downloading remote file https://raw.githubusercontent.com/pocopico/rp-ext/master/vmxnet3/rpext-index.json to /home/tc/redpill-load/custom/extensions/_new_ext_index.tmp_json
######################################################################## 100.0%

[!] Extension is already added (index exists at /home/tc/redpill-load/custom/extensions/pocopico.vmxnet3/pocopico.vmxnet3.json). For more info use "ext-manager.sh info pocopico.vmxnet3"

*** Process will exit ***
Found Ethernet Interface : pciid 15add000007b0 Required Extension : vmxnet3
Searching for matching extension for vmxnet3
Found matching extension :
"https://raw.githubusercontent.com/pocopico/rp-ext/master/vmxnet3/rpext-index.json"

 

 

Do I need to install SATA extension? This is the only part I suspect, something is wrong.

Link to comment
Share on other sites

On 6/4/2022 at 2:42 PM, mhl07 said:

Ok, I figured out what I am missing... After creating a build a I had to copy MAC address into VMXNET3 card in ESXi.

 

Yes, there are circumstances that require this.  A better solution is to use the "realmac" argument in the MAC assignment during the loader creation.  @Acidflash this is probably your issue as well. The tutorial has been amended to assist the user with this decision.

Link to comment
Share on other sites

Hello @flyride

 

Thank you for your instruction. I successfully install the 7.1 on ESXi 7 and migrate DSM from 6.x to it. I have a question about disk order/number. I have a SAS controller LSI-9211-8i in passthrough mode. on DSM 6.1 they are from number 1 to 8 and now they are from 3 to 10 as I set sata0:0 as boot and sata1:0 as data. Is it possible to move the sas disk to the first 8 drives? I searched everywhere and didn't find the clear instructions how to do it.

Link to comment
Share on other sites

Il y a 1 heure, aerolite a dit :

Hello @flyride

 

Thank you for your instruction. I successfully install the 7.1 on ESXi 7 and migrate DSM from 6.x to it. I have a question about disk order/number. I have a SAS controller LSI-9211-8i in passthrough mode. on DSM 6.1 they are from number 1 to 8 and now they are from 3 to 10 as I set sata0:0 as boot and sata1:0 as data. Is it possible to move the sas disk to the first 8 drives? I searched everywhere and didn't find the clear instructions how to do it.

 

Hello @aerolite i want to migrate my dsm 6.x on esxi 6.7 to 7.1 but i'm a bit worried to do it. Can you write me a summarize of your step especially to migrate RDM disks ? 

 

thx

Link to comment
Share on other sites

Hi @gis70

 

Here is what I did.

 

1, install a brand new DSM 7.x with this instruction.

2, backup the data for my old DSM 6.x and shut it down

3, passthrough my LSI-9211-8i to new DSM 7.x and follow web interface to finish the migration.

 

now I have the above mentioned disk order problem, even through the data is there.

 

Hope the above help.

Link to comment
Share on other sites

9 hours ago, aerolite said:

Thank you for your instruction. I successfully install the 7.1 on ESXi 7 and migrate DSM from 6.x to it. I have a question about disk order/number. I have a SAS controller LSI-9211-8i in passthrough mode. on DSM 6.1 they are from number 1 to 8 and now they are from 3 to 10 as I set sata0:0 as boot and sata1:0 as data. Is it possible to move the sas disk to the first 8 drives? I searched everywhere and didn't find the clear instructions how to do it.

 

What you have described suggests that you have set the SATA1 controller up with two ports - i.e. SataPortMap=12 and DiskIdxMap=1000 (or 100002)

With RedPill, there will always be a gap from the last SATA controller to the first HBA device. You could delete your SATA1:0 controller and attached virtual disks(s) and then rebuild the loader with SataPortMap=1 - then your HBA would start at port 2. That's the best on ESXi unless you want to passthrough a real USB flash drive and boot from that.

Link to comment
Share on other sites

4 hours ago, flyride said:

 

What you have described suggests that you have set the SATA1 controller up with two ports - i.e. SataPortMap=12 and DiskIdxMap=1000 (or 100002)

With RedPill, there will always be a gap from the last SATA controller to the first HBA device. You could delete your SATA1:0 controller and attached virtual disks(s) and then rebuild the loader with SataPortMap=1 - then your HBA would start at port 2. That's the best on ESXi unless you want to passthrough a real USB flash drive and boot from that.

 Thank you @flyride for the clarification. I just wonder if we can put the HBA devices in front of SATA. it looks like we need to live with it this way. Thank you again for the instruction.

Link to comment
Share on other sites

  • 4 weeks later...
On 6/15/2022 at 10:46 PM, flyride said:

 

What you have described suggests that you have set the SATA1 controller up with two ports - i.e. SataPortMap=12 and DiskIdxMap=1000 (or 100002)

With RedPill, there will always be a gap from the last SATA controller to the first HBA device. You could delete your SATA1:0 controller and attached virtual disks(s) and then rebuild the loader with SataPortMap=1 - then your HBA would start at port 2. That's the best on ESXi unless you want to passthrough a real USB flash drive and boot from that.

@flyride, does this mean that the 21GB disk is now attached SATA 0 controller - as Sata 0:1? I have this exact setup and trying to understand what deleting SATA 1 controller means :)

Edited by urundai
Link to comment
Share on other sites

7 hours ago, urundai said:

@flyride, does this mean that the 21GB disk is now attached SATA 0 controller - as Sata 0:1? I have this exact setup and trying to understand what deleting SATA 1 controller means :)

 

Most of the ESXi XPe tutorials suggest that the user installs a virtual disk as an example device, separate from the loader vmdk.  Maybe you want to use a virtual disk in your installation, and maybe you would rather use a passthrough controller.  It is not always clear and often people install the virtual disk when it isn't necessary.

 

Because we map the loader vmdk away (with SataPortMap=10 and DiskIdxMap=1) that causes the vmdk to be assigned outside of the addressable port range (assuming 16 ports).  Any SATA devices on that same controller (SATA0) would be similarly not addressable, so we ask the user to add a second SATA controller (SATA1) for the virtual disks (or RDM devices) to be attached to.  Those are then addressed at the beginning of the port range (SataPortMap=1000 and DiskIdxMap=1n, where n is the number of virtual disks).

 

In @aerolite's case, they did not need a "21GB" virtual disk because data drives were being delivered via LSI HBA but it appears they had created one and set up the virtual controller as above.  Non-SATA ports tack onto the end of whatever SATA ports are reserved by SataPortMap/DiskIdxMap.  So they were asking how to get the starting port for the HBA back to the beginning of the range.

 

Therefore, since they do not need the 21GB disk it can be deleted, the SATA1 controller also deleted, and SataPortMap and DiskIdxMap adjusted.  With no SATA devices in the system (aside from the loader vmdk) then SataPortMap=1000 and DiskIdxMap=1.  Unusually, the last SataPortMap 00 is required so that the HBA knows where to start addressing its ports.  Unfortunately, there is an anomaly exhibited with TCRP/DSM7/HBA's that causes a single port gap between the last SATA disk and the first HBA disk.  I haven't figured out how to make that go away outside of a device tree configuration.

  • Like 1
Link to comment
Share on other sites

3 hours ago, flyride said:

 

Most of the ESXi XPe tutorials suggest that the user installs a virtual disk as an example device, separate from the loader vmdk.  Maybe you want to use a virtual disk in your installation, and maybe you would rather use a passthrough controller.  It is not always clear and often people install the virtual disk when it isn't necessary.

 

Because we map the loader vmdk away (with SataPortMap=10 and DiskIdxMap=1) that causes the vmdk to be assigned outside of the addressable port range (assuming 16 ports).  Any SATA devices on that same controller (SATA0) would be similarly not addressable, so we ask the user to add a second SATA controller (SATA1) for the virtual disks (or RDM devices) to be attached to.  Those are then addressed at the beginning of the port range (SataPortMap=1000 and DiskIdxMap=1n, where n is the number of virtual disks).

 

In @aerolite's case, they did not need a "21GB" virtual disk because data drives were being delivered via LSI HBA but it appears they had created one and set up the virtual controller as above.  Non-SATA ports tack onto the end of whatever SATA ports are reserved by SataPortMap/DiskIdxMap.  So they were asking how to get the starting port for the HBA back to the beginning of the range.

 

Therefore, since they do not need the 21GB disk it can be deleted, the SATA1 controller also deleted, and SataPortMap and DiskIdxMap adjusted.  With no SATA devices in the system (aside from the loader vmdk) then SataPortMap=1000 and DiskIdxMap=1.  Unusually, the last SataPortMap 00 is required so that the HBA knows where to start addressing its ports.  Unfortunately, there is an anomaly exhibited with TCRP/DSM7/HBA's that causes a single port gap between the last SATA disk and the first HBA disk.  I haven't figured out how to make that go away outside of a device tree configuration.

Thank you @flyride. I had my DSM installed on the HBA disks and I was little confused by the tutorial as well. I wasn't sure if there were particular benefits to installing on VMDK vs directly using the devices.

 

I have decided to go back to my original model and deleted SATA 1 controller and the vmdk. I am all good now.

 

Thanks for the great tutorial, it was spot on and helped me immensely.

Link to comment
Share on other sites

I've been successfuly running DSM 6.2.3 on the DS3615xs platform as a VM on ESXi7 with Jun's bootloader and a single RDMed hard drive for a while now and was wondering if there was any consensus on whether TCRP was stable enough to migrate one's data to it.

 

If so, would a best practice be to first get DSM 7.1.0 up and running with a virtual disk as the target drive and then add the RDMed drive (and then optionally removing the virtual drive) or would that mess up the sata diskmap generation process that is done in TCRP?

 

If I use the DS918+ platform instead of DS3615xs, would I be able to retain the data on the RDMed drive?

 

Thanks

Link to comment
Share on other sites

24 minutes ago, unmesh said:

I've been successfuly running DSM 6.2.3 on the DS3615xs platform as a VM on ESXi7 with Jun's bootloader and a single RDMed hard drive for a while now and was wondering if there was any consensus on whether TCRP was stable enough to migrate one's data to it.

 

The unusual situation with RedPill compared with Jun's loaders is that many different parties are always tinkering and improving it.  So there is always code that is untested/alpha if you want to try it. 

 

The stickied links in the FAQ and Tutorials (such as this) refer to the code and procedures that are part of "stable" TCRP which is deliberately frozen with the idea that it would remain stable and predictable.  There are things about DSM 7 that are more finicky than DSM 6, but TCRP is more flexible in how it can be configured.

 

If you are chasing the latest stuff on every dev thread, good luck to you.

 

28 minutes ago, unmesh said:

If so, would a best practice be to first get DSM 7.1.0 up and running with a virtual disk as the target drive and then add the RDMed drive (and then optionally removing the virtual drive) or would that mess up the sata diskmap generation process that is done in TCRP?

 

Best practice would be the testing and migration procedure specifically outlined in the tutorial here:

https://xpenology.com/forum/topic/62221-tutorial-installmigrate-to-dsm-7x-with-tinycore-redpill-tcrp-loader/

 

29 minutes ago, unmesh said:

If I use the DS918+ platform instead of DS3615xs, would I be able to retain the data on the RDMed drive?

 

Yes, the migration install doesn't require the platforms to be identical.

Link to comment
Share on other sites

Thanks for the quick reply. I had looked at the referenced thread (and will read it more carefully) but wasn't sure how much of it applied to an installation over ESXi.

 

I don't want to be on the bleeding edge but it seems like DSM 6 has stalled out at 6.2.3 for 3rd party hardware

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...