Hide Forgot
Description of problem: "When changing a guest VM from SPICE to VNC or vice versa, either by editing the VMs's properties under Console, or temporarily by using Run Once, it causes the guest OS to detect a different NIC card (though the MAC address is unchanged). This results in a loss of connectivity if the NIC was configured on the guest OS to use a static IP. We have verified this on Windows 2008 (x32). On Windows the NIC will show up as something like "Virtio Adapter #2". Why is the choice of console tied to the NIC? There are times when one display protocol is desirable over another. Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. start Windows guest with spice spice qemu-kvm command line: 20922 ? Sl 1:02 /usr/libexec/qemu-kvm -no-hpet -usbdevice tablet -rtc-td-hack -startdate 2011-08-02T16:18:29 -name winbase2 -smp 1,cores=1 -k en-us -m 2048 -boot cn -net nic,vlan=1,macaddr=00:1a:4a:93:65:37,model=virtio -net tap,vlan=1,ifname=virtio_26_1,script=no -drive file=/rhev/data-center/9a7bddf1-2b94-40f3-9043-caa4301fa8cd/df7fb0da-0ccd-4305-885e-cbc3c39e9a0e/images/b6ca7dda-bc24-4015-94ef-defd03b131a4/797daf6c-0132-4d05-9a7b-6b58f359619d,media=disk,if=virtio,cache=off,serial=15-94ef-defd03b131a4,boot=on,format=qcow2,werror=stop -pidfile /var/vdsm/ec04bf73-c1bc-44fb-b3b0-a82fcb164772.pid -soundhw ac97 -spice sslpassword=,sslciphersuite=DEFAULT,sslcert=/var/vdsm/ts/certs/vdsmcert.pem,sslkey=/var/vdsm/ts/keys/vdsmkey.pem,ssldhfile=/var/vdsm/ts/keys/dh.pem,sslcafile=/var/vdsm/ts/certs/cacert.pem,host=0,secure-channels=main+inputs,ic=on,sport=5874,port=5926 -qxl 1 -cpu qemu64,+sse2,+cx16,+ssse3,+sse4.1,+sse4.2,+popcnt -M rhel5.5.0 -notify all -balloon none -smbios type=1,manufacturer=Red Hat,product=RHEV Hypervisor,version=5.7-20110725.1.el5,serial=33343934-3932-5355-4539-34374E314B42_00:26:55:2c:ed:de,uuid=ec04bf73-c1bc-44fb-b3b0-a82fcb164772 -vmchannel di:0200,unix:/var/vdsm/ec04bf73-c1bc-44fb-b3b0-a82fcb164772.guest.socket,server -monitor unix:/var/vdsm/ec04bf73-c1bc-44fb-b3b0-a82fcb164772.monitor.socket,server 2. restart guest with vnc qemu-kvm command line with vnc: 16504 ? Sl 0:34 /usr/libexec/qemu-kvm -no-hpet -usbdevice tablet -rtc-td-hack -startdate 2011-08-02T16:00:52 -name winbase2 -smp 1,cores=1 -k en-us -m 2048 -boot c -net nic,vlan=1,macaddr=00:1a:4a:93:65:37,model=virtio -net tap,vlan=1,ifname=virtio_26_1,script=no -drive file=/rhev/data-center/9a7bddf1-2b94-40f3-9043-caa4301fa8cd/df7fb0da-0ccd-4305-885e-cbc3c39e9a0e/images/b6ca7dda-bc24-4015-94ef-defd03b131a4/797daf6c-0132-4d05-9a7b-6b58f359619d,media=disk,if=virtio,cache=off,serial=15-94ef-defd03b131a4,boot=on,format=qcow2,werror=stop -pidfile /var/vdsm/ec04bf73-c1bc-44fb-b3b0-a82fcb164772.pid -vnc 0:26,password -cpu qemu64,+sse2,+cx16,+ssse3,+sse4.1,+sse4.2,+popcnt -M rhel5.5.0 -notify all -balloon none -smbios type=1,manufacturer=Red Hat,product=RHEV Hypervisor,version=5.7-20110725.1.el5,serial=33343934-3932-5355-4539-34374E314B42_00:26:55:2c:ed:de,uuid=ec04bf73-c1bc-44fb-b3b0-a82fcb164772 -vmchannel di:0200,unix:/var/vdsm/ec04bf73-c1bc-44fb-b3b0-a82fcb164772.guest.socket,server -monitor unix:/var/vdsm/ec04bf73-c1bc-44fb-b3b0-a82fcb164772.monitor.socket,server 3. Windows will create new NIC hardware because qxl device has been removed/added to the guest Actual results: Windows will create new NIC hardware because qxl device has been removed/added to the guest Expected results: PCI NIC device does not change order when spice/sql is added or removed Additional info:
I talked to Dan Yasny and he said he had opened a bug on this in SolidICE time frame 3 years ago but couldn't find it. It was probably closed WONTFIX he assumed. He said this should be an RFE. I should mention this was seen with RHEV H 5.7, we have not tried this on RHEL 6 but I assume it can't be implemented within RHEL 5 timeframe which is why I opened it under RHEL 6
ugh, I had a mid air collision with pm-rhel on some flags it was adding at the same time i put in my last comment and I just submitted mine anyway w/o realizing i could submit just the comment. can someone check the flags and everything and fix them as needed? sorry.
It's not a bug - qemu is not invoked with static pci addresses so using qxl or cirrus makes the pci ordering effect other devices. It is possible to add this to the command line to make the problem go away.
Dor I think I see what you're saying. qemu just does what it's told so the problem is coming from vdsm or libvirt not keeping the order consistent. Dan said this problem is also seen sometimes with adding multiple displays to a windows guest. For the customer story I put in comment #1 what would be the best way to get this behavior corrected? what about an RFE to always have consistent PCI addressing when adding/removing devices? or if it is a bug would it be a bug in vdsm or libvirt?
can someone respond to comment #7 == For the customer story I put in comment #1 what would be the best way to get this behavior corrected? what about an RFE to always have consistent PCI addressing when adding/removing devices? or if it is a bug would it be a bug in vdsm or libvirt? ==
For anyone interested, I opened an RFE on this because I couldn't find an existing one: https://bugzilla.redhat.com/show_bug.cgi?id=745274