Bug 580411

Summary: Virtualization guest can't boot directly from Network(PXE)
Product: [Fedora] Fedora Reporter: Lijian Xu <lxu>
Component: qemuAssignee: Justin M. Forbes <jforbes>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 13CC: amit.shah, berrange, clalance, crobinso, dwmw2, ehabkost, gcosta, itamar, jaswinder, jforbes, knoel, markmc, matt_domsch, rhe, scottt.tw, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-05-18 20:01:04 UTC Type: ---
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
Contains an error output and two xml configuration files.
none
pxeboot log none

Description Lijian Xu 2010-04-08 08:28:01 UTC 
Created attachment 405221 [details]
Contains an error output and two xml configuration files.

Description of problem:
    I followed the instuctions in https://fedoraproject.org/wiki/QA:Testcase_Virtualization_Guest_pxeBoot, and when I run "virsh start netboot", it reports error, and doesn't start.
    Then I used "VIRT_DEBUG=1 libvirtd", and the output was as the attachment "libvirtd-errors".
    But when I changed the boot device from "network" to "cdrom", and added a cdrom device, it just boots. I can even select to boot from pxe by press "Ctrl + b" and everything works. I think it may be a bug that the boot device can't be "network".
    The two xml virtual machine configuration files are also added as attachments.

Version-Release number of selected component (if applicable):
    * kernel-2.6.33.1-19.fc13
    * libvirt-0.7.7-1.fc13
    * python-virtinst-0.500.2-3.fc13
    * qemu-0.12.3-6.fc13
    * seabios-0.5.1-1.fc13
    * virt-manager-0.8.3-2.fc13 

How reproducible:
    Every time.

Steps to Reproduce:
1.Use netboot.xml in the attachment, run:
2.Run "virsh define netboot.xml"
3.Run "virsh start netboot"

Actual results:
    [root@dhcp-65-190 ~]# virsh start netboot
    error: Failed to start domain netboot
    error: monitor socket did not show up.: Connection refused

Expected results:
    Virtual machine starts normally.

Additional info:
    None.
Comment 1 He Rui 2010-04-08 08:46:43 UTC 
I had the same problem when executing that case using http://jforbes.fedorapeople.org/virt-test-day/

boot log is attached.
Comment 2 He Rui 2010-04-08 08:50:09 UTC 
Created attachment 405230 [details]
pxeboot log
Comment 3 Lijian Xu 2010-04-12 02:56:35 UTC 
I found the error "monitor socket did not show up.: Connection refused
" is caused by missing an error-receive serial, after added the serial, I get the actual error message: 

libvirtError: internal error Process exited while reading console log output: char device redirected to /dev/pts/2
Cannot boot from non-existent NIC

I hope this would be helpful.
Comment 4 Matt Domsch 2010-05-05 18:27:30 UTC 
netboot -uuid 543628e0-2b75-3513-d131-03ba38c073de -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/netboot.monitor,server,nowait -mon chardev=monitor,mode=readline -rtc base=utc -no-acpi -boot n -device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:05:38:5c,bus=pci.0,addr=0x4 -net tap,fd=41,vlan=0,name=hostnet0 -usb -vnc 127.0.0.1:0 -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 
Cannot boot from non-existent NIC

It's this last part (cannot boot from non-existant NIC) that I suspect is the problem.  This isn't in gPXE (it's not getting that far).
Comment 5 Daniel Berrangé 2010-05-05 18:35:21 UTC 
This looks like a QEMU bug

 * libvirt has set the guest to boot from network:

    -boot n

 * given the guest a NIC device

  -device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:05:38:5c,bus=pci.0,addr=0x4 

 * and associated this NIC with a host network

  -net tap,fd=41,vlan=0,name=hostnet0

So all the info QEMU requires is present. I suspect this is a bug in QEMU BIOS setup not handling -device properly.
Comment 6 Cole Robinson 2010-05-18 20:01:04 UTC 
Should be fixed in qemu-0.12.3-8.fc13

*** This bug has been marked as a duplicate of bug 577851 ***