Bug 706039 - [RHEL.6][VDSM] - vdsm somehow failed\didn't configure libvirt to work on 16514
Summary: [RHEL.6][VDSM] - vdsm somehow failed\didn't configure libvirt to work on 16514
Keywords:
Status: CLOSED DUPLICATE of bug 684764
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: vdsm
Version: 6.1
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Yotam Oron
QA Contact: David Botzer
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-19 09:34 UTC by David Botzer
Modified: 2014-01-13 23:59 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-23 07:28:20 UTC
Target Upstream Version:


Attachments (Terms of Use)
vdsmLOG (250.22 KB, application/octet-stream)
2011-05-19 09:35 UTC, David Botzer
no flags Details
libvirt_qemu_conf (30.00 KB, text/plain)
2011-05-19 10:01 UTC, David Botzer
no flags Details

Description David Botzer 2011-05-19 09:34:49 UTC
Description of problem:
libvirt on DST Host, doesn't listen on its designated port (16514)
its listens to 16509

Version-Release number of selected component (if applicable):


How reproducible:
Not Always

Steps to Reproduce:
1.Migrate a VM from SRC Host to a DST Host
2.If the DST Host doesnt listen on the same port of libvirt as SRC host it will fail (TCP 16514)
3.
  
Actual results:
VM fails to migrate

Expected results:
VM Should migrate successfully

Additional info:

Libvirt Log
-----------------------------------
12:04:10.846: 9821: error : remoteIO:10569 : operation failed: Failed to connect to remote libvirt URI qemu+tls://10.16.33.116/syst
em

VDSM - fails migration
-----------------------------------
Thread-114::ERROR::2011-05-19 12:04:14,833::vm::456::vm.Vm::(run) vmId=`edc5a15c-1041-4a0a-9421-3cbd2ed8ec34`::Traceback (most rece
nt call last):
  File "/usr/share/vdsm/vm.py", line 447, in run
    self._startUnderlyingMigration()
  File "/usr/share/vdsm/libvirtvm.py", line 281, in _startUnderlyingMigration
    libvirt.VIR_MIGRATE_PEER2PEER, None, maxBandwidth)
  File "/usr/share/vdsm/libvirtvm.py", line 306, in f
    ret = attr(*args, **kwargs)
  File "/usr/share/vdsm/libvirtconnection.py", line 59, in wrapper
    ret = f(*args, **kwargs)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 576, in migrateToURI
    if ret == -1: raise libvirtError ('virDomainMigrateToURI() failed', dom=self)
libvirtError: operation failed: Failed to connect to remote libvirt URI qemu+tls://10.16.33.116/system
===============================================
===============================================
10.16.33.113  (SRC Host)
tcp        0      0 0.0.0.0:16514               0.0.0.0:*                   LISTEN      0          18587      2627/libvirtd
--------------------
10.16.33.116  (DST Host)
tcp        0      0 0.0.0.0:16509               0.0.0.0:*                   LISTEN      0          18085      2547/libvirtd

Comment 1 David Botzer 2011-05-19 09:35:15 UTC
Created attachment 499787 [details]
vdsmLOG

Comment 3 Dan Kenigsberg 2011-05-19 09:46:44 UTC
I need much more information on what was going on with your dst host in the past. Did you change ssl from true to false manually? could you attach /etc/libvirt/{qemu,libvirtd}.conf ?

I suspect this is a dup of 684764, but I'm not yet sure.

Comment 4 David Botzer 2011-05-19 10:01:22 UTC
Created attachment 499793 [details]
libvirt_qemu_conf

I didnt touch the hosts
See attached

Comment 5 Yotam Oron 2011-05-23 07:28:20 UTC
qemu.conf has

listen_tcp=1 # by vdsm
listen_tls=0 # by vdsm

so it is clear that it was previously installed with ssl=false. It is unfortunate that future installations with ssl=true do not fix those configurations, and that is what bug 684764 is about.

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


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