With Virt-Manager, you should have the option to choose an existing disk image. In that dialog, you can create an image in any of the pools (you can also add pools in that dialog), and that will let you change the file name and disk size.
I am not ay my laptop currently, but I can take and share some screenshots later today. On October 27, 2023 9:17:46 AM UTC, The Wanderer <wande...@fastmail.fm> wrote: >On 2023-10-26 at 15:28, Andrew M.A. Cater wrote: > >> Apt-get install virt-manager will pull in all the associated >> qemu/KVM packages you might need. It should be at least as >> straightforward to use as Virtualbox. > >I've seen people state or suggest multiple times that virt-manager >should be, as you say, as straightforward to use as VirtualBox, and that >was what I expected to find when I tried to use it myself - but even >once I got around the issues that arose from my not using systemd et >cetera and could actually use the program, it is not what I actually found. > >(I very much hope that what I am about to describe is wrong, and that >people will explain how/why it's wrong, such that I can get out of the >situation described and into a state where I can actually use >virt-manager in a way that I could find useful. It is not my intention >to spread FUD or falsehoods, even if some of the below may look like it >would fall within those categories.) > > >From what I recall from having used VirtualBox in the past, its workflow >is fairly similar to what I see in using VMWare Workstation in a >(work-related) Windows environment. When you create a new VM, it prompts >you for where the VM's files should be stored, and then for details >about the VM's configuration (disk sizes, hardware devices, et cetera), >and optionally lets you specify what will be done to install the OS that >will run in the VM - and then with that done, the VM is ready, and you >can boot it up or create a snapshot (using a graphical >snapshot-management interface) or make further configuration edits or do >whatever else you will with it. > >With virt-manager, from what I recall (it has been a while since I last >tried), the workflow was quite different. IIRC, I didn't even try using >qemu as a backend, because AFAIK it doesn't support hierarchical VM >snapshots and that's a feature I very much expect to rely on; instead I >think I went with KVM. With that backend, AFAIR I didn't even get >prompted for where the VM's file should be stored; instead, the location >where the system stores files appears to be defined in a system-wide >config file, and to not be modifiable on a per-VM basis (except relative >to that system-wide root). That's a problem, because when I partitioned >this system I expected to be able to store VM files in the same massive >data partition as I allocated for other large data; the default >system-wide location doesn't have the space to do much with. It also >doesn't work when the system may have multiple users who may want to >manage VMs separately from one another (though, fortunately, this is >more an abstract concern rather than one that affects me in practice). > >With VMWare Workstation and what I think I I recall from VirtualBox, >once a VM is created, the resulting files are owned by the user who ran >the program. With what I recall from when I tried virt-manager, even if >I redirected the file storage location to be under the larger data >partition, the files were owned by another user, related to libvirt. >That's undesirable when trying to store VM files per-user in a per-user >location, since the user won't be able to work with them (moving them >around, editing details, etc.) except through programs running with that >other user's access. > >When I accepted that and tried to proceed anyway, for the sake of >experimentation, IIRC, I ran into obstacles trying to set up the >necessary virtual hardware for the VM - in particular, IIRC, a virtual >CD drive pointed at the ISO that would be used to install the OS. (This >part I am less certain about than even the above; it's been rather a >while, and I was stressed enough by the time I hit this point that I may >have blanked out more of the details in self-defense.) At that point, I >gave up, at least in part for the sake of not piling more and more >stress on myself trying to get the ability to do things that would >hopefully enable me to reduce stress in other areas. > >(Writing this mail is already bringing back up all that stress, and I >hope it will not just wind up making things worse.) > > >So... either I somehow have managed to do things *100% completely >wrong*, or the workflow with virt-manager is not even remotely as >straightforward(ly usable) as the one I see with VMWare Workstation and >think I remember seeing with VirtualBox. > >I would *love* to be wrong about that, because there is a *lot* of stuff >that I'd like to do that would be *far* easier if I had discardable VM >snapshots to do it in. However, I also do not have the personal stress >to spare for experimenting with this blindly and bashing my head against >walls getting nowhere in those experiments. > >If there *is* a way to get virt-manager to support a VMWare( and, I >think, VirtualBox)-like workflow - with support for hierarchical nested >snapshots, and graphical management thereof, among other things - and >have things more-or-less Just Work, I would *love* to learn about it. > >-- > The Wanderer > >The reasonable man adapts himself to the world; the unreasonable one >persists in trying to adapt the world to himself. Therefore all >progress depends on the unreasonable man. -- George Bernard Shaw >
