Hi,
What happened to the idea of displaying operating system icons on the VMs list? I found this[1] but, in the end, I don't know if the trademark issues were solved at all?
I'm really looking forward to this.
Thanks, Jorge
[1]: http://fedoraproject.org/wiki/Features/Virt-manager_Guest_Inspection
On 04/25/2014 11:55 PM, Jorge Fábregas wrote:
Hi,
What happened to the idea of displaying operating system icons on the VMs list? I found this[1] but, in the end, I don't know if the trademark issues were solved at all?
I'm really looking forward to this.
Thanks, Jorge
It's been available for a while, but you need to install python-guestfs to make it work, and the user you run virt-manager as needs read access to the VM disk images.
- Cole
On 04/26/2014 08:25 AM, Cole Robinson wrote:
It's been available for a while, but you need to install python-guestfs to make it work, and the user you run virt-manager as needs read access to the VM disk images.
Hi Cole,
The only package close to that is python-libguestfs. I installed it, restarted libvirt, fired up some VMs (after changing permissions) but didn't see any icons. Is the image recognition done upon libvirt startup or upon VM startup? I'll have to recheck permissions because they get overwritten eventually (leaving my regular user without access)...don't know if that's the problem.
Just curious: Isn't it more easier to create the icons based on the OS type (as specified by --os-type) instead of inspecting the actual images & having to install all these extra packages?
Thanks, Jorge
On 04/27/2014 09:44 AM, Jorge Fábregas wrote:
On 04/26/2014 08:25 AM, Cole Robinson wrote:
It's been available for a while, but you need to install python-guestfs to make it work, and the user you run virt-manager as needs read access to the VM disk images.
Hi Cole,
The only package close to that is python-libguestfs.
That's the correct package name, sorry for the confusion.
I installed it,
restarted libvirt, fired up some VMs (after changing permissions) but didn't see any icons. Is the image recognition done upon libvirt startup or upon VM startup? I'll have to recheck permissions because they get overwritten eventually (leaving my regular user without access)...don't know if that's the problem.
Inspection is done at virt-manager startup time. If it doesn't appear to work, run virt-manager --debug and check for error output.
Just curious: Isn't it more easier to create the icons based on the OS type (as specified by --os-type) instead of inspecting the actual images & having to install all these extra packages?
Yes that would be easier, but it hits the trademark issues mentioned in the feature page you referenced in the first mail, since we would need to ship windows icons etc. Pulling the icons out of the VMs was deemed legally acceptable though.
For linux distros we can probably ship freely distributable icons, maybe libosinfo could grow support for that in the future.
- Cole
On Sun, Apr 27, 2014 at 09:44:17AM -0400, Jorge Fábregas wrote:
On 04/26/2014 08:25 AM, Cole Robinson wrote:
It's been available for a while, but you need to install python-guestfs to make it work, and the user you run virt-manager as needs read access to the VM disk images.
Hi Cole,
The only package close to that is python-libguestfs. I installed it, restarted libvirt, fired up some VMs (after changing permissions) but didn't see any icons. Is the image recognition done upon libvirt startup or upon VM startup?
It is done on virt-manager start up + some time delay (30 seconds IIRC).
If it doesn't work for you please do use the --debug flag that Cole suggested and let us know in a bug report if something is going wrong.
I'll have to recheck permissions because they get overwritten eventually (leaving my regular user without access)...don't know if that's the problem.
Just curious: Isn't it more easier to create the icons based on the OS type (as specified by --os-type) instead of inspecting the actual images
As Cole said, it's not allowed for us (or any free software that wants to obey trademark law in the majority of countries in the world) to ship icons. The relevant legal thread is:
https://lists.fedoraproject.org/pipermail/legal/2011-April/thread.html#1604
In any case how would you know which icon to display without guest inspection? --os-type isn't recorded by libvirt, and even if it was it doesn't reliably tell you which guest is running.
& having to install all these extra packages?
Starting with libguestfs >= 1.26 (in Fedora >= 20 & Debian/ experimental), libguestfs is split into multiple subpackages, so it doesn't pull in large dependencies like XFS, clustered filesystems and virt-rescue tools.
Rich.
On 05/12/2014 04:35 PM, Richard W.M. Jones wrote:
It is done on virt-manager start up + some time delay (30 seconds IIRC).
If it doesn't work for you please do use the --debug flag that Cole suggested and let us know in a bug report if something is going wrong.
I just tried it again but it still doesn't work. I've waited more than 1 minute and also made sure that my regular user could list & copy the images within the images directory. Here's the output with the --debug switch:
http://fpaste.org/101471/40000304/
I got that block for every VM on my inventory. I'm running F20 with virt-preview repo fully updated.
As Cole said, it's not allowed for us (or any free software that wants to obey trademark law in the majority of countries in the world) to ship icons. The relevant legal thread is:
https://lists.fedoraproject.org/pipermail/legal/2011-April/thread.html#1604
Nice thread. Thanks.
In any case how would you know which icon to display without guest inspection? --os-type isn't recorded by libvirt, and even if it was it doesn't reliably tell you which guest is running.
Arggh I see. I didn't know it wasn't being recorded at all.
Starting with libguestfs >= 1.26 (in Fedora >= 20 & Debian/ experimental), libguestfs is split into multiple subpackages, so it doesn't pull in large dependencies like XFS, clustered filesystems and virt-rescue tools.
That's superb.
Thanks Richard for the input.
Regards, Jorge
On Tue, May 13, 2014 at 01:55:31PM -0400, Jorge Fábregas wrote:
On 05/12/2014 04:35 PM, Richard W.M. Jones wrote:
It is done on virt-manager start up + some time delay (30 seconds IIRC).
If it doesn't work for you please do use the --debug flag that Cole suggested and let us know in a bug report if something is going wrong.
I just tried it again but it still doesn't work. I've waited more than 1 minute and also made sure that my regular user could list & copy the images within the images directory. Here's the output with the --debug switch:
http://fpaste.org/101471/40000304/
I got that block for every VM on my inventory. I'm running F20 with virt-preview repo fully updated.
If you are running virt-manager as non-root, then it is probably this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1075164
You could try this before starting virt-manager as a workaround, but basically it's a permissions / authentication issue so it still might not work depending on your exact configuration:
export LIBGUESTFS_BACKEND=direct
Rich.
On 05/15/2014 04:09 AM, Richard W.M. Jones wrote:
You could try this before starting virt-manager as a workaround, but basically it's a permissions / authentication issue so it still might not work depending on your exact configuration:
export LIBGUESTFS_BACKEND=direct
Thanks, that did it but apparently the inspection only works with raw images; it didn't show any icon for all of the qcow2 based ones :(
On Thu, May 15, 2014 at 10:42:31AM -0400, Jorge Fábregas wrote:
On 05/15/2014 04:09 AM, Richard W.M. Jones wrote:
You could try this before starting virt-manager as a workaround, but basically it's a permissions / authentication issue so it still might not work depending on your exact configuration:
export LIBGUESTFS_BACKEND=direct
Thanks, that did it but apparently the inspection only works with raw images; it didn't show any icon for all of the qcow2 based ones :(
That must be something to do with permissions (perhaps on the backing files if they have them). libguestfs can deal with qcow2 files just fine. You'll have to run with the --debug option to find out what's really happening.
Rich.
-
Cole Robinson -
Jorge Fábregas -
Richard W.M. Jones