Jump to content
XPEnology Community

Cannot migrate data after building new 6.2 VM


SirIanthe3rd

Recommended Posts

If you happen to be editing the hardware configuration of the VM, it may be reordering the PCI addresses of the devices from boot to boot.

 

Let's regroup on this as I am losing track of the system state due to changes:

Try: SataPortMap=1 DiskIdxMap=0C00

 

This is not technically correct but should work for most unknown configurations.

Link to comment
Share on other sites

Do me a favor, in ESXi, modify the SATA Controller 0 then save. Then modify the SATA Controller 1, then save.  Finally remove and add the passthrough HBA.

See if that changes anything.   

 

As long as you don't write anything to your array you won't have to resync when we get this sorted out.

Edited by flyride
Link to comment
Share on other sites

Something else changed.  Are there any other controllers (even with no drives attached to them) remaining in the VM?

 

Let's try SataPortMap=444 and DiskIdxMap=00

 

This is a purely diagnostic/discovery test and the best case is that 4/5 drives on your HBA are visible, but it will tell us conclusively how these are getting mapped.

Link to comment
Share on other sites

You cannot have all those controllers in the system.  Is this vCenter we are looking at?  I find it hard to believe you cannot remove the base controllers from the image.  Was the VM built from the "Other 3.x Linux 64-bit" template as the tutorials state?

 

From my web access to my ESXi host, I see this on my production VM:

 

esxivm.thumb.jpg.05e6be415c530ca2e0cbc3ac6251d73d.jpg

 

Controller 0 with loader, controller 1 with virtual drives (RDM's in my case), and a PCI passthrough HBA.

 

Link to comment
Share on other sites

I also vaguely remember editing the synoinfo.conf files for esataportcfg when I was first setting this up. Could that be related?

 

To answer your other questions, yes I've built this VM to whatever the guide was at the time. The only difference is that I've added more RAM and procs because I was running surveillance station and resilio sync on it.

Link to comment
Share on other sites

synoinfo.conf

 

So I just a lspci -nn -q and it shows the first two sata controllers as lower numbers, but the lsi controller shows up as a sas controller. Would that make a difference in the grub config?

 

0000:02:01.0 SATA controller [0106]: VMware SATA AHCI controller [15ad:07e0]
0000:02:02.0 SATA controller [0106]: VMware SATA AHCI controller [15ad:07e0]
0000:03:00.0 Ethernet controller [0200]: Intel Corporation 82574L Gigabit Network Connection [8086:10d3]
0000:0b:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] [1000:0072] (rev 03)
 

Link to comment
Share on other sites

So I removed the disk and controller and put the grub settings back to default:

 

set sata_args='sata_uid=1 sata_pcislot=5 synoboot_satadom=1 DiskIdxMap=0C SataPortMap=1 SasIdxMap=0'

 

and the two drives are showing back up, but they've fallen out of the array. I really don't care about the numbers or order at this point. Can we get the drives back in the array without doing a full resync?

Edited by SirIanthe3rd
Link to comment
Share on other sites

If all the drives are present and it is not reporting healthy, then something wrote to the array while it was in degraded mode.  In that case you ought to resync.


If you want to continue with an upgrade plan, the controller/drive mapping needs to be understood. Nothing in your synoinfo.conf would cause the problem.  Can you post the Disk Manager Overview now?

 

You might feel like you've gone through a wringer, but your data was not at risk.  And you have corrected two significant issues: vSCSI controller conversion to vSATA, and adding FixSynoBoot.sh, both of which are needed for a successful upgrade.

Link to comment
Share on other sites

It doesn't work that way, each drive has a write serial number. The write serials are no longer in sync across the whole array.  If the array wouldn't start because of not enough members, it would be up and healthy now, but it managed to start degraded and something in DSM wrote to it.  It's probably innocuous and could be forced, but it's your data and I would never recommend that unless the data was otherwise irrecoverable.

Link to comment
Share on other sites

  • 3 months later...

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...