Fix Virtualizor “Could not make the Query” Error —

Ever opened your Virtualizor panel expecting to see your usual dashboard — all your VPS instances lined up neatly — only to be greeted by a cryptic error message with a bunch of PHP array output? Yeah, that was my Tuesday night last week. A client messaged me in a panic, “My whole panel is dead! I can’t see any of my VPSes!”

After hopping into SSH and checking the logs, the culprit was clear: a missing MySQL data file. Specifically, servers.MYD — the file that stores all server data for Virtualizor. Without it, Virtualizor can’t load anything. Here’s the exact error:

Could not make the Query.
SELECT * FROM servers ORDER BY serid ASC
Array
(
    [0] => HY000
    [1] => 29
    [2] => File './virtualizor/servers.MYD' not found (Errcode: 30)
)

If you’re staring at this error right now, don’t worry. By the end of this article, you’ll know exactly what happened, why it happened, and how to fix it — step by step.

Symptoms & Error Message Breakdown

This error typically shows up on the main Virtualizor admin page. Instead of your normal dashboard, you see the raw PHP array output of a failed MySQL query.

Breaking it down: MySQL is telling us, “I know the servers table exists, but I can’t read its data because the underlying file is gone.”

Technical Deep Dive: What Is a .MYD File?

Before we jump to solutions, let’s understand the anatomy of a MySQL database using MyISAM storage engine — which is what Virtualizor uses.

In MyISAM, each table is stored as three separate files:

When servers.MYD is missing, MySQL still knows the table exists (the .frm file is there), but it can’t read any rows. Think of it like a book with its cover intact but all the pages torn out.

Root Cause: Why Did servers.MYD Disappear?

After handling over a dozen similar cases, I’ve narrowed down the most common causes:

Common Causes

Step-by-Step Solution

Let’s get into the fix. I’ll walk you through multiple methods, from safest to more aggressive. Follow the order — don’t skip ahead.

Method 1: Check Disk Health First

Before touching the database, make sure your disk is healthy. Fixing a database on a failing disk is pointless.

# Check disk space
df -h

# Check for disk errors in kernel log
dmesg | grep -i error

# Check SMART health (if available)
smartctl -a /dev/sda

If disk is full, clean up unnecessary files first. If filesystem errors are found, repair them before proceeding.

# For ext4 filesystem (MUST unmount first or use recovery mode)
fsck -y /dev/sda1

Method 2: Restore from MySQL Backup

This is the ideal method — if you have a recent, complete backup.

# 1. Check for existing backups
ls -la /var/backups/mysql/
ls -la /home/virtualizor/backups/

# 2. Check Virtualizor's own backup directory
ls -la /usr/local/virtualizor/

If you have a mysqldump backup:

# Restore from dump
mysql -u root -p virtualizor < /path/to/virtualizor-backup.sql

If you backed up the entire database directory:

# Stop MySQL first
systemctl stop mysqld

# Backup current state (just in case)
cp -a /var/lib/mysql/virtualizor /var/lib/mysql/virtualizor.bak.$(date +%Y%m%d)

# Copy backup into place
cp -a /path/to/backup/virtualizor /var/lib/mysql/

# Fix permissions
chown -R mysql:mysql /var/lib/mysql/virtualizor

# Start MySQL again
systemctl start mysqld

Method 3: MySQL Repair Table

If .MYD is missing but .MYI and .frm still exist, try MySQL’s built-in repair. Note: this usually only works if the index file contains enough info to reconstruct data — which is rare when .MYD is completely gone.

# Login to MySQL
mysql -u root -p

# Attempt repair
USE virtualizor;
REPAIR TABLE servers;

If the result says “OK” — you’re good. If you get an error like “Can’t create/write to file” — move to Method 4.

Method 4: Recreate the servers Table (Emergency Recovery)

This is your last resort when no backup exists and repair fails. Proceed with extreme caution.

# 1. Backup remaining files
cp -a /var/lib/mysql/virtualizor /var/lib/mysql/virtualizor.emergency.$(date +%Y%m%d)

# 2. Login to MySQL
mysql -u root -p

# 3. Drop the corrupt table (CAREFUL!)
USE virtualizor;
DROP TABLE IF EXISTS servers;

# 4. Recreate the table with the correct structure
CREATE TABLE servers (
  serid int(11) NOT NULL AUTO_INCREMENT,
  server_name varchar(255) NOT NULL,
  server_ip varchar(45) NOT NULL,
  server_type varchar(50) DEFAULT 'openvz',
  hostname varchar(255) DEFAULT NULL,
  port varchar(10) DEFAULT '4645',
  username varchar(255) DEFAULT NULL,
  password varchar(255) DEFAULT NULL,
  bandwidth varchar(50) DEFAULT '0',
  bandwidth_limit varchar(50) DEFAULT '0',
  solusvm_ip varchar(45) DEFAULT NULL,
  solusvm_key varchar(255) DEFAULT NULL,
  PRIMARY KEY (serid)
) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

# 5. Verify the table was created
DESCRIBE servers;
SHOW TABLE STATUS FROM virtualizor LIKE 'servers';

Method 5: Re-sync Server Data

After recreating the table, you need to repopulate it with your server data:

# Option 1: Resync via Virtualizor CLI
cd /usr/local/virtualizor
php bin/virtualizor_resync.php

# Option 2: Add server manually via admin panel
# Open Virtualizor Admin Panel → Add Server → Enter your server details

# Option 3: Import from old config
# If you have old configuration files, extract server data from there

Verification After Fix

After applying any of the methods above, verify everything works:

# 1. Check MySQL status
systemctl status mysqld

# 2. Verify table is accessible
mysql -u root -p -e "USE virtualizor; SELECT COUNT(*) FROM servers;"

# 3. Check Virtualizor service
systemctl status virtualizor

# 4. Open admin panel in browser, verify no errors
# Access: https://your-ip:4084

# 5. Check Virtualizor error logs
cat /usr/local/virtualizor/logs/error.log | tail -20

Pro Tips & Warnings

# Daily backup at 2 AM
0 2 * * * mysqldump -u root -p'password' virtualizor | gzip > /var/backups/mysql/virtualizor-$(date +%Y%m%d).sql.gz

# Check disk usage and alert if > 85%
DISK=$(df -h / | awk 'NR==2 {print $5}' | sed 's/%//')
if [ "$DISK" -gt 85 ]; then
  echo "Disk usage: ${DISK}%" | mail -s "ALERT: Disk almost full!" admin@domain.com
fi

Troubleshooting Table: Common Related Errors

FAQ

Related Issues

• MySQL Crash Recovery — Safe Database Restoration Guide
• Disk Full on Linux Server — Causes & Solutions
• Complete Virtualizor Installation Guide

Conclusion

The Could not make the Query error with a missing servers.MYD file is a common Virtualizor issue, especially on long-running servers. The root cause almost always traces back to disk space exhaustion or an unexpected MySQL crash.

The key takeaway: don’t panic, don’t rush to reinstall Virtualizor (that will wipe all your VPS data), and always start with diagnostics — check disk, check filesystem, then restore the database.

After fixing the issue, invest some time setting up auto-backups and disk monitoring. These two things will save you from repeat headaches in the future.

Need more help? Check out the related articles above or reach out to our technical team for consultation.