Hello,
I just upgraded some of my el6xen boxes to latest CentOS 6.7, Xen 4.4.3 and dom0 3.18.17 rpms, and noticed these new problems:
1) virt-manager fails to start with an error: "D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open "/var/lib/dbus/machine-id": No such file or directory"
And indeed.. there was no such file. Running command "dbus-uuidgen --ensure" fixed it, and virt-manager starts OK after that. So this was more for the mailinglist archives, if someone else meets the same issue.
2) virt-viewer doesn't work anymore.
It seems in el6.6 virt-viewer was version 0.6.0-11, but now in el6.7 it's 2.0-7, with a lot of changes..
If I try to use virt-viewer and run "virt-viewer <testvm>" command, I get an error popup dialog saying "Failed to connect: Display can only be attached through libvirt with --attach".
verbose debug output:
# virt-viewer -v --debug -c "xen://" testvm
(virt-viewer:9420): virt-viewer-DEBUG: Set connect info: (null),(null),(null),-1,(null),(null),(null),0 [root@fdell01 rpm]# less testvm01.txt (virt-viewer:9374): virt-viewer-DEBUG: connecting ... (virt-viewer:9374): virt-viewer-DEBUG: Opening connection to libvirt with URI xen:// Opening connection to libvirt with URI xen:// (virt-viewer:9374): virt-viewer-DEBUG: Add handle 7 1 0x865520 (virt-viewer:9374): virt-viewer-DEBUG: initial connect (virt-viewer:9374): virt-viewer-DEBUG: notebook show status 0x7f0000 (virt-viewer:9374): virt-viewer-DEBUG: virt_viewer_app_set_uuid_string: UUID changed to 587eb1bf-2427-a4d3-9113-d8bfb9911212 (virt-viewer:9374): virt-viewer-DEBUG: No guest-specific fullscreen config, using fallback (virt-viewer:9374): virt-viewer-DEBUG: notebook show status 0x7f0000 (virt-viewer:9374): virt-viewer-DEBUG: Guest testvm is running, determining display Guest testvm is running, determining display (virt-viewer:9374): virt-viewer-DEBUG: Set connect info: (null),(null),(null),-1,(null),(null),(null),0 (virt-viewer:9374): virt-viewer-DEBUG: Guest testvm has a vnc display Guest testvm has a vnc display (virt-viewer:9374): virt-viewer-DEBUG: Using direct libvirt connection (virt-viewer:9374): virt-viewer-DEBUG: Error operation forbidden: read only access prevents virDomainOpenGraphics (virt-viewer:9374): virt-viewer-DEBUG: After open connection callback fd=-1 (virt-viewer:9374): virt-viewer-DEBUG: Remove handle 1 7 (virt-viewer:9374): virt-viewer-DEBUG: Disposing window 0x7e1820
(virt-viewer:9374): virt-viewer-DEBUG: Set connect info: (null),(null),(null),-1,(null),(null),(null),0
And trying with the "attach" option:
# virt-viewer -v --debug -c "xen://" -a testvm
(virt-viewer:9374): virt-viewer-DEBUG: Set connect info: (null),(null),(null),-1,(null),(null),(null),0 [root@fdell01 rpm]# less testvm02.txt (virt-viewer:9389): virt-viewer-DEBUG: connecting ... (virt-viewer:9389): virt-viewer-DEBUG: Opening connection to libvirt with URI xen:// Opening connection to libvirt with URI xen:// (virt-viewer:9389): virt-viewer-DEBUG: Add handle 7 1 0x13ef580 (virt-viewer:9389): virt-viewer-DEBUG: initial connect (virt-viewer:9389): virt-viewer-DEBUG: notebook show status 0x137a000 (virt-viewer:9389): virt-viewer-DEBUG: virt_viewer_app_set_uuid_string: UUID changed to 587eb1bf-2427-a4d3-9113-d8bfb9911212 (virt-viewer:9389): virt-viewer-DEBUG: No guest-specific fullscreen config, using fallback (virt-viewer:9389): virt-viewer-DEBUG: notebook show status 0x137a000 (virt-viewer:9389): virt-viewer-DEBUG: Guest testvm is running, determining display Guest testvm is running, determining display (virt-viewer:9389): virt-viewer-DEBUG: Set connect info: (null),(null),(null),-1,(null),(null),(null),0 (virt-viewer:9389): virt-viewer-DEBUG: Guest testvm has a vnc display Guest testvm has a vnc display (virt-viewer:9389): virt-viewer-DEBUG: Using direct libvirt connection (virt-viewer:9389): virt-viewer-DEBUG: Error argument unsupported: fd passing is not supported by this connection (virt-viewer:9389): virt-viewer-DEBUG: After open connection callback fd=-1 (virt-viewer:9389): virt-viewer-DEBUG: Remove handle 1 7 (virt-viewer:9389): virt-viewer-DEBUG: Disposing window 0x136b820
(virt-viewer:9389): virt-viewer-DEBUG: Set connect info: (null),(null),(null),-1,(null),(null),(null),0
So it seems both connection types/methods now fail.. I'm not sure if the issue is in our custom libvirt build, or in Xen's qemu.. (googling for those errors reveals some related patches which also have patches for qemu: http://comments.gmane.org/gmane.comp.emulators.virt-tools/9185)
Error from the first attempt:
(virt-viewer:9374): virt-viewer-DEBUG: Using direct libvirt connection (virt-viewer:9374): virt-viewer-DEBUG: Error operation forbidden: read only access prevents virDomainOpenGraphics
Error from the second attempt: (virt-viewer:9389): virt-viewer-DEBUG: Using direct libvirt connection (virt-viewer:9389): virt-viewer-DEBUG: Error argument unsupported: fd passing is not supported by this connection
Thanks,
-- Pasi
On Sat, Sep 26, 2015 at 09:04:23PM +0300, Pasi Kärkkäinen wrote:
Hello,
I just upgraded some of my el6xen boxes to latest CentOS 6.7, Xen 4.4.3 and dom0 3.18.17 rpms, and noticed these new problems:
And third issue aswell:
3) Creating an HVM guest using virt-manager with file-based storage uses loopback-mount, not blktap
When I manually create a new Xen HVM guest using virt-manager, and choose file-based image for storage of the VM, it seems to be set up to use file: backend/driver with loopback-mounted image file:
<disk type='file' device='disk'> <driver name='file'/> <source file='/var/lib/libvirt/images/testvm2.img'/> <backingStore/> <target dev='hda' bus='ide'/> </disk>
# losetup -a /dev/loop0: [fd00]:1709109 (/var/lib/libvirt/images/testvm2.img)
With earlier versions of rpms similar setup used blktap2 backend.. (and yes, I do have blktap module loaded in dom0 kernel).
Thanks,
-- Pasi
On Sat, Sep 26, 2015 at 9:29 PM, Pasi Kärkkäinen pasik@iki.fi wrote:
On Sat, Sep 26, 2015 at 09:04:23PM +0300, Pasi Kärkkäinen wrote:
Hello,
I just upgraded some of my el6xen boxes to latest CentOS 6.7, Xen 4.4.3 and dom0 3.18.17 rpms, and noticed these new problems:
And third issue aswell:
- Creating an HVM guest using virt-manager with file-based storage uses loopback-mount, not blktap
When I manually create a new Xen HVM guest using virt-manager, and choose file-based image for storage of the VM, it seems to be set up to use file: backend/driver with loopback-mounted image file:
<disk type='file' device='disk'> <driver name='file'/> <source file='/var/lib/libvirt/images/testvm2.img'/> <backingStore/> <target dev='hda' bus='ide'/> </disk># losetup -a /dev/loop0: [fd00]:1709109 (/var/lib/libvirt/images/testvm2.img)
With earlier versions of rpms similar setup used blktap2 backend.. (and yes, I do have blktap module loaded in dom0 kernel).
I remember having to patch some dependency of virt-manager to give it the correct default driver name (something like, it got 'tap' but needed to be 'tap2'). In all likelihood, someone has sussed that 'tap' doesn't work and just replaced it with 'file'. Actually, it's fairly likely if they've updated stuff in CentOS that you're not getting the re-build virt-manager stuff either -- I may have to respin that one as well.
While we're here, could you give me a couple of virt-install and virt-viewer "smoketest" commands that I could add to my automated test scripts? ATM I'm testing libvirt by using virsh to import an xl .cfg file, but it would be better to have something that created the config end-to-end. Using virt-manager directly is probably more work than I'm up for in most cases, but hopefully if I can test the things it depends on I can notice this sort of breakage.
Thanks, -George
On Tue, Sep 29, 2015 at 12:37:25PM +0100, George Dunlap wrote:
On Sat, Sep 26, 2015 at 9:29 PM, Pasi Kärkkäinen pasik@iki.fi wrote:
On Sat, Sep 26, 2015 at 09:04:23PM +0300, Pasi Kärkkäinen wrote:
Hello,
I just upgraded some of my el6xen boxes to latest CentOS 6.7, Xen 4.4.3 and dom0 3.18.17 rpms, and noticed these new problems:
And third issue aswell:
- Creating an HVM guest using virt-manager with file-based storage uses loopback-mount, not blktap
When I manually create a new Xen HVM guest using virt-manager, and choose file-based image for storage of the VM, it seems to be set up to use file: backend/driver with loopback-mounted image file:
<disk type='file' device='disk'> <driver name='file'/> <source file='/var/lib/libvirt/images/testvm2.img'/> <backingStore/> <target dev='hda' bus='ide'/> </disk># losetup -a /dev/loop0: [fd00]:1709109 (/var/lib/libvirt/images/testvm2.img)
With earlier versions of rpms similar setup used blktap2 backend.. (and yes, I do have blktap module loaded in dom0 kernel).
I remember having to patch some dependency of virt-manager to give it the correct default driver name (something like, it got 'tap' but needed to be 'tap2'). In all likelihood, someone has sussed that 'tap' doesn't work and just replaced it with 'file'. Actually, it's fairly likely if they've updated stuff in CentOS that you're not getting the re-build virt-manager stuff either -- I may have to respin that one as well.
I think it's specified at least in python-virtinst. See these emails from a few years back about the tap/tap2-issue:
https://www.redhat.com/archives/virt-tools-list/2013-June/msg00037.html https://www.redhat.com/archives/virt-tools-list/2013-June/msg00039.html
While we're here, could you give me a couple of virt-install and virt-viewer "smoketest" commands that I could add to my automated test scripts? ATM I'm testing libvirt by using virsh to import an xl .cfg file, but it would be better to have something that created the config end-to-end. Using virt-manager directly is probably more work than I'm up for in most cases, but hopefully if I can test the things it depends on I can notice this sort of breakage.
The problem with virt-viewer issue is that it gives the "error popup" in the GUI, so there's no way to figure out it didn't work without looking at the GUI and interacting with the gui..
Not easy to script/automate..
Thanks, -George
-- Pasi
On 09/29/2015 07:55 AM, Pasi Kärkkäinen wrote:
On Tue, Sep 29, 2015 at 12:37:25PM +0100, George Dunlap wrote:
On Sat, Sep 26, 2015 at 9:29 PM, Pasi Kärkkäinen pasik@iki.fi wrote:
On Sat, Sep 26, 2015 at 09:04:23PM +0300, Pasi Kärkkäinen wrote:
Hello,
I just upgraded some of my el6xen boxes to latest CentOS 6.7, Xen 4.4.3 and dom0 3.18.17 rpms, and noticed these new problems:
And third issue aswell:
- Creating an HVM guest using virt-manager with file-based storage uses loopback-mount, not blktap
When I manually create a new Xen HVM guest using virt-manager, and choose file-based image for storage of the VM, it seems to be set up to use file: backend/driver with loopback-mounted image file:
<disk type='file' device='disk'> <driver name='file'/> <source file='/var/lib/libvirt/images/testvm2.img'/> <backingStore/> <target dev='hda' bus='ide'/> </disk># losetup -a /dev/loop0: [fd00]:1709109 (/var/lib/libvirt/images/testvm2.img)
With earlier versions of rpms similar setup used blktap2 backend.. (and yes, I do have blktap module loaded in dom0 kernel).
I remember having to patch some dependency of virt-manager to give it the correct default driver name (something like, it got 'tap' but needed to be 'tap2'). In all likelihood, someone has sussed that 'tap' doesn't work and just replaced it with 'file'. Actually, it's fairly likely if they've updated stuff in CentOS that you're not getting the re-build virt-manager stuff either -- I may have to respin that one as well.
I think it's specified at least in python-virtinst. See these emails from a few years back about the tap/tap2-issue:
https://www.redhat.com/archives/virt-tools-list/2013-June/msg00037.html https://www.redhat.com/archives/virt-tools-list/2013-June/msg00039.html
This is indeed where it was patched before (as a stand alone program) .. have they now rolled that into virt-manager?
While we're here, could you give me a couple of virt-install and virt-viewer "smoketest" commands that I could add to my automated test scripts? ATM I'm testing libvirt by using virsh to import an xl .cfg file, but it would be better to have something that created the config end-to-end. Using virt-manager directly is probably more work than I'm up for in most cases, but hopefully if I can test the things it depends on I can notice this sort of breakage.
The problem with virt-viewer issue is that it gives the "error popup" in the GUI, so there's no way to figure out it didn't work without looking at the GUI and interacting with the gui..
Not easy to script/automate..
Thanks, -George
-- Pasi
On Tue, Sep 29, 2015 at 4:00 PM, Johnny Hughes johnny@centos.org wrote:
On 09/29/2015 07:55 AM, Pasi Kärkkäinen wrote:
On Tue, Sep 29, 2015 at 12:37:25PM +0100, George Dunlap wrote:
On Sat, Sep 26, 2015 at 9:29 PM, Pasi Kärkkäinen pasik@iki.fi wrote:
On Sat, Sep 26, 2015 at 09:04:23PM +0300, Pasi Kärkkäinen wrote:
Hello,
I just upgraded some of my el6xen boxes to latest CentOS 6.7, Xen 4.4.3 and dom0 3.18.17 rpms, and noticed these new problems:
And third issue aswell:
- Creating an HVM guest using virt-manager with file-based storage uses loopback-mount, not blktap
When I manually create a new Xen HVM guest using virt-manager, and choose file-based image for storage of the VM, it seems to be set up to use file: backend/driver with loopback-mounted image file:
<disk type='file' device='disk'> <driver name='file'/> <source file='/var/lib/libvirt/images/testvm2.img'/> <backingStore/> <target dev='hda' bus='ide'/> </disk># losetup -a /dev/loop0: [fd00]:1709109 (/var/lib/libvirt/images/testvm2.img)
With earlier versions of rpms similar setup used blktap2 backend.. (and yes, I do have blktap module loaded in dom0 kernel).
I remember having to patch some dependency of virt-manager to give it the correct default driver name (something like, it got 'tap' but needed to be 'tap2'). In all likelihood, someone has sussed that 'tap' doesn't work and just replaced it with 'file'. Actually, it's fairly likely if they've updated stuff in CentOS that you're not getting the re-build virt-manager stuff either -- I may have to respin that one as well.
I think it's specified at least in python-virtinst. See these emails from a few years back about the tap/tap2-issue:
https://www.redhat.com/archives/virt-tools-list/2013-June/msg00037.html https://www.redhat.com/archives/virt-tools-list/2013-June/msg00039.html
This is indeed where it was patched before (as a stand alone program) .. have they now rolled that into virt-manager?
I'm guessing updated packages in base have a higher version number than those in the xen4centos repos. Anyway, I'll take a look at some point.
-George
Hello,
Replying to myself.. see below for more details about the problem.
On Sat, Sep 26, 2015 at 09:04:23PM +0300, Pasi Kärkkäinen wrote:
- virt-viewer doesn't work anymore.
It seems in el6.6 virt-viewer was version 0.6.0-11, but now in el6.7 it's 2.0-7, with a lot of changes..
If I try to use virt-viewer and run "virt-viewer <testvm>" command, I get an error popup dialog saying "Failed to connect: Display can only be attached through libvirt with --attach".
verbose debug output:
# virt-viewer -v --debug -c "xen://" testvm
(virt-viewer:9420): virt-viewer-DEBUG: Set connect info: (null),(null),(null),-1,(null),(null),(null),0 [root@fdell01 rpm]# less testvm01.txt (virt-viewer:9374): virt-viewer-DEBUG: connecting ... (virt-viewer:9374): virt-viewer-DEBUG: Opening connection to libvirt with URI xen:// Opening connection to libvirt with URI xen:// (virt-viewer:9374): virt-viewer-DEBUG: Add handle 7 1 0x865520 (virt-viewer:9374): virt-viewer-DEBUG: initial connect (virt-viewer:9374): virt-viewer-DEBUG: notebook show status 0x7f0000 (virt-viewer:9374): virt-viewer-DEBUG: virt_viewer_app_set_uuid_string: UUID changed to 587eb1bf-2427-a4d3-9113-d8bfb9911212 (virt-viewer:9374): virt-viewer-DEBUG: No guest-specific fullscreen config, using fallback (virt-viewer:9374): virt-viewer-DEBUG: notebook show status 0x7f0000 (virt-viewer:9374): virt-viewer-DEBUG: Guest testvm is running, determining display Guest testvm is running, determining display (virt-viewer:9374): virt-viewer-DEBUG: Set connect info: (null),(null),(null),-1,(null),(null),(null),0 (virt-viewer:9374): virt-viewer-DEBUG: Guest testvm has a vnc display Guest testvm has a vnc display (virt-viewer:9374): virt-viewer-DEBUG: Using direct libvirt connection (virt-viewer:9374): virt-viewer-DEBUG: Error operation forbidden: read only access prevents virDomainOpenGraphics (virt-viewer:9374): virt-viewer-DEBUG: After open connection callback fd=-1 (virt-viewer:9374): virt-viewer-DEBUG: Remove handle 1 7 (virt-viewer:9374): virt-viewer-DEBUG: Disposing window 0x7e1820
(virt-viewer:9374): virt-viewer-DEBUG: Set connect info: (null),(null),(null),-1,(null),(null),(null),0
And trying with the "attach" option:
# virt-viewer -v --debug -c "xen://" -a testvm
(virt-viewer:9374): virt-viewer-DEBUG: Set connect info: (null),(null),(null),-1,(null),(null),(null),0 [root@fdell01 rpm]# less testvm02.txt (virt-viewer:9389): virt-viewer-DEBUG: connecting ... (virt-viewer:9389): virt-viewer-DEBUG: Opening connection to libvirt with URI xen:// Opening connection to libvirt with URI xen:// (virt-viewer:9389): virt-viewer-DEBUG: Add handle 7 1 0x13ef580 (virt-viewer:9389): virt-viewer-DEBUG: initial connect (virt-viewer:9389): virt-viewer-DEBUG: notebook show status 0x137a000 (virt-viewer:9389): virt-viewer-DEBUG: virt_viewer_app_set_uuid_string: UUID changed to 587eb1bf-2427-a4d3-9113-d8bfb9911212 (virt-viewer:9389): virt-viewer-DEBUG: No guest-specific fullscreen config, using fallback (virt-viewer:9389): virt-viewer-DEBUG: notebook show status 0x137a000 (virt-viewer:9389): virt-viewer-DEBUG: Guest testvm is running, determining display Guest testvm is running, determining display (virt-viewer:9389): virt-viewer-DEBUG: Set connect info: (null),(null),(null),-1,(null),(null),(null),0 (virt-viewer:9389): virt-viewer-DEBUG: Guest testvm has a vnc display Guest testvm has a vnc display (virt-viewer:9389): virt-viewer-DEBUG: Using direct libvirt connection (virt-viewer:9389): virt-viewer-DEBUG: Error argument unsupported: fd passing is not supported by this connection (virt-viewer:9389): virt-viewer-DEBUG: After open connection callback fd=-1 (virt-viewer:9389): virt-viewer-DEBUG: Remove handle 1 7 (virt-viewer:9389): virt-viewer-DEBUG: Disposing window 0x136b820
(virt-viewer:9389): virt-viewer-DEBUG: Set connect info: (null),(null),(null),-1,(null),(null),(null),0
So it seems both connection types/methods now fail.. I'm not sure if the issue is in our custom libvirt build, or in Xen's qemu.. (googling for those errors reveals some related patches which also have patches for qemu: http://comments.gmane.org/gmane.comp.emulators.virt-tools/9185)
Error from the first attempt:
(virt-viewer:9374): virt-viewer-DEBUG: Using direct libvirt connection (virt-viewer:9374): virt-viewer-DEBUG: Error operation forbidden: read only access prevents virDomainOpenGraphics
Error from the second attempt: (virt-viewer:9389): virt-viewer-DEBUG: Using direct libvirt connection (virt-viewer:9389): virt-viewer-DEBUG: Error argument unsupported: fd passing is not supported by this connection
It seems CentOS 7.1 is still using virt-viewer version 0.6.0-12, and on centos7 virt-viewer works OK for me with xen/libvirt! So it seems only the newer virt-viewer 2.0 on CentOS 6.7 is broken ..
Both the c6 and c7 hosts have the same version of libvirt (1.2.15-3) from centos/xen repos:
c7 (works OK): virt-viewer-0.6.0-12.el7.x86_64 xen-4.4.3-2.el7.x86_64 libvirt-daemon-1.2.15-3.el7.x86_64 libvirt-daemon-config-network-1.2.15-3.el7.x86_64 libvirt-daemon-driver-network-1.2.15-3.el7.x86_64 libvirt-daemon-driver-xen-1.2.15-3.el7.x86_64 libvirt-daemon-driver-storage-1.2.15-3.el7.x86_64
c6 (doesn't work): virt-viewer-2.0-7.el6.x86_64 xen-4.4.3-1.el6.x86_64 libvirt-daemon-config-nwfilter-1.2.15-3.el6.x86_64 libvirt-daemon-driver-interface-1.2.15-3.el6.x86_64 libvirt-daemon-driver-nwfilter-1.2.15-3.el6.x86_64 libvirt-daemon-driver-xen-1.2.15-3.el6.x86_64 libvirt-daemon-driver-secret-1.2.15-3.el6.x86_64 libvirt-daemon-driver-storage-1.2.15-3.el6.x86_64 libvirt-daemon-driver-network-1.2.15-3.el6.x86_64 libvirt-daemon-config-network-1.2.15-3.el6.x86_64 libvirt-daemon-driver-nodedev-1.2.15-3.el6.x86_64 libvirt-daemon-1.2.15-3.el6.x86_64 libvirt-daemon-driver-lxc-1.2.15-3.el6.x86_64 libvirt-daemon-driver-libxl-1.2.15-3.el6.x86_64 libvirt-daemon-driver-qemu-1.2.15-3.el6.x86_64
Thanks,
-- Pasi
On Sat, Sep 26, 2015 at 7:04 PM, Pasi Kärkkäinen pasik@iki.fi wrote:
Hello,
I just upgraded some of my el6xen boxes to latest CentOS 6.7, Xen 4.4.3 and dom0 3.18.17 rpms, and noticed these new problems:
- virt-manager fails to start with an error: "D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open "/var/lib/dbus/machine-id": No such file or directory"
And indeed.. there was no such file. Running command "dbus-uuidgen --ensure" fixed it, and virt-manager starts OK after that. So this was more for the mailinglist archives, if someone else meets the same issue.
That's a bit strange -- maybe there was a post-processing thing added to 6.7 that does this, which my package lacks. I'll take a look at it when I get a chance.
(Or let me know and I'll post the virt-manager source so you can look at it and maybe send a pull request!)
- virt-viewer doesn't work anymore.
It seems in el6.6 virt-viewer was version 0.6.0-11, but now in el6.7 it's 2.0-7, with a lot of changes..
If I try to use virt-viewer and run "virt-viewer <testvm>" command, I get an error popup dialog saying "Failed to connect: Display can only be attached through libvirt with --attach".
verbose debug output:
# virt-viewer -v --debug -c "xen://" testvm
(virt-viewer:9420): virt-viewer-DEBUG: Set connect info: (null),(null),(null),-1,(null),(null),(null),0 [root@fdell01 rpm]# less testvm01.txt (virt-viewer:9374): virt-viewer-DEBUG: connecting ... (virt-viewer:9374): virt-viewer-DEBUG: Opening connection to libvirt with URI xen:// Opening connection to libvirt with URI xen:// (virt-viewer:9374): virt-viewer-DEBUG: Add handle 7 1 0x865520 (virt-viewer:9374): virt-viewer-DEBUG: initial connect (virt-viewer:9374): virt-viewer-DEBUG: notebook show status 0x7f0000 (virt-viewer:9374): virt-viewer-DEBUG: virt_viewer_app_set_uuid_string: UUID changed to 587eb1bf-2427-a4d3-9113-d8bfb9911212 (virt-viewer:9374): virt-viewer-DEBUG: No guest-specific fullscreen config, using fallback (virt-viewer:9374): virt-viewer-DEBUG: notebook show status 0x7f0000 (virt-viewer:9374): virt-viewer-DEBUG: Guest testvm is running, determining display Guest testvm is running, determining display (virt-viewer:9374): virt-viewer-DEBUG: Set connect info: (null),(null),(null),-1,(null),(null),(null),0 (virt-viewer:9374): virt-viewer-DEBUG: Guest testvm has a vnc display Guest testvm has a vnc display (virt-viewer:9374): virt-viewer-DEBUG: Using direct libvirt connection (virt-viewer:9374): virt-viewer-DEBUG: Error operation forbidden: read only access prevents virDomainOpenGraphics (virt-viewer:9374): virt-viewer-DEBUG: After open connection callback fd=-1 (virt-viewer:9374): virt-viewer-DEBUG: Remove handle 1 7 (virt-viewer:9374): virt-viewer-DEBUG: Disposing window 0x7e1820
(virt-viewer:9374): virt-viewer-DEBUG: Set connect info: (null),(null),(null),-1,(null),(null),(null),0
Searching around, it looks like the error above is pretty common as a first try, but that usually fall-backs are attempted which then succeed. The normal thing following "After open connection callback fd=-1" is "DEBUG: Opening direct TCP connection to display at 127.0.0.1:5901:-1".
Can you try virt-viewer -v --debug on 6.6 to see what things look like there?
-George
On Mon, Sep 28, 2015 at 03:22:10PM +0100, George Dunlap wrote:
On Sat, Sep 26, 2015 at 7:04 PM, Pasi Kärkkäinen pasik@iki.fi wrote:
Hello,
I just upgraded some of my el6xen boxes to latest CentOS 6.7, Xen 4.4.3 and dom0 3.18.17 rpms, and noticed these new problems:
- virt-manager fails to start with an error: "D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open "/var/lib/dbus/machine-id": No such file or directory"
And indeed.. there was no such file. Running command "dbus-uuidgen --ensure" fixed it, and virt-manager starts OK after that. So this was more for the mailinglist archives, if someone else meets the same issue.
That's a bit strange -- maybe there was a post-processing thing added to 6.7 that does this, which my package lacks. I'll take a look at it when I get a chance.
(Or let me know and I'll post the virt-manager source so you can look at it and maybe send a pull request!)
Sure :)
- virt-viewer doesn't work anymore.
It seems in el6.6 virt-viewer was version 0.6.0-11, but now in el6.7 it's 2.0-7, with a lot of changes..
If I try to use virt-viewer and run "virt-viewer <testvm>" command, I get an error popup dialog saying "Failed to connect: Display can only be attached through libvirt with --attach".
verbose debug output:
# virt-viewer -v --debug -c "xen://" testvm
(virt-viewer:9420): virt-viewer-DEBUG: Set connect info: (null),(null),(null),-1,(null),(null),(null),0 [root@fdell01 rpm]# less testvm01.txt (virt-viewer:9374): virt-viewer-DEBUG: connecting ... (virt-viewer:9374): virt-viewer-DEBUG: Opening connection to libvirt with URI xen:// Opening connection to libvirt with URI xen:// (virt-viewer:9374): virt-viewer-DEBUG: Add handle 7 1 0x865520 (virt-viewer:9374): virt-viewer-DEBUG: initial connect (virt-viewer:9374): virt-viewer-DEBUG: notebook show status 0x7f0000 (virt-viewer:9374): virt-viewer-DEBUG: virt_viewer_app_set_uuid_string: UUID changed to 587eb1bf-2427-a4d3-9113-d8bfb9911212 (virt-viewer:9374): virt-viewer-DEBUG: No guest-specific fullscreen config, using fallback (virt-viewer:9374): virt-viewer-DEBUG: notebook show status 0x7f0000 (virt-viewer:9374): virt-viewer-DEBUG: Guest testvm is running, determining display Guest testvm is running, determining display (virt-viewer:9374): virt-viewer-DEBUG: Set connect info: (null),(null),(null),-1,(null),(null),(null),0 (virt-viewer:9374): virt-viewer-DEBUG: Guest testvm has a vnc display Guest testvm has a vnc display (virt-viewer:9374): virt-viewer-DEBUG: Using direct libvirt connection (virt-viewer:9374): virt-viewer-DEBUG: Error operation forbidden: read only access prevents virDomainOpenGraphics (virt-viewer:9374): virt-viewer-DEBUG: After open connection callback fd=-1 (virt-viewer:9374): virt-viewer-DEBUG: Remove handle 1 7 (virt-viewer:9374): virt-viewer-DEBUG: Disposing window 0x7e1820
(virt-viewer:9374): virt-viewer-DEBUG: Set connect info: (null),(null),(null),-1,(null),(null),(null),0
Searching around, it looks like the error above is pretty common as a first try, but that usually fall-backs are attempted which then succeed. The normal thing following "After open connection callback fd=-1" is "DEBUG: Opening direct TCP connection to display at 127.0.0.1:5901:-1".
Can you try virt-viewer -v --debug on 6.6 to see what things look like there?
Yep, here's debug output from a working virt-viewer session with virt-viewer 0.6.0-11.el6 (from centos 6.6):
(virt-viewer:3989): virt-viewer-DEBUG: Insert window 0 0x1fba020 (virt-viewer:3989): virt-viewer-DEBUG: fullscreen display 0: 0 (virt-viewer:3989): virt-viewer-DEBUG: connecting ... (virt-viewer:3989): virt-viewer-DEBUG: Opening connection to libvirt with URI xen:// Opening connection to libvirt with URI xen:// (virt-viewer:3989): virt-viewer-DEBUG: Add handle 7 1 0x203dc30 (virt-viewer:3989): virt-viewer-DEBUG: initial connect (virt-viewer:3989): virt-viewer-DEBUG: notebook show status 0x1fc8000 (virt-viewer:3989): virt-viewer-DEBUG: virt_viewer_app_set_uuid_string: UUID changed to ce5bfb10-cd02-7cf2-45b0-7ee36d751987 (virt-viewer:3989): virt-viewer-DEBUG: notebook show status 0x1fc8000 (virt-viewer:3989): virt-viewer-DEBUG: Guest testvm is running, determining display Guest testvm is running, determining display (virt-viewer:3989): virt-viewer-DEBUG: Set connect info: (null),(null),(null),-1,(null),(null),(null),0 (virt-viewer:3989): virt-viewer-DEBUG: Guest testvm has a vnc display Guest testvm has a vnc display (virt-viewer:3989): virt-viewer-DEBUG: Guest graphics listen '' is NULL or a wildcard, replacing with 'localhost' (virt-viewer:3989): virt-viewer-DEBUG: Set connect info: localhost,localhost,5901,-1,(null),(null),(null),0 (virt-viewer:3989): virt-viewer-DEBUG: Error operation forbidden: read only access prevents virDomainOpenGraphics (virt-viewer:3989): virt-viewer-DEBUG: After open connection callback fd=-1 (virt-viewer:3989): virt-viewer-DEBUG: Opening direct TCP connection to display at localhost:5901:-1 Opening direct TCP connection to display at localhost:5901:-1 (virt-viewer:3989): virt-viewer-DEBUG: notebook show status 0x1fc8000 (virt-viewer:3989): virt-viewer-DEBUG: Add timeout 0x2041780 -1 0x7f3436886640 0x203e3a0 1 (virt-viewer:3989): virt-viewer-DEBUG: notebook show status 0x1fc8000 (virt-viewer:3989): virt-viewer-DEBUG: notebook show display 0x1fc8000 (virt-viewer:3989): virt-viewer-DEBUG: notebook show display 0x1fc8000 (virt-viewer:3989): virt-viewer-DEBUG: Display size request 50x50 (desktop 100x100) (virt-viewer:3989): virt-viewer-DEBUG: Allocated 400x374 (virt-viewer:3989): virt-viewer-DEBUG: Child allocate 374x374 (virt-viewer:3989): virt-viewer-DEBUG: Display size request 50x50 (desktop 100x100) (virt-viewer:3989): virt-viewer-DEBUG: Allocated 400x374 (virt-viewer:3989): virt-viewer-DEBUG: Child allocate 374x374 (virt-viewer:3989): virt-viewer-DEBUG: desktop resize 1024x768 (virt-viewer:3989): virt-viewer-DEBUG: Preparing main window resize (virt-viewer:3989): virt-viewer-DEBUG: Decided todo 1024x768 (desktop is 1024x768, fullscreen is 1920x1080 (virt-viewer:3989): virt-viewer-DEBUG: Display size request 1024x768 (desktop 1024x768) (virt-viewer:3989): virt-viewer-DEBUG: Allocated 1024x768 (virt-viewer:3989): virt-viewer-DEBUG: Child allocate 1024x768 (virt-viewer:3989): virt-viewer-DEBUG: Display size request 50x50 (desktop 1024x768) (virt-viewer:3989): virt-viewer-DEBUG: Allocated 1024x768 (virt-viewer:3989): virt-viewer-DEBUG: Child allocate 1024x768 (virt-viewer:3989): virt-viewer-DEBUG: Dispatch handler 7 1 0x203dc30 (virt-viewer:3989): virt-viewer-DEBUG: Dispatch handler 7 2 0x203dc30 (virt-viewer:3989): virt-viewer-DEBUG: Dispatch handler 7 1 0x203dc30 (virt-viewer:3989): virt-viewer-DEBUG: Dispatch handler 7 2 0x203dc30 (virt-viewer:3989): virt-viewer-DEBUG: Dispatch handler 7 1 0x203dc30 (virt-viewer:3989): virt-viewer-DEBUG: Dispatch handler 7 2 0x203dc30 (virt-viewer:3989): virt-viewer-DEBUG: Dispatch handler 7 1 0x203dc30 (virt-viewer:3989): virt-viewer-DEBUG: Dispatch handler 7 2 0x203dc30 (virt-viewer:3989): virt-viewer-DEBUG: Dispatch handler 7 1 0x203dc30 (virt-viewer:3989): virt-viewer-DEBUG: Dispatch handler 7 2 0x203dc30 (virt-viewer:3989): virt-viewer-DEBUG: Dispatch handler 7 1 0x203dc30 (virt-viewer:3989): virt-viewer-DEBUG: Dispatch handler 7 2 0x203dc30 (virt-viewer:3989): virt-viewer-DEBUG: Window closed
So yeah.. here we have the: (virt-viewer:3989): virt-viewer-DEBUG: Opening direct TCP connection to display at localhost:5901:-1 Opening direct TCP connection to display at localhost:5901:-1
I wonder why the newer virt-viewer version doesn't do/try that anymore.. time to look at the source I guess.
-George
Thanks,
-- Pasi
-
George Dunlap -
Johnny Hughes -
Pasi Kärkkäinen