Suppose I do all this successfully, and eventually have similar overcrowding issues on the boot drive; can I park a qcow2 on a different device and virt-manager will still list it and launch it?
I checked again - the folder below holds my old config files! However, it should contain your qcow2 files:
Ok, so I took the advice above, figuring a new install of mint would have fewer opportunities for error, had a minor panic when it wanted me to choose a mount point, guessed / and that seems to have gone ok. But I'm trying to import my old VMs, and that's not going so well.
I'd already created xml's by copy/paste from the old install (and BTW the old install is intact, presumably runnable should I need to), copied the qcow2 files into var...images, alongside the xml's, just so I didn't lose track of the xmls.
virt-manager didn't see them. I ran the virsh defines against the xmls, and they then appeared in virt-manager. But they don't run.
So I decide I'll make a quick accept-all-defaults vm with the name of one of my vms, paste in the xml, edit some filenames so my old qcow2 file replaces the newly created one, repeat for all my vms. Tedious, but should work. At the moment, it's not.
Trying to create an all new vm is generating a bunch of errors which it offers to fix, and it appears that's worked, but now I'm hitting a permission error I don't understand. (see image) quickstore is a folder I created early on, just to hold iso's and stuff. (As I fumbled through gpu passthrough learning curve, I installed a lot, so quickstore on 2nd nvme saved a lot of time.) Now, however, virt-manager says it can't search to it.
quickstore itself is now d777 permissions, and I even changed owner to my regular account. World should be able to see it, but I'm still getting this error.
I'm willing to totally start over with the mint reinstall if I have to, but I don't think that's really the problem: any suggestions on solving this permission problem? I had hoped moving a vm would be easier than this. thanks!
(oops, forgot the image. here it is...)
Attachments
Screenshot from 2024-01-06 00-14-46 quickstore access fault.png (22.91 KiB) Viewed 434 times
I managed a workaround: copied the key iso's to my Documents folder. Now I can make a new vm in the new mint using the usual virt-manager procedures.
But I've had no success migrating my old vms to the new mint. Every time I turn around, I get some kind of permission error. I played filename edit to make my old qcow2 have the name the brand new vm was created as, but when I paste the old VMs xml onto the new vm, it chokes vmname already exists with a uuid of blah.
I've tried renamiinng that xml file in etc/libvirt/qemu/, so that in theory that (new) vm's xml shouldn't exist, but it still complains already exists with uuid old-xml's-uuid-value.
I wouldn't keep hearing about how vms are portable if they just plain aren't, so I must be missing something.
And... I got past the uuid thing by dropping the old vm's xml straight into /etc/libvirt/quemu/ and editing the uuid, then rebooting before trying to use it.
That worked, but then attempts to launch the transplanted vm give errors failed to change permissions (but it doesn't say what permissions) so it can't access my Documents folder. So that folder worked for making a brand new vm on the new installation, but for some reason it's still spitting out the old, transplanted vm.
It can't be this hard, I must be missing something up the chain.
Ok gang, this insanity appears endless. I think the way forward is to vacuum off anything I really want to keep, wipe both nvme sticks, start over. I've done it all once, so it should be at least somewhat quicker the 2nd time.
Thanks for all the attempts to help, but I think this is another gordian knot; wipe and reinstall, the ancient cure-all for windows, seems to be the solution to this situation as well.
I am confused why I'm finding vm's so much less portable for me than they're reputed to be.
Moving VMs is not so easy. There are some tutorials, I've linked them in my recent post here: Script to Dump xml Configuration Files. To find the links, go further down to the "libvirt Storage Locations". The post also explains how to restore VM configurations.
Most people - me included - only use the Virtual Machine Manager (virt-manager), but that is just a front end to libvirt. virt-manager isn't capable of dealing with all the scenarios. You will sometimes have to use the "virsh" commands from command line to get things going.
If or when you reinstall Linux Mint, don't forget to install all the relevant packages you need for virtualization. Also, add your username to the libvirt group, otherwise you will have permission problems:
There is a silver lining to throwing in the towel on this installation: having done it once, there are a number of things I can do better in the layout and sysadmin area. May as well do those things now and get the system better laid out.
Yeah, I would suggest to have separate / and /home partitions, in addition to /boot/efi. Plus a swap partition. If you plan on storing the VMs in libvirt's default /var... location, it might be a good idea to have a separate large /var/lib/libvirt partition, or whereever the stuff is located.
But then, I don't like the way libvirt / virt-manager stores config files and VMs. I defined new storage locations in virt-manager and that works also reasonably well. However, I use LVM for all my storage. It's unfortunately command-line only, and it takes a little to get familiar with it. Redhat has probably the best LVM documentation: https://access.redhat.com/documentation ... umes/index.
