TrueNas Scale in a VM w/SmartD - Smart Test results not showing?

burmjohn

Cadet
Joined
Feb 26, 2021
Messages
9
Hi All,

Not sure if anyone else ran across this, but I wanted to confirm this is the right way to go about enabling the SmartD service in TrueNas Scale when running in a VM. I couldn't figure out why SmartD kept failing to start and did some searching, systemd was reporting back something to effect "ConditionVirtualization=no was not met".

I went ahead and edited the /etc/systemd/system/smartd.service and changed the ConditionVirtualization=no to ConditionVirtualization= (see below for example). Then went ahead and reloaded the daemon with systemctl daemon-reload and restarted the service with systemctl restart smartd. All looks good now and its running.

In the GUI (perhaps this isnt implemented yet, the smart results still do not show when clicking the "Add Smart Test Results Of..."


1614375529302.png

Code:
[Unit]
Description=Self Monitoring and Reporting Technology (SMART) Daemon
Documentation=man:smartd(8) man:smartd.conf(5)
ConditionVirtualization=

[Service]
Type=notify
EnvironmentFile=-/etc/default/smartmontools
ExecStart=/usr/sbin/smartd -n $smartd_opts
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target
Alias=smartd.service


Thanks,
John
 

ornias

Wizard
Joined
Mar 6, 2020
Messages
1,458
Firstoff: Ofcoarse SCALE is not a "edit config yourself"-style debian distro, it's an appliance
Second: I'm not sure how your disks are mounted, that might be quite relevant

Anyhow:
are you sure "ConditionVirtualization=" is right?
I can imagine that throwing an NRE
 

burmjohn

Cadet
Joined
Feb 26, 2021
Messages
9
"ConditionVirtualization=" just means it will accept yes or no.
 

FlangeMonkey

Contributor
Joined
Dec 6, 2012
Messages
111
I also ran into this, I remarked out the line instead to get it running.

The greater question is why is there validation for virtual environments for this service? IMO it should be a bug report?
 

ornias

Wizard
Joined
Mar 6, 2020
Messages
1,458
The greater question is why is there validation for virtual environments for this service? IMO it should be a bug report?
It's hard to answer questions if you mix-and-match multiple forms of jargon

If you mean if you should file a SCALE Bug report:
- It's not a SCALE bug report, simply put SCALE config files should be edited. If that causes a bug, thats pretty much your own problem from a SCALE point of view. If you think the default should be different that might be worth a bug report

If you mean if you should file a bug report about the existance of the "ConditionVirtualization" option:
- Thats an opstream issue with the packages used and not related to SCALE, you would have to ask the upstream devs about it.
 

FlangeMonkey

Contributor
Joined
Dec 6, 2012
Messages
111
what? There is no mixing of jargon. The service is configured to validate if it's a virtual environment because of "ConditionVirtualization=".

The default config from Debian reps for smartmontools is:

Code:
[Unit]
Description=Self Monitoring and Reporting Technology (SMART) Daemon
Documentation=man:smartd(8) man:smartd.conf(5)

[Service]
EnvironmentFile=-/etc/default/smartmontools
ExecStart=/usr/sbin/smartd -n $smartd_opts
ExecReload=/bin/kill -HUP $MAINPID
StandardOutput=syslog

[Install]
WantedBy=multi-user.target


Therefore "ConditionVirtualization=no" has been added. This is more of a question for the devs.
 

ornias

Wizard
Joined
Mar 6, 2020
Messages
1,458
what? There is no mixing of jargon. The service is configured to validate if it's a virtual environment because of "ConditionVirtualization=".
The service is configured NOT to validate if the system is virtualised, because the default is "ConditionVirtualization=no".

Why?
I bet two reasons:
1. The middleware consuming the smart data has no use of virtualisation data
2. Users are supposed to NEVER virtualise or abstract away the storage controllers and doing so is not supported. So detecting virtualisation has no use.
2.b. Only thing that might be virtualised is the system disk, in which case SMART would be primarily the duty of the hypervisor, not TrueNAS.

Anyhow:
OP's error is weird "ConditionVirtualization=no" means "Do not check for virtualisation" so has no condition that has to be met, according to the docs that is.
 
Last edited:

burmjohn

Cadet
Joined
Feb 26, 2021
Messages
9
1. The middleware consuming the smart data has no use of virtualisation data
2. Users are supposed to NEVER virtualise or abstract away the storage controllers and doing so is not supported. So detecting virtualisation has no use.
2.b. Only thing that might be virtualised is the system disk, in which case SMART would be primarily the duty of the hypervisor, not TrueNAS.
1. Wrong - A lot of people w/in the TrueNas world pass controllers through to a VM to virtualize their storage servers/appliances.
2. Wrong - see above
3. Wrong - see above
 

burmjohn

Cadet
Joined
Feb 26, 2021
Messages
9
I also ran into this, I remarked out the line instead to get it running.

The greater question is why is there validation for virtual environments for this service? IMO it should be a bug report?

Thanks for confirming. Did you notice an issue with the smart display from the disk screen in the UI (like in the screenshot I posted)?
 

Ericloewe

Server Wrangler
Moderator
Joined
Feb 15, 2014
Messages
20,176
A lot of people w/in the TrueNas world pass controllers through to a VM to virtualize their storage servers/appliances.
I think the point is precisely that the pass-through controller is ideally no different from a bare metal controller, meaning that any virtualization options do not apply. They would be relevant for virtual disks of some description, which shouldn't really be the case.
 

FlangeMonkey

Contributor
Joined
Dec 6, 2012
Messages
111
Thanks for confirming. Did you notice an issue with the smart display from the disk screen in the UI (like in the screenshot I posted)?
That task is to schedule smart testing. I could be wrong, but I've never seen it post results in that section.
 

FlangeMonkey

Contributor
Joined
Dec 6, 2012
Messages
111
I think the point is precisely that the pass-through controller is ideally no different from a bare metal controller, meaning that any virtualization options do not apply. They would be relevant for virtual disks of some description, which shouldn't really be the case.

Yes that is correct and virtualizing freenas/truenas has always been supported as fare as I'm aware. Unless its a recent change, however I see drivers and tools are still in there for VMware.
 

ornias

Wizard
Joined
Mar 6, 2020
Messages
1,458
1. Wrong - A lot of people w/in the TrueNas world pass controllers through to a VM to virtualize their storage servers/appliances.
2. Wrong - see above
3. Wrong - see above

When you tell people they are "wrong wrong wrong" maybe read what they actually wrote?

"The middleware consuming the smart data has no use of virtualisation data"
- I was saying the IX middleware CODE doesn't use that specific datasource (virtualisation specific SMART data), your answer isn't even relevant in regards to what the middleware does or doesn't do.

"Users are supposed to NEVER virtualise or abstract away the storage controllers and doing so is not supported. So detecting virtualisation has no use"
- I said "abstracting away" and "virtualise", which is the exact opposite as "Passing Through". The first two are NOT supported and ill-adviced, the third is actually adviced, supported and doesn't need to know about virtualisation because it talks directly to the hardware. (as @Ericloewe explained)

Before giving people an attitude, you might also try to notice who's question got answered. Because I didn't answer you, I anwered a question by @FlangeMonkey on why the devs might disable the check for virtualisation in said file.
To answer this question, I refer to the general best-pracitices, guidelines and manuals out there. You might not agree with the decision to disable the check (hell I might not even agree), I just explained the logic behind it.

That being said:
I actually supported your issue by explaining you shouldn't get this error even if it was disabled, but you seemed to ignore that part in your quest to prove me "Wrong, Wrong, Wrong". That makes be question, are you here to "complain and be proven right" or to actually find out what causes your issue?
 

FlangeMonkey

Contributor
Joined
Dec 6, 2012
Messages
111
The service is configured NOT to validate if the system is virtualised, because the default is "ConditionVirtualization=no".
You have the the wrong way around, this line prevents the service from running if the system is virtualised.
 

ornias

Wizard
Joined
Mar 6, 2020
Messages
1,458
You have the the wrong way around, this line prevents the service from running if the system is virtualised.
No, not according to the manual it doesnt.
"Takes either boolean value to check if being executed in any virtualized environment, or one of "vm" and "container" to test against a generic type of virtualization solution"
- Which means: no, check in no environment at all and yes, check if it runs in any environment

However: i'm not sure if "no" is the correct way if setting the boolean to false. There is some discussion out there between: "no", "false" and "none"
I suggest trying the other two and report back if it starts working :)


As smart.d follows the system.d manual that should be the explaination of the setting.

However:
It should still not-run if no smart-compatible drives are detected, which might be the case here...
(That check might also be part of the codeportion related to "ConditionVirtualization", hence the error. I'm not sure however, as I do not have the time to dig through the source)
 
Last edited:

FlangeMonkey

Contributor
Joined
Dec 6, 2012
Messages
111
@ornias I don't know why your being argumentative, I'll let people google it themselves, to prevent any miss-leading attention to this from this point on.

This issue truly comes down to why the devs chose this, its not mine or yours to say otherwise. This is why I suggested a bug report, although its a simple fix, I cannot say if it should be prevented or not depending on why. This forum thread highlights it and I'll let any of the scale team weigh in on if someone should create this bug report.
 

ornias

Wizard
Joined
Mar 6, 2020
Messages
1,458
@ornias I don't know why your being argumentative, I'll let people google it themselves, to prevent any miss-leading attention to this from this point on.
I just quoted the SystemD documentation for you.
I simply pointed out your argument based on authority (thats what it's called when you provide no source besides your say-so), does not seem to be in line with the systemd manual.

If anyone here is argumentative, it's you and OP @FlangeMonkey, Both of you keep ignoring 80% of what I write about the actual underlaying issue, just to highlight minor nit-picks or just simply "reinterpret" my complete post to suit some nerrative.

This issue truly comes down to why the devs chose this, its not mine or yours to say otherwise.

To say otherwise about what? "to say otherwise" isn't the correct english scentence, it means "to contradict" but there is nothing to contradict in this case. Actually: never said the issue didn't exist and I even said I have no position on the subject, I just EXPLAINED both the Middleware and the SystemD manual.


I'll let any of the scale team weigh in on if someone should create this bug report.
Standard procedure is always to just file a report, you don't need an answer for a dev because the answer is always the same "just file a report and attach debug and we will check it out".


Anyhow:
As both of you now made clear you really just want the devs to look at it, are not interested in doing any research yourself and/or investigating with others when it doesn't suit your nerrative:

Just make the damn bug report on Jira and Call it a day.
Like Kris said just a few days back: IX rather has to delete/close bugreports than recieve less of them and miss something.
 

burmjohn

Cadet
Joined
Feb 26, 2021
Messages
9
The service is configured NOT to validate if the system is virtualised, because the default is "ConditionVirtualization=no".

Why?
I bet two reasons:
1. The middleware consuming the smart data has no use of virtualisation data
2. Users are supposed to NEVER virtualise or abstract away the storage controllers and doing so is not supported. So detecting virtualisation has no use.
2.b. Only thing that might be virtualised is the system disk, in which case SMART would be primarily the duty of the hypervisor, not TrueNAS.

Anyhow:
OP's error is weird "ConditionVirtualization=no" means "Do not check for virtualisation" so has no condition that has to be met, according to the docs that is.
When you tell people they are "wrong wrong wrong" maybe read what they actually wrote?

"The middleware consuming the smart data has no use of virtualisation data"
- I was saying the IX middleware CODE doesn't use that specific datasource (virtualisation specific SMART data), your answer isn't even relevant in regards to what the middleware does or doesn't do.

"Users are supposed to NEVER virtualise or abstract away the storage controllers and doing so is not supported. So detecting virtualisation has no use"
- I said "abstracting away" and "virtualise", which is the exact opposite as "Passing Through". The first two are NOT supported and ill-adviced, the third is actually adviced, supported and doesn't need to know about virtualisation because it talks directly to the hardware. (as @Ericloewe explained)

Before giving people an attitude, you might also try to notice who's question got answered. Because I didn't answer you, I anwered a question by @FlangeMonkey on why the devs might disable the check for virtualisation in said file.
To answer this question, I refer to the general best-pracitices, guidelines and manuals out there. You might not agree with the decision to disable the check (hell I might not even agree), I just explained the logic behind it.

That being said:
I actually supported your issue by explaining you shouldn't get this error even if it was disabled, but you seemed to ignore that part in your quest to prove me "Wrong, Wrong, Wrong". That makes be question, are you here to "complain and be proven right" or to actually find out what causes your issue?

Looks like you should take your own advise, and perhaps also stop sharing false information and BS.
 

FlangeMonkey

Contributor
Joined
Dec 6, 2012
Messages
111
@ornias, ignoring comments is to prevent argument, I have been nothing put polite and will continue to ignore your offence. Please keep focus on the issue at hand.
 

Ericloewe

Server Wrangler
Moderator
Joined
Feb 15, 2014
Messages
20,176
<Moderator hat>
I think everyone needs to take a step back here, since I'm sure everyone is acting in good faith. So deep breath everyone and let's go over the issue at hand.
</Moderator hat>


"Takes either boolean value to check if being executed in any virtualized environment, or one of "vm" and "container" to test against a generic type of virtualization solution"
This sentence does suggest to me that = no (or = false or whatever is being tested against) should disable the check. But, given the behavior seen here, perhaps it is misleading and actually means:

case "no": Enforce that is is not virtualized
case "yes": Enforce that it is virtualized
case "vm": Enforce that it is a vm and not a container?
case "container": Enforce that it is not a vm and is a container?

If this is on purpose, it seems like a pretty poor way to word it, since it doesn't make it at all clear that this is what will happen.

The service is configured NOT to validate if the system is virtualised, because the default is "ConditionVirtualization=no".
...is what a reasonable dev would have thought after coming to the same interpretation of the docs as we did at first. In any case, it sounds like there's a good bug report for iX in here and I welcome its submission.
 
Top