Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Several things need to be confirmed:
- Does it work if vhost is turned off or switch to use e1000?
- Since it was complained by autotest, we need first exclude autotest bug. I suggest you manually log into the guest to see whether autotest get the correct ip of guest.
- Make sure guest has unique mac address, you can do this by enforcing a special mac address and re-try.
Thanks
(In reply to jason wang from comment #5)
> Several things need to be confirmed:
>
> - Does it work if vhost is turned off or switch to use e1000?
It can be reproduced w/ vhost=off or e1000.
> - Since it was complained by autotest, we need first exclude autotest bug. I
> suggest you manually log into the guest to see whether autotest get the
> correct ip of guest.
The guest has the correct ip when login to guest manually.
> - Make sure guest has unique mac address, you can do this by enforcing a
> special mac address and re-try.
The guest has the unique mac address.
But this bug can just be reproduced by autotest, have not met this manually. From the debug log, can't make sure whether this a qemu bug. I will add more info to debug this.
Thanks,
Cong
(In reply to CongLi from comment #7)
> (In reply to jason wang from comment #5)
> > Several things need to be confirmed:
> >
> > - Does it work if vhost is turned off or switch to use e1000?
> It can be reproduced w/ vhost=off or e1000.
>
> > - Since it was complained by autotest, we need first exclude autotest bug. I
> > suggest you manually log into the guest to see whether autotest get the
> > correct ip of guest.
> The guest has the correct ip when login to guest manually.
>
> > - Make sure guest has unique mac address, you can do this by enforcing a
> > special mac address and re-try.
> The guest has the unique mac address.
>
> But this bug can just be reproduced by autotest, have not met this
> manually. From the debug log, can't make sure whether this a qemu bug. I
> will add more info to debug this.
Ok, since you can manually log into the guest. I believe it was a bug of autotest. So let move this to autotest?
>
>
> Thanks,
> Cong
(In reply to jason wang from comment #8)
> Ok, since you can manually log into the guest. I believe it was a bug of
> autotest. So let move this to autotest?
Ok, close this bug at first, will update the bug if there is any progress.
Thanks a lot,
Cong
Created attachment 844380 [details] tcpdump.log Description of problem: guest sometimes could not verify DHCP lease Version-Release number of selected component (if applicable): kernel-3.10.0-64.el7.x86_64 qemu-kvm-1.5.3-30.el7.x86_64 How reproducible: sometimes Steps to Reproduce: 1. Boot a SLES.11.3 guest then login: /home/staf-kvm-devel/autotest-devel/client/tests/virt/qemu/qemu \ -S \ -name 'virt-tests-vm1' \ -sandbox off \ -M pc \ -nodefaults \ -vga cirrus \ -chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20131231-191647-wnZt9k9y,server,nowait \ -mon chardev=qmp_id_qmpmonitor1,mode=control \ -chardev socket,id=serial_id_serial0,path=/tmp/serial-serial0-20131231-191647-wnZt9k9y,server,nowait \ -device isa-serial,chardev=serial_id_serial0 \ -chardev socket,id=seabioslog_id_20131231-191647-wnZt9k9y,path=/tmp/seabios-20131231-191647-wnZt9k9y,server,nowait \ -device isa-debugcon,chardev=seabioslog_id_20131231-191647-wnZt9k9y,iobase=0x402 \ -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=03 \ -drive id=drive_image1,if=none,cache=unsafe,snapshot=off,aio=native,file=/home/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/images/sles11sp3-64-virtio.qcow2 \ -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=04 \ -device virtio-net-pci,mac=9a:6a:6b:6c:6d:6e,id=idDIBJUD,netdev=id16M5w2,bus=pci.0,addr=05 \ -netdev tap,id=id16M5w2,vhost=on,vhostfd=23,fd=22 \ -m 2048 \ -smp 1,maxcpus=1,cores=1,threads=1,sockets=2 \ -cpu 'SandyBridge' \ -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \ -vnc :0 \ -rtc base=utc,clock=host,driftfix=slew \ -boot order=cdn,once=c,menu=off \ -balloon virtio \ -global PIIX4_PM.disable_s4=0 \ -no-kvm-pit-reinjection \ -enable-kvm 2. 3. Actual results: guest could not verify DHCP lease Expected results: login guest successfully Additional info: 1. This problem is hard to reproduce manually. 2. According to tcpdump.log(attached), there is IP which is corresponding with the mac(9a:6a:6b:6c:6d:6e): 013-12-31 19:17:05: 19:17:05.087179 IP (tos 0x0, ttl 255, id 4867, offset 0, flags [none], proto UDP (17), length 365) 2013-12-31 19:17:05: 10.66.85.254.bootps > 10.66.84.132.bootpc: BOOTP/DHCP, Reply, length 337, hops 1, xid 0xb8d85961, Flags [none] 2013-12-31 19:17:05: Your-IP 10.66.84.132 2013-12-31 19:17:05: Server-IP 10.66.94.104 2013-12-31 19:17:05: Gateway-IP 10.66.85.254 2013-12-31 19:17:05: Client-Ethernet-Address 9a:6a:6b:6c:6d:6e 2013-12-31 19:17:05: file "pxelinux.0" 2013-12-31 19:17:05: Vendor-rfc1048 Extensions 2013-12-31 19:17:05: Magic Cookie 0x63825363 2013-12-31 19:17:05: DHCP-Message Option 53, length 1: ACK 2013-12-31 19:17:05: Server-ID Option 54, length 4: 10.66.78.111 2013-12-31 19:17:05: Lease-Time Option 51, length 4: 14400 2013-12-31 19:17:05: RN Option 58, length 4: 7200 2013-12-31 19:17:05: RB Option 59, length 4: 12600 2013-12-31 19:17:05: Subnet-Mask Option 1, length 4: 255.255.254.0 2013-12-31 19:17:05: BR Option 28, length 4: 10.66.85.255 2013-12-31 19:17:05: Default-Gateway Option 3, length 4: 10.66.85.254 2013-12-31 19:17:05: Domain-Name Option 15, length 21: "englab.nay.redhat.com" 2013-12-31 19:17:05: Domain-Name-Server Option 6, length 12: 10.66.78.117,10.66.78.111,10.66.127.10 2013-12-31 19:17:05: NTP Option 42, length 12: 10.66.127.10,10.5.26.10,134.226.81.3 3. cpuinfo: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Xeon(R) CPU E31225 @ 3.10GHz stepping : 7 microcode : 0x29 cpu MHz : 1885.671 cache size : 6144 KB physical id : 0 siblings : 4 core id : 3 cpu cores : 4 apicid : 6 initial apicid : 6 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid bogomips : 6184.29 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: