After playing around with virtual manager. I finally understood what is the problem. I am writing it down for the next one with the same problem.
As defined here: http://libvirt.org/drvqemu.html The libvirt QEMU driver is a multi-instance driver, providing a single system wide privileged driver (the "system" instance), and per-user unprivileged drivers (the "session" instance). The of the driver protocol is "qemu". Some example conection URIs for the libvirt driver are: qemu:///session, qemu:///system What is happening is that virtual manager lists only qemu://session (the user instance of driver) This instance "session" does not have privileges to write to system pool, it has only the privileges of the user. If someone is trying to create a new virtual disk from the "qemu://session" in the system pool, it will not work. If you are local admin of libvirt (by default all local admins are libvirtd admins too) you can add manage the system instance by navigating file->add connection and select hypervision QEMU/KVM and connection local. This will add one more connection that will be named localhost(System). This connection is priviliged you can even edit networks, create machines in the main pool and AFAIK vms that reside in system instance can be configured to auto-start too. This bug seems invalid, but there is a bug that the interface is not helping new-comer. A bug could be considered that the first time you run virtual-manager, it runs with "session" connection but the only available pool is from "system" -- virt-manager cannot create image file https://bugs.launchpad.net/bugs/405388 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
