I have been trying to get virt-manager to create a new VM for a while now but it just does not seem to work for me. I installed all the kvm stuff using the installer provided in YaST and then rebooted a couple times but still no luck. I am sure I overlooked something incredibly simple but I cant seem to figure out what it is. Here is the error I get and I am pretty sure the iso should be readable.
Unable to complete install: 'internal error: process exited while connecting to monitor: char device redirected to /dev/pts/2 (label charserial0)
qemu-system-x86_64: -drive file=/run/media/gum/Files/Downloads/OS/CentOS-6.5-x86_64-LiveDVD.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw: could not open disk image /run/media/gum/Files/Downloads/OS/CentOS-6.5-x86_64-LiveDVD.iso: Permission denied
'
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 96, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/create.py", line 2022, in do_install
guest.start_install(False, meter=meter)
File "/usr/lib/python2.7/site-packages/virtinst/Guest.py", line 1251, in start_install
noboot)
File "/usr/lib/python2.7/site-packages/virtinst/Guest.py", line 1319, in _create_guest
dom = self.conn.createLinux(start_xml or final_xml, 0)
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2886, in createLinux
if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: internal error: process exited while connecting to monitor: char device redirected to /dev/pts/2 (label charserial0)
qemu-system-x86_64: -drive file=/run/media/gum/Files/Downloads/OS/CentOS-6.5-x86_64-LiveDVD.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw: could not open disk image /run/media/gum/Files/Downloads/OS/CentOS-6.5-x86_64-LiveDVD.iso: Permission denied
Apologies for the thread, it seems it was an issue with systemd/udisks2 because the drive was mounted in /run. I was able to make the error go away by simply mounting in my home directory.
If you’re referring to the Guest VM’s diskfile,
Yes, it would help if you stored it in a persistent file location.
Don’t store files you want to keep in any place that has “run” or “tmp” in the path…
I think the error is about trying to read the .iso file not where I am storing the VM (since I tried storing it in the default location and it still gave that error).
If you’re referring to mounting an ISO so it can be used in a virtual CDROM on a Guest,
I generally create an ISO directory either off root (/) if those ISOs might be used by a variety of apps, I <might> create the ISO directory in my “/home/username/…” directory if I’m certain it will only be used by an app that will use my User’s security context. That way all my ISO files are in the same place, easy to find and guaranteed accessible.
Depending on the Guest OS, when the VM is created or the VM’s properties can be modified to point the virtual CDROM to the ISO file.
On some OS, it may not be obvious how to access the virtual CDROM, eg no Desktop or some distro with a complex mount architecture. In those cases, there is usually instructions to expose the ISO file to the guest and then I mount the ISO file in the Guest manually.
I think there is a bit of confusion about what I am mounting. The iso files are located on an secondary storage drive that I use to store all my large files (so that I dont kill my SSD and run out of space) which is mounted in /run when I use KDE to mount it. It seems that libvirt/kvm/whatever it is called could not read the actual iso file due to some read permission problems with the actual drive (/dev/sdb). I fixed it but just mounting the drive in my home directory instead of /run. Still though thank you for the explanation.
When you expose an ISO file to the virtual CDROM, it does not matter whether the ISO is mounted (is unnecessary) in the Host (in your case KDE).
So, what you saw in KDE is <not> what you should have been pointing your virtual CDROM to…
Instead it should have been pointing to the original source in your secondary storage… or what you appeared to do was simply to copy from secondary storage to primary storage. But, you could have simply pointed to the file in secondary storage.
