Bug 977987

Summary: when using virsh with libvirt default backend devices are incorrectly created.
Product: [Fedora] Fedora Reporter: Konrad Rzeszutek Wilk <ketuzsezr>
Component: xenAssignee: Michael Young <m.a.young>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: jfehlig, jforbes, kraxel, m.a.young, raistlin, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: xen-4.2.2-10.fc18 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-07-03 03:30:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
The virt-install viewer when using virt-install
none
F19 install using vnc
none
backport of commit 5420f265
none
With backport of commit 5420f265 none

Description Konrad Rzeszutek Wilk 2013-06-25 18:15:13 UTC
Description of problem:

When trying to install a PV guest using virt-install the VFB is not setup. This means that 'virt-viewer' only says 'serial0 console' and no output is being show.

However if I do 'xl console' on the guest I can see that the guest is working.

When looking at the XenBus, I saw:
[root@tst031 ~]# xenstore-ls /local/domain/0/backend/vkbd
7 = ""
 -1 = ""
  frontend = "/local/domain/7/device/vkbd/-1"
  frontend-id = "7"
  online = "1"
  state = "4"
  domain = "F19-23"
  feature-abs-pointer = "1"
  hotplug-status = "connected"

[root@tst031 ~]# xenstore-ls /local/domain/0/backend/vfb
7 = ""
 -1 = ""
  frontend = "/local/domain/7/device/vfb/-1"
  frontend-id = "7"
  online = "1"
  state = "4"
  domain = "F19-23"
  vnc = "1"
  vnclisten = "127.0.0.1"
  vncdisplay = "2"
  vncunused = "0"
  sdl = "0"
  opengl = "0"
  feature-resize = "1"
  hotplug-status = "connected"
  request-update = "1"

Version-Release number of selected component (if applicable):
[root@tst031 ~]# rpm -qa | grep xen
xen-licenses-4.2.2-6.fc19.x86_64
libvirt-daemon-xen-1.0.5.1-1.fc19.x86_64
xen-runtime-4.2.2-6.fc19.x86_64
xen-hypervisor-4.2.2-6.fc19.x86_64
libvirt-daemon-driver-xen-1.0.5.1-1.fc19.x86_64
xen-libs-4.2.2-6.fc19.x86_64
xen-4.2.2-6.fc19.x86_64


Jim Fehlig points out that I should have git commit 5420f265 backported, which is:

commit 5420f26507fc5c9853eb1076401a8658d72669da
Author: Jim Fehlig <jfehlig>
Date:   Fri Jan 11 12:22:26 2013 +0000

    libxl: Set vfb and vkb devid if not done so by the caller
    
    Other devices set a sensible devid if the caller has not done so.
    Do the same for vfb and vkb.  While at it, factor out the common code
    used to determine a sensible devid, so it can be used by other
    libxl__device_*_add functions.
    

How reproducible:
100%

Steps to Reproduce:
1.  virt-install -l http://192.168.2.251/tftpboot/lab/tst031/f19-x86_64/ --ram 1024 --disk /dev/vg_guests/guest --name F19-64 -w bridge=switch
2. See some output on the virt-viewer

Actual results:

'seria0 console'

Expected results:

Fedora installer 
Additional info:

Comment 1 Konrad Rzeszutek Wilk 2013-06-25 19:26:51 UTC
Tried the backport (as suggested by Jim) but no luck

Comment 2 Michael Young 2013-06-25 19:47:42 UTC
I am a bit worried about that patch as it adds a completely pointless set of brackets in a couple of places. If I see
if (( ... )) {
my natural reaction is to wonder if they are placed correctly, and on my quick reading of the logic I think my suspicions are justified! Does the code look right to you?

Comment 3 Konrad Rzeszutek Wilk 2013-06-25 20:03:54 UTC
Created attachment 765270 [details]
The virt-install viewer when using virt-install

Comment 4 Konrad Rzeszutek Wilk 2013-06-25 20:17:03 UTC
Created attachment 765275 [details]
F19 install using vnc

If I append the 'vnc' parameter so that the F19 guest sets up VNC, I can install it:

virt-install -l http://dl.fedoraproject.org/pub/alt/stage/19-RC1/Fedora/i386/os/ --ram 1024 --disk /dev/vg_guests/guest --name F19-32 -w bridge=switch -x vnc

Comment 5 Jim Fehlig 2013-06-25 20:33:44 UTC
(In reply to Michael Young from comment #2)
> I am a bit worried about that patch as it adds a completely pointless set of
> brackets in a couple of places. If I see
> if (( ... )) {

Err, where do you see pointless brackets?  Can you give a precise example?

Comment 6 Jim Fehlig 2013-06-25 20:35:04 UTC
(In reply to Konrad Rzeszutek Wilk from comment #1)
> Tried the backport (as suggested by Jim) but no luck

Do you still see the '-1' for vfb devid in xenstore with the backported patch?

Comment 7 Jim Fehlig 2013-06-25 20:37:56 UTC
Created attachment 765282 [details]
backport of commit 5420f265

I've been using this backport with 4.2.x for some time now and have not noticed any issues.

Comment 8 Michael Young 2013-06-25 20:42:36 UTC
(In reply to Jim Fehlig from comment #6)
> (In reply to Konrad Rzeszutek Wilk from comment #1)
> > Tried the backport (as suggested by Jim) but no luck
> 
> Do you still see the '-1' for vfb devid in xenstore with the backported
> patch?

In the patch 
http://xenbits.xenproject.org/gitweb/?p=xen.git;a=commit;h=5420f26507fc5c9853eb1076401a8658d72669da
you add lines like
if ((vtpm->devid = libxl__device_nextid(gc, domid, "vtpm") < 0)) {

i.e. set vtpm->devid to be true or false based on the comparison libxl__device_nextid(gc, domid, "vtpm") < 0

Comment 9 Jim Fehlig 2013-06-25 22:07:18 UTC
(In reply to Michael Young from comment #8)
> In the patch 
> http://xenbits.xenproject.org/gitweb/?p=xen.git;a=commit;
> h=5420f26507fc5c9853eb1076401a8658d72669da
> you add lines like
> if ((vtpm->devid = libxl__device_nextid(gc, domid, "vtpm") < 0)) {

Ah, the parens are not pointless, but one of the closing ones is misplaced :(.  E.g. that line should be

if ((vtpm->devid = libxl__device_nextid(gc, domid, "vtpm")) < 0) {

I've sent a patch to fix these cases

http://lists.xen.org/archives/html/xen-devel/2013-06/msg02515.html

Thanks for noticing the subtle bug!  It went unnoticed by upstream reviewers...

Comment 10 Dario Faggioli 2013-06-26 08:23:12 UTC
I have seen this before in the past (and reported to Jim in the libvirt mailing list) and I confirm that I also see it when trying to install and/or run F19.

As already said, what I have in xenstore looks sensible (i.e., not seeing any '-1'), and I'm not using any backported patch, just plain Xen and Libvirt F18 and F19 (I tried both as Dom0, and I'm seeing the issue in both cases) packages.

Dario

Comment 11 Dario Faggioli 2013-06-26 08:52:00 UTC
Oh, and BTW, nor adding '-x vnc' neither something like '--graphics vnc,listex=xxx' seem to do any magic here... I tried both and I'm still seeing the very same black screen with only 'serial0' on it that Konrad posted

Comment 12 Konrad Rzeszutek Wilk 2013-06-26 15:30:34 UTC
(In reply to Jim Fehlig from comment #7)
> Created attachment 765282 [details]
> backport of commit 5420f265
> 
> I've been using this backport with 4.2.x for some time now and have not
> noticed any issues.

That patch fixes the issues I saw. With it the FB shows the guest.

Comment 13 Konrad Rzeszutek Wilk 2013-06-26 15:31:52 UTC
Created attachment 765652 [details]
With backport of commit  5420f265

And xenstore-ls shows more appropiate values:

vfb = ""
  1 = ""
   0 = ""
    frontend = "/local/domain/1/device/vfb/0"
    frontend-id = "1"
    online = "1"
    state = "4"
    domain = "F19-again2"
    vnc = "1"
    vnclisten = "127.0.0.1"
    vncdisplay = "0"
    vncunused = "0"
    sdl = "0"
    opengl = "0"
    feature-resize = "1"
    hotplug-status = "connected"
    request-update = "1"

Comment 14 Konrad Rzeszutek Wilk 2013-06-26 15:37:15 UTC
(In reply to Konrad Rzeszutek Wilk from comment #1)
> Tried the backport (as suggested by Jim) but no luck

Looking back at my specfile, I added the patch in the spec file:

Patch95: bz977987

but I forgot the patch stanza: %patch95.

So I actually never tested the patch until today :-(

Comment 15 Jim Fehlig 2013-06-26 16:23:08 UTC
Glad to hear it works for you.  The patch mentioned in #9 (already ACK'ed by George) will also be needed, particularly if your config has more than one of a given device type.

Comment 16 Fedora Update System 2013-06-26 19:39:22 UTC
xen-4.2.2-10.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/xen-4.2.2-10.fc19

Comment 17 Fedora Update System 2013-06-26 20:09:40 UTC
xen-4.2.2-10.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/xen-4.2.2-10.fc18

Comment 18 Fedora Update System 2013-06-27 15:47:21 UTC
Package xen-4.2.2-10.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xen-4.2.2-10.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-11837/xen-4.2.2-10.fc19
then log in and leave karma (feedback).

Comment 19 Fedora Update System 2013-07-03 03:30:20 UTC
xen-4.2.2-10.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 20 Fedora Update System 2013-07-07 01:30:48 UTC
xen-4.2.2-10.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.