N app-it version suggestion - system crashed

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

dragonme

Active Member
Apr 12, 2016
282
25
28
I have a system running dual l5640 processors.. yeah.. old box but serviceable..

have esxi 6 still on here and need to know which version of the Napp-it VM pre-made OVA to download.. looks like the newer versions are 6.5 and 6.7 required?

Thanks
 

gea

Well-Known Member
Dec 31, 2010
3,141
1,182
113
DE
The VM with OmniOS 151026 is the latest that runs up from ESXi 5.5. The newest ova template with the current OmniOS 151028 requires a current ESXi 6.7

You can of course install current OmniOS manually for ESXi 6.0 and the tools via pkg install open-vm-tools. Install napp-it then via the wget online installer.
 

dragonme

Active Member
Apr 12, 2016
282
25
28
thanks gea..

I think I am pretty well dorked...

I had a backup of this vm somewhere but cant find it.. things got lost last year preping for the hurricaine...

I think I remember the user ID numbers to recreat the users.. I might have a napp-it appliance settings backup but cant find it either

I loaded 151022 ... I cant remember if I updatad it or not after installation.. and have my mounts and interet set up I think....

cant remember how to re-create replicate/backup jobs so that I can pick up where I left off without having to destroy the backup destination and re-copy from scratch
 

gea

Well-Known Member
Dec 31, 2010
3,141
1,182
113
DE
Hello dragonme

You can still download former ova templates from the /old folder
If you had run a napp-it backup job, you find settings on the datapool in /backup_appliance
With napp-it pro you can restore via menu Users, otherwise manually

Without a napp-it backup you can recreate replication jobs to continue incremental replications manually. Recreate a job with same source and target and same jobid. As the jobid is part of the snapnames that you still have you can get it from a snap listing.
 

dragonme

Active Member
Apr 12, 2016
282
25
28
thanks gea
I managed to find my original download of you 151022OVA but can't remember if this is omniosIT or CE-LTS..

I did find a rather old backup_appliance but I don't use a pro license ... I attempted to scp from esxi to the VM and for whatever reason it is not working at all.. no attempt to connect to napp-it and times out. SSH is enabled for napp-it and can ssh in from my workstation.

I re-created my 2 users and remembered their user IDs so I think the file system is sorted.

I went and made some improvements while I was at it and now have some new weirdness.

the original setup boots from USB, and loaded Napp-it from a SATA SSD. The majority of VMs where on a stripped pair of intel s3500 SSDs on a lsi card that was passed through to napp-it and the primary data drives were 3x DRM passthroughs on the motherboard SATA connectors.

I found a older lsi-1074 mezzanine card for this S5520 intel motherboard x2 L5640s and have changed things around.

ESXI still boots from USB internal header, Napp-it now boots from the LSI-1074 on a mirrored pair of 80GB S3500 SSDs in native vmfs datastore to esxi providing some redundancy and allowing me to pass the SATA controller to napp-it thus eliminating the RDM passthrough. napp-it provides nfs datastores from the remaining 2 pools for VMs and data.

Now napp-it complains one of the drives in that 3 drive stripe has a warning on the wall stating that drive at XXXX has block alignment larger than the pool or something to that effect. and it use to show all 3 drives as being 'whole' drives but now shows the offending drive as attached through partition 1. The original 2 drive pool was created outside of napp-it potentialy, can't remember, but for sure the 3rd was added through the Napp-it gui and the RDM must have introduced some weirdness. but when the drives were all DRM, there were no warnings, no partitions and showed all 3 disks as attached to the pool as whole disks, even reporting SMART data with each disk in the pool. now the SMART on the one drive is 'out' of the pool showing the partition in the pool with , no SMART info of course but its whole drive shows good smart data, just no grouped with the other 2 pool members.. weird ..

last night attempted to recreate the jobs by hand since I could not scp the job folder in _log and they would not run.. stupid me I think that the origin pool might have been imported using -o readonly=on as I was poking around looking for possible backups of the original napp-it VM and to ensure things were working ok.. so DUH ... can't create snaps on the origin pool in readonly... will try again today


1> how can I ensure I am actually using 151022LTS and not 151022 original , non CE/LTS omniosIT version?

2> I am still running esxi 6 and vcenter 6.5 since I have older hardware.. but I have seen people state that their l5640s are running with 6.7 .. it it worth upgrading ? if so, would I need to start over with a different version of napp-it from scratch again? which free version should I run if I upgrade? I cloned the ESXI USB last night so I have a backup of that now as well?

3> without a pro license, can you point me at a post that specified the best way to back this up and restore in the future.. .thanks

4> with the primary pool reporting block size issues and having 1 drive in the pool seemingly connected as a partition instead of the disk at this point, should I destroy the 3x8gb pool that is 65% full and rebuild it from the backup?
 
Last edited:

dragonme

Active Member
Apr 12, 2016
282
25
28
[thanks see post abovee
QUOTE="gea, post: 217945, member: 15"]Hello dragonme

You can still download former ova templates from the /old folder
If you had run a napp-it backup job, you find settings on the datapool in /backup_appliance
With napp-it pro you can restore via menu Users, otherwise manually

Without a napp-it backup you can recreate replication jobs to continue incremental replications manually. Recreate a job with same source and target and same jobid. As the jobid is part of the snapnames that you still have you can get it from a snap listing.[/QUOTE]
 

gea

Well-Known Member
Dec 31, 2010
3,141
1,182
113
DE
thanks gea
I managed to find my original download of you 151022OVA but can't remember if this is omniosIT or CE-LTS..

I did find a rather old backup_appliance but I don't use a pro license ... I attempted to scp from esxi to the VM and for whatever reason it is not working at all.. no attempt to connect to napp-it and times out. SSH is enabled for napp-it and can ssh in from my workstation.

I re-created my 2 users and remembered their user IDs so I think the file system is sorted.

I went and made some improvements while I was at it and now have some new weirdness.

the original setup boots from USB, and loaded Napp-it from a SATA SSD. The majority of VMs where on a stripped pair of intel s3500 SSDs on a lsi card that was passed through to napp-it and the primary data drives were 3x DRM passthroughs on the motherboard SATA connectors.

I found a older lsi-1074 mezzanine card for this S5520 intel motherboard x2 L5640s and have changed things around.

ESXI still boots from USB internal header, Napp-it now boots from the LSI-1074 on a mirrored pair of 80GB S3500 SSDs in native vmfs datastore to esxi providing some redundancy and allowing me to pass the SATA controller to napp-it thus eliminating the RDM passthrough. napp-it provides nfs datastores from the remaining 2 pools for VMs and data.

Now napp-it complains one of the drives in that 3 drive stripe has a warning on the wall stating that drive at XXXX has block alignment larger than the pool or something to that effect. and it use to show all 3 drives as being 'whole' drives but now shows the offending drive as attached through partition 1. The original 2 drive pool was created outside of napp-it potentialy, can't remember, but for sure the 3rd was added through the Napp-it gui and the RDM must have introduced some weirdness. but when the drives were all DRM, there were no warnings, no partitions and showed all 3 disks as attached to the pool as whole disks, even reporting SMART data with each disk in the pool. now the SMART on the one drive is 'out' of the pool showing the partition in the pool with , no SMART info of course but its whole drive shows good smart data, just no grouped with the other 2 pool members.. weird ..

last night attempted to recreate the jobs by hand since I could not scp the job folder in _log and they would not run.. stupid me I think that the origin pool might have been imported using -o readonly=on as I was poking around looking for possible backups of the original napp-it VM and to ensure things were working ok.. so DUH ... can't create snaps on the origin pool in readonly... will try again today


1> how can I ensure I am actually using 151022LTS and not 151022 original , non CE/LTS omniosIT version?

2> I am still running esxi 6 and vcenter 6.5 since I have older hardware.. but I have seen people state that their l5640s are running with 6.7 .. it it worth upgrading ? if so, would I need to start over with a different version of napp-it from scratch again? which free version should I run if I upgrade? I cloned the ESXI USB last night so I have a backup of that now as well?

3> without a pro license, can you point me at a post that specified the best way to back this up and restore in the future.. .thanks

4> with the primary pool reporting block size issues and having 1 drive in the pool seemingly connected as a partition instead of the disk at this point, should I destroy the 3x8gb pool that is 65% full and rebuild it from the backup?
1,
The initial release was identical but updates are only for ce
Check menu About (or uname -a) or call pkg publisher wether you use the OmniTo repo or the ce one


2.
Only problem is the ESXi VM version. As this relate sto newer features my current ova requires 6.7. Bit no problem if you install OmniOS 151028 and current napp-it on ESXi 6.0 (or update an older ova)

3.
Simply backup/ restore /var/web-gui/_log/* and recreate users and groups with same uid/gid

4.
This is related to ZFS. With ashift =12 (4k disks) all disks in the same vdev must support 4k (4kn or 512e)
 

dragonme

Active Member
Apr 12, 2016
282
25
28
1,
The initial release was identical but updates are only for ce
Check menu About (or uname -a) or call pkg publisher wether you use the OmniTo repo or the ce one


2.
Only problem is the ESXi VM version. As this relate sto newer features my current ova requires 6.7. Bit no problem if you install OmniOS 151028 and current napp-it on ESXi 6.0 (or update an older ova)

3.
Simply backup/ restore /var/web-gui/_log/* and recreate users and groups with same uid/gid

4.
This is related to ZFS. With ashift =12 (4k disks) all disks in the same vdev must support 4k (4kn or 512e)


thanks gea...

so should I not be runnig omnios 151022 with 18.01 on esxi 6.0?

also, all three disks in that vdev are essentially 8tb WD red or equivelent AND the pool was created ashift=9 I think? funny bit is why would the error not be present or show that the third drive was connected to the pool via partition when they were attached to the VM through DRM and now show issues when the SATA controller is passed though? I assume since the pool appears to be functioning, no errors reported, and its just a warning its ok to continue to use?
 

gea

Well-Known Member
Dec 31, 2010
3,141
1,182
113
DE
You can run the lts but I would prefer the newest (a lot of new features)

Your 8TB disks are 4k physical what means ashift=12
Ashift=9 is a problem as this can give problems when replacing a disk.

If you have a chance, recreate the pool with vdevs of type ashift=12
 

dragonme

Active Member
Apr 12, 2016
282
25
28
You can run the lts but I would prefer the newest (a lot of new features)

Your 8TB disks are 4k physical what means ashift=12
Ashift=9 is a problem as this can give problems when replacing a disk.

If you have a chance, recreate the pool with vdevs of type ashift=12

any features worth while if just using napp-it as a esxi filer? don't need zones etc.

did they ever implement SMB server side copy ? also some have seemed to complain the more recent version of omnios on older hardware like mine were slower SMB / vmxnet3 than say 151014 ? anyone ever figure that one out?

is there an easy update path ... I will likely remain at esxi 6 and vcsa 6.5 since its older 1366 hardware and while some say they have no issues.. esxi is problematic enough without going off the reservation...
 

dragonme

Active Member
Apr 12, 2016
282
25
28
well since I was cleaning house anyway.. and I took the entire server apart to blow out dust and get an early spring cleaning going while rebuilding the failed SSD and reinstalling napp-it ...

I figured I would update everything to 6.7

so what do I gain by going to 151028 and 18.12 free ... ?
 

dragonme

Active Member
Apr 12, 2016
282
25
28
after a more in-depth review of what went down.. I still can't put my finger on it.

originally, when esxi was failing to boot through and startup napp-it and other vms.. I figured that the consumer class ssd that I was using for the native vmfs datastore for napp-it when bad.. I was wrong I think

I took that ssd and with some tools and trickery mounted it on an ubuntu 16.04 desktop machine and opened it up.. all the VMs were there.. both napp-it and observium which I use to host apcupsd and collect metrics.. all seemed fine..

in fact I scp'd the observium vm back over to the running esxi box .. added it back to inventory and everything it was fine... huh...

I am now thinking perhaps that it just ran out of space.. as the observium vm was a 20gb thin and napp-it is what a 40gb thin in the OVA... so perhaps it just ran out of free space.. esxi does weird things when disks fill.
I am no esxi ninja and log analysis is really not my thing


as for the RDM passthrough pool issue where one disk now shows as attached though a partitions... I did more research and this looks like a bug in napp-it

the original pool was indeed created on a mac running openzfs. it was a stripe of 2x8TB reds and were attached as disk1, disk2. It was created ashift=12 and both devs were ashift12

the third disk, the one in question was added via napp-it gui .. after the pool was moved from a OS X based server and re-imported into napp-it esxi as RDM pass-through disks.

I passed napp-it the RDM disk3 as a blank drive, just as I had the other 2. and used the gui in napp-it to attach it to the pool. zpool history shows that it was attached as a whole disk.. c12d1c0 or something to that effect. also, at the time of the disk add.. napp-it added it as a ashift9 dev.. into a pool that was already a ashift12 .. very strange.. I guess as a DRM it didn't see the 512e 4k native tags properly?

after rebuilding the server from the crash and now passing napp-it the ICH10 controller, ditching the RDM passthrough tags, the drive clearly shows up as attached as a partition and in zpool list, etc, no drive serial or information show up. in napp-it smart data the whole drive smart info is not part of a pool but look like an disk not attached to a zfs system.. and a placeholder of sorts that has no smart info is attached as the 3rd device in that pool on the smart page..

weirdness for sure.. so when napp-it added it to the pool when it was DRM it attached it as a whole disk and all the napp-it disk infos, and smart screens etc worked as expected and showed the 3 disks in the pool as whole drives.. including using command line

after changing to controller pass through.. no longer the case and one drive appears to be attached as a partition in every napp-it menu and also in the command line.

TLDR .. if you are working with RDM disks and napp-it proceed with caution..

pool construction and pool portability may get effected.


 

gea

Well-Known Member
Dec 31, 2010
3,141
1,182
113
DE
Basically ESXi supports only one RDM method: Using an SAS HBA and add disks then as raw disk, preferable SAS disks but this works with Sata disks as well. This also allows Smart checks.

Any other way of RDM in ESXi (via Sata controller, physical RDM or logical) may work or not, is not supported by Vmware and therefor not suggested. Behaviour may be different depending on OS (napp-it runs on different operating systems and does not modify the OS behaviours) and ESXi releases.