On Fri, Oct 27, 2023 at 05:17:46AM -0400, The Wanderer 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.) >
People's experience varies: I've used Virtualbox in the past, Hyper-V under Windows and VMWare Workstation - Virt-manager provides as easy a front end to KVM for me. It does help if you select the "Customise configuration" option before beginning install at step 5 of 5 <snip> > > 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. > See the "configure before install" which opens this up more - you can also see this by viewing/modifying settings - but you normally have to make sure that the VM is shut down. > (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. > All the VM solutions essentially have a text backend and something configurable: virt-manager is just a nice front end to things like virsh and means that you can get stuff done quickly. That said, I tend to be simplistic: one or two VMs which have access via the host network, no bonding, nothing too fancy. I think there's probably more documentation for KVM out there than anything else, one way and another. > -- > 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 > All the very best, as ever, Andy
