Bug 727947

Summary:	Changing a Guest VM Console between SPICE and VNC Causes Change in Virtual NIC
Product:	Red Hat Enterprise Linux 6	Reporter:	John Brier <jbrier>
Component:	qemu-kvm	Assignee:	Virtualization Maintenance <virt-maint>
Status:	CLOSED NOTABUG	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.3	CC:	emcnabb, juzhang, mkalinin, mkenneth, tburke, virt-maint
Target Milestone:	rc	Keywords:	Reopened
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-09-22 08:22:46 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:

Description John Brier 2011-08-03 18:32:08 UTC

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:

Comment 2 John Brier 2011-08-03 18:47:48 UTC

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

Comment 3 John Brier 2011-08-03 18:49:35 UTC

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.

Comment 6 Dor Laor 2011-08-11 21:37:34 UTC

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.

Comment 7 John Brier 2011-08-16 15:05:40 UTC

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?

Comment 8 John Brier 2011-09-21 23:07:22 UTC

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?
==

Comment 10 John Brier 2011-10-11 21:10:31 UTC

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