Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1559332

Summary: Windows VM got console type changed to RDP in Admin portal
Product: [oVirt] ovirt-engine Reporter: Jiri Belka <jbelka>
Component: Frontend.WebAdminAssignee: bugs <bugs>
Status: CLOSED DUPLICATE QA Contact: Jiri Belka <jbelka>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.2.2CC: bugs, jbelka, michal.skrivanek
Target Milestone: ---Keywords: Regression
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-17 07:42:03 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
screenshot none

Description Jiri Belka 2018-03-22 10:23:11 UTC
Created attachment 1411668 [details]
screenshot

Description of problem:

By some miracle our brq-w2k12r2 VM got changed default console to RDP. This is clearly odd as underlying qemu does not know any RDP at all, the console should be SPICE or VNC (or both) and IIURC RDP could be set for Windows clients.

My client - OpenSUSE LEAP 42.3 with Google Chrome. See screenshot (opening console just downloads .rdp config file).

FYI our cluster got recently updated from 4.1 level to 4.2. But this VM does not have next_run warning.

Version-Release number of selected component (if applicable):
ovirt-engine-webadmin-portal-4.2.2.1-0.1.el7.noarch

How reproducible:
1 in 1

Steps to Reproduce:
1. 
2.
3.

Actual results:
opening console downloads rdp config file instead of opening spice/vnc console
default console seems to be rdp and cannot be changed

Expected results:
should be spice or vnc (or both)

Additional info:

Comment 1 Jiri Belka 2018-03-22 10:27:59 UTC
# virsh dumpxml brq-w2k12r2 | xmllint --xpath '//*/video' -
<video>
      <model type="qxl" ram="65536" vram="32768" vgamem="16384" heads="1" primary="yes"/>
      <alias name="video0"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x0"/>
    </video>

# ps auxww | grep '[b]rq-w2k12r2'
qemu     43982  5.0  8.2 4912772 4084536 ?     Sl   Mar16 441:09 /usr/libexec/qemu-kvm -name guest=brq-w2k12r2,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-8-brq-w2k12r2/master-key.aes -machine pc-i440fx-rhel7.3.0,accel=kvm,usb=off,dump-guest-core=off -cpu Westmere,vmx=on,vme=on,pclmuldq=on,x2apic=on,hypervisor=on,arat=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m size=4194304k,slots=16,maxmem=16777216k -realtime mlock=off -smp 2,maxcpus=16,sockets=16,cores=1,threads=1 -numa node,nodeid=0,cpus=0-1,mem=4096 -uuid b85142f5-4aac-412a-ae4d-aff541c33ae8 -smbios type=1,manufacturer=oVirt,product=RHEV Hypervisor,version=7.5-8.el7,serial=4C4C4544-0044-4B10-8046-CAC04F313332,uuid=b85142f5-4aac-412a-ae4d-aff541c33ae8 -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-8-brq-w2k12r2/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=2018-03-16T10:51:43,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x5 -drive file=/rhev/data-center/mnt/str-03s1.rhev.lab.eng.brq.redhat.com:_iso_shared/0c78b4d6-ba00-4d3e-9f9f-65c7d5899d71/images/11111111-1111-1111-1111-111111111111/RHEV-toolsSetup_4.1_7.iso,format=raw,if=none,id=drive-ide0-1-0,werror=report,rerror=report,readonly=on -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/rhev/data-center/mnt/blockSD/219bc71f-c5ec-4ace-80f5-f07b2f892163/images/971f09d3-181a-49a2-af02-9fb25e50fac9/bdaff20a-2a1e-40ac-ab81-d5421bfd550b,format=qcow2,if=none,id=drive-virtio-disk0,serial=971f09d3-181a-49a2-af02-9fb25e50fac9,werror=stop,rerror=stop,cache=none,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=31,id=hostnet0,vhost=on,vhostfd=33 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:01:3f:fb,bus=pci.0,addr=0x3 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/b85142f5-4aac-412a-ae4d-aff541c33ae8.ovirt-guest-agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=ovirt-guest-agent.0 -chardev socket,id=charchannel1,path=/var/lib/libvirt/qemu/channels/b85142f5-4aac-412a-ae4d-aff541c33ae8.org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -device qxl-vga,id=video0,ram_size=67108864,vram_size=33554432,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -incoming defer -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on

Comment 2 Jiri Belka 2018-03-22 10:33:10 UTC
# select vm_name,default_display_type from vms where vm_name = 'brq-w2k12r2';
   vm_name   | default_display_type 
-------------+----------------------
 brq-w2k12r2 |                    1
(1 row)

Comment 4 Michal Skrivanek 2018-03-23 12:05:40 UTC
sounds much like issues in https://bugzilla.redhat.com/show_bug.cgi?id=1528868#c38

We need to see that live, can you provide access to a VM where it's currently happening?

Comment 5 Jiri Belka 2018-03-27 12:17:07 UTC
(In reply to Michal Skrivanek from comment #4)
> sounds much like issues in
> https://bugzilla.redhat.com/show_bug.cgi?id=1528868#c38
> 
> We need to see that live, can you provide access to a VM where it's
> currently happening?

sent via mail to mskrivan@.

Comment 6 Michal Skrivanek 2018-04-16 12:24:38 UTC
possibly a duplicate of bug 1528868. If you can reproduce that it would be great to verify once it's fixed

Comment 7 Jiri Belka 2018-04-17 06:36:59 UTC
(In reply to Michal Skrivanek from comment #6)
> possibly a duplicate of bug 1528868. If you can reproduce that it would be
> great to verify once it's fixed

I can't reproduce, it just appeared on some a specific VM. Also our env is a historical one, since 3.1.

Comment 8 Michal Skrivanek 2018-04-17 07:42:03 UTC

*** This bug has been marked as a duplicate of bug 1528868 ***