[ovirt-users] Re: CentOS 8 is dead

2021-01-23 Thread Florian Schmid via Users
Hi Strahil, 

thank you very much for the information. 

Now the question is, will oVirt stay 100 % compatible to RH? 

As I understood it, is that oVirt will be developed for CentOS Stream and will 
be tested against it. 
RH doesn't have the same application versions than CentOS Stream, because 
Stream is newer and a way ahead RH, so is oVirt then. 

I think, we will have then the same problems with oVirt and CentOS had, where 
RH 8.3 was already released and CentOS 8.3 not. Now it is vice versa. Stream is 
first and RH later. 


BR Florian 


Von: "users"  
An: "users"  
Gesendet: Samstag, 23. Januar 2021 14:58:44 
Betreff: [ovirt-users] Re: CentOS 8 is dead 

For anyone interested , 

RH are extending the developer subscription for production use of up to 16 
systems [1]. 
For me , it's completely enough to run my oVirt nodes on EL 8. 


[ 
https://www.redhat.com/en/blog/new-year-new-red-hat-enterprise-linux-programs-easier-ways-access-rhel
 | 
https://www.redhat.com/en/blog/new-year-new-red-hat-enterprise-linux-programs-easier-ways-access-rhel
 ] 

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/privacy-policy.html 
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/ 
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/S5SG7IXZYSCA6MVFV6MIPJZFVDAFQ3EU/
 
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/KBIXKW7XQ5FMXBQZEIBB4B6X2K4WBNMT/


[ovirt-users] Re: CentOS 8 is dead

2020-12-26 Thread Florian Schmid via Users
Hello Simon, 

would you be so kind and explain me, why OLVM is so far behind RHV or oVirt? 

It would be also great to know, if you backport fixes from oVirt 4.3.7+ back to 
OLVM 4.3.6? I have seen, that there are some newer packages on your repo server 
for 4.3.6, which seem newer than the oVirt release, but I haven't find any 
release notes of your versions. 

Thank you very much for your answers. 
BR Florian 


Von: "Simon Coter"  
An: "Strahil Nikolov"  
CC: "marcel d'heureuse" , "James Loker-Steele" 
, "Diggy Mc" , "users"  
Gesendet: Freitag, 25. Dezember 2020 23:14:41 
Betreff: [ovirt-users] Re: CentOS 8 is dead 






On Dec 25, 2020, at 10:50 PM, Strahil Nikolov via Users < [ 
mailto:users@ovirt.org | users@ovirt.org ] > wrote: 

В 22:32 +0100 на 25.12.2020 (пт), marcel d'heureuse написа: 

BQ_BEGIN
I think oracle is not a solution. if they do the same with oracle Linux like 
java one year ago. that you can't use it in company's it will be a wast of time 
to move to oracle. 

or am I wrong? 

br 
marcel 



I admit that Oracle's reputation is not best ... but I guess if they do take 
such approach - we can always migrate to Springade/Rocky Linux/Lenix .. 
After all , OLVM is new tech for Oracle and they want more users to start using 
it (and later switch to paid subscription). 

I think that it's worth testing. 

@Simon, 

do you have any idea if there will be any issues migrating from CentOS 7 + 
oVirt 4.3.10 to OEL 8 + OLVM (once the 4.4 is available ) ? 

BQ_END


I do not expect particular issues; for OL we’re also working to the pure OL7 to 
OL8 upgrade process. 
BTW, I tested more times the moving from CentOS 7 to OL7 / oVirt to OLVM on 4.3 
release. 


BQ_BEGIN

I saw [ 
https://blogs.oracle.com/virtualization/getting-started-with-oracle-linux-virtualization-manager
 | 
https://blogs.oracle.com/virtualization/getting-started-with-oracle-linux-virtualization-manager
 ] , but it's a little bit outdated and is about OLVM 4.2 + OEL 7 . 

BQ_END


We’re now on OLVM 4.3.6+ ( [ 
https://blogs.oracle.com/virtualization/announcing-oracle-linux-virtualization-manager-43
 | 
https://blogs.oracle.com/virtualization/announcing-oracle-linux-virtualization-manager-43
 ] ) and working on latest maintenance release (on 4.3.10+). 
The plan is to then work on OLVM 4.4 with OL8. 

Simon 


BQ_BEGIN



Happy Hollidays! 

Best Regards, 
Strahil Nikolov 
___ 
Users mailing list -- [ mailto:users@ovirt.org | users@ovirt.org ] 
To unsubscribe send an email to [ mailto:users-le...@ovirt.org | 
users-le...@ovirt.org ] 
Privacy Statement: [ 
https://urldefense.com/v3/__https://www.ovirt.org/privacy-policy.html__;!!GqivPVa7Brio!LCOm_us9gseDgFXAmC7bYXy5yX2h68L4y4cwTq4ULhIW6Q0mpoeHZ9INuzSfvSjn$
 | 
https://urldefense.com/v3/__https://www.ovirt.org/privacy-policy.html__;!!GqivPVa7Brio!LCOm_us9gseDgFXAmC7bYXy5yX2h68L4y4cwTq4ULhIW6Q0mpoeHZ9INuzSfvSjn$
 ] 
oVirt Code of Conduct: [ 
https://urldefense.com/v3/__https://www.ovirt.org/community/about/community-guidelines/__;!!GqivPVa7Brio!LCOm_us9gseDgFXAmC7bYXy5yX2h68L4y4cwTq4ULhIW6Q0mpoeHZ9INu-0TAgKs$
 | 
https://urldefense.com/v3/__https://www.ovirt.org/community/about/community-guidelines/__;!!GqivPVa7Brio!LCOm_us9gseDgFXAmC7bYXy5yX2h68L4y4cwTq4ULhIW6Q0mpoeHZ9INu-0TAgKs$
 ] 
List Archives: [ 
https://urldefense.com/v3/__https://lists.ovirt.org/archives/list/users@ovirt.org/message/6VS6GH7FKBLWLDHJ6JUPENKNQEPWN2KL/__;!!GqivPVa7Brio!LCOm_us9gseDgFXAmC7bYXy5yX2h68L4y4cwTq4ULhIW6Q0mpoeHZ9INu8QCjROD$
 | 
https://urldefense.com/v3/__https://lists.ovirt.org/archives/list/users@ovirt.org/message/6VS6GH7FKBLWLDHJ6JUPENKNQEPWN2KL/__;!!GqivPVa7Brio!LCOm_us9gseDgFXAmC7bYXy5yX2h68L4y4cwTq4ULhIW6Q0mpoeHZ9INu8QCjROD$
 ] 

BQ_END



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


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

2020-12-22 Thread Florian Schmid via Users
Thx a lot Sandro. 


Von: "Sandro Bonazzola"  
An: "Florian Schmid"  
CC: "users" , "Jason Keltz" , "Strahil 
Nikolov"  
Gesendet: Dienstag, 22. Dezember 2020 14:14:28 
Betreff: Re: [ovirt-users] Re: [ANN] oVirt 4.4.4 is now generally available 



Il giorno mar 22 dic 2020 alle ore 13:57 Florian Schmid via Users < [ 
mailto:users@ovirt.org | users@ovirt.org ] > ha scritto: 


Hi, 

I think the big question is: Will ovirt be tested against such EL-based clones. 


Well, it will be tested for those EL-based clones a few months before they'll 
be released, being CentOS Stream upstream to those clones. 
At GA time, oVirt is already expected to work fine on latest Red Hat Enterprise 
Linux. 
The gain on using CentOS Stream is that it will be already working also on next 
Red Hat Enterprise Linux. 

BQ_BEGIN
Is ovirt then still 100% compatible to EL, when it will be developed for 
Stream, because Stream will be ahead EL. 

BQ_END

I don't see why it shouldn't. 
As an example scenario: 
- oVirt 4.4.3 has been released with cluster compatibility level 4.5, requiring 
RHEL 8.3 + Advanced Virtualization to be able to consume the new feature. But 
it worked fine on CentOS 8.2 in cluster compatibility level 4.4. 
- CentOS 8.3 and Advanced Virtualization 8.3 got released: 4.4.3 and the new 
4.4.4 can now use cluster level 4.5. 

With CentOS Stream you'll get similar scenario. At GA time oVirt 4.4.5 will be 
released working with CentOS Stream at release date which basically means, it 
will be ready to work on RHEL 8.4 but will be working with RHEL 8.3 too while 
waiting for RHEL 8.4 to be released. 


BQ_BEGIN
Next question is, how stable will be CentOS stream? 

BQ_END

I think pretty much. Before landing on CentOS Stream packages have been already 
through RHEL CI. 
And oVirt wise, it will go through our CI as well. 

BQ_BEGIN
At the moment, ovirt is using a lot a packages of different 3rd party repos, 
but the OS system core is still EL clone and stable. 
With stream, also the core system is quite new and a way newer than EL, so how 
stable will it be? 

Can you then still use CentOS stream + oVirt in production systems? 

BQ_END

I think so, and oVirt wise we already foresee CentOS Stream in production more 
than one year ago: [ https://blogs.ovirt.org/2019/09/ovirt-and-centos-stream/ | 
https://blogs.ovirt.org/2019/09/ovirt-and-centos-stream/ ] 

BQ_BEGIN

BR Florian 

- Ursprüngliche Mail - 
Von: "users" < [ mailto:users@ovirt.org | users@ovirt.org ] > 
An: "users" < [ mailto:users@ovirt.org | users@ovirt.org ] >, "Jason Keltz" < [ 
mailto:j...@eecs.yorku.ca | j...@eecs.yorku.ca ] > 
Gesendet: Dienstag, 22. Dezember 2020 12:20:04 
Betreff: [ovirt-users] Re: [ANN] oVirt 4.4.4 is now generally available 

You can use OEL or any EL-based clone. 

Best Regards, 
Strahil Nikolov 






В вторник, 22 декември 2020 г., 08:46:54 Гринуич+2, Jason Keltz < [ 
mailto:j...@eecs.yorku.ca | j...@eecs.yorku.ca ] > написа: 






On 12/21/2020 8:22 AM, Sandro Bonazzola wrote: 


> 


oVirt 4.4.4 is now generally available 


The oVirt project is excited to announce the general availability of oVirt 
4.4.4 , as of December 21st, 2020. 

... 



> 
> 
> This release is available now on x86_64 architecture for: 
> 
> * Red Hat Enterprise Linux 8.3 
> * CentOS Linux (or similar) 8.3 
> * CentOS Stream (tech preview) 
> 
> 

Sandro, 

I have a question about "Red Hat Enterprise Linux" compatibility with oVirt. 
I've always used CentOS in the past along with oVirt. I'm running CentOS 7 
along with oVirt 4.3. I really want to upgrade to oVirt 4.4, but I'm not 
comfortable with the future vision for CentOS as it stands for my 
virtualization platform. If I was to move to RHEL for my oVirt systems, but 
still stick with the "self supported" model, it's not clear whether I can get 
away with using "RHEL Workstation" for my 4 hosts ($179 USD each), or whether I 
need to purchase "Red Hat Enterprise Linux Server" ($349 USD each). Any 
feedback would be appreciated. 

Thanks! 


Jason. 

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

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

2020-12-22 Thread Florian Schmid via Users
Hi,

I think the big question is: Will ovirt be tested against such EL-based clones. 
Is ovirt then still 100% compatible to EL, when it will be developed for 
Stream, because Stream will be ahead EL.

Next question is, how stable will be CentOS stream?
At the moment, ovirt is using a lot a packages of different 3rd party repos, 
but the OS system core is still EL clone and stable.
With stream, also the core system is quite new and a way newer than EL, so how 
stable will it be?

Can you then still use CentOS stream + oVirt in production systems?

BR Florian

- Ursprüngliche Mail -
Von: "users" 
An: "users" , "Jason Keltz" 
Gesendet: Dienstag, 22. Dezember 2020 12:20:04
Betreff: [ovirt-users] Re: [ANN] oVirt 4.4.4 is now generally available

You can use OEL or any EL-based clone.

Best Regards,
Strahil Nikolov






В вторник, 22 декември 2020 г., 08:46:54 Гринуич+2, Jason Keltz 
 написа: 






On 12/21/2020 8:22 AM, Sandro Bonazzola wrote:


>  


oVirt 4.4.4 is now generally available


The oVirt project is excited to announce the general availability of oVirt 
4.4.4 , as of December 21st, 2020.

...



>  
>  
> This release is available now on x86_64 architecture for:
> 
> * Red Hat Enterprise Linux 8.3
> * CentOS Linux (or similar) 8.3
> * CentOS Stream (tech preview)
> 
> 

Sandro,

I have a question about "Red Hat Enterprise Linux" compatibility with oVirt.  
I've always used CentOS in the past along with oVirt.  I'm running CentOS 7 
along with oVirt 4.3.  I really want to upgrade to oVirt 4.4, but I'm not 
comfortable with the future vision for CentOS as it stands for my 
virtualization platform.  If I was to move to RHEL for my oVirt systems, but 
still stick with the "self supported" model, it's not clear whether  I can get 
away with using "RHEL Workstation" for my 4 hosts ($179 USD each), or whether I 
need to purchase "Red Hat Enterprise Linux Server" ($349 USD each).  Any 
feedback would be appreciated.

Thanks!  


Jason.

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


[ovirt-users] Re: VM with illegal snapshots

2020-11-17 Thread Florian Schmid via Users


Hi, 




I have also sometimes the issue with snapshots or disk move, which is also 
related to snapshots, when the engine process is running for a longer time. 

After restarting the engine service, then it is working again for several 
weeks, until it gets too long and issues starting again to happen. 




I had never the time to dig in deeper here and I'm never on a version, which is 
still supported, but it would be nice to here, if you maybe have the same 
issue? 

How long was your engine process running, until the issues have started? 




BR Florian 


Von: "Magnus Isaksson"  
An: "Alex K" , "Giorgio Biacchi"  
CC: "users"  
Gesendet: Dienstag, 17. November 2020 10:37:24 
Betreff: [ovirt-users] Re: VM with illegal snapshots 

Hello 

We have the same issue, and not just one VM, we have about 10-15 VMs that have 
either snapshots that are illegal or snapshots that is not possible to remove. 
This have been an issue for quite some time, all since beginning of 4.3 we get 
"vm with illegal snapshots" almost every week, and most often we can remove the 
snapshot and all is ok, but now this have escalated quite much and leaves us 
with customer VM that we may not be able to reboot or that the disk gets 
corrupted, that have happed a few times. 
This is the VM with most snapshots that we are unable to remove any of them. 

Engine is on 4.3.10 and hosts on 4.3.9 

How can i safely remove these snapshots? 
(I am not super comfortable around database "hacking" so some informative 
description would be much appreciated.) 

And how can we eliminate that these things happen? 

Cheers 
Magnus 

From: Alex K  
Sent: 10 November 2020 05:05 
To: Giorgio Biacchi  
Cc: users  
Subject: [ovirt-users] Re: VM with illegal snapshots 


On Fri, Oct 9, 2020, 12:59 Giorgio Biacchi < [ mailto:gior...@di.unimi.it | 
gior...@di.unimi.it ] > wrote: 


Hi, 
due to a bug in our Ovirt integrated backup system now we have some VMs 
with snapshots in illegal state. 

It seems that there's an inconsistency between the db and the real 
status of images on disk. 

Let me show an example: 

engine=# select 
image_guid,parentid,imagestatus,vm_snapshot_id,volume_type,volume_format,active 
from images where image_group_id='e34f77cb-54d5-40d0-b539-e0a5fd512d2d'; 
image_guid | parentid | 
imagestatus | vm_snapshot_id | volume_type | 
volume_format | active 
--+--+-+--+-+---+
 
a107b6c4-842e-4b40-9215-c965431a0c0f | 
---- | 4 | 
d19d6ca3-1989-4c67-8ee7-c0c43b3e6d74 | 2 | 4 | f 
a4c86a68-9123-454c-b417-1b15038a4bf2 | 
a107b6c4-842e-4b40-9215-c965431a0c0f | 1 | 
e7a405ee-8fd4-4733-ae9c-5252bf07c9d3 | 2 | 4 | f 
f6a61f2e-26bd-4b63-97c6-d66913ce48c5 | 
a4c86a68-9123-454c-b417-1b15038a4bf2 | 1 | 
9d0958b9-4995-4e11-a027-a32d4bac52e4 | 2 | 4 | t 
(3 rows) 


[root@host02 ~]# lvs -o+lv_tags |grep e34f77cb-54d5-40d0-b539-e0a5fd512d2d 
a107b6c4-842e-4b40-9215-c965431a0c0f 
459011cf-ebb6-46ff-831d-8ccfafd82c8a -wi--- 149.50g 
IU_e34f77cb-54d5-40d0-b539-e0a5fd512d2d,MD_68,PU_----
 
f6a61f2e-26bd-4b63-97c6-d66913ce48c5 
459011cf-ebb6-46ff-831d-8ccfafd82c8a -wi--- 10.00g 
IU_e34f77cb-54d5-40d0-b539-e0a5fd512d2d,MD_348,PU_a107b6c4-842e-4b40-9215-c965431a0c0f
 

so image guid a4c86a68-9123-454c-b417-1b15038a4bf2 is not present on 
disk, i think that the image was correctly merged but not removed from 
the database. 

Any suggestion on how to fix the database to reflect the real situation 
on disk?? 



In those cases I delete the entry from engine DB to reflect the status of the 
image chain. 

BQ_BEGIN

TIA 
-- 
gb 

PGP Key: [ http://pgp.mit.edu/ | 
http://pgp.mit.edu/ ] 
Primary key fingerprint: C510 0765 943E EBED A4F2 69D3 16CC DC90 B9CB 0F34 
___ 
Users mailing list -- [ mailto:users@ovirt.org | 
users@ovirt.org ] 
To unsubscribe send an email to [ mailto:users-le...@ovirt.org | 
users-le...@ovirt.org ] 
Privacy Statement: [ https://www.ovirt.org/privacy-policy.html | 
https://www.ovirt.org/privacy-policy.html ] 
oVirt Code of Conduct: [ 
https://www.ovirt.org/community/about/community-guidelines/ | 
https://www.ovirt.org/community/about/community-guidelines/ ] 
List Archives: [ 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/OF4NTAC6BPGRP4YJZRWBXQCNBWLERL72/
 | 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/OF4NTAC6BPGRP4YJZRWBXQCNBWLERL72/
 ] 

BQ_END


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

[ovirt-users] Re: rhv 4.3.11 but not ovirt 4.3.11

2020-11-12 Thread Florian Schmid via Users
Hi Sandro, 

will those patches in 4.3.11 also find the way into ovirt 4.4? 

I had also these troubles when upgrading to 4.3.8 and it would be great not 
having them, when upgrading to 4.4. 
[ https://bugzilla.redhat.com/show_bug.cgi?id=1845747 | 
https://bugzilla.redhat.com/show_bug.cgi?id=1845747 ] 

BR Florian Schmid 





Von: "Sandro Bonazzola"  
An: "Gianluca Cecchi"  
CC: "users"  
Gesendet: Montag, 26. Oktober 2020 14:54:37 
Betreff: [ovirt-users] Re: rhv 4.3.11 but not ovirt 4.3.11 



Il giorno gio 22 ott 2020 alle ore 11:21 Gianluca Cecchi < [ 
mailto:gianluca.cec...@gmail.com | gianluca.cec...@gmail.com ] > ha scritto: 



Hello, 
I see that a 4.3.11 version is available for downstream RHV but not for 
upstream oVirt. 
Will it be released for oVirt too? 
Are there only security fixes inside or also bug fixes (like the few lines one 
related to export as OVA)? 



Hi, 
after oVIrt 4.4 gone GA, oVirt 4.3 is not maintained anymore. 
Code included in RHV 4.3.11 is still publicly available but oVirt packages are 
not built and released officially. 



BQ_BEGIN


Thanks, 
Gianluca 
___ 
Users mailing list -- [ mailto:users@ovirt.org | users@ovirt.org ] 
To unsubscribe send an email to [ mailto:users-le...@ovirt.org | 
users-le...@ovirt.org ] 
Privacy Statement: [ https://www.ovirt.org/privacy-policy.html | 
https://www.ovirt.org/privacy-policy.html ] 
oVirt Code of Conduct: [ 
https://www.ovirt.org/community/about/community-guidelines/ | 
https://www.ovirt.org/community/about/community-guidelines/ ] 
List Archives: [ 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/GDLRJXSS525POCOQICJVGXFL55Q4RMWV/
 | 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/GDLRJXSS525POCOQICJVGXFL55Q4RMWV/
 ] 

BQ_END



-- 


Sandro Bonazzola 

MANAGER, SOFTWARE ENGINEERING, EMEA R RHV 

[ https://www.redhat.com/ | Red Hat EMEA ] 


[ mailto:sbona...@redhat.com | sbona...@redhat.com ] 
[ https://www.redhat.com/ ] 
[ https://mojo.redhat.com/docs/DOC-1199578 | Red Hat respects your work life 
balance. Therefore there is no need to answer this email out of your office 
hours. ] 
[ https://www.redhat.com/it/forums/emea/italy-track ] 


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


[ovirt-users] Re: Removal of dpdk

2020-11-04 Thread Florian Schmid via Users


Hi Dominik, 




I don't have any concerns, I only wanted to know, why it will be removed, 
because it can increase network performance a lot. 

Thank you very much for your explanation. 




I fully understand, that you want to remove features, when nobody is using 
them. 




BR Florian 


Von: "Dominik Holler"  
An: "Florian Schmid"  
CC: "Ales Musil" , "users" , "devel" 
 
Gesendet: Mittwoch, 4. November 2020 12:15:47 
Betreff: Re: [ovirt-users] Re: Removal of dpdk 

Hi Florian, 
thanks for your thoughts! 

On Tue, Nov 3, 2020 at 3:21 PM Florian Schmid via Users < [ 
mailto:users@ovirt.org | users@ovirt.org ] > wrote: 



Hi Ales, 

what do you mean with "not maintained for a long time"? 



The oVirt integration of dpdk was not maintained. 

BQ_BEGIN

DPDK is heavily developed and make the linux network extremely fast. 

I don't think, that SR-IOV can replace it, 

BQ_END

The removal of dpdk is about removing the dpdk support from oVirt hosts only. 
We wonder if there is someone using dpdk to attach oVirt VMs to physical NICs. 
We are aware that many users use SR-IOV, especially for scenarios of enabling a 
high count of Ethernet frames for VMs or requiring a low latency, 
but we are not aware of users using dpdk to connect the oVirt VMs to the 
physical NICs of the host. 

BQ_BEGIN

because packets must be still processed by the kernel, which is really slow and 
CPU demanding. 

BQ_END


In SR-IOV the packets might be processed by the guest kernel, not but the host 
kernel. 
oVirt is focused on the host kernel, while the guest OS is managed by the user 
of oVirt. 

Did this explanation address your concerns? 


BQ_BEGIN



BR Florian 


Von: "Ales Musil" < [ mailto:amu...@redhat.com | amu...@redhat.com ] > 
An: "Nir Soffer" < [ mailto:nsof...@redhat.com | nsof...@redhat.com ] > 
CC: "users" < [ mailto:users@ovirt.org | users@ovirt.org ] >, "devel" < [ 
mailto:de...@ovirt.org | de...@ovirt.org ] > 
Gesendet: Dienstag, 3. November 2020 13:56:12 
Betreff: [ovirt-users] Re: Removal of dpdk 



On Tue, Nov 3, 2020 at 1:52 PM Nir Soffer < [ mailto:nsof...@redhat.com | 
nsof...@redhat.com ] > wrote: 

BQ_BEGIN

On Tue, Nov 3, 2020 at 1:07 PM Ales Musil < [ mailto:amu...@redhat.com | 
amu...@redhat.com ] > wrote: 

BQ_BEGIN

Hello, 
we have decided to remove dpdk in the upcoming version of oVirt namely 4.4.4. 
Let us know if there are any concerns about this. 

BQ_END

Can you give more info why we want to remove this feature, and what is 
the replacement for existing users? 

Nir 

BQ_END


Sure, 
the feature was only experimental and not maintained for a long time. The 
replacement is to use SR-IOV 
which is supported by oVirt. 

Thanks, 
Ales 


-- 


Ales Musil 

Software Engineer - RHV Network 

[ https://www.redhat.com/ | Red Hat EMEA ] 


[ mailto:amu...@redhat.com | amu...@redhat.com ] IM: amusil 
[ https://red.ht/sig |   ] 

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


BQ_END


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


[ovirt-users] Re: Removal of dpdk

2020-11-03 Thread Florian Schmid via Users
Hi Ales, 

what do you mean with "not maintained for a long time"? 
DPDK is heavily developed and make the linux network extremely fast. 

I don't think, that SR-IOV can replace it, because packets must be still 
processed by the kernel, which is really slow and CPU demanding. 


BR Florian 


Von: "Ales Musil"  
An: "Nir Soffer"  
CC: "users" , "devel"  
Gesendet: Dienstag, 3. November 2020 13:56:12 
Betreff: [ovirt-users] Re: Removal of dpdk 



On Tue, Nov 3, 2020 at 1:52 PM Nir Soffer < [ mailto:nsof...@redhat.com | 
nsof...@redhat.com ] > wrote: 



On Tue, Nov 3, 2020 at 1:07 PM Ales Musil < [ mailto:amu...@redhat.com | 
amu...@redhat.com ] > wrote: 

BQ_BEGIN

Hello, 
we have decided to remove dpdk in the upcoming version of oVirt namely 4.4.4. 
Let us know if there are any concerns about this. 



Can you give more info why we want to remove this feature, and what is 
the replacement for existing users? 

Nir 

BQ_END


Sure, 
the feature was only experimental and not maintained for a long time. The 
replacement is to use SR-IOV 
which is supported by oVirt. 

Thanks, 
Ales 


-- 


Ales Musil 

Software Engineer - RHV Network 

[ https://www.redhat.com/ | Red Hat EMEA ] 


[ mailto:amu...@redhat.com | amu...@redhat.com ] IM: amusil 
[ https://red.ht/sig |   ] 

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


[ovirt-users] Re: Guest agent ubuntu 20.04

2020-08-13 Thread Florian Schmid via Users
Hi Carl, 

for Ubuntu 20.04, you have to use the qemu-guest-agent alone. 
OGA was not ported to python 3 and is deprecated in 4.4. 

You can also have a look here, when you want to have FQDN in your engine: 
[ 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/BGGFBU24SQAJICU5OR7VOZLBQUZ3CWNJ/
 | 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/BGGFBU24SQAJICU5OR7VOZLBQUZ3CWNJ/
 ] 

BR Florian 





Von: "carl langlois"  
An: "users"  
Gesendet: Donnerstag, 13. August 2020 14:48:19 
Betreff: [ovirt-users] Guest agent ubuntu 20.04 

Hi, 
This may not be the right place to ask but any of you is using Ubuntu 20.04 
guest. I have noticed that the guest agent is not present in the repo.. 

Regards 
Carl 

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


[ovirt-users] Re: qemu-guest-agent on Ubuntu doesn't report FQDN

2020-07-24 Thread Florian Schmid via Users
Hi Didi,

thank you very much for your help.

We will use the FQDN as hostname. This seems to work fine and it will report 
the full name again in oVirt.

BR Florian

- Ursprüngliche Mail -
Von: "Yedidyah Bar David" 
An: "Florian Schmid" 
CC: "Tomas Golembiovsky" , "Sandro Bonazzola" 
, "users" 
Gesendet: Donnerstag, 23. Juli 2020 12:01:14
Betreff: Re: [ovirt-users] Re: qemu-guest-agent on Ubuntu doesn't report FQDN

On Thu, Jul 23, 2020 at 10:23 AM Florian Schmid  wrote:
>
> Hello Yedidyah,
>
> thank you for this great answer.
>
> I will answer in the text below.
>
> BR Florian
>
>
> - Ursprüngliche Mail -
> Von: "Yedidyah Bar David" 
> An: "Florian Schmid" 
> CC: "Tomas Golembiovsky" , "Sandro Bonazzola" 
> , "users" 
> Gesendet: Donnerstag, 23. Juli 2020 08:37:21
> Betreff: Re: [ovirt-users] Re: qemu-guest-agent on Ubuntu doesn't report FQDN
>
> On Wed, Jul 22, 2020 at 5:34 PM Florian Schmid via Users
>  wrote:
> >>
> >> Hi,
> >>
> >> after digging a bit deeper, it looks like it is the problem with the 
> >> qemu-guest-agent.
> >>
> >> It does only report the hostname and nothing more. It uses this function: 
> >> g_get_host_name ()
> >>
> >> This function always returns the value in /etc/hostname and this is 
> >> normally the short name of the VM without the domain part.
> >>
> >> It looks like, that the ovirt-guest-agent made this different,
> >
> >Indeed, and from checking the git log, it seems like it did this since
> >the very first commit - already then,
> >ovirt-guest-agent/GuestAgentLinux2.py had:
> >def getMachineName(self):
> >return socket.getfqdn()
>
> Correct, this is what I wanted back.
>
> >
> >> but this is not working anymore with python 3.
> >
> >If in "this" you refer to ovirt-guest-agent, then it's deprecated:
> >
> >https://bugzilla.redhat.com/show_bug.cgi?id=1672732
>
> Yes, I know. Now using the QGA with oVirt 4.3 reports only the short hostname.
>
> >
> >>
> >> There was a recent patch for qga -> 
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1845127
> >
> >This bug seems to discuss something else, not directly related to your
> >own issue.
> >
> >> but this won't help me, because even when this patch would add the FQDN to 
> >> oVirt back, there won't be a package for this for Ubuntu 20.04 and 
> >> probably also not for RedHat/CentOS 8.
> >
> >Not sure what you mean here. The bug is on qga, and fixing it (or your
> >own issue) is unrelated to oga's deprecation.
>
> I wanted to say, that this change might also impact the reported hostname, 
> but I don't think so...
>
> >
> >Your issue seems to be, to me:
> >
> >1. oga used to report the FQDN, as returned by python's socket.getfqdn()
> >2. qga returns something else (and this something else might be
> >changed, following above bug, but likely not to what you want).
> >3. oVirt now uses qga instead of oga, thus changing its past behavior.
> >4. You want the old behavior back - basically, claiming this is a regression.
>
> Yes, exactly.
>
> >
> >If so, then:
> >
> >1. You are welcome to open a bug about this, on qga.
> >2. Your request *might* be rejected, on the ground of breaking
> >compatibility for existing/old users of qga (say, using virt-manager
> >or whatever other virt tool, without oga installed)
>
> I'm 100 % sure, that they will reject this.
>
> >
> >Alternatively, or if this bug is rejected, you can open two new bugs:
> >
> >1. one on qga, to provide the fqdn (using, hopefully, logic similar to
> >python's getfqdn, although qga is written in C)
>
> Possible, but this won't help me a lot, because even if they add a new 
> function to qga, oVirt would need to be changed too, to access this function 
> instead of the one it is using now.
>
> >2. other on the oVirt engine, to use this new functionality of qga
> >instead of the existing one.
>
> Yes.
>
> >
> >You also have another alternative - just adapt your machines to have
> >the fqdn as the hostname. I personally think this is the best way to
> >go. Have 'hostname' return the FQDN you want, and only use 'hostname
> >-s' where you really want it to be short. How do you set the hostnames
> >of your machines?
>
> This is what I don't know, if this has some drawbacks.
> I have checked this on internet, but haven't find a lot about it, wh

[ovirt-users] Re: qemu-guest-agent on Ubuntu doesn't report FQDN

2020-07-23 Thread Florian Schmid via Users
Hello Yedidyah, 

thank you for this great answer. 

I will answer in the text below. 

BR Florian


- Ursprüngliche Mail -
Von: "Yedidyah Bar David" 
An: "Florian Schmid" 
CC: "Tomas Golembiovsky" , "Sandro Bonazzola" 
, "users" 
Gesendet: Donnerstag, 23. Juli 2020 08:37:21
Betreff: Re: [ovirt-users] Re: qemu-guest-agent on Ubuntu doesn't report FQDN

On Wed, Jul 22, 2020 at 5:34 PM Florian Schmid via Users
 wrote:
>>
>> Hi,
>>
>> after digging a bit deeper, it looks like it is the problem with the 
>> qemu-guest-agent.
>>
>> It does only report the hostname and nothing more. It uses this function: 
>> g_get_host_name ()
>>
>> This function always returns the value in /etc/hostname and this is normally 
>> the short name of the VM without the domain part.
>>
>> It looks like, that the ovirt-guest-agent made this different,
>
>Indeed, and from checking the git log, it seems like it did this since
>the very first commit - already then,
>ovirt-guest-agent/GuestAgentLinux2.py had:
>def getMachineName(self):
>return socket.getfqdn()

Correct, this is what I wanted back.

>
>> but this is not working anymore with python 3.
>
>If in "this" you refer to ovirt-guest-agent, then it's deprecated:
>
>https://bugzilla.redhat.com/show_bug.cgi?id=1672732

Yes, I know. Now using the QGA with oVirt 4.3 reports only the short hostname.

>
>>
>> There was a recent patch for qga -> 
>> https://bugzilla.redhat.com/show_bug.cgi?id=1845127
>
>This bug seems to discuss something else, not directly related to your
>own issue.
>
>> but this won't help me, because even when this patch would add the FQDN to 
>> oVirt back, there won't be a package for this for Ubuntu 20.04 and probably 
>> also not for RedHat/CentOS 8.
>
>Not sure what you mean here. The bug is on qga, and fixing it (or your
>own issue) is unrelated to oga's deprecation.

I wanted to say, that this change might also impact the reported hostname, but 
I don't think so...

>
>Your issue seems to be, to me:
>
>1. oga used to report the FQDN, as returned by python's socket.getfqdn()
>2. qga returns something else (and this something else might be
>changed, following above bug, but likely not to what you want).
>3. oVirt now uses qga instead of oga, thus changing its past behavior.
>4. You want the old behavior back - basically, claiming this is a regression.

Yes, exactly.

>
>If so, then:
>
>1. You are welcome to open a bug about this, on qga.
>2. Your request *might* be rejected, on the ground of breaking
>compatibility for existing/old users of qga (say, using virt-manager
>or whatever other virt tool, without oga installed)

I'm 100 % sure, that they will reject this.

>
>Alternatively, or if this bug is rejected, you can open two new bugs:
>
>1. one on qga, to provide the fqdn (using, hopefully, logic similar to
>python's getfqdn, although qga is written in C)

Possible, but this won't help me a lot, because even if they add a new function 
to qga, oVirt would need to be changed too, to access this function instead of 
the one it is using now.

>2. other on the oVirt engine, to use this new functionality of qga
>instead of the existing one.

Yes.

>
>You also have another alternative - just adapt your machines to have
>the fqdn as the hostname. I personally think this is the best way to
>go. Have 'hostname' return the FQDN you want, and only use 'hostname
>-s' where you really want it to be short. How do you set the hostnames
>of your machines?

This is what I don't know, if this has some drawbacks.
I have checked this on internet, but haven't find a lot about it, what is 
digging deeper.

Maybe someone here has some experience with using FQDN for hostname?

I can live with such a solution, when it doesn't have big drawbacks...

I can set the hostname via ansible, so this would not be a big problem for 
doing it.

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


[ovirt-users] Re: qemu-guest-agent on Ubuntu doesn't report FQDN

2020-07-22 Thread Florian Schmid via Users
Hi, 

after digging a bit deeper, it looks like it is the problem with the 
qemu-guest-agent. 

It does only report the hostname and nothing more. It uses this function: 
g_get_host_name () 

This function always returns the value in /etc/hostname and this is normally 
the short name of the VM without the domain part. 

It looks like, that the ovirt-guest-agent made this different, but this is not 
working anymore with python 3. 

There was a recent patch for qga -> [ 
https://bugzilla.redhat.com/show_bug.cgi?id=1845127 | 
https://bugzilla.redhat.com/show_bug.cgi?id=1845127 ] 
but this won't help me, because even when this patch would add the FQDN to 
oVirt back, there won't be a package for this for Ubuntu 20.04 and probably 
also not for RedHat/CentOS 8. 

BR Florian 





Von: "users"  
An: "Sandro Bonazzola"  
CC: "users"  
Gesendet: Montag, 20. Juli 2020 09:06:30 
Betreff: [ovirt-users] Re: qemu-guest-agent on Ubuntu doesn't report FQDN 

Hi, 

when setting hostnamectl set-hostname "FQDN", then engine will report the real 
and correct "FQDN", but this is not a good fix. 

With our older Debian and Ubuntu VMs, it is working correctly, although 
hostname is only reporting the short hostname. hostname -f is reporting here 
the correct FQDN. 

BR Florian 





 
UBIMET GmbH - weather matters 
Ing. Florian Schmid • IT Infrastruktur Austria 


A-1220 Wien • Donau-City-Straße 11 • Tel +43 1 263 11 22 DW 469 • Fax +43 1 263 
11 22 219 
fsch...@ubimet.com • www.ubimet.com • Mobile: +43 664 8323379 


Sitz: Wien • Firmenbuchgericht: Handelsgericht Wien • FN 248415 t 


 



The information contained in this message (including any attachments) is 
confidential and may be legally privileged or otherwise protected from 
disclosure. This message is intended solely for the addressee(s). If you are 
not the intended recipient, please notify the sender by return e-mail and 
delete this message from your system. Any unauthorized use, reproduction, or 
dissemination of this message is strictly prohibited. Please note that e-mails 
are susceptible to change. UBIMET GmbH shall not be liable for the improper or 
incomplete transmission of the information contained in this communication, nor 
shall it be liable for any delay in its receipt. UBIMET GmbH accepts no 
liability for loss or damage caused by software viruses and you are advised to 
carry out a virus check on any attachments contained in this message. 





Von: "Sandro Bonazzola"  
An: "Florian Schmid" , "Tomas Golembiovsky" 
 
CC: "users"  
Gesendet: Freitag, 17. Juli 2020 09:21:37 
Betreff: Re: [ovirt-users] qemu-guest-agent on Ubuntu doesn't report FQDN 



Il giorno gio 16 lug 2020 alle ore 15:55 Florian Schmid via Users < [ 
mailto:users@ovirt.org | users@ovirt.org ] > ha scritto: 


Hi, 

I have a problem with Ubuntu 20.04 VM reporting the correct FQDN to the engine. 
Starting with this release, the ovirt-guest-agent is not available anymore. 

Therefore, I have installed qemu-geust-agent with package defaults. 

Now in the Engine, I only see the hostname under FQDN tab, instead the real 
full name with domain. 

I'm running an oVirt environment on 4.3.8. 

The VM is resolveable, forward and reverse DNS entries are working. 
hostname -f shows the correct FQDN. 

Even adding IP and FQDN to /etc/hosts file doesn't change anything. 

qemu-guest-agent version: 4.2-3ubuntu6.3 

I manage this VM via ansible 2.9 and ansible is able to get the FQDN of the VM 
without any issues... 

What can I do here to debug my issue? 
Does the engine cache the wrong result? Even after stopping and starting the VM 
again, engine is only showing the hostname instead of the FQDN. 




[ mailto:tgole...@redhat.com | +Tomas Golembiovsky ] can you help here? 



BQ_BEGIN
Best regards, 
Florian 
___ 
Users mailing list -- [ mailto:users@ovirt.org | users@ovirt.org ] 
To unsubscribe send an email to [ mailto:users-le...@ovirt.org | 
users-le...@ovirt.org ] 
Privacy Statement: [ https://www.ovirt.org/privacy-policy.html | 
https://www.ovirt.org/privacy-policy.html ] 
oVirt Code of Conduct: [ 
https://www.ovirt.org/community/about/community-guidelines/ | 
https://www.ovirt.org/community/about/community-guidelines/ ] 
List Archives: [ 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/BGGFBU24SQAJICU5OR7VOZLBQUZ3CWNJ/
 | 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/BGGFBU24SQAJICU5OR7VOZLBQUZ3CWNJ/
 ] 

BQ_END



-- 


Sandro Bonazzola 

MANAGER, SOFTWARE ENGINEERING, EMEA R RHV 

[ https://www.redhat.com/ | Red Hat EMEA ] 


[ mailto:sbona...@redhat.com | sbona...@redhat.com ] 
[ https://

[ovirt-users] Re: qemu-guest-agent on Ubuntu doesn't report FQDN

2020-07-20 Thread Florian Schmid via Users
Hi, 

when setting hostnamectl set-hostname "FQDN", then engine will report the real 
and correct "FQDN", but this is not a good fix. 

With our older Debian and Ubuntu VMs, it is working correctly, although 
hostname is only reporting the short hostname. hostname -f is reporting here 
the correct FQDN. 

BR Florian 





 
UBIMET GmbH - weather matters 
Ing. Florian Schmid • IT Infrastruktur Austria 


A-1220 Wien • Donau-City-Straße 11 • Tel +43 1 263 11 22 DW 469 • Fax +43 1 263 
11 22 219 
fsch...@ubimet.com • www.ubimet.com • Mobile: +43 664 8323379 


Sitz: Wien • Firmenbuchgericht: Handelsgericht Wien • FN 248415 t 


 



The information contained in this message (including any attachments) is 
confidential and may be legally privileged or otherwise protected from 
disclosure. This message is intended solely for the addressee(s). If you are 
not the intended recipient, please notify the sender by return e-mail and 
delete this message from your system. Any unauthorized use, reproduction, or 
dissemination of this message is strictly prohibited. Please note that e-mails 
are susceptible to change. UBIMET GmbH shall not be liable for the improper or 
incomplete transmission of the information contained in this communication, nor 
shall it be liable for any delay in its receipt. UBIMET GmbH accepts no 
liability for loss or damage caused by software viruses and you are advised to 
carry out a virus check on any attachments contained in this message. 





Von: "Sandro Bonazzola"  
An: "Florian Schmid" , "Tomas Golembiovsky" 
 
CC: "users"  
Gesendet: Freitag, 17. Juli 2020 09:21:37 
Betreff: Re: [ovirt-users] qemu-guest-agent on Ubuntu doesn't report FQDN 



Il giorno gio 16 lug 2020 alle ore 15:55 Florian Schmid via Users < [ 
mailto:users@ovirt.org | users@ovirt.org ] > ha scritto: 


Hi, 

I have a problem with Ubuntu 20.04 VM reporting the correct FQDN to the engine. 
Starting with this release, the ovirt-guest-agent is not available anymore. 

Therefore, I have installed qemu-geust-agent with package defaults. 

Now in the Engine, I only see the hostname under FQDN tab, instead the real 
full name with domain. 

I'm running an oVirt environment on 4.3.8. 

The VM is resolveable, forward and reverse DNS entries are working. 
hostname -f shows the correct FQDN. 

Even adding IP and FQDN to /etc/hosts file doesn't change anything. 

qemu-guest-agent version: 4.2-3ubuntu6.3 

I manage this VM via ansible 2.9 and ansible is able to get the FQDN of the VM 
without any issues... 

What can I do here to debug my issue? 
Does the engine cache the wrong result? Even after stopping and starting the VM 
again, engine is only showing the hostname instead of the FQDN. 




[ mailto:tgole...@redhat.com | +Tomas Golembiovsky ] can you help here? 



BQ_BEGIN
Best regards, 
Florian 
___ 
Users mailing list -- [ mailto:users@ovirt.org | users@ovirt.org ] 
To unsubscribe send an email to [ mailto:users-le...@ovirt.org | 
users-le...@ovirt.org ] 
Privacy Statement: [ https://www.ovirt.org/privacy-policy.html | 
https://www.ovirt.org/privacy-policy.html ] 
oVirt Code of Conduct: [ 
https://www.ovirt.org/community/about/community-guidelines/ | 
https://www.ovirt.org/community/about/community-guidelines/ ] 
List Archives: [ 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/BGGFBU24SQAJICU5OR7VOZLBQUZ3CWNJ/
 | 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/BGGFBU24SQAJICU5OR7VOZLBQUZ3CWNJ/
 ] 

BQ_END



-- 


Sandro Bonazzola 

MANAGER, SOFTWARE ENGINEERING, EMEA R RHV 

[ https://www.redhat.com/ | Red Hat EMEA ] 


[ mailto:sbona...@redhat.com | sbona...@redhat.com ] 
[ https://www.redhat.com/ ] 
[ https://mojo.redhat.com/docs/DOC-1199578 | Red Hat respects your work life 
balance. Therefore there is no need to answer this email out of your office 
hours. ] 

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


[ovirt-users] Re: qemu-guest-agent on Ubuntu doesn't report FQDN

2020-07-16 Thread Florian Schmid via Users
Hi Strahil,

no, the hosts file should be OK:
127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts


When adding an additional line, like this:
192.168.1.1 FQDN hostname

it is also not working.

This is the same hosts file like on our older Ubuntu 18.04 systems, but with 
ovirt-guest-agent installed.

BR Florian


- Ursprüngliche Mail -
Von: "Strahil Nikolov" 
An: "Florian Schmid" , "users" 
Gesendet: Donnerstag, 16. Juli 2020 18:17:22
Betreff: Re: [ovirt-users] qemu-guest-agent on Ubuntu doesn't report FQDN

Can you share your /etc/hosts.
As far as I remember there was an entry like:

127.0.1.2 hostname

So you have to comment it out.

Best Regards,
Strahil Nikolov

На 16 юли 2020 г. 16:53:36 GMT+03:00, Florian Schmid via Users 
 написа:
>Hi,
>
>I have a problem with Ubuntu 20.04 VM reporting the correct FQDN to the
>engine.
>Starting with this release, the ovirt-guest-agent is not available
>anymore.
>
>Therefore, I have installed qemu-geust-agent with package defaults.
>
>Now in the Engine, I only see the hostname under FQDN tab, instead the
>real full name with domain.
>
>I'm running an oVirt environment on 4.3.8.
>
>The VM is resolveable, forward and reverse DNS entries are working.
>hostname -f shows the correct FQDN.
>
>Even adding IP and FQDN to /etc/hosts file doesn't change anything.
>
>qemu-guest-agent version: 4.2-3ubuntu6.3
>
>I manage this VM via ansible 2.9 and ansible is able to get the FQDN of
>the VM without any issues...
>
>What can I do here to debug my issue?
>Does the engine cache the wrong result? Even after stopping and
>starting the VM again, engine is only showing the hostname instead of
>the FQDN.
>
>Best regards,
>Florian
>___
>Users mailing list -- users@ovirt.org
>To unsubscribe send an email to users-le...@ovirt.org
>Privacy Statement: https://www.ovirt.org/privacy-policy.html
>oVirt Code of Conduct:
>https://www.ovirt.org/community/about/community-guidelines/
>List Archives:
>https://lists.ovirt.org/archives/list/users@ovirt.org/message/BGGFBU24SQAJICU5OR7VOZLBQUZ3CWNJ/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/AEGO7OBASTEDT66MZSW2TSYC3RPMC6PI/


[ovirt-users] qemu-guest-agent on Ubuntu doesn't report FQDN

2020-07-16 Thread Florian Schmid via Users
Hi,

I have a problem with Ubuntu 20.04 VM reporting the correct FQDN to the engine.
Starting with this release, the ovirt-guest-agent is not available anymore.

Therefore, I have installed qemu-geust-agent with package defaults.

Now in the Engine, I only see the hostname under FQDN tab, instead the real 
full name with domain.

I'm running an oVirt environment on 4.3.8.

The VM is resolveable, forward and reverse DNS entries are working.
hostname -f shows the correct FQDN.

Even adding IP and FQDN to /etc/hosts file doesn't change anything.

qemu-guest-agent version: 4.2-3ubuntu6.3

I manage this VM via ansible 2.9 and ansible is able to get the FQDN of the VM 
without any issues...

What can I do here to debug my issue?
Does the engine cache the wrong result? Even after stopping and starting the VM 
again, engine is only showing the hostname instead of the FQDN.

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


[ovirt-users] Re: cloud-init: reverts on reboot

2020-06-12 Thread Florian Schmid via Users
Hi,

we are using cloud-init for several years now and it looks like, that 
cloud-init needs a config for every boot, otherwise, it will use the default 
network config, which is DHCP.

We come around this issue by adding this file:
cat /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
network: {config: disabled}

by cloud-init itself on the first run.

With this, cloud-init creates only once the network config and never touches it 
again.
I would not completely disable cloud-init, because this could also have some 
drawbacks, like not being able to create a root/user password anymore, if on 
worst case, ssh is not working anymore...

What we also fix on the first boot is the datasource_list
-> datasource_list: ["NoCloud", "ConfigDrive"]

Otherwise, we have an extremely long boot process (up to 5 minutes or so), 
because cloud-init tries to reach several cloud-config URLs.

BR Florian

- Ursprüngliche Mail -
Von: "Jp" 
An: "users" 
Gesendet: Donnerstag, 11. Juni 2020 16:54:31
Betreff: [ovirt-users] Re: cloud-init: reverts on reboot

I re-read the docs on creating VMs.

What is the difference between the Run Once w/ it's pop-up form vs the Initial 
Run with it's embedded form?

If an (updated) doc were to have a sequential workflow for using cloud-init in 
oVirt for a new VM's setup, would it look like this:

* assume cloud-init already installed, ex. Glance image; so SysPre/Cloud-Init 
process already done*

Glance Image Method

1. Import Image + Create Template
2. Create VM (_don't_ use Run; and _don't_ populate Initial Run tab)
3. start VM with Run Once (_not_ Run)
4. fill out Run Once pop-up form
5. VM boots as usual
6. remote Console/shell into VM to verify setting
7. Reboot or Shutdown/Run
8. use cloud-init'd VM like any other non-cloud-init'd VM

That ^ look right?
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/LXA4TCGENOQ3PPNGTCRPZQQJYXSR52QI/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/CE7MMZEETR3E5CQUGQ3RBI6KXFVOLUMD/