[SOLVED] `libvirtd` reboots the system after 1 min

I’m trying to set up virt-manager for a guest OS, and my main reference is (can’t include links) dividebyzer0 dot gitlab dot io slash GPUpassthrough html.

After about 1 min from systemctl start libvirtd, it reboots without warning. journalctl -b0 doesn’t show anything suspicious (at least to me), but a quick search showed two posts on reddit saying that it happens because they’ve allocated a pool in /dev. Which is funny, because in the link above, the 1st step in Configuring Virtual Machine section involves stting up a path in /dev. If this is the cause, how can I continue?

can you enable libvirtd on boot in systemd and then see if that allows you to use it? if this results in looping reboots, you can use single user mode to disable the service on boot.

I wonder whether you’re tickling a kernel bug… or a hardware problem … (e.g. instability at low CPU utilization or some other such weird thing).

If it’s a purely software issue, Linux has a thing for the kernel called kdump, that can help debugging, but it’s a bit awkward even for developers to gleen useful information from it.

I think it’s probably also more likely to be a hardware issue, or a specific configuration related issue.


Can you share more details about your particular setup?

Check out libvirt: Libvirt Daemons to see all the different things starting the libvirt service does.

Maybe a dumb question, but are you sure your system supports KVM virtualization? Is it supported by your CPU, is it enabled / supported in your BIOS?

Post the output of the dmesg command after you do a fresh reboot.

Hello everyone, thank you for replying.

@gordonthree

I should have specified, sorry about that: Ryzen 3700X, B450 Tomahawk Max, RX 5700XT + 750Ti, 32 GB RAM. It’s very similar to the one in the guide, so I’m fairly sure that it does support it.

@mathew2214

I ran systemctl enable libvirtd and rebooted. Nothing happened, because the “bad” pool was deleted. I proceeded with the normal install by following the guide. As soon as I added the /dev part, after 1 min: reboot. What frustrates me is that it reboots the system. If something goes wrong with the service, let it crash, if there are programs depending on it, let them crash, but why does it have to reboot the computer?

At any rate, after reboot, I didn’t even touch the keyboard. POST, Grub for 5 sec, normal boot, there were two messages about the watchdog, seemingly appearing over the login: part (first time I see it like this), didn’t even login, after 1 min – reboot. After that I deleted the pool .xml setting from /etc/libvirt/storage/dev.xml (as it was named), went on to startx, but – reboot! Which makes it seem that it loads the .xml from the start and is not affected by subsequent actions on it (is it?). At any rate, the next start (this) is going fine without the .xml. No watchdog messages.

@risk

If it’s a hardware issue, then the two other people on reddit must have (had) it, too. I’m willing to use that kdump, but the signs, so far, seem to point at libvirtd dealing with /dev (or being unable to).

1 Like

so I typed in the url you spelled out. I rather disagree with these instructions … trying to assign the entire /dev folder as a libvirt storage pool is bound to cause problems!

If you’re trying to pass-through an SSD partition to your guest machine, specify it directly by path, don’t rely on the gui and browser to find it for you in all of /dev

Here’s the relevant docs on block device / storage management
https://libvirt.org/storage.html

There isn’t really any performance benefit to assigning a block device to a guest, versus assigning a file stored on that device, the exception would be PCIe based storage, and that’s a different ballpark. The advantage of using a file is, you can backup that file, you can also share a fast device with multiple guests, if they don’t consume the entire space, with sparse provisioning.

Pass SSD device directly to VM

Add Hardware -> Storage -> Select or create custom storage
Device type: Disk device
Bus type: VirtIO
Click Manage...
Click the + on the bottom left (Add Pool).
Type: dir: Filesystem Directory
Name it whatever you want, or leave it on the default of pool. Doesn't matter.
Target Path: /dev 
Finish.
Select the newly created pool on the left and locate the sd* device you want to install Windows on. In my case, this was sdb. Don't aim for partition numbers, just use the device. (ie, sdb and not sdb1)
Make sure the device is selected and click Choose Volume
Confirm that it's still set to VirtIO and raw, if so, click Finish.
Go ahead and remove the 2GB disk that was added by the wizard by locating it on the left pane, right clicking and clicking Remove hardware```
2 Likes

FWIW, I didn’t use /dev, I used /dev/sdb2 (which is where I would have installed the OS), but it’s the same effect. So then, I’ll try out the “cow2” extension (or something like that). Well, back to the aching board, hopefully there will be some good news.

Adding the qcow2 extension isn’t going to help. You can’t store a path directly on a block device, it needs to be mounted somewhere first, with a filesystem.

You can however, create a disk pool in libvirt libvirt: Storage Management

You would assign /dev/sdb to the pool, and make sure there are no existing partitions on the disk to begin with.

The idea was to mahe fstab hold a partition where the OS will be installed, which is the one I prepared especially for this: /dev/sdb2.

I’m afraid this would be impossible currently: I don’t have a whole disk to allocate to this. Only a partition. Do I need a whole disk?

I’m reading now through your link and I found this:

Since /dev/XXX names aren’t generally stable, it is recommended to configure the pool to use /dev/disk/by-path or /dev/disk/by-id for the target path. These provide persistent stable naming for LUNs Since 0.6.2

Do they mean “stable” in the sense that the names can change, or stable as in the system is shaky?

Oh my, I think I found the cause: in your link, under the filesystem pool section, it lists the valid pool format types, and none of them is NTFS. And the partition exists there since the Windows days, that’s why I cleared it. And it’s NTFS. I’m going to reformat it to ext4, allocate it as in the guide, and then see if it still crashes.

if that fails, i recommend using storage controller passthrough for a high-performance Windows VM. if performance is not a priority, then an image file might also work.

5 min have passed and no crash. I call this success. Thank you all for the advices, I should have RTFM, and not follow the guide, blindly, but sometimes guides are meant to be a slow introduction to the heavy manuals. I’ll mark this as solved.

3 Likes

If you add a drive, or move the connections around, /dev/sd? will point to another device, or disappear completely. Those drive identifiers are assigned more or less at random.

If you can’t dedicate the entire drive, I recommend making a partition as big as the free space you have available, format it with XFS and mount it somewhere, like /mnt/vmstorage … then you can create qcow2 files in there for your Windows machines. You aren’t going to see any performance difference versus giving the vm direct access to a partition.

Sorry for the minor necromancy. I’ve been a bit hasty, it still crashes, but the problem was in my (mis)understanding of the guide. In there, it says to select the whole device, /dev/sdb (as is in my case), not /dev/sdb2 (as I thought). That way it sees the whole root disk, so it can select what to see and what not. There’s a similar problem here (on askubuntu). When I do that, it works just fine. I can also add external partitions to share and view from within the OS. Mishaps, everywhere.

Hi there!
It’s not a question. I just wanna mention here that this problem still persist.

I also accidentally added /dev to the pool, which took me a while to figure out the problem. After a 40s auto reboot, I disabled libvirtd.service, the problem got migrated. Then somehow I managed to remove /dev pool using virt-manager. Now the problem is solved.

Idk if it help but I’ll just leave the message here :slight_smile: