SOLVED: Zpool import shows insufficient replicas and invalid label for main pool

[stk]

I am using ZFS replication. There is a ZVol that for my truenas running in the VM holding the pool (empty at the moment) called “main”.

the import sees a valid pool on the Zvol associated with the VM and lists it.

It has to have the exact same ID because the ID is in the ZVol and the Zvol is replicated bit by bit because ZFS isn’t supposed to know what is inside.

So it makes perfect sense to me.

Am I missing something?

[Stux]

It’s strange, I’ve never seen that happen personally, and i make use of quite a few TrueNAS hosted TrueNAS VMs.

Maybe I just haven’t looked properly.

[winnielinnie]

When it comes to this inception-level stuff, I have to kindly remove myself.

It sounds like you’re doing some “ZFS in ZFS” juggling.

[winnielinnie]

@stk

OK, so I’ve figured out these zd devices are zvols and if you go to /dev/zvol you can look under the covers to find out the truenas name of the zvol.

BINGO: To be creative, I used the truenas VM to install truenas on truenas. to create the VM, I created two zvols, one for the installation, and another zvol for the pool. in the VM, I called my pool “main”.

So this is why the clone exists on the backup systems because it’s backing up all my VMs, including my truenas VM.

So basically, that zvol looks like an importable pool last used by truenas, no surprise. Makes perfect sense.

More later, but I’m getting real close now. I think I’ll destroy the main pool in the vm and call it a new name

This is all just to test and play around, right?

You’re not going to use this “chimera” setup to store valuable data, right?

You’re not making any indicative claims about ZFS, based on this experience, right? (This is not “safe” ZFS usage, just to reiterate.)

[winnielinnie]

I used the truenas VM to install truenas on truenas.

Someone needs to print this on a shirt and sell it.

“Want to keep your data safe? Use TrueNAS!”

“Want to keep your data extra safe? Try TrueNAS in TrueNAS.”

[stk]

correct. I amended the post now that I’ve figured out what happened.

[stk]

correct. this is just for seeing if I can do it, creating a truenas I can muck with without worry about losing anything, testing untested scripts written by LLMs, etc.

It works and is reliable, just as expected.

Note that it SHOULD be safe and so it is a good “stress test” of robustness.

AFAIK, there should be no reason at all why truenas should fail under this scenario if everything works as advertised.

[Stux]

Still not sure how you’re seeing zvols as candidates for import.

I have dozens of zvols with zfs on them on one of my systems… here’s just one example

tank/vms/eel_expansion/boot                            3.85G  53.5T  3.62G  -
tank/vms/eel_expansion/disk1                            201M  53.5T   160M  -
tank/vms/eel_expansion/disk10                           168M  53.5T   133M  -
tank/vms/eel_expansion/disk2                            196M  53.5T   157M  -
tank/vms/eel_expansion/disk3                            202M  53.5T   161M  -
tank/vms/eel_expansion/disk4                            193M  53.5T   153M  -
tank/vms/eel_expansion/disk5                            192M  53.5T   153M  -
tank/vms/eel_expansion/disk6                            182M  53.5T   146M  -
tank/vms/eel_expansion/disk7                            182M  53.5T   146M  -
tank/vms/eel_expansion/disk8                            175M  53.5T   140M  -
tank/vms/eel_expansion/disk9                            176M  53.5T   140M  -
tank/vms/pfSense-g9v9ab                                4.61G  53.5T  4.16G  -

Meanwhile,

root@chronus[~]# zpool import
no pools available to import

Notice, it doesn’t offer to import pools which are on zvols.

[stk]

these are pool replicas on my backup disks using full file replication of the pool to the backup disk. That’s what it is seeing: the pool, not the zvols.