[ovirt-users] Re: Cluster compatibility 4.1 to 4.2 upgrade

2018-05-09 Thread Michal Skrivanek
On 8 May 2018, at 09:29, Demeter Tibor  wrote:

Dear Listmember,

I've just upgrade to my ovirt-hosted-engine from 4.1 to 4.2.3. It was
successful, but it saw "Data Center XYZ compatibility version is 4.1, which
is lower than latest engine version 4.2. Please upgrade your Data Center to
latest version to successfully finish upgrade of your setup."

My first question is that, it need to do BEFORE or AFTER the node upgrades?

I haven't upgrade my nodes yet, because after upgrade the live migration
does not work with some VMs.  It seems only affected those VMs that's have
big (>8GB ) memory.  It counting to 99 percent and after a while just
stopped.


Did you try other migration policies?

At this moment I can't stop my affected, productive VMs, so I can't do the
upgrade of nodes.


They’re probably too active. Maybe you can stop some services inside those
guests? Migrate when they are not that busy?

I just wondering, if i do the upgrade to 4.2 , that's maybe repair my the
live migration function?

What can I do?

Centos 7.4, NFS storage, 4 nodes, Hyperconverged hosted engine.


Thanks in advance,
Tibor


___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] delete snapshot error

2018-05-09 Thread 董青龙
Hi all,
I am using ovirt4.1. I failed deleting a snapshot of a vm. The state of 
the snapshot stayed locked and I could not start the vm. Anyone can help? 
Thanks!


PS: some logs:
VDSM command ReconcileVolumeChainVDS failed: Could not acquire 
resource. Probably resource factory threw an exception.: ()
VDSM host command GetVGInfoVDS failed: Volume Group does not exist: 
(u'vg_uuid: nL3wgg-uctH-1lGd-Vyl1-f1P2-fk95-tH5tlj',)___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] ovirt4.1 repo error

2018-05-09 Thread Fernando Fuentes
I am trying to upgrade my ovirt cluster and came across a repo 404.

http://mirror.centos.org/centos/7/storage/x86_64/gluster-3.8/repodata/repomd.xml:
 [Errno 14] HTTP Error 404 - Not Found
Trying other mirror.


Any ideas how to fix it?
TIA!



-- 
Fernando Fuentes
ffuen...@txweather.org
http://www.txweather.org
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] oVIrt 4.2 could not boot up old < 4.2 image or new boot from virtual CD ROM

2018-05-09 Thread paul . lkw
Hi anyone:
Any one success in booting up FreeBSD 10.4 from oVIrt 4.2, seems a bug in oVirt 
!
However FreeBSD earlier than 10.4 (eg. 10.3, 10.2) is fine for booting up.

BR,
Paul.LKW
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] Re: routing

2018-05-09 Thread Edward Haas
On Mon, May 7, 2018 at 7:50 AM, Justin Zygmont 
wrote:

> Thanks for the reply,
>
>
>
> Ok I see what you’re saying, its just confusing because there are several
> places that mention the gateways and none of them are clear on what they’re
> doing.
>
> For example, under Cluster > Networks > Manage Networks,  default route is
> only selectable for 1 network, yet in each network you create there is
> still the option of choosing a IP address and gateway.
>

On the host there are multiple routing tables, the default main one
contains the default route of the host. Each defined network also maintains
its own routing table, for traffic that it generated or is destined to it
(in case the network has an IP).
So these are not the same things.


>
>
> Even if I don’t put in any IP or gateway for a tagged vlan, it still
> depends of the management gateway to forward to the router.  I thought I
> should be able to lose the management network and still have all the tagged
> vlans working?
>
Setting an IP on a network is useful if you need the *host* to communicate
with some remote on an IP level.
If you need VM communication, then an IP on a host network is not needed.
The vnics are connected through a bridge, not through a router. So traffic
from a VM is not passing through the L3 stack of the host and its routing
entries on the host do not effect that traffic.


>
>
>
>
>
> *From:* Edward Haas [mailto:eh...@redhat.com]
> *Sent:* Sunday, May 6, 2018 7:34 AM
> *To:* Justin Zygmont 
> *Cc:* users@ovirt.org
> *Subject:* Re: [ovirt-users] routing
>
>
>
> Not sure if I understand what you are asking here, but the need for a
> gateway per network has emerged from the need to support other host
> networks (not VM networks) beside the management one.
>
> As an example, migration and storage networks can be defined, each passing
> dedicated traffic (one for storage communication and another for VM
> migration traffic), they may need to pass through different gateways.
>
> So the management network can be accessed using gateway A, storage using B
> and migration using C. A will usually be set on a host level as the host
> default gateway, and the others will be set for the individual networks.
>
> Otherwise, how would you expect storage to use a different router (than
> the management one) in the network?
>
> Thanks,
>
> Edy.
>
>
>
> On Thu, May 3, 2018 at 1:08 AM, Justin Zygmont 
> wrote:
>
> I don’t understand why you would want this unless the ovirtnode itself was
> actually the router, wouldn’t you want to only have an IP on the management
> network, and leave the rest of the VLANS blank so they depend on the router
> to route the traffic:
>
>
>
> NIC1  -> ovirt-mgmt  - gateway set
>
> NIC2  -> VLAN3, VLAN4, etc…
>
>
>
>
>
> https://www.ovirt.org/documentation/admin-guide/chap-Logical_Networks/
> 
>
>
>
> *Viewing or Editing the Gateway for a Logical Network*
>
> Users can define the gateway, along with the IP address and subnet mask,
> for a logical network. This is necessary when multiple networks exist on a
> host and traffic should be routed through the specified network, rather
> than the default gateway.
>
> If multiple networks exist on a host and the gateways are not defined,
> return traffic will be routed through the default gateway, which may not
> reach the intended destination. This would result in users being unable to
> ping the host.
>
> oVirt handles multiple gateways automatically whenever an interface goes
> up or down.
>
>
>
>
>
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 
>
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] Re: How to update "quota_cluster_limit" settings of a quota object through REST API?

2018-05-09 Thread Andrej Krejcir
Hi,

Currently the REST API does not support updating the quota_cluster_limit
using the PUT method.

To change the limit, it has to be removed first using DELETE method and
then added again using POST.
The methods are described in the API documentation here:
http://ovirt.github.io/ovirt-engine-api-model/4.2/#services/quota_cluster_limit

The same also applies to quota_storage_limit.

The web UI does the same in the background, when changing
quota_cluster_limit or quota_storage_limit.

Best regards,
Andrej

On 9 May 2018 at 08:48, Shao-Da Huang  wrote:

> Hi,
>
> I can update the vCPU and memory quota by editing a Quota object of a
> datacenter through webadmin portal, but it seems that I cannot update
> through REST API...
>
> For example, I have a quota object with a global quota_cluster_limit
> object:
>
> GET https://192.168.80.168/ovirt-engine/api/datacenters/5ad4fafe
> -0253-0015-0215-0378/quotas/8a6b3336-2dfc-4e40-
> a58e-9bdcb45d228a/quotaclusterlimits/
>
> 
>   id="8a6b3336-2dfc-4e40-a58e-9bdcb45d228a"> 16.0
> 0.0 6
> 0  id="8a6b3336-2dfc-4e40-a58e-9bdcb45d228a"/> 
> 
>
> But when I try to do
>
> PUT
> https://192.168.80.168/ovirt-engine/api/datacenters/5ad4fafe
> -0253-0015-0215-0378/quotas/8a6b3336-2dfc-4e40-
> a58e-9bdcb45d228a/quotaclusterlimits/8a6b3336-2dfc-4e40-a58e-9bdcb45d228a
>
> with request body like:
> 
> 8
> 
>
> I got *405 Method Not Allowed.*
> Could anyone give me some advices?
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] Re: Mikrotik CHR guest agent

2018-05-09 Thread Tomáš Golembiovský
Hi,

On Wed, 9 May 2018 09:29:16 +
Magnus Isaksson  wrote:

> Hello all
> 
> I have installed MikroTik Cloud Hosted Router on my oVirt 4.2 setup
> It starts fine and so but oVirt complains about guest-agent.

oVirt complaints about missing oVirt Guest Agent. I doubt there is a
package for RouterOS.


> At MikroTik this information is available regarding guest-agent
> https://wiki.mikrotik.com/wiki/Manual:CHR#KVM
> 
> But I don't understand what I shall do with that information to get it 
> working.

The page talks about QEMU Guest Agent. We have introduced limited
support for it in oVirt 4.2 and you don't have to do anything besides
checking that it is installed and running.

Unfortunately this will not rid you of the warning about missing agent
in oVirt.

Tomas


> 
> Can somebody help me?
> 
> Regards
> Magnus
> 
> 


-- 
Tomáš Golembiovský 
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] Re: self hosted engine mac range and possible conflict

2018-05-09 Thread Gianluca Cecchi
On Wed, May 9, 2018 at 4:32 PM, Simone Tiraboschi 
wrote:

>
>
> On Wed, May 9, 2018 at 4:21 PM, Gianluca Cecchi  > wrote:
>
>> Hello,
>> suppose I have an environment with self hosted engine environment in 4.1
>>
>> How is it generated the hw address of the virtual nic of the engine vm
>> when I deploy using cockpit?
>>
>> Suppose on a lan I already have a self hosted engine environment and I'm
>> going to create another one on the same lan, is there any risck of hw
>> address collision for the engine?
>>
>> I know that from inside web admin console I can then set the hw address
>> ranges for the VMs, but what about the mac of the engine vm itself?
>>
>> At the moment I have only lan access and so crosschecked an RHV 4.1
>> environment and I see that the engine has hw addr 00:16:3e:7c:65:34 (a
>> lookup seems to associate to "Xensource, Inc.") while the VMs have their hw
>> addr in the range 00:1a:4a:16:01:51 - 00:1a:4a:16:01:e6 (eg
>> the 00:1a:4a:16:01:56) (a lookup seems to associate to "Qumranet Inc.".
>>
>> Does this mean that the engine has a sort of dedicated range? Any risk of
>> collision or is a query on the lan done before assigning it?
>>
>
> It has been discussed here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1244502
>
> In a few worlds: the proposed HE MAC address are explicitly on a different
> range just to minimize collision risks on complex scenarios.
>
>

Thanks Sandro,
Indeed I forgot that as part of the engine deploy (from cockpit but it
should be the same from the deprecated command line setup too) there is the
explicit option to specify hw address of its vnic.
In my case I'm proposed this one:
"
You may specify a unicast MAC address for the VM or accept a randomly
generated default [00:16:3e:15:6a:e5]:
"
So I should be in the safe place, as I have only one other engine vm and I
have no Xen based environments...
Gianluca
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] Re: self hosted engine mac range and possible conflict

2018-05-09 Thread Simone Tiraboschi
On Wed, May 9, 2018 at 4:21 PM, Gianluca Cecchi 
wrote:

> Hello,
> suppose I have an environment with self hosted engine environment in 4.1
>
> How is it generated the hw address of the virtual nic of the engine vm
> when I deploy using cockpit?
>
> Suppose on a lan I already have a self hosted engine environment and I'm
> going to create another one on the same lan, is there any risck of hw
> address collision for the engine?
>
> I know that from inside web admin console I can then set the hw address
> ranges for the VMs, but what about the mac of the engine vm itself?
>
> At the moment I have only lan access and so crosschecked an RHV 4.1
> environment and I see that the engine has hw addr 00:16:3e:7c:65:34 (a
> lookup seems to associate to "Xensource, Inc.") while the VMs have their hw
> addr in the range 00:1a:4a:16:01:51 - 00:1a:4a:16:01:e6 (eg
> the 00:1a:4a:16:01:56) (a lookup seems to associate to "Qumranet Inc.".
>
> Does this mean that the engine has a sort of dedicated range? Any risk of
> collision or is a query on the lan done before assigning it?
>

It has been discussed here:
https://bugzilla.redhat.com/show_bug.cgi?id=1244502

In a few worlds: the proposed HE MAC address are explicitly on a different
range just to minimize collision risks on complex scenarios.


>
> BTW: probably the range for engine VM hw addr has to be put in Qumranet
> too...?
>
> Thanks in advance,
>
> Gianluca
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] self hosted engine mac range and possible conflict

2018-05-09 Thread Gianluca Cecchi
Hello,
suppose I have an environment with self hosted engine environment in 4.1

How is it generated the hw address of the virtual nic of the engine vm when
I deploy using cockpit?

Suppose on a lan I already have a self hosted engine environment and I'm
going to create another one on the same lan, is there any risck of hw
address collision for the engine?

I know that from inside web admin console I can then set the hw address
ranges for the VMs, but what about the mac of the engine vm itself?

At the moment I have only lan access and so crosschecked an RHV 4.1
environment and I see that the engine has hw addr 00:16:3e:7c:65:34 (a
lookup seems to associate to "Xensource, Inc.") while the VMs have their hw
addr in the range 00:1a:4a:16:01:51 - 00:1a:4a:16:01:e6 (eg
the 00:1a:4a:16:01:56) (a lookup seems to associate to "Qumranet Inc.".

Does this mean that the engine has a sort of dedicated range? Any risk of
collision or is a query on the lan done before assigning it?

BTW: probably the range for engine VM hw addr has to be put in Qumranet
too...?

Thanks in advance,

Gianluca
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] Mikrotik CHR guest agent

2018-05-09 Thread Magnus Isaksson
Hello all

I have installed MikroTik Cloud Hosted Router on my oVirt 4.2 setup
It starts fine and so but oVirt complains about guest-agent.

At MikroTik this information is available regarding guest-agent
https://wiki.mikrotik.com/wiki/Manual:CHR#KVM

But I don't understand what I shall do with that information to get it working.

Can somebody help me?

Regards
Magnus


___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] Re: [ovirt-devel] Work-Around for Access Problem to resources.ovirt.org and jenkins.ovirt.org

2018-05-09 Thread Eyal Edri
On Wed, May 9, 2018 at 4:46 PM, Nir Soffer  wrote:

> On Wed, May 9, 2018 at 12:15 PM Anton Marchukov 
> wrote:
>
>> Hello All.
>>
>> Please note that ovirt.org got HSTS setting enabled.
>
> The way this
>> change was rolled was not authorised by us. The setting contains
>> “includeSubDomains” parameter that ask browser to access all resources
>> inside *.ovirt.org using https://.
>>
>> The problem is that not all resources on *.ovirt.org are
>> https-enabled. And this will prevent you from being able to access
>>
>> http://resources.ovirt.org
>> http://jenkins.ovirt.org
>>
>> This setting is cached in your browser and then applied with no
>> exceptions even if you explicitly specify http:// the browser will
>> rewrite to https and then connection to above mentioned resources will
>> fail.
>>
>> The only immediate work-around for you is to clear the HSTS flag in
>> your browser, please find the instructions for Firefox and Chrome [1].
>> Please note that you will get that setting back by visiting ovirt.org
>> website until we clear it from there.
>>
>> We are currently working on this setting to be soften or disabled till
>> all resources are https enabled that is also in progress.
>>
>> This is only related to access via the web browser. Accessing using
>> yum or automated scripts should work fine as they usually do not
>> observe and cache HSTS.
>>
>
> curl also fail to access jenkins.ovirt.org.
>
> Thanks for notifying, I'm failing to access jenkins since yesterday.
>
> Can we revert this change until we complete converting to https?
>

The change was reverted, so its just a matter of clearing cache, what is
the curl command you running and what is the error message?



>
> Nir
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
>
>


-- 

Eyal edri


MANAGER

RHV DevOps

EMEA VIRTUALIZATION R


Red Hat EMEA 
 TRIED. TESTED. TRUSTED. 
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] Re: [ovirt-devel] Work-Around for Access Problem to resources.ovirt.org and jenkins.ovirt.org

2018-05-09 Thread Nir Soffer
On Wed, May 9, 2018 at 12:15 PM Anton Marchukov  wrote:

> Hello All.
>
> Please note that ovirt.org got HSTS setting enabled.

The way this
> change was rolled was not authorised by us. The setting contains
> “includeSubDomains” parameter that ask browser to access all resources
> inside *.ovirt.org using https://.
>
> The problem is that not all resources on *.ovirt.org are
> https-enabled. And this will prevent you from being able to access
>
> http://resources.ovirt.org
> http://jenkins.ovirt.org
>
> This setting is cached in your browser and then applied with no
> exceptions even if you explicitly specify http:// the browser will
> rewrite to https and then connection to above mentioned resources will
> fail.
>
> The only immediate work-around for you is to clear the HSTS flag in
> your browser, please find the instructions for Firefox and Chrome [1].
> Please note that you will get that setting back by visiting ovirt.org
> website until we clear it from there.
>
> We are currently working on this setting to be soften or disabled till
> all resources are https enabled that is also in progress.
>
> This is only related to access via the web browser. Accessing using
> yum or automated scripts should work fine as they usually do not
> observe and cache HSTS.
>

curl also fail to access jenkins.ovirt.org.

Thanks for notifying, I'm failing to access jenkins since yesterday.

Can we revert this change until we complete converting to https?

Nir
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] Upgrade host to 4.2 - 10gbe connection does not work anymore

2018-05-09 Thread Demeter Tibor
Hi All, 

I did successfully upgraded my 4.1 hosted engine and the first node to 4.2.3. 
Since upgrade, the node's 10Gbe connection does not work. It was the connection 
between host and storage. That is why, now I can't activate my node. 
I have IP and I have all of bonding, and it seems to fine. All other networks 
and bonds (1gbe) is working fine, I can communicate with other hosts. 
I had a mode-1 (active/passive) bonding on that interfaces. I can ping from 
other nodes, but not from this. 
Also, I did a full OS upgrade (yum update) on node. 

Somebody could me help? 

Thanks in advance, 
R 
Tibor 




___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] Re: sun.security.validator.ValidatorException after update to 4.2.3

2018-05-09 Thread Yedidyah Bar David
On Wed, May 9, 2018 at 10:10 AM, Yedidyah Bar David  wrote:
> On Tue, May 8, 2018 at 7:11 PM, Sandro Bonazzola  wrote:
>> Adding Didi
>>
>> Il mar 8 mag 2018, 10:32 Jiří Sléžka  ha scritto:
>>>
>>> Hi,
>>>
>>> solution was obvious. Upgrade process modified apache's ssl.conf and
>>> reverted my customization.
>>>
>>> for example - my custom cert...
>>>
>>> SSLCertificateFile /etc/pki/tls/certs/ovirt.crt.pem
>>>
>>> ...was replaced by this
>>>
>>> SSLCertificateFile /etc/pki/ovirt-engine/certs/apache.cer
>>>
>>> the same for SSLCertificateKeyFile and SSLCACertificateFile
>
> Actually that was intended, see [1]. But I admit I didn't specifically
> think about 3rd-party CAs, sorry.
>
> You were notified about this by engine-setup, right?
>
> "Apache httpd SSL was already configured in the past,
> but some needed changes are missing there.
> Configure again? (Automatic, Manual) [Automatic]:"
>
> Please open a bug about this. Not sure exactly what the bug
> should say - perhaps that on upgrade, engine-setup should only
> touch specific values there, which do not include SSL*File,
> perhaps show to the user what we are actually going to change,
> perhaps default to 'No' - not sure about this - and change to
> 'Yes, No'.

Filed this for now:

https://bugzilla.redhat.com/show_bug.cgi?id=1576377

Feel free to comment there and/or add yourself to CC.

Thanks,

>
> [1] https://bugzilla.redhat.com/1558500
>
>>>
>>> After reverting this changes everything works as usual but it makes me
>>> unsure if I have my 3rd party certificate configured the right way...
>
> You are welcome to review other changes we did and decide for yourself.
> See also:
>
> https://www.ovirt.org/develop/release-management/features/infra/pki-renew/
> https://www.ovirt.org/documentation/how-to/migrate-pki-to-sha256/
>
>>>
>>> Cheers,
>>>
>>> Jiri
>>>
>>>
>>> On 05/07/2018 05:41 PM, Jiří Sléžka wrote:
>>> > Hi,
>>> >
>>> > after upgrade ovirt from 4.2.2 to 4.2.3.5-1.el7.centos I cannot login
>>> > into admin portal because
>>> >
>>> > sun.security.validator.ValidatorException: PKIX path building failed:
>>> > sun.security.provider.certpath.SunCertPathBuilderException: unable to
>>> > find valid certification path to requested target
>>> >
>>> > I am using custom 3rd party certificate
>>> >
>>> > Any hints how to resolve this issue?
>
> I am not sure this should have happened.
> If engine-setup replaced all relevant SSL*File options, it should have
> worked, and at most you should have received a pop-up in your browser.
> Please also check/share engine-setup log from /var/log/ovirt-engine/setup
> and the actual changes to ssl.conf.
>
> Thanks!
>
> Best regards,
>
>>> >
>>> > Thanks in advance,
>>> >
>>> > Jiri Slezka
>>> >
>>> >
>>> >
>>> >
>>> > ___
>>> > Users mailing list
>>> > Users@ovirt.org
>>> > http://lists.ovirt.org/mailman/listinfo/users
>>> >
>>>
>>> ___
>>> Users mailing list -- users@ovirt.org
>>> To unsubscribe send an email to users-le...@ovirt.org
>
>
>
> --
> Didi



-- 
Didi
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] Re: Self Hosted Engine and iSCSI doubt

2018-05-09 Thread Gianluca Cecchi
On Wed, May 9, 2018 at 11:22 AM, Simone Tiraboschi 
wrote:

>
>
> On Wed, May 9, 2018 at 10:52 AM, Veiko Kukk  wrote:
>
>> 2018-05-09 11:37 GMT+03:00 Gianluca Cecchi :
>>>
>>> I have the hierarchy
>>> ../target/tpg/luns/[lun0,lun1,lun2]
>>>
>>> so it seems I have to create two different targets and put the hosted
>>> engine lun under target1/tpg1 and then the data domain luns under
>>> target2/tpg2
>>>
>>>
>> No. You are missing the logic here. Path /target meants that following is
>> a iSCSI target. Each LUN is different target.
>> You can see more here https://www.thomas-krenn.
>> com/en/wiki/ISCSI_Basics#iSCSI_Target
>>
>>
> Not really: a target can expose multiple LUNs and you can expose the same
> LUN over different targets.
>
>
>>
>>
Indeed. In my opinion the link provided confirms that probably the generic
term "do not use the same iSCSI target" could be improved/clarified.
I can open a documentation bug and see what Red Hat Documentation team
thinks about it, but first I would like to understand the use case, eg
describing a scenario where problems could arise using a particular
configuration.

Gianluca
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] Re: Self Hosted Engine and iSCSI doubt

2018-05-09 Thread Simone Tiraboschi
On Wed, May 9, 2018 at 10:37 AM, Gianluca Cecchi 
wrote:

> On Wed, May 9, 2018 at 10:23 AM, Veiko Kukk  wrote:
>
>> 2018-05-09 11:07 GMT+03:00 Gianluca Cecchi :
>>>
>>> "
>>> IMPORTANT
>>> If you are using iSCSI storage, do not use the same iSCSI target for the
>>> shared
>>> storage domain and data storage domain.
>>> "
>>>
>>> Does it simply remark that the LUN for the hosted engine storage (shared
>>> storage domain) should be different from the LUN(s) used then for normal
>>> VMs (data storage domain), or what?
>>>
>>> I think it doesn't refer to the portal that for some reason needs to be
>>> different, correct?
>>>
>>> Any clarification about this restrictions?
>>>
>>>
>>>
>> I do not know. But I would guess it might be to avoid errors during
>> mounting/unmounting those two logically separate storage domains if they
>> are on the same physical resource.
>>
>> Veiko
>>
>>
> Actually I don't understand the meaning of the limitation itself... what
> target stands for in this context?
>

That limitation was due to this one:
https://bugzilla.redhat.com/show_bug.cgi?id=1351213
The root issue is clearly explained here:
https://bugzilla.redhat.com/show_bug.cgi?id=1351213#c4

The issue was mainly related to the auto import process and now in node-0
deployment flow we are not relying on that anymore (the hosted-engine
storage domain is directly created by the engine running on the bootstrap
local VM and so it's known by the engine by design) so probably we can just
ignore that limitation but honestly I'm not 100% you will not encounter
other minor gaps so I'd suggest to still keep two distinct storage domains
over two distinct iSCSI targets for production systems.

We are still working to handle the HE storage domain exactly as a regular
storage domain but we still have some gaps so it's targeted to 4.3:
https://bugzilla.redhat.com/show_bug.cgi?id=1451653



> Eg if I configure an iSCSI server using RHEL/CentOS 7.x OS and using
> targetcli and follow this:
> https://access.redhat.com/documentation/en-us/red_hat_
> enterprise_linux/7/html/storage_administration_guide/
> online-storage-management#osm-target-setup
>
> I have the hierarchy
> ../target/tpg/luns/[lun0,lun1,lun2]
>
> so it seems I have to create two different targets and put the hosted
> engine lun under target1/tpg1 and then the data domain luns under
> target2/tpg2
>

You can use a single target portal group (by the way now hosted-engine is
able to connect all the portals in the same portal group) but I'd recommend
to expose two distinct targets so, as an example  with targetcli:

/> iscsi/ create iqn.2018-05.com.example:target1
/> iscsi/ create iqn.2018-05.com.example:target2


> Normally if I connect to Enterrise Storage Arrays that offers iSCSI as a
> connection type (eg EQL or 3PAR) I simply put the portal ip and then I see
> the mapped LUNs granted to me, so in this case how can I differentiate
> "target", to be in the "safe/recommended" condition?
>
> Gianluca
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] Re: Self Hosted Engine and iSCSI doubt

2018-05-09 Thread Simone Tiraboschi
On Wed, May 9, 2018 at 10:52 AM, Veiko Kukk  wrote:

> 2018-05-09 11:37 GMT+03:00 Gianluca Cecchi :
>>
>> I have the hierarchy
>> ../target/tpg/luns/[lun0,lun1,lun2]
>>
>> so it seems I have to create two different targets and put the hosted
>> engine lun under target1/tpg1 and then the data domain luns under
>> target2/tpg2
>>
>>
> No. You are missing the logic here. Path /target meants that following is
> a iSCSI target. Each LUN is different target.
> You can see more here https://www.thomas-krenn.com/en/wiki/ISCSI_Basics#
> iSCSI_Target
>
>
Not really: a target can expose multiple LUNs and you can expose the same
LUN over different targets.


> Veiko
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] Work-Around for Access Problem to resources.ovirt.org and jenkins.ovirt.org

2018-05-09 Thread Anton Marchukov
Hello All.

Please note that ovirt.org got HSTS setting enabled. The way this
change was rolled was not authorised by us. The setting contains
“includeSubDomains” parameter that ask browser to access all resources
inside *.ovirt.org using https://.

The problem is that not all resources on *.ovirt.org are
https-enabled. And this will prevent you from being able to access

http://resources.ovirt.org
http://jenkins.ovirt.org

This setting is cached in your browser and then applied with no
exceptions even if you explicitly specify http:// the browser will
rewrite to https and then connection to above mentioned resources will
fail.

The only immediate work-around for you is to clear the HSTS flag in
your browser, please find the instructions for Firefox and Chrome [1].
Please note that you will get that setting back by visiting ovirt.org
website until we clear it from there.

We are currently working on this setting to be soften or disabled till
all resources are https enabled that is also in progress.

This is only related to access via the web browser. Accessing using
yum or automated scripts should work fine as they usually do not
observe and cache HSTS.

Anton.

[1] https://www.thesslstore.com/blog/clear-hsts-settings-chrome-firefox/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] Re: Self Hosted Engine and iSCSI doubt

2018-05-09 Thread Veiko Kukk
2018-05-09 11:37 GMT+03:00 Gianluca Cecchi :
>
> I have the hierarchy
> ../target/tpg/luns/[lun0,lun1,lun2]
>
> so it seems I have to create two different targets and put the hosted
> engine lun under target1/tpg1 and then the data domain luns under
> target2/tpg2
>
>
No. You are missing the logic here. Path /target meants that following is a
iSCSI target. Each LUN is different target.
You can see more here
https://www.thomas-krenn.com/en/wiki/ISCSI_Basics#iSCSI_Target

Veiko
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] Re: Self Hosted Engine and iSCSI doubt

2018-05-09 Thread Gianluca Cecchi
On Wed, May 9, 2018 at 10:23 AM, Veiko Kukk  wrote:

> 2018-05-09 11:07 GMT+03:00 Gianluca Cecchi :
>>
>> "
>> IMPORTANT
>> If you are using iSCSI storage, do not use the same iSCSI target for the
>> shared
>> storage domain and data storage domain.
>> "
>>
>> Does it simply remark that the LUN for the hosted engine storage (shared
>> storage domain) should be different from the LUN(s) used then for normal
>> VMs (data storage domain), or what?
>>
>> I think it doesn't refer to the portal that for some reason needs to be
>> different, correct?
>>
>> Any clarification about this restrictions?
>>
>>
>>
> I do not know. But I would guess it might be to avoid errors during
> mounting/unmounting those two logically separate storage domains if they
> are on the same physical resource.
>
> Veiko
>
>
Actually I don't understand the meaning of the limitation itself... what
target stands for in this context?
Eg if I configure an iSCSI server using RHEL/CentOS 7.x OS and using
targetcli and follow this:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/online-storage-management#osm-target-setup

I have the hierarchy
../target/tpg/luns/[lun0,lun1,lun2]

so it seems I have to create two different targets and put the hosted
engine lun under target1/tpg1 and then the data domain luns under
target2/tpg2

Normally if I connect to Enterrise Storage Arrays that offers iSCSI as a
connection type (eg EQL or 3PAR) I simply put the portal ip and then I see
the mapped LUNs granted to me, so in this case how can I differentiate
"target", to be in the "safe/recommended" condition?

Gianluca
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] Re: Self Hosted Engine and iSCSI doubt

2018-05-09 Thread Veiko Kukk
2018-05-09 11:07 GMT+03:00 Gianluca Cecchi :
>
> "
> IMPORTANT
> If you are using iSCSI storage, do not use the same iSCSI target for the
> shared
> storage domain and data storage domain.
> "
>
> Does it simply remark that the LUN for the hosted engine storage (shared
> storage domain) should be different from the LUN(s) used then for normal
> VMs (data storage domain), or what?
>
> I think it doesn't refer to the portal that for some reason needs to be
> different, correct?
>
> Any clarification about this restrictions?
>
>
>
I do not know. But I would guess it might be to avoid errors during
mounting/unmounting those two logically separate storage domains if they
are on the same physical resource.

Veiko
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] Self Hosted Engine and iSCSI doubt

2018-05-09 Thread Gianluca Cecchi
Hello,
a doubt for 4.1 related to LUNs / storage domains to dedicate to hosted
engine storage and normal data domain storage.

In oVirt docs here:
https://ovirt.org/documentation/self-hosted/chap-Deploying_Self-Hosted_Engine/

doesn't say anything special to differentiate iSCSI based and FC-SAN based
storage for hosted engine.

Inside the docs of Self-Hosted Engine Guide for RHV (bot 4.1 final and
4.2beta ones) there is this general statement:

"
You must have prepared storage for your self-hosted engine environment. At
least two storage domains are required:
- A shared storage domain dedicated to the Manager virtual machine. This
domain is created
during the self-hosted engine deployment, and must be at least 60 GB.
- A data storage domain for regular virtual machine data. This domain must
be added to the
self-hosted engine environment after the deployment is complete.
"

So far so good. But a bit below there is a particular note for iSCSI that I
don't understand quite well

"
IMPORTANT
If you are using iSCSI storage, do not use the same iSCSI target for the
shared
storage domain and data storage domain.
"

Does it simply remark that the LUN for the hosted engine storage (shared
storage domain) should be different from the LUN(s) used then for normal
VMs (data storage domain), or what?

I think it doesn't refer to the portal that for some reason needs to be
different, correct?

Any clarification about this restrictions?

Thanks,
Gianluca
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] gluster dispersed volume provisioning

2018-05-09 Thread josip
Hi, have a quick question regarding ovirt UI and provisioning of gluster 
volumes.
I've found an old thread - 
https://lists.ovirt.org/pipermail/users/2015-February/064602.html - where it's 
said that creating dispersed volumes is not supported but that it will be in 
the next release.
Is there any update on when will it be supported?

Thanks
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] Fwd: [JIRA] (OVIRT-2005) jira.ovirt.org redirect doesn't work anymore, redirects instead to https://jira.ovirt.org/ovirt.apps/

2018-05-09 Thread Eyal Edri
FYI,

It seems jira.ovirt.org redirect doesn't work, since we don't own the jira
instance ( cloud provided by Attlasian ) it might be a change done on their
side.
We'll investigate and check possible solutions.

Until then, please use the full URL for the JIRA instance -
https://ovirt-jira.atlassian.net


-- Forwarded message --
From: eyal edri (oVirt JIRA) 
Date: Wed, May 9, 2018 at 10:11 AM
Subject: [JIRA] (OVIRT-2005) jira.ovirt.org redirect doesn't work anymore,
redirects instead to https://jira.ovirt.org/ovirt.apps/
To: in...@ovirt.org


[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-2005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

eyal edri updated OVIRT-2005:

Epic Link: OVIRT-403

jira.ovirt.org redirect doesn't work anymore, redirects instead to
https://jira.ovirt.org/ovirt.apps/

 Key: OVIRT-2005
 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2005
 Project: oVirt - virtualization made easy
 Issue Type: Bug
Reporter: eyal edri
Assignee: infra
Priority: High

[~ederevea] any idea what could cause this? maybe Atlassian blocked us or
IP was changed? cc [~e...@redhat.com] [~bkor...@redhat.com]

— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100083)

___
Infra mailing list -- in...@ovirt.org
To unsubscribe send an email to infra-le...@ovirt.org




-- 

Eyal edri


MANAGER

RHV DevOps

EMEA VIRTUALIZATION R


Red Hat EMEA 
 TRIED. TESTED. TRUSTED. 
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] Re: How to add hosted-engine deployment in oVIrt 4.2.3 after host has already been added to cluster ?

2018-05-09 Thread Yedidyah Bar David
On Tue, May 8, 2018 at 7:35 PM, Balg, Andreas  wrote:
>
> Hello everybody,
>
> how am I supposed to add an additional hosted-engine deployment to a
> cluster to a host that has already been added - "hosted-engine --
> deploy" in the hosts terminal tells me to do it using the webUI ( oVirt
> 4.2.3 ) but in WebUI I haven't found a way to do so - also in Cockpit
> it offers me to "Redeploy" the Hosted-engine setup is that the way to
> go? It would really hurt if this would break the whole stuff.
>
> Usually I'd just try that before bothering you guys here - but this
> deployment is currently in use so this would really hurt.

I am not sure I understand what you mean/want. I assume this:

1. You deployed hosted-engine on host1.
2. You added host2 as a normal host.
3. Now you want host2 to also be in the hosted-engine cluster.

If so, you should:
1. Move host2 to maintenance
2. Reinstall host2 from the ui, marking 'hosted-engine' there.

If I got it wrong, please clarify.

Best regards,

>
>
> Thanks in advance for any help
>
> Cheers
> Andreas
>
> --
> Andreas Balg
> Senior Site Reliability Engineer DevOps
> --
> Haufe-umantis AG
> Ein Unternehmen der Haufe Gruppe
> Unterstrasse 11, CH-9001 St.Gallen
> Tel. +41 71 224 01 52, Fax +41 71 224 01 02
> E-Mail: andreas.b...@haufe.com
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org



-- 
Didi
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] Re: sun.security.validator.ValidatorException after update to 4.2.3

2018-05-09 Thread Yedidyah Bar David
On Tue, May 8, 2018 at 7:11 PM, Sandro Bonazzola  wrote:
> Adding Didi
>
> Il mar 8 mag 2018, 10:32 Jiří Sléžka  ha scritto:
>>
>> Hi,
>>
>> solution was obvious. Upgrade process modified apache's ssl.conf and
>> reverted my customization.
>>
>> for example - my custom cert...
>>
>> SSLCertificateFile /etc/pki/tls/certs/ovirt.crt.pem
>>
>> ...was replaced by this
>>
>> SSLCertificateFile /etc/pki/ovirt-engine/certs/apache.cer
>>
>> the same for SSLCertificateKeyFile and SSLCACertificateFile

Actually that was intended, see [1]. But I admit I didn't specifically
think about 3rd-party CAs, sorry.

You were notified about this by engine-setup, right?

"Apache httpd SSL was already configured in the past,
but some needed changes are missing there.
Configure again? (Automatic, Manual) [Automatic]:"

Please open a bug about this. Not sure exactly what the bug
should say - perhaps that on upgrade, engine-setup should only
touch specific values there, which do not include SSL*File,
perhaps show to the user what we are actually going to change,
perhaps default to 'No' - not sure about this - and change to
'Yes, No'.

[1] https://bugzilla.redhat.com/1558500

>>
>> After reverting this changes everything works as usual but it makes me
>> unsure if I have my 3rd party certificate configured the right way...

You are welcome to review other changes we did and decide for yourself.
See also:

https://www.ovirt.org/develop/release-management/features/infra/pki-renew/
https://www.ovirt.org/documentation/how-to/migrate-pki-to-sha256/

>>
>> Cheers,
>>
>> Jiri
>>
>>
>> On 05/07/2018 05:41 PM, Jiří Sléžka wrote:
>> > Hi,
>> >
>> > after upgrade ovirt from 4.2.2 to 4.2.3.5-1.el7.centos I cannot login
>> > into admin portal because
>> >
>> > sun.security.validator.ValidatorException: PKIX path building failed:
>> > sun.security.provider.certpath.SunCertPathBuilderException: unable to
>> > find valid certification path to requested target
>> >
>> > I am using custom 3rd party certificate
>> >
>> > Any hints how to resolve this issue?

I am not sure this should have happened.
If engine-setup replaced all relevant SSL*File options, it should have
worked, and at most you should have received a pop-up in your browser.
Please also check/share engine-setup log from /var/log/ovirt-engine/setup
and the actual changes to ssl.conf.

Thanks!

Best regards,

>> >
>> > Thanks in advance,
>> >
>> > Jiri Slezka
>> >
>> >
>> >
>> >
>> > ___
>> > Users mailing list
>> > Users@ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/users
>> >
>>
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org



-- 
Didi
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] How to update "quota_cluster_limit" settings of a quota object through REST API?

2018-05-09 Thread Shao-Da Huang
 Hi,

I can update the vCPU and memory quota by editing a Quota object of a
datacenter through webadmin portal, but it seems that I cannot update
through REST API...

For example, I have a quota object with a global quota_cluster_limit object:

GET https://192.168.80.168/ovirt-engine/api/datacenters/
5ad4fafe-0253-0015-0215-0378/quotas/8a6b3336-
2dfc-4e40-a58e-9bdcb45d228a/quotaclusterlimits/


  16.0
0.0 6
0 
 

But when I try to do

PUT
https://192.168.80.168/ovirt-engine/api/datacenters/5ad4fafe-0253-0015-0215-
0378/quotas/8a6b3336-2dfc-4e40-a58e-9bdcb45d228a/
quotaclusterlimits/8a6b3336-2dfc-4e40-a58e-9bdcb45d228a

with request body like:

8


I got *405 Method Not Allowed.*
Could anyone give me some advices?
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] Re: oVirt Orb 4.2.3 is now available

2018-05-09 Thread Sandro Bonazzola
2018-05-08 21:04 GMT+02:00 Gianluca Cecchi :

> On Tue, May 8, 2018 at 6:10 PM, Sandro Bonazzola 
> wrote:
>
>>
>>
>> 2018-05-08 11:45 GMT+02:00 Sandro Bonazzola :
>>
>>> oVirt Orb image has been updated with oVirt 4.2.3 content[1]
>>> oVirt Orb is a project that allows anyone to easily take an oVirt for a
>>> ride, test and play with it.
>>>
>>> See oVirt Orb documentation for using it[2]
>>>
>>> [1] http://resources.ovirt.org/pub/ovirt-4.2/ovirt-orb/
>>> [2] https://ovirt.org/documentation/ovirt-orb/
>>>
>>
>> Please use http instead of https when trying to access
>> http://resources.ovirt.org/pub/ovirt-4.2/ovirt-orb/
>> https is knwon to be not working, a ticket has been already opened for
>> tracking the issue.
>>
>>
> it seems there is in place an automatic redirect to https, so the http
> link doesn't work at the moment, at least for me.
>

It happened to me as well with google chrome.
Not sure what happened, but a workaround that helped me is:
- open chrome://net-internals/#hsts
- go to "Delete domain security policies" section
- enter "ovirt.org" and hit "Delete"




>
>
> Gianluca
>



-- 

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R

Red Hat EMEA 

sbona...@redhat.com


___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] Re: oVirt Orb 4.2.3 is now available

2018-05-09 Thread Sandro Bonazzola
2018-05-08 12:59 GMT+02:00 Staniforth, Paul :

> Hello Sandro,
>
>On the last version when trying to run it on Fedora
> instead of Centos it fails because it only installs version3 of the Python
> SDK. The workaround is to download the version4 SDK rpm and install that.
>
>
> Yes, looking at
https://ovirt.org/documentation/ovirt-orb/#installing-ovirt-python-sdk it
points you to https://pypi.org/project/ovirt-engine-sdk-python/4.2.4/




> Thanks,
>
>  Paul S.
>
>
> --
> *From:* Sandro Bonazzola 
> *Sent:* 08 May 2018 10:45
> *To:* users; devel
> *Subject:* [ovirt-users] oVirt Orb 4.2.3 is now available
>
> oVirt Orb image has been updated with oVirt 4.2.3 content[1]
> oVirt Orb is a project that allows anyone to easily take an oVirt for a
> ride, test and play with it.
>
> See oVirt Orb documentation for using it[2]
>
> [1] http://resources.ovirt.org/pub/ovirt-4.2/ovirt-orb/
> [2] https://ovirt.org/documentation/ovirt-orb/
>
> --
>
> SANDRO BONAZZOLA
>
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R
>
> Red Hat EMEA 
>
> sbona...@redhat.com
> 
> 
> To view the terms under which this email is distributed, please go to:-
> http://disclaimer.leedsbeckett.ac.uk/disclaimer/disclaimer.html
>
>


-- 

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R

Red Hat EMEA 

sbona...@redhat.com


___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org


[ovirt-users] Re: Host install failed - cannot set maintenance or remove

2018-05-09 Thread Alona Kaplan
Hi Callum,

For some reason, when installing the host the management network wasn't
attached to the host.
Since the management network is required, due to
https://bugzilla.redhat.com/1570388
 the host stuck in non
operational <-> activating states.

You have two options -

1. Updating ovirt to ovirt-engine-4.2.3.4 and re-installing the host.

2. Trying to understand why the management network wasn't attached to the
host at the first place.

If you choose option 2 please attach the full engine logs (engine.log,
server.log) and vdsm logs (vdsm.log, supervdsm.log).

Thanks,
Alona.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org