SSL timeout
by Sandro Bonazzola
Hi,
I'm trying to solve Bug 1034777 - SSL connection times out on read operation when installing from disk.
It has been suggested to try tweaking SSL socket timeout on client side, but it seems that the timeout is set
on server side to 160 seconds in vdsm/kaxmlrpclib.py [1]
I suggest to set it to something higher like 1800 (30 minutes) or allow to specify it in a configuration file.
I don't think this can be solved on client side.
Can anybody confirm it can be solved only server side?
If not, can you provide an example for setting timeout on client side?
Thanks.
[1] http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=vdsm/kaxmlrpclib.py;h=...
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years, 6 months
vdsm-tool: vdsm fails to configure services
by asegurap@redhat.com
Hi List,
I was building vdsm from git master on a newly installed minimal F20.
I get the following when trying to start vdsm:
vdsm: Running mkdirs
vdsm: Running configure_coredump
vdsm: Running run_init_hooks
vdsm: Running gencerts
vdsm: Running check_is_configured
libvirt is not configured for vdsm yet
Traceback (most recent call last):
File "/usr/bin/vdsm-tool", line 145, in <module>
sys.exit(main())
File "/usr/bin/vdsm-tool", line 142, in main
return tool_command[cmd]["command"](*args[1:])
File "/usr/lib64/python2.7/site-packages/vdsm/tool/configurator.py", line 224, in isconfigured
if c.getName() in args.modules and not c.isconfigured()
File "/usr/lib64/python2.7/site-packages/vdsm/tool/configurator.py", line 166, in isconfigured
raise RuntimeError("sanlock service requires restart")
RuntimeError: sanlock service requires restart
vdsm: failed to execute check_is_configured, error code 1
A brief look at lib/vdsm/tool/configurator.py makes me see that:
--pre-start calls configurator.py:configure()
that configure() checks all the configurers and calls isconfigured() on them to
determine which should be stopped, configured and started again.
that SanlockMonduleConfigure, instead of returning False when the sanlock user
has been added to the kvm and qemu groups raises an exception instead of
returning False.
This exception raising seems counterintuitive, shouldn't we only raise
exception if a configuration is not possible? I manually stopped sanlock:
systemctl stop sanlock
and performed the configuration step in configurator.py
usermod -a -G qemu,kvm sanlock
and after this /proc/$sanlock_pid/status reported the proper pid.
Is there something I am missing for which it is necessary to raise and prevent
the configuring?
Best,
Toni
10 years, 6 months
Re: [vdsm] [Users] Trouble Upgrading (Fedora)
by Dan Kenigsberg
Joining two threads on that subject
On Sun, Nov 24, 2013 at 11:32:55AM -0500, Yaniv Bronheim wrote:
> Hey,
>
> ----- Original Message -----
> > From: "Nicholas Kesick" <cybertimber2000(a)hotmail.com>
> > To: "oVirt Mailing List" <users(a)ovirt.org>
> > Sent: Friday, November 22, 2013 6:55:23 PM
> > Subject: [Users] Trouble Upgrading (Fedora)
> >
> > I am having trouble upgrading on Fedora 19 to 3.3.1.
> >
> > Two observations:
> > 1) I can't find ovirt-engine-3.3.1, even after a yum clear all; yum update.
> >
> >
> > 2) There is a dependency update circle involving
> > python-cpopen-1.2.3-4.fc19.x86_64 and dsm-python-cpopen.x86_64
> > 0:4.13.0-11.fc19
>
> This issue is fine. Not so smoothly but we had to do that.
> cpopen package is published as part of vdsm code in ovirt-3.3 and before,
> On master branch we require python-cpopen formal package that is shipped with fedora\rhel currently .
>
> Each time you'll switch between newer version of current master (3.4) to ovirt-3.3 or older you will notice this report
We should break this vicious cycle.
I think it was intended to simplify "upgrade" from ovirt-3.4 to
ovirt-3.3 on Jenkins slaves. But that's plain wrong on a wider context.
The Jenkins issue should be solved explicitly by removing python-cpopen
when vdsm-python-cpopen has to be installed.
Dan.
10 years, 6 months
Latest master fails to start due to logging
by asegurap@redhat.com
Hi List,
I just upgraded my testing vdsm to the new master and vdsmd fails to go
up due to:
[vdsm@nx01]~% /usr/share/vdsm/vdsm
Traceback (most recent call last):
File "/usr/share/vdsm/vdsm", line 175, in <module>
run(**argDict)
File "/usr/share/vdsm/vdsm", line 67, in run
lconfig.fileConfig(loggerConfFile)
File "/usr/lib64/python2.7/logging/config.py", line 78, in fileConfig
handlers = _install_handlers(cp, formatters)
File "/usr/lib64/python2.7/logging/config.py", line 156, in _install_handlers
h = klass(*args)
File "/usr/lib64/python2.7/logging/handlers.py", line 392, in __init__
logging.FileHandler.__init__(self, filename, mode, encoding, delay)
File "/usr/lib64/python2.7/logging/__init__.py", line 902, in __init__
StreamHandler.__init__(self, self._open())
File "/usr/lib64/python2.7/logging/__init__.py", line 925, in _open
stream = open(self.baseFilename, self.mode)
IOError: [Errno 13] Permission denied: '/var/log/vdsm/upgrade.log'
I'd appreciate it if somebody could point me if there is a known patch for that
Best,
Toni
10 years, 6 months
[Users] Problem with python-cpopen dependency on f19 AIO stable
by Vinzenz Feenstra
Forwading to vdsm-devel
On 12/04/2013 08:59 AM, Gianluca Cecchi wrote:
> Hello,
> since yesterday evening I have this sort of dependency problem with updates
>
> yum update
> say
>
> Resolving Dependencies
> --> Running transaction check
> ---> Package python-cpopen.x86_64 0:1.2.3-4.fc19 will be obsoleting
> ---> Package vdsm-python-cpopen.x86_64 0:4.13.0-11.fc19 will be obsoleted
> --> Finished Dependency Resolution
>
> Dependencies Resolved
>
> =============================================================================================================================
> Package Arch Version
> Repository Size
> =============================================================================================================================
> Installing:
> python-cpopen x86_64
> 1.2.3-4.fc19 updates 19 k
> replacing vdsm-python-cpopen.x86_64 4.13.0-11.fc19
>
> Transaction Summary
> =============================================================================================================================
> Install 1 Package
>
> If I go ahead and run yum update again I have:
>
> Dependencies Resolved
>
> =============================================================================================================================
> Package Arch Version
> Repository Size
> =============================================================================================================================
> Installing:
> vdsm-python-cpopen x86_64
> 4.13.0-11.fc19 ovirt-stable 20 k
> replacing python-cpopen.x86_64 1.2.3-4.fc19
>
> Transaction Summary
> =============================================================================================================================
> Install 1 Package
>
> and so again in a loop....
>
> Gianluca
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
--
Regards,
Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years, 6 months
VDSM and Fedora 20 test
by Douglas Schilling Landgraf
Hi,
Below the initial tests that I have executed with vdsm version
(4.13.0-11 and 4.13.0-12) on Fedora 20. Faced an 'iscsiadm: Error while
adding record: no available memory' trying to connect to iscsi storage
and opened a bugzilla [1] for it.
Engine and otopi
=====================
oVirt Engine Version: 3.4.0-0.2.master.20131129131413.git3f58634.fc19
otopi-1.1.2-1.fc19
Hosts
===============
# cat /etc/fedora-release
Fedora release 20 (Heisenbug)
# getenforce
Enforcing
vdsm 4.13.0-11 (current stable)
====================================
- Host deployed
NFS:
- Added NFS DATA and ISO [OK]
- Created and started VM (SPICE) [OK]
ISCSI:
Thread-927::ERROR::2013-12-03
00:06:26,672::hsm::2364::Storage.HSM::(connectStorageServer) Could not
connect to storageServer
Traceback (most recent call last):
File "/usr/share/vdsm/storage/hsm.py", line 2361, in connectStorageServer
conObj.connect()
File "/usr/share/vdsm/storage/storageServer.py", line 359, in connect
iscsi.addIscsiNode(self._iface, self._target, self._cred)
File "/usr/share/vdsm/storage/iscsi.py", line 150, in addIscsiNode
iscsiadm.node_new(iface.name, portalStr, targetName)
File "/usr/share/vdsm/storage/iscsiadm.py", line 239, in node_new
raise IscsiNodeError(rc, out, err)
IscsiNodeError: (3, [], ['iscsiadm: Error while adding record: no
available memory'])
4.13.0-12 (BETA build 3.3.2)
===============================================
- Host deployed
NFS:
- Added NFS DATA and ISO [OK]
- Created and started VM (SPICE) [OK]
ISCSI:
Thread-498::ERROR::2013-12-03
00:33:29,199::hsm::2369::Storage.HSM::(connectStorageServer) Could not
connect to storageServer
Traceback (most recent call last):
File "/usr/share/vdsm/storage/hsm.py", line 2366, in connectStorageServer
conObj.connect()
File "/usr/share/vdsm/storage/storageServer.py", line 359, in connect
iscsi.addIscsiNode(self._iface, self._target, self._cred)
File "/usr/share/vdsm/storage/iscsi.py", line 150, in addIscsiNode
iscsiadm.node_new(iface.name, portalStr, targetName)
File "/usr/share/vdsm/storage/iscsiadm.py", line 239, in node_new
raise IscsiNodeError(rc, out, err)
IscsiNodeError: (3, [], ['iscsiadm: Error while adding record: no
available memory'])
[1] F20: iscsiadm: Error while adding record: no available memory
https://bugzilla.redhat.com/show_bug.cgi?id=1037602
--
Cheers
Douglas
10 years, 6 months
vdsm sync meeting December 2th
by Douglas Schilling Landgraf
VDSM sync meeting Monday December 2th 2013
=============================================
- Douglas going to make tests between VDSM and Fedora 20
- Antoni will rework on the 'make dist check' patches.
- Dan raised to have virt functional tests for checking vdsm
failure/disconnect versus reconnect. Antoni going to check with Martin.
- Federico going to review:
tests: Add simple mocking library
http://gerrit.ovirt.org/#/c/21155/
- Antoni raised the thread:
seobject vdsm master install
https://lists.fedorahosted.org/pipermail/vdsm-devel/2013-November/002773....
- Yaniv going to check with Federico the ovirt-host-deploy/libvirt
fallback problem.
- Dan raised that we are going to increase the version of iscsi (rpm
dependency)
- Federico to review Douglas's doc about building new release:
http://www.ovirt.org/Vdsm_Developers#Building_new_releases_for_Fedora_or_...
- tarball release - Yaniv is going to talk with infra team to check the
best way to provide the vdsm tarball and patches. We never done it
before, until now only provided the srpm/rpm builds.
- The below patch going to be verified:
Removing hack for stopping libvirt-guests as conflict service
http://gerrit.ovirt.org/#/c/21205/1
- Fedora rpm branches and vdsm beta/stable builds.
Yaniv and Douglas to push new beta 3.3.2 vdsm rpm into master branch.
--
Cheers
Douglas
10 years, 6 months
Fedora 20 seobject vdsm master install
by asegurap@redhat.com
Hi List,
I just built master with some gerrit patch and when installing in Fedora20 I
get the following:
Installing : vdsm-python-4.13.0-179.gite51bbc3.fc20.x86_64 1/7
Installing : vdsm-xmlrpc-4.13.0-179.gite51bbc3.fc20.noarch 2/7
Installing : vdsm-python-zombiereaper-4.13.0-179.gite51bbc3.fc20.noarch 3/7
Installing : vdsm-4.13.0-179.gite51bbc3.fc20.x86_64 4/7
Traceback (most recent call last):
File "/usr/bin/vdsm-tool", line 145, in <module>
sys.exit(main())
File "/usr/bin/vdsm-tool", line 142, in main
return tool_command[cmd]["command"](*args[1:])
File "/usr/lib64/python2.7/site-packages/vdsm/tool/seboolsetup.py", line 59, in sebool_config
setup_booleans(True)
File "/usr/lib64/python2.7/site-packages/vdsm/tool/seboolsetup.py", line 41, in setup_booleans
sebool_obj = seobject.booleanRecords()
File "/usr/lib/python2.7/site-packages/seobject/__init__.py", line 2070, in __init__
semanageRecords.__init__(self, store)
File "/usr/lib/python2.7/site-packages/seobject/__init__.py", line 205, in __init__
self.mylog = logger()
File "/usr/lib/python2.7/site-packages/seobject/__init__.py", line 90, in __init__
self.audit_fd = audit.audit_open()
OSError: [Errno 93] Protocol not supported
OSError: Protocol not supported
Installing : vdsm-debug-plugin-4.13.0-179.gite51bbc3.fc20.noarch 5/7
Installing : vdsm-reg-4.13.0-179.gite51bbc3.fc20.noarch 6/7
Installing : vdsm-cli-4.13.0-179.gite51bbc3.fc20.noarch 7/7
Verifying : vdsm-debug-plugin-4.13.0-179.gite51bbc3.fc20.noarch 1/7
Verifying : vdsm-reg-4.13.0-179.gite51bbc3.fc20.noarch 2/7
Verifying : vdsm-python-zombiereaper-4.13.0-179.gite51bbc3.fc20.noarch 3/7
Verifying : vdsm-cli-4.13.0-179.gite51bbc3.fc20.noarch 4/7
Verifying : vdsm-4.13.0-179.gite51bbc3.fc20.x86_64 5/7
Verifying : vdsm-xmlrpc-4.13.0-179.gite51bbc3.fc20.noarch 6/7
Verifying : vdsm-python-4.13.0-179.gite51bbc3.fc20.x86_64
Shouldn't the auditing be optional (I have audit=0 in the kernel cmdline).
Best,
Toni
10 years, 6 months