[virt-tools-list] [rhelv6-list] virt-install --pxe REVISIT

[Derek Yarnell]

Hi,

I just wanted to follow up this post saying I ran back into this issue
with our setup.  There is a bug report about this,

https://bugzilla.redhat.com/show_bug.cgi?id=632712

DELAY=0

is needed in your bridge device (same file as TYPE=Bridge).

Thanks,
derek

On 11/12/10 12:47 PM, Phil Meyer wrote:
> Pleas guide me as to where and/or who would work this bug:
> 
> Fedora 12+ and RHEL6 both suffer this issue.
> 
> I would speculate that all systems that ship a reasonably new version of
> qemu featuring the seabios suffer from this issue.
> 
> Here is a sample virt-install that works on servers with older (not
> seabios) versions of qemu.
> 
> virt-install \
> --noreboot \
> --hvm \
> --virt-type=kvm  \
> --name=a008474 \
> --ram=1024 \
> --vcpus=1 \
> --arch=x86_64 \
> --uuid=ff1507df-2f77-4618-b9d6-8c9b27e6528f \
> --os-type=linux \
> --os-variant=rhel6 \
> --disk path=/dev/mapper/008474,bus=virtio,cache=none
> --network=bridge=br1,model=virtio,mac=52:54:ac:14:21:04 \
> --pxe \
> --vnc \
> --vnclisten=0.0.0.0 \
> --noautoconsole \
> --wait=-1
> 
> We are really only interested in the affect of calling: --pxe
> 
> If the libvirt provided NAT interface is used, it works.
> 
> If a bridge is set up and (as in the above example) is used for the VM,
> the dhcp request shows up on the vnet assigned to the guest, but never
> to the bridge.
> 
> ie:
> 
> # tshark --i vnet0
>      Always shows the dhcp request.
> 
> # tshark -i br0
>      Never shows any packets from the guest.
> 
> However:
> 
> If you press <CNTRL>b to drop into the gpxe BIOS before it aborts,
> manual processing does indeed work.
> 
> gpxe> dhcp net0
>     WORKS!
> 
> By entering imgload, etc. manually, the PXE boot can work.
> 
> Very strange.
> 
> Any advice is welcome.  This is a show stopper for us.
> 
> Thanks!
> 
> _______________________________________________
> rhelv6-list mailing list
> rhelv6-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rhelv6-list
> 


-- 
---
Derek T. Yarnell
University of Maryland
Institute for Advanced Computer Studies