Onedb fsck fails (6.6.0), quotas miscalculated

Community Support General
1

Hi all,

we are still having problems with various quotas being out of sync with reality - users having negative number of running VMs, users with no VM running but non-zero “running memory”, etc. So I need to run onedb fsck occasionally. Today, it refused to start:

# onedb fsck
Version mismatch: fsck file is for version
Shared: 6.6.0, Local: 6.6.0

Current database is version
Shared: , Local:

The error message was not very helpful. But OpenNebula 6.6.0 has been running correctly, so database version should be correct. After trying many things, I tried to run also various other onedb subcommands:

onedb show-body vm --id 1234 displayed a correct XML data of that VM. But then onedb history failed with somewhat meaningful error message:

# onedb history
Error connecting to DB: Mysql2::Error: Unsupported charset: '"utf8mb3"'

After re-reading the onedb manual page, I guessed that I could try onedb fsck --charset utf8, as I didn’t know what utf8mb3 means :-). And indeed it worked.

So, why do OpenNebula daemons and some onedb subcommands work, but onedb history connects with the wrong charset, and onedb fsck fails even without a meaningful error message?

Also, does anybody else see miscalculated resource usage for various quotas? I have been seeing it for many ONe versions back.

Thanks,

-Yenya

2

According to our DB administrator, it could be related to the MariaDB server upgrade several weeks ago. MariaDB 10.6 has apparently different default parameters related to charset:

But it is still strange that most part of OpenNebula work, except onedb fsck and onedb history.

3

Hello Yenya,
I’ve recently fixed some charset issues in onedb fsck. I believe it should fix also your onedb fsck issue, but it’s not part of any release yet.

For the onedb history, feel free to open GitHub issue to get more attention.

About the quotas - last significant improvement was in release 6.4.1. But apparently, we haven’t fixed everything. We probably miss some quota updates after command failures. It would be very helpful if you know how to reproduce that.
If you have user with wrong quotas, who doesn’t own too many VMs, then the VM logs will be very helpful.