Bug 859013

Created attachment 614850 [details]
Screenshot from VNC session

can you pxe boot on same host via virt-manager / kvm command line?

how I can try that? ;-) can you provide me the cmd I should run?

the cmd appears in vdsm log, but point is to simply try doing the same from say virt-manager to see it works, then start comparing the command lines of both via qemu-kvm to find the culprit

(In reply to comment #4)
> the cmd appears in vdsm log, but point is to simply try doing the same from
> say virt-manager to see it works, then start comparing the command lines of
> both via qemu-kvm to find the culprit

The command line does NOT appear in vdsm.log - regression?

However, the vdsm.log looks ok, more or less:
'nicModel': 'rtl8139,pv' - looks strange, but the libvirt.xml looks fine with virtio only.

I'd snoop the network to see if there's any TFTP traffic.

(In reply to comment #7)
> (In reply to comment #4)
> > the cmd appears in vdsm log, but point is to simply try doing the same from
> > say virt-manager to see it works, then start comparing the command lines of
> > both via qemu-kvm to find the culprit
> 
> The command line does NOT appear in vdsm.log - regression?

But you can get the command line from the VM log, at /var/log/libvirt/qemu/<vmname>.log

Guys, I discovered something after playing around. When the VM has no disk assigned and I boot it the PXE menu appears normally. I think it will also work with 'pre-allocated' disk.

(In reply to comment #10)
> (In reply to comment #7)
> > (In reply to comment #4)
> > > the cmd appears in vdsm log, but point is to simply try doing the same from
> > > say virt-manager to see it works, then start comparing the command lines of
> > > both via qemu-kvm to find the culprit
> > 
> > The command line does NOT appear in vdsm.log - regression?
> 
> But you can get the command line from the VM log, at
> /var/log/libvirt/qemu/<vmname>.log

LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/libexec/qemu-kvm -S -M rhel6.3.0 -cpu Penryn -enable-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -name test123 -uuid 06399f0e-4a7d-480f-8c3d-6d99582e2a83 -smbios type=1,manufacturer=Red Hat,product=RHEV Hypervisor,version=6Server-6.3.0.3.el6,serial=4C4C4544-004B-3610-8050-B7C04F5A344A_84:2B:2B:FE:0A:5D,uuid=06399f0e-4a7d-480f-8c3d-6d99582e2a83 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/test123.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=2012-09-20T03:09:38,driftfix=slew -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw,serial= -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/rhev/data-center/9df72b84-0234-11e2-9b87-9386d9b09d4a/c010e0c4-3af3-407a-a072-bb9ce2868ccb/images/360e86a2-2c67-4697-8ee9-c1600cdf92f3/7a2d6098-250d-4f64-a193-ed56f8709379,if=none,id=drive-virtio-disk0,format=raw,serial=360e86a2-2c67-4697-8ee9-c1600cdf92f3,cache=none,werror=stop,rerror=stop,aio=threads -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:22:20:00,bus=pci.0,addr=0x3,bootindex=1 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/test123.com.redhat.rhevm.vdsm,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm -chardev socket,id=charchannel1,path=/var/lib/libvirt/qemu/channels/test123.org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -chardev pty,id=charconsole0 -device virtconsole,chardev=charconsole0,id=console0 -device usb-tablet,id=input0 -vnc 0:0,password -k en-us -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6
char device redirected to /dev/pts/0
Domain id=43 is tainted: custom-monitor

One thing I found suspicious above is that my CPU Family is set to Intel Westmere but qemu command line shows ' -cpu Penryn'. Dunno if that is important.

(In reply to comment #13)
> One thing I found suspicious above is that my CPU Family is set to Intel
> Westmere but qemu command line shows ' -cpu Penryn'. Dunno if that is
> important.

Most likely because your cluster level is not set to Westmere. Irrelevant to the issue.

(In reply to comment #11)
> Guys, I discovered something after playing around. When the VM has no disk
> assigned and I boot it the PXE menu appears normally. I think it will also
> work with 'pre-allocated' disk.

Is this reproducible constantly? 
If I understand you correctly:
PXE boot with no HD = success 
PXE boot with pre-allocated disk = success
PXE boot with Thin provision disk = no menu 


Correct?
This sounds like a qemu bug.

Yes, it is reproducible constantly. And yes, what you described is right.

syslinux was updated to 4.02 in RHEL6.1, you're still using 3.86.  What happens if you update syslinux to the latest package and update your boot server to make use of it?

I was able to reproduce this.  I tftp'd the pxelinux.0 from the server shown in the screen shot from comment 1, put it on my server and the guest hangs as reported.  I then replaced pxelinux.0 with the version from syslinux-4.02-7.el6.x86_64 and the guest booted up to a pxe menu.  I therefore believe this is already fixed with the updated version of syslinux.

This was verified to work in the already released version, so this should have moved to CLOSED/CURRENTRELEASE instead of MODIFIED.