[ovirt-users] Re: I wrote an article on using Ansible to backup oVirt VMs

2020-02-10 Thread Torsten Stolpmann

Thanks Jayme, much appreciated!

On 10.02.2020 16:59, Jayme wrote:
I've been part of this mailing list for a while now and have received a 
lot of great advice and help on various subjects. I read the list daily 
and one thing I've noticed is that many users are curious about backup 
options for oVirt (myself included). I wanted to share with the 
community a solution I've come up with to easily backup multiple running 
oVirt VMs to OVA format using some basic Ansible playbooks. I've put 
together a blog post detailing the process which also includes links to 
a Github repo containing the playbooks here: 
https://blog.silverorange.com/backing-up-ovirt-vms-with-ansible-4c2fca8b3b43


Any feedback, suggestions or questions are welcome. I hope this 
information is helpful.


Thanks!

- Jayme

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


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


[ovirt-users] Re: Ovirt backup

2020-01-19 Thread Torsten Stolpmann
Well there is also https://github.com/vacosta94/VirtBKP (See 
http://blog.infratic.com/create-ovirtrhevs-vm-backup/) which is taking 
an image based approach which I assume might be faster.


Again, I have not tried it myself.

I personally prefer to have an easy to restore VM on the export storage 
to restore from, so I stick to the tools mentioned before.


But yes, the process takes a lot of space and time and your mileage may 
vary.



On 19.01.2020 19:11, Strahil Nikolov wrote:

That's what VEPA Backup is also doing and is widely used in the Enterprise.
It depends of the type of storage you use. For example , file-based 
storage (NFS, Gluster) is easy - you can just copy the snapshot and then 
delete.


Yet , for block-based storage the only working solution I have seen to 
be working properly is the snapshot (VEPA backup) or it's clone to be 
presented to a VM for accessing it.
I don't know about this vProtect , but ssh cannot be faster than a tar 
over a tape or other media.


Of course, storage-based snapshots are the fastest , but they also 
require space.


Best Regards,
Strahil Nikolov

В неделя, 19 януари 2020 г., 19:40:05 ч. Гринуич+2, Jayme 
 написа:



The biggest problem with these tools is that they are very inefficient.  
To work they snapshot the VM then clone the snapshot into a new VM, back 
it up then delete.  This takes a lot of space and time.


vProtect and some other enterprise backup software snapshot the VM and 
stream the snapshot from the API without needing to clone or using a 
proxy VM.  The new version of vProtect even bypasses the API (because 
it's slow) and now supports streaming over SSH directly from the host.  
This is the ideal solution for oVirt VM backups imo, but I don't know if 
any free tool exists that can offer the same functionality.


On Sun, Jan 19, 2020 at 1:03 PM Torsten Stolpmann 
mailto:torsten.stolpm...@verit.de>> wrote:


I am still using https://github.com/wefixit-AT/oVirtBackup but since
support for the v3 API will be removed with oVirt 4.4 it will stop
working with this release. For this reason I can no longer recommend it
but it served me well the past few years.

There is also https://github.com/jb-alvarado/ovirt-vm-backup which has
similar functionality but I have yet no first-hand experience with this.

Hope this helps.

Torsten

On 19.01.2020 10:05, Nazan CENGİZ wrote:
 > Hi all,
 >
 >
 > I want to back up Ovirt for free. Is there a script, project or tool
 > that you can recommend for this?
 >
 >
 > Is there a project that you can test, both backup and restore
process
 > can work properly?
 >
 >
 > Best Regards,
 >
 > Nazan.
 >
 >
 >
 > <http://www.havelsan.com.tr>
 > **Nazan CENGİZ
 > AR-GE MÜHENDİSİ
 > Mustafa Kemal Mahallesi 2120 Cad. No:39 06510 Çankaya Ankara TÜRKİYE
 >       +90 312 219 57 87               +90 312 219 57 97
 >
 > YASAL UYARI: Bu elektronik posta işbu linki kullanarak
ulaşabileceğiniz
 > Koşul ve Şartlar dokümanına tabidir.
 > <http://havelsan.com.tr/tr/news/e-posta-yasal-uyari>
 > LEGAL NOTICE: This e-mail is subject to the Terms and Conditions
 > document which can be accessed with this link.
 > <http://havelsan.com.tr/tr/news/e-posta-yasal-uyari>
 >       Lütfen gerekmedikçe bu sayfa ve eklerini yazdırmayınız /
Please
 > consider the environment before printing this email
 >
 >
 >
 > ___
 > Users mailing list -- users@ovirt.org <mailto:users@ovirt.org>
 > To unsubscribe send an email to users-le...@ovirt.org
<mailto: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/G56O76VB5WO3MV2URL4OH3KNZMQRSKU4/
 >
___
Users mailing list -- users@ovirt.org <mailto:users@ovirt.org>
To unsubscribe send an email to users-le...@ovirt.org
<mailto: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/2LGGH7UEC3RBNELT57YF7255FYORSMGZ/

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

Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code 

[ovirt-users] Re: Ovirt backup

2020-01-19 Thread Torsten Stolpmann
I am still using https://github.com/wefixit-AT/oVirtBackup but since 
support for the v3 API will be removed with oVirt 4.4 it will stop 
working with this release. For this reason I can no longer recommend it 
but it served me well the past few years.


There is also https://github.com/jb-alvarado/ovirt-vm-backup which has 
similar functionality but I have yet no first-hand experience with this.


Hope this helps.

Torsten

On 19.01.2020 10:05, Nazan CENGİZ wrote:

Hi all,


I want to back up Ovirt for free. Is there a script, project or tool 
that you can recommend for this?



Is there a project that you can test, both backup and restore process 
can work properly?



Best Regards,

Nazan.



  
**Nazan CENGİZ
AR-GE MÜHENDİSİ
Mustafa Kemal Mahallesi 2120 Cad. No:39 06510 Çankaya Ankara TÜRKİYE
+90 312 219 57 87   +90 312 219 57 97

YASAL UYARI: Bu elektronik posta işbu linki kullanarak ulaşabileceğiniz 
Koşul ve Şartlar dokümanına tabidir. 

LEGAL NOTICE: This e-mail is subject to the Terms and Conditions 
document which can be accessed with this link. 

	Lütfen gerekmedikçe bu sayfa ve eklerini yazdırmayınız / Please 
consider the environment before printing this email




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


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


[ovirt-users] Re: Can we please migrate to 2020 and get a user friendly issues/support tool?

2020-01-13 Thread Torsten Stolpmann
To throw in my 2cents worth - I am totally happy with a mailing list and 
see absolutely no need for a change.


I heard that Google is very good at indexing btw. as is my mailreader.


On 13.01.2020 15:37, m.skrzetu...@gmail.com wrote:

Well, yes... in my opinion it should be a discussion forum, with a well designed search. 
A place where you can see the question and answers and maybe a "marked" 
solution. Not everything is a bug and Bugzilla is as modern as Internet Explorer 4. Did 
you try to search for solutions, for some oVirt problems? It's a nightmare to go through 
this list here.

The comparison with Jira was probably wrong, although you don't have to use 
Jira like a ticketing system. I just wanted to express that I would like some 
kind of a modern tool. Something like StackOverflow maybe. Or a simple forum 
software.
___
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/LAHRPTZCDZQEOLBD3TKWKUKUKPUXWC2B/


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


[ovirt-users] Re: Intel Xeon X5460

2019-09-01 Thread Torsten Stolpmann
I might be wrong here, but I think that Conroe/Penryn processors are 
still supported if you set cluster compatibility version to 4.2.


On a personal side I also like to state that I am disappointed about 
this change as it artificially limits usage of older hardware. A warning 
about potential Spectre vulnerabilities in the UI would have been 
sufficient here IMHO.


On 01.09.2019 09:59, Liran Rotenberg wrote:

Hi Marcello,
Unfortunately, this processor is not supported since 4.3.
Your processor is in Penryn family (from looking on wikipedia).

Here is the related bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1540921

Regards,
Liran.

On Sun, Sep 1, 2019 at 9:50 AM Marcello Gentile 
mailto:marcello.gent...@adsdata.ca>> wrote:


Is this procesor supported?


https://ark.intel.com/content/www/us/en/ark/products/33087/intel-xeon-processor-x5460-12m-cache-3-16-ghz-1333-mhz-fsb.html

Seems to meet all the requirements but when I install the self
hosted engine it fails with the error message below:

[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg":
"The host has been set in non_operational status, deployment errors:
code 156: Host Ovirt-Node1.adsdata.ca
 moved to Non-Operational state as
host CPU type is not supported in this cluster compatibility version
or is not supported at all, code 9000: Failed to verify Power
Management configuration for Host Ovirt-Node1.adsdata.ca
., fix accordingly and re-deploy."}

Thanks for any 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/SXZJZ2VQ7ILF56W4NWA5OS6KD5FTJUIO/


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


___
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/6TXJ4PK2BQMBJIP6C6NM3GU5YSKLHGS5/


[ovirt-users] Re: SURVEY: your NFS configuration (Bug 1666795 - SHE doesn't start after power-off, 4.1 to 4.3 upgrade - VolumeDoesNotExist: Volume does not exist )

2019-02-13 Thread Torsten Stolpmann

/etc/exports:

/export/volumes *(rw,all_squash,anonuid=36,anongid=36)


exportfs -v:

/data/volumes 
(sync,wdelay,hide,no_subtree_check,anonuid=36,anongid=36,sec=sys,rw,secure,root_squash,all_squash)


Centos7.6, oVirt 4.2.8. We are not running HE, ovirt-engine runs on bare 
metal. Not sure if this information is relevant then.


Torsten

On 12.02.2019 23:39, Nir Soffer wrote:

Looking at
https://bugzilla.redhat.com/1666795

It seems that a change in vdsm/libvirt exposed NFS configuration issue, 
that may was

needed in the past and probably not needed now.

If you use NFS, I would like to see your /etc/exports (after sanitizing 
it if needed).

For extra bonus, output of "exportfs -v" would be useful.

In particular, I want to know if you use root_squash, all_squash, or 
no_root_squash.


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


___
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/3JLCVXS72DTSM6C2KXTYCERWZAA44WIO/


[ovirt-users] Re: [ANN] oVirt 4.3.0 is now generally available

2019-02-04 Thread Torsten Stolpmann

On 04.02.2019 19:58, Jon bae wrote:



Am 04.02.2019 um 19:16 schrieb Torsten Stolpmann 
mailto:torsten.stolpm...@verit.de>>:



On 04.02.2019 16:03, Mike wrote:

04.02.2019 17:45, Torsten Stolpmann пишет:

Congratulations to the team, this list looks impressive!

I have one question though:

We are relying on https://github.com/wefixit-AT/oVirtBackup for our 
daily backup routine (which sadly is still stuck on API v3).


So my question is, is API v3 still available in the 4.3 release?

If the answer is no, this will sadly lock us out from updating to 
4.3 in the foreseeable future.

maybe try to use this?
https://github.com/openbacchus/bacchus
it uses sdk4
it works with ovirt 4.2.7 after some updates
it looks modern ;)
(I'm also trying to use it :)


We also tried using openbaccus once in the past but it shortly stopped 
working for us, see https://github.com/openbacchus/bacchus/issues/30


I think that was due to 
https://bugzilla.redhat.com/show_bug.cgi?id=1628909 and I am unsure if 
this is now working again with release 4.3.0.


I would be interested in hearing about your experiences in day to day 
usage. The potential is definitely there with openbaccus.


But to be honest I prefer a small but flexible command line tool over 
a fancy GUI any time.


Torsten


--
Mike
___
Users mailing list -- users@ovirt.org <mailto:users@ovirt.org>
To unsubscribe send an email to users-le...@ovirt.org 
<mailto: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/K2L4DZY32G2LL2C5WXQY7EIODTIOPWF2/ 


___
Users mailing list -- users@ovirt.org <mailto:users@ovirt.org>
To unsubscribe send an email to users-le...@ovirt.org 
<mailto: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/VKCAGC5ZPW25MKO4NC4JZJCANFEL4XXV/


You can give this a try, if you want:

https://github.com/jb-alvarado/ovirt-vm-backup


It is very similar to oVirtBackup, but use the new API.


Thanks a lot, I missed this one. I will definitely give it at try.

Torsten


___
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/6MBBJ227H2GSRFGSJRZXHNZD2IDFXNWQ/


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


[ovirt-users] Re: [ANN] oVirt 4.3.0 is now generally available

2019-02-04 Thread Torsten Stolpmann

On 04.02.2019 16:03, Mike wrote:

04.02.2019 17:45, Torsten Stolpmann пишет:

Congratulations to the team, this list looks impressive!

I have one question though:

We are relying on https://github.com/wefixit-AT/oVirtBackup for our 
daily backup routine (which sadly is still stuck on API v3).


So my question is, is API v3 still available in the 4.3 release?

If the answer is no, this will sadly lock us out from updating to 4.3 
in the foreseeable future.


maybe try to use this?

https://github.com/openbacchus/bacchus

it uses sdk4
it works with ovirt 4.2.7 after some updates
it looks modern ;)

(I'm also trying to use it :)



We also tried using openbaccus once in the past but it shortly stopped 
working for us, see https://github.com/openbacchus/bacchus/issues/30


I think that was due to 
https://bugzilla.redhat.com/show_bug.cgi?id=1628909 and I am unsure if 
this is now working again with release 4.3.0.


I would be interested in hearing about your experiences in day to day 
usage. The potential is definitely there with openbaccus.


But to be honest I prefer a small but flexible command line tool over a 
fancy GUI any time.


Torsten


--
Mike

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


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


[ovirt-users] Re: [ANN] oVirt 4.3.0 is now generally available

2019-02-04 Thread Torsten Stolpmann

Congratulations to the team, this list looks impressive!

I have one question though:

We are relying on https://github.com/wefixit-AT/oVirtBackup for our 
daily backup routine (which sadly is still stuck on API v3).


So my question is, is API v3 still available in the 4.3 release?

If the answer is no, this will sadly lock us out from updating to 4.3 in 
the foreseeable future.


I am aware, that the release notes list API v3 as 'officially not 
supported'. Bit I *think* that it read somewhere else on the list that 
it still is available until 4.4 is released.


What is the situation here?

Regards,

Torsten
___
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/ZBFCXYZHWNNCEMYEI5I6FLBV4FS77K4N/


[ovirt-users] Re: Backup & Restore

2018-12-20 Thread Torsten Stolpmann

On 20.12.2018 07:41, Yedidyah Bar David wrote:

On Wed, Dec 19, 2018 at 1:35 PM Torsten Stolpmann
 wrote:


On 19.12.2018 11:54, Yedidyah Bar David wrote:

On Wed, Dec 19, 2018 at 12:34 PM Torsten Stolpmann
 wrote:


On 19.12.2018 08:01, Yedidyah Bar David wrote:

On Tue, Dec 18, 2018 at 5:20 PM Torsten Stolpmann
 wrote:


Hi Yedidyah,

please find the logs at the following URL:
http://www.klaros-testmanagement.com/files/ovirt/ovirt-restore-logs.tar.gz

Let me know once you received them safely so I can remove them again.


Done.



Thanks, removed.



I also added the restore.log containing the actual error which occured
during the restore.

Since this was a clean system I restored on, the setup has been executed
after the database restore, so the setup logs probably contain nothing
of interest. I added them anyway.


Sorry I wasn't clear enough. I meant the setup logs on the machine used
to create the backup. So that I can try to see why your backup contained
this function. Do you still have these by any chance?

Indeed, I can't see anything wrong in the logs above.


Sorry for misunderstanding, this totally makes sense.

I added the setup logs i found at:
http://www.klaros-testmanagement.com/files/ovirt/ovirt-setup-logs.tar.gz

Again, please let me know once I can remove them.


Done.


Thanks, removed.





Please let me know if there is anything I can add to this.


If you do not have setup logs from the original machine, at least try
to think about its history and tell us notable points - including entire
version history, setup/upgrade (or similar) problems you had there (and
perhaps worked around), etc.



We started with one of the first 4.0 releases and updated the system on
a regular basis since then. We almost never skipped a release.


The last log there is ovirt-engine-setup-20171231170651-lb3q89.log ,
meaning it was last upgraded almost a year ago. Were there indeed no
more upgrades since?



20171231170651 is most probably the date when we installed the last
major release (4.2.0). We did a lot more updates since and I now have a
suspicion what went wrong here.

We naively assumed that a yum update is sufficient for a minor upgrade
of the engine installation.


:-(


Rereading the documentation I think we were
missing explicit engine-setup calls after each minor upgrade.


Indeed



It may be the case, that the extra call to engine-setup is required to
not be part of the yum update.


engine-setup might need to ask the user questions, so we do not run it
inside yum update.

As long as it clear to users that this is required this is totally ok 
for me.



I think in this case it would be a good
idea to warn users that this step has not yet been taken and the update
is not completed yet.


Do you think you would have noticed? It's not that hard to add such a
message during yum update, but not sure it's that helpful.


Yes, I would probably have noticed that. Sooner or later ... :)


Perhaps we can also make the engine check e.g. if the setup package is
newer than itself, and warn the user in the admin ui.

I think that both is a good idea. Some applications even go the way to 
lock out users from the GUI until a necessary database migration has 
been executed by an administrator. Your mileage may vary here but this 
is the solution I would favor.




Could this be the cause for the missing logs and behavior discrepancies?

If yes, would another call to engine-setup in the current state fix this
and allow us to produce correct backups in the future?


If you still have the source machine, then yes, it should be enough.
Run engine-setup, then engine-backup again to backup, then restore
on the new machine.


Thanks, will do.




The log indicates the machine was upgraded to ovirt-engine-4.2.0.2 ,
which didn't remove the uuid functions. The bug I linked at before,
1515635, was fixed in 4.2.1.

Based on this, I think the best solution for now would be the patch
you suggested. Would you like to open a bug for this and push a patch
to gerrit? I can do this as well if you prefer. Bug summary line
should probably be something like:

engine-setup fails after restoring a backup taken with 4.2.0


I currently fear that would only cure the symptom.


Another solution would be to try using the same engine version during
restore (4.2.0.2), and only upgrade later. This is a bit hard, because
we do not have separate repos for each version, although they do
include all released versions - so you can try e.g.:

yum install ovirt-engine-4.2.0.2-1.el7

(meaning, after you remove existing 4.2.7, or you can try yum downgrade).

I didn't try this myself, not sure how well it would work. There might
be older dependencies to handle, and/or it might break due to too-new
stuff.


I don't think this is necessary.


Obviously, the best solution is to upgrade more often and backup more
often, and have a smaller difference between backup version and restore
version, ideally no difference. But I realize this does not always

[ovirt-users] Re: Backup & Restore

2018-12-19 Thread Torsten Stolpmann

On 19.12.2018 11:54, Yedidyah Bar David wrote:

On Wed, Dec 19, 2018 at 12:34 PM Torsten Stolpmann
 wrote:


On 19.12.2018 08:01, Yedidyah Bar David wrote:

On Tue, Dec 18, 2018 at 5:20 PM Torsten Stolpmann
 wrote:


Hi Yedidyah,

please find the logs at the following URL:
http://www.klaros-testmanagement.com/files/ovirt/ovirt-restore-logs.tar.gz

Let me know once you received them safely so I can remove them again.


Done.



Thanks, removed.



I also added the restore.log containing the actual error which occured
during the restore.

Since this was a clean system I restored on, the setup has been executed
after the database restore, so the setup logs probably contain nothing
of interest. I added them anyway.


Sorry I wasn't clear enough. I meant the setup logs on the machine used
to create the backup. So that I can try to see why your backup contained
this function. Do you still have these by any chance?

Indeed, I can't see anything wrong in the logs above.


Sorry for misunderstanding, this totally makes sense.

I added the setup logs i found at:
http://www.klaros-testmanagement.com/files/ovirt/ovirt-setup-logs.tar.gz

Again, please let me know once I can remove them.


Done.


Thanks, removed.





Please let me know if there is anything I can add to this.


If you do not have setup logs from the original machine, at least try
to think about its history and tell us notable points - including entire
version history, setup/upgrade (or similar) problems you had there (and
perhaps worked around), etc.



We started with one of the first 4.0 releases and updated the system on
a regular basis since then. We almost never skipped a release.


The last log there is ovirt-engine-setup-20171231170651-lb3q89.log ,
meaning it was last upgraded almost a year ago. Were there indeed no
more upgrades since?



20171231170651 is most probably the date when we installed the last 
major release (4.2.0). We did a lot more updates since and I now have a 
suspicion what went wrong here.


We naively assumed that a yum update is sufficient for a minor upgrade 
of the engine installation. Rereading the documentation I think we were 
missing explicit engine-setup calls after each minor upgrade.


It may be the case, that the extra call to engine-setup is required to 
not be part of the yum update. I think in this case it would be a good 
idea to warn users that this step has not yet been taken and the update 
is not completed yet.


Could this be the cause for the missing logs and behavior discrepancies?

If yes, would another call to engine-setup in the current state fix this 
and allow us to produce correct backups in the future?



The log indicates the machine was upgraded to ovirt-engine-4.2.0.2 ,
which didn't remove the uuid functions. The bug I linked at before,
1515635, was fixed in 4.2.1.

Based on this, I think the best solution for now would be the patch
you suggested. Would you like to open a bug for this and push a patch
to gerrit? I can do this as well if you prefer. Bug summary line
should probably be something like:

engine-setup fails after restoring a backup taken with 4.2.0


I currently fear that would only cure the symptom.


Another solution would be to try using the same engine version during
restore (4.2.0.2), and only upgrade later. This is a bit hard, because
we do not have separate repos for each version, although they do
include all released versions - so you can try e.g.:

yum install ovirt-engine-4.2.0.2-1.el7

(meaning, after you remove existing 4.2.7, or you can try yum downgrade).

I didn't try this myself, not sure how well it would work. There might
be older dependencies to handle, and/or it might break due to too-new
stuff.


I don't think this is necessary.


Obviously, the best solution is to upgrade more often and backup more
often, and have a smaller difference between backup version and restore
version, ideally no difference. But I realize this does not always
work out for everyone...


You are right, we did this.

Best regards

Torsten


There was indeed one glitch during updates which was connected to the
Postgres version in use:

The initial install was (accidentally) done under Postgres 9.4 which
happened to be present on the machine at that point of time. oVirt 4.0
was allowing this way back then. I think in 4.1 Postgres 9.2 has been
enforced, so there had been workarounds to allow updates under 9.4. This
got resolved with the migration to 4.2 which brought the Postgres 9.5
installation (if I recall that correctly).

Other than that I have no idea which might have introduced this.


All of this sounds irrelevant to current problem. Thanks for recalling :-)

Best regards,



If you find something in the logs you need more information on, please
let me know.

Best regards

Torsten



If you, or anyone, manages to come up with a flow resulting in a 4.2
engine database that contains a function uuid_generate_v1 in the engine
database schema, I'd definitely want to know about it.

Re

[ovirt-users] Re: Backup & Restore

2018-12-19 Thread Torsten Stolpmann

On 19.12.2018 08:01, Yedidyah Bar David wrote:

On Tue, Dec 18, 2018 at 5:20 PM Torsten Stolpmann
 wrote:


Hi Yedidyah,

please find the logs at the following URL:
http://www.klaros-testmanagement.com/files/ovirt/ovirt-restore-logs.tar.gz

Let me know once you received them safely so I can remove them again.


Done.



Thanks, removed.



I also added the restore.log containing the actual error which occured
during the restore.

Since this was a clean system I restored on, the setup has been executed
after the database restore, so the setup logs probably contain nothing
of interest. I added them anyway.


Sorry I wasn't clear enough. I meant the setup logs on the machine used
to create the backup. So that I can try to see why your backup contained
this function. Do you still have these by any chance?

Indeed, I can't see anything wrong in the logs above.


Sorry for misunderstanding, this totally makes sense.

I added the setup logs i found at: 
http://www.klaros-testmanagement.com/files/ovirt/ovirt-setup-logs.tar.gz


Again, please let me know once I can remove them.



Please let me know if there is anything I can add to this.


If you do not have setup logs from the original machine, at least try
to think about its history and tell us notable points - including entire
version history, setup/upgrade (or similar) problems you had there (and
perhaps worked around), etc.



We started with one of the first 4.0 releases and updated the system on 
a regular basis since then. We almost never skipped a release.


There was indeed one glitch during updates which was connected to the 
Postgres version in use:


The initial install was (accidentally) done under Postgres 9.4 which 
happened to be present on the machine at that point of time. oVirt 4.0 
was allowing this way back then. I think in 4.1 Postgres 9.2 has been 
enforced, so there had been workarounds to allow updates under 9.4. This 
got resolved with the migration to 4.2 which brought the Postgres 9.5 
installation (if I recall that correctly).


Other than that I have no idea which might have introduced this.

If you find something in the logs you need more information on, please 
let me know.


Best regards

Torsten



If you, or anyone, manages to come up with a flow resulting in a 4.2
engine database that contains a function uuid_generate_v1 in the engine
database schema, I'd definitely want to know about it.

Re-adding others posting in this thread, in case someone has a clue.
Perhaps one of you has setup logs of the machine on which the backup
was generated? If so, please share. Thanks.

That said, on a second thought, the implications of this are not that
significant - mainly somewhat lower performance - so perhaps it's more
important to fix your bug (by adding a line to IGNORED_ERRORS, as you
suggested)... but it's still weird.

Thanks and best regards,



Cheers,

Torsten


On 18.12.2018 07:54, Yedidyah Bar David wrote:

On Mon, Dec 17, 2018 at 2:26 PM Torsten Stolpmann
 wrote:


I experienced the same issue while restoring a full backup (engine &
dwh) on a clean machine. Both machines are running CentOS 7.6 and
oVirt 4.2.7.

The issue went away when adding the following line to the IGNORED_ERRORS
list starting at 1944 in engine-backup:

must be owner of function uuid_generate_v1

Hope this helps,


It does, and thanks for the report!

Can you please share all of your setup logs (/var/log/ovirt-engine/setup/*)?

Thanks!

More details:

This function should not normally be included in a 4.2 backup, and I do
not yet understand why you get this error.

If it's a clean 4.2 setup, it should never have been defined.
Earlier versions did create it, and the upgrade process should have
dropped it, if it's an upgraded setup. See also:

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

Best regards,



Torsten

On 24.05.2018 11:32, emmanuel.the...@obs-nancay.fr wrote:

hi,

I have the same error when I try to restore on a new hosted VM (ovirt 4.2.3)
Have you a solution ?

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


___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
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/YMMFCYUMLCM47OJSTHXS2IMOIKEEFU27/





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

[ovirt-users] Re: Backup & Restore

2018-12-18 Thread Torsten Stolpmann

Hi Yedidyah,

please find the logs at the following URL: 
http://www.klaros-testmanagement.com/files/ovirt/ovirt-restore-logs.tar.gz


Let me know once you received them safely so I can remove them again.

I also added the restore.log containing the actual error which occured 
during the restore.


Since this was a clean system I restored on, the setup has been executed 
after the database restore, so the setup logs probably contain nothing 
of interest. I added them anyway.


Please let me know if there is anything I can add to this.

Cheers,

Torsten


On 18.12.2018 07:54, Yedidyah Bar David wrote:

On Mon, Dec 17, 2018 at 2:26 PM Torsten Stolpmann
 wrote:


I experienced the same issue while restoring a full backup (engine &
dwh) on a clean machine. Both machines are running CentOS 7.6 and
oVirt 4.2.7.

The issue went away when adding the following line to the IGNORED_ERRORS
list starting at 1944 in engine-backup:

must be owner of function uuid_generate_v1

Hope this helps,


It does, and thanks for the report!

Can you please share all of your setup logs (/var/log/ovirt-engine/setup/*)?

Thanks!

More details:

This function should not normally be included in a 4.2 backup, and I do
not yet understand why you get this error.

If it's a clean 4.2 setup, it should never have been defined.
Earlier versions did create it, and the upgrade process should have
dropped it, if it's an upgraded setup. See also:

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

Best regards,



Torsten

On 24.05.2018 11:32, emmanuel.the...@obs-nancay.fr wrote:

hi,

I have the same error when I try to restore on a new hosted VM (ovirt 4.2.3)
Have you a solution ?

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


___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
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/YMMFCYUMLCM47OJSTHXS2IMOIKEEFU27/





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


[ovirt-users] Re: Backup & Restore

2018-12-17 Thread Torsten Stolpmann
I experienced the same issue while restoring a full backup (engine & 
dwh) on a clean machine. Both machines are running CentOS 7.6 and

oVirt 4.2.7.

The issue went away when adding the following line to the IGNORED_ERRORS 
list starting at 1944 in engine-backup:


must be owner of function uuid_generate_v1

Hope this helps,

Torsten

On 24.05.2018 11:32, emmanuel.the...@obs-nancay.fr wrote:

hi,

I have the same error when I try to restore on a new hosted VM (ovirt 4.2.3)
Have you a solution ?

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


___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
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/YMMFCYUMLCM47OJSTHXS2IMOIKEEFU27/


[ovirt-users] Re: oVirt 4.2 and CLI options

2018-06-06 Thread Torsten Stolpmann

On 02.06.2018 08:52, Yaniv Kaul wrote:



On Thu, May 31, 2018, 10:08 PM Simon Coter > wrote:


Hi,

what is the best choice for a CLI interface vs oVirt 4.2 ?


While I recommend looking at Ansible, 
https://github.com/fbacchella/ovirtcmd is also an interesting option.




I found ovirt-shell an indispensable tool during troubleshooting when 
ssh is the last usable option, due to its interactive nature in relation 
to ansible.


I feel sad to see it vanish in 4.3 without any equivalent replacement.

Will have a look at ovirtcmd though. Are there plans to make this 
available via yum in the future?



Torsten



I've looked for it and I saw that ovirt-shell is already deprecated.


Correct.
Y.

Thanks

Simon
___
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/IUSAU6HO776435P7DZ36CJ2AVHZLDGDW/



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


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


Re: [ovirt-users] How is everyone performing backups?

2017-10-30 Thread Torsten Stolpmann

On 30.10.2017 17:51, Nathanaël Blanchet wrote:



Le 30/10/2017 à 17:24, Bernardo Juanicó a écrit :

Torsten:
That tool (oVirtBackup ) is 
based on the old SDK (Version 3) which is deprecated and will be 
removed (correct me if im wrong) on the 4.2 version.
No it will finally still be available in 4.2, sdk3 will be removed later 
to an undefined date.
I also have been keeping an eye on that subject. Thanks to the oVirt 
team for the decision to keep the API around a bit longer.


Torsten
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] How is everyone performing backups?

2017-10-30 Thread Torsten Stolpmann

We are using https://github.com/wefixit-AT/oVirtBackup for backups.

This works ok for us for nightly scheduled online backups of our vms 
managed by an oVirt 4.0.2.7 engine.


Is this the script you have been using?

Torsten

On 27.10.2017 17:27, Wesley Stewart wrote:
Originally, I used a script I found on github, but since updating I 
can't seem to get that to work again.


I was just curious if there were any other more elegant type solutions?  
I am currently running a single host and local storage, but I would love 
to backup VM's automatically once a week or so to an NFS share.


Just curious if anyone had tackled this issue.


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users



___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] Issues with Power Management

2017-01-23 Thread Torsten Stolpmann

Hello Bradley,

beats me - I tried to replicate your situation but was unable to reach 
that error. My setup seems identical to yours (Centos 7.3 / oVirt Engine 
4.0.2.7-1).


Is it possible that this error is related to some totally different field?

Out of ideas,
Torsten


On 23.01.2017 23:08, Bradley Bishop wrote:

Hello Torsten,

Thank you for replying! I read that somewhere else also. The issue is
web ui does not allow me to enter those options. I get an error that
states "The field must contain an integer number between -2147483648
<tel:(214)%20748-3648> and 2147483648 <tel:(214)%20748-3648>."

Thank you,
Bradley

___

Hello Bradley,

I am successfully managing an R710 drac6 controller using the following
parameters:

Type: drac5
Options: cmd_prompt=/admin1->,login_timeout=60

Hope this helps,

Torsten

On 23.01.2017 22:43, Bradley Bishop wrote:

Hello all,

I am new to ovirt and having issues setting up Power Management options
for my Dell Hosts r710 hosts with idrac 8. I am running ovirt 4.0 on
Centos 7.3

I found some other information that stated i needed to have the option
cmd_prompt=admin->
 (http://users.ovirt.narkive.com/IuztlLPv/power-management-for-drac6
<http://users.ovirt.narkive.com/IuztlLPv/power-management-for-drac6>)
but i consistantly get the error of the content needing to be an integer
when i do that. I have attached a screenshot below


​
Has anyone seen this and know what i am doing wrong?

Thank you,
Bradley Bishop


___
Users mailing list
Users@ovirt.org <mailto:Users@ovirt.org>
http://lists.ovirt.org/mailman/listinfo/users
<http://lists.ovirt.org/mailman/listinfo/users>


On Mon, Jan 23, 2017 at 4:59 PM, Torsten Stolpmann
<torsten.stolpm...@verit.de <mailto:torsten.stolpm...@verit.de>> wrote:

Hello Bradley,

I am successfully managing an R710 drac6 controller using the
following parameters:

Type: drac5
Options: cmd_prompt=/admin1->,login_timeout=60

Hope this helps,

Torsten

On 23.01.2017 22:43, Bradley Bishop wrote:

Hello all,

I am new to ovirt and having issues setting up Power Management
options
for my Dell Hosts r710 hosts with idrac 8. I am running ovirt 4.0 on
Centos 7.3

I found some other information that stated i needed to have the
option
cmd_prompt=admin->
 (http://users.ovirt.narkive.com/IuztlLPv/power-management-for-drac6
<http://users.ovirt.narkive.com/IuztlLPv/power-management-for-drac6>)
but i consistantly get the error of the content needing to be an
integer
when i do that. I have attached a screenshot below


​
Has anyone seen this and know what i am doing wrong?

Thank you,
Bradley Bishop


___
Users mailing list
Users@ovirt.org <mailto:Users@ovirt.org>
http://lists.ovirt.org/mailman/listinfo/users
<http://lists.ovirt.org/mailman/listinfo/users>





___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] Issues with Power Management

2017-01-23 Thread Torsten Stolpmann

Hello Bradley,

I am successfully managing an R710 drac6 controller using the following 
parameters:


Type: drac5
Options: cmd_prompt=/admin1->,login_timeout=60

Hope this helps,

Torsten

On 23.01.2017 22:43, Bradley Bishop wrote:

Hello all,

I am new to ovirt and having issues setting up Power Management options
for my Dell Hosts r710 hosts with idrac 8. I am running ovirt 4.0 on
Centos 7.3

I found some other information that stated i needed to have the option
cmd_prompt=admin->
 (http://users.ovirt.narkive.com/IuztlLPv/power-management-for-drac6)
but i consistantly get the error of the content needing to be an integer
when i do that. I have attached a screenshot below


​
Has anyone seen this and know what i am doing wrong?

Thank you,
Bradley Bishop


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users



___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users