oVirt 3.4 test day - PPC support
by bazulay@redhat.com
Hi,
I tried to test various engine features related to PPC support,
However since I don't have a real Power PC HW I tried using the fake PPC configuration introduced by http://gerrit.ovirt.org/#/c/18718
So I added the following configuration to /etc/vdsm/vdsm.conf on a x86_64 host:
fake_kvm_support=true
fake_kvm_architecture=ppc64
And indeed it looked successful as you can see below
[root@bazulay1 ~]# vdsClient -s 0 getVdsCaps | grep -i cpu
cpuCores = '4'
cpuFlags = 'powernv,model_POWER7_v2.3'
cpuModel = 'POWER 7 (fake)'
cpuSockets = '1'
cpuSpeed = '3401.000'
cpuThreads = '8'
However after creating the appropriate cluster:
CPU Architecture = ppc64
CPU name = IBM POWER 7* (meaning I tried all IBM POWER 7... cpus)
Adding the host always ended in non operational status with the error:
"Host bazulay1 has architecture x86_64 and cannot join Cluster TESTDAY-CLUSTER which has architecture ppc64."
Thanks
Barak Azulay
10 years, 5 months
[Users] The machine type of one cluster
by Kewei Yu
Hi all:
There is a "machine type" in cluster, It will decide which machine of
Qemu will be used, When we add the first host into cluster, a default
machine type is shown. We can correct the DB's value of the engine to set
the machine type.
I just want to know how dose cluster choice the default machine? It is
decided by VDSM? Qemu? or It is only fixed value in engine's DB?
Regard
Kewei
10 years, 5 months
Re: [vdsm] [Users] oVirt 3.4.0 beta - Hosted Engine Setup -- issues
by Sandro Bonazzola
Il 23/01/2014 15:21, Brad House ha scritto:
> On 01/23/2014 08:30 AM, Sandro Bonazzola wrote:
>> It seems that VDSM is not working on your system.
>> Can you attach vdsm logs?
>>
>
> vdsm log is empty
>
> # ls -l /var/log/vdsm/vdsm.log
> -rw-r--r-- 1 root root 0 Jan 20 10:13 /var/log/vdsm/vdsm.log
>
>
> # ps -ef | grep -i vdsm
> root 1628 1 0 09:16 ? 00:00:00 /usr/bin/python /usr/share/vdsm/supervdsmServer --sockfile /var/run/vdsm/svdsm.sock
>
>
> # service vdsmd status
> Redirecting to /bin/systemctl status vdsmd.service
> vdsmd.service - Virtual Desktop Server Manager
> Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled)
> Active: failed (Result: start-limit) since Thu 2014-01-23 09:16:38 EST; 1min 26s ago
> Process: 2387 ExecStopPost=/usr/libexec/vdsm/vdsmd_init_common.sh --post-stop (code=exited, status=0/SUCCESS)
> Process: 2380 ExecStart=/usr/share/vdsm/daemonAdapter -0 /dev/null -1 /dev/null -2 /dev/null /usr/share/vdsm/vdsm (code=exited, status=1/FAILURE)
> Process: 2328 ExecStartPre=/usr/libexec/vdsm/vdsmd_init_common.sh --pre-start (code=exited, status=0/SUCCESS)
>
> Jan 23 09:16:38 ovirttest.internal.monetra.com systemd[1]: Unit vdsmd.service entered failed state.
> Jan 23 09:16:38 ovirttest.internal.monetra.com systemd[1]: vdsmd.service holdoff time over, scheduling restart.
> Jan 23 09:16:38 ovirttest.internal.monetra.com systemd[1]: Stopping Virtual Desktop Server Manager...
> Jan 23 09:16:38 ovirttest.internal.monetra.com systemd[1]: Starting Virtual Desktop Server Manager...
> Jan 23 09:16:38 ovirttest.internal.monetra.com systemd[1]: vdsmd.service start request repeated too quickly, refusing to start.
what's this ^^^^. It's the first start of vdsmd!
> Jan 23 09:16:38 ovirttest.internal.monetra.com systemd[1]: Failed to start Virtual Desktop Server Manager.
> Jan 23 09:16:38 ovirttest.internal.monetra.com systemd[1]: Unit vdsmd.service entered failed state.
>
>
> I've attached the supervdsm.log and ovirt-hosted-engine-setup-20140123091611.log incase that's helpful.
>
> Thanks.
> -Brad
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years, 5 months
Vdsm network functional tests taking slave offline
by dcaroest@redhat.com
Hi!
We have been seeing the slave that is used for the network tests getting offline
from time to time, it was dues to vdsm_functional_tests not cleaning up
properly, as removing all the *dummy* interface configurations from
/etc/sysconfig/network-scripts and restarting the network brings it back again.
Can you take a look on why it would not have been cleaning up properly?
the last job that made the host go offline is:
http://jenkins.ovirt.org/job/vdsm_network_functional_tests/1173/console
The number of the dummy interface that was left over was 6 (not sure it's
reelevant, but just in case).
Thanks!
--
David Caro
Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D
Email: dcaro(a)redhat.com
Web: www.redhat.com
RHT Global #: 82-62605
10 years, 5 months
Re: [vdsm] [ANN] oVirt 3.4.0 Test Day - Tomorrow Jan 23th
by Sandro Bonazzola
Il 23/01/2014 07:45, Ramesh Nachimuthu ha scritto:
> Hi,
>
> After adding the node to engine, it goes to non operational state with the error "Host 10.70.43.160 is compatible with versions (3.0,3.1,3.2,3.3) and cannot join Cluster Default which is set to version 3.4.".
>
> I have enabled the repo http://resources.ovirt.org/releases/3.4.0_pre/rpm/Fedora/$releasever/ in host.
>
> Following is the vdsm version installed in F19 node:
>
> [root@localhost ~]# rpm -qa | grep vdsm
> vdsm-cli-4.14.1-2.fc19.noarch
> vdsm-4.14.1-2.fc19.x86_64
> vdsm-python-4.14.1-2.fc19.x86_64
> vdsm-python-zombiereaper-4.14.1-2.fc19.noarch
> vdsm-xmlrpc-4.14.1-2.fc19.noarch
> vdsm-gluster-4.14.1-2.fc19.noarch
>
>
> [root@localhost ~]# vdsClient -s 0 getVdsCaps
> clusterLevels = ['3.0', '3.1', '3.2', '3.3']
>
> Anything I am missing here?
Same here, if it's not already there, please open a BZ on VDSM.
As temporary workaround, please use cluster with 3.3 cluster level
>
>
> Regards,
> Ramesh
> ----- Original Message -----
> From: "Sandro Bonazzola" <sbonazzo(a)redhat.com>
> To: "arch" <arch(a)ovirt.org>, "engine-devel" <engine-devel(a)ovirt.org>, Users(a)ovirt.org
> Sent: Wednesday, January 22, 2014 6:37:23 PM
> Subject: [ANN] oVirt 3.4.0 Test Day - Tomorrow Jan 23th
>
> Hi all,
> tomorrow Jan 23th we'll have oVirt 3.4.0 test day.
>
> On this day all relevant engineers will be online ready to support
> any issues you find during install / operating this new release.
>
> Just make sure you have 1 hosts or more to test drive the new release.
> If you're curious to see how it works, this is your chance.
>
> Thanks again for everyone who will join us tomorrow!
>
> Location
> #ovirt irc channel
> Please communicate here to allow others to see any issues
>
> What
> In this test day you have a license to kill ;)
> Follow the documentation to setup your environment, and test drive the new features.
> Please remember we expect to see some issues, and anything you come up with will save a you when you'll install final release
> Remember to try daily tasks you'd usually do in the engine, to see there are no regressions.
> Write down the configuration you used (HW, console, etc) in the report etherpad[1].
>
> Documentation
> Release notes: http://www.ovirt.org/OVirt_3.4.0_release_notes
> Features pages links: http://bit.ly/17qBn6F
> If you find errors in the wiki please annotate it as well in report etherpad [1]
>
> Prerequisites / recommendations
> Use CentOS or RHEL 6.5 only. 6.4 is unsupported due to various issues (sanlock, libvirt, etc).
> Use Fedora 19 only. Fedora 20 is unsupported due to various issues (sos, jboss).
>
> Latest RPMs
> repository to be enabled for testing the release are listed in the release notes page [2].
>
> NEW issues / reports
> For any new issue, please update the reports etherpad [1]
>
> Feature owners, please make sure:
> your feature is updated and referenced on release page [2].
> you have testing instruction for your feature either on test day page [3] or in your feature page.
> your team regression testing section is organized and up to date on test day page [3].
>
>
> [1] http://etherpad.ovirt.org/p/3.4-testday-1
> [2] http://www.ovirt.org/OVirt_3.4.0_release_notes
> [3] http://www.ovirt.org/OVirt_3.4_Test_Day
>
>
> Thanks.
>
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years, 5 months
[gerrit 23138] VM responsiveness and libvirt timeouts
by fromani@redhat.com
Hi everyone,
I'd like to gather some thoughts about this change http://gerrit.ovirt.org/#/c/23138/5
Sorry for the long mail, but the scenario is not trivial to explain and I tried
to achieve a decent compromise between terseness and completeness.
Context
-------
Everything starts from the bugzilla https://bugzilla.redhat.com/866484 .
Summary of the bug: when a blockInfo call to libvirt goes in timeout,
the status of the affected VM start to bounce in the engine between
'Non Responsive' and 'Up'.
This is because the responsiveness of a VM is tracked using a single flag,
updated each after libvirt call, and the flag could be overwritten behind the back of
the engine (between two getStats). In a nutshell, the responsiveness of a VM
could observed in a different way depending on the time sequence of the updates.
It is worth to mention that, I *cannot* yet reproduce in the terms described in the bug
description.
Part of the reason why I failed to reproduce it is a particular event sequence
is required to achieve the bouncing effect described in the bug.
The event sequence is in turn determined by the timing of the block storage timeout
and by the time the engine queries the affected VDSM.
However, my understanding is that the scenario which emerges from the bug description
and the analysis of the logs attached to the bug is still relevant, although somewhat
unlikely. This is the reason why I submitted the change http://gerrit.ovirt.org/#/c/23138/5
The issue with the new patch
----------------------------
The new code determines the responsiveness of the monitor -and thus of the VM-
in a `pessimistic` way, meaning that now as long as at least one call to libvirt fails,
the VM is deemed unresponsive.
On the other hand, with the current code, if an attribute is unresponsive but if the sequence
of events is "good" enough, the not responsive time interval could be hidden from the engine's sight.
Or, of course, the engine could see the bouncing we're discussing.
In a nutshell, the new code could be too pessimistic in reporting the state.
A VM could be reported not responsive longer and more often (again it all depends on the event
sequence) than before.
It that is the case, the problem is: how to fix the reporting in a more "optimistic" way?
Possible solution
-----------------
While reviewing the change with Michal, we found that partitioning the set of
the calls to be monitored in critical/not critical could be a way:
* critical libvirt calls: if at least one fails for timeout, and while it fails for timeout,
the VM is considered Unresponsive.
* not critical: a timeout is logged but ignored to decide the responsiveness of the VM
Would that be an improvement with respect to the current state and, possible, a viable
long-term solution?
Any advice will be greatly appreciated.
Thanks and regards,
--
Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani
10 years, 5 months
ovirt-guest-agent on debian
by Sven Kieske
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
here are my results so far.
I did:
install debian 7 x64 into a vm
as root:
mkdir code
cd code
git clone git://gerrit.ovirt.org/ovirt-guest-agent
cd ovirt-guest-agent
./autogen.sh
./autogen.sh: 3: ./autogen.sh: autoreconf: not found
apt-get install dh-autoreconf
./autogen.sh
./configure
configure: error: no suitable Python interpreter found
apt-get install python
./configure
./configure: line 15790: --variable=systemdsystemunitdir: command not
found
checking for pep8... no
configure: WARNING: python-pep8 not found
./configure: line 15868: syntax error near unexpected token 'GDM_PLUGIN, '
./configure: line 15868: ' PKG_CHECK_MODULES(GDM_PLUGIN; '
apt-get install pep8
I found this:
http://lists.ovirt.org/pipermail/users/2013-August/015773.html
so I tried:
./configure --with-gdm=no --with-sso=no
but I get the same errors again.
Doing "less configure" shows however that this options should be
recognized and supported?
Any help will be appreciated.
I will try to maintain some manual and get patches in so we can
get a stable build for Debian.
Thanks for your time.
Sven
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQGcBAEBAgAGBQJS3ttmAAoJEAq0kGAWDrqlezAMAJwi4ZPMdWCCANUdWn7fPUDm
6QsAamcaNm5pcSwUHYKMLjhfn+UO2NoVb/f46UVOSadJ1Yfr7CbVutnRy+W0MMjR
PehaoZw5o2bJ09Is8nLN505iriiw4Xvwk1MvmYCIj8XcHC0Uj3q+VU7erV0fE4Js
XHUMuHto8S/4op9MDAfjAAJfu0l/9ADSIcp4HRo75NCqt0r3wccT8tSI/t+ABYc1
7luDA0RqRAbnYgqZPgfv7P3l0wHy5SBCEbFP8md5CH0VHJw1w8x40Mx4X9K1UI2g
9nkyI+ObNlTI7ori6OP0ZHjQpddzQlO8r965rANW4Zlj4YHwRL6Z0YlgVNzIlFLJ
ps5qAKc2xxXfC3cqk/EGalGaLGwQNV1rI1s/Ah/jsET0sNAc55tBFvsYOQxkoVit
lFbzXm9J17kUBb+EcIxMihkU2abQMx+j4KVaxA430uwggQL1mmTLgGfgBtFhOB8t
laWExv4FAoy4UQLHkOptmscPiRfKPAzRvXNd9q5oMg==
=b9/7
-----END PGP SIGNATURE-----
10 years, 5 months
Re: [vdsm] [Users] Problem with python-cpopen dependency on f19 AIO stable
by Sven Kieske
Hi,
was this resolved for EL 6.5?
I'm currently planning to roll out EL 6.5 Nodes and would like
to know how to circumvent this issue if it is still present?
Am 05.12.2013 12:13, schrieb Martijn Grendelman:
> I have the same issue on a CentOS node after updating it to 6.5:
>
>> Resolving Dependencies
>> --> Running transaction check
>> ---> Package python-cpopen.x86_64 0:1.2.3-4.el6 will be obsoleted
>> ---> Package vdsm-python-cpopen.x86_64 0:4.13.0-11.el6 will be obsoleting
>> --> Finished Dependency Resolution
>>
>> Dependencies Resolved
>>
>> ========================================================================================================================================================
>> Package Arch Version Repository Size
>> ========================================================================================================================================================
>> Installing:
>> vdsm-python-cpopen x86_64 4.13.0-11.el6 ovirt-stable 19 k
>> replacing python-cpopen.x86_64 1.2.3-4.el6
>>
>> Transaction Summary
>> ========================================================================================================================================================
>> Install 1 Package(s)
>>
>> Total download size: 19 k
>> Is this ok [y/N]: y
>
> On a subsequent run of 'yum update', python-cpopen will replace
> vdsm-python-cpopen, and so on.
>
> Vinzenz Feenstra schreef op 5-12-2013 8:34:
>> 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
--
Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
10 years, 5 months
Nightly vdsm on rhel 6.5 and pcopen
by Piotr Kliczewski
I wanted to install vdsm on my rhel 6.5 and it failed during deployment due to
http://fpaste.org/70327/90316269/
I looks like together with vdsm-4.14.0-44.gitb22e719.el6 yum wants to install
vdsm-python-cpopen-4.13.2-0.6.el6ev.x86_64.
When I yum searched for python-cpopen I only have vdsm-python-cpopen.
I checked on customer portal and when looking for python-cpopen get again only
vdsm-python-cpopen-4.13.2-0.6.el6ev.x86_64.
I do not see vdsm-python-cpopen in the spec.
How can I have vdsm up and running on my el6?
10 years, 5 months