Display network doen't work for me

Latest response

I have installed RHEV (with FreeIPA).

 

There are two networks in RHEVM. Display network 172.17.205.200/29 and rhevm network 172.17.192.128/26. Display and rhevm networks are in different VLANs. Both RHEVM and RHEVH hosts has display and rhevm IPs.

 

There are two desktops which connect to network via Cisco VPN. First (adminitrator) desktop has access to rhevm and display network. RHEVM and spice work fine. Second desktop has not access to rhevm network (Cisco admin prohibits this access). User can access UserPortal but spice doesn't work because spice client tries to connect to rhevm IP.  So all spice traffic goes throught rhevm network. Why?

PZ
Log in to join the conversation

Responses

gf Red Hat Active Contributor 140 points
19 January 2012 10:16 AM

the display network problem should have been fixed by vdsm-4.9-112.2.el6 , changes posted upstream at http://gerrit.ovirt.org/255

Sadique Puthen's picture Red Hat Guru 4679 points
19 January 2012 10:55 AM

As noted earlier, there was a bug in Beta with displayNetwork and is fixed in GA which includes vdsm-4.9-112.

 

If you are using RHEV3 beta, you need to test this with GA and revert back with your feedback.

PZ Active Contributor 240 points
20 January 2012 11:43 AM

I've updated RHEV-M and have installed second host with RHEV-H GA (restarted hosts and jbosass) .

 

But problem still persists. Spicec connects to rhevm IPs. From user desktop spice doesn't work.

 

vdsm-4.9-112.1.el6.x86_64
Red Hat Enterprise Virtualization Hypervisor release 6.2 (20120116.0.el6_2)
 

DY Guru 5340 points
20 January 2012 11:55 AM

Need to separate two things here

 

1. display network setting means the set network will be the one where VMs from the relevant cluster will be listening for spice/vnc connections. 

Does this work OK? When you start a VM, check for `ps -ef |grep qemu` and see where the spice/vnc listener is attached

 

2. when you use a client machine, and try to connect to a VM's console, the client should know on which network to try accessing the console. 

So if you look at the connections, do you see the spice client go to the right ports on the right host via the right network?

PZ Active Contributor 240 points
20 January 2012 12:12 PM

Output:

 

3650M2-top ~]# netstat -tnlp | grep qemu | grep 590
tcp        0      0 0.0.0.0:5900                0.0.0.0:*                   LISTEN      13314/qemu-kvm     
tcp        0      0 0.0.0.0:5901                0.0.0.0:*                   LISTEN      13314/qemu-kvm     
..... Output omitted ......   
tcp        0      0 0.0.0.0:5907                0.0.0.0:*                   LISTEN      25441/qemu-kvm  



/usr/libexec/qemu-kvm .... -spice port=5906,tls-port=5907,addr=0,x509-dir=/etc/pki/vdsm/libvirt-spice,tls-channel=main,tls-channel=inputs

 

 

2) Spice client goes to host in rhevm network (not spice network)

DY Guru 5340 points
20 January 2012 12:16 PM

1. looks like it's listening on all the IPs - this is definitely wrong

2. again - not the right behaviour. 

 

Let me try and recreate this internally, I'll keep you posted

PZ Active Contributor 240 points
20 January 2012 2:48 PM

I have found some interesting strings in spice log

 

1327070550 INFO [31839:31839] Application::main: starting 0.8.3
1327070550 INFO [31839:31839] init_key_map: using evdev mapping
1327070551 INFO [31839:31839] MultyMonScreen::MultyMonScreen: platform_win: 123731971
1327070551 INFO [31839:31839] ForeignMenu::ForeignMenu: Creating a foreign menu connection /tmp/SpiceForeignMenu-31839.uds
1327070551 INFO [31839:31839] Controller::Controller: Creating a controller connection /home/pzhukov/.spicec/spice-xpi-btSlcc
1327070551 INFO [31839:31839] Application::enter_full_screen:
1327070551 INFO [31839:31840] RedPeer::connect_secure: Connected to 172.17.192.140 5903
1327070551 INFO [31839:31840] RedClient::handle_init:
1327070552 INFO [31839:31843] RedPeer::connect_unsecure: Connected to 172.17.192.140 5902
1327070552 INFO [31839:31844] RedPeer::connect_unsecure: Connected to 172.17.192.140 5902
1327070552 INFO [31839:31846] RedPeer::connect_unsecure: Connected to 172.17.192.140 5902
1327070552 INFO [31839:31847] RedPeer::connect_unsecure: Connected to 172.17.192.140 5902
1327070552 INFO [31839:31848] RedPeer::connect_secure: Connected to 172.17.192.140 5903
1327070552 INFO [31839:31847] DisplayChannel::create_primary_surface:
1327070552 INFO [31839:31839] DisplayChannel::create_sw_canvas: display 0: using sw
1327070553 INFO [31839:31839] Application::exit_full_screen:

 

 

and after migration

 

 

1327070563 INFO [31839:31839] DisplayChannel::destroy_canvas: surface does not exist: 14
1327070563 INFO [31839:31839] DisplayChannel::destroy_canvas: surface does not exist: 20
1327070613 INFO [31839:31840] RedClient::handle_migrate_begin:
1327070622 INFO [31839:31839] Application::switch_host: host=3650M2-top.rhev.domain.com port=5904 sport=5905
1327070622 INFO [31839:31839] RedClient::set_target: old protocol 2, new protocol 0
1327070623 WARN [31839:31840] RedChannel::run: cannot resolve host address 3650M2-top.rhev.domain.com
1327070623 INFO [31839:31839] main: Spice client terminated (exitcode = 2)

 

So UserPortal gets IP adress of management network (not FQDN) before migration and  FQDN after migration (via spice protocol).

 

PZ Active Contributor 240 points
24 January 2012 6:50 AM

Just for information:

I've got VM info by Rest API

        <display>
            <type>spice</type>
            <address>172.17.192.139</address> <!-- This is management network address. Is it a bug? -->
            <port>5900</port>
            <secure_port>5901</secure_port>
            <monitors>1</monitors>
        </display>

DY Guru 5340 points
24 January 2012 9:55 AM

http://rhn.redhat.com/errata/RHBA-2012-0012.html

seems like the issue should be resolved in vdsm 112.4

please make sure you're up to date

PZ Active Contributor 240 points
24 January 2012 6:33 PM

Yes, display network works now!  Thanks. 

Waiting for RHEV-H respin.