date:20190206

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?
>

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/B6AKM6MQVNYLVBEXYXENLYY325OVEJMD/

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

Il giorno gio 7 feb 2019 alle ore 07:09 Robert Crawford <
robert.crawford4.14...@gmail.com> ha scritto:

> So I've checked the "Use CloudInit/Sysprep" and set the root user &
> password but it doesn't seem to apply.
>
> I can't login after setting it and also running "Run Once" as well.
>

Can you please open a bug on
https://bugzilla.redhat.com/enter_bug.cgi?classification=oVirt  so we can
track this?
Please provide steps to reproduce this, in particular which CentOS image
you used.


> ___
> 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/K6Z7YRD4QTAESJ7KTTAGFVH7R7WKO5LO/
>


-- 

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/3JZV6ACAL433QZRYZ3PU4GVHZS75ZMG6/

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

2019-02-06 Thread Ryan Bullock

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/

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

So I've checked the "Use CloudInit/Sysprep" and set the root user & password 
but it doesn't seem to apply. 

I can't login after setting it and also running "Run Once" as well. 
___
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/K6Z7YRD4QTAESJ7KTTAGFVH7R7WKO5LO/

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

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/

[ovirt-users] ovirt-node 4.3 hyperconverged - fails on VM deployment - all nodes broken

Boring 3 vanilla node deployment. Default options except for gluster volume
size. All three nodes on static IP on LAN. All three have each other listed
in /etc/hosts as well as dns.
Gluster wizard complete successfully, deploy VM. VM deployment fails after
copying to the gluster storage. At that point, rebooting any node results
in node not coming back to life. No networking, so no other services.
Only error I can get is to check the engine.log, which I cannot do as the
engine fails to come up.

Anyone else seeing this with a vanilla install/deployment?

-- 
_
Fact:
1. Ninjas are mammals.
2. Ninjas fight ALL the time.
3. The purpose of the ninja is to flip out and kill people.
___
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/4QDZX5DK4VC6LPGS3SOM2NR6KFW7QUA6/

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

2019-02-06 Thread Sahina Bose

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/X2IQYD3HK367RWAY5VMFDXZPPT4G33KF/

[ovirt-users] Re: ovirt-node 4.2 iso - hyperconverged wizard doesn't write gdeployConfig settings

2019-02-06 Thread Sachidananda URS

Hi,

On Thu, Feb 7, 2019 at 9:27 AM Sahina Bose  wrote:

> +Sachidananda URS to review user request about systemd mount files
>
> On Tue, Feb 5, 2019 at 10:22 PM feral  wrote:
> >
> > Using SystemD makes way more sense to me. I was just trying to use
> ovirt-node as it was ... intended? Mainly because I have no idea how it all
> works yet, so I've been trying to do the most stockish deployment possible,
> following deployment instructions and not thinking I'm smarter than the
> software :p.
> > I've given up on 4.2 for now, as 4.3 was just released, so giving that a
> try now. Will report back. Hopefully 4.3 enlists systemd for stuff?
> >
>


Unless we have really complicated mount setup, it is better to use fstab.
We had certain difficulties while using vdo, maybe for such cases?

However the systemd.mount(5) manpage suggests that the preferred way of
mount configuration
should be /etc/fstab.

src:
https://manpages.debian.org/jessie/systemd/systemd.mount.5.en.html#/ETC/FSTAB


/ETC/FSTAB

Mount units may either be configured via unit files, or via /etc/fstab
(seefstab(5) for details). Mounts listed in /etc/fstab will be converted
into native units dynamically at boot and when the configuration of the
system manager is reloaded. In general, configuring mount points through
/etc/fstab is the preferred approach. See systemd-fstab-generator(8) for
details about the conversion.



> > On Tue, Feb 5, 2019 at 4:33 AM Strahil Nikolov 
> wrote:
> >>
> >> Dear Feral,
> >>
> >> >On that note, have you also had issues with gluster not restarting on
> reboot, as well as >all of the HA stuff failing on reboot after power loss?
> Thus far, the only way I've got the >cluster to come back to life, is to
> manually restart glusterd on all nodes, then put the >cluster back into
> "not mainentance" mode, and then manually starting the hosted-engine vm.
> >This also fails after 2 or 3 power losses, even though the entire cluster
> is happy through >the first 2.
> >>
> >>
> >> About the gluster not starting - use systemd.mount unit files.
> >> here is my setup and for now works:
> >>
> >> [root@ovirt2 yum.repos.d]# systemctl cat gluster_bricks-engine.mount
> >> # /etc/systemd/system/gluster_bricks-engine.mount
> >> [Unit]
> >> Description=Mount glusterfs brick - ENGINE
> >> Requires = vdo.service
> >> After = vdo.service
> >> Before = glusterd.service
> >> Conflicts = umount.target
> >>
> >> [Mount]
> >> What=/dev/mapper/gluster_vg_md0-gluster_lv_engine
> >> Where=/gluster_bricks/engine
> >> Type=xfs
> >> Options=inode64,noatime,nodiratime
> >>
> >> [Install]
> >> WantedBy=glusterd.service
> >> [root@ovirt2 yum.repos.d]# systemctl cat
> gluster_bricks-engine.automount
> >> # /etc/systemd/system/gluster_bricks-engine.automount
> >> [Unit]
> >> Description=automount for gluster brick ENGINE
> >>
> >> [Automount]
> >> Where=/gluster_bricks/engine
> >>
> >> [Install]
> >> WantedBy=multi-user.target
> >> [root@ovirt2 yum.repos.d]# systemctl cat glusterd
> >> # /etc/systemd/system/glusterd.service
> >> [Unit]
> >> Description=GlusterFS, a clustered file-system server
> >> Requires=rpcbind.service gluster_bricks-engine.mount
> gluster_bricks-data.mount gluster_bricks-isos.mount
> >> After=network.target rpcbind.service gluster_bricks-engine.mount
> gluster_bricks-data.mount gluster_bricks-isos.mount
> >> Before=network-online.target
> >>
> >> [Service]
> >> Type=forking
> >> PIDFile=/var/run/glusterd.pid
> >> LimitNOFILE=65536
> >> Environment="LOG_LEVEL=INFO"
> >> EnvironmentFile=-/etc/sysconfig/glusterd
> >> ExecStart=/usr/sbin/glusterd -p /var/run/glusterd.pid  --log-level
> $LOG_LEVEL $GLUSTERD_OPTIONS
> >> KillMode=process
> >> SuccessExitStatus=15
> >>
> >> [Install]
> >> WantedBy=multi-user.target
> >>
> >> # /etc/systemd/system/glusterd.service.d/99-cpu.conf
> >> [Service]
> >> CPUAccounting=yes
> >> Slice=glusterfs.slice
> >>
> >>
> >> Best Regards,
> >> Strahil Nikolov
> >
> >
> >
> > --
> > _
> > Fact:
> > 1. Ninjas are mammals.
> > 2. Ninjas fight ALL the time.
> > 3. The purpose of the ninja is to flip out and kill people.
> > ___
> > 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/G4AE6YQHYL7XBTYNCLQPFQY6CY6C7YGX/
>
___
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/JMBK3F3LGTYUQ4MAS7GP5JM2ONTY7HCT/

[ovirt-users] Re: ovirt-node 4.2 iso - hyperconverged wizard doesn't write gdeployConfig settings

2019-02-06 Thread Sahina Bose

+Sachidananda URS to review user request about systemd mount files

On Tue, Feb 5, 2019 at 10:22 PM feral  wrote:
>
> Using SystemD makes way more sense to me. I was just trying to use ovirt-node 
> as it was ... intended? Mainly because I have no idea how it all works yet, 
> so I've been trying to do the most stockish deployment possible, following 
> deployment instructions and not thinking I'm smarter than the software :p.
> I've given up on 4.2 for now, as 4.3 was just released, so giving that a try 
> now. Will report back. Hopefully 4.3 enlists systemd for stuff?
>
> On Tue, Feb 5, 2019 at 4:33 AM Strahil Nikolov  wrote:
>>
>> Dear Feral,
>>
>> >On that note, have you also had issues with gluster not restarting on 
>> >reboot, as well as >all of the HA stuff failing on reboot after power loss? 
>> >Thus far, the only way I've got the >cluster to come back to life, is to 
>> >manually restart glusterd on all nodes, then put the >cluster back into 
>> >"not mainentance" mode, and then manually starting the hosted-engine vm. 
>> >>This also fails after 2 or 3 power losses, even though the entire cluster 
>> >is happy through >the first 2.
>>
>>
>> About the gluster not starting - use systemd.mount unit files.
>> here is my setup and for now works:
>>
>> [root@ovirt2 yum.repos.d]# systemctl cat gluster_bricks-engine.mount
>> # /etc/systemd/system/gluster_bricks-engine.mount
>> [Unit]
>> Description=Mount glusterfs brick - ENGINE
>> Requires = vdo.service
>> After = vdo.service
>> Before = glusterd.service
>> Conflicts = umount.target
>>
>> [Mount]
>> What=/dev/mapper/gluster_vg_md0-gluster_lv_engine
>> Where=/gluster_bricks/engine
>> Type=xfs
>> Options=inode64,noatime,nodiratime
>>
>> [Install]
>> WantedBy=glusterd.service
>> [root@ovirt2 yum.repos.d]# systemctl cat gluster_bricks-engine.automount
>> # /etc/systemd/system/gluster_bricks-engine.automount
>> [Unit]
>> Description=automount for gluster brick ENGINE
>>
>> [Automount]
>> Where=/gluster_bricks/engine
>>
>> [Install]
>> WantedBy=multi-user.target
>> [root@ovirt2 yum.repos.d]# systemctl cat glusterd
>> # /etc/systemd/system/glusterd.service
>> [Unit]
>> Description=GlusterFS, a clustered file-system server
>> Requires=rpcbind.service gluster_bricks-engine.mount 
>> gluster_bricks-data.mount gluster_bricks-isos.mount
>> After=network.target rpcbind.service gluster_bricks-engine.mount 
>> gluster_bricks-data.mount gluster_bricks-isos.mount
>> Before=network-online.target
>>
>> [Service]
>> Type=forking
>> PIDFile=/var/run/glusterd.pid
>> LimitNOFILE=65536
>> Environment="LOG_LEVEL=INFO"
>> EnvironmentFile=-/etc/sysconfig/glusterd
>> ExecStart=/usr/sbin/glusterd -p /var/run/glusterd.pid  --log-level 
>> $LOG_LEVEL $GLUSTERD_OPTIONS
>> KillMode=process
>> SuccessExitStatus=15
>>
>> [Install]
>> WantedBy=multi-user.target
>>
>> # /etc/systemd/system/glusterd.service.d/99-cpu.conf
>> [Service]
>> CPUAccounting=yes
>> Slice=glusterfs.slice
>>
>>
>> Best Regards,
>> Strahil Nikolov
>
>
>
> --
> _
> Fact:
> 1. Ninjas are mammals.
> 2. Ninjas fight ALL the time.
> 3. The purpose of the ninja is to flip out and kill people.
> ___
> 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/G4AE6YQHYL7XBTYNCLQPFQY6CY6C7YGX/
___
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/OU3HJYDT5P4ZQ2WJT7AS6URPEVTC4LRJ/

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

2019-02-06 Thread Edward Berger

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.

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.

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/

[ovirt-users] Re: performance issues with Windows 10

2019-02-06 Thread Nir Soffer

On Tue, Feb 5, 2019 at 3:58 PM Hetz Ben Hamo  wrote:

> Hi,
>
> I'm doing some very simple disk benchmarks on Windows 10, both with ESXI
> 6.7 and oVirt 4.3.0.
> Both Windows 10 Pro guests have all the driver installed.
> the "Storage" (Datastore in VMWare and storage domains in oVirt) comes
> from the same ZFS machine, both mounted as NFS *without* any parameters
> for NFS mount.
> The ESXI is running on HP DL360 G7 with E5620 CPU, while the oVirt node is
> running on IBM X3550 M3 with dual Xeon E5620. There are no memory issues as
> both machines have plenty of free memory and free CPU resources.
>
> Screenshots:
>
> - Windows 10 in vSphere 6.7 -  https://imgur.com/V75ep2n
> - Windows 10 in oVirt 4.3.0 - https://imgur.com/3JDrWLx
>
> As you can see, while oVirt lags a bit in 4K Read, the write performance
> is really bad.
>

382 MiB/s vs 54 MiBs? smells like someone is cheating :-)

Maybe VMWare is using buffered I/O, so you test writing to the host buffer
cache,
while oVirt is using cache=none, and actually writing to the remote storage.
But this is only a wild guess, we need much more details.

Lets start by getting more details about your setup, so we can reproduce it
in our lab.

- What is the network topology?
- Spec of the NFS server?
- Configuration of the VM on both oVirt and VMWare.
- How do you test? how much data is written during the test?
- How it compares to running the same tests on the hypervisor?

For oVirt, getting the VM XML would be helpful - try:

Find the vm id:

sudo virsh -r list

Dump the xml:

sudo virsh -r dumpxml N

For testing, you should probably use fio:
https://bluestop.org/fio/

Added people who can help to diagnose this or at least ask better questions.

Nir
___
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/PD63I247C7L7PAA5BXXE4UVG77RS2JJP/

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

2019-02-06 Thread Brian T

Hi, thank you for the swift response!

That's true, haha!

Currently, we are looking to incorporate an RDP solution (Mechdyne TGX) into 
the VM portal for our users. The current "workaround" is pasting the VM's IP 
address in the description or comment section and having the end-user run TGX 
separately.

My proposed idea would be (Correct me if I'm wrong):
1) Create a new Button or option from "Console" labelled something like 
"Console with TGX"
2) Upon hitting this button, make a REST API call to obtain the VM's IPv4 
address.
3) Launch Mechdyne TGX, slotting in the IPv4 address obtained

There's more than one way to achieve this, and I guess I'm looking for any 
suggestions or a place to start. I understand that this use case is not a 
universal improvement for a lot of oVirt users (Hence why I thought it would be 
a more personal modification!), but I can see a use for allowing other RDP 
solutions as well.
___
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/XN6OEWENCSMZXZQVML75FGTA2WKYMCHP/

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

On Wed, Feb 6, 2019 at 5:29 PM Brian T 
wrote:

> Hi all,
>
> I'm pretty new to using oVirt; it's been a couple of months since I've
> installed it. I apologize if this question has been answered; I've been
> digging around for a straight answer.
>
> As the title suggest, is it possible to customize the web-ui/User
> Portal/VM Portal portion of oVirt? I know the web-ui portion seems
> completely separate from WebAdmin. Based on the documentation and what I
> can scrounge up, web-ui was made with React and Patternfly? I would love to
> tinker with adding more features to our VM Portal; thank you!
>

This is great to hear :) Would you mind sharing your ideas? We have some
pretty cool stuff going on right now, and we would love contributions from
the community! You are welcome to join the project at any time. Enhancing
it for yourself would be cool, but enhancing it for everyone would be even
better :D

Yes, it's written in react and uses PatternFly for most of the look. It's a
pretty typical react / redux application and uses redux-saga. There is
limited branding functionality if you're looking to change colors and logos
and such. If you want to do more than that, it requires some JavaScript
code.

We do all of the work in https://github.com/oVirt/ovirt-web-ui/
Additionally, our design work lives in
https://drive.google.com/open?id=1JHhQfi32uZd7V8XpoIcdNIUIZd-tmV9I

Feel free to browse the code, the issues list, and the designs, and let me
know your thoughts.

Best wishes,
Greg

> ___
> 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/L5B2NGLZCJNWOWKEBKXVSXILR547PJUU/
>

-- 

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/7BECI226JML3IAMPWQVL23IP2YYKA7U3/

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

2019-02-06 Thread Brian T

Hi all,

I'm pretty new to using oVirt; it's been a couple of months since I've 
installed it. I apologize if this question has been answered; I've been digging 
around for a straight answer.

As the title suggest, is it possible to customize the web-ui/User Portal/VM 
Portal portion of oVirt? I know the web-ui portion seems completely separate 
from WebAdmin. Based on the documentation and what I can scrounge up, web-ui 
was made with React and Patternfly? I would love to tinker with adding more 
features to our VM Portal; thank you!
___
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/L5B2NGLZCJNWOWKEBKXVSXILR547PJUU/

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

Update, when the node is rebooted, it fails with "timed out waiting for
device dev-gluster_vg_vdb-gluster_lv_data.device
The node also has no networking online, which is probably the cause of the
gluster failure.

On Wed, Feb 6, 2019 at 2:04 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
> storage, but as soon as it starts doing so, the VM never comes back online.
>
>
> --
> _
> Fact:
> 1. Ninjas are mammals.
> 2. Ninjas fight ALL the time.
> 3. The purpose of the ninja is to flip out and kill people.
>


-- 
_
Fact:
1. Ninjas are mammals.
2. Ninjas fight ALL the time.
3. The purpose of the ninja is to flip out and kill people.
___
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/NBBBT25VZDO5EXUKFUE2HUALDLVSAROB/

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

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 storage, but as
soon as it starts doing so, the VM never comes back online.


-- 
_
Fact:
1. Ninjas are mammals.
2. Ninjas fight ALL the time.
3. The purpose of the ninja is to flip out and kill people.
___
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/LAM3TX64UQOOO7A2WBMGZUEF4TVFHXJA/

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

On Wed, Feb 6, 2019 at 4:15 PM Robert Crawford <
robert.crawford4.14...@gmail.com> wrote:

> I did try 1901 earlier, also it does eventually boot.
>

I'm not familiar with 1901 - afaik 1810 is the latest release.


>
> 1810 does not appear in the ISO domain
>

You (or an administrator) can upload it there. You can also upload ISOs to
any data domain, too, using the disk upload.
https://ovirt.org/documentation/admin-guide/chap-Storage.html#uploading-images-to-a-data-storage-domain
Storage > Disks


> ___
> 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/UZ7DH5M4C57FX3AYH2E5O2JM5JCQCIUC/
>


-- 

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/G66IBRPPI55XVW6LP7KCXWOMNO6BTIIB/

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

I did try 1901 earlier, also it does eventually boot. 

1810 does not appear in the ISO domain 
___
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/UZ7DH5M4C57FX3AYH2E5O2JM5JCQCIUC/

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

By any chance did you try latest, 1810?

On Wed, Feb 6, 2019 at 3:42 PM Robert Crawford <
robert.crawford4.14...@gmail.com> wrote:

> On 4.3.0 with the 1809 CentOS image from the ISO Domain the VM Guest will
> fail to boot and freeze on initialized qxl 0.1.0
> ___
> 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/LSIDIR37DWDKXAY3GQUF7LAJWOJUT4VJ/
>


-- 

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/MG3Y33IIZZLUS3GU4PHXLZCFGZ2FJKEG/

[ovirt-users] Re: Suggestions on adding 1000 or more networks to an engine/hosts

2019-02-06 Thread Brian Wilson

Another thing i was looking at now was trying to add the networks to a label 
thats not on a NIC and then add the label. 


Adding the Networks works well in-fact i added 1500 of them with no issue.

Then I moved the new label to the nic and watched as it begin to add the 
interfaces, i watched it and saw that it got to about 300 Interfaces before the 
UI Timed out with the error:

Operation Cancelled
Error while executing action HostSetupNetworks: Network error during 
communication with the Host.


In the Engine The Log looks like this - since there were so many networks in 
the message to add them i truncated that section - they are all the same 
settings on each network



2019-02-06 21:34:43,932+01 ERROR 
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default 
task-25) [c12f3f58-ef87-4a82-9248-e79d4c625edc] EVENT_ID: 
VDS_BROKER_COMMAND_FAILURE(10,802), VDSM u90c10aio01.cisco.com command 
HostSetupNetworksVDS failed: Message timeout which can be caused by 
communication issues
2019-02-06 21:34:43,939+01 ERROR 
[org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand] 
(default task-25) [c12f3f58-ef87-4a82-9248-e79d4c625edc] Command 
'HostSetupNetworksVDSCommand(HostName = u90c10aio01.cisco.com, 
HostSetupNetworksVdsCommandParameters:{hostId='509f5298-00df-4f74-9a2b-c95836442e60',
 vds='Host[u90c10aio01.cisco.com,509f5298-00df-4f74-9a2b-c95836442e60]', 
rollbackOnFailure='true', connectivityTimeout='120', 
networks='[HostNetwork:{defaultRoute='false', bonding='false', 
networkName='u90aio001-1502', vdsmName='u90aio001-1502', nicName='eno1', 
vlan='1502', vmNetwork='true', stp='false', properties='null', 
ipv4BootProtocol='NONE', ipv4Address='null', ipv4Netmask='null', 
ipv4Gateway='null', ipv6BootProtocol='NONE', ipv6Address='null', 
ipv6Prefix='null', ipv6Gateway='null', nameServers='null'}, 
HostNetwork:{defaultRoute='false', bonding='false', 
networkName='u90aio001-1503', vdsmName='u90aio001-1503', nicName='eno1', 
vlan='1503', vmNetwork='true', stp='fals
 e', properties='null', ipv4BootProtocol='NONE', ipv4Address='null', 
ipv4Netmask='null', ipv4Gateway='null', ipv6BootProtocol='NONE', 
ipv6Address='null', ipv6Prefix='null', ipv6Gateway='null', nameServers='null'}, 
HostNetwork:{defaultRoute='false', bonding='false', 
networkName='u90aio001-1504', vdsmName='u90aio001-1504', nicName='eno1', 
vlan='1504', vmNetwork='true', stp='false', properties='null', 
ipv4BootProtocol='NONE', ipv4Address='null', ipv4Netmask='null', 
ipv4Gateway='null', ipv6BootProtocol='NONE', 

..truncated...

ipv6Prefix='null', ipv6Gateway='null', nameServers='null'}, 
HostNetwork:{defaultRoute='false', bonding='false', 
networkName='u90aio001-2998', vdsmName='u90aio001-2998', nicName='eno1', 
vlan='2998', vmNetwork='true', stp='false', properties='null', 
ipv4BootProtocol='NONE', ipv4Address='null', ipv4Netmask='null', 
ipv4Gateway='null', ipv6BootProtocol='NONE', ipv6Address='null', 
ipv6Prefix='null', ipv6Gateway='null', nameServers='null'}, 
HostNetwork:{defaultRoute='false', bonding='false', 
networkName='u90aio001-2999', vdsmName='u90aio001-2999', nicName='eno1', 
vlan='2999', vmNetwork='true', stp='false', properties='null', 
ipv4BootProtocol='NONE', ipv4Address='null', ipv4Netmask='null', 
ipv4Gateway='null', ipv6BootProtocol='NONE', ipv6Address='null', 
ipv6Prefix='null', ipv6Gateway='null', nameServers='null'}, 
HostNetwork:{defaultRoute='false', bonding='false', 
networkName='u90aio001-3000', vdsmName='u90aio001-3000', nicName='eno1', 
vlan='3000', vmNetwork='true', stp='false', properties='n
 ull', ipv4BootProtocol='NONE', ipv4Address='null', ipv4Netmask='null', 
ipv4Gateway='null', ipv6BootProtocol='NONE', ipv6Address='null', 
ipv6Prefix='null', ipv6Gateway='null', nameServers='null'}]', 
removedNetworks='[]', bonds='[]', removedBonds='[]', 
clusterSwitchType='LEGACY'})' execution failed: VDSGenericException: 
VDSNetworkException: Message timeout which can be caused by communication issues
2019-02-06 21:34:43,942+01 ERROR 
[org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand] 
(default task-25) [c12f3f58-ef87-4a82-9248-e79d4c625edc] Error: 
VDSGenericException: VDSNetworkException: Message timeout which can be caused 
by communication issues
2019-02-06 21:34:43,942+01 ERROR 
[org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand] (default 
task-25) [c12f3f58-ef87-4a82-9248-e79d4c625edc] Command 
'org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand' failed: 
EngineException: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException: 
VDSGenericException: VDSNetworkException: Message timeout which can be caused 
by communication issues (Failed with error VDS_NETWORK_ERROR and code 5022)
___
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:

[ovirt-users] qxl issue on OVirt 4.3.0

On 4.3.0 with the 1809 CentOS image from the ISO Domain the VM Guest will fail 
to boot and freeze on initialized qxl 0.1.0
___
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/LSIDIR37DWDKXAY3GQUF7LAJWOJUT4VJ/

[ovirt-users] Re: Strange behavior when changing memory and virtual cpu for VM

2019-02-06 Thread Pavel Novotny

On 06. 02. 19 12:03, matthias.barme...@sourcepark.de wrote:

Hi,

after creating a VM from a template everything works fine. After a while I would like to
increase memory and cpus. I changed the memory and virtual cpu settings in the
"System" settings.
I restarted the VM.

From this moment on the VM hangs on boot with this messages filling the
console:

Hi Matthias,

it is really strange that update of the VM memory or CPU settings would
trigger this cloud-init behavior inside the VM.

I would focus more on what's been happening with the VM after its
creation and before the restart.

Few ideas and questions:
- Is it possible that the cloud-init has been installed or enabled later
after the VM creation?
- Is the VM from pool? If yes, were there some changes made to the
template, e.g., new sub-versions created, before the VM was restarted?

url_helper.py[WARNING]: Calling
'http://169.254.169.254/2009-04-04/meta-data/instance-id' Connection to
169.254.169.254 timed out.
This means that the cloud-init service running on your VM is trying to
reach the EC2 datasource[1]:

https://cloudinit.readthedocs.io/en/latest/topics/datasources/ec2.html

I am not familiar with cloud-init on Debian but there should be 120
seconds default timeout to wait for the 169.254.169.254 address to
return something,

it definitely should not wait forever.

This goes on for ever. What can I do to make the VM work again ? I tried to
restore the settings to the values it has before but this does not help.
The VM contains debian 9 (stretch) with cloud init. Ovirt version: 4.2.7.5-1.el7

Ciao
Matze
___
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/BCVGAAKBBX53YBDHXWZ6VBJJNPUAM52V/

--
Pavel Novotny
Red Hat Virtualization Quality Engineer
Red Hat Czech
___
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/HUQTI24SLWUCHDFX4CQIBBCD7LUR2L76/

[ovirt-users] Re: ovirt 4.2.7 -> 4.3.0 upgrade process

2019-02-06 Thread Douglas Duckworth

Thanks everyone!

We will try the upgrade to 4.2.8 then try 4.3 later.


Thanks,

Douglas Duckworth, MSc, LFCS
HPC System Administrator
Scientific Computing Unit
Weill Cornell Medicine
1300 York Avenue
New York, NY 10065
E: d...@med.cornell.edu
O: 212-746-6305
F: 212-746-8690


On Wed, Feb 6, 2019 at 11:56 AM Sandro Bonazzola 
mailto:sbona...@redhat.com>> wrote:


Il giorno mer 6 feb 2019 alle ore 17:28 Douglas Duckworth 
mailto:dod2...@med.cornell.edu>> ha scritto:
Hello

Can anyone confirm that the steps for upgrading to 4.3 from 4.2 are the same as 
listed for previous versions?

I reviewed 4.1 to 4.2 which looks straight forward:

https://www.ovirt.org/documentation/upgrade-guide/chap-Upgrading_from_4.1_to_oVirt_4.2.html

I am sure nothing will go wrong though we are doing daily backups of the hosted 
engine VM database.

If you are on 4.2.7 I would recommend upgrade the engine to 4.2.8 before 
upgrading to 4.3.
Since in 4.3 we switched from fluentd to rsyslog for the metrics part, with 
4.2.7 you may have some issue if you upgrade hosts to 4.3 before the engine 
gets upgraded.





Thanks,

Douglas Duckworth, MSc, LFCS
HPC System Administrator
Scientific Computing Unit
Weill Cornell Medicine
1300 York Avenue
New York, NY 10065
E: d...@med.cornell.edu
O: 212-746-6305
F: 212-746-8690
___
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/VC2TVZIHTOTMZOKWBN7VOY2H3FQGTQS3/


--

SANDRO BONAZZOLA

MANAGER, SOFTWARE ENGINEERING, EMEA R RHV

Red Hat 
EMEA

sbona...@redhat.com

[https://www.redhat.com/files/brand/email/sig-redhat.png]
___
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/4T25GIPR7SHXXKBVEWNFO2S3YOSZ6JCE/

[ovirt-users] Re: sun.security.validator

2019-02-06 Thread Ravi Shankar Nori

On Wed, Feb 6, 2019 at 11:18 AM Greg Sheremeta  wrote:

> Ravi, can you assist?
>
> Greg
>
>
> On Tue, Feb 5, 2019 at 8:39 PM  wrote:
>
>> Did you ever get an answer to this?  I am experiencing the same issue
>> after:
>>
>> 1) Updating the BIOS on my system to the latest one
>> 2) Installing a new 10GbE NIC
>>
>> Both the BIOS update and the NIC installation completed without incident,
>> but I am getting the exact same error.
>>
>> Any advice out there?
>> __
>
>

If you are not using custom certificates check the FQDN of the host and run
engine-setup again.

If you are using custom certificates you can follow the steps in oVirt blog
[1]

[1] https://www.ovirt.org/documentation/admin-guide/appe-oVirt_and_SSL.html


> _
>> 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/6CSADXLGCOMYYC22ZJEQ46EBOINK257H/
>>
>
>
> --
>
> 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/MC42TO5TLPJLW5RO2RUROLGLDFRGRJ4Q/

[ovirt-users] Re: Spice console very poor performance for Windows 10 vm

2019-02-06 Thread Leo David

Hello everyone,
Any chance that this issue to be already fixed in the new 4.3 version ?
Thank you !

On Tue, Jan 8, 2019, 12:25 Victor Toso  Hi,
>
> On Tue, Jan 08, 2019 at 12:08:31PM +0200, Leo David wrote:
> > Thank you very mucjh,  and sorry for being so lazy to search
> > for that rpm by myself. Somehow, fedora rpms missed from my
> > mind.  Oh boy, it requires a lot of packages. Do you think
> > would it be a good idea to temporarily install fedora repos, do
> > the yum installation to get the dependencoes too and then
> > disable the repo ? I am thinking to not break the ovirt node
> > installation.
>
> The easiest path is to get the source from your current rpm,
> apply the patch mentioned in previous email, build, install,
> test.
>
> If that does not work you can rollback. If works, you can rethink
> what is best.
>
> Cheers,
>
> >  yum localinstall spice-server-0.14.1-1.fc30.x86_64.rpm
> > Loaded plugins: enabled_repos_upload, fastestmirror, imgbased-persist,
> > package_upload, product-id, search-disabled-repos, subscription-manager,
> > vdsmupgrade
> > This system is not registered with an entitlement server. You can use
> > subscription-manager to register.
> > Examining spice-server-0.14.1-1.fc30.x86_64.rpm:
> > spice-server-0.14.1-1.fc30.x86_64
> > Marking spice-server-0.14.1-1.fc30.x86_64.rpm as an update to
> > spice-server-0.14.0-2.el7_5.3.x86_64
> > Resolving Dependencies
> > --> Running transaction check
> > ---> Package spice-server.x86_64 0:0.14.0-2.el7_5.3 will be updated
> > ---> Package spice-server.x86_64 0:0.14.1-1.fc30 will be an update
> > --> Processing Dependency: libcrypto.so.1.1(OPENSSL_1_1_0)(64bit) for
> > package: spice-server-0.14.1-1.fc30.x86_64
> > Loading mirror speeds from cached hostfile
> >  * epel: ftp.nluug.nl
> >  * ovirt-4.2-epel: ftp.nluug.nl
> > --> Processing Dependency: libssl.so.1.1(OPENSSL_1_1_0)(64bit) for
> package:
> > spice-server-0.14.1-1.fc30.x86_64
> > --> Processing Dependency: libcrypto.so.1.1()(64bit) for package:
> > spice-server-0.14.1-1.fc30.x86_64
> > --> Processing Dependency: libgstapp-1.0.so.0()(64bit) for package:
> > spice-server-0.14.1-1.fc30.x86_64
> > --> Processing Dependency: libgstbase-1.0.so.0()(64bit) for package:
> > spice-server-0.14.1-1.fc30.x86_64
> > --> Processing Dependency: libgstreamer-1.0.so.0()(64bit) for package:
> > spice-server-0.14.1-1.fc30.x86_64
> > --> Processing Dependency: libgstvideo-1.0.so.0()(64bit) for package:
> > spice-server-0.14.1-1.fc30.x86_64
> > --> Processing Dependency: liborc-0.4.so.0()(64bit) for package:
> > spice-server-0.14.1-1.fc30.x86_64
> > --> Processing Dependency: libssl.so.1.1()(64bit) for package:
> > spice-server-0.14.1-1.fc30.x86_64
> > --> Finished Dependency Resolution
> > Error: Package: spice-server-0.14.1-1.fc30.x86_64
> > (/spice-server-0.14.1-1.fc30.x86_64)
> >Requires: libgstvideo-1.0.so.0()(64bit)
> > Error: Package: spice-server-0.14.1-1.fc30.x86_64
> > (/spice-server-0.14.1-1.fc30.x86_64)
> >Requires: libgstbase-1.0.so.0()(64bit)
> > Error: Package: spice-server-0.14.1-1.fc30.x86_64
> > (/spice-server-0.14.1-1.fc30.x86_64)
> >Requires: libgstreamer-1.0.so.0()(64bit)
> > Error: Package: spice-server-0.14.1-1.fc30.x86_64
> > (/spice-server-0.14.1-1.fc30.x86_64)
> >Requires: libcrypto.so.1.1(OPENSSL_1_1_0)(64bit)
> > Error: Package: spice-server-0.14.1-1.fc30.x86_64
> > (/spice-server-0.14.1-1.fc30.x86_64)
> >Requires: liborc-0.4.so.0()(64bit)
> > Error: Package: spice-server-0.14.1-1.fc30.x86_64
> > (/spice-server-0.14.1-1.fc30.x86_64)
> >Requires: libcrypto.so.1.1()(64bit)
> > Error: Package: spice-server-0.14.1-1.fc30.x86_64
> > (/spice-server-0.14.1-1.fc30.x86_64)
> >Requires: libssl.so.1.1(OPENSSL_1_1_0)(64bit)
> > Error: Package: spice-server-0.14.1-1.fc30.x86_64
> > (/spice-server-0.14.1-1.fc30.x86_64)
> >Requires: libgstapp-1.0.so.0()(64bit)
> > Error: Package: spice-server-0.14.1-1.fc30.x86_64
> > (/spice-server-0.14.1-1.fc30.x86_64)
> >Requires: libssl.so.1.1()(64bit)
> >  You could try using --skip-broken to work around the problem
> >  You could try running: rpm -Va --nofiles --nodigest
> > Uploading Enabled Repositories Report
> > Loaded plugins: fastestmirror, product-id, subscription-manager
> > This system is not registered with an entitlement server. You can use
> > subscription-manager to register.
> > Cannot upload enabled repos report, is this client registered?
> >
> > Thank you  !
> >
> > Leo
> >
> > On Tue, Jan 8, 2019 at 10:19 AM Victor Toso 
> wrote:
> >
> > > Hi,
> > >
> > > On Mon, Jan 07, 2019 at 07:29:13PM +0200, Leo David wrote:
> > > > Thank you very much Victor,
> > > > Is there a rpm that I can easily install on all the nodes, or will I
> need
> > > > to build that version from sources ?
> > >
> > > You can fetch the release of 0.14.1 version at
> > > https://gitlab.freedesktop.org/spice/spice/tags
> > >
> > > You can fetch an rpm

[ovirt-users] Re: ovirt-4.3 hyperconverged deployment - no option for "disc count" for JBOD

On that note, this was already reported several times a few months back,
but apparently was fixed in gdeploy-2.0.2-29.el7rhgs.noarch. I'm guessing
ovirt-node-4.3 just hasn't updated to that version yet?

On Wed, Feb 6, 2019 at 8:51 AM feral  wrote:

> Bugzilla must have lost my account. Requesting password reset on an
> account that doesn't exist, results in 500 :p.
> Created a new one.
>
> However, my options for gdeploy version do not match the version 2.0.2
> installed. They only list 0.xx.x.
>
> On Wed, Feb 6, 2019 at 8:44 AM Greg Sheremeta  wrote:
>
>>
>> On Wed, Feb 6, 2019 at 11:31 AM feral  wrote:
>>
>>> Sorry, I tried opening a bug, but RH's Bugzilla is having issues and
>>> 500's out when I try to request password reset.
>>>
>>
>> Sorry to hear that. I hate to ask, but could you try after clearing
>> cookies for *redhat.com, or try in an incognito tab? It's done that to
>> me before and clearing cookies worked for me. If it still doesn't work,
>> I'll open the bug. Thanks!
>>
>>
>>>
>>>
>>> ---
>>> PLAY [gluster_servers]
>>> *
>>>
>>> TASK [Run a shell script]
>>> **
>>> changed: [ovirt-431.localdomain] =>
>>> (item=/usr/share/gdeploy/scripts/grafton-sanity-check.sh -d vdb -h
>>> ovirt-431.localdomain, ovirt-432.localdomain, ovirt-433.localdomain)
>>>
>>> PLAY RECAP
>>> *
>>> ovirt-431.localdomain  : ok=1changed=1unreachable=0
>>> failed=0
>>>
>>>
>>> PLAY [gluster_servers]
>>> *
>>>
>>> TASK [Run a shell script]
>>> **
>>> changed: [ovirt-432.localdomain] =>
>>> (item=/usr/share/gdeploy/scripts/grafton-sanity-check.sh -d vdb -h
>>> ovirt-431.localdomain, ovirt-432.localdomain, ovirt-433.localdomain)
>>>
>>> PLAY RECAP
>>> *
>>> ovirt-432.localdomain  : ok=1changed=1unreachable=0
>>> failed=0
>>>
>>>
>>> PLAY [gluster_servers]
>>> *
>>>
>>> TASK [Run a shell script]
>>> **
>>> changed: [ovirt-433.localdomain] =>
>>> (item=/usr/share/gdeploy/scripts/grafton-sanity-check.sh -d vdb -h
>>> ovirt-431.localdomain, ovirt-432.localdomain, ovirt-433.localdomain)
>>>
>>> PLAY RECAP
>>> *
>>> ovirt-433.localdomain  : ok=1changed=1unreachable=0
>>> failed=0
>>>
>>>
>>> PLAY [gluster_servers]
>>> *
>>>
>>> TASK [Create VDO with specified size]
>>> **
>>> changed: [ovirt-431.localdomain] => (item={u'disk': u'/dev/vdb',
>>> u'logicalsize': u'11000G', u'name': u'vdo_vdb'})
>>>
>>> PLAY RECAP
>>> *
>>> ovirt-431.localdomain  : ok=1changed=1unreachable=0
>>> failed=0
>>>
>>>
>>> PLAY [gluster_servers]
>>> *
>>>
>>> TASK [Create VDO with specified size]
>>> **
>>> changed: [ovirt-432.localdomain] => (item={u'disk': u'/dev/vdb',
>>> u'logicalsize': u'11000G', u'name': u'vdo_vdb'})
>>>
>>> PLAY RECAP
>>> *
>>> ovirt-432.localdomain  : ok=1changed=1unreachable=0
>>> failed=0
>>>
>>>
>>> PLAY [gluster_servers]
>>> *
>>>
>>> TASK [Create VDO with specified size]
>>> **
>>> changed: [ovirt-433.localdomain] => (item={u'disk': u'/dev/vdb',
>>> u'logicalsize': u'11000G', u'name': u'vdo_vdb'})
>>>
>>> PLAY RECAP
>>> *
>>> ovirt-433.localdomain  : ok=1changed=1unreachable=0
>>> failed=0
>>>
>>>
>>> PLAY [gluster_servers]
>>> *
>>>
>>> TASK [Enable or disable services]
>>> **
>>> ok: [ovirt-432.localdomain] => (item=chronyd)
>>> ok: [ovirt-431.localdomain] => (item=chronyd)
>>> ok: [ovirt-433.localdomain] => (item=chronyd)
>>>
>>> PLAY RECAP
>>> *
>>> ovirt-431.localdomain  : ok=1changed=0unreachable=0
>>> failed=0
>>> ovirt-432.localdomain  : ok=1changed=0unreachable=0
>>> failed=0
>>> ovirt-433.localdomain  : ok=1changed=0unreachable=0
>>> failed=0
>>>
>>>
>>> PLAY [gluster_servers]
>>> *
>>>
>>> TASK

[ovirt-users] Re: ovirt 4.2.7 -> 4.3.0 upgrade process

Il giorno mer 6 feb 2019 alle ore 17:28 Douglas Duckworth <
dod2...@med.cornell.edu> ha scritto:

> Hello
>
> Can anyone confirm that the steps for upgrading to 4.3 from 4.2 are the
> same as listed for previous versions?
>
> I reviewed 4.1 to 4.2 which looks straight forward:
>
>
> https://www.ovirt.org/documentation/upgrade-guide/chap-Upgrading_from_4.1_to_oVirt_4.2.html
>
> I am sure nothing will go wrong though we are doing daily backups of the
> hosted engine VM database.
>

If you are on 4.2.7 I would recommend upgrade the engine to 4.2.8 before
upgrading to 4.3.
Since in 4.3 we switched from fluentd to rsyslog for the metrics part, with
4.2.7 you may have some issue if you upgrade hosts to 4.3 before the engine
gets upgraded.





>
> Thanks,
>
> Douglas Duckworth, MSc, LFCS
> HPC System Administrator
> Scientific Computing Unit 
> Weill Cornell Medicine
> 1300 York Avenue
> New York, NY 10065
> E: d...@med.cornell.edu
> O: 212-746-6305
> F: 212-746-8690
> ___
> 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/VC2TVZIHTOTMZOKWBN7VOY2H3FQGTQS3/
>


-- 

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/X64ZU4ZLL4IIWVK3LASFO2BOCOPF2MZN/

[ovirt-users] Re: ovirt-4.3 hyperconverged deployment - no option for "disc count" for JBOD

Bugzilla must have lost my account. Requesting password reset on an account
that doesn't exist, results in 500 :p.
Created a new one.

However, my options for gdeploy version do not match the version 2.0.2
installed. They only list 0.xx.x.

On Wed, Feb 6, 2019 at 8:44 AM Greg Sheremeta  wrote:

>
> On Wed, Feb 6, 2019 at 11:31 AM feral  wrote:
>
>> Sorry, I tried opening a bug, but RH's Bugzilla is having issues and
>> 500's out when I try to request password reset.
>>
>
> Sorry to hear that. I hate to ask, but could you try after clearing
> cookies for *redhat.com, or try in an incognito tab? It's done that to me
> before and clearing cookies worked for me. If it still doesn't work, I'll
> open the bug. Thanks!
>
>
>>
>>
>> ---
>> PLAY [gluster_servers]
>> *
>>
>> TASK [Run a shell script]
>> **
>> changed: [ovirt-431.localdomain] =>
>> (item=/usr/share/gdeploy/scripts/grafton-sanity-check.sh -d vdb -h
>> ovirt-431.localdomain, ovirt-432.localdomain, ovirt-433.localdomain)
>>
>> PLAY RECAP
>> *
>> ovirt-431.localdomain  : ok=1changed=1unreachable=0
>> failed=0
>>
>>
>> PLAY [gluster_servers]
>> *
>>
>> TASK [Run a shell script]
>> **
>> changed: [ovirt-432.localdomain] =>
>> (item=/usr/share/gdeploy/scripts/grafton-sanity-check.sh -d vdb -h
>> ovirt-431.localdomain, ovirt-432.localdomain, ovirt-433.localdomain)
>>
>> PLAY RECAP
>> *
>> ovirt-432.localdomain  : ok=1changed=1unreachable=0
>> failed=0
>>
>>
>> PLAY [gluster_servers]
>> *
>>
>> TASK [Run a shell script]
>> **
>> changed: [ovirt-433.localdomain] =>
>> (item=/usr/share/gdeploy/scripts/grafton-sanity-check.sh -d vdb -h
>> ovirt-431.localdomain, ovirt-432.localdomain, ovirt-433.localdomain)
>>
>> PLAY RECAP
>> *
>> ovirt-433.localdomain  : ok=1changed=1unreachable=0
>> failed=0
>>
>>
>> PLAY [gluster_servers]
>> *
>>
>> TASK [Create VDO with specified size]
>> **
>> changed: [ovirt-431.localdomain] => (item={u'disk': u'/dev/vdb',
>> u'logicalsize': u'11000G', u'name': u'vdo_vdb'})
>>
>> PLAY RECAP
>> *
>> ovirt-431.localdomain  : ok=1changed=1unreachable=0
>> failed=0
>>
>>
>> PLAY [gluster_servers]
>> *
>>
>> TASK [Create VDO with specified size]
>> **
>> changed: [ovirt-432.localdomain] => (item={u'disk': u'/dev/vdb',
>> u'logicalsize': u'11000G', u'name': u'vdo_vdb'})
>>
>> PLAY RECAP
>> *
>> ovirt-432.localdomain  : ok=1changed=1unreachable=0
>> failed=0
>>
>>
>> PLAY [gluster_servers]
>> *
>>
>> TASK [Create VDO with specified size]
>> **
>> changed: [ovirt-433.localdomain] => (item={u'disk': u'/dev/vdb',
>> u'logicalsize': u'11000G', u'name': u'vdo_vdb'})
>>
>> PLAY RECAP
>> *
>> ovirt-433.localdomain  : ok=1changed=1unreachable=0
>> failed=0
>>
>>
>> PLAY [gluster_servers]
>> *
>>
>> TASK [Enable or disable services]
>> **
>> ok: [ovirt-432.localdomain] => (item=chronyd)
>> ok: [ovirt-431.localdomain] => (item=chronyd)
>> ok: [ovirt-433.localdomain] => (item=chronyd)
>>
>> PLAY RECAP
>> *
>> ovirt-431.localdomain  : ok=1changed=0unreachable=0
>> failed=0
>> ovirt-432.localdomain  : ok=1changed=0unreachable=0
>> failed=0
>> ovirt-433.localdomain  : ok=1changed=0unreachable=0
>> failed=0
>>
>>
>> PLAY [gluster_servers]
>> *
>>
>> TASK [start/stop/restart/reload services]
>> **
>> changed: [ovirt-432.localdomain] => (item=chronyd)
>> changed: [ovirt-431.localdomain] => (item=chronyd)
>> changed: [ovirt-433.localdomain] => (item=chronyd)
>>
>> PLAY RECAP
>> *
>> ovirt-431.localdomain  : ok=1changed=1unreachable=0
>> failed=0

[ovirt-users] Re: ovirt 4.2.7 -> 4.3.0 upgrade process

2019-02-06 Thread Eduardo Mayoral

Just did it yesterday, following
https://www.ovirt.org/release/4.3.0/#centos--rhel

Only very minor problem was the duplicated dashboard icon which has
already been discussed in this mailing list.

But please note that my setup may be different from yours.

Best regards,


On 6/2/19 17:26, Douglas Duckworth wrote:
> Hello
>
> Can anyone confirm that the steps for upgrading to 4.3 from 4.2 are
> the same as listed for previous versions?
>
> I reviewed 4.1 to 4.2 which looks straight forward:
>
> https://www.ovirt.org/documentation/upgrade-guide/chap-Upgrading_from_4.1_to_oVirt_4.2.html
>
> I am sure nothing will go wrong though we are doing daily backups of
> the hosted engine VM database.
>
> Thanks,
>
> Douglas Duckworth, MSc, LFCS
> HPC System Administrator
> Scientific Computing Unit 
> Weill Cornell Medicine
> 1300 York Avenue
> New York, NY 10065
> E: d...@med.cornell.edu 
> O: 212-746-6305
> F: 212-746-8690
>
> ___
> 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/VC2TVZIHTOTMZOKWBN7VOY2H3FQGTQS3/

-- 
Eduardo Mayoral Jimeno
Systems engineer, platform department. Arsys Internet.
emayo...@arsys.es - +34 941 620 105 - ext 2153

___
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/NWUPPRXBVSPYNXYM5SR7BHOS3PBAAZL5/

[ovirt-users] Re: ovirt-4.3 hyperconverged deployment - no option for "disc count" for JBOD

On Wed, Feb 6, 2019 at 11:31 AM feral  wrote:

> Sorry, I tried opening a bug, but RH's Bugzilla is having issues and 500's
> out when I try to request password reset.
>

Sorry to hear that. I hate to ask, but could you try after clearing cookies
for *redhat.com, or try in an incognito tab? It's done that to me before
and clearing cookies worked for me. If it still doesn't work, I'll open the
bug. Thanks!


>
>
> ---
> PLAY [gluster_servers]
> *
>
> TASK [Run a shell script]
> **
> changed: [ovirt-431.localdomain] =>
> (item=/usr/share/gdeploy/scripts/grafton-sanity-check.sh -d vdb -h
> ovirt-431.localdomain, ovirt-432.localdomain, ovirt-433.localdomain)
>
> PLAY RECAP
> *
> ovirt-431.localdomain  : ok=1changed=1unreachable=0
> failed=0
>
>
> PLAY [gluster_servers]
> *
>
> TASK [Run a shell script]
> **
> changed: [ovirt-432.localdomain] =>
> (item=/usr/share/gdeploy/scripts/grafton-sanity-check.sh -d vdb -h
> ovirt-431.localdomain, ovirt-432.localdomain, ovirt-433.localdomain)
>
> PLAY RECAP
> *
> ovirt-432.localdomain  : ok=1changed=1unreachable=0
> failed=0
>
>
> PLAY [gluster_servers]
> *
>
> TASK [Run a shell script]
> **
> changed: [ovirt-433.localdomain] =>
> (item=/usr/share/gdeploy/scripts/grafton-sanity-check.sh -d vdb -h
> ovirt-431.localdomain, ovirt-432.localdomain, ovirt-433.localdomain)
>
> PLAY RECAP
> *
> ovirt-433.localdomain  : ok=1changed=1unreachable=0
> failed=0
>
>
> PLAY [gluster_servers]
> *
>
> TASK [Create VDO with specified size]
> **
> changed: [ovirt-431.localdomain] => (item={u'disk': u'/dev/vdb',
> u'logicalsize': u'11000G', u'name': u'vdo_vdb'})
>
> PLAY RECAP
> *
> ovirt-431.localdomain  : ok=1changed=1unreachable=0
> failed=0
>
>
> PLAY [gluster_servers]
> *
>
> TASK [Create VDO with specified size]
> **
> changed: [ovirt-432.localdomain] => (item={u'disk': u'/dev/vdb',
> u'logicalsize': u'11000G', u'name': u'vdo_vdb'})
>
> PLAY RECAP
> *
> ovirt-432.localdomain  : ok=1changed=1unreachable=0
> failed=0
>
>
> PLAY [gluster_servers]
> *
>
> TASK [Create VDO with specified size]
> **
> changed: [ovirt-433.localdomain] => (item={u'disk': u'/dev/vdb',
> u'logicalsize': u'11000G', u'name': u'vdo_vdb'})
>
> PLAY RECAP
> *
> ovirt-433.localdomain  : ok=1changed=1unreachable=0
> failed=0
>
>
> PLAY [gluster_servers]
> *
>
> TASK [Enable or disable services]
> **
> ok: [ovirt-432.localdomain] => (item=chronyd)
> ok: [ovirt-431.localdomain] => (item=chronyd)
> ok: [ovirt-433.localdomain] => (item=chronyd)
>
> PLAY RECAP
> *
> ovirt-431.localdomain  : ok=1changed=0unreachable=0
> failed=0
> ovirt-432.localdomain  : ok=1changed=0unreachable=0
> failed=0
> ovirt-433.localdomain  : ok=1changed=0unreachable=0
> failed=0
>
>
> PLAY [gluster_servers]
> *
>
> TASK [start/stop/restart/reload services]
> **
> changed: [ovirt-432.localdomain] => (item=chronyd)
> changed: [ovirt-431.localdomain] => (item=chronyd)
> changed: [ovirt-433.localdomain] => (item=chronyd)
>
> PLAY RECAP
> *
> ovirt-431.localdomain  : ok=1changed=1unreachable=0
> failed=0
> ovirt-432.localdomain  : ok=1changed=1unreachable=0
> failed=0
> ovirt-433.localdomain  : ok=1changed=1unreachable=0
> failed=0
>
>
> PLAY [gluster_servers]
> *
>
> TASK [Run a command in the shell]
> **
> changed: [ovirt-431.localdomain] => (item=vdsm-tool configure --force)
> changed:

[ovirt-users] Re: ovirt 4.2.7 -> 4.3.0 upgrade process

On Wed, Feb 6, 2019 at 11:35 AM Greg Sheremeta  wrote:

> Hi,
>
> We're working on getting a guide out as soon as possible, but I don't have
> an ETA yet.
>
> On Wed, Feb 6, 2019 at 11:29 AM Douglas Duckworth 
> wrote:
>
>> Hello
>>
>> Can anyone confirm that the steps for upgrading to 4.3 from 4.2 are the
>> same as listed for previous versions?
>>
>
> Basically. Do you use metrics? That's using rsyslog now. Also, if you have
> AMD hosts, there are some things there. That's all I know of.
>

The deprecated CPUs (cpus variable, that entire list)
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, Epyc IBPB, Conroe, Penryn, and Opteron G1-3. If you have those,
you need to change it to a supported type before upgrading or the cluster
will remain non-operational.


> Greg
>
>
>>
>> I reviewed 4.1 to 4.2 which looks straight forward:
>>
>>
>> https://www.ovirt.org/documentation/upgrade-guide/chap-Upgrading_from_4.1_to_oVirt_4.2.html
>>
>> I am sure nothing will go wrong though we are doing daily backups of the
>> hosted engine VM database.
>>
>> Thanks,
>>
>> Douglas Duckworth, MSc, LFCS
>> HPC System Administrator
>> Scientific Computing Unit 
>> Weill Cornell Medicine
>> 1300 York Avenue
>> New York, NY 10065
>> E: d...@med.cornell.edu
>> O: 212-746-6305
>> F: 212-746-8690
>> ___
>> 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/VC2TVZIHTOTMZOKWBN7VOY2H3FQGTQS3/
>>
>
>
> --
>
> 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/YQYC6LYG7Y2Q3ZYJX3BEKTYMCZOAM4TK/

[ovirt-users] Re: ovirt 4.2.7 -> 4.3.0 upgrade process

Hi,

We're working on getting a guide out as soon as possible, but I don't have
an ETA yet.

On Wed, Feb 6, 2019 at 11:29 AM Douglas Duckworth 
wrote:

> Hello
>
> Can anyone confirm that the steps for upgrading to 4.3 from 4.2 are the
> same as listed for previous versions?
>

Basically. Do you use metrics? That's using rsyslog now. Also, if you have
AMD hosts, there are some things there. That's all I know of.

Greg


>
> I reviewed 4.1 to 4.2 which looks straight forward:
>
>
> https://www.ovirt.org/documentation/upgrade-guide/chap-Upgrading_from_4.1_to_oVirt_4.2.html
>
> I am sure nothing will go wrong though we are doing daily backups of the
> hosted engine VM database.
>
> Thanks,
>
> Douglas Duckworth, MSc, LFCS
> HPC System Administrator
> Scientific Computing Unit 
> Weill Cornell Medicine
> 1300 York Avenue
> New York, NY 10065
> E: d...@med.cornell.edu
> O: 212-746-6305
> F: 212-746-8690
> ___
> 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/VC2TVZIHTOTMZOKWBN7VOY2H3FQGTQS3/
>


-- 

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/TA3C5Y2GXUJPNDD3CGPKR2XUZ6MZPR3Y/

[ovirt-users] Re: ovirt 4.2.7 -> 4.3.0 upgrade process

2019-02-06 Thread Petr Matyáš


Hi,

yeah the upgrade is using the same steps.

And actually should be working without any problems.

--
Petr Matyas | RHEVM System QE
pmat...@redhat.com
pmatyas @ #brno, #rhev-qe

On 2/6/19 5:26 PM, Douglas Duckworth wrote:

Hello

Can anyone confirm that the steps for upgrading to 4.3 from 4.2 are 
the same as listed for previous versions?


I reviewed 4.1 to 4.2 which looks straight forward:

https://www.ovirt.org/documentation/upgrade-guide/chap-Upgrading_from_4.1_to_oVirt_4.2.html

I am sure nothing will go wrong though we are doing daily backups of 
the hosted engine VM database.


Thanks,

Douglas Duckworth, MSc, LFCS
HPC System Administrator
Scientific Computing Unit 
Weill Cornell Medicine
1300 York Avenue
New York, NY 10065
E: d...@med.cornell.edu 
O: 212-746-6305
F: 212-746-8690

___
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/VC2TVZIHTOTMZOKWBN7VOY2H3FQGTQS3/
___
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/436CHZNLCQVA23NMEB43RFWXU4X3YS7I/

[ovirt-users] Re: ovirt-4.3 hyperconverged deployment - no option for "disc count" for JBOD

Sorry, I tried opening a bug, but RH's Bugzilla is having issues and 500's
out when I try to request password reset.

---
PLAY [gluster_servers]
*

TASK [Run a shell script]
**
changed: [ovirt-431.localdomain] =>
(item=/usr/share/gdeploy/scripts/grafton-sanity-check.sh -d vdb -h
ovirt-431.localdomain, ovirt-432.localdomain, ovirt-433.localdomain)

PLAY RECAP
*
ovirt-431.localdomain  : ok=1changed=1unreachable=0
failed=0


PLAY [gluster_servers]
*

TASK [Run a shell script]
**
changed: [ovirt-432.localdomain] =>
(item=/usr/share/gdeploy/scripts/grafton-sanity-check.sh -d vdb -h
ovirt-431.localdomain, ovirt-432.localdomain, ovirt-433.localdomain)

PLAY RECAP
*
ovirt-432.localdomain  : ok=1changed=1unreachable=0
failed=0


PLAY [gluster_servers]
*

TASK [Run a shell script]
**
changed: [ovirt-433.localdomain] =>
(item=/usr/share/gdeploy/scripts/grafton-sanity-check.sh -d vdb -h
ovirt-431.localdomain, ovirt-432.localdomain, ovirt-433.localdomain)

PLAY RECAP
*
ovirt-433.localdomain  : ok=1changed=1unreachable=0
failed=0


PLAY [gluster_servers]
*

TASK [Create VDO with specified size]
**
changed: [ovirt-431.localdomain] => (item={u'disk': u'/dev/vdb',
u'logicalsize': u'11000G', u'name': u'vdo_vdb'})

PLAY RECAP
*
ovirt-431.localdomain  : ok=1changed=1unreachable=0
failed=0


PLAY [gluster_servers]
*

TASK [Create VDO with specified size]
**
changed: [ovirt-432.localdomain] => (item={u'disk': u'/dev/vdb',
u'logicalsize': u'11000G', u'name': u'vdo_vdb'})

PLAY RECAP
*
ovirt-432.localdomain  : ok=1changed=1unreachable=0
failed=0


PLAY [gluster_servers]
*

TASK [Create VDO with specified size]
**
changed: [ovirt-433.localdomain] => (item={u'disk': u'/dev/vdb',
u'logicalsize': u'11000G', u'name': u'vdo_vdb'})

PLAY RECAP
*
ovirt-433.localdomain  : ok=1changed=1unreachable=0
failed=0


PLAY [gluster_servers]
*

TASK [Enable or disable services]
**
ok: [ovirt-432.localdomain] => (item=chronyd)
ok: [ovirt-431.localdomain] => (item=chronyd)
ok: [ovirt-433.localdomain] => (item=chronyd)

PLAY RECAP
*
ovirt-431.localdomain  : ok=1changed=0unreachable=0
failed=0
ovirt-432.localdomain  : ok=1changed=0unreachable=0
failed=0
ovirt-433.localdomain  : ok=1changed=0unreachable=0
failed=0


PLAY [gluster_servers]
*

TASK [start/stop/restart/reload services]
**
changed: [ovirt-432.localdomain] => (item=chronyd)
changed: [ovirt-431.localdomain] => (item=chronyd)
changed: [ovirt-433.localdomain] => (item=chronyd)

PLAY RECAP
*
ovirt-431.localdomain  : ok=1changed=1unreachable=0
failed=0
ovirt-432.localdomain  : ok=1changed=1unreachable=0
failed=0
ovirt-433.localdomain  : ok=1changed=1unreachable=0
failed=0


PLAY [gluster_servers]
*

TASK [Run a command in the shell]
**
changed: [ovirt-431.localdomain] => (item=vdsm-tool configure --force)
changed: [ovirt-432.localdomain] => (item=vdsm-tool configure --force)
changed: [ovirt-433.localdomain] => (item=vdsm-tool configure --force)

PLAY RECAP
*
ovirt-431.localdomain  : ok=1changed=1unreachable=0
failed=0
ovirt-432.localdomain  : ok=1changed=1unreachable=0
failed=0
ovirt-433.localdomain  : ok=1changed=1unreachable=0
failed=0


PLAY [gluster_servers]
*

TASK [Run a shell script]

[ovirt-users] ovirt 4.2.7 -> 4.3.0 upgrade process

2019-02-06 Thread Douglas Duckworth

Hello

Can anyone confirm that the steps for upgrading to 4.3 from 4.2 are the same as 
listed for previous versions?

I reviewed 4.1 to 4.2 which looks straight forward:

https://www.ovirt.org/documentation/upgrade-guide/chap-Upgrading_from_4.1_to_oVirt_4.2.html

I am sure nothing will go wrong though we are doing daily backups of the hosted 
engine VM database.

Thanks,

Douglas Duckworth, MSc, LFCS
HPC System Administrator
Scientific Computing Unit
Weill Cornell Medicine
1300 York Avenue
New York, NY 10065
E: d...@med.cornell.edu
O: 212-746-6305
F: 212-746-8690
___
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/VC2TVZIHTOTMZOKWBN7VOY2H3FQGTQS3/

[ovirt-users] Re: sun.security.validator

Ravi, can you assist?

Greg


On Tue, Feb 5, 2019 at 8:39 PM  wrote:

> Did you ever get an answer to this?  I am experiencing the same issue
> after:
>
> 1) Updating the BIOS on my system to the latest one
> 2) Installing a new 10GbE NIC
>
> Both the BIOS update and the NIC installation completed without incident,
> but I am getting the exact same error.
>
> Any advice out 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/6CSADXLGCOMYYC22ZJEQ46EBOINK257H/
>


-- 

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/PJJR4HU4TIN4KE47RKWI6KGKOFUXPEUR/

[ovirt-users] Re: ovirt-4.3 hyperconverged deployment - no option for "disc count" for JBOD

Please open a bug on this.
https://bugzilla.redhat.com/enter_bug.cgi?product=cockpit-ovirt
Component = Gdeploy

Best wishes,
Greg


On Tue, Feb 5, 2019 at 3:20 PM feral  wrote:

> Vanilla install of ovirt-node-4.3 (iso). During hyperconverged wizard,
> there is no option for disc count for JBOD. This results in error during
> deployment.
> Disc Count option is available for all other raid levels.
>
> --
> _
> Fact:
> 1. Ninjas are mammals.
> 2. Ninjas fight ALL the time.
> 3. The purpose of the ninja is to flip out and kill people.
> ___
> 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/7JLLJJM4D2RCOFQLKLW5AVJPUK24J3YY/
>


-- 

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/IFFKQ2WZNN2BYJFNLCT4OEGX2HBXNMKJ/

[ovirt-users] Re: Strange behavior when changing memory and virtual cpu for VM

On Wed, Feb 6, 2019 at 10:34 AM Matthias Barmeier 
wrote:

>
>
> the VM is a plain debian9 VM. Other VMs with identical setup are still
> working as expected. Only when I try to change System settings I got this
> behavior..
>

Hm. I'm not too familiar with cloud-init. Hopefully someone who knows that
better can chime in.
Did cloud-init get turned back on for this VM when you changed the
CPU/memory settings?


>
> 6. Februar 2019 16:27, "Greg Sheremeta"  >
> schrieb:
>
> On Wed, Feb 6, 2019 at 6:04 AM  wrote:
>
> Hi,
>
> after creating a VM from a template everything works fine. After a while I
> would like to increase memory and cpus. I changed the memory and virtual
> cpu settings in the "System" settings.
> I restarted the VM.
>
> From this moment on the VM hangs on boot with this messages filling the
> console:
> url_helper.py[WARNING]: Calling '
> http://169.254.169.254/2009-04-04/meta-data/instance-id' Connection to
> 169.254.169.254 timed out.
>
> Google says that's a special EC2 address. Does your VM do something with
> EC2 and now the network isn't coming up for some reason?
> Can you get a fresh Stretch VM working with networking that can ping out?
>
>
> This goes on for ever. What can I do to make the VM work again ? I tried
> to restore the settings to the values it has before but this does not help.
>
> The VM contains debian 9 (stretch) with cloud init. Ovirt version:
> 4.2.7.5-1.el7
>
> Ciao
> Matze
> ___
> 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/BCVGAAKBBX53YBDHXWZ6VBJJNPUAM52V/
>
> --
>
> GREG SHEREMETA
>
> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>
> Red Hat NA 
>
> gsher...@redhat.com IRC: 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/Z3ONHETJ273YS4G6ROIPM76SY6VNK6WD/

[ovirt-users] Re: engine-iso-uploader taking a REALLY long time

Il giorno mer 6 feb 2019 alle ore 16:32 Tahlia Richardson <
trich...@redhat.com> ha scritto:

>
>
> On Wed, Feb 6, 2019 at 3:23 PM Greg Sheremeta  wrote:
>
>> On Wed, Feb 6, 2019 at 2:28 AM Sandro Bonazzola 
>> wrote:
>>
>>>
>>>
>>> Il giorno mer 6 feb 2019 alle ore 02:31  ha
>>> scritto:
>>>
 I appreciate the responses.  I think we should probably add to this
 page that ISO domains are deprecated since it does not seem to be found
 anywhere here.

 +1. I think a message on the UI is appropriate too.
>> I opened https://bugzilla.redhat.com/show_bug.cgi?id=1673059
>> please vote on it if you agree
>>
>>
>>>
 https://www.ovirt.org/documentation/install-guide/chap-Configuring_Storage.html
>>>
>>>
>>> Sent a pull request here: https://github.com/oVirt/ovirt-site/pull/1895
>>> Thalia, can you please review?
>>>
>>
> Hi, sorry for the delay. I've left a comment with a slight edit
> suggestion.
>

Addressed :-)


>
>
>>
>> +1 from me
>>
>>
>>>
>>>
>>>
>>>

 ___
 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/2USQTH46J64J4FX4HVSOYYQY6BNPAVBL/

>>>
>>>
>>> --
>>>
>>> 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/FGEI5GRZBOTCQMNYY5GZ7A225IMXSQB2/
>>>
>>
>>
>> --
>>
>> GREG SHEREMETA
>>
>> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>>
>> Red Hat NA
>>
>> 
>>
>> gsher...@redhat.comIRC: gshereme
>> 
>>
>
>
> --
> Tahlia Richardson
> Technical Writer, Red Hat Virtualization
> Red Hat Farnborough, EMEA
> IRC: trichard
>


-- 

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/BOC4XBWJESLLELXCSSNQHCMTPNCSFLU3/

[ovirt-users] Re: Strange behavior when changing memory and virtual cpu for VM

On Wed, Feb 6, 2019 at 6:04 AM  wrote:

> Hi,
>
> after creating a VM from a template everything works fine. After a while I
> would like to increase memory and cpus. I changed the memory and virtual
> cpu settings in the "System" settings.
> I restarted the VM.
>
> From this moment on the VM hangs on boot with this messages filling the
> console:
> url_helper.py[WARNING]: Calling '
> http://169.254.169.254/2009-04-04/meta-data/instance-id' Connection to
> 169.254.169.254 timed out.
>

Google says that's a special EC2 address. Does your VM do something with
EC2 and now the network isn't coming up for some reason?
Can you get a fresh Stretch VM working with networking that can ping out?


>
> This goes on for ever. What can I do to make the VM work again ? I tried
> to restore the settings to the values it has before but this does not help.
>
> The VM contains debian 9 (stretch) with cloud init. Ovirt version:
> 4.2.7.5-1.el7
>
> Ciao
>Matze
> ___
> 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/BCVGAAKBBX53YBDHXWZ6VBJJNPUAM52V/
>


-- 

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/XKPD4YMEE5N4GURIIG24UK4XSNM5VXZC/

[ovirt-users] Re: engine-iso-uploader taking a REALLY long time

On Wed, Feb 6, 2019 at 2:28 AM Sandro Bonazzola  wrote:

>
>
> Il giorno mer 6 feb 2019 alle ore 02:31  ha
> scritto:
>
>> I appreciate the responses.  I think we should probably add to this page
>> that ISO domains are deprecated since it does not seem to be found anywhere
>> here.
>>
>> +1. I think a message on the UI is appropriate too.
I opened https://bugzilla.redhat.com/show_bug.cgi?id=1673059
please vote on it if you agree


>
>> https://www.ovirt.org/documentation/install-guide/chap-Configuring_Storage.html
>
>
> Sent a pull request here: https://github.com/oVirt/ovirt-site/pull/1895
> Thalia, can you please review?
>

+1 from me


>
>
>
>
>>
>> ___
>> 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/2USQTH46J64J4FX4HVSOYYQY6BNPAVBL/
>>
>
>
> --
>
> 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/FGEI5GRZBOTCQMNYY5GZ7A225IMXSQB2/
>


-- 

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/H73QHLDMIW3JOUAQLDL7CCY5U5VRJEDS/

[ovirt-users] Re: Bug in the web interface?

Le 06/02/2019 à 15:42, Greg Sheremeta a écrit :
On Wed, Feb 6, 2019 at 6:33 AM Nicolas Ecarnot > wrote:

Le 06/02/2019 à 10:53, Lucie Leistnerova a écrit :
>
> On 2/6/19 10:22 AM, Nicolas Ecarnot wrote:
>> Hi Lucie,
>>
>> Le 06/02/2019 à 10:02, Lucie Leistnerova a écrit :
>>> I'm sorry, my mistake I did not mention to remove the package
without
>>> dependencies.

Same -- sorry, ugh.
For anyone in the same situation, the better thing to do now is simply 
'yum update ovirt-engine-ui-extensions'

That will remove the old dashboard correctly.
https://github.com/oVirt/ovirt-engine-ui-extensions/blob/master/packaging/spec.in#L16

Thank you. We need this kind of wheels greasing as oVirt's complexity 
increases.

To sum up, I think what I'm missing is a clear and solide
documentation
or official Redhat message about whether/what/how/when can/cannot we
update (with "yum update") the engine host and/or the hosts.

Not Red Hat -- oVirt :)

Yep, Greg Sheremeta  ;-)

Indeed, we need an Upgrade Guide update. I'll look into it.

Generally, on my dev instances (which are probably nowhere near as 
complicated as your setups), I run 'yum update' followed by 
'engine-setup'.

Actually, my experience is that yum-upgrading the engine was most of the 
times harmless, but yum-upgrading the hosts lead to complex situations.

I'm at a point where I no longer update my hosts with yum update, and 
only relies on oVirt's update (either via the web GUI or ansible's 
cluster upgrade) which only updates part of the packages.

I'd rather have a strong enough RPM environment around oVirt preventing 
any issue (the version lock usage shows that it's already a concern 
oVirt's people are dealing with and I thank you. Keep strengthening.)

--

Nicolas ECARNOT

___
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/TQAYEZSGMLQCWFJTMAUERABCUNYWG3N6/

[ovirt-users] Re: Bug in the web interface?

On Wed, Feb 6, 2019 at 6:33 AM Nicolas Ecarnot  wrote:

> Le 06/02/2019 à 10:53, Lucie Leistnerova a écrit :
> >
> > On 2/6/19 10:22 AM, Nicolas Ecarnot wrote:
> >> Hi Lucie,
> >>
> >> Le 06/02/2019 à 10:02, Lucie Leistnerova a écrit :
> >>> I'm sorry, my mistake I did not mention to remove the package without
> >>> dependencies.
>

Same -- sorry, ugh.
For anyone in the same situation, the better thing to do now is simply 'yum
update ovirt-engine-ui-extensions'
That will remove the old dashboard correctly.
https://github.com/oVirt/ovirt-engine-ui-extensions/blob/master/packaging/spec.in#L16



> >>>
> >>> rpm -e --nodeps ...
> >>
> >> I'll write that down.
> >>
> >>
>  When looking at the log file above
>  (
> https://framadrop.org/r/ywTOD-Q02-#dA6hdYaxfZpgUB68gtJLB9inH5oJajrL4H9LTktDd6o=)
>
>  [...]
> 
> "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/db/schema.py",
>
> >>>
> >>>
> >>> The error is cause by missing ovirt-engine-dbscripts.
> >>
> >> OK
> >>
>  Well, I thought I messed up with packages, and I thought a compete
>  yum update would help, as I read :
> > Le 05/02/2019 à 15:19, Greg Sheremeta wrote :
> 
> > The fix is pushed. Standalone engine upgrades should be fine starting
> >> now. `yum update` any appliance engines or already upgraded
> >> engines to get the latest ovirt-engine-ui-extensions, which fixes
> >> the problem.
> 
>  So I ran a yum update.
> 
> >>> This package is part of ovirt-engine versionlock so can't be
> >>> installed/updated separately.
> >>> engine-setup should install the missing packages. I tried it by
> >>> myself and it fixed the issue.
> >>>
> >>>[install]
> >>>
> ovirt-engine-dbscripts-4.3.0.5-0.0.master.20190205084851.gitaaebfc9.el7.noarch
>
> >>> will be installed
> >>
> >> I see I have this package, though in an older version :
> >> # rpm -qa|grep -i dbscripts
> >> ovirt-engine-dbscripts-4.3.0.4-1.el7.noarch
> >>
> > The version shouldn't be problem. I tested it in u/s ovirt. Now I tried
> > with same version.
> >
> > Try to remove that package and install again. Versionlock seems to
> > differ here so I was able to install it separately, if not run
> > engine-setup.
> >
> > # rpm -e --nodeps ovirt-engine-dbscripts
>
> Indeed, it found a lot of missing files/dir.
>
> >
> > # yum install ovirt-engine-dbscripts
>
> I forgot to set LANG=C so you'll read some parts in french, but I get
> the idea :
>
> 
> root@mvm01:/tmp# yum install ovirt-engine-dbscripts
> Modules complémentaires chargés : fastestmirror, versionlock
> Loading mirror speeds from cached hostfile
>   * base: centos.mirror.fr.planethoster.net
>   * epel: pkg.adfinis-sygroup.ch
>   * extras: ftp.pasteur.fr
>   * ovirt-4.3: ovirt.repo.nfrance.com
>   * ovirt-4.3-epel: pkg.adfinis-sygroup.ch
>   * updates: centos.mirror.fr.planethoster.net
> Excluding 1 update due to versionlock (use "yum versionlock status" to
> show it)
> Résolution des dépendances
> --> Lancement de la transaction de test
> ---> Le paquet ovirt-engine-dbscripts.noarch 0:4.3.0.4-1.el7 sera installé
> --> Résolution des dépendances terminée
>
> Dépendances résolues
>
>
> =
>   Package
> Architecture Version
>  Dépôt
>  Taille
>
> =
> Installation :
>   ovirt-engine-dbscripts
> noarch   4.3.0.4-1.el7
>  ovirt-4.3
>  331 k
>
> Résumé de la transaction
>
> =
> Installation   1 Paquet
>
> Taille totale des téléchargements : 331 k
> Taille d'installation : 1.6 M
> Is this ok [y/d/N]: y
> Downloading packages:
> ovirt-engine-dbscripts-4.3.0.4-1.el7.noarch.rpm
>
>   | 331 kB
> 00:00:02
> Running transaction check
> Running transaction test
> Transaction test succeeded
> Running transaction
> Avertissement : RPMDB a été modifiée par une autre application que yum.
> ** 1 problèmes RPMDB préexistants trouvés, la sortie de « yum check »
> est la suivante :
> ovirt-engine-4.3.0.4-1.el7.noarch a des dépendances manquantes de
> ovirt-engine-dbscripts = ('0', '4.3.0.4', '1.el7')
>Installation

[ovirt-users] Re: But in the web interface?

On Tue, Feb 5, 2019 at 1:21 PM Strahil  wrote:

> Hey Greg,
>
> Thanks for the efforts.
> It seems the only way I can support the project is to raise bugs - which
> is causing only troubles :)
>

It's not causing trouble at all! It's one of the most helpful things you
can do as a user of the software.


> ... If you have a way towards Bulgaria - I will buy you a beer.
>

Some day ;)

Greg

>
> Best Regards,
> Strahil Nikolov
>
> On Feb 5, 2019 16:19, Greg Sheremeta  wrote:
>
> The fix is pushed. Standalone engine upgrades should be fine starting now.
> `yum update` any appliance engines or already upgraded engines to get the
> latest ovirt-engine-ui-extensions, which fixes the problem.
>
> I'll add a release note. Thanks all.
>
> Best wishes,
> Greg
>
> On Tue, Feb 5, 2019 at 8:48 AM Hetz Ben Hamo  wrote:
>
> Thanks a lot ;)
>
>
> On Tue, Feb 5, 2019 at 2:38 PM Strahil Nikolov 
> wrote:
>
> Dear Hetz,
>
> I have opened a bug for that : 1662047 – [UI] 2 dashboard icons after
> upgrade 
>
> 1662047 – [UI] 2 dashboard icons after upgrade
>
> 
>
>
> You can check the workaround described there.
>
> 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/F76QF32CQSSUDWAM5N4F75WE5PQ5NE5P/
>
>
>
> --
>
> 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/RSHBOH4XNJDXR7FS62E2MKWF4HVNUUEF/

[ovirt-users] glusterevents daemon fails after upgrade from 4.2.8 to 4.3

2019-02-06 Thread Edward Berger

 I upgraded some nodes from 4.28 to 4.3 and now when I look at the cockpit
"services"
tab I see a red failure for Gluster Events Notifier and clicking through I
get these messages below.

14:00
glustereventsd.service failed.
systemd
14:00
Unit glustereventsd.service entered failed state.
systemd
14:00
glustereventsd.service: main process exited, code=exited, status=1/FAILURE
systemd
14:00
ValueError: Attempted relative import in non-package
glustereventsd
14:00
from .eventsapiconf import (LOG_FILE,
glustereventsd
14:00
File "/usr/libexec/glusterfs/events/utils.py", line 29, in 
glustereventsd
14:00
import utils
glustereventsd
14:00
File "/usr/libexec/glusterfs/events/handlers.py", line 12, in 
glustereventsd
14:00
import handlers
glustereventsd
14:00
File "/usr/sbin/glustereventsd", line 24, in 
glustereventsd
___
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/K6N5EWVRPYRAXBUON2XNJVT5OH42PDEN/

[ovirt-users] Re: Bug in the web interface?


Le 06/02/2019 à 10:53, Lucie Leistnerova a écrit :


On 2/6/19 10:22 AM, Nicolas Ecarnot wrote:

Hi Lucie,

Le 06/02/2019 à 10:02, Lucie Leistnerova a écrit :
I'm sorry, my mistake I did not mention to remove the package without 
dependencies.


rpm -e --nodeps ...


I'll write that down.



When looking at the log file above
(https://framadrop.org/r/ywTOD-Q02-#dA6hdYaxfZpgUB68gtJLB9inH5oJajrL4H9LTktDd6o=) 
[...]
"/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/db/schema.py", 



The error is cause by missing ovirt-engine-dbscripts.


OK

Well, I thought I messed up with packages, and I thought a compete 
yum update would help, as I read :

Le 05/02/2019 à 15:19, Greg Sheremeta wrote :



The fix is pushed. Standalone engine upgrades should be fine starting
now. `yum update` any appliance engines or already upgraded 
engines to get the latest ovirt-engine-ui-extensions, which fixes 
the problem.


So I ran a yum update.

This package is part of ovirt-engine versionlock so can't be 
installed/updated separately.
engine-setup should install the missing packages. I tried it by 
myself and it fixed the issue.


   [install] 
ovirt-engine-dbscripts-4.3.0.5-0.0.master.20190205084851.gitaaebfc9.el7.noarch 
will be installed


I see I have this package, though in an older version :
# rpm -qa|grep -i dbscripts
ovirt-engine-dbscripts-4.3.0.4-1.el7.noarch

The version shouldn't be problem. I tested it in u/s ovirt. Now I tried 
with same version.


Try to remove that package and install again. Versionlock seems to 
differ here so I was able to install it separately, if not run 
engine-setup.


# rpm -e --nodeps ovirt-engine-dbscripts


Indeed, it found a lot of missing files/dir.



# yum install ovirt-engine-dbscripts


I forgot to set LANG=C so you'll read some parts in french, but I get 
the idea :



root@mvm01:/tmp# yum install ovirt-engine-dbscripts
Modules complémentaires chargés : fastestmirror, versionlock
Loading mirror speeds from cached hostfile
 * base: centos.mirror.fr.planethoster.net
 * epel: pkg.adfinis-sygroup.ch
 * extras: ftp.pasteur.fr
 * ovirt-4.3: ovirt.repo.nfrance.com
 * ovirt-4.3-epel: pkg.adfinis-sygroup.ch
 * updates: centos.mirror.fr.planethoster.net
Excluding 1 update due to versionlock (use "yum versionlock status" to 
show it)

Résolution des dépendances
--> Lancement de la transaction de test
---> Le paquet ovirt-engine-dbscripts.noarch 0:4.3.0.4-1.el7 sera installé
--> Résolution des dépendances terminée

Dépendances résolues

=
 Package 
Architecture Version 
Dépôt 
Taille

=
Installation :
 ovirt-engine-dbscripts 
noarch   4.3.0.4-1.el7 
ovirt-4.3 
331 k


Résumé de la transaction
=
Installation   1 Paquet

Taille totale des téléchargements : 331 k
Taille d'installation : 1.6 M
Is this ok [y/d/N]: y
Downloading packages:
ovirt-engine-dbscripts-4.3.0.4-1.el7.noarch.rpm 

 | 331 kB 
00:00:02

Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Avertissement : RPMDB a été modifiée par une autre application que yum.
** 1 problèmes RPMDB préexistants trouvés, la sortie de « yum check » 
est la suivante :
ovirt-engine-4.3.0.4-1.el7.noarch a des dépendances manquantes de 
ovirt-engine-dbscripts = ('0', '4.3.0.4', '1.el7')
  Installation : ovirt-engine-dbscripts-4.3.0.4-1.el7.noarch 



 1/1
  Vérification : ovirt-engine-dbscripts-4.3.0.4-1.el7.noarch 



 1/1

Installé :
  ovirt-engine-dbscripts.noarch 0:4.3.0.4-1.el7 





Terminé !

-

After that, I ran again engine-setup and it went OK.
Now, my ovirt DC and dashboard is back to life, thanks to you Lucie.

To sum up, I think what I'm missing is a clear and solide documentation 
or official Redhat message about whether/what/how/when can/cannot we 
update (with "yum update") the engine host and/or the hosts.


??

--
Nicolas ECARNOT
___
Users mailing list -- users@ovirt.org
To

[ovirt-users] Re: Ovirt 4.3 RC missing glusterfs-gnfs

2019-02-06 Thread Strahil




I've raised https://bugzilla.redhat.com/show_bug.cgi?id=1672711 to fix this.

As a workaround, can you remove glusterfs-gnfs and update?


I have recently implemented nfs-ganesha with ctdb (via storhaug) due to performance issues with FUSE mounts (20 MB/s writes, 600MB/s reads) and that is not possible.I'm not in a hurry, so I can hold the upgrade.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/A75KJI5RM7XWWQINZ56UCMIVF4U5MQ4Q/

[ovirt-users] Strange behavior when changing memory and virtual cpu for VM

2019-02-06 Thread matthias . barmeier

Hi,

after creating a VM from a template everything works fine. After a while I 
would like to increase memory and cpus. I changed the memory and virtual cpu 
settings in the "System" settings. 
I restarted the VM. 

From this moment on the VM hangs on boot with this messages filling the console:
url_helper.py[WARNING]: Calling 
'http://169.254.169.254/2009-04-04/meta-data/instance-id' Connection to 
169.254.169.254 timed out.

This goes on for ever. What can I do to make the VM work again ? I tried to 
restore the settings to the values it has before but this does not help.

The VM contains debian 9 (stretch) with cloud init. Ovirt version: 4.2.7.5-1.el7

Ciao
   Matze
___
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/BCVGAAKBBX53YBDHXWZ6VBJJNPUAM52V/

[ovirt-users] "Volume Option cluster.granular-entry-heal=enable could not be set" when using "Optimize for Virt store"

2019-02-06 Thread Jorick Astrego

Hi again,

When using the option "Optimize for Virt store", I get the following error:

2019-02-06 10:25:02,353+01 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(EE-ManagedThreadFactory-engine-Thread-15727)
[051cfc8c-9efc-427c-9e2e-9127e3e0a86d] EVENT_ID:
GLUSTER_VOLUME_OPTION_SET_FAILED(4,003), Volume Option
cluster.granular-entry-heal=enable could not be set on ssd9 of
cluster GlusterFS-storage.

This looks like the same issue as
https://bugzilla.redhat.com/show_bug.cgi?id=1635684

Volume set option 'granular-entry-heal' is not longer set via
gluster volume set option.

Is this a known issue or should I open a bug for this?





Met vriendelijke groet, With kind regards,

Jorick Astrego

Netbulae Virtualization Experts 



Tel: 053 20 30 270  i...@netbulae.euStaalsteden 4-3A
KvK 08198180
Fax: 053 20 30 271  www.netbulae.eu 7547 TA Enschede
BTW NL821234584B01



___
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/HYEJJPEJISYSQCQLPT45AUAHEOKWBKN5/

[ovirt-users] Re: Changing CPU type from Opteron G3 to Epyc with hosted engine in 4.3

2019-02-06 Thread Simone Tiraboschi

On Wed, Feb 6, 2019 at 11:02 AM Juhani Rautiainen <
juhani.rautiai...@gmail.com> wrote:

> On Wed, Feb 6, 2019 at 11:27 AM Juhani Rautiainen
>  wrote:
> >
> > On Wed, Feb 6, 2019 at 10:31 AM Simone Tiraboschi 
> wrote:
> > >
> > > The only case that could prevent that is that you are in hosted-engine
> mode and so you cannot set the latest host into maintenance mode without
> loosing the engine itself.
> > >
> > > If this is your case,
> > > what you can do is:
> > > - set HE global maintenance mode
> > > - set one of the hosted-engine hosts into maintenance mode
> > > - move it to a different cluster
> > > - shutdown the engine VM
> > > - manually restart the engine VM on the host on the custom cluster
> directly executing on that host: hosted-engine --vm-start
> > > - connect again to the engine
> > > - set all the hosts of the initial cluster into maintenance mode
> > > - upgrade the cluster
> > > - shut down again the engine VM
> > > - manually restart the engine VM on one of the hosts of the initial
> cluster
> > > - move back the host that got into a temporary cluster to its initial
> cluster
> >
> > I might try this one.
>
> I tried this one and it worked. There was problem with couple of VM's
> (they were made from OVA from Virtualbox). It couldn't upgrade old
> cluster until they were moved to temporary cluster too (complaining
> about wrong cluster level). It might have been the real reason why the
> normal upgrade failed? Maybe the error message was wrong?
>

Thanks for the report, honestly I have to double check it because it looks
a bit suspicious.

I also think that an addition to
https://github.com/oVirt/ovirt-ansible-cluster-upgrade
to handle also the upgrade of the hosted-engine cluster making it smoother
could make a lot of sense.


>
> Thanks a lot,
> 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/VY6KPQVW27YBJT2ASLKOLISJNHW4RMW4/

[ovirt-users] Re: Bug in the web interface?

2019-02-06 Thread Lucie Leistnerova



On 2/6/19 10:22 AM, Nicolas Ecarnot wrote:

Hi Lucie,

Le 06/02/2019 à 10:02, Lucie Leistnerova a écrit :
I'm sorry, my mistake I did not mention to remove the package without 
dependencies.


rpm -e --nodeps ...


I'll write that down.



When looking at the log file above
(https://framadrop.org/r/ywTOD-Q02-#dA6hdYaxfZpgUB68gtJLB9inH5oJajrL4H9LTktDd6o=) 
[...]
"/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/db/schema.py", 


The error is cause by missing ovirt-engine-dbscripts.


OK

Well, I thought I messed up with packages, and I thought a compete 
yum update would help, as I read :

Le 05/02/2019 à 15:19, Greg Sheremeta wrote :



The fix is pushed. Standalone engine upgrades should be fine starting
now. `yum update` any appliance engines or already upgraded 
engines to get the latest ovirt-engine-ui-extensions, which fixes 
the problem.


So I ran a yum update.

This package is part of ovirt-engine versionlock so can't be 
installed/updated separately.
engine-setup should install the missing packages. I tried it by 
myself and it fixed the issue.


   [install] 
ovirt-engine-dbscripts-4.3.0.5-0.0.master.20190205084851.gitaaebfc9.el7.noarch 
will be installed


I see I have this package, though in an older version :
# rpm -qa|grep -i dbscripts
ovirt-engine-dbscripts-4.3.0.4-1.el7.noarch

The version shouldn't be problem. I tested it in u/s ovirt. Now I tried 
with same version.


Try to remove that package and install again. Versionlock seems to 
differ here so I was able to install it separately, if not run engine-setup.


# rpm -e --nodeps ovirt-engine-dbscripts

# yum install ovirt-engine-dbscripts



Not sure what went wrong by you, send please the setup log and the 


>> 
(https://framadrop.org/r/ywTOD-Q02-#dA6hdYaxfZpgUB68gtJLB9inH5oJajrL4H9LTktDd6o=)


ovirt-engine* rpms list. And also result of 'ls 
/usr/share/ovirt-engine/dbscripts'


# LANG=C ls -la /usr/share/ovirt-engine/dbscripts
ls: cannot access /usr/share/ovirt-engine/dbscripts: No such file or 
directory


You seem to hit the point.


--
Lucie Leistnerova
Quality Engineer, QE Cloud, RHVM
Red Hat EMEA

IRC: lleistne @ #rhev-qe
___
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/DHLDJ25RAXEDHEZOPBZKY7OLPNF3NV32/

[ovirt-users] Re: Changing CPU type from Opteron G3 to Epyc with hosted engine in 4.3

2019-02-06 Thread Juhani Rautiainen

On Wed, Feb 6, 2019 at 10:31 AM Simone Tiraboschi  wrote:
>

>
> You can simply upgrade the cluster if all the hosts are in global maintenance 
> mode.

Like I originally wrote it doesn't work like that for me. This was
what I tried. I tried again now and even confirmed from cli that it is
correct mode:

# hosted-engine --vm-status

!! Cluster is in GLOBAL MAINTENANCE mode !!

And still I get this:

"Error while executing action: Cannot change Cluster CPU type unless
all Hosts attached to this Cluster are in Maintenance"

Is there a log where I can check if there are some traces why it gives
this error message?

> The only case that could prevent that is that you are in hosted-engine mode 
> and so you cannot set the latest host into maintenance mode without loosing 
> the engine itself.
>
> If this is your case,
> what you can do is:
> - set HE global maintenance mode
> - set one of the hosted-engine hosts into maintenance mode
> - move it to a different cluster
> - shutdown the engine VM
> - manually restart the engine VM on the host on the custom cluster directly 
> executing on that host: hosted-engine --vm-start
> - connect again to the engine
> - set all the hosts of the initial cluster into maintenance mode
> - upgrade the cluster
> - shut down again the engine VM
> - manually restart the engine VM on one of the hosts of the initial cluster
> - move back the host that got into a temporary cluster to its initial cluster

I might try this one.

Thanks,
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/WN6XG4JT5MPLGIINEGB2W2YRGJ43JMHG/

[ovirt-users] Re: Bug in the web interface?


Hi Lucie,

Le 06/02/2019 à 10:02, Lucie Leistnerova a écrit :
I'm sorry, my mistake I did not mention to remove the package without 
dependencies.


rpm -e --nodeps ...


I'll write that down.



When looking at the log file above
(https://framadrop.org/r/ywTOD-Q02-#dA6hdYaxfZpgUB68gtJLB9inH5oJajrL4H9LTktDd6o=) 
[...]
"/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/db/schema.py", 

The error is cause by missing ovirt-engine-dbscripts.


OK

Well, I thought I messed up with packages, and I thought a compete yum 
update would help, as I read :

Le 05/02/2019 à 15:19, Greg Sheremeta wrote :



The fix is pushed. Standalone engine upgrades should be fine starting
now. `yum update` any appliance engines or already upgraded engines 
to get the latest ovirt-engine-ui-extensions, which fixes the problem.


So I ran a yum update.

This package is part of ovirt-engine versionlock so can't be 
installed/updated separately.
engine-setup should install the missing packages. I tried it by myself 
and it fixed the issue.


   [install] 
ovirt-engine-dbscripts-4.3.0.5-0.0.master.20190205084851.gitaaebfc9.el7.noarch 
will be installed


I see I have this package, though in an older version :
# rpm -qa|grep -i dbscripts
ovirt-engine-dbscripts-4.3.0.4-1.el7.noarch



Not sure what went wrong by you, send please the setup log and the 


>> 
(https://framadrop.org/r/ywTOD-Q02-#dA6hdYaxfZpgUB68gtJLB9inH5oJajrL4H9LTktDd6o=)


ovirt-engine* rpms list. And also result of 'ls 
/usr/share/ovirt-engine/dbscripts'


# LANG=C ls -la /usr/share/ovirt-engine/dbscripts
ls: cannot access /usr/share/ovirt-engine/dbscripts: No such file or 
directory


You seem to hit the point.

--
Nicolas ECARNOT
___
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/DA3RSDSTLAHWDCIAZNAGRUMKFHT7Y2GN/

[ovirt-users] Re: Bug in the web interface?

2019-02-06 Thread Lucie Leistnerova


Hi Nicolas,

On 2/6/19 9:07 AM, Nicolas Ecarnot wrote:

Le 05/02/2019 à 10:51, Lucie Leistnerova a écrit :

Hi Hetz,

On 2/5/19 10:25 AM, Hetz Ben Hamo wrote:

Hi,

I upgraded to 4.3 and on the hosted engine web interface, I see the 
"dashboard" button twice, one below the other.


How can I fix it or is it a known bug?

Yes, it is known issue and guys are working on that. Package 
ovirt-engine-dashboard is obsolete and ovirt-engine-ui-extensions is 
the new one. The fix then should remove the obsolete package, now it 
stays.


Remove package ovirt-engine-dashboard and one dashboard button 
disappears.


Hi,

I upgraded to 4.3 and hit the same issue.
I ran "yum remove ovirt-engine-dashboard" and I saw the additional 
button disappear.

I was tired and then mistyped :
"yum remove -y ovirt-engine-dashboard"
At first, I thought it would do nothing as I just removed it.
Instead, it *did* things, as if there was an alias from this package 
name to the "ovirt-engine-ui-extensions" name.

Is it possible?

Well, I ctrl-C'ed it in hurry and saw it uninstalled :
ovirt-engine-extension-aaa-ldap-setup-1.3.8-1.el7.noarch
ovirt-engine-extension-aaa-ldap-1.3.8-1.el7.noarch
ovirt-engine-api-explorer-0.0.2-1.el7.centos.noarch
ovirt-engine-backend-4.3.0.4-1.el7.noarch
ovirt-engine-dbscripts-4.3.0.4-1.el7.noarch

I'm sorry, my mistake I did not mention to remove the package without 
dependencies.


rpm -e --nodeps ...



So I reinstalled these packages.

I witnessed that my GUI wasn't working anymore, so I ran "engine-setup".
I answered the same questions I answered since years so I was pretty 
confident - I run this command at each upgrade, it does work.


Now, troubles are coming.

I choose to backup the database and to perform the vacuum.
After confirming the otopi answers, I see this failure :

[ INFO  ] Configuring WebSocket Proxy
[ INFO  ] Backing up database localhost:engine to 
'/var/lib/ovirt-engine/backups/engine-20190206084916.CbO3sD.dump'.

[ INFO  ] Creating/refreshing Engine database schema
[ ERROR ] Failed to execute stage 'Misc configuration': [Errno 2] 
Aucun fichier ou dossier de ce type

[ INFO  ] Rolling back DWH database schema
[ INFO  ] Clearing DWH database ovirt_engine_history
[ INFO  ] Rolling back database schema
[ INFO  ] Clearing Engine database engine
[ INFO  ] Restoring Engine database engine
[ INFO  ] Restoring file 
'/var/lib/ovirt-engine/backups/engine-20190206084916.CbO3sD.dump' to 
database localhost:engine.
[ ERROR ] Errors while restoring engine database, please check the log 
file for details

[ INFO  ] Stage: Clean up
  Log file is located at 
/var/log/ovirt-engine/setup/ovirt-engine-setup-20190206084840-2ps56v.log
[ INFO  ] Generating answer file 
'/var/lib/ovirt-engine/setup/answers/20190206084929-setup.conf'

[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination
[ ERROR ] Execution of setup failed

When looking at the log file above
(https://framadrop.org/r/ywTOD-Q02-#dA6hdYaxfZpgUB68gtJLB9inH5oJajrL4H9LTktDd6o=) 


, I see a lot of SQL queries, then :

2019-02-06 08:49:17,955+0100 DEBUG 
otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema 
plugin.executeRaw:813 execute: 
['/usr/share/ovirt-engine/dbscripts/schema.sh', '-s', 'localhost', 
'-p', '5432', '-u', 'engine', '-d', 'eng2019-02-06 08:49:17,960+0100 
DEBUG otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema 
plugin.executeRaw:869 execute-result: 
['/usr/share/ovirt-engine/dbscripts/schema.sh', '-s', 'localhost', 
'-p', '5432', '-u', 'engine', '-dTraceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/otopi/plugin.py", line 856, 
in executeRaw

    preexec_fn=preexec_fn,
  File "/usr/lib64/python2.7/subprocess.py", line 711, in __init__
    errread, errwrite)
  File "/usr/lib64/python2.7/subprocess.py", line 1327, in _execute_child
    raise child_exception
OSError: [Errno 2] Aucun fichier ou dossier de ce type
2019-02-06 08:49:17,961+0100 DEBUG otopi.context 
context._executeMethod:143 method exception

Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/otopi/context.py", line 133, 
in _executeMethod

    method['method']()
  File 
"/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/db/schema.py", 
line 427, in _misc

    raiseOnError=False,
  File "/usr/lib/python2.7/site-packages/otopi/plugin.py", line 912, 
in execute

    **kwargs
  File "/usr/lib/python2.7/site-packages/otopi/plugin.py", line 856, 
in executeRaw

    preexec_fn=preexec_fn,
  File "/usr/lib64/python2.7/subprocess.py", line 711, in __init__
    errread, errwrite)
  File "/usr/lib64/python2.7/subprocess.py", line 1327, in _execute_child
    raise child_exception
OSError: [Errno 2] Aucun fichier ou dossier de ce type
2019-02-06 08:49:17,961+0100 ERROR otopi.context 
context._executeMethod:152 Failed to execute stage 'Misc 
configuration': [Errno 2] Aucun fichier ou dossier de ce type




The error is cause by missing ovirt-engine-dbscripts.


Well, I thought I

[ovirt-users] Re: Changing CPU type from Opteron G3 to Epyc with hosted engine in 4.3

2019-02-06 Thread Simone Tiraboschi

On Wed, Feb 6, 2019 at 5:21 AM Juhani Rautiainen <
juhani.rautiai...@gmail.com> wrote:

> On Tue, Feb 5, 2019 at 8:24 AM Juhani Rautiainen
>  wrote:
> > Hi!
> > Now that I have engine and nodes on 4.3 level I'm stuck on upgrading
> > the CPU type.  What is the correct way to solve this problem?
>
> So it seems that I have to reinstall the whole cluster because usually
> the silence means that there is no solution. As it currently stands I
> don't see any other way. I made bugzilla entry about the problem
> (1672859). This problem has been discussed shortly on this list 2016
> but probably nobody bothered to do the bug report back then. Makes
> upgrading hardware bit pointless if you can't use new CPU features.
>

You can simply upgrade the cluster if all the hosts are in global
maintenance mode.

The only case that could prevent that is that you are in hosted-engine mode
and so you cannot set the latest host into maintenance mode without loosing
the engine itself.

If this is your case,
what you can do is:
- set HE global maintenance mode
- set one of the hosted-engine hosts into maintenance mode
- move it to a different cluster
- shutdown the engine VM
- manually restart the engine VM on the host on the custom cluster directly
executing on that host: hosted-engine --vm-start
- connect again to the engine
- set all the hosts of the initial cluster into maintenance mode
- upgrade the cluster
- shut down again the engine VM
- manually restart the engine VM on one of the hosts of the initial cluster
- move back the host that got into a temporary cluster to its initial
cluster







>
> -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/54K7BGQEWESN2DEIMZ55FIYQ7RLAIAZR/
>
___
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/LGVEAMVTNTJVAVFDXKV7YALEUTPIEKVU/

[ovirt-users] Re: Bug in the web interface?