ilovepancakes

Members
  • Content Count

    153
  • Joined

  • Last visited

  • Days Won

    2

ilovepancakes last won the day on July 8 2021

ilovepancakes had the most liked content!

Community Reputation

25 Excellent

About ilovepancakes

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. That's a good point and I believe correct. If I take a virtual disk used under a vSATA controller and move it to vSCSI controller, it will still be accessible. The only thing I thought that made SCSI more performant when virtualized is a more performant driver, like Vmware Paravirtual SCSI. But, if performance really is the same or so similar, it doesn't matter to me with DSM. It isn't like I'm running a giant database or 1,000 users trying to access and write/read at same time. There definitely are performance gains in other operating systems when using PVSCSI for example over vSA
  2. Thanks for the insight. I agree it isn't a "problem" with Redpill itself other than simply not being supported/coded (to make the SMART data shim work on virtual SCSI/SAS drives like Redpill does with SATA. That being said, on 1.04b 6.2.x I have used virtual SCSI disks in ESXi as the main DSM drives and have had 0 issues with them. The only reason I did this is because from my beginning days with Xpenology, I thought everyone would always say the virtual SCSI disks would be more performant than virtual SATA, especially with Vmware Paravirtual SCSI ones since that is made specifical
  3. Now that Redpill loaders for DSM 7 can be reliably created (thanks to many recent contributions from @haydibe, @pocopico, others, and of course @ThorGroup's original code which was very well organized for others to understand), I am trying to focus down on some stability bugs for typical use cases, namely related to running Redpill DSM 7 on ESXi based virtual machines. I'm experiencing an issue where using SCSI based virtual disks (with virtual LSI SAS or Vmware PVSCSI controllers) isn't working properly within DSM, and first off I am curious if anyone else experiences the same sym
  4. In latest version Poco preset the password to: P@ssw0rd
  5. Tested, doesn't work on ESXi. Without Vmware tools or open-vm-tools installed, etc... it greys out the option to shutdown or restart the guest VM. Pretty sure those two options in ESXi work differently than typical ACPID events anyway. Was worth a shot.
  6. Yep... and would be great if TTG really is gone (still holding out hope though) to better organize efforts amongst community devs who are capable of continuing the project in various ways.
  7. Ohh I was under the impression that only works with Proxmox and not ESXi, will have to try it out later. Agreed if this does shutdown and restart on ESXi, then IP address display isn't as important. Do you have the package/code anywhere on github for others to test with? Weird restart doesn't work if shutdown does... and I'm assuming it doesn't show IP address in ESXi at all?
  8. Could open-vm-tools somehow be implemented as a Redpill extension? It seems it can't be installed the conventional way (DSM Package) used in DSM 6.2 because DSM 7 doesn't allow packages to run as root, which seems to be needed for open-vm-tools to work 100%. This would allow data (IP address, etc.) to be passed from DSM to ESXi based installs and would allow ESXi VM Guest shutdown/restart features to work.
  9. I appreciate the compile option being there nonetheless as sometimes it's nice to be able to compile something ourselves completely from scratch, for security. Although I suppose we could still compile rp-lkm manually and just use the .ko output from that to be the static module used rather than yours. I'm impressed with the ease of use now to generate a loader. I did it via SSH as on ESXi for some reason the mouse doesn't work when trying to use the GUI. I only tried with a USB 3.1 controller added to the VM maybe it only works with USB 2.0 or something. Now to try and fix that pe
  10. Copy that. And upon changing that entry and downloading the modules file for correct matching of extensions, running the script seems to have worked flawlessly using the static rp-lkm option. Didn't try compile option yet. Well done!
  11. The ID "bromolow-7.0.1-42218" on the custom_config.json included with the repo seems to reference jumkey's master branch, but isn't 7.0.1 included on jumkey's develop branch only?
  12. Nice job on this project! When running on ESXi using a PV SCSI controller, I get the following from the auto detection attempt for modules. Found SAS Controller : pciid 15add000007c0 Required Extension : No matching extension What is your preferred approach to add that pciid to be associated with your vmw_pvscsi extension? You want to add/control them or should we open pull requests on github?
  13. Thanks for the article, that helped me sort out the disk order/getting all disks to show up. But, it didn't solve the issue of virtual SCSI disks being wonky in DSM. I'll start by saying that SATA virtual disks with redpill continue to work fine and reliably. Using your extension for vmw_pvscsi (or mptsas) I am able to get virtual SCSI disks to show up in DSM. Attaching a few screenshots to walk through the issue. Here we can see all disks attached. Loader VMDK is Drive 1 (hidden when redpill SATA boot option is used instead of USB) and a test SATA virtual disk is Drive 2 on the sam
  14. So that helped sort of. Using vmw_pvscsi virtual disks, I can get them to show up in DSM. BUT, If I use DiskIdxMap=0A00 and SataPortMap=58 (with the loader on SATA 0:0 and first data disk on SCSI 0:0) the loader disk doesn't show up at all, which is fine and normal with SATA boot entry on RedPill. And the single SCSI data disk shows up as "Drive 6" in DSM. If I change the SataPortMap to equal just "1" the SCSI virtual disk moves to "Drive 2" on DSM. This is all fine so far. But here is where it gets weird. If I add additional virtual disks to the same SCSI controller, they show up