Bug 727947 - Changing a Guest VM Console between SPICE and VNC Causes Change in Virtual NIC
Summary: Changing a Guest VM Console between SPICE and VNC Causes Change in Virtual NIC
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.3
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Virtualization Maintenance
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-03 18:32 UTC by John Brier
Modified: 2013-08-14 23:06 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-09-22 08:22:46 UTC


Attachments (Terms of Use)

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@redhat.com 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


Note You need to log in before you can comment on or make changes to this bug.