If I run virt-manager on fedora 18, I see random instances of virtual machines named guestfs-something pop up for a second, then go away.
Where the heck do they come from and why is it happening?
On 01/27/2013 04:44 PM, Tom Horsley wrote:
If I run virt-manager on fedora 18, I see random instances of virtual machines named guestfs-something pop up for a second, then go away.
Where the heck do they come from and why is it happening?
If python-libguestfs is installed, virt-manager will use it in the background to determine guest OS and a few other interesting bits of info. Recently libguestfs grew the ability to do its magic using libvirt rather than a manually launched qemu instance. What you are probably seeing is those transient libguestfs appliances popping in and out of existence.
However I didn't think libguestfs was using libvirt by default on F18, and I didn't think it was connecting qemu:///system, so I'm not entirely sure what's happening. Are you using qemu:///session with virt-manager, or just the default libvirt connection?
Rich, any thoughts?
- Cole
On Sun, 27 Jan 2013 17:29:13 -0500 Cole Robinson wrote:
Are you using qemu:///session with virt-manager, or just the default libvirt connection?
I'm using whatever it uses by default. If I do a "Connection details" under Edit it says qemu:///system.
I don't know what libguestfs needs to look at either. I'm not running any VMs at all right now, yet every so often the guestfs-* machines pop up.
On Sun, Jan 27, 2013 at 06:01:13PM -0500, Tom Horsley wrote:
On Sun, 27 Jan 2013 17:29:13 -0500 Cole Robinson wrote:
Are you using qemu:///session with virt-manager, or just the default libvirt connection?
I'm using whatever it uses by default. If I do a "Connection details" under Edit it says qemu:///system.
I don't know what libguestfs needs to look at either. I'm not running any VMs at all right now, yet every so often the guestfs-* machines pop up.
It looks at each guest (at most once) in order to determine what OS it contains, which should result in a nice little OS icon next to each guest plus some extra information in various dialogs. See:
http://rwmj.wordpress.com/tag/virt-manager/
You can disable this by uninstalling python-libguestfs.
Rich.
On Sun, 27 Jan 2013 23:35:22 +0000 Richard W.M. Jones wrote:
It looks at each guest (at most once) in order to determine what OS it contains, which should result in a nice little OS icon next to each guest plus some extra information in various dialogs.
OK, that sort of explains it, but I see a lot more than N log entries for these things than the N virtual machines I have. Is the "at most once" each time I start virt-manager, or boot the system, or what?
On Sun, Jan 27, 2013 at 08:03:07PM -0500, Tom Horsley wrote:
On Sun, 27 Jan 2013 19:54:19 -0500 Tom Horsley wrote:
should result in a nice little OS icon next to each guest plus some extra information in various dialogs.
And I'm not getting any icons next to my Windows XP virtual machines (maybe that's why it keeps trying to run :-).
It should only try once per VM (per run of virt-manager). It will not retry if it fails to inspect a VM.
To understand why it would not be able to inspect the Windows XP guest, try the following command:
# virt-inspector -d NameOfWindowsVM > /tmp/winxp.xml
It should show one <operatingsystem> section containing an <icon>.
If it doesn't show that, then do:
# virt-inspector -d NameOfWindowsVM -x > /tmp/debug.txt 2>&1
and post the resulting data into a bug report.
Rich.
On Mon, 28 Jan 2013 08:46:50 +0000 Richard W.M. Jones wrote:
It should show one <operatingsystem> section containing an <icon>.
That works, and the "Overview" page in the info window when I open a virtual machine does have text to correctly identify the operating system, but I haven't yet seen anything actually display the icon :-).
On Mon, Jan 28, 2013 at 06:13:11AM -0500, Tom Horsley wrote:
On Mon, 28 Jan 2013 08:46:50 +0000 Richard W.M. Jones wrote:
It should show one <operatingsystem> section containing an <icon>.
That works, and the "Overview" page in the info window when I open a virtual machine does have text to correctly identify the operating system, but I haven't yet seen anything actually display the icon :-).
<icon> appears in the XML output of virt-inspector or not? The <icon> in the XML should be a base64-encoded PNG file.
virt-manager gets the data from exactly the same place as virt-inspector does, ie. from the libguestfs inspection API:
http://libguestfs.org/guestfs.3.html#inspection
Rich.
On Mon, Jan 28, 2013 at 09:53:00AM -0500, Tom Horsley wrote:
On Mon, 28 Jan 2013 14:39:00 +0000 Richard W.M. Jones wrote:
<icon> appears in the XML output of virt-inspector or not? The <icon> in the XML should be a base64-encoded PNG file.
Yes, the <icon> is in the xml, but nothing seems to draw it anywhere (that I've noticed).
Can you file a bug about this, including the XML.
Thanks,
Rich.
On Mon, 28 Jan 2013 18:37:36 +0000 Richard W.M. Jones wrote:
Can you file a bug about this, including the XML.
Here 'tis:
On Sun, Jan 27, 2013 at 07:54:19PM -0500, Tom Horsley wrote:
On Sun, 27 Jan 2013 23:35:22 +0000 Richard W.M. Jones wrote:
It looks at each guest (at most once) in order to determine what OS it contains, which should result in a nice little OS icon next to each guest plus some extra information in various dialogs.
OK, that sort of explains it, but I see a lot more than N log entries for these things than the N virtual machines I have. Is the "at most once" each time I start virt-manager, or boot the system, or what?
Once per run of virt-manager. There is a possibility that we should cache the information between runs, but it's not been implemented.
Rich.
On Sun, Jan 27, 2013 at 05:29:13PM -0500, Cole Robinson wrote:
On 01/27/2013 04:44 PM, Tom Horsley wrote:
If I run virt-manager on fedora 18, I see random instances of virtual machines named guestfs-something pop up for a second, then go away.
Where the heck do they come from and why is it happening?
If python-libguestfs is installed, virt-manager will use it in the background to determine guest OS and a few other interesting bits of info. Recently libguestfs grew the ability to do its magic using libvirt rather than a manually launched qemu instance. What you are probably seeing is those transient libguestfs appliances popping in and out of existence.
However I didn't think libguestfs was using libvirt by default on F18, and I didn't think it was connecting qemu:///system, so I'm not entirely sure what's happening. Are you using qemu:///session with virt-manager, or just the default libvirt connection?
Since Fedora 18, libvirt is now the default (but see below).
Rich, any thoughts?
Well this is a bug / missing feature in libvirt. When you create a transient guest libvirt forces you to give it a name, and effectively you have to give it a random name (because other instances of libguestfs might be running at the same time). So we give it a name like guestfs-<random>, but that unfortunately means that a persistent log file is created (probably under $HOME/.cache/libvirt/qemu/log), and you see oddly named guests coming into existence.
We should fix this, but for now you could:
(1) Ignore the guests.
(2) Switch libguestfs to using the 'appliance' backend, which means it directly runs qemu instead of using libvirt (this was the default before Fedora 18):
export LIBGUESTFS_ATTACH_METHOD=appliance
(3) Uninstall python-libguestfs.
Rich.
-
Cole Robinson -
Richard W.M. Jones -
Tom Horsley