ovirt storage creation problems
by aditya mamidwar
hey
am facing following problem while creating new storage domain in ovirt.
PFA screenshot and log file details
--
-Aditya Mamidwar
10 years, 4 months
New gerrit flags behavior
by dcaroest@redhat.com
Hi everyone!
With the latest gerrit upgrade it has become easier to add the propagation of
the Code Review and Verified flags when doing a trivial rebase or when no code
was changed, so I've enabled those features for all the projects!
The change should become effective right away, so let me know if you have any
issues.
Enjoy!
--
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, 4 months
Re: [vdsm] [Users] ovirt-3.3.3 release postponed due to blockers
by Sandro Bonazzola
Il 29/01/2014 09:21, Sven Kieske ha scritto:
> Hi,
>
> I wanted to try it the other way around, installing vdsm-python-cpopen
> and check if it runs without python-cpopen .
>
> But that leads me to a question:
>
> Is there any difference between these packages beside their different
> name?
>
> If yes, what is the difference and which package should be installed?
> I no, why is there a packet vdsm-python-cpopen ?
CCing VDSM
>
> Thank you!
>
>
> Am 28.01.2014 20:14, schrieb Trey Dockendorf:
>> I found manually installing python-cpopen before adding a node in the
>> engine is a viable workaround. This was on EL6.5
>>
>> - Trey
>
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years, 4 months
Re: [vdsm] [Users] ovirtmgmt vanishes after reboot
by fabiand@redhat.com
Am Donnerstag, den 23.01.2014, 12:34 -0300 schrieb Francisco Pérez:
> Hi. I have configured an ovirt-engine to manage an ovirt node
> succesfully. I have created VM and all runs well but im trying to do
> some escenario testing and i have found an issue.
>
>
> If somehow the ovirt node is rebooted(Power failure, crash, manual
> reboot, etc) when its comes up it does not start the ovirtmgmt
> network. Even if in the ovirt-engine you save network configuration or
> if you execute persist
> on /etc/sysconfig/network-scripts/ifcfg-ovirtmgmt. It tells you it's
> already been added to the configuration.
>
>
> Is this normal behavior after ovirt node's is rebooted? Am i doing
> something wrong?
Hey Francisco,
that sounds like a bug.
VDSM Devs, how can we debug why the network is not brought up?
- fabian
10 years, 4 months
Gerrit NEW Change Screen
by iheim@redhat.com
with gerrit 2.8, there is a new change screen.
its not enabled by default (yet), please use and see what you think.
to enable, go to settings (click the top-right arrow next to your name,
and choose settings).
select preferences and set "Change View:" to "New Screen".
Thanks,
Itamar
10 years, 4 months
ovirt-3.3.3 release postponed due to blockers
by Sandro Bonazzola
Hi,
oVirt 3.3.3 release need to be postponed.
A recent release of python-cpopen-1.3 is breaking dependency resolution on EL6 and F19 so vdsm can't be installed and node can't be composed.
A recent change in vdsm-python-cpopen added the needed conflict against python-cpopen and removed Provides / Obsoletes on python-cpopen.
But no new releases of python-cpopen is available fixing the correct Provides / Obsoletes pair.
oVirt 3.3.2 / stable is affected too.
Please fix
Bug 1056470 - python-cpopen-1.3 is not providing obsoleted package.
Bug 1056464 - python-cpopen-1.3 is not providing obsoleted package.
ASAP.
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years, 4 months
Introduction of VDSM <-> Guest Agent API Versioning
by Vinzenz Feenstra
Hi,
With the increasing complexity on different version of the guest agent
and vdsm
I have proposed a patchset for each the guest agent and vdsm to
implement it on
top of the current protocol, in a way that it will not affect the
existing protocol.
This patchset has created some controversy about its implementation and
design
and I was asked to kick off a discussion to design a better
implementation or
validate the suggested approach.
My goals for the API versioning:
===============================
- Make VDSM and the Guest Agent both aware of what the other side
understands
(which messages) to avoid logging errors
- The used version of the API should be automatically and immediately be
agreed
upon in case any change happened. And in case one end doesn't support
it but
the other does, the supporting end must revert back to a compatible
state.
Possible scenarios:
- a VM gets migrated from a VDSM version with API version support to
a VDSM
without API version support (or lower version)
- VDSM gets downgraded or upgraded and the API version changed or is no
longer supported
- The ovirt-guest-agent gets up or downgraded
- Make use of existing messages which allow extending without generating
errors
or would result in VDSM API changes due to direct export of the
message, to be
backwards compatible on both ends
From my side not considered as goals for the API Versioning:
======================================================
- Deprecation of messages, because you can send alternatives if the
other side
supports it
- Raising the lowest supported API version, as this would actually break
backwards
compatibility
The proposed solution:
======================
VDSM:
- Add a field to the 'refresh' message reporting the highest API version
supported by VDSM
- Upon receiving the 'heartbeat' message check for the `apiVersion` field
to know if the guest agent supports api versioning.
- If the fields is not present:
The guest agent won't support api versioning. And it needs to be
disabled on the VDSM side and the version 0 has to be assumed. That
simply means only messages can be sent which were supported
before the
API versioning was introduced.
- If the field is present:
The value of the field is supposed to represent the maximum version
supported by the guest agent.
VDSM then makes a `min(vdsmMaxApiVersion, guestAgentMaxApiVersion)`
to determine the highest common value and uses this value as
supported
API version.
When the value has changed since the last time a heartbeat was
received.
VDSM will send a message 'api-version' to update the guest agent
about
the determined value. And sets the internally stored apiVersion value
to this new value.
Guest Agent:
- Adds the field `apiVersion` to the heartbeat containing the
highest API
version supported by the guest agent
- Upon receiving the `refresh` message without a `apiVersion` field, the
guest agent immediately will revert immediately fall back to version 0
To avoid sending any messages which are not yet supported.
- Upon receiving the `api-version` message, the guest agent will
verify the
value received and sets the value to min(received, maxAgentApiVersion)
which should, of course, result in setting the received value (this is
just an additional step to ensure it does not send more than
supported by
VDSM.
Once having the API version, we can use some lookup table for the messages
before sending and check which version is required to send it. And we would
even be able to give some feedback if we support a feature or not on the
guest
side.
Please let me know your opinion and I would be welcoming suggestions or any
other comment related to this.
Thanks.
--
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, 4 months