So I went to the shares tab and saw that some of my shares had "illegal characters", apparently spaces in the share name aren't allowed anymore. So I renamed them, one of them was my VM share. And now when I'm trying to start the VM i get this:

I see that the first path has my old share name, but I can't figure out how to change it. I've looked at the source path in the xml view, and it has the correct path. If I change the vdisk location to just vdisk1.img it starts, but that restores the vm from before I took a snapshot it looks like. I've also rebooted to check if that would fix it, but no dice. I would like to fix the path so I can just start the VM and come back to where I was. The snapshot is old, so last option is to restore to that. Does Anyone have a clue how I could fix this?

tower-diagnostics-20251222-0045.zip

So I did a workaround for now. Since the webui didn't let me recreate the share with spaces, I just made a new top-level folder from cli, stopped the vm service and copied the data from the new, renamed share to the new, old name share. After restarting the array, the VM booted right back up to where I left it.

But I would still like to know how I can use my share without spaces and make the VM boot.

I forgot to change the vdisk location back to the path with spaces before I started the VM, but the VM booted anyway, now with the path to the share without spaces in the vdisk settings.

So there is a conflict here somewhere, and now I'm afraid to delete the share with spaces again in case it won't boot back up again. While I wait for some guidence I'll take the opportunity to back up the share to the array since I haven't done that in a long time. I would like to create another snapshot too, but with this path mess, I'm not sure it would do any good or even make things worse.

After some searches, I believe one option I could do is to block commit the changes from the snapshot to the base vdisk. My current state will then be transferred to the base image, if I understand correctly. Then just delete the snapshot, copy the vdisk back to the new share without spaces, and it should fire right back up? If I can just get the current state to the base image, I think I'm good, right?

When you do the block commit it will remove the snapshot. You would also need to update the XML as the path would be wrong.

The snapshotdb may be incorrect also. Can you cat /etc/libvirt/qemu/snapshotdb/VM name/snapshots.db

There is an option in qemu-img to rebase the base image in the overlay file but I have not tried. I would just do the commit and then move etc.

4 hours ago, SimonF said:

Can you cat /etc/libvirt/qemu/snapshotdb/VM name/snapshots.db

Does the vm service need to be started for this? I have nothing in the libvirt directory. Do you have any idea why I got the error in my first post btw?

3 minutes ago, strike said:

Does the vm service need to be started for this? I have nothing in the libvirt directory. Do you have any idea why I got the error in my first post btw?

The way snapshots work is it creates an overlay file which has a backing file. The VM could not find the backing file as it was moved. The info on the backing files are stored within the qcow2 file and not within the template.

Yes VM service needs to be started so the libvirt image file is mounted.

root@computenode:~# qemu-img info /mnt/user/domains2/Arch9/vdisk1.S20250321211701qcow2 | grep backing

backing file: /mnt/user/domains2/Arch9/vdisk1.img

backing file format: raw

This is what I have in the db:

{
    "02032025--generate": {
        "name": "02032025--generate",
        "parent": "Base",
        "state": "running",
        "desc": null,
        "memory": {
            "@attributes": {
                "snapshot": "external",
                "file": "\/mnt\/nvme\/VM disk share\/Windows 10\/memory02032025--generate.mem"
            }
        },
        "creationtime": "1740933832",
        "method": "QEMU",
        "backing": {
            "hdc": [
                "\/mnt\/nvme\/VM disk share\/Windows 10\/vdisk1.02032025--generateqcow2",
                "\/mnt\/nvme\/VM disk share\/Windows 10\/vdisk1.img"
            ],
            "rhdc": [
                "\/mnt\/nvme\/VM disk share\/Windows 10\/vdisk1.img",
                "\/mnt\/nvme\/VM disk share\/Windows 10\/vdisk1.02032025--generateqcow2"
            ]
        },
        "primarypath": "\/mnt\/nvme\/VM disk share\/Windows 10",
        "disks": [
            {
                "@attributes": {
                    "name": "hdc",
                    "snapshot": "external",
                    "type": "file"
                },
                "driver": {
                    "@attributes": {
                        "type": "qcow2"
                    }
                },
                "source": {
                    "@attributes": {
                        "file": "\/mnt\/nvme\/VM disk share\/Windows 10\/vdisk1.02032025--generateqcow2"
                    }
                }
            },
            {
                "@attributes": {
                    "name": "hdb",
                    "snapshot": "no"
                }
            }
        ]
    }

But if I do the block commit the snapshot will be deleted, doesn't the db get deleted too then? Or do I need the db if I just start with the base image after doing the block commit?

20 minutes ago, strike said:

But if I do the block commit the snapshot will be deleted, doesn't the db get deleted too then? Or do I need the db if I just start with the base image after doing the block commit?

The db is just tracking for the gui. If you put the files in the original directory it will do the block commit and remove the entries from the db.

1 minute ago, SimonF said:

The db is just tracking for the gui. If you put the files in the original directory it will do the block commit and remove the entries from the db.

Aight, thanks. I'll try that when the backup of my second VM share is finished.

3 hours ago, SimonF said:

The db is just tracking for the gui. If you put the files in the original directory it will do the block commit and remove the entries from the db.

Everything worked out nicely :)