[SOLVED] Running vms with command line

Succulent of your garden · 2025-08-23 15:38:11

I'm making a script to launch vms with a hotkey: this is the main command line of the script as so far:

qemu-system-x86_64 -enable-kvm -smp 6 -m 8G -nic user,model=virtio -drive file=/blah/blah/blah/path_to_vm.qcow2,if=virtio -audio driver=pipewire,model=virtio

So first any recommendations for qemu-system-x86_64 ? If you think so, then It will highly appreciated

Second I'm not sure if the flag -nic user will use the virtual network. I'm running the network like this:

sudo virsh net-start default

This is to enable the network so virt-manager can connect the machine to the internet using NAT, but I'm not sure if the "-nic user" flag will make the use of the default network or not.

Last edited by Succulent of your garden (2025-10-05 12:48:55)

ajgringo619 · 2025-08-23 15:47:44

Why not just use sudo virsh start domain_name?

Succulent of your garden · 2025-08-23 16:04:55

ajgringo619 wrote:

Why not just use sudo virsh start domain_name?

Does that starts the machine but with visual output ? I need to see the desktop of the machine.

So I'm troubleshooting this now: the machine is in not in the /blah/blah/blah folder, it is in the /var/lib/libvirt, by defautl virt-manager can launch the iso. The problem is that the script doesn't, it said that it does not have the permissions to read the .qcow 2 file. I'm able to launch the vm using virt-manager in the /var/lib/libvirt, but since my script is another folder and launched by my user [which is in the libvirt group btw] I don't see the reason why this is not working.

Any recommendations for hardening the setup, including the path of the vm are welcome

So which setup is probably recommended for this context ? Any changes that will make the system more robust will also be appreciated.

Last edited by Succulent of your garden (2025-08-23 16:06:01)

ajgringo619 · 2025-08-23 16:07:57

No, that command only starts the VM. Here's an example I used with a NixOS VM, using virt-viewer:

sudo virsh start nix-xfce-tst; virt-viewer --connect qemu:///system --full-screen --domain-name nix-xfce-tst --wait

EDIT: I think I misread your last comment. If you're looking to just start a VM, then the first command I gave will work.

Last edited by ajgringo619 (2025-08-23 18:25:32)

Lone_Wolf · 2025-08-24 11:05:53

virsh start domain_name actually starts libvirt and tells it to use the settings in the xml-file called domain_name .
That can be a vm run under qemu, but also something entirely different.

Many people that prefer starting qemu from CLI don't want to use a frontend, but control qemu directly .

Succulent of your garden : decide first how you want to setup & control the VM.
If you prefer a gui there are other options then libvirt like gonome-boxes.

Keep in mind that many of the threads about 'qemu' issues on this forum turn out to be libvirt/virsh issues.

Succulent of your garden · 2025-08-24 16:46:10

I want to use a gui to see the virtual machine, is not for production environment or testing, is just a regular virtual machine that I want to have to do things in it, and not in the host system.

So my approach is to use the initial line of command suggested by me, since I have another machine but without arch, and works. With that I'm able to run and open a window with the output display of the virtual machine. I like this approach because I don't want to use gnome-boxes or virt-manager to open a window display for the vm. The main reason for this is so I can use super key + F1 to launch my vm in my WM keybindings, but I had made the installation and config with virt-manager because for troubleshooting the xml is more easily, but I don't want to every time that I need to open the vm went to open virt-manager and then open another window to launch the machine, I just want super + F1 to just display the machine starting and see the booting process instantly.

But the current problem is this now in my command, as I said before:

A potplant from the past wrote:

The problem is that the script doesn't, it said that it does not have the permissions to read the .qcow 2 file. I'm able to launch the vm using virt-manager in the /var/lib/libvirt, but since my script is another folder and launched by my user [which is in the libvirt group btw] I don't see the reason why this is not working.

Last edited by Succulent of your garden (2025-08-24 16:48:25)

Lone_Wolf · 2025-08-25 12:18:24

for clarity :
/blah/blah/blah/path_to_vm.qcow2 is the file the user can't access ?

Please post the outputs of

$ ls -l /blah1/blah2/blah3/path_to_vm.qcow2
$ stat /blah1/blah2/blah3/path_to_vm.qcow2

Succulent of your garden · 2025-09-01 01:32:04

Hi sorry for answering this a little bit late, I'm currently very busy doing many things in parallel and I almost forgot this, I was unable in the job days of the week to answer to this post. Nevertheless thank so much for helping me here

So:

Lone__Wolf wrote:

/blah/blah/blah/path_to_vm.qcow2 is the file the user can't access ?

Yes, If I do the command, this one complain about it .

the /blahb/blah/blah path is in reality /var/lib/libvirt/images which at least virt manager is able to launch the virtual machines, outside of it it seem that it can't.

ls -l to the vm gives this:

.rw------- 38G libvirt-qemu 31 Aug 21:28  vm1.qcow2

the stat command gives this:

  File: vm1.qcow2
  Size: 37586927616	Blocks: 23910072   IO Block: 4096   regular file
Device: 254,0	Inode: 192806979   Links: 1
Access: (0600/-rw-------)  Uid: (  966/libvirt-qemu)   Gid: (  966/libvirt-qemu)
Access: 2025-08-31 21:30:01.623903657 -0400
Modify: 2025-08-31 21:29:44.800273463 -0400
Change: 2025-08-31 21:29:44.800273463 -0400
 Birth: 2025-08-02 08:52:37.668459933 -0400

So what do you think about this ? I really want to use that command so I can see the display of the vm instantly.

Once again thanks for the help

Last edited by Succulent of your garden (2025-09-01 01:32:35)

Head_on_a_Stick · 2025-09-01 06:57:55

If you're starting the VM with the qemu-system-x86_64 command then you don't need to use libvirt (or whatever the stupid abstraction layer is called) and the disk image can be owned by your normal user.

I use 2 shell functions for installing to the disk image and running the system once it is installed:

~$ functions                                                                   
function kvm-efi {
    qemu-system-x86_64 -enable-kvm -device intel-iommu -m 2G -cpu host -machine q35 -drive format=raw,cache=none,if=virtio,file="$1" -drive if=pflash,format=raw,readonly=on,file=/home/empty/qemu/OVMF_CODE.4m.fd -drive if=pflash,format=raw,file=/home/empty/qemu/OVMF_VARS_4M.secboot.fd -device virtio-vga-gl -display gtk,gl=on -device virtio-sound-pci,audiodev=my_audiodev -audiodev pa,id=my_audiodev 
} 
function kvm-install {
    qemu-system-x86_64 -enable-kvm -device intel-iommu -m 2G -cpu host -machine q35 -drive format=raw,cache=none,if=virtio,file="$1" -drive if=pflash,format=raw,readonly=on,file=/home/empty/qemu/OVMF_CODE.secboot.4m.fd -drive if=pflash,format=raw,file=/home/empty/qemu/OVMF_VARS_4M.secboot.fd -device virtio-vga-gl -display gtk,gl=on -device virtio-sound-pci,audiodev=my_audiodev -audiodev pa,id=my_audiodev -cdrom "$2" -boot d 
} 
~$

The OVMF (firmware) & disk image files are all in /home/empty/qemu/ so adjust that to your system. The OVMF drives can be ommitted if you want to run a non-UEFI VM, which can be simpler.

Lone_Wolf · 2025-09-01 09:56:45

The permissions on that folder are set so that members of libvirt-qemu that are not the libvirt-qemu user can do nothing with it.
In essence libvirt blocks all other users from accessing the vm directly .

Try HoaS suggestion.

Succulent of your garden · 2025-09-03 00:37:18

So virt-manager is in the libvirt group so it can access the vms right ? What If I do something with ACL ? do you think could I make something using access control list ? I really like the path where the vms is now.

Thanks both for the help!

Lone_Wolf · 2025-09-03 11:59:11

Virt-manager is probably run as root or as libvirt-qemu user .

Tou can try changing the group access permissions using chmod , but that change may not persist.

tekstryder · 2025-09-03 15:25:21

Succulent of your garden wrote:

the /blahb/blah/blah path is in reality /var/lib/libvirt/images which at least virt manager is able to launch the virtual machines, outside of it it seem that it can't.

Of course it can. I keep all my virtual disk images on a separate partition (/mnt/Virtual-Disks (below)).

NAME             FSTYPE            FSVER LABEL                  UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                                                                 
└─sda1           linux_raid_member 1.2   boomshanka:data-raid10 b74ab1bb-c3d9-025b-3403-1ceea7e22752                
  └─md127        crypto_LUKS       1                            601a9ee4-69f3-483c-b25e-72bffdd83792                
    └─crypt-data ext4              1.0   Data                   bf8e0350-d26a-45dc-adff-4864f79a491d    7.8T    28% /mnt/Data
sdb                                                                                                                 
└─sdb1           linux_raid_member 1.2   boomshanka:data-raid10 b74ab1bb-c3d9-025b-3403-1ceea7e22752                
  └─md127        crypto_LUKS       1                            601a9ee4-69f3-483c-b25e-72bffdd83792                
    └─crypt-data ext4              1.0   Data                   bf8e0350-d26a-45dc-adff-4864f79a491d    7.8T    28% /mnt/Data
sdc                                                                                                                 
└─sdc1           linux_raid_member 1.2   boomshanka:data-raid10 b74ab1bb-c3d9-025b-3403-1ceea7e22752                
  └─md127        crypto_LUKS       1                            601a9ee4-69f3-483c-b25e-72bffdd83792                
    └─crypt-data ext4              1.0   Data                   bf8e0350-d26a-45dc-adff-4864f79a491d    7.8T    28% /mnt/Data
sdd                                                                                                                 
└─sdd1           linux_raid_member 1.2   boomshanka:data-raid10 b74ab1bb-c3d9-025b-3403-1ceea7e22752                
  └─md127        crypto_LUKS       1                            601a9ee4-69f3-483c-b25e-72bffdd83792                
    └─crypt-data ext4              1.0   Data                   bf8e0350-d26a-45dc-adff-4864f79a491d    7.8T    28% /mnt/Data
sde                                                                                                                 
├─sde1           exfat             1.0   scratch                EDBF-D02A                                           
├─sde2           ext4              1.0   debian-backup          5f406f6b-5e78-49d7-8e21-8ec1b7c99fb9                
└─sde3           ext4              1.0   arch-backup            e0fc1072-d556-41f2-9acf-240e6e4b5556                
sdf                                                                                                                 
├─sdf1           ext4              1.0   virtual-disks          77b732ef-e9e8-45e9-bac1-f8686bb6e1d9   75.8G    33% /mnt/Virtual-Disks
├─sdf2           ntfs                    windows-backup         2375A98EF80C84DC                                    
└─sdf3           vfat              FAT32 ESP-BACKUP             058E-A228                                           
nvme0n1                                                                                                             
├─nvme0n1p1      vfat              FAT32 ESP                    F280-E596                                           
├─nvme0n1p2      ext4              1.0   arch                   d475ae3e-f8c5-4e02-9c23-541d4667d78e   28.9G    63% /
├─nvme0n1p3      ext4              1.0   debian                 1f4bfa2c-f2b0-492c-99eb-42e4b395d451                
├─nvme0n1p4      ntfs                    windows                FCF80CCAF80C84DC                                    
└─nvme0n1p5      ntfs                                           08AC713EAC7126FA

Lone_Wolf wrote:

Virt-manager is probably run as root or as libvirt-qemu user .

It shouldn't be. It should be run as the non-priveledged user launching the application.

Succulent of your garden wrote:

I'm making a script to launch vms with a hotkey

Succulent of your garden wrote:

Any recommendations for hardening the setup, including the path of the vm

Succulent of your garden wrote:

I want to use a gui to see the virtual machine

@Succulent of your garden:

You've got multiple "wants" listed in this thread. Are you looking now to manage your VMs with virt-manager and libvirt?

If so, follow the wiki(s) closely and perhaps consider opening a separate thread specific to that topic if you run into issues.

• https://wiki.archlinux.org/title/Libvirt
• https://wiki.archlinux.org/title/Virt-manager

I also recommend setting up modular daemons from the get-go.

• https://libvirt.org/daemons.html#modular-driver-daemons

Head_on_a_Stick · 2025-09-03 16:58:24

Missed this:

Succulent of your garden wrote:

Any recommendations for hardening the setup

Virtual machines are insecure, don't listen to the Qubes hype, it is nonsense.

I will appeal to authority here, in the form of OpenBSD's lead developer:

Theo de Raadt wrote:

> Virtualization seems to have a lot of security benefits.
You've been smoking something really mind altering, and I think you should share it.
x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit.
You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.
You've seen something on the shelf, and it has all sorts of pretty colours, and you've bought it.
That's all x86 virtualization is.

https://marc.info/?l=openbsd-misc&m=119318909016582

TooOldForDeInterwebz · 2025-09-04 07:59:42

I think we need to look at the input to correctly interpet Theo de Raadt's output.

Why not:

# start the VM
virsh --connect qemu:///system start "VM-NAME"
# connect to the VM
virt-manager --connect qemu:///system --show-domain-console "VM-NAME"

From:
https://unix.stackexchange.com/question … mmand-line

Succulent of your garden · 2025-09-04 23:26:56

# start the VM
virsh --connect qemu:///system start "VM-NAME"
# connect to the VM
virt-manager --connect qemu:///system --show-domain-console "VM-NAME"

By VM-NAME how can get the proper VM name ? Since it doesn't show with virsh list. Does this would go straight into /var/lib/libvirt ?

Head_on_a_stick wrote:

I will appeal to authority here, in the form of OpenBSD's lead developer:

Yeah, I get it. Virtual Machines are not "security" condoms as some people tend to think

Last edited by Succulent of your garden (2025-09-04 23:28:52)

TooOldForDeInterwebz · 2025-09-05 07:10:46

Succulent of your garden wrote:

By VM-NAME how can get the proper VM name ? Since it doesn't show with virsh list. Does this would go straight into /var/lib/libvirt ?

How can you launch them at all if you don't know what they are called? I was under the impression that what is being referred to as domain_name in previous replies in this thread, is what the person on StackExchange called VM-NAME.

Apologies for my misunderstanding and not useful input.

Lone_Wolf · 2025-09-05 09:14:12

https://wiki.gentoo.org/wiki/Libvirt/domain wrote:

A domain represents a virtualized instance within the libvirtd library/package/API. This instance could be a virtual machine, a container, or any other virtualized environment managed by libvirt.

For everything managed by libvirt it creates an xml-file that stores the settings used by libvirt .
The filename without the xml extension file is the domain-name .

In order to use an existing qemu commandline with libvirt you have to create an xml file that has the desired settings in the format understood by libvirt.

Read up on the virt-install command.

Sidenote:
it's possible to have a libvirt domain_name of "My first VM" that starts an image called dangerousmalware-don't-execute.qcow .

Last edited by Lone_Wolf (2025-09-05 09:15:34)

Succulent of your garden · 2025-09-14 13:53:01

Okey now I had the time to check my issue more deeply. So I was able to get the vm name using virsh list, but with sudo. If I just use virsh list then the vm name is not being showed in the terminal.

I tried to change the qcow2 file into another folder. So I move the file vm.cqow2 file from /var/libvirt/images to basically my home folder. I tried to run my script not using the /var/lib/libvrit path now, but I get always the same error:

qemu-system-x86_64: -drive file=vm.qcow2,if=virtio: Could not open 'vm.qcow2': Permission denied

I tried to run the script with changing the file permission, even I tried with chmod 777 just to be 100% is not the script what is creating the issue [ I tried first with many number combinations of course, I knew that 777 was mostly going to fail when I exec the script, I tried just to basically write that here, it's not a permission issue on the script].

But I don't get it why I'm not able to execute the vm with my script. I'm in the libvirt group, I can see that clearly when I do the id command that my user is in the libvirt group. It's obvious that the script is going to work if I just launch it with sudo, but that's obviously not a good idea. So what could it be that I'm not allow to run vms as my normal user ? Just a quick reminder that I can run it without using sudo from virt-manager using the same user session.

Last edited by Succulent of your garden (2025-09-14 13:55:14)

Succulent of your garden · 2025-10-05 12:46:23

So after weeks of much things to do and trying to solve this issue, I made it. I'm going to write here the solution so if other users does want to do the same and have similar issues can understand better what was going on and how to make it work:

The main issue was that virtual machine image was not owned by my user, you change the user ownership with chown and the vm works with the script. Also maybe you can put it with ACL using setfacl command, but I haven't tried that, and I'm not going to do it because I lack the time now to experiment with things and I found a better approach, which I would suggest to use.

If you want to run virtual machines that had been created with virt-manager with a shortcut, which is my case, less typing better in this case for me, you can do it with this script:

#!/bin/sh
virsh --connect qemu:///system start "Put_your_virtual_machine_name_here"
virt-manager --connect qemu:///system --show-domain-console "Put_your_virtual_machine_name_here"

Add this script to you favorite WM or Desktop in a keybinding and you will have the vm running into boot. The first line starts the vm and the second one shows the display of it. Probably this is the best approach.

My first approach which is this:

qemu-system-x86_64 -enable-kvm -smp 6 -m 8G -nic user,model=virtio -drive file=/blah/blah/blah/path_to_vm.qcow2,if=virtio -audio driver=pipewire,model=virtio

I don't recommend it anymore, It is possible to make it run it, I was able to do it when I change the ownership of the vm image. The main advantage of this is that your topbar of the virtual machine host window is less bloated, I mean you have very few options, virt-manager gives you more, but you can make it to show less stuff, if you do that, you are using the exact size of the top bar using my first approach, so you won more space to show in your vm and is perfect for using it while you are doing things with your WM for example, you can switch between windows very easily.

So if for some reason you want a less bloated system then you can try my first approach, which in theory you can create a virtual machine without installing virt-manager. But if you want the comfy-ness of virt-manager then I would suggest going to the second approach, which helps you in changing more easily stuff in your xml file of the virtual machine. But if you are more tech-savy or need a less bloated system, then the first one is an option, it's up to you to decide which approach to choose ^^

So that's it, I'm going to mark this post as solved ^^
Thanks also for anyone here that were trying to help.

Last edited by Succulent of your garden (2025-10-05 12:48:39)

Arch Linux

#1 2025-08-23 15:38:11

[SOLVED] Running vms with command line

#2 2025-08-23 15:47:44

Re: [SOLVED] Running vms with command line

#3 2025-08-23 16:04:55

Re: [SOLVED] Running vms with command line

#4 2025-08-23 16:07:57

Re: [SOLVED] Running vms with command line

#5 2025-08-24 11:05:53

Re: [SOLVED] Running vms with command line

#6 2025-08-24 16:46:10

Re: [SOLVED] Running vms with command line

#7 2025-08-25 12:18:24

Re: [SOLVED] Running vms with command line

#8 2025-09-01 01:32:04

Re: [SOLVED] Running vms with command line

#9 2025-09-01 06:57:55

Re: [SOLVED] Running vms with command line

#10 2025-09-01 09:56:45

Re: [SOLVED] Running vms with command line

#11 2025-09-03 00:37:18

Re: [SOLVED] Running vms with command line

#12 2025-09-03 11:59:11

Re: [SOLVED] Running vms with command line

#13 2025-09-03 15:25:21

Re: [SOLVED] Running vms with command line

#14 2025-09-03 16:58:24

Re: [SOLVED] Running vms with command line

#15 2025-09-04 07:59:42

Re: [SOLVED] Running vms with command line

#16 2025-09-04 23:26:56

Re: [SOLVED] Running vms with command line

#17 2025-09-05 07:10:46

Re: [SOLVED] Running vms with command line

#18 2025-09-05 09:14:12

Re: [SOLVED] Running vms with command line

#19 2025-09-14 13:53:01

Re: [SOLVED] Running vms with command line

#20 2025-10-05 12:46:23

Re: [SOLVED] Running vms with command line

Board footer