date:20190207

Hi Strahil,

Do you have any experiences similar to mine?
On Feb 7 2019, at 9:05 pm, Strahil  wrote:
> Hey Femi,
>
>
> Just run away ... For me it seems, that they don't have that software ready 
> for ovirt.
>
> Best Regards,
> Strahil Nikolov
>
>

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/OTH6LXISADJAKGTBGJZS3E3UG42GZ6SC/

[ovirt-users] Re: Agentless Backup update: Trilio Vault, pay $7500

2019-02-07 Thread Strahil

Hey Femi,Just run away ... For me it seems, that they don't have that software ready for ovirt.Best Regards,Strahil Nikolov___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/UZZCFDJYQLPYGYTCVC5V2HUNADOULWSX/

[ovirt-users] Re: possibly corrupted disk during 4.3 upgrade

2019-02-07 Thread Strahil

Hey Jason,
The *main* thing I'm concerned about, though, is that the disk for one

of my large VMs appears to have been truncated -- it's virtual size is

300GB, I think the actual size was probably just under half of that,

but it's actual size is now reported to be less than a gig, and it's

taking up only 300MB of space. I'm afraid the answer is no, but I'm

hoping that the data might be recoverable from somewhere on the

bricks...

glusterfs is using features.shard with 4MB shards, so it is natural to see a VM disk as 300GB virtual size with a very small actual size, as the rest of the data is in the shards.The best way to check the VM is to power it off and power it on.I am wondering how you managed to upgrade as vdsm-gluster and glusterfs-gnfs (depend each other) have a dependency issues in 4.3 repo ?!?Best Regards,Strahil Nikolov___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/3GPGGAWAVJSJANFEUNGLG355WOLBTVLL/

[ovirt-users] Re: oVirt Cloud Init CentOS not setting password

2019-02-07 Thread Strahil

Hey Vincent , Robert,I have tries cloud-init and it works as expected.Of course, you need to install and enable the cloud-init service in your template.How exactly are you trying to use cloud-init ?Best Regards,Strahil Nikolov___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/J72QW5GBLOOALVE4J77R6NFXOUV4B2F6/

[ovirt-users] Re: Forcing vdsm to configure another NIC as the bridge (oVirt 4.2.8)

2019-02-07 Thread zachary . winter

Also seeing this:

Feb 07 21:51:18 ovirthost systemd[1]: Dependency failed for Virtual Desktop 
Server Manager.
Feb 07 21:51:18 ovirthost systemd[1]: Job vdsmd.service/start failed with 
result 'dependency'.
Feb 07 22:18:30 ovirthost systemd[1]: Dependency failed for Virtual Desktop 
Server Manager.
Feb 07 22:18:30 ovirthost systemd[1]: Job vdsmd.service/start failed with 
result 'dependency'.
Feb 07 22:18:54 ovirthost systemd[1]: Dependency failed for Virtual Desktop 
Server Manager.
Feb 07 22:18:54 ovirthost systemd[1]: Job vdsmd.service/start failed with 
result 'dependency'.
Feb 07 22:21:09 ovirthost systemd[1]: Dependency failed for Virtual Desktop 
Server Manager.
Feb 07 22:21:09 ovirthost systemd[1]: Job vdsmd.service/start failed with 
result 'dependency'.


Replacing "nic" with the adapter I want allows the network to come up with the 
IP I want, but the vdsmd.service still fails to start.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/O2ZI7VPJR73OVNROTMBWV6PU5MT72Y2Q/

[ovirt-users] Re: oVirt Cloud Init CentOS not setting password

2019-02-07 Thread Vincent Royer

I have this same issue with one of my cloud-init centos vms.  I log in
using ssh keys, the root password was never set and there seems to be no
way for me to set it.





On Thu, Feb 7, 2019 at 10:32 AM Robert Crawford <
robert.crawford4.14...@gmail.com> wrote:

> Okay, I'm confused does it take time for cloud init to apply?
> Because leaving the VM booted for a few minutes it will eventually work
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/R3EGRWPPAFQ6EZPOPNUBK3YCJEBIXMZE/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZZGB4T4COCINUSZQEL2L54NXERPA4EFC/

[ovirt-users] Re: need network design advice for iSCSI

2019-02-07 Thread Vinícius Ferrão

Hello, another guy with what appears to be the same problem...

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

PS: Uwe I’m ccing you.

Sent from my iPhone

> On 29 Jan 2019, at 13:57, John Florian  wrote:
> 
> Okay, both the BZ and ML posts are interesting and helpful.  I'm kind of 
> surprised there seems to be so much trouble and confusion for what I would 
> have thought to be a very common setup.  Are most people using something else?
> 
> I think this gives me what I need for my next stab at doing this but I"m 
> still puzzled on how to tear down what I have in oVirt so that I can redo it. 
>  Specifically, I didn't see how to delete the existing iSCSI connections.  
> I've read that this can only be done through the REST API.  I have managed to 
> redo the interfaces on my Hosts so that everything is now on just 2 NICs 
> each, leaving 2 NICs free for a foothold on a new setup.  From all of my 
> experimentation, it would appear that my only option is to create a new 
> storage domain and export/import each disk volume one by one.  Maybe there's 
> a migration option I have yet to see, but I don't see any way around creating 
> a new storage domain here.
> 
>> On 1/21/19 7:12 AM, Vinícius Ferrão wrote:
>> Hello people, in the past Maor Lipchuk (from RH) tried very hard to help me 
>> and Uwe but we was unable to converge on the solution.
>> 
>> This was discussed a year ago and on my understanding it still and oVirt 
>> bug. As today, if you simple “DuckDuckGo” for “ovirt iscsi multipath not 
>> working” the third link points to this bugzilla: 
>> https://bugzilla.redhat.com/show_bug.cgi?id=1474904
>> 
>> Which is the one I’ve mentioned and it’s extremely similar to John Florian 
>> case, which was my case too.
>> 
>> @John, take a look at the bugzilla link and see if the desired topology 
>> match with your case.
>> 
>> Regards,
>> 
>> 
>>> On 21 Jan 2019, at 05:21, Eitan Raviv  wrote:
>>> 
>>> Shani,
>>> Can you help here with  iSCSI bonding?
>>> Thanks
>>> 
 On Mon, Jan 21, 2019 at 7:51 AM Uwe Laverenz  wrote:
 
 Hi John,
 
 Am 20.01.19 um 18:32 schrieb John Florian:
 
> As for how to get there, whatever exactly that might look like, I'm also
> having troubles figuring that out.  I figured I would transform the
> setup described below into one where each host has:
> 
>  * 2 NICs bonded with LACP for my ovirtmgmt and "main" net
>  * 1 NIC for my 1st storage net
>  * 1 NIC for my 2nd storage net
 
 This is exactly the setup I use. I have run this successfully with
 CentOS/LIO and FreeNAS iSCSI targets with good performance.
 
 In short:
 
 - 2 separate, isolated networks for iSCSI with dedicated adapters
   on hosts and iSCSI target
 - jumbo frames enabled
 - no VLANs config needed on hosts, untagged VLANs on switch
 - do _not_ use LACP, let multipathd handle failovers
 
 Same experience as Vinicius: what did _not_ work for me is the
 iSCSI-Bonding in OVirt. It seems to require that all storage IPs are
 reachable from all other IPs, which is not the case in every setup.
 
 To get multipathing to work I use multipath directly:
 
> https://www.mail-archive.com/users@ovirt.org/msg42735.html
 
 I will post a bonnie++ result later. If you need more details please let
 me know.
 
 cu,
 Uwe
 ___
 Users mailing list -- users@ovirt.org
 To unsubscribe send an email to users-le...@ovirt.org
 Privacy Statement: https://www.ovirt.org/site/privacy-policy/
 oVirt Code of Conduct: 
 https://www.ovirt.org/community/about/community-guidelines/
 List Archives: 
 https://lists.ovirt.org/archives/list/users@ovirt.org/message/E2QKV7CZR27NT6MRSNL352KLOQ5OAGDR/
>> 
>> 
>> 
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct: 
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives: 
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/NSE5BCLJSIFDX2VDZRBRLODEH3ZCPYWN/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/BMKNLMONCF44ADXTWE3JM4P6XQBWZHNC/

[ovirt-users] Forcing vdsm to configure another NIC as the bridge (oVirt 4.2.8)

2019-02-07 Thread zachary . winter

I installed a new 10GbE NIC after installing the oVirt engine, and upon reboot 
vdsm began auto-configuring one of the ports on the new NIC rather than the 
original 1GbE interface.  The new NIC is not currently connected to anything, 
so I am wondering how to force vdsm to use the 1GbE NIC until I install and 
connect the server to a 10GbE switch.  This is causing the data center and host 
in the Administration Portal to show as "non-operational," though I can still 
log in.

I have been poring over any files I can find on the server relating to 
"ovirtmgmt" or "vdsm," and I am wondering if I simply change the "nic" 
parameter to the name of the 1GbE interface in the following file that 
reloading vdsmd or rebooting will cause it to behave the way I want:

/var/lib/vdsm/persistence/netconf/nets/ovirtmgmt

Any insight on this?  Are there other locations that need to be edited to force 
vdsm to use, say, "eth0" rather than "eth3"?  Are there files that I need to 
delete so vdsm will automatically re-create them?  

Any help is appreciated - thanks!
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/OFYRUQYT7VB34ZPWFBCUISJKIXZ6IMH4/

[ovirt-users] Retrieval of iSCSI targets failed.

2019-02-07 Thread cbop . mail

Hello!

I was just trying to setup my first oVirt Server via Cockpit but it failed when 
I wanted to connect it to my iSCSI.

These are the last lines of my vdsm.log:
2019-02-08 01:34:07,080+0100 INFO  (jsonrpc/3) [jsonrpc.JsonRpcServer] RPC call 
Host.getAllVmStats succeeded in 0.00 seconds (__init__:312) 

 
2019-02-08 01:34:07,096+0100 INFO  (jsonrpc/5) [api.host] START 
getAllVmIoTunePolicies() from=::1,36420 (api:48)

 
2019-02-08 01:34:07,096+0100 INFO  (jsonrpc/5) [api.host] FINISH 
getAllVmIoTunePolicies return={'status': {'message': 'Done', 'code': 0}, 
'io_tune_policies_dict': {'be244416-dc4b-4bee-b451-37c0517f19f7': {'policy': 
[], 'current_values': []}}} from=:
:1,36420 (api:54)   


 
2019-02-08 01:34:07,097+0100 INFO  (jsonrpc/5) [jsonrpc.JsonRpcServer] RPC call 
Host.getAllVmIoTunePolicies succeeded in 0.00 seconds (__init__:312)

 
2019-02-08 01:34:08,149+0100 INFO  (jsonrpc/7) [vdsm.api] START 
discoverSendTargets(con={'ipv6_enabled': u'false', 'connection': 
u'20.20.20.20', 'password': '', 'port': u'3260', 'user': ''}, options=None) 
from=:::192.168.122.144,35682, flow_id=6
a17a7b3-1dfa-424c-8978-652d73314daf, 
task_id=f8be43e7-9085-42bd-b526-c2adb9962cb4 (api:48)   


2019-02-08 01:34:08,330+0100 INFO  (jsonrpc/7) [vdsm.api] FINISH 
discoverSendTargets return={'fullTargets': ['20.20.20.20:3260,1 
iqn.2019-02.eu.teamxenon:data', '20.20.20.20:3260,1 
iqn.2019-02.eu.teamxenon:ovirt'], 'targets': ['iqn.2019-02.eu.teamxe
non:data', 'iqn.2019-02.eu.teamxenon:ovirt']} 
from=:::192.168.122.144,35682, 
flow_id=6a17a7b3-1dfa-424c-8978-652d73314daf, 
task_id=f8be43e7-9085-42bd-b526-c2adb9962cb4 (api:54)   
  
2019-02-08 01:34:08,331+0100 INFO  (jsonrpc/7) [jsonrpc.JsonRpcServer] RPC call 
ISCSIConnection.discoverSendTargets succeeded in 0.18 seconds (__init__:312)

 
2019-02-08 01:34:10,739+0100 INFO  (vmrecovery) [vdsm.api] START 
getConnectedStoragePoolsList(options=None) from=internal, 
task_id=0507616a-5b31-4d88-897f-0d2411674ce3 (api:48)   
  
2019-02-08 01:34:10,739+0100 INFO  (vmrecovery) [vdsm.api] FINISH 
getConnectedStoragePoolsList return={'poollist': []} from=internal, 
task_id=0507616a-5b31-4d88-897f-0d2411674ce3 (api:54)   
   
2019-02-08 01:34:10,740+0100 INFO  (vmrecovery) [vds] recovery: waiting for 
storage pool to go up (clientIF:709) 

As you can see it finds the targets but for some reason it fails. The initiator 
name should be configured correctly.
My iSCSI is configured as the following:
o- / 
.
 [...]  
   
  o- backstores 
..
 [...]  
   
  | o- block 
..
 [Storage Objects: 0]   
  
  | o- fileio 
.
 [Storage Objects: 4]   
  
  | | o- code . 
[/mnt/pool0/vdisks/code.img (200.0GiB) write-back activated]

 
  | | | o- alua 
...
 [ALUA Groups: 1]

[ovirt-users] possibly corrupted disk during 4.3 upgrade

2019-02-07 Thread Jason Brooks

I have a ovirt+gluster cluster that I've been running for a while now
-- across several versions of oVirt. I was upgrading to 4.3 today, and
am halfway through the upgrade. I've upgraded two of my four hosts to
4.3, as well as the engine, but the hosted-ha agents aren't running on
my new hosts.

Also, one of my two upgraded hosts won't connect to one of my domains
-- I'm not sure whether that's the master data domain or the hosted
engine domain.

The *main* thing I'm concerned about, though, is that the disk for one
of my large VMs appears to have been truncated -- it's virtual size is
300GB, I think the actual size was probably just under half of that,
but it's actual size is now reported to be less than a gig, and it's
taking up only 300MB of space. I'm afraid the answer is no, but I'm
hoping that the data might be recoverable from somewhere on the
bricks...

Any thoughts?

Jason
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/6XO2TGSMOCQHPWZPGO6XQJZHXYRQNMH6/

[ovirt-users] Network Performance Issues

2019-02-07 Thread Bryan Sockel

Hi,
 
I currently have a 4 node ovirt cluster running.  Each node is configured with 
an active passive network setup, with each link being 10 GB.  After looking 
over my performance metrics collected via observium.  I am noticing the network 
traffic rarely exceeds 100 MB.  I am noticing this across all four of my 
servers and my 2 storage arrays that are also connected via the same 10 GB 
links.
 
What is the best way to trouble shoot this problem? 
 
Thanks
 
 ___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/P4KJR6F4QPQRN3XFULCHV7ZDU77LJLEE/

[ovirt-users] Re: AMD EPYC 4.3 upgrade 'CPU type is not supported in this cluster compatibility version or is not supported at all'

On Thu, Feb 7, 2019 at 7:15 PM Juhani Rautiainen <
juhani.rautiai...@gmail.com> wrote:

>
>
> On Thu, Feb 7, 2019 at 6:52 PM Simone Tiraboschi 
> wrote:
>
>>
>>
>> For an hosted-engine cluster we have a manual workaround procedure
>> documented here:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1672859#c1
>>
>>
> I managed to upgrade my Epyc cluster with those steps. I made new cluster
> with Epyc CPU Type and cluster already in 4.3 level. Starting engine in new
> cluster complained something about not finding vm with that uuid but it
> still started engine fine. When all nodes were in new cluster I still
> couldn't upgrade old cluster because engine was complaining that couple of
> VM's couldn't be upgraded (something to do with custom level). I moved them
> to new cluster too. Had to just change networks to management for the move.
> After that I could upgrade old cluster to Epyc and 4.3 level. Then I just
> moved VM's and nodes back (same steps but backwards). After that you can
> remove the extra cluster and raise datacenter to 4.3 level.
>
> -Juhani
>

Thanks for the report!
We definitively have to  figure out a better upgrade flow when a cluster
CPU change is required/advised.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/VFPSYXCYXQCRYNQ7EQ32ONADEQHRIUYZ/

[ovirt-users] Re: ovirt-node-4.3, deployment fails when moving hosted engine vm to gluster storage.

2019-02-07 Thread feral

Update:

Removing all gluster mounts from /etc/fstab, solves the boot problem. I am
then able to manually mount all gluster bricks, bring up glusterd properly.
I'm trying to deploy the hosted VM again now, but I suspect that the
problem there as well, is going to be that it's trying to mount a gluster
brick before bringing up networking.

On Thu, Feb 7, 2019 at 8:37 AM feral  wrote:

> Which logs?
>
> The nodes hang on boot at "Started Flush Journal to Persistent Storage".
> This would be followed by gluster mounts coming up (before networking,
> which still doesn't make sense to me...) but they of course all fail as
> networking is down.
> The gluster logs, post node failure, simply state that all connection
> attempts are failing (because networking is down.
>
> I managed to get networking online manually and push logs OUT (cant' start
> sshd as that causes reboot).
> https://drive.google.com/open?id=1Kdb2pRUC0O-5u3ZkA3KT0qvAQIpv9SZm
>
> It seems to me that some vital systemd service must be failing on the
> nodes (and possibly that's what's happening on the VM as well?
>
> On Thu, Feb 7, 2019 at 8:25 AM Simone Tiraboschi 
> wrote:
>
>>
>>
>> On Thu, Feb 7, 2019 at 5:19 PM feral  wrote:
>>
>>> I've never managed to get a connection to the engine via VNC/Spice
>>> (works fine for my other hypervisors...)
>>>
>>> As I said, the network setup is super simple. All three nodes have 1
>>> interface each (eth0). They are all set with static IP's, with matching
>>> DHCP reservations on the DHCP server, with matching DNS. All nodes have
>>> entries in /etc/hosts on each machine. IP's are 192.168.1.195-7, and the
>>> engine VM gets 192.168.1.198. During the engine deployment, the VM does
>>> come up on 198. I can ping it and ssh into it, but at some point, the
>>> connection drops.
>>> So I'm not relying on DHCP or DNS at all. VM comes up where expected,
>>> for a while, then it goes to reboot to get transferred to the
>>> gluster_engine storage, and that's where it drops offline and never comes
>>> back.
>>>
>>> I did another round of deployment tests last night and discovered that
>>> the nodes all fail to boot immediately after the gluster deployment (not
>>> after VM deployment as I mistakenly stated earlier). So the nodes get in a
>>> bad state during gluster deployment. They stay online just fine and gluster
>>> works perfect, until the node tries to reboot (which it fails to do).
>>>
>>
>> So I suggest to focus on the gluster deployment; can you please share
>> gluster logs?
>>
>>
>>>
>>> Also, the networking I'm using is identical to my ovirt 4.2 setup. I'm
>>> using the same MAC addresses, IP's, and hostnames (4.2 cluster is offline
>>> when I'm trying 4.3). They are identical configurations other than the
>>> version of ovirt-node.
>>>
>>> On Thu, Feb 7, 2019 at 12:15 AM Simone Tiraboschi 
>>> wrote:
>>>


 On Wed, Feb 6, 2019 at 11:07 PM feral  wrote:

> I have no idea what's wrong at this point. Very vanilla install of 3
> nodes. Run the Hyperconverged wizard, completes fine. Run the engine
> deployment, takes hours, eventually fails with :
>
> [ INFO ] TASK [oVirt.hosted-engine-setup : Check engine VM health]
> [ ERROR ] fatal: [localhost]: FAILED! => {"attempts": 120, "changed":
> true, "cmd": ["hosted-engine", "--vm-status", "--json"], "delta":
> "0:00:00.340985", "end": "2019-02-06 11:44:48.836431", "rc": 0, "start":
> "2019-02-06 11:44:48.495446", "stderr": "", "stderr_lines": [], "stdout":
> "{\"1\": {\"conf_on_shared_storage\": true, \"live-data\": true, 
> \"extra\":
> \"metadata_parse_version=1\\nmetadata_feature_version=1\\ntimestamp=12994
> (Wed Feb 6 11:44:44
> 2019)\\nhost-id=1\\nscore=3400\\nvm_conf_refresh_time=12995 (Wed Feb 6
> 11:44:44
> 2019)\\nconf_on_shared_storage=True\\nmaintenance=False\\nstate=EngineStop\\nstopped=False\\n\",
> \"hostname\": \"ovirt-431.localdomain\", \"host-id\": 1, 
> \"engine-status\":
> {\"reason\": \"failed liveliness check\", \"health\": \"bad\", \"vm\":
> \"up\", \"detail\": \"Up\"}, \"score\": 3400, \"stopped\": false,
> \"maintenance\": false, \"crc32\": \"5474927a\", \"local_conf_timestamp\":
> 12995, \"host-ts\": 12994}, \"global_maintenance\": false}",
> "stdout_lines": ["{\"1\": {\"conf_on_shared_storage\": true, 
> \"live-data\":
> true, \"extra\":
> \"metadata_parse_version=1\\nmetadata_feature_version=1\\ntimestamp=12994
> (Wed Feb 6 11:44:44
> 2019)\\nhost-id=1\\nscore=3400\\nvm_conf_refresh_time=12995 (Wed Feb 6
> 11:44:44
> 2019)\\nconf_on_shared_storage=True\\nmaintenance=False\\nstate=EngineStop\\nstopped=False\\n\",
> \"hostname\": \"ovirt-431.localdomain\", \"host-id\": 1, 
> \"engine-status\":
> {\"reason\": \"failed liveliness check\", \"health\": \"bad\", \"vm\":
> \"up\", \"detail\": \"Up\"}, \"score\": 3400, \"stopped\": false,
> \"maintenance\": false, \"crc32\": \"5474927a\",

[ovirt-users] Re: oVirt Cloud Init CentOS not setting password

2019-02-07 Thread Robert Crawford

Okay, I'm confused does it take time for cloud init to apply? 
Because leaving the VM booted for a few minutes it will eventually work
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/R3EGRWPPAFQ6EZPOPNUBK3YCJEBIXMZE/

[ovirt-users] Re: AMD EPYC 4.3 upgrade 'CPU type is not supported in this cluster compatibility version or is not supported at all'

2019-02-07 Thread Juhani Rautiainen

On Thu, Feb 7, 2019 at 6:52 PM Simone Tiraboschi 
wrote:

>
>
> For an hosted-engine cluster we have a manual workaround procedure
> documented here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1672859#c1
>
>
I managed to upgrade my Epyc cluster with those steps. I made new cluster
with Epyc CPU Type and cluster already in 4.3 level. Starting engine in new
cluster complained something about not finding vm with that uuid but it
still started engine fine. When all nodes were in new cluster I still
couldn't upgrade old cluster because engine was complaining that couple of
VM's couldn't be upgraded (something to do with custom level). I moved them
to new cluster too. Had to just change networks to management for the move.
After that I could upgrade old cluster to Epyc and 4.3 level. Then I just
moved VM's and nodes back (same steps but backwards). After that you can
remove the extra cluster and raise datacenter to 4.3 level.

-Juhani
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/426ZMUHUUPO3Z3H43NVHKUPSPLZY4LI5/

[ovirt-users] Re: Is it possible to customize web-ui/User Portal/VM Portal?

2019-02-07 Thread Brian T

> Cool! We're actually in the process of overhauling consoles for VM Portal.
> We currently have Windows RDP in the Admin Portal, and we are actively
> working on it for VM Portal. Here are some screens from the design:
>
> We also have SPICE (thick client) fully implemented in both portals, thick
> client VNC in both portals, novnc (web-based) in Admin, and novnc coming
> very soon in VM Portal (4.3.2 at the latest, but I hope 4.3.1) as part of
> the overhaul.
> 
> Also, would you mind please reviewing the designs we have so far? I'm
> interested in others' opinions, especially someone who has already been
> thinking about this.

That's awesome to hear! We were wondering why novnc was an Admin only feature 
and why 'Console' in VM Portal felt sparse. Looking at these designs, this is 
kinda what I was going to go for anywho haha, with support for other RDP 
solutions.

> Is Mechdyne TGX much different than Windows RDP, SPICE, and VNC? If so,
> what is the use case for using that over Windows RDP / SPICE / VNC?

Mechdyne TGX is an TDP solution that offers significantly higher frame rates 
(60+ frames per second) and resolution (We can hit 4k resolution); to our 
understanding, Windows RDP and SPICE cannot hit those numbers. For the average 
workstation user, SPICE is sufficient! We have some users that are heavily 
invested in simulation and potentially VR, so a close recreation in terms of 
frame rate and resolution is needed and Mechdyne TGX supports this. You can 
read more about this here: https://tgxremotedesktop.com/tgx-features/

I guess this leads into my next question...

Is it possible to configure how console.rdp is created in VM Portal or achieve 
parity between how it's created in VM Portal and Admin Portal? When you open up 
the console.rdp file created in Admin portal, under where "full address:s:", 
the IPv4 address is listed. However, when you open the console.rdp file created 
in VM Portal, under where "full address:s", it takes the VM name instead of 
something like the IPv4 address or even the FQDN of the VM. Currently, someone 
wrote a bash script to grep out the "full address:s" value and use it alongside 
TGX, but this doesn't work on the VM Portal due to the value being set to the 
VM Name. The workaround is to register the VM name in our DNS so that it will 
resolve with an IPv4 address, but I feel that this is a poor solution.

My suggestion is for the console.rdp generated in VM Portal, instead of using 
the VM Name, use either the FQDN or the IPv4 address. I can see the 
counterargument that this will expose the FQDN/IP address to the user.


> And I would certainly love for you to help test it out as we're nearing
> completion, at the least. If you want to code, we would love to have you :)

I'd love to help! Problem is, I guess I'm trying to start from 0 and I'm not 
sure HOW to start developing for web-ui or even WebAdmin. How would you suggest 
setting up?

Let me know if you have any further questions and thank you for taking the time 
to respond!
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/FCZMWR4ODZJ7P6IMTHJ7NPPX7KGWDIMT/

[ovirt-users] Re: AMD EPYC 4.3 upgrade 'CPU type is not supported in this cluster compatibility version or is not supported at all'

On Thu, Feb 7, 2019 at 5:46 PM Greg Sheremeta  wrote:

>
> On Thu, Feb 7, 2019 at 11:31 AM Ryan Bullock  wrote:
>
>> That would explain it.
>>
>> Would removing the host and then reinstalling it under a new 4.3 cluster
>> work without having to set the entire old cluster into maintenance to
>> change the cpu? Then I could just restart VM's into the new cluster as we
>> transition to minimize downtime.
>>
>
> @Simone Tiraboschi  or @Ryan Barry
>  ?
>

For an hosted-engine cluster we have a manual workaround procedure
documented here:
https://bugzilla.redhat.com/show_bug.cgi?id=1672859#c1


>
>
>>
>> Thanks for the info!
>>
>
> Glad to help :)
>
> Greg
>
>
>>
>> Ryan
>>
>> On Thu, Feb 7, 2019 at 7:56 AM Greg Sheremeta 
>> wrote:
>>
>>> AMD EPYC IBPB is deprecated in 4.3.
>>> The deprecated CPUs (cpus variable, that entire list) are:
>>>
>>> https://gerrit.ovirt.org/#/c/95310/7/frontend/webadmin/modules/webadmin/src/main/java/org/ovirt/engine/ui/webadmin/widget/table/column/ClusterAdditionalStatusColumn.java
>>>
>>> So, *-IBRS [IBRS-SSBD is still ok], Epyc IBPB, Conroe, Penryn, and
>>> Opteron G1-3. If you have those, you need to change it to a supported type
>>> while it's in 4.2 still.
>>>
>>> Greg
>>>
>>> On Thu, Feb 7, 2019 at 1:11 AM Ryan Bullock  wrote:
>>>
 We just updated our engine to 4.3, but when I tried to update one of
 our AMD EPYC hosts it could not activate with the error:

 Host vmc2h2 moved to Non-Operational state as host CPU type is not
 supported in this cluster compatibility version or is not supported at all.

 Relevant (I think) parts from the the engine log:

 (EE-ManagedThreadFactory-engineScheduled-Thread-82) [ee51a70] Could not
 find server cpu for server 'vmc2h2' (745a14c6-9d31-48a4-9566-914647d83f53),
 flags:
 'fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,mmx,fxsr,sse,sse2,ht,syscall,nx,mmxext,fxsr_opt,pdpe1gb,rdtscp,lm,constant_tsc,art,rep_good,nopl,nonstop_tsc,extd_apicid,amd_dcm,aperfmperf,eagerfpu,pni,pclmulqdq,monitor,ssse3,fma,cx16,sse4_1,sse4_2,movbe,popcnt,aes,xsave,avx,f16c,rdrand,lahf_lm,cmp_legacy,svm,extapic,cr8_legacy,abm,sse4a,misalignsse,3dnowprefetch,osvw,skinit,wdt,tce,topoext,perfctr_core,perfctr_nb,bpext,perfctr_l2,cpb,hw_pstate,sme,retpoline_amd,ssbd,ibpb,vmmcall,fsgsbase,bmi1,avx2,smep,bmi2,rdseed,adx,smap,clflushopt,sha_ni,xsaveopt,xsavec,xgetbv1,clzero,irperf,xsaveerptr,arat,npt,lbrv,svm_lock,nrip_save,tsc_scale,vmcb_clean,flushbyasid,decodeassists,pausefilter,pfthreshold,avic,v_vmsave_vmload,vgif,overflow_recov,succor,smca'
 2019-02-06 17:23:58,527-08 INFO
 [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand]
 (EE-ManagedThreadFactory-engineScheduled-Thread-82) [7f6d4f0d] START,
 SetVdsStatusVDSCommand(HostName = vmc2h2,
 SetVdsStatusVDSCommandParameters:{hostId='745a14c6-9d31-48a4-9566-914647d83f53',
 status='NonOperational',
 nonOperationalReason='CPU_TYPE_INCOMPATIBLE_WITH_CLUSTER'


 From virsh -r capabilities:

 
   x86_64
   EPYC-IBPB
   AMD
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
 

 I also tried creating a new 4.3 cluster, set to the AMD EPYC IPBDB SSBD
 and moving the host into it, but it failed to move it into that cluster
 with a similar error about an unsupported CPU (for some reason it also made
 me clear the additional kernel options as well, we use 1gb hugepages). I
 have not yet tried removing the host entirely and adding it as part of
 creating the new cluster.

 We have been/are using a database change to update the 4.2 cluster
 level to include EPYC support with the following entries (can post the
 whole query if needed):
 7:AMD EPYC:svm,nx,model_EPYC:EPYC:x86_64; 8:AMD EPYC
 IBPB:svm,nx,ibpb,model_EPYC:EPYC-IBPB:x86_64

 We have been running 4.2 with this for awhile. We did apply the same
 changes after the 4.3 update, but only for the 4.2 cluster level. We only
 used the AMD EPYC IBPB model.

 Reverting the host back to 4.2 allows it to activate and run normally.

 Anyone have any ideas as to why it can't seem to find the cpu type?

 Thanks,

 Ryan Bullock
 ___
 Users mailing list -- users@ovirt.org
 To unsubscribe send an email to users-le...@ovirt.org
 Privacy Statement: https://www.ovirt.org/site/privacy-policy/
 oVirt Code of Conduct:
 https://www.ovirt.org/community/about/community-guidelines/
 List Archives:
 https://lists.ovirt.org/archives/list/users@ovirt.org/message/4Y4X7UGDEYSB5JK45TLDERNM7IMTHIYY/

>>>
>>>
>>> --
>>>
>>> GREG SHEREMETA
>>>
>>> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>>>
>>> Red Hat NA
>>>
>>>

[ovirt-users] Re: AMD EPYC 4.3 upgrade 'CPU type is not supported in this cluster compatibility version or is not supported at all'

On Thu, Feb 7, 2019 at 11:31 AM Ryan Bullock  wrote:

> That would explain it.
>
> Would removing the host and then reinstalling it under a new 4.3 cluster
> work without having to set the entire old cluster into maintenance to
> change the cpu? Then I could just restart VM's into the new cluster as we
> transition to minimize downtime.
>

@Simone Tiraboschi  or @Ryan Barry 
 ?


>
> Thanks for the info!
>

Glad to help :)

Greg


>
> Ryan
>
> On Thu, Feb 7, 2019 at 7:56 AM Greg Sheremeta  wrote:
>
>> AMD EPYC IBPB is deprecated in 4.3.
>> The deprecated CPUs (cpus variable, that entire list) are:
>>
>> https://gerrit.ovirt.org/#/c/95310/7/frontend/webadmin/modules/webadmin/src/main/java/org/ovirt/engine/ui/webadmin/widget/table/column/ClusterAdditionalStatusColumn.java
>>
>> So, *-IBRS [IBRS-SSBD is still ok], Epyc IBPB, Conroe, Penryn, and
>> Opteron G1-3. If you have those, you need to change it to a supported type
>> while it's in 4.2 still.
>>
>> Greg
>>
>> On Thu, Feb 7, 2019 at 1:11 AM Ryan Bullock  wrote:
>>
>>> We just updated our engine to 4.3, but when I tried to update one of our
>>> AMD EPYC hosts it could not activate with the error:
>>>
>>> Host vmc2h2 moved to Non-Operational state as host CPU type is not
>>> supported in this cluster compatibility version or is not supported at all.
>>>
>>> Relevant (I think) parts from the the engine log:
>>>
>>> (EE-ManagedThreadFactory-engineScheduled-Thread-82) [ee51a70] Could not
>>> find server cpu for server 'vmc2h2' (745a14c6-9d31-48a4-9566-914647d83f53),
>>> flags:
>>> 'fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,mmx,fxsr,sse,sse2,ht,syscall,nx,mmxext,fxsr_opt,pdpe1gb,rdtscp,lm,constant_tsc,art,rep_good,nopl,nonstop_tsc,extd_apicid,amd_dcm,aperfmperf,eagerfpu,pni,pclmulqdq,monitor,ssse3,fma,cx16,sse4_1,sse4_2,movbe,popcnt,aes,xsave,avx,f16c,rdrand,lahf_lm,cmp_legacy,svm,extapic,cr8_legacy,abm,sse4a,misalignsse,3dnowprefetch,osvw,skinit,wdt,tce,topoext,perfctr_core,perfctr_nb,bpext,perfctr_l2,cpb,hw_pstate,sme,retpoline_amd,ssbd,ibpb,vmmcall,fsgsbase,bmi1,avx2,smep,bmi2,rdseed,adx,smap,clflushopt,sha_ni,xsaveopt,xsavec,xgetbv1,clzero,irperf,xsaveerptr,arat,npt,lbrv,svm_lock,nrip_save,tsc_scale,vmcb_clean,flushbyasid,decodeassists,pausefilter,pfthreshold,avic,v_vmsave_vmload,vgif,overflow_recov,succor,smca'
>>> 2019-02-06 17:23:58,527-08 INFO
>>> [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand]
>>> (EE-ManagedThreadFactory-engineScheduled-Thread-82) [7f6d4f0d] START,
>>> SetVdsStatusVDSCommand(HostName = vmc2h2,
>>> SetVdsStatusVDSCommandParameters:{hostId='745a14c6-9d31-48a4-9566-914647d83f53',
>>> status='NonOperational',
>>> nonOperationalReason='CPU_TYPE_INCOMPATIBLE_WITH_CLUSTER'
>>>
>>>
>>> From virsh -r capabilities:
>>>
>>> 
>>>   x86_64
>>>   EPYC-IBPB
>>>   AMD
>>>   
>>>   
>>>   
>>>   
>>>   
>>>   
>>>   
>>>   
>>>   
>>>   
>>>   
>>>   
>>>   
>>>   
>>>   
>>>   
>>>   
>>> 
>>>
>>> I also tried creating a new 4.3 cluster, set to the AMD EPYC IPBDB SSBD
>>> and moving the host into it, but it failed to move it into that cluster
>>> with a similar error about an unsupported CPU (for some reason it also made
>>> me clear the additional kernel options as well, we use 1gb hugepages). I
>>> have not yet tried removing the host entirely and adding it as part of
>>> creating the new cluster.
>>>
>>> We have been/are using a database change to update the 4.2 cluster level
>>> to include EPYC support with the following entries (can post the whole
>>> query if needed):
>>> 7:AMD EPYC:svm,nx,model_EPYC:EPYC:x86_64; 8:AMD EPYC
>>> IBPB:svm,nx,ibpb,model_EPYC:EPYC-IBPB:x86_64
>>>
>>> We have been running 4.2 with this for awhile. We did apply the same
>>> changes after the 4.3 update, but only for the 4.2 cluster level. We only
>>> used the AMD EPYC IBPB model.
>>>
>>> Reverting the host back to 4.2 allows it to activate and run normally.
>>>
>>> Anyone have any ideas as to why it can't seem to find the cpu type?
>>>
>>> Thanks,
>>>
>>> Ryan Bullock
>>> ___
>>> Users mailing list -- users@ovirt.org
>>> To unsubscribe send an email to users-le...@ovirt.org
>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>>> oVirt Code of Conduct:
>>> https://www.ovirt.org/community/about/community-guidelines/
>>> List Archives:
>>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/4Y4X7UGDEYSB5JK45TLDERNM7IMTHIYY/
>>>
>>
>>
>> --
>>
>> GREG SHEREMETA
>>
>> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>>
>> Red Hat NA
>>
>> 
>>
>> gsher...@redhat.comIRC: gshereme
>> 
>>
>

-- 

GREG SHEREMETA

SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX

Red Hat NA



gsher...@redhat.comIRC: gshereme

___
Users mailing list --

[ovirt-users] Re: ovirt-node-4.3, deployment fails when moving hosted engine vm to gluster storage.

2019-02-07 Thread feral

Which logs?

The nodes hang on boot at "Started Flush Journal to Persistent Storage".
This would be followed by gluster mounts coming up (before networking,
which still doesn't make sense to me...) but they of course all fail as
networking is down.
The gluster logs, post node failure, simply state that all connection
attempts are failing (because networking is down.

I managed to get networking online manually and push logs OUT (cant' start
sshd as that causes reboot).
https://drive.google.com/open?id=1Kdb2pRUC0O-5u3ZkA3KT0qvAQIpv9SZm

It seems to me that some vital systemd service must be failing on the nodes
(and possibly that's what's happening on the VM as well?

On Thu, Feb 7, 2019 at 8:25 AM Simone Tiraboschi 
wrote:

>
>
> On Thu, Feb 7, 2019 at 5:19 PM feral  wrote:
>
>> I've never managed to get a connection to the engine via VNC/Spice (works
>> fine for my other hypervisors...)
>>
>> As I said, the network setup is super simple. All three nodes have 1
>> interface each (eth0). They are all set with static IP's, with matching
>> DHCP reservations on the DHCP server, with matching DNS. All nodes have
>> entries in /etc/hosts on each machine. IP's are 192.168.1.195-7, and the
>> engine VM gets 192.168.1.198. During the engine deployment, the VM does
>> come up on 198. I can ping it and ssh into it, but at some point, the
>> connection drops.
>> So I'm not relying on DHCP or DNS at all. VM comes up where expected, for
>> a while, then it goes to reboot to get transferred to the gluster_engine
>> storage, and that's where it drops offline and never comes back.
>>
>> I did another round of deployment tests last night and discovered that
>> the nodes all fail to boot immediately after the gluster deployment (not
>> after VM deployment as I mistakenly stated earlier). So the nodes get in a
>> bad state during gluster deployment. They stay online just fine and gluster
>> works perfect, until the node tries to reboot (which it fails to do).
>>
>
> So I suggest to focus on the gluster deployment; can you please share
> gluster logs?
>
>
>>
>> Also, the networking I'm using is identical to my ovirt 4.2 setup. I'm
>> using the same MAC addresses, IP's, and hostnames (4.2 cluster is offline
>> when I'm trying 4.3). They are identical configurations other than the
>> version of ovirt-node.
>>
>> On Thu, Feb 7, 2019 at 12:15 AM Simone Tiraboschi 
>> wrote:
>>
>>>
>>>
>>> On Wed, Feb 6, 2019 at 11:07 PM feral  wrote:
>>>
 I have no idea what's wrong at this point. Very vanilla install of 3
 nodes. Run the Hyperconverged wizard, completes fine. Run the engine
 deployment, takes hours, eventually fails with :

 [ INFO ] TASK [oVirt.hosted-engine-setup : Check engine VM health]
 [ ERROR ] fatal: [localhost]: FAILED! => {"attempts": 120, "changed":
 true, "cmd": ["hosted-engine", "--vm-status", "--json"], "delta":
 "0:00:00.340985", "end": "2019-02-06 11:44:48.836431", "rc": 0, "start":
 "2019-02-06 11:44:48.495446", "stderr": "", "stderr_lines": [], "stdout":
 "{\"1\": {\"conf_on_shared_storage\": true, \"live-data\": true, \"extra\":
 \"metadata_parse_version=1\\nmetadata_feature_version=1\\ntimestamp=12994
 (Wed Feb 6 11:44:44
 2019)\\nhost-id=1\\nscore=3400\\nvm_conf_refresh_time=12995 (Wed Feb 6
 11:44:44
 2019)\\nconf_on_shared_storage=True\\nmaintenance=False\\nstate=EngineStop\\nstopped=False\\n\",
 \"hostname\": \"ovirt-431.localdomain\", \"host-id\": 1, \"engine-status\":
 {\"reason\": \"failed liveliness check\", \"health\": \"bad\", \"vm\":
 \"up\", \"detail\": \"Up\"}, \"score\": 3400, \"stopped\": false,
 \"maintenance\": false, \"crc32\": \"5474927a\", \"local_conf_timestamp\":
 12995, \"host-ts\": 12994}, \"global_maintenance\": false}",
 "stdout_lines": ["{\"1\": {\"conf_on_shared_storage\": true, \"live-data\":
 true, \"extra\":
 \"metadata_parse_version=1\\nmetadata_feature_version=1\\ntimestamp=12994
 (Wed Feb 6 11:44:44
 2019)\\nhost-id=1\\nscore=3400\\nvm_conf_refresh_time=12995 (Wed Feb 6
 11:44:44
 2019)\\nconf_on_shared_storage=True\\nmaintenance=False\\nstate=EngineStop\\nstopped=False\\n\",
 \"hostname\": \"ovirt-431.localdomain\", \"host-id\": 1, \"engine-status\":
 {\"reason\": \"failed liveliness check\", \"health\": \"bad\", \"vm\":
 \"up\", \"detail\": \"Up\"}, \"score\": 3400, \"stopped\": false,
 \"maintenance\": false, \"crc32\": \"5474927a\", \"local_conf_timestamp\":
 12995, \"host-ts\": 12994}, \"global_maintenance\": false}"]}
 [ INFO ] TASK [oVirt.hosted-engine-setup : Check VM status at virt
 level]
 [ INFO ] changed: [localhost]
 [ INFO ] TASK [oVirt.hosted-engine-setup : debug]
 [ INFO ] ok: [localhost]
 [ INFO ] TASK [oVirt.hosted-engine-setup : Fail if engine VM is not
 running]
 [ INFO ] skipping: [localhost]
 [ INFO ] TASK [oVirt.hosted-engine-setup : Get target engine VM IP
 address]
 [ INFO ]

[ovirt-users] Re: AMD EPYC 4.3 upgrade 'CPU type is not supported in this cluster compatibility version or is not supported at all'

2019-02-07 Thread Ryan Bullock

That would explain it.

Would removing the host and then reinstalling it under a new 4.3 cluster
work without having to set the entire old cluster into maintenance to
change the cpu? Then I could just restart VM's into the new cluster as we
transition to minimize downtime.

Thanks for the info!

Ryan

On Thu, Feb 7, 2019 at 7:56 AM Greg Sheremeta  wrote:

> AMD EPYC IBPB is deprecated in 4.3.
> The deprecated CPUs (cpus variable, that entire list) are:
>
> https://gerrit.ovirt.org/#/c/95310/7/frontend/webadmin/modules/webadmin/src/main/java/org/ovirt/engine/ui/webadmin/widget/table/column/ClusterAdditionalStatusColumn.java
>
> So, *-IBRS [IBRS-SSBD is still ok], Epyc IBPB, Conroe, Penryn, and
> Opteron G1-3. If you have those, you need to change it to a supported type
> while it's in 4.2 still.
>
> Greg
>
> On Thu, Feb 7, 2019 at 1:11 AM Ryan Bullock  wrote:
>
>> We just updated our engine to 4.3, but when I tried to update one of our
>> AMD EPYC hosts it could not activate with the error:
>>
>> Host vmc2h2 moved to Non-Operational state as host CPU type is not
>> supported in this cluster compatibility version or is not supported at all.
>>
>> Relevant (I think) parts from the the engine log:
>>
>> (EE-ManagedThreadFactory-engineScheduled-Thread-82) [ee51a70] Could not
>> find server cpu for server 'vmc2h2' (745a14c6-9d31-48a4-9566-914647d83f53),
>> flags:
>> 'fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,mmx,fxsr,sse,sse2,ht,syscall,nx,mmxext,fxsr_opt,pdpe1gb,rdtscp,lm,constant_tsc,art,rep_good,nopl,nonstop_tsc,extd_apicid,amd_dcm,aperfmperf,eagerfpu,pni,pclmulqdq,monitor,ssse3,fma,cx16,sse4_1,sse4_2,movbe,popcnt,aes,xsave,avx,f16c,rdrand,lahf_lm,cmp_legacy,svm,extapic,cr8_legacy,abm,sse4a,misalignsse,3dnowprefetch,osvw,skinit,wdt,tce,topoext,perfctr_core,perfctr_nb,bpext,perfctr_l2,cpb,hw_pstate,sme,retpoline_amd,ssbd,ibpb,vmmcall,fsgsbase,bmi1,avx2,smep,bmi2,rdseed,adx,smap,clflushopt,sha_ni,xsaveopt,xsavec,xgetbv1,clzero,irperf,xsaveerptr,arat,npt,lbrv,svm_lock,nrip_save,tsc_scale,vmcb_clean,flushbyasid,decodeassists,pausefilter,pfthreshold,avic,v_vmsave_vmload,vgif,overflow_recov,succor,smca'
>> 2019-02-06 17:23:58,527-08 INFO
>> [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand]
>> (EE-ManagedThreadFactory-engineScheduled-Thread-82) [7f6d4f0d] START,
>> SetVdsStatusVDSCommand(HostName = vmc2h2,
>> SetVdsStatusVDSCommandParameters:{hostId='745a14c6-9d31-48a4-9566-914647d83f53',
>> status='NonOperational',
>> nonOperationalReason='CPU_TYPE_INCOMPATIBLE_WITH_CLUSTER'
>>
>>
>> From virsh -r capabilities:
>>
>> 
>>   x86_64
>>   EPYC-IBPB
>>   AMD
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>> 
>>
>> I also tried creating a new 4.3 cluster, set to the AMD EPYC IPBDB SSBD
>> and moving the host into it, but it failed to move it into that cluster
>> with a similar error about an unsupported CPU (for some reason it also made
>> me clear the additional kernel options as well, we use 1gb hugepages). I
>> have not yet tried removing the host entirely and adding it as part of
>> creating the new cluster.
>>
>> We have been/are using a database change to update the 4.2 cluster level
>> to include EPYC support with the following entries (can post the whole
>> query if needed):
>> 7:AMD EPYC:svm,nx,model_EPYC:EPYC:x86_64; 8:AMD EPYC
>> IBPB:svm,nx,ibpb,model_EPYC:EPYC-IBPB:x86_64
>>
>> We have been running 4.2 with this for awhile. We did apply the same
>> changes after the 4.3 update, but only for the 4.2 cluster level. We only
>> used the AMD EPYC IBPB model.
>>
>> Reverting the host back to 4.2 allows it to activate and run normally.
>>
>> Anyone have any ideas as to why it can't seem to find the cpu type?
>>
>> Thanks,
>>
>> Ryan Bullock
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/4Y4X7UGDEYSB5JK45TLDERNM7IMTHIYY/
>>
>
>
> --
>
> GREG SHEREMETA
>
> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>
> Red Hat NA
>
> 
>
> gsher...@redhat.comIRC: gshereme
> 
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/FMDXG35JGXXEA3IKDWKFRS5OICZIXQYL/

[ovirt-users] Re: ovirt-node-4.3, deployment fails when moving hosted engine vm to gluster storage.

On Thu, Feb 7, 2019 at 5:19 PM feral  wrote:

> I've never managed to get a connection to the engine via VNC/Spice (works
> fine for my other hypervisors...)
>
> As I said, the network setup is super simple. All three nodes have 1
> interface each (eth0). They are all set with static IP's, with matching
> DHCP reservations on the DHCP server, with matching DNS. All nodes have
> entries in /etc/hosts on each machine. IP's are 192.168.1.195-7, and the
> engine VM gets 192.168.1.198. During the engine deployment, the VM does
> come up on 198. I can ping it and ssh into it, but at some point, the
> connection drops.
> So I'm not relying on DHCP or DNS at all. VM comes up where expected, for
> a while, then it goes to reboot to get transferred to the gluster_engine
> storage, and that's where it drops offline and never comes back.
>
> I did another round of deployment tests last night and discovered that the
> nodes all fail to boot immediately after the gluster deployment (not after
> VM deployment as I mistakenly stated earlier). So the nodes get in a bad
> state during gluster deployment. They stay online just fine and gluster
> works perfect, until the node tries to reboot (which it fails to do).
>

So I suggest to focus on the gluster deployment; can you please share
gluster logs?


>
> Also, the networking I'm using is identical to my ovirt 4.2 setup. I'm
> using the same MAC addresses, IP's, and hostnames (4.2 cluster is offline
> when I'm trying 4.3). They are identical configurations other than the
> version of ovirt-node.
>
> On Thu, Feb 7, 2019 at 12:15 AM Simone Tiraboschi 
> wrote:
>
>>
>>
>> On Wed, Feb 6, 2019 at 11:07 PM feral  wrote:
>>
>>> I have no idea what's wrong at this point. Very vanilla install of 3
>>> nodes. Run the Hyperconverged wizard, completes fine. Run the engine
>>> deployment, takes hours, eventually fails with :
>>>
>>> [ INFO ] TASK [oVirt.hosted-engine-setup : Check engine VM health]
>>> [ ERROR ] fatal: [localhost]: FAILED! => {"attempts": 120, "changed":
>>> true, "cmd": ["hosted-engine", "--vm-status", "--json"], "delta":
>>> "0:00:00.340985", "end": "2019-02-06 11:44:48.836431", "rc": 0, "start":
>>> "2019-02-06 11:44:48.495446", "stderr": "", "stderr_lines": [], "stdout":
>>> "{\"1\": {\"conf_on_shared_storage\": true, \"live-data\": true, \"extra\":
>>> \"metadata_parse_version=1\\nmetadata_feature_version=1\\ntimestamp=12994
>>> (Wed Feb 6 11:44:44
>>> 2019)\\nhost-id=1\\nscore=3400\\nvm_conf_refresh_time=12995 (Wed Feb 6
>>> 11:44:44
>>> 2019)\\nconf_on_shared_storage=True\\nmaintenance=False\\nstate=EngineStop\\nstopped=False\\n\",
>>> \"hostname\": \"ovirt-431.localdomain\", \"host-id\": 1, \"engine-status\":
>>> {\"reason\": \"failed liveliness check\", \"health\": \"bad\", \"vm\":
>>> \"up\", \"detail\": \"Up\"}, \"score\": 3400, \"stopped\": false,
>>> \"maintenance\": false, \"crc32\": \"5474927a\", \"local_conf_timestamp\":
>>> 12995, \"host-ts\": 12994}, \"global_maintenance\": false}",
>>> "stdout_lines": ["{\"1\": {\"conf_on_shared_storage\": true, \"live-data\":
>>> true, \"extra\":
>>> \"metadata_parse_version=1\\nmetadata_feature_version=1\\ntimestamp=12994
>>> (Wed Feb 6 11:44:44
>>> 2019)\\nhost-id=1\\nscore=3400\\nvm_conf_refresh_time=12995 (Wed Feb 6
>>> 11:44:44
>>> 2019)\\nconf_on_shared_storage=True\\nmaintenance=False\\nstate=EngineStop\\nstopped=False\\n\",
>>> \"hostname\": \"ovirt-431.localdomain\", \"host-id\": 1, \"engine-status\":
>>> {\"reason\": \"failed liveliness check\", \"health\": \"bad\", \"vm\":
>>> \"up\", \"detail\": \"Up\"}, \"score\": 3400, \"stopped\": false,
>>> \"maintenance\": false, \"crc32\": \"5474927a\", \"local_conf_timestamp\":
>>> 12995, \"host-ts\": 12994}, \"global_maintenance\": false}"]}
>>> [ INFO ] TASK [oVirt.hosted-engine-setup : Check VM status at virt level]
>>> [ INFO ] changed: [localhost]
>>> [ INFO ] TASK [oVirt.hosted-engine-setup : debug]
>>> [ INFO ] ok: [localhost]
>>> [ INFO ] TASK [oVirt.hosted-engine-setup : Fail if engine VM is not
>>> running]
>>> [ INFO ] skipping: [localhost]
>>> [ INFO ] TASK [oVirt.hosted-engine-setup : Get target engine VM IP
>>> address]
>>> [ INFO ] changed: [localhost]
>>> [ INFO ] TASK [oVirt.hosted-engine-setup : Get VDSM's target engine VM
>>> stats]
>>> [ INFO ] changed: [localhost]
>>> [ INFO ] TASK [oVirt.hosted-engine-setup : Convert stats to JSON format]
>>> [ INFO ] ok: [localhost]
>>> [ INFO ] TASK [oVirt.hosted-engine-setup : Get target engine VM IP
>>> address from VDSM stats]
>>> [ INFO ] ok: [localhost]
>>> [ INFO ] TASK [oVirt.hosted-engine-setup : debug]
>>> [ INFO ] ok: [localhost]
>>> [ INFO ] TASK [oVirt.hosted-engine-setup : Fail if Engine IP is
>>> different from engine's he_fqdn resolved IP]
>>> [ INFO ] skipping: [localhost]
>>> [ INFO ] TASK [oVirt.hosted-engine-setup : Fail is for any other reason
>>> the engine didn't started]
>>> [ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "The
>>> engine failed to start inside the

[ovirt-users] Re: ovirt-node-4.3, deployment fails when moving hosted engine vm to gluster storage.

2019-02-07 Thread feral

I've never managed to get a connection to the engine via VNC/Spice (works
fine for my other hypervisors...)

As I said, the network setup is super simple. All three nodes have 1
interface each (eth0). They are all set with static IP's, with matching
DHCP reservations on the DHCP server, with matching DNS. All nodes have
entries in /etc/hosts on each machine. IP's are 192.168.1.195-7, and the
engine VM gets 192.168.1.198. During the engine deployment, the VM does
come up on 198. I can ping it and ssh into it, but at some point, the
connection drops.
So I'm not relying on DHCP or DNS at all. VM comes up where expected, for a
while, then it goes to reboot to get transferred to the gluster_engine
storage, and that's where it drops offline and never comes back.

I did another round of deployment tests last night and discovered that the
nodes all fail to boot immediately after the gluster deployment (not after
VM deployment as I mistakenly stated earlier). So the nodes get in a bad
state during gluster deployment. They stay online just fine and gluster
works perfect, until the node tries to reboot (which it fails to do).

Also, the networking I'm using is identical to my ovirt 4.2 setup. I'm
using the same MAC addresses, IP's, and hostnames (4.2 cluster is offline
when I'm trying 4.3). They are identical configurations other than the
version of ovirt-node.

On Thu, Feb 7, 2019 at 12:15 AM Simone Tiraboschi 
wrote:

>
>
> On Wed, Feb 6, 2019 at 11:07 PM feral  wrote:
>
>> I have no idea what's wrong at this point. Very vanilla install of 3
>> nodes. Run the Hyperconverged wizard, completes fine. Run the engine
>> deployment, takes hours, eventually fails with :
>>
>> [ INFO ] TASK [oVirt.hosted-engine-setup : Check engine VM health]
>> [ ERROR ] fatal: [localhost]: FAILED! => {"attempts": 120, "changed":
>> true, "cmd": ["hosted-engine", "--vm-status", "--json"], "delta":
>> "0:00:00.340985", "end": "2019-02-06 11:44:48.836431", "rc": 0, "start":
>> "2019-02-06 11:44:48.495446", "stderr": "", "stderr_lines": [], "stdout":
>> "{\"1\": {\"conf_on_shared_storage\": true, \"live-data\": true, \"extra\":
>> \"metadata_parse_version=1\\nmetadata_feature_version=1\\ntimestamp=12994
>> (Wed Feb 6 11:44:44
>> 2019)\\nhost-id=1\\nscore=3400\\nvm_conf_refresh_time=12995 (Wed Feb 6
>> 11:44:44
>> 2019)\\nconf_on_shared_storage=True\\nmaintenance=False\\nstate=EngineStop\\nstopped=False\\n\",
>> \"hostname\": \"ovirt-431.localdomain\", \"host-id\": 1, \"engine-status\":
>> {\"reason\": \"failed liveliness check\", \"health\": \"bad\", \"vm\":
>> \"up\", \"detail\": \"Up\"}, \"score\": 3400, \"stopped\": false,
>> \"maintenance\": false, \"crc32\": \"5474927a\", \"local_conf_timestamp\":
>> 12995, \"host-ts\": 12994}, \"global_maintenance\": false}",
>> "stdout_lines": ["{\"1\": {\"conf_on_shared_storage\": true, \"live-data\":
>> true, \"extra\":
>> \"metadata_parse_version=1\\nmetadata_feature_version=1\\ntimestamp=12994
>> (Wed Feb 6 11:44:44
>> 2019)\\nhost-id=1\\nscore=3400\\nvm_conf_refresh_time=12995 (Wed Feb 6
>> 11:44:44
>> 2019)\\nconf_on_shared_storage=True\\nmaintenance=False\\nstate=EngineStop\\nstopped=False\\n\",
>> \"hostname\": \"ovirt-431.localdomain\", \"host-id\": 1, \"engine-status\":
>> {\"reason\": \"failed liveliness check\", \"health\": \"bad\", \"vm\":
>> \"up\", \"detail\": \"Up\"}, \"score\": 3400, \"stopped\": false,
>> \"maintenance\": false, \"crc32\": \"5474927a\", \"local_conf_timestamp\":
>> 12995, \"host-ts\": 12994}, \"global_maintenance\": false}"]}
>> [ INFO ] TASK [oVirt.hosted-engine-setup : Check VM status at virt level]
>> [ INFO ] changed: [localhost]
>> [ INFO ] TASK [oVirt.hosted-engine-setup : debug]
>> [ INFO ] ok: [localhost]
>> [ INFO ] TASK [oVirt.hosted-engine-setup : Fail if engine VM is not
>> running]
>> [ INFO ] skipping: [localhost]
>> [ INFO ] TASK [oVirt.hosted-engine-setup : Get target engine VM IP
>> address]
>> [ INFO ] changed: [localhost]
>> [ INFO ] TASK [oVirt.hosted-engine-setup : Get VDSM's target engine VM
>> stats]
>> [ INFO ] changed: [localhost]
>> [ INFO ] TASK [oVirt.hosted-engine-setup : Convert stats to JSON format]
>> [ INFO ] ok: [localhost]
>> [ INFO ] TASK [oVirt.hosted-engine-setup : Get target engine VM IP
>> address from VDSM stats]
>> [ INFO ] ok: [localhost]
>> [ INFO ] TASK [oVirt.hosted-engine-setup : debug]
>> [ INFO ] ok: [localhost]
>> [ INFO ] TASK [oVirt.hosted-engine-setup : Fail if Engine IP is different
>> from engine's he_fqdn resolved IP]
>> [ INFO ] skipping: [localhost]
>> [ INFO ] TASK [oVirt.hosted-engine-setup : Fail is for any other reason
>> the engine didn't started]
>> [ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "The
>> engine failed to start inside the engine VM; please check engine.log."}
>>
>> ---
>>
>> I can't check the engine.log as I can't connect to the VM once this
>> failure occurs. I can ssh in prior to the VM being moved to gluster
>>

[ovirt-users] oVirt users using Gluster: feedback needed

2019-02-07 Thread Sandro Bonazzola

Hi,
Gluster community opened a survey for the whole month of February 2019:
https://www.gluster.org/gluster-community-survey-february-2019/

If you're using Gluster with oVirt please be sure to give gluster community
feedback helping improve for next versions.

Thanks,
-- 

SANDRO BONAZZOLA

MANAGER, SOFTWARE ENGINEERING, EMEA R RHV

Red Hat EMEA 

sbona...@redhat.com

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/3OJDZ263X62REBCHOYGQZ7DATGLYQSM4/

[ovirt-users] Re: AMD EPYC 4.3 upgrade 'CPU type is not supported in this cluster compatibility version or is not supported at all'

AMD EPYC IBPB is deprecated in 4.3.
The deprecated CPUs (cpus variable, that entire list) are:
https://gerrit.ovirt.org/#/c/95310/7/frontend/webadmin/modules/webadmin/src/main/java/org/ovirt/engine/ui/webadmin/widget/table/column/ClusterAdditionalStatusColumn.java

So, *-IBRS [IBRS-SSBD is still ok], Epyc IBPB, Conroe, Penryn, and Opteron
G1-3. If you have those, you need to change it to a supported type while
it's in 4.2 still.

Greg

On Thu, Feb 7, 2019 at 1:11 AM Ryan Bullock  wrote:

> We just updated our engine to 4.3, but when I tried to update one of our
> AMD EPYC hosts it could not activate with the error:
>
> Host vmc2h2 moved to Non-Operational state as host CPU type is not
> supported in this cluster compatibility version or is not supported at all.
>
> Relevant (I think) parts from the the engine log:
>
> (EE-ManagedThreadFactory-engineScheduled-Thread-82) [ee51a70] Could not
> find server cpu for server 'vmc2h2' (745a14c6-9d31-48a4-9566-914647d83f53),
> flags:
> 'fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,mmx,fxsr,sse,sse2,ht,syscall,nx,mmxext,fxsr_opt,pdpe1gb,rdtscp,lm,constant_tsc,art,rep_good,nopl,nonstop_tsc,extd_apicid,amd_dcm,aperfmperf,eagerfpu,pni,pclmulqdq,monitor,ssse3,fma,cx16,sse4_1,sse4_2,movbe,popcnt,aes,xsave,avx,f16c,rdrand,lahf_lm,cmp_legacy,svm,extapic,cr8_legacy,abm,sse4a,misalignsse,3dnowprefetch,osvw,skinit,wdt,tce,topoext,perfctr_core,perfctr_nb,bpext,perfctr_l2,cpb,hw_pstate,sme,retpoline_amd,ssbd,ibpb,vmmcall,fsgsbase,bmi1,avx2,smep,bmi2,rdseed,adx,smap,clflushopt,sha_ni,xsaveopt,xsavec,xgetbv1,clzero,irperf,xsaveerptr,arat,npt,lbrv,svm_lock,nrip_save,tsc_scale,vmcb_clean,flushbyasid,decodeassists,pausefilter,pfthreshold,avic,v_vmsave_vmload,vgif,overflow_recov,succor,smca'
> 2019-02-06 17:23:58,527-08 INFO
> [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand]
> (EE-ManagedThreadFactory-engineScheduled-Thread-82) [7f6d4f0d] START,
> SetVdsStatusVDSCommand(HostName = vmc2h2,
> SetVdsStatusVDSCommandParameters:{hostId='745a14c6-9d31-48a4-9566-914647d83f53',
> status='NonOperational',
> nonOperationalReason='CPU_TYPE_INCOMPATIBLE_WITH_CLUSTER'
>
>
> From virsh -r capabilities:
>
> 
>   x86_64
>   EPYC-IBPB
>   AMD
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
> 
>
> I also tried creating a new 4.3 cluster, set to the AMD EPYC IPBDB SSBD
> and moving the host into it, but it failed to move it into that cluster
> with a similar error about an unsupported CPU (for some reason it also made
> me clear the additional kernel options as well, we use 1gb hugepages). I
> have not yet tried removing the host entirely and adding it as part of
> creating the new cluster.
>
> We have been/are using a database change to update the 4.2 cluster level
> to include EPYC support with the following entries (can post the whole
> query if needed):
> 7:AMD EPYC:svm,nx,model_EPYC:EPYC:x86_64; 8:AMD EPYC
> IBPB:svm,nx,ibpb,model_EPYC:EPYC-IBPB:x86_64
>
> We have been running 4.2 with this for awhile. We did apply the same
> changes after the 4.3 update, but only for the 4.2 cluster level. We only
> used the AMD EPYC IBPB model.
>
> Reverting the host back to 4.2 allows it to activate and run normally.
>
> Anyone have any ideas as to why it can't seem to find the cpu type?
>
> Thanks,
>
> Ryan Bullock
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/4Y4X7UGDEYSB5JK45TLDERNM7IMTHIYY/
>


-- 

GREG SHEREMETA

SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX

Red Hat NA



gsher...@redhat.comIRC: gshereme

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/N4FMHDIK2GWERNWLFUG5NQFKCYMXEZSS/

[ovirt-users] Agentless Backup update: Trilio Vault, pay $7500

Back in June of 2018, I posted regarding Agentless backup solutions.
Greg Sheremeta replied & mentioned Trilio.

The rest of the story...well just read on...

These guys at Trilio have turned out to be a complete waste of time. (I could
use some more colorful language)

After my post & reply from Greg Sheremeta, I followed up with Trilio.
A lot of promises/dates were made (by Trilio) as to when a beta would be made
available for testing.
Needless to say, they never came through.
Finally in Dec 2018, they said we are ready for the demo, we will show you a
working product.
The day came, Trilio said, sorry it's too close to Xmas, we will postpone the
demo's till 2019.
In 2019, I continued to follow up & finally they set a date for another demo -
Jan 29.
On Jan. 29, we get on the Webex, they said, sorry the demo just broke 10 mins
prior to our call, so no demo.
They show me some screenshots & their OpenStack version & again promise to get
me beta software in a few days.
I continue to follow up (via email)

Yesterday (Feb 6), I get an email from Thomas Lahive GM; Sales and Alliance
Partners(copied & pasted below):
"We started RHV betas and decided to prioritize current Trilio customers (those
that purchased Triliovault for Openstack).
If you would like to be part of the beta now then We can sign you up as a
certified Trilio reseller which has a $7,500 Starter Fee. The $7,500 will be
credited against your first customer order that is at least $7,500 so it will
eventually cost you nothing. Many of our partners can apply the fee against
revenue so it's a great tax incentive, but you can confirm with your finance
department.
Please Lmk how you would like to proceed."

Please remember, I have never seen a working demo of this product, never.

Is this typical behavior of RH partners?
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/LOURUDNY72K3HX35HDT7LMJ4UKTRAQ7S/

[ovirt-users] Re: ovn bad gateway after update from 4.2.7 to 4.2.8

2019-02-07 Thread Dominik Holler

On Mon, 4 Feb 2019 16:15:56 +0100
Dominik Holler  wrote:

> On Mon, 4 Feb 2019 15:57:24 +0100
> Gianluca Cecchi  wrote:
> 
> > On Mon, Feb 4, 2019 at 2:47 PM Gianluca Cecchi 
> > wrote:
> > 
> > > On Fri, Feb 1, 2019 at 10:51 PM Dominik Holler  wrote:
> > >
> > >> On Fri, 1 Feb 2019 22:35:00 +0200
> > >> Dan Kenigsberg  wrote:
> > >>
> > >> > On Fri, Feb 1, 2019 at 10:18 PM Dominik Holler 
> > >> > wrote:
> > >> > >
> > >> > > On Fri, 1 Feb 2019 14:37:10 +0100
> > >> > > Gianluca Cecchi  wrote:
> > >> > >
> > >> > > > Hello,
> > >> > > > at this moment (about two days ago) I have updated only engine
> > >> > > > (external, not self hosted) from 4.2.7.5 to 4.2.8.2
> > >> > > >
> > >> > > > As soon as I'm starting for the first time a VM with an ovn based
> > >> > > > nic I get what below in ovirt-provider-ovn.log
> > >> > > >
> > >> > > > In admin gui, if I try for example to start via "run once" I get:
> > >> > > > "
> > >> > > > Error while executing action Run VM once: Failed to communicate
> > >> > > > with the external provider, see log for additional details.
> > >> > > > "
> > >> > > > Any clue?
> > >> > >
> > >> > > The ovirt-provider-ovn fails during checking the credentials at
> > >> > > engine's sso because of a networking problem.
> > >> >
> > >> > That would be odd - after all we're using the loopback interface
> > >> > From: :::127.0.0.1:49582 Request: GET /v2.0/ports
> > >> > but please try the url.
> > >> >
> > >>
> > >> Communication from Engine to ovirt-provider-ovn via OpenStack API looks
> > >> good. The problem seems to be in the communication from
> > >> ovirt-provider-ovn to engine's sso.
> > >> The hostname to resolve seems to be 'engine-host'.
> > >>
> > >>
> > > Hi all, so it seems that updating from 4.2.7 to 4.2.8 wiped the file
> > > entirely...
> > >
> > > In fact now I only have:
> > >
> > >  [root@ovmgr1 ~]# ll /etc/ovirt-provider-ovn/conf.d/
> > > total 4
> > > -rw-r--r--. 1 root root 194 Jan 14 16:18 README
> > > [root@ovmgr1 ~]#
> > >
> > > While on another similar environment in 4.2.7 I still have:
> > >
> > > [root@ovirt ~]# ll /etc/ovirt-provider-ovn/conf.d/
> > > total 8
> > > -rw-r--r--. 1 root root 561 Dec 31  2017 10-setup-ovirt-provider-ovn.conf
> > > -rw-r--r--. 1 root root 194 Oct 17 05:56 README
> > > [root@ovirt ~]#
> > >
> > > So in my updated environment I think it tries to use the default file
> > > values in /etc/ovirt-provider-ovn/ovirt-provider-ovn.conf
> > > [OVIRT]
> > > ovirt-host=https://engine-host
> > >
> > > The question now is why it has been wiped out?
> > > This environment has external VM working as ovirt engine, so not SHE.
> > >
> > > I see that engine-backup doesn't run backup of the
> > > /etc/ovirt-provider-ovn/ ... could it be useful to include it?
> 
> Sounds like a valuable idea, would you create a bug?
> 

Bug 1630824 - engine-backup should backup ovirt-provider-ovn
https://bugzilla.redhat.com/1630824


> > > I should have a VSPhere image backup of the VM so I should be able to
> > > restore the file. I'll see...
> > >
> > > In the mean time could it be the update of the package has been the
> > > responsible?
> > > Eg, in my 4.2.7 env I currently have 
> > > ovirt-provider-ovn-1.2.16-1.el7.noarch
> > > The update to 4.2.8 in the other system has put
> > > in ovirt-provider-ovn-1.2.18-1.el7.noarch
> > >
> > > HIH debugging
> > > Gianluca
> > >
> > 
> > My update from 4.2.7 to 4.2.8 has been executed on 29th of January around
> > 18:00
> > I have restored a VM image the day before and it seems that
> > the  /etc/ovirt-provider-ovn/conf.d/10-setup-ovirt-provider-ovn.conf was
> > not there even before the update
> > 
> > The diff between the
> > previous /etc/ovirt-provider-ovn/ovirt-provider-ovn.conf and the new one
> > put in place by the update is
> > 
> > [root@ovmgr1 ovirt-provider-ovn]# diff old_ovirt-provider-ovn.conf
> > ovirt-provider-ovn.conf
> > 11a12
> > > url_filter_exception=limit,page_reverse,next,previous
> > [root@ovmgr1 ovirt-provider-ovn]#
> > 
> > At this point, as it has been some time I didn't power up  VMs on OVN in
> > this environment, I go back with past updates.
> > On this environment the OVN part was installed manually when not yet
> > included in standard setup.
> > So I find this thread of mine about update from 4.1.9 to 4.2.3 on May 2018
> > I had a doubt about OVN and update and posted here:
> > https://www.mail-archive.com/users@ovirt.org/msg48491.html
> > 
> 
> Thanks for figuring this out.
> 
> > So based on Marcin feedback I selected NO for ovirt-ovn-provider question
> > and perhaps the following updates caused file to be removed... perhaps...
> 
> This file is generated by engine-setup if Yes is selected for
> ovirt-ovn-provider, so I expect the file never existed.
> 
> > How can I solve now?
> 
> Remove or rename the ovirt-provider-ovn provider in oVirt Engine, if it
> already exsits and run engine-setup with answer-file that has
> 'OVESETUP_OVN/ovirtProviderOvn' enabled: 
>

[ovirt-users] Agentless Backup update: Trilio Vault...what a joke, pay $7500

Back in June of 2018, I posted regarding Agentless backup solutions.
Greg Sheremeta replied & mentioned Trilio.

The rest of the story...well just read on...

These guys at Trilio have turned out to be a complete waste of time. (I could
use some more colorful language)

Please remember, I have never seen a working demo of this product, never.

Is this typical behavior of RH partners?

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/S3EXPUPGRT4YWMGE44ZCPTIPQZOTP5EH/

[ovirt-users] Re: unable to migrate hosted-engine to oVirt 4.3 updated nodes

2019-02-07 Thread Edward Berger

Ok, I'll check.
4.2.8 nodes
   libvirt.x86_644.5.0-10.el7_6.3
installed
4.3.0 upgraded nodes
  libvirt.x86_644.5.0-10.el7_6.4
installed


On Thu, Feb 7, 2019 at 12:03 AM Sahina Bose  wrote:

> On Thu, Feb 7, 2019 at 8:57 AM Edward Berger  wrote:
> >
> > I'm seeing migration failures for the hosted-engine VM from a 4.28 node
> to a 4.30 node so I can complete the node upgrades.
>
> You may be running into
> https://bugzilla.redhat.com/show_bug.cgi?id=1641798. Can you check the
> version of libvirt used on the nodes?
> >
> > In one case I tried to force an update on the last node and now have a
> cluster where the hosted-engine VM fails to start properly.   Sometimes
> something thinks the VM is running, but clicking for details it seems to
> have no disk.  I was so close to putting that one into production with
> working LDAP user logins and custom SSL cert and then Oops! with the
> upgrade.
> >
> > In both cases the hosted VM storage is on gluster.  One hyperconverged
> oVirt nodes, the other two nodes with an external gluster 5 server cluster
> >
> > I will note that I had set the engines previously (while at 4.2.8) to
> use the gluster direct method enabling (libgfapi disk access level 4.2)
> instead of the default fuse client for improved performance.
> >
> > Other details  Engine was updated first.
> > Nodes were updated with
> >
> > yum install
> https://resources.ovirt.org/pub/ovirt-4.3/rpm/el7/noarch/ovirt-node-ng-image-update-4.3.0-1.el7.noarch.rpm
> >
> > I forgot to mention another symptom.
> > On the hyperconverged cluster, the "gluster volume heal engine" command
> errors out on 4.3, but other gluster volumes accepted it.
>
> +Ravishankar Narayanankutty to check the heal failures
>
> >
> > rolling back to 4.28 allows the heal command to succeed (nothing to do
> actually) on engine, but I'm still unable to start a working engine VM with
> hosted-engine --vm-start
> >
> >
> > ___
> > Users mailing list -- users@ovirt.org
> > To unsubscribe send an email to users-le...@ovirt.org
> > Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> > oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> > List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/HFHLP473CFIMINFBUO4NH6WO3GPIQSVU/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/UZWZGGO3LDBCIT4RRZHL2SKOVOA66Y5G/

[ovirt-users] Re: Agentless backup solutions

Sorry to dig up an old thread...

These guys at Trilio have turned out to be a complete waste of time. (I could
use some more colorful language)

After the post from Greg Sheremeta, I followed up with Trilio.
A lot of promises/dates were made (by Trilio) as to when a beta would be made
available for testing.
Needless to say, they never came through.
Finally in Dec 2018, they said we are ready for the demo, we will show you a
working product.
The day came, Trilio said, sorry it's too close to Xmas, we will postpone the
demo's till 2019.
In 2019, I continued to follow up & finally they set a date for another demo -
Jan 29.
On Jan. 29, we get on the Webex, they said, sorry the demo just broke 10 mins
prior to our call, so no demo.
They show me some screenshots & their OpenStack version & again promise to get
me beta software in a few days.
I continue to follow up (via email)

Yesterday (Feb 6), I get an email from Trilio(copied & pasted below):
"We started RHV betas and decided to prioritize current Trilio customers (those
that purchased Triliovault for Openstack).
If you would like to be part of the beta now then We can sign you up as a
certified Trilio reseller which has a $7,500 Starter Fee. The $7,500 will be
credited against your first customer order that is at least $7,500 so it will
eventually cost you nothing. Many of our partners can apply the fee against
revenue so it's a great tax incentive, but you can confirm with your finance
department.
Please Lmk how you would like to proceed."

[ovirt-users] Re: Agentless backup solutions

Sorry to dig up an old thread...

These guys at Trilio have turned out to be a complete waste of time. (I could
use some more colorful language)

[ovirt-users] Re: Agentless backup solutions

Sorry to dig up an old thread...

These guys at Trilio have turned out to be a complete waste of time. (I could
use some more colorful language)

[ovirt-users] Re: ovirt-imageio-proxy upload and status

On Thu, Feb 7, 2019 at 3:32 PM Hetz Ben Hamo  wrote:

> Sure, care to tell me the locations of those files? (I assume they are on
> the HE?)
>

Yes, should be on /var/log folder.
If you just want to unlock the disk in the mean time, you can use the
'unlock_entity' utility:
https://www.ovirt.org/develop/developer-guide/db-issues/helperutilities.html#unlock_entity


>
> Thanks
>
>
> On Thu, Feb 7, 2019 at 3:30 PM Daniel Erez  wrote:
>
>>
>>
>> On Thu, Feb 7, 2019 at 3:25 PM Hetz Ben Hamo  wrote:
>>
>>> see this screenshot: https://imgur.com/a/Mzpn6qY
>>>
>>
>> ok, so maybe there was a failure in the finalizing step that should
>> unlock the disk as well.
>> Can you please attach the relevant engine/vdsm/proxy/daemon logs?
>>
>>
>>>
>>> תודה,
>>> *חץ בן חמו*
>>> אתם מוזמנים לבקר בבלוג היעוץ  או בבלוג הפרטי
>>> שלי 
>>>
>>>
>>> On Thu, Feb 7, 2019 at 3:21 PM Daniel Erez  wrote:
>>>


 On Thu, Feb 7, 2019 at 3:19 PM Hetz Ben Hamo  wrote:

> Hi Daniel,
>
> There is no failure when uploading the ISO. I tried to upload it both
> to NFS and to iSCSI. In both cases it completes the upload and the status
> remains "completed".
> I can use the ISO from the storage domain without any problems so
> there are no errors.
>

 Where do you see this status? In REST-API?
 What is the status of the disk? ('Disks' tab in the WebAdmin)


>
>
> On Thu, Feb 7, 2019 at 3:04 PM Daniel Erez  wrote:
>
>>
>>
>> On Thu, Feb 7, 2019 at 9:26 AM Sandro Bonazzola 
>> wrote:
>>
>>>
>>>
>>> Il giorno gio 7 feb 2019 alle ore 01:12 Hetz Ben Hamo 
>>> ha scritto:
>>>
 Hi,

 I've just uploaded the CentOS 1810 ISO to a domain. It worked.
 However, the status in the UI is "stuck" in the "complete" in the
 status column. Does it change to "OK" as others images in the domain?

>>>
>> Hi Hetz,
>>
>> The disk should move back to 'OK' status after completing the
>> operation.
>> In case of a failure during the operation, the disk moves to 'PAUSED'
>> state, in which it can be either resumes or cancelled.
>>
>> * What is the current status of the disk?
>> * Any failure message in the events tab?
>> * Can you please attach engine/vdsm/proxy/daemon logs?
>> * If the upload can't be cancelled or resumed, the disk can be
>> manually unlocked using the 'unlock_entity' utility:
>>
>> https://www.ovirt.org/develop/developer-guide/db-issues/helperutilities.html#unlock_entity
>>
>>
>>>
>>> Daniel, Tal, do we have page data refresh issue there?
>>>
>>>
 ___
 Users mailing list -- users@ovirt.org
 To unsubscribe send an email to users-le...@ovirt.org
 Privacy Statement: https://www.ovirt.org/site/privacy-policy/
 oVirt Code of Conduct:
 https://www.ovirt.org/community/about/community-guidelines/
 List Archives:
 https://lists.ovirt.org/archives/list/users@ovirt.org/message/K5FEKILG2D7PO3QPTB5RRX3RR6RXWNII/

>>>
>>>
>>> --
>>>
>>> SANDRO BONAZZOLA
>>>
>>> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>>>
>>> Red Hat EMEA 
>>>
>>> sbona...@redhat.com
>>> 
>>>
>>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/GUHPSXO6EISTSV2GZLVYVN6E32FLF342/

[ovirt-users] Re: ovirt-imageio-proxy upload and status

Sure, care to tell me the locations of those files? (I assume they are on
the HE?)

Thanks


On Thu, Feb 7, 2019 at 3:30 PM Daniel Erez  wrote:

>
>
> On Thu, Feb 7, 2019 at 3:25 PM Hetz Ben Hamo  wrote:
>
>> see this screenshot: https://imgur.com/a/Mzpn6qY
>>
>
> ok, so maybe there was a failure in the finalizing step that should unlock
> the disk as well.
> Can you please attach the relevant engine/vdsm/proxy/daemon logs?
>
>
>>
>> תודה,
>> *חץ בן חמו*
>> אתם מוזמנים לבקר בבלוג היעוץ  או בבלוג הפרטי שלי
>> 
>>
>>
>> On Thu, Feb 7, 2019 at 3:21 PM Daniel Erez  wrote:
>>
>>>
>>>
>>> On Thu, Feb 7, 2019 at 3:19 PM Hetz Ben Hamo  wrote:
>>>
 Hi Daniel,

 There is no failure when uploading the ISO. I tried to upload it both
 to NFS and to iSCSI. In both cases it completes the upload and the status
 remains "completed".
 I can use the ISO from the storage domain without any problems so there
 are no errors.

>>>
>>> Where do you see this status? In REST-API?
>>> What is the status of the disk? ('Disks' tab in the WebAdmin)
>>>
>>>


 On Thu, Feb 7, 2019 at 3:04 PM Daniel Erez  wrote:

>
>
> On Thu, Feb 7, 2019 at 9:26 AM Sandro Bonazzola 
> wrote:
>
>>
>>
>> Il giorno gio 7 feb 2019 alle ore 01:12 Hetz Ben Hamo 
>> ha scritto:
>>
>>> Hi,
>>>
>>> I've just uploaded the CentOS 1810 ISO to a domain. It worked.
>>> However, the status in the UI is "stuck" in the "complete" in the
>>> status column. Does it change to "OK" as others images in the domain?
>>>
>>
> Hi Hetz,
>
> The disk should move back to 'OK' status after completing the
> operation.
> In case of a failure during the operation, the disk moves to 'PAUSED'
> state, in which it can be either resumes or cancelled.
>
> * What is the current status of the disk?
> * Any failure message in the events tab?
> * Can you please attach engine/vdsm/proxy/daemon logs?
> * If the upload can't be cancelled or resumed, the disk can be
> manually unlocked using the 'unlock_entity' utility:
>
> https://www.ovirt.org/develop/developer-guide/db-issues/helperutilities.html#unlock_entity
>
>
>>
>> Daniel, Tal, do we have page data refresh issue there?
>>
>>
>>> ___
>>> Users mailing list -- users@ovirt.org
>>> To unsubscribe send an email to users-le...@ovirt.org
>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>>> oVirt Code of Conduct:
>>> https://www.ovirt.org/community/about/community-guidelines/
>>> List Archives:
>>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/K5FEKILG2D7PO3QPTB5RRX3RR6RXWNII/
>>>
>>
>>
>> --
>>
>> SANDRO BONAZZOLA
>>
>> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>>
>> Red Hat EMEA 
>>
>> sbona...@redhat.com
>> 
>>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/I7SUAJSZ2EENKUUVX6SAOPV3AU7NCYM6/

[ovirt-users] Re: ovirt-imageio-proxy upload and status

On Thu, Feb 7, 2019 at 3:25 PM Hetz Ben Hamo  wrote:

> see this screenshot: https://imgur.com/a/Mzpn6qY
>

ok, so maybe there was a failure in the finalizing step that should unlock
the disk as well.
Can you please attach the relevant engine/vdsm/proxy/daemon logs?


>
> תודה,
> *חץ בן חמו*
> אתם מוזמנים לבקר בבלוג היעוץ  או בבלוג הפרטי שלי
> 
>
>
> On Thu, Feb 7, 2019 at 3:21 PM Daniel Erez  wrote:
>
>>
>>
>> On Thu, Feb 7, 2019 at 3:19 PM Hetz Ben Hamo  wrote:
>>
>>> Hi Daniel,
>>>
>>> There is no failure when uploading the ISO. I tried to upload it both to
>>> NFS and to iSCSI. In both cases it completes the upload and the status
>>> remains "completed".
>>> I can use the ISO from the storage domain without any problems so there
>>> are no errors.
>>>
>>
>> Where do you see this status? In REST-API?
>> What is the status of the disk? ('Disks' tab in the WebAdmin)
>>
>>
>>>
>>>
>>> On Thu, Feb 7, 2019 at 3:04 PM Daniel Erez  wrote:
>>>


 On Thu, Feb 7, 2019 at 9:26 AM Sandro Bonazzola 
 wrote:

>
>
> Il giorno gio 7 feb 2019 alle ore 01:12 Hetz Ben Hamo 
> ha scritto:
>
>> Hi,
>>
>> I've just uploaded the CentOS 1810 ISO to a domain. It worked.
>> However, the status in the UI is "stuck" in the "complete" in the
>> status column. Does it change to "OK" as others images in the domain?
>>
>
 Hi Hetz,

 The disk should move back to 'OK' status after completing the operation.
 In case of a failure during the operation, the disk moves to 'PAUSED'
 state, in which it can be either resumes or cancelled.

 * What is the current status of the disk?
 * Any failure message in the events tab?
 * Can you please attach engine/vdsm/proxy/daemon logs?
 * If the upload can't be cancelled or resumed, the disk can be manually
 unlocked using the 'unlock_entity' utility:

 https://www.ovirt.org/develop/developer-guide/db-issues/helperutilities.html#unlock_entity


>
> Daniel, Tal, do we have page data refresh issue there?
>
>
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/K5FEKILG2D7PO3QPTB5RRX3RR6RXWNII/
>>
>
>
> --
>
> SANDRO BONAZZOLA
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>
> Red Hat EMEA 
>
> sbona...@redhat.com
> 
>

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/HREIHW3GIO6GOARII5FQUPTSO3HZMPOR/

[ovirt-users] Re: ovirt-imageio-proxy upload and status

see this screenshot: https://imgur.com/a/Mzpn6qY
תודה,
*חץ בן חמו*
אתם מוזמנים לבקר בבלוג היעוץ  או בבלוג הפרטי שלי



On Thu, Feb 7, 2019 at 3:21 PM Daniel Erez  wrote:

>
>
> On Thu, Feb 7, 2019 at 3:19 PM Hetz Ben Hamo  wrote:
>
>> Hi Daniel,
>>
>> There is no failure when uploading the ISO. I tried to upload it both to
>> NFS and to iSCSI. In both cases it completes the upload and the status
>> remains "completed".
>> I can use the ISO from the storage domain without any problems so there
>> are no errors.
>>
>
> Where do you see this status? In REST-API?
> What is the status of the disk? ('Disks' tab in the WebAdmin)
>
>
>>
>>
>> On Thu, Feb 7, 2019 at 3:04 PM Daniel Erez  wrote:
>>
>>>
>>>
>>> On Thu, Feb 7, 2019 at 9:26 AM Sandro Bonazzola 
>>> wrote:
>>>


 Il giorno gio 7 feb 2019 alle ore 01:12 Hetz Ben Hamo 
 ha scritto:

> Hi,
>
> I've just uploaded the CentOS 1810 ISO to a domain. It worked.
> However, the status in the UI is "stuck" in the "complete" in the
> status column. Does it change to "OK" as others images in the domain?
>

>>> Hi Hetz,
>>>
>>> The disk should move back to 'OK' status after completing the operation.
>>> In case of a failure during the operation, the disk moves to 'PAUSED'
>>> state, in which it can be either resumes or cancelled.
>>>
>>> * What is the current status of the disk?
>>> * Any failure message in the events tab?
>>> * Can you please attach engine/vdsm/proxy/daemon logs?
>>> * If the upload can't be cancelled or resumed, the disk can be manually
>>> unlocked using the 'unlock_entity' utility:
>>>
>>> https://www.ovirt.org/develop/developer-guide/db-issues/helperutilities.html#unlock_entity
>>>
>>>

 Daniel, Tal, do we have page data refresh issue there?


> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/K5FEKILG2D7PO3QPTB5RRX3RR6RXWNII/
>


 --

 SANDRO BONAZZOLA

 MANAGER, SOFTWARE ENGINEERING, EMEA R RHV

 Red Hat EMEA 

 sbona...@redhat.com
 

>>>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/F2K3V7R4QCAIA3JWBQNF4OKPJJ4TN32F/

[ovirt-users] Re: ovirt-imageio-proxy upload and status

On Thu, Feb 7, 2019 at 3:19 PM Hetz Ben Hamo  wrote:

> Hi Daniel,
>
> There is no failure when uploading the ISO. I tried to upload it both to
> NFS and to iSCSI. In both cases it completes the upload and the status
> remains "completed".
> I can use the ISO from the storage domain without any problems so there
> are no errors.
>

Where do you see this status? In REST-API?
What is the status of the disk? ('Disks' tab in the WebAdmin)


>
>
> On Thu, Feb 7, 2019 at 3:04 PM Daniel Erez  wrote:
>
>>
>>
>> On Thu, Feb 7, 2019 at 9:26 AM Sandro Bonazzola 
>> wrote:
>>
>>>
>>>
>>> Il giorno gio 7 feb 2019 alle ore 01:12 Hetz Ben Hamo 
>>> ha scritto:
>>>
 Hi,

 I've just uploaded the CentOS 1810 ISO to a domain. It worked.
 However, the status in the UI is "stuck" in the "complete" in the
 status column. Does it change to "OK" as others images in the domain?

>>>
>> Hi Hetz,
>>
>> The disk should move back to 'OK' status after completing the operation.
>> In case of a failure during the operation, the disk moves to 'PAUSED'
>> state, in which it can be either resumes or cancelled.
>>
>> * What is the current status of the disk?
>> * Any failure message in the events tab?
>> * Can you please attach engine/vdsm/proxy/daemon logs?
>> * If the upload can't be cancelled or resumed, the disk can be manually
>> unlocked using the 'unlock_entity' utility:
>>
>> https://www.ovirt.org/develop/developer-guide/db-issues/helperutilities.html#unlock_entity
>>
>>
>>>
>>> Daniel, Tal, do we have page data refresh issue there?
>>>
>>>
 ___
 Users mailing list -- users@ovirt.org
 To unsubscribe send an email to users-le...@ovirt.org
 Privacy Statement: https://www.ovirt.org/site/privacy-policy/
 oVirt Code of Conduct:
 https://www.ovirt.org/community/about/community-guidelines/
 List Archives:
 https://lists.ovirt.org/archives/list/users@ovirt.org/message/K5FEKILG2D7PO3QPTB5RRX3RR6RXWNII/

>>>
>>>
>>> --
>>>
>>> SANDRO BONAZZOLA
>>>
>>> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>>>
>>> Red Hat EMEA 
>>>
>>> sbona...@redhat.com
>>> 
>>>
>>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/3N644Q2N3AQ5TTSII6746WDKRWNP24KU/

[ovirt-users] Re: ovirt-imageio-proxy upload and status

Hi Daniel,

There is no failure when uploading the ISO. I tried to upload it both to
NFS and to iSCSI. In both cases it completes the upload and the status
remains "completed".
I can use the ISO from the storage domain without any problems so there are
no errors.


On Thu, Feb 7, 2019 at 3:04 PM Daniel Erez  wrote:

>
>
> On Thu, Feb 7, 2019 at 9:26 AM Sandro Bonazzola 
> wrote:
>
>>
>>
>> Il giorno gio 7 feb 2019 alle ore 01:12 Hetz Ben Hamo  ha
>> scritto:
>>
>>> Hi,
>>>
>>> I've just uploaded the CentOS 1810 ISO to a domain. It worked.
>>> However, the status in the UI is "stuck" in the "complete" in the status
>>> column. Does it change to "OK" as others images in the domain?
>>>
>>
> Hi Hetz,
>
> The disk should move back to 'OK' status after completing the operation.
> In case of a failure during the operation, the disk moves to 'PAUSED'
> state, in which it can be either resumes or cancelled.
>
> * What is the current status of the disk?
> * Any failure message in the events tab?
> * Can you please attach engine/vdsm/proxy/daemon logs?
> * If the upload can't be cancelled or resumed, the disk can be manually
> unlocked using the 'unlock_entity' utility:
>
> https://www.ovirt.org/develop/developer-guide/db-issues/helperutilities.html#unlock_entity
>
>
>>
>> Daniel, Tal, do we have page data refresh issue there?
>>
>>
>>> ___
>>> Users mailing list -- users@ovirt.org
>>> To unsubscribe send an email to users-le...@ovirt.org
>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>>> oVirt Code of Conduct:
>>> https://www.ovirt.org/community/about/community-guidelines/
>>> List Archives:
>>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/K5FEKILG2D7PO3QPTB5RRX3RR6RXWNII/
>>>
>>
>>
>> --
>>
>> SANDRO BONAZZOLA
>>
>> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>>
>> Red Hat EMEA 
>>
>> sbona...@redhat.com
>> 
>>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/SO6HLN5KVZDRNRPHJPVZJXVGC6JGWEPD/

[ovirt-users] Re: vm autostart and priorities

On Thu, Feb 7, 2019 at 1:59 PM Greg Sheremeta  wrote:

>
> On Thu, Feb 7, 2019 at 5:28 AM Hetz Ben Hamo  wrote:
>
>> Hi,
>>
>> I'm migrating my VM's to oVirt from ESXI and I've only got one left on
>> the ESXi side - a VM which provides me DNS, mail and DHCP services. Without
>> this VM's, I can't access the internet.
>>
>
> I'm not sure about the feasability of running DNS or DHCP in a vm --
> hopefully someone else can speak to that.
>
>
>>
>> The only issue that prevents me from migrating this VM to oVirt and
>> "kill" the ESXi machine, is that I need to start this VM's upon oVirt node
>> power up (auto start), so if the power goes down and comes back, I'll have
>> my infrastructure up and running automatically within minutes.
>>
>> Is there a way to auto start specific VM's
>>
>
> Yes, see
>
> https://www.ovirt.org/documentation/vmm-guide/chap-Administrative_Tasks.html#improving-uptime-with-virtual-machine-high-availability
>  and maybe
>
> https://www.ovirt.org/documentation/vmm-guide/chap-Additional_Configuration.html#configuring-a-watchdog
>
> or better - start VM's based on specific orders upon boot of the nodes? I
>> think it's a very important feature.
>>
>
> Affinity might help here, not sure.
> https://www.ovirt.org/documentation/vmm-guide/chap-Administrative_Tasks.html#affinity-groups
>

We need to split the problems in two:
- the first step is bringing oVirt engine and oVirt hosted-engine is
designed for that purpose: ovirt-ha-agent will connect the storage and
bring up a VM with the engine in a matter of minutes (*)
- than, once you have a running engine, you can rely on the HA mechanism
with VM leases and so on to restart the VMs that you need to be in HA.

Please notice that at engine level you have a kind of HA priority mechanism
to influence the VM boostrap order without really setting dependencies or
something like that:
http://ovirt.github.io/ovirt-engine-api-model/master/#types/high_availability/attributes/priority

Please notice that the graphical user interface (GUI) does not allow
specifying all the possible values, instead it only allows you to select
Low, Medium or High. If you need a finer granularity you have to set them
via REST APIs.

Then, in the second plane, you should also take a look to
VmStorageErrorResumeBehaviour:
http://ovirt.github.io/ovirt-engine-api-model/master/#types/vm_storage_error_resume_behaviour

to eventually handle the resume after storage errors.
and you can also eventually define per VM watchdogs:
http://ovirt.github.io/ovirt-engine-api-model/master/#services/vm_watchdog


* Please notice that you should configure your env to be sure that your HE
hosts and the engine VM are able to correctly start even without a properly
running DHCP and DNS.


>
> Best wishes,
> Greg
>
>
>>
>> Thanks
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/NJLGLSOTMNUCHPZ7WOLKCWY4ZVSMKMAD/
>>
>
>
> --
>
> GREG SHEREMETA
>
> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>
> Red Hat NA
>
> 
>
> gsher...@redhat.comIRC: gshereme
> 
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/7L4KXO3ESAFVAKPZ45SAI7DSNIHK3CIW/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/EX6OPVE4W55NBI5L45BJGHMW5N5BQNHF/

[ovirt-users] Re: Gluster version on oVirt 4.3.0

2019-02-07 Thread Simon Coter



> On Feb 7, 2019, at 11:55 AM, supo...@logicworks.pt wrote:
> 
> Hi,
> 
> What Glusterfs version should I use with oVirt 4.3.0 ?

Gluster 5.2 is the release used by oVirt 4.3

Simon

> 
> Thanks
> 
> -- 
> Jose Ferradeira
> http://www.logicworks.pt
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/Z7ZZO5DES3HZEAYYUVEJHNTVVMSTOUPB/

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/MMSDRYL2UR53W2OWBULSE7KOQJNBXRAL/

[ovirt-users] Re: ovirt-imageio-proxy upload and status

On Thu, Feb 7, 2019 at 9:26 AM Sandro Bonazzola  wrote:

>
>
> Il giorno gio 7 feb 2019 alle ore 01:12 Hetz Ben Hamo  ha
> scritto:
>
>> Hi,
>>
>> I've just uploaded the CentOS 1810 ISO to a domain. It worked.
>> However, the status in the UI is "stuck" in the "complete" in the status
>> column. Does it change to "OK" as others images in the domain?
>>
>
Hi Hetz,

The disk should move back to 'OK' status after completing the operation.
In case of a failure during the operation, the disk moves to 'PAUSED'
state, in which it can be either resumes or cancelled.

* What is the current status of the disk?
* Any failure message in the events tab?
* Can you please attach engine/vdsm/proxy/daemon logs?
* If the upload can't be cancelled or resumed, the disk can be manually
unlocked using the 'unlock_entity' utility:
https://www.ovirt.org/develop/developer-guide/db-issues/helperutilities.html#unlock_entity

>
> Daniel, Tal, do we have page data refresh issue there?
>
>
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/K5FEKILG2D7PO3QPTB5RRX3RR6RXWNII/
>>
>
>
> --
>
> SANDRO BONAZZOLA
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>
> Red Hat EMEA 
>
> sbona...@redhat.com
> 
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/YEGI6ZKIXYUTHVKLP2BGLX4SSAI45BVO/

[ovirt-users] Re: ovirt upgrade 4.3 - dashboard is dispalyed 2x in top left corner menu

Ok great, great to hear it's all working now.

On Thu, Feb 7, 2019 at 7:54 AM Martin Humaj  wrote:

> Hi Greg,
>
> We did upgrade from 4.2.0 something to 4.3 two days ago. The hosted engine
> is running as another VM under the oVirt.
> I had some trouble to run engine-setup after the upgrade.Simone Tiraboschi
> helped to avoid error with initial setup. I could not set global
> maintenance on engine, because communication was not working between hosts
> and VM engine.
> After I was able to login to GUI everything is working so far, even the
> vmware migration is going smoothly.
>

nice to hear that too :)

Greg


>
> I just faced the issue with dasboard and you helped to fix that one also.
> The rest is looking good.
>
> Thanks
>
>
>
>
>
> On Thu, Feb 7, 2019 at 1:42 PM Greg Sheremeta  wrote:
>
>>
>> On Thu, Feb 7, 2019 at 7:39 AM Martin Humaj  wrote:
>>
>>> Hi Greg,
>>>
>>> Thanks a lot for quick reply.
>>>
>>> yum update ovirt-engine-ui-extensions, fixed the issue
>>>
>>> The duplicate is gone.
>>>
>>
>> Good to hear, thanks. For posterity, can you tell me if you did the
>> update today or a couple days ago? And, are you using hosted engine? I want
>> to make sure it's not still broken for everyone else :)
>>
>>
>>>
>>> martin
>>>
>>> On Thu, Feb 7, 2019 at 1:32 PM Greg Sheremeta 
>>> wrote:
>>>
 It should be fixed now. When did you update?

 Are you using hosted engine?

 On Thu, Feb 7, 2019, 6:36 AM  wrote:

> After the upgrade to ovirt 4.3, I can see two entry for dashboard in
> top left corner menu. Is there any way how to get rid of the duplicity?
>
> thanks
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/GN4ER4YD6KTQLF2FK2ZLZI6IM5U6XEW4/
>

>>
>> --
>>
>> GREG SHEREMETA
>>
>> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>>
>> Red Hat NA
>>
>> 
>>
>> gsher...@redhat.comIRC: gshereme
>> 
>>
>

-- 

GREG SHEREMETA

SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX

Red Hat NA



gsher...@redhat.comIRC: gshereme

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/MHD5A6VVALKHLXPIV4CXLCHDHUW3KZOY/

[ovirt-users] Re: vm autostart and priorities

On Thu, Feb 7, 2019 at 5:28 AM Hetz Ben Hamo  wrote:

> Hi,
>
> I'm migrating my VM's to oVirt from ESXI and I've only got one left on the
> ESXi side - a VM which provides me DNS, mail and DHCP services. Without
> this VM's, I can't access the internet.
>

I'm not sure about the feasability of running DNS or DHCP in a vm --
hopefully someone else can speak to that.


>
> The only issue that prevents me from migrating this VM to oVirt and "kill"
> the ESXi machine, is that I need to start this VM's upon oVirt node power
> up (auto start), so if the power goes down and comes back, I'll have my
> infrastructure up and running automatically within minutes.
>
> Is there a way to auto start specific VM's
>

Yes, see
https://www.ovirt.org/documentation/vmm-guide/chap-Administrative_Tasks.html#improving-uptime-with-virtual-machine-high-availability
 and maybe
https://www.ovirt.org/documentation/vmm-guide/chap-Additional_Configuration.html#configuring-a-watchdog

or better - start VM's based on specific orders upon boot of the nodes? I
> think it's a very important feature.
>

Affinity might help here, not sure.
https://www.ovirt.org/documentation/vmm-guide/chap-Administrative_Tasks.html#affinity-groups

Best wishes,
Greg


>
> Thanks
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/NJLGLSOTMNUCHPZ7WOLKCWY4ZVSMKMAD/
>


-- 

GREG SHEREMETA

SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX

Red Hat NA



gsher...@redhat.comIRC: gshereme

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/7L4KXO3ESAFVAKPZ45SAI7DSNIHK3CIW/

[ovirt-users] Re: ovirt upgrade 4.3 - dashboard is dispalyed 2x in top left corner menu

2019-02-07 Thread Martin Humaj

Hi Greg,

We did upgrade from 4.2.0 something to 4.3 two days ago. The hosted engine
is running as another VM under the oVirt.
I had some trouble to run engine-setup after the upgrade.Simone Tiraboschi
helped to avoid error with initial setup. I could not set global
maintenance on engine, because communication was not working between hosts
and VM engine.
After I was able to login to GUI everything is working so far, even the
vmware migration is going smoothly.

I just faced the issue with dasboard and you helped to fix that one also.
The rest is looking good.

Thanks





On Thu, Feb 7, 2019 at 1:42 PM Greg Sheremeta  wrote:

>
> On Thu, Feb 7, 2019 at 7:39 AM Martin Humaj  wrote:
>
>> Hi Greg,
>>
>> Thanks a lot for quick reply.
>>
>> yum update ovirt-engine-ui-extensions, fixed the issue
>>
>> The duplicate is gone.
>>
>
> Good to hear, thanks. For posterity, can you tell me if you did the update
> today or a couple days ago? And, are you using hosted engine? I want to
> make sure it's not still broken for everyone else :)
>
>
>>
>> martin
>>
>> On Thu, Feb 7, 2019 at 1:32 PM Greg Sheremeta 
>> wrote:
>>
>>> It should be fixed now. When did you update?
>>>
>>> Are you using hosted engine?
>>>
>>> On Thu, Feb 7, 2019, 6:36 AM  wrote:
>>>
 After the upgrade to ovirt 4.3, I can see two entry for dashboard in
 top left corner menu. Is there any way how to get rid of the duplicity?

 thanks
 ___
 Users mailing list -- users@ovirt.org
 To unsubscribe send an email to users-le...@ovirt.org
 Privacy Statement: https://www.ovirt.org/site/privacy-policy/
 oVirt Code of Conduct:
 https://www.ovirt.org/community/about/community-guidelines/
 List Archives:
 https://lists.ovirt.org/archives/list/users@ovirt.org/message/GN4ER4YD6KTQLF2FK2ZLZI6IM5U6XEW4/

>>>
>
> --
>
> GREG SHEREMETA
>
> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>
> Red Hat NA
>
> 
>
> gsher...@redhat.comIRC: gshereme
> 
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/KJBX7CNEJOESTJXQNN6UQ2WM5FSMZEPX/

[ovirt-users] Re: Gluster version on oVirt 4.3.0

2019-02-07 Thread Sandro Bonazzola

Il giorno gio 7 feb 2019 alle ore 11:57  ha scritto:

> Hi,
>
> What Glusterfs version should I use with oVirt 4.3.0 ?
>

4.3.0 is using Gluster 5


>
> Thanks
>
> --
> --
> Jose Ferradeira
> http://www.logicworks.pt
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/Z7ZZO5DES3HZEAYYUVEJHNTVVMSTOUPB/
>


-- 

SANDRO BONAZZOLA

MANAGER, SOFTWARE ENGINEERING, EMEA R RHV

Red Hat EMEA 

sbona...@redhat.com

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/6P43MAXPE5MWHJJ35PX2DCWE6SRE6H7X/

[ovirt-users] Re: qxl issue on OVirt 4.3.0

Welcome, glad you got it working :)

On Thu, Feb 7, 2019 at 1:07 AM Robert Crawford <
robert.crawford4.14...@gmail.com> wrote:

> I'm using images from https://cloud.centos.org/centos/7/images/
>
> The 1811 image works as expected.
> Thanks for your help
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/LOYY7FICIWYYG2T7OLO3545K445BNSLY/
>


-- 

GREG SHEREMETA

SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX

Red Hat NA



gsher...@redhat.comIRC: gshereme

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/HIUU3IHJTFMWPD2D4SWK4FTJHZEJTQD4/

[ovirt-users] Re: ovirt upgrade 4.3 - dashboard is dispalyed 2x in top left corner menu

On Thu, Feb 7, 2019 at 7:39 AM Martin Humaj  wrote:

> Hi Greg,
>
> Thanks a lot for quick reply.
>
> yum update ovirt-engine-ui-extensions, fixed the issue
>
> The duplicate is gone.
>

Good to hear, thanks. For posterity, can you tell me if you did the update
today or a couple days ago? And, are you using hosted engine? I want to
make sure it's not still broken for everyone else :)


>
> martin
>
> On Thu, Feb 7, 2019 at 1:32 PM Greg Sheremeta  wrote:
>
>> It should be fixed now. When did you update?
>>
>> Are you using hosted engine?
>>
>> On Thu, Feb 7, 2019, 6:36 AM  wrote:
>>
>>> After the upgrade to ovirt 4.3, I can see two entry for dashboard in top
>>> left corner menu. Is there any way how to get rid of the duplicity?
>>>
>>> thanks
>>> ___
>>> Users mailing list -- users@ovirt.org
>>> To unsubscribe send an email to users-le...@ovirt.org
>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>>> oVirt Code of Conduct:
>>> https://www.ovirt.org/community/about/community-guidelines/
>>> List Archives:
>>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/GN4ER4YD6KTQLF2FK2ZLZI6IM5U6XEW4/
>>>
>>

-- 

GREG SHEREMETA

SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX

Red Hat NA



gsher...@redhat.comIRC: gshereme

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/HWQ22OB3LUHT7AGRXNZFC6GKYQNUSUML/

[ovirt-users] Re: ovirt upgrade 4.3 - dashboard is dispalyed 2x in top left corner menu

It should be fixed now. When did you update?

Are you using hosted engine?

On Thu, Feb 7, 2019, 6:36 AM  wrote:

> After the upgrade to ovirt 4.3, I can see two entry for dashboard in top
> left corner menu. Is there any way how to get rid of the duplicity?
>
> thanks
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/GN4ER4YD6KTQLF2FK2ZLZI6IM5U6XEW4/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/5NE4UCG5UN5X4QQUOYWVZ5WSJ2BTHQZS/

[ovirt-users] Re: Cluster upgrade

2019-02-07 Thread Misak Khachatryan

Well, never did that before ...
Anyway, thanks for pointing that out.

Best regards,
Misak Khachatryan


On Thu, Feb 7, 2019 at 3:32 PM Martin Perina  wrote:

>
>
> On Thu, Feb 7, 2019 at 12:24 PM Misak Khachatryan 
> wrote:
>
>> Thanks Martin,
>>
>> you are right, on all hosts which i did upgrade ovirt-4.3 repo is not
>> present. Seems like a bug.
>>
>
> This is not a bug, you need to update repos on hosts manually prior to the
> upgrade.
>
>>
>> Best regards,
>> Misak Khachatryan
>>
>>
>> On Tue, Feb 5, 2019 at 10:03 PM Martin Perina  wrote:
>>
>>>
>>>
>>> On Tue, 5 Feb 2019, 14:54 Misak Khachatryan >>
 Hi,

 I've successfully upgraded to 4.3, but when I'm trying to upgrade
 Cluster version I'm getting this:

 "Error while executing action: Cannot change Cluster Compatibility
 Version to higher version when there are active Hosts with lower version.
 -Please move Host virt2 with lower version to maintenance first."

>>>
>>> It seems that on host virt2 you have installed VDSM which doesn't
>>> support higher cluster version. Please try to upgrade the host before
>>> upgrading the cluster.
>>>
>>>
 Any clues?

 Best regards,
 Misak Khachatryan
 ___
 Users mailing list -- users@ovirt.org
 To unsubscribe send an email to users-le...@ovirt.org
 Privacy Statement: https://www.ovirt.org/site/privacy-policy/
 oVirt Code of Conduct:
 https://www.ovirt.org/community/about/community-guidelines/
 List Archives:
 https://lists.ovirt.org/archives/list/users@ovirt.org/message/6R64SOEIYXFGTDTWOWZDHREJDUKL6IEP/

>>>
>
> --
> Martin Perina
> Associate Manager, Software Engineering
> Red Hat Czech s.r.o.
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/3KHEOJKEMCGVSDMLIH3EUMYFTR43OZSO/

[ovirt-users] ovirt upgrade 4.3 - dashboard is dispalyed 2x in top left corner menu

2019-02-07 Thread mhumaj

After the upgrade to ovirt 4.3, I can see two entry for dashboard in top left 
corner menu. Is there any way how to get rid of the duplicity?

thanks
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/GN4ER4YD6KTQLF2FK2ZLZI6IM5U6XEW4/

[ovirt-users] Re: Cluster upgrade

2019-02-07 Thread Martin Perina

On Thu, Feb 7, 2019 at 12:24 PM Misak Khachatryan  wrote:

> Thanks Martin,
>
> you are right, on all hosts which i did upgrade ovirt-4.3 repo is not
> present. Seems like a bug.
>

This is not a bug, you need to update repos on hosts manually prior to the
upgrade.

>
> Best regards,
> Misak Khachatryan
>
>
> On Tue, Feb 5, 2019 at 10:03 PM Martin Perina  wrote:
>
>>
>>
>> On Tue, 5 Feb 2019, 14:54 Misak Khachatryan >
>>> Hi,
>>>
>>> I've successfully upgraded to 4.3, but when I'm trying to upgrade
>>> Cluster version I'm getting this:
>>>
>>> "Error while executing action: Cannot change Cluster Compatibility
>>> Version to higher version when there are active Hosts with lower version.
>>> -Please move Host virt2 with lower version to maintenance first."
>>>
>>
>> It seems that on host virt2 you have installed VDSM which doesn't support
>> higher cluster version. Please try to upgrade the host before upgrading the
>> cluster.
>>
>>
>>> Any clues?
>>>
>>> Best regards,
>>> Misak Khachatryan
>>> ___
>>> Users mailing list -- users@ovirt.org
>>> To unsubscribe send an email to users-le...@ovirt.org
>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>>> oVirt Code of Conduct:
>>> https://www.ovirt.org/community/about/community-guidelines/
>>> List Archives:
>>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/6R64SOEIYXFGTDTWOWZDHREJDUKL6IEP/
>>>
>>

-- 
Martin Perina
Associate Manager, Software Engineering
Red Hat Czech s.r.o.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/CDDTOYVVNP7L4RHQADZOVFDIRTCUORC5/

[ovirt-users] Re: Cluster upgrade

2019-02-07 Thread Misak Khachatryan

Thanks Martin,

you are right, on all hosts which i did upgrade ovirt-4.3 repo is not
present. Seems like a bug.

Best regards,
Misak Khachatryan


On Tue, Feb 5, 2019 at 10:03 PM Martin Perina  wrote:

>
>
> On Tue, 5 Feb 2019, 14:54 Misak Khachatryan 
>> Hi,
>>
>> I've successfully upgraded to 4.3, but when I'm trying to upgrade Cluster
>> version I'm getting this:
>>
>> "Error while executing action: Cannot change Cluster Compatibility
>> Version to higher version when there are active Hosts with lower version.
>> -Please move Host virt2 with lower version to maintenance first."
>>
>
> It seems that on host virt2 you have installed VDSM which doesn't support
> higher cluster version. Please try to upgrade the host before upgrading the
> cluster.
>
>
>> Any clues?
>>
>> Best regards,
>> Misak Khachatryan
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/6R64SOEIYXFGTDTWOWZDHREJDUKL6IEP/
>>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/KWLDFPZOFGMYBFDZMBDQ3OVRRLX27NLC/

[ovirt-users] Gluster version on oVirt 4.3.0

2019-02-07 Thread suporte

Hi, 

What Glusterfs version should I use with oVirt 4.3.0 ? 

Thanks 

-- 

Jose Ferradeira 
http://www.logicworks.pt 
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/Z7ZZO5DES3HZEAYYUVEJHNTVVMSTOUPB/

[ovirt-users] vm autostart and priorities

Hi,

I'm migrating my VM's to oVirt from ESXI and I've only got one left on the
ESXi side - a VM which provides me DNS, mail and DHCP services. Without
this VM's, I can't access the internet.

The only issue that prevents me from migrating this VM to oVirt and "kill"
the ESXi machine, is that I need to start this VM's upon oVirt node power
up (auto start), so if the power goes down and comes back, I'll have my
infrastructure up and running automatically within minutes.

Is there a way to auto start specific VM's or better - start VM's based on
specific orders upon boot of the nodes? I think it's a very important
feature.

Thanks
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/NJLGLSOTMNUCHPZ7WOLKCWY4ZVSMKMAD/

[ovirt-users] oVirt + GlusterFS over FCoE

2019-02-07 Thread Николаев Алексей

Hi community! Is it possibly to use oVirt with GlusterFS over FCoE with instruction https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/html-single/administration_guide/#How_to_Set_Up_RHVM_to_Use_FCoE?   ___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/CQEUFPAKOXQF4OTTVS5VNQ6ZFMKGRWFU/

[ovirt-users] Re: upgrade bug

2019-02-07 Thread Dominik Holler

On Thu, 7 Feb 2019 09:48:39 +0200
ada per  wrote:

> Thank you for your help.
> 
> You were right, it the filtering issue thats causing the failed start.
> 

Thank you very much for the feedback and checking this.

> Even newly created networks under 7.2.8 still have the network filter by
> default.
> 

External networks should have no filter, let's figure this out in
https://bugzilla.redhat.com/1671739


> THANKS :)
> 
> On Sat, Feb 2, 2019 at 4:52 PM Dominik Holler  wrote:
> 
> > On Sat, 2 Feb 2019 12:53:13 +0200
> > ada per  wrote:
> >
> > > Thank you for your reply :).
> > >
> > > I don't think is the network filters, i have also created a new OVN
> > > network to check but still the vm dont boot-up on the hosts that have
> > > been upgraded.
> > >
> >
> > Can you please share the vdsm.log from a host after a failed start?
> >
> > >
> > > On Fri, 1 Feb 2019, 21:56 Dominik Holler  > >
> > > > On Fri, 1 Feb 2019 15:31:18 +0200
> > > > ada per  wrote:
> > > >
> > > > > After upgrading my hosts from 4.2.7.1 to 4.2.8 the external
> > > > > networks stopped working!
> > > > > When im starting a VM using external network it does not boot up
> > > > > at all!
> > > > >
> > > > > The error message is:
> > > > > "VM  is down with error. Exit message: unsupported configuration:
> > > > > filterref is not supported for network interfaces with virtualport
> > > > > type openvswitch"
> > > > >
> > > >
> > > > Can you please ensure that the vNIC profiles of the external network
> > > > has no network filter?
> > > > Please find details in https://bugzilla.redhat.com/1502754 .
> > > > The default setting for new created OVN networks should be
> > > > "No Network Filter", but there might be old networks which still
> > > > have an network filter.
> > > >
> > > > > I rolled it back to 4.2.7.1 for 1 of my hosts just as a test and
> > > > > the VMs on that host can now bootup using external networks as
> > > > > they are supposed to!!
> > > > >
> > > > > Please advice as i would like to use the upgrade!!!
> > > >
> > > >
> >
> >
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/XRRQSYYVHZJMNMFBUFYNP32RUSMYKPOZ/

[ovirt-users] Re: ovirt-node-4.3, deployment fails when moving hosted engine vm to gluster storage.