[ovirt-users] Re: How to Upgrade Node with Local Storage ?

[Vojtech Juranek]

On Wednesday, 21 April 2021 16:40:29 CEST Nur Imam Febrianto wrote:
> Set global maintenance and then turn off all vm, do yum update but it
> completed with failed. Am I missing something ?

can you share the details? What failed, wthat was the error?


> From: Adam Xu
> Sent: 20 April 2021 7:36
> To: users@ovirt.org
> Subject: [ovirt-users] Re: How to Upgrade Node with Local Storage ?
> 
> 
> For  oVirt Node that using Local Storage, I think you should shutdown all
> your vms before you upgrade the Node. 在 2021/4/19 22:09, Nur Imam Febrianto
> 写道:
> Hi,
> 
> How we can upgrade oVirt Node that using Local Storage ? Seems I cant find
> any good documentation about this. Planning to upgrade one 4.4.4 node with
> local storage to 4.4.5.
> Thanks before.
> 
> Regards,
> Nur Imam Febrianto
> 
> 
> 
> ___
> 
> 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 on.outlook.com/?url=https%3A%2F%2Fwww.ovirt.org%2Fprivacy-policy.html=0
> 4%7C01%7C%7C2817620cd2134104f81908d90394654e%7C84df9e7fe9f640afb435a
> aaa%7C1%7C0%7C637544758156873163%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=VV663qDHl6C24C0
> XTZLoUF4n%2Bm4umP4dkG1EsKS895E%3D=0>
> 
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/ safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovirt.org%2Fcommunit
> y%2Fabout%2Fcommunity-guidelines%2F=04%7C01%7C%7C2817620cd2134104f81908
> d90394654e%7C84df9e7fe9f640afb435%7C1%7C0%7C637544758156883118%7
> CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> CJXVCI6Mn0%3D%7C1000=XF1vC3JCyVjQCsD1x%2FDQinfKOImw5VJbZIryDg9sKKg%3D&
> reserved=0>
> 
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZOCHCAJPXO4LT
> IMA4JHK3WMR5CTKR37C/ tps%3A%2F%2Flists.ovirt.org%2Farchives%2Flist%2Fusers%40ovirt.org%2Fmessage%
> 2FZOCHCAJPXO4LTIMA4JHK3WMR5CTKR37C%2F=04%7C01%7C%7C2817620cd2134104f819
> 08d90394654e%7C84df9e7fe9f640afb435%7C1%7C0%7C637544758156883118
> %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw
> iLCJXVCI6Mn0%3D%7C1000=raH9RGOWlZIWlj%2FCWFJUbqI94y0U2TR9lUukXhzi2B8%3
> D=0>



signature.asc
Description: This is a digitally signed message part.
___
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/JVTFTHF3LSGAFHBKN4X6W63HSEK3BFFX/

[ovirt-users] Re: What software used to take forever incremental backup from VM?

[Annie Blackwell]

Sounds interesting..maybe I'll give it a try to evaluate.
___
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/JOYBYFE5RLCS2OOBKPEIKLFNHHZKKV45/

[ovirt-users] Re: What software used to take forever incremental backup from VM?

[Annie Blackwell]

Thanks!I'll try
___
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/6Y3QKRHGORV6OJY4J2PLFPC3LIJZJTOS/

[ovirt-users] Re: What software used to take forever incremental backup from VM?

[Annie Blackwell]

Thanks for the advice, I installed vprotect and try to test, but it's not 
friendly at all, I need an easy to handle tool, not difficult to understand and 
manage, I don't want to waste my time on exploring it. 
___
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/K7GFEEHAIXYUVRB47XLWFKGZEHQ7MKW4/

[ovirt-users] Re: How to Upgrade Node with Local Storage ?

[Adam Xu]

在 2021/4/21 22:40, Nur Imam Febrianto 写道:


Set global maintenance and then turn off all vm, do yum update but it 
completed with failed.


Am I missing something ?

where is your ovirt engine ? is it running in that local storage or in a 
standalone server?


*From: *Adam Xu 
*Sent: *20 April 2021 7:36
*To: *users@ovirt.org 
*Subject: *[ovirt-users] Re: How to Upgrade Node with Local Storage ?

For  oVirt Node that using Local Storage, I think you should shutdown 
all your vms before you upgrade the Node.


在 2021/4/19 22:09, Nur Imam Febrianto 写道:

Hi,

How we can upgrade oVirt Node that using Local Storage ? Seems I
cant find any good documentation about this.

Planning to upgrade one 4.4.4 node with local storage to 4.4.5.

Thanks before.

Regards,

Nur Imam Febrianto



___

Users mailing list --users@ovirt.org  

To unsubscribe send an email tousers-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/ZOCHCAJPXO4LTIMA4JHK3WMR5CTKR37C/
  



___
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/ZIWFVG73Y5CBSBVRSSBNQQJMJ2AEVJV6/
___
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/O4Z6FBPIAB34BFJCB35PZECUCW4BDQHP/

[ovirt-users] Re: pool list vm assign user

[Dominique D]

I found this a "select command" on this link 
https://bugzilla.redhat.com/show_bug.cgi?id=1462236

I use ovirt 4.4

But where I execute this command : 

engine=# select s.vm_name, d.status, u.name from vm_static s, vm_dynamic d, 
permissions p, users u
where
s.vm_guid = d.vm_guid and
u.user_id = p.ad_element_id and
p.object_type_id = 2 and
p.object_id = s.vm_guid and
s.vm_name ilike '%VMPOOL%' ORDER BY vm_name;
   vm_name| status | name 
--++--
 VMPOOL-1   |  1 | ADRIAN
 VMPOOL-10  |  1 | ADRIAN
___
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/DPCDBK4LNEKJTKG6HFT4GXBHUV3TYDE2/

[ovirt-users] Re: How to update ovirt-sdk

[Miguel Garcia]

The command you describe above seems to be for CentOS8 while the system we use 
is CentOS7.

Is python3-ovirt-engie-sdk4 is supported for centos7?
___
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/JVBW4SYMBMJZMXIKZXONHMUZ5DDMJNH2/

[ovirt-users] Re: Moving templates and their thin based VMs

[Chris Adams]

Once upon a time, Gianluca Cecchi  said:
> This means that if I do this I create a break in the dependency of the VM
> from the particular storage domain, correct?

Yes.  I just finished moving some VMs based on templates from one
storage domain to another (for some of these, I think this is the third
SAN these VMs/templates have lived on, now in the second physical
location 5 miles away :) ).

> And what if later I go and edit the template, changing its properties? I
> think they are only metadata that doesn't imply any modification of the
> disk itself, that is now present in more than one domain, correct?

AFAIK template settings are all in the database on the engine.  The disk
image on storage is just that: a disk image.
-- 
Chris Adams 
___
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/OVKKM42NXMWZEPROFS2ZQFKBN72B2CQ7/

[ovirt-users] Re: FreeBSD 13 and virtio

[Nur Imam Febrianto]

Thanks. Using this q356 confirm it works. But found another strange issue. On 2 
Core CPU  VM, one of the vCPU are used 100% by system. Switching back to i440fx 
and that problem is gone. Don’t know what’s wrong. Will try to find another 
clue and ask another BSD user for this.

Thanks before for sharing your config.

Regards,
Nur Imam Febrianto
From: tho...@hoberg.net
Sent: 20 April 2021 20:09
To: 'Nur Imam Febrianto'; 
users@ovirt.org
Subject: AW: [ovirt-users] Re: FreeBSD 13 and virtio

I am attaching both working configs here.

Von: Nur Imam Febrianto 
Gesendet: Dienstag, 20. April 2021 14:14
An: Thomas Hoberg ; users@ovirt.org
Betreff: [ovirt-users] Re: FreeBSD 13 and virtio

Seems strange. I want to use q35, but whenever I try even to start the 
installation (vm disk using virtio-scsi/virtio, net adapter using virtio) it 
always shows me the installer doesn’t detect any disk. I have an existing VM 
too that recently upgraded from 12.2 to 13. It uses i440FX with virtio-scsi 
disk and virtio network. If I try to change the machine into q35, it keeps 
stuck at boot after “promiscuous mode enabled”.
Don’t know what’s wrong. Using oVirt 4.4.5. Can you share your VM Config ?

From: Thomas Hoberg
Sent: 20 April 2021 17:27
To: users@ovirt.org
Subject: [ovirt-users] Re: FreeBSD 13 and virtio

q35 with BIOS as that is the cluster default with >4.3.

Running the dmesg messages through my mind as I remember them, the vio hardware 
may be all PCIe based, which would explain why this won't work on a virtual FX 
440FX system, because those didn't have PCIe support AFAIK.

Any special reason why you'd want them based on 440FX?

And I also tested with GhostBSD, which is still 12.* based, and that doesn't 
seem to have vio support, at least I could not see a hard disk there, which 
confirms your observation there.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to 
users-le...@ovirt.org
Privacy Statement: 
https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovirt.org%2Fprivacy-policy.htmldata=04%7C01%7C%7C71e5972978224d31def708d903e6f09b%7C84df9e7fe9f640afb435%7C1%7C0%7C637545112683975628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=effZxEik3q1lfTBn%2BBi4DXIQM6wVJfgiQ7%2Fqr0W1dLM%3Dreserved=0
oVirt Code of Conduct: 
https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovirt.org%2Fcommunity%2Fabout%2Fcommunity-guidelines%2Fdata=04%7C01%7C%7C71e5972978224d31def708d903e6f09b%7C84df9e7fe9f640afb435%7C1%7C0%7C637545112683975628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=rvQ12IpSElU9D23G7HJvPz%2FvqqZ0OaUhJ3wI%2BRslIQY%3Dreserved=0
List Archives: 
https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ovirt.org%2Farchives%2Flist%2Fusers%40ovirt.org%2Fmessage%2F7ZWDRPXM6G25H4VRE3OUAH25UIY4JVI3%2Fdata=04%7C01%7C%7C71e5972978224d31def708d903e6f09b%7C84df9e7fe9f640afb435%7C1%7C0%7C637545112683975628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=qDf%2BRNi1PXI2cf%2F4XFc6qHCTY6lqOX9lE5Qvyhg4Xls%3Dreserved=0


___
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: 

[ovirt-users] Re: How to Upgrade Node with Local Storage ?

[Nur Imam Febrianto]

Set global maintenance and then turn off all vm, do yum update but it completed 
with failed.
Am I missing something ?

From: Adam Xu
Sent: 20 April 2021 7:36
To: users@ovirt.org
Subject: [ovirt-users] Re: How to Upgrade Node with Local Storage ?


For  oVirt Node that using Local Storage, I think you should shutdown all your 
vms before you upgrade the Node.
在 2021/4/19 22:09, Nur Imam Febrianto 写道:
Hi,

How we can upgrade oVirt Node that using Local Storage ? Seems I cant find any 
good documentation about this.
Planning to upgrade one 4.4.4 node with local storage to 4.4.5.
Thanks before.

Regards,
Nur Imam Febrianto



___

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

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

[ovirt-users] Re: Moving templates and their thin based VMs

[Gianluca Cecchi]

On Wed, Apr 21, 2021 at 3:55 PM Chris Adams  wrote:

> Once upon a time, Gianluca Cecchi  said:
> > But some of these VMs had disk with storage allocation of type "Thin" on
> > their related template.
> > So I was both unable to move these templates and VMs disks...
>
> You can copy (rather than move) a template to the new storage domain,
> then any thin-provisioned disks that rely on the template can be moved.
>
> --
> Chris
>

Thank, Chris!

I didn't notice this.
So I can select in Storage --> DIsks the disk corresponding to a template,
then I see I can copy it to another storage domain.
And then the template continues to be one, but in Compute --> Templates
select template, DIsks I see now one disk with a "+" sign and expanding it
I see the two domains.
Great!

This means that if I do this I create a break in the dependency of the VM
from the particular storage domain, correct?
And what if later I go and edit the template, changing its properties? I
think they are only metadata that doesn't imply any modification of the
disk itself, that is now present in more than one domain, correct?

Gianluca
___
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/TC2SPXK3LJV6B5TFMXH57WUN4CPZGURS/

[ovirt-users] Re: Moving templates and their thin based VMs

[Chris Adams]

Once upon a time, Gianluca Cecchi  said:
> But some of these VMs had disk with storage allocation of type "Thin" on
> their related template.
> So I was both unable to move these templates and VMs disks...

You can copy (rather than move) a template to the new storage domain,
then any thin-provisioned disks that rely on the template can be moved.

-- 
Chris Adams 
___
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/7FX57CSNOYTTJAAY4G3GZDKLLWIZ464X/

[ovirt-users] Moving templates and their thin based VMs

[Gianluca Cecchi]

Hello,
I had to free up and reformat a storage domain where I had some templates
and many VMs.
I was able to move to other existing storage domains disks of VMs created
with "Clone" Storage Allocation
But some of these VMs had disk with storage allocation of type "Thin" on
their related template.
So I was both unable to move these templates and VMs disks...

I was able to export as OVA the templates and then import again them (with
another name "_Copy") on to another storage domain then remove VMs and
templates and rename templates' names...

Are there any chances to better solve these kind of problems if one has to
decommission a storage domain? Only export of all VMs and related templates?

Is there a way to "consolidate" the disks of an existing "Thin" based
storage allocation to Clone?
Possibly I can clone the VM?

Thanks in advance,

Gianluca
___
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/3P57FIIJ5255QG32DX56MHT66XY2XOIK/

[ovirt-users] Re: How do I share a disk across multiple VMs?

[Sandro Bonazzola]

Il giorno mer 21 apr 2021 alle ore 11:02 Thomas Hoberg 
ha scritto:

> >
> > You're welcome to help with oVirt project design and discuss with the
> > community the parts that you think should benefit from a re-design.
>
> I consider these pesky little comments part of the discussion, even if I
> know they are not the best style.
>
> But how much is there to discuss, if Redhat has already decided to switch
> to a beta base (CentOS stream) underneath oVirt?
>
> Nobody wants bleeding edge on a hypervisor, except those who develop that
> hypervisor.
>

I can understand the position here, but the fact that oVirt is developed
and stabilized against CentOS Stream which is upstream to RHEL doesn't
prevent you to run oVirt on RHEL or any other RHEL rebuild on production.
If you face any issue running oVirt on top of a downstream to CentOS Stream
please report a bug for it and we'll be happy to handle.


>
> oVirt is supposed to deliver a higher reliability than bare metal
> hardware, by providing a fault tolerant design and automatic fault recovery.
>
> But if the software stack that the HA engine builds on is more volatile
> than the hardware below, it simply can't do its work of increasing overall
> resilience: a beta OS kills the value of a HA management stack above.
>
> Only a RHEL downstream CentOS is near solid enough to build on (unless you
> did fully validated oVirt node images). Bleeding edge is what you put
> inside the VMs, not underneath. I don't think I have heard a single oVirt
> *user* advocating the switch to Stream. IMHO it's political and kills
> oVirt's value proposition.
>

And I understand the point of view on this and I've nothing against this.
CentOS Linux 8 is going to reach EOL in a few months and oVirt project
can't keep using it for development.
CentOS Stream is upstream to whatever CentOS Stream derivative (including
RHEL) oVirt users are going to use in production so we need to ensure oVirt
will run on what's coming next in order to avoid oVirt users to get broken
systems once an update will come to production. So from oVirt development
perspective CentOS Stream right now is the only choice.
That said, really, on production you are not required to use CentOS Stream
if you don't want to.



>
> My next major other gripe is that to a newcomer it's not obvious from the
> start that the oVirt 'classic' and the HCI variant are and will most likely
> remain very different beasts, because they have a distinct history and
> essentially incompatible principles.
>
> Classic oVirt started with shared storage, which is always turned on.
> Theat means idle hosts can be turned off and workloads consolidated to
> minimize energy consumption. It aims for the minimal number of hosts to do
> the job.
>
> Gluster is all about scale out without any choke points, the more hosts
> the better the performance.
>
> And when you combine both in a HCI gluster, turning off hosts requires a
> much better attention as to whether these hosts contribute bricks to
> volumes in use or not.
>
> For a user it's quite natural to mix both, using a set of HCI nodes to
> provide storage and base capacity and then add pure compute nodes to
> provide dynamic workload expansion.
>
> But now I'm pretty sure that's unchartered territory, because I see
> terrible things happening with quota decisions when computing nodes that
> don't even contribute bricks to volumes are rebooted e.g. during updates.
>

And this can be made more clear either on the download page or in the
installation guide documentation for new comers.
Let's do it. I can open a PR on https://github.com/oVirt/ovirt-site or you
can do it and  we can work together on ensuring this will be clear for new
comers.


>
> Making the community responsible for providing a unifying vision, is
> asking for help a bit too late in the game.
>
> And then classic oVirt and HCI oVirt have completely different scaling
> characteristics. Classic will scale from one to N hosts without any issue,
> but HCI won't even go from 1 to 2 or the more sensible 3 nodes. Nor does it
> then allow the transition from replicas to the obviously more attractive
> dispersion volumes as you expand from 3 to 6 or 9 nodes.
>
> How much of a discussion will we have, when I say that I want a Gluster
> volume to expand/grow/shrink and transform from 1 to N bricks and
> transition between replicas, dispersed volumes, sharded or non sharded with
> oVirt seamlessly running on top?
>

I'll let Gluster team discuss this, I lack the needed knowledge to give
meaningful replies.


>
> But unfortunately that is the natural expectation any newcomer will have,
> just like I did, when I read all the nice things Redhat had to say about
> the technology.
>
> I hope you won't dispute it's still very much a patchwork and with a very
> small chance of near time resolution.
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> 

[ovirt-users] Re: How do I share a disk across multiple VMs?

[Gianluca Cecchi]

On Wed, Apr 21, 2021 at 11:02 AM Thomas Hoberg  wrote:

> >
> > You're welcome to help with oVirt project design and discuss with the
> > community the parts that you think should benefit from a re-design.
>
> I consider these pesky little comments part of the discussion, even if I
> know they are not the best style.
>
> But how much is there to discuss, if Redhat has already decided to switch
> to a beta base (CentOS stream) underneath oVirt?
>
> Nobody wants bleeding edge on a hypervisor, except those who develop that
> hypervisor.
>
> oVirt is supposed to deliver a higher reliability than bare metal
> hardware, by providing a fault tolerant design and automatic fault recovery.
>
>
>
Only to point out that between core components of this type of hypervisor
are for sure libvirt and qemu-kvm and these two components were never the
ones provided OOTB by the downstream RHEL version.
Also vdsm for example, that is another core component, was never part of
the downstream OS.

In 4.2 deps.repo:
[ovirt-4.2-epel]
mirrorlist=
https://mirrors.fedoraproject.org/metalink?repo=epel-7=$basearch
[ovirt-4.2-centos-gluster312]
baseurl=http://mirror.centos.org/centos/7/storage/$basearch/gluster-3.12/
[ovirt-4.2-virtio-win-latest]
baseurl=http://fedorapeople.org/groups/virt/virtio-win/repo/latest
[ovirt-4.2-centos-qemu-ev]
baseurl=http://mirror.centos.org/centos/7/virt/$basearch/kvm-common/
[ovirt-4.2-centos-opstools]
baseurl=http://mirror.centos.org/centos/7/opstools/$basearch/
[centos-sclo-rh-release]
baseurl=http://mirror.centos.org/centos/7/sclo/$basearch/rh/
[ovirt-4.2-centos-ovirt42]
baseurl=http://mirror.centos.org/centos/7/virt/$basearch/ovirt-4.2/

In 4.3 deps.repo:
[ovirt-4.3-epel]
mirrorlist=
https://mirrors.fedoraproject.org/metalink?repo=epel-7=$basearch
[ovirt-4.3-centos-gluster6]
baseurl=http://mirror.centos.org/centos/7/storage/$basearch/gluster-6/
[ovirt-4.3-virtio-win-latest]
baseurl=http://fedorapeople.org/groups/virt/virtio-win/repo/latest
[ovirt-4.3-centos-qemu-ev]
baseurl=http://mirror.centos.org/centos/7/virt/$basearch/kvm-common/
[ovirt-4.3-centos-ovirt43]
baseurl=http://mirror.centos.org/centos/7/virt/$basearch/ovirt-4.3/
[ovirt-4.3-centos-ovirt-common]
baseurl=http://mirror.centos.org/centos/7/virt/$basearch/ovirt-common/
[ovirt-4.3-centos-opstools]
baseurl=http://mirror.centos.org/centos/7/opstools/$basearch/
[centos-sclo-rh-release]
baseurl=http://mirror.centos.org/centos/7/sclo/$basearch/rh/

Gianluca
___
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/XFCSBFPCQS6XFLHLUF7SUYH5BI3NNLH5/

[ovirt-users] Re: Cannot delete snapshot

[Giulio Casella]

I tried, with no luck. Giving "disk snapshot id" as a parameter to that
psql procedure nothing happened. Giving the "vm_snapshot_id" as found in
the "images" table made the snapshot disappear from the gui, but not
from the "images" table.

SO I decided to look into DeleteSnapshot procedure, that resolve as:

DELETE FROM snapshots WHERE snapshot_id = v_snapshot_id;

It only acts on the "snapshots" table, and not on the "image" table,
where the parentship between snapshots is still wrong.

How safe is to manually modify "images" table and set correct parentship?





On 20/04/2021 15:56, Shani Leviim wrote:
> Thanks, Ritesh.
> 
> In order to delete that snapshot, run this command on psql:
> SELECT DeleteSnapshot('snapshot-id');
> 
> *Regards,
> *
> *Shani Leviim
> *
> 
> 
> On Tue, Apr 20, 2021 at 3:25 PM Ritesh Chikatwar  > wrote:
> 
> adding @Shani Leviim  
> 
> On Tue, Apr 20, 2021 at 5:35 PM Thomas Hoberg  > wrote:
> 
> I have used these tools to get rid of snapshots that wouldn't go
> away any other way:
> 
> https://www.ovirt.org/develop/developer-guide/db-issues/helperutilities.html
> 
> 
> ___
> 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/37K5J2X2OUDQKN5J3J7ISOV26FMTHCTY/
> 
> 
> 
> 
> ___
> 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/LS3BUPQIVHQMG7I7C6IL7QTXJTJE7KCE/
> 
___
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/RAGYLKOM2DMLOCGIDYGZGCNVSQAASBIQ/

[ovirt-users] Re: How do I share a disk across multiple VMs?

[Gobinda Das]

Right now we don't have any plan for supporting Disperse gluster volume
from HCI. We have BZ to stop creating  Storage Domain for such unsupported
volume[1]
We only recommend replica 3  or replica2 + arbiter with sharding for VM
store use cases.
1. https://bugzilla.redhat.com/show_bug.cgi?id=1951894

On Wed, Apr 21, 2021 at 12:39 PM Sandro Bonazzola 
wrote:

>
>
> Il giorno mar 20 apr 2021 alle ore 03:00 Thomas Hoberg 
> ha scritto:
>
>> Sharing disks typically requires that you need to coordinate their use
>> above the disk.
>>
>> So did you consider sharing a file system instead?
>>
>> Members in my team have been using NetApp for their entire career and are
>> quite used to sharing files even for databases.
>>
>> And since Gluster HCI basically builds disks out of a replicated file
>> system, why not use that directly? All they do these days is mount some
>> parts of oVirt's 'data' volume inside the VMs as a GlusterFS. We just
>> create a separate directory to avoid stepping on oVirt's toes and mount
>> that on the clients, who won't see or disturb the oVirt images.
>>
>> They also run persistent Docker storage on these with Gluster mounted by
>> the daemon, so none of the Gluster stuff needs to be baked into the Docker
>> images. Gives you HA, zero extra copying and very fast live-migrations,
>> which are RAM content, only.
>>
>> I actually added separate Glusters (not managed by oVirt) using erasure
>> coding dispersed volumes for things not database, because the storage
>> efficiency is much better and a lot of that data is read-mostly. These are
>> machines that are seen as pure compute hosts to oVirt, but offer distinct
>> gluster volumes to all types of consumers via GlusterFS (NFS or SMB would
>> work, too).
>>
>> Too bad oVirt breaks with dispersed volumes and Gluster won't support a
>> seamless migration from 2+1 replicas+arbiter to say 7:2 dispersed volumes
>> as you add tiplets of hosts...
>>
>
> +Gobinda Das  you may be interested joining this
> discussion.
>
>
>>
>> If only oVirt was a product rather than only a patchwork design!
>>
>
> You're welcome to help with oVirt project design and discuss with the
> community the parts that you think should benefit from a re-design.
>
>
>
>
>
>
>
>> ___
>> 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/JKRIJDB6PQSIUKA3BEZ4VUERBPSEBR3K/
>>
>
>
> --
>
> Sandro Bonazzola
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>
> Red Hat EMEA 
>
> sbona...@redhat.com
> 
>
> *Red Hat respects your work life balance. Therefore there is no need to
> answer this email out of your office hours.
> *
>
>
>

-- 


Thanks,
Gobinda
___
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/PZ6QLC5YQVL2T6MY4TW3DTCUKWBMKR6L/

[ovirt-users] Re: How do I share a disk across multiple VMs?

[Thomas Hoberg]

> 
> You're welcome to help with oVirt project design and discuss with the
> community the parts that you think should benefit from a re-design.

I consider these pesky little comments part of the discussion, even if I know 
they are not the best style.

But how much is there to discuss, if Redhat has already decided to switch to a 
beta base (CentOS stream) underneath oVirt?

Nobody wants bleeding edge on a hypervisor, except those who develop that 
hypervisor.

oVirt is supposed to deliver a higher reliability than bare metal hardware, by 
providing a fault tolerant design and automatic fault recovery.

But if the software stack that the HA engine builds on is more volatile than 
the hardware below, it simply can't do its work of increasing overall 
resilience: a beta OS kills the value of a HA management stack above.

Only a RHEL downstream CentOS is near solid enough to build on (unless you did 
fully validated oVirt node images). Bleeding edge is what you put inside the 
VMs, not underneath. I don't think I have heard a single oVirt *user* 
advocating the switch to Stream. IMHO it's political and kills oVirt's value 
proposition.

My next major other gripe is that to a newcomer it's not obvious from the start 
that the oVirt 'classic' and the HCI variant are and will most likely remain 
very different beasts, because they have a distinct history and essentially 
incompatible principles.

Classic oVirt started with shared storage, which is always turned on. Theat 
means idle hosts can be turned off and workloads consolidated to minimize 
energy consumption. It aims for the minimal number of hosts to do the job.

Gluster is all about scale out without any choke points, the more hosts the 
better the performance.

And when you combine both in a HCI gluster, turning off hosts requires a much 
better attention as to whether these hosts contribute bricks to volumes in use 
or not.

For a user it's quite natural to mix both, using a set of HCI nodes to provide 
storage and base capacity and then add pure compute nodes to provide dynamic 
workload expansion.

But now I'm pretty sure that's unchartered territory, because I see  terrible 
things happening with quota decisions when computing nodes that don't even 
contribute bricks to volumes are rebooted e.g. during updates.

Making the community responsible for providing a unifying vision, is asking for 
help a bit too late in the game.

And then classic oVirt and HCI oVirt have completely different scaling 
characteristics. Classic will scale from one to N hosts without any issue, but 
HCI won't even go from 1 to 2 or the more sensible 3 nodes. Nor does it then 
allow the transition from replicas to the obviously more attractive dispersion 
volumes as you expand from 3 to 6 or 9 nodes.

How much of a discussion will we have, when I say that I want a Gluster volume 
to expand/grow/shrink and transform from 1 to N bricks and transition between 
replicas, dispersed volumes, sharded or non sharded with oVirt seamlessly 
running on top?

But unfortunately that is the natural expectation any newcomer will have, just 
like I did, when I read all the nice things Redhat had to say about the 
technology.

I hope you won't dispute it's still very much a patchwork and with a very small 
chance of near time resolution.
___
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/2CIGCLM5E2CTA2VKDZZOKXGIEQDCO5VT/

[ovirt-users] Re: n00b Requesting Some Advice

[Eyal Shenitzky]

Thanks Tarun Kumar,

Right, we have that option too :)

On Wed, 21 Apr 2021 at 10:43, Kushwaha, Tarun Kumar <
ta...@synergysystemsindia.com> wrote:

> Hi All,
>
> POSIXFS is good option to mount cephfs filesystem as Data domain and get
> all benefits of virtualization layer and as well as ceph storage layer i am
> using since more than 2 years without problem
>
> Tarun kumar kushwaha
> Skyvirt Cyberrange
> https://cyberrange.skyvirt.tech
>
> On Wed, 21 Apr 2021, 13:03 Eyal Shenitzky,  wrote:
>
>> Hi Matthew,
>>
>> Currently, in order to use Ceph in oVirt you have 2 options:
>>
>> 1. Ceph using ISCSI gateway - regular ISCSI storage domain with Ceph as
>> the storage backend, supports all the regular operations [1].
>> 2. Using the new Managed Block Storage (Cinderlib integration)
>> technical-preview - Create a Managed Block Storage domain that doesn't
>> support all the operations that we have for the "regular" storage domain
>> you can find more info here [2] and [3].
>>
>> Each option has its benefits.
>>
>> [1] -
>> https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/3/html/block_device_guide/using_an_iscsi_gateway
>> [2] -
>> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/html/installing_red_hat_virtualization_as_a_self-hosted_engine_using_the_command_line/set_up_cinderlib
>> [3] -
>> https://www.ovirt.org/develop/release-management/features/storage/cinderlib-integration.html
>>
>> On Wed, 21 Apr 2021 at 10:12, Sandro Bonazzola 
>> wrote:
>>
>>> +Eyal Shenitzky  any suggestion?
>>>
>>> Il giorno lun 12 apr 2021 alle ore 11:15  ha
>>> scritto:
>>>
 Hi All,

 I need some "best practice" advice. We have a Ceph Storage Cluster
 (Octopus moving to Pacific) which we'd like to use with our new oVirt
 Cluster (all on CentOS 8 boxes). What I'd like to know is what is the
 "best" (ie recommended / best practice) way of doing this - via iSCSI, CFS,
 'raw' RBD blocks, some other way I haven't read about yet, etc?

 I realise 'best' is a subjective term, but what I tend to do is do
 'manual' installs so that I both actually understand what is happening (ie
 how things fit together - I pull apart and rebuild mechanical clocks and
 watches for the same reason) and also so I can '"Puppet-ise" the results
 for future use. This means that I am *not* necessarily looking for "quick
 and dirty" or "quick and easy" (ie, I have no trouble using the CLI and
 'vim-ing' conf files as required) but I do want a solid, "best-practice"
 system when I'm done.

 So, can some please help? And also, would you mind pointing me towards
 the relevant documentation for the answer(s) supplied (yes, I *always* RTFM
 :-) ).

 Thanks in advance

 Dulux-Oz
 ___
 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/5VDIZ6AAES22C7MN7P3YNVYEAEYGAGSY/

>>>
>>>
>>> --
>>>
>>> Sandro Bonazzola
>>>
>>> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>>>
>>> Red Hat EMEA 
>>>
>>> sbona...@redhat.com
>>> 
>>>
>>> *Red Hat respects your work life balance. Therefore there is no need to
>>> answer this email out of your office hours.
>>> *
>>>
>>>
>>>
>>
>> --
>> Regards,
>> Eyal Shenitzky
>> ___
>> 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/QMWK2TT7NXNWRAGWW5MA74NTFDXU6QYP/
>>
>

-- 
Regards,
Eyal Shenitzky
___
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/DIO4UPB5CAUOWWKU5UJVFNW3KULYSS7F/

[ovirt-users] Re: How to update ovirt-sdk

[Martin Perina]

Hi,

According to the packages below you are using Python SDK v3, which has been
deprecated in oVirt 4.0. You need to install Python SDK v4 using below:

dnf install python3-ovirt-engine-sdk4

Regards,
Martin


On Tue, Apr 20, 2021 at 5:27 PM Miguel Garcia 
wrote:

> We integrate jenkins to launch vms dynamically to run smoketest from our
> builds but now we receive the following problem:
>
> "msg": "ovirtsdk4 version 4.3.0 or higher is required for this module"
>
> I had installed following packages in CentOs7
> ovirt-engine-sdk-java.noarch  3.6.10.0-1.el7   epel
> ovirt-engine-sdk-java-javadoc.noarch  3.6.10.0-1.el7   epel
> ovirt-engine-sdk-python.noarch3.6.9.1-1.el7epel
>
> I tired to use yum upgrade but did not report more recent version from
> ovirt-sdk.
>
> How can I upgrade/install ovirt-sdk to version 4.3?
> ___
> 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/JHCE5VSXQI7KTCOM72DGQ4GZ4HXC34PJ/
>


-- 
Martin Perina
Manager, Software Engineering
Red Hat Czech s.r.o.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/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/G6LVJC7LAE67N63ICPCBAK2IVVE4XCCA/

[ovirt-users] Re: n00b Requesting Some Advice

[Kushwaha, Tarun Kumar]

Hi All,

POSIXFS is good option to mount cephfs filesystem as Data domain and get
all benefits of virtualization layer and as well as ceph storage layer i am
using since more than 2 years without problem

Tarun kumar kushwaha
Skyvirt Cyberrange
https://cyberrange.skyvirt.tech

On Wed, 21 Apr 2021, 13:03 Eyal Shenitzky,  wrote:

> Hi Matthew,
>
> Currently, in order to use Ceph in oVirt you have 2 options:
>
> 1. Ceph using ISCSI gateway - regular ISCSI storage domain with Ceph as
> the storage backend, supports all the regular operations [1].
> 2. Using the new Managed Block Storage (Cinderlib integration)
> technical-preview - Create a Managed Block Storage domain that doesn't
> support all the operations that we have for the "regular" storage domain
> you can find more info here [2] and [3].
>
> Each option has its benefits.
>
> [1] -
> https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/3/html/block_device_guide/using_an_iscsi_gateway
> [2] -
> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/html/installing_red_hat_virtualization_as_a_self-hosted_engine_using_the_command_line/set_up_cinderlib
> [3] -
> https://www.ovirt.org/develop/release-management/features/storage/cinderlib-integration.html
>
> On Wed, 21 Apr 2021 at 10:12, Sandro Bonazzola 
> wrote:
>
>> +Eyal Shenitzky  any suggestion?
>>
>> Il giorno lun 12 apr 2021 alle ore 11:15  ha
>> scritto:
>>
>>> Hi All,
>>>
>>> I need some "best practice" advice. We have a Ceph Storage Cluster
>>> (Octopus moving to Pacific) which we'd like to use with our new oVirt
>>> Cluster (all on CentOS 8 boxes). What I'd like to know is what is the
>>> "best" (ie recommended / best practice) way of doing this - via iSCSI, CFS,
>>> 'raw' RBD blocks, some other way I haven't read about yet, etc?
>>>
>>> I realise 'best' is a subjective term, but what I tend to do is do
>>> 'manual' installs so that I both actually understand what is happening (ie
>>> how things fit together - I pull apart and rebuild mechanical clocks and
>>> watches for the same reason) and also so I can '"Puppet-ise" the results
>>> for future use. This means that I am *not* necessarily looking for "quick
>>> and dirty" or "quick and easy" (ie, I have no trouble using the CLI and
>>> 'vim-ing' conf files as required) but I do want a solid, "best-practice"
>>> system when I'm done.
>>>
>>> So, can some please help? And also, would you mind pointing me towards
>>> the relevant documentation for the answer(s) supplied (yes, I *always* RTFM
>>> :-) ).
>>>
>>> Thanks in advance
>>>
>>> Dulux-Oz
>>> ___
>>> 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/5VDIZ6AAES22C7MN7P3YNVYEAEYGAGSY/
>>>
>>
>>
>> --
>>
>> Sandro Bonazzola
>>
>> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>>
>> Red Hat EMEA 
>>
>> sbona...@redhat.com
>> 
>>
>> *Red Hat respects your work life balance. Therefore there is no need to
>> answer this email out of your office hours.
>> *
>>
>>
>>
>
> --
> Regards,
> Eyal Shenitzky
> ___
> 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/QMWK2TT7NXNWRAGWW5MA74NTFDXU6QYP/
>
___
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/4OF4K4XOPPONRGGROKXM4MRBR2CWU7AA/

[ovirt-users] Re: How to assign a server disk and nic profile via REST API?

[Shani Leviim]

Yes, follow the example here:

POST /ovirt-engine/api/vms/123/nics


  mynic
  virtio
  


http://ovirt.github.io/ovirt-engine-api-model/master/#services/vm_nics/methods/add



*Regards,*

*Shani Leviim*


On Wed, Apr 21, 2021 at 10:05 AM  wrote:

> Thanks. Is it possible to do it like this via the REST-API?
> I can't find it in the documentation. :-(
> I don't use Python.
> ___
> 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/GBCOWSEHG6HR2FFWTY6MLD632EPOOQWT/
>
___
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/574T3PCT6HQZXDQYBJCNACRZ5G5GGM25/

[ovirt-users] Re: n00b Requesting Some Advice

[duluxoz]

Thanks guys - yeah, we thought that was the case.

Thanks for confirming things

Regards

Matthew J

On 21/04/2021 17:30, Eyal Shenitzky wrote:

Hi Matthew,

Currently, in order to use Ceph in oVirt you have 2 options:

1. Ceph using ISCSI gateway - regular ISCSI storage domain with Ceph 
as the storage backend, supports all the regular operations [1].
2. Using the new Managed Block Storage (Cinderlib integration) 
technical-preview - Create a Managed Block Storage domain that doesn't 
support all the operations that we have for the "regular" storage 
domain you can find more info here [2] and [3].


Each option has its benefits.

[1] - 
https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/3/html/block_device_guide/using_an_iscsi_gateway 

[2] - 
https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/html/installing_red_hat_virtualization_as_a_self-hosted_engine_using_the_command_line/set_up_cinderlib 

[3] - 
https://www.ovirt.org/develop/release-management/features/storage/cinderlib-integration.html 



On Wed, 21 Apr 2021 at 10:12, Sandro Bonazzola > wrote:


+Eyal Shenitzky  any suggestion?

Il giorno lun 12 apr 2021 alle ore 11:15 mailto:matt...@peregrineit.net>> ha scritto:

Hi All,

I need some "best practice" advice. We have a Ceph Storage
Cluster (Octopus moving to Pacific) which we'd like to use
with our new oVirt Cluster (all on CentOS 8 boxes). What I'd
like to know is what is the "best" (ie recommended / best
practice) way of doing this - via iSCSI, CFS, 'raw' RBD
blocks, some other way I haven't read about yet, etc?

I realise 'best' is a subjective term, but what I tend to do
is do 'manual' installs so that I both actually understand
what is happening (ie how things fit together - I pull apart
and rebuild mechanical clocks and watches for the same reason)
and also so I can '"Puppet-ise" the results for future use.
This means that I am *not* necessarily looking for "quick and
dirty" or "quick and easy" (ie, I have no trouble using the
CLI and 'vim-ing' conf files as required) but I do want a
solid, "best-practice" system when I'm done.

So, can some please help? And also, would you mind pointing me
towards the relevant documentation for the answer(s) supplied
(yes, I *always* RTFM :-) ).

Thanks in advance

Dulux-Oz
___
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/5VDIZ6AAES22C7MN7P3YNVYEAEYGAGSY/





-- 


Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R RHV

Red Hat EMEA 

sbona...@redhat.com 

 

*Red Hat respects your work life balance. Therefore there is no
need to answer this email out of your office hours.
*
*

*



--
Regards,
Eyal Shenitzky

--
Peregrine IT Signature

*Matthew J BLACK*
  M.Inf.Tech.(Data Comms)
  MBA
  B.Sc.
  MACS (Snr), CP, IP3P

When you want it done /right/ ‒ the first time!

Phone:  +61 4 0411 0089
Email:  matt...@peregrineit.net 
Web:www.peregrineit.net 

View Matthew J BLACK's profile on LinkedIn 



This Email is intended only for the addressee.  Its use is limited to 
that intended by the author at the time and it is not to be distributed 
without the author’s consent.  You must not use or disclose the contents 
of this Email, or add the sender’s Email address to any database, list 
or mailing list unless you are expressly authorised to do so.  Unless 
otherwise stated, Peregrine I.T. Pty Ltd accepts no liability for the 
contents of this Email except where subsequently confirmed in 
writing. 

[ovirt-users] Re: n00b Requesting Some Advice

[Eyal Shenitzky]

Hi Matthew,

Currently, in order to use Ceph in oVirt you have 2 options:

1. Ceph using ISCSI gateway - regular ISCSI storage domain with Ceph as the
storage backend, supports all the regular operations [1].
2. Using the new Managed Block Storage (Cinderlib integration)
technical-preview - Create a Managed Block Storage domain that doesn't
support all the operations that we have for the "regular" storage domain
you can find more info here [2] and [3].

Each option has its benefits.

[1] -
https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/3/html/block_device_guide/using_an_iscsi_gateway
[2] -
https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/html/installing_red_hat_virtualization_as_a_self-hosted_engine_using_the_command_line/set_up_cinderlib
[3] -
https://www.ovirt.org/develop/release-management/features/storage/cinderlib-integration.html

On Wed, 21 Apr 2021 at 10:12, Sandro Bonazzola  wrote:

> +Eyal Shenitzky  any suggestion?
>
> Il giorno lun 12 apr 2021 alle ore 11:15  ha
> scritto:
>
>> Hi All,
>>
>> I need some "best practice" advice. We have a Ceph Storage Cluster
>> (Octopus moving to Pacific) which we'd like to use with our new oVirt
>> Cluster (all on CentOS 8 boxes). What I'd like to know is what is the
>> "best" (ie recommended / best practice) way of doing this - via iSCSI, CFS,
>> 'raw' RBD blocks, some other way I haven't read about yet, etc?
>>
>> I realise 'best' is a subjective term, but what I tend to do is do
>> 'manual' installs so that I both actually understand what is happening (ie
>> how things fit together - I pull apart and rebuild mechanical clocks and
>> watches for the same reason) and also so I can '"Puppet-ise" the results
>> for future use. This means that I am *not* necessarily looking for "quick
>> and dirty" or "quick and easy" (ie, I have no trouble using the CLI and
>> 'vim-ing' conf files as required) but I do want a solid, "best-practice"
>> system when I'm done.
>>
>> So, can some please help? And also, would you mind pointing me towards
>> the relevant documentation for the answer(s) supplied (yes, I *always* RTFM
>> :-) ).
>>
>> Thanks in advance
>>
>> Dulux-Oz
>> ___
>> 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/5VDIZ6AAES22C7MN7P3YNVYEAEYGAGSY/
>>
>
>
> --
>
> Sandro Bonazzola
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>
> Red Hat EMEA 
>
> sbona...@redhat.com
> 
>
> *Red Hat respects your work life balance. Therefore there is no need to
> answer this email out of your office hours.
> *
>
>
>

-- 
Regards,
Eyal Shenitzky
___
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/QMWK2TT7NXNWRAGWW5MA74NTFDXU6QYP/

[ovirt-users] Re: n00b Requesting Some Advice

[Sandro Bonazzola]

+Eyal Shenitzky  any suggestion?

Il giorno lun 12 apr 2021 alle ore 11:15  ha
scritto:

> Hi All,
>
> I need some "best practice" advice. We have a Ceph Storage Cluster
> (Octopus moving to Pacific) which we'd like to use with our new oVirt
> Cluster (all on CentOS 8 boxes). What I'd like to know is what is the
> "best" (ie recommended / best practice) way of doing this - via iSCSI, CFS,
> 'raw' RBD blocks, some other way I haven't read about yet, etc?
>
> I realise 'best' is a subjective term, but what I tend to do is do
> 'manual' installs so that I both actually understand what is happening (ie
> how things fit together - I pull apart and rebuild mechanical clocks and
> watches for the same reason) and also so I can '"Puppet-ise" the results
> for future use. This means that I am *not* necessarily looking for "quick
> and dirty" or "quick and easy" (ie, I have no trouble using the CLI and
> 'vim-ing' conf files as required) but I do want a solid, "best-practice"
> system when I'm done.
>
> So, can some please help? And also, would you mind pointing me towards the
> relevant documentation for the answer(s) supplied (yes, I *always* RTFM :-)
> ).
>
> Thanks in advance
>
> Dulux-Oz
> ___
> 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/5VDIZ6AAES22C7MN7P3YNVYEAEYGAGSY/
>


-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R RHV

Red Hat EMEA 

sbona...@redhat.com


*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/VDOJVH2QBBFBUF6EW2UH5NPQNC34E2BK/

[ovirt-users] Re: How do I share a disk across multiple VMs?

[Sandro Bonazzola]

Il giorno mar 20 apr 2021 alle ore 03:00 Thomas Hoberg 
ha scritto:

> Sharing disks typically requires that you need to coordinate their use
> above the disk.
>
> So did you consider sharing a file system instead?
>
> Members in my team have been using NetApp for their entire career and are
> quite used to sharing files even for databases.
>
> And since Gluster HCI basically builds disks out of a replicated file
> system, why not use that directly? All they do these days is mount some
> parts of oVirt's 'data' volume inside the VMs as a GlusterFS. We just
> create a separate directory to avoid stepping on oVirt's toes and mount
> that on the clients, who won't see or disturb the oVirt images.
>
> They also run persistent Docker storage on these with Gluster mounted by
> the daemon, so none of the Gluster stuff needs to be baked into the Docker
> images. Gives you HA, zero extra copying and very fast live-migrations,
> which are RAM content, only.
>
> I actually added separate Glusters (not managed by oVirt) using erasure
> coding dispersed volumes for things not database, because the storage
> efficiency is much better and a lot of that data is read-mostly. These are
> machines that are seen as pure compute hosts to oVirt, but offer distinct
> gluster volumes to all types of consumers via GlusterFS (NFS or SMB would
> work, too).
>
> Too bad oVirt breaks with dispersed volumes and Gluster won't support a
> seamless migration from 2+1 replicas+arbiter to say 7:2 dispersed volumes
> as you add tiplets of hosts...
>

+Gobinda Das  you may be interested joining this
discussion.


>
> If only oVirt was a product rather than only a patchwork design!
>

You're welcome to help with oVirt project design and discuss with the
community the parts that you think should benefit from a re-design.







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


-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R RHV

Red Hat EMEA 

sbona...@redhat.com


*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/6KLUAUYUYFYAKIN3WWINPSVOKGXH5YUT/

[ovirt-users] Re: oVirt Node's Future Regarding CentOS Stream

[Sandro Bonazzola]

Il giorno mar 20 apr 2021 alle ore 03:45 Thomas Hoberg 
ha scritto:

> As long as CentOS was downstream of RHEL, it was a base so solid it might
> have been better than the oVirt node image, even if that was theoretically
> going through some full stack QA testing.
>
> But with CentOS [Up]Stream you get beta quality for the base and then the
> various acquired parts that make up the oVirt house of cards on top.
>
> If then the oVirt node OS were to go through full-stack QA, that could be
> quite the better choice.
> But I'm more and more inclined to believe that the if is a false and any
> testing is just unit testing.
>

You're welcome to join oVirt QA initiative:
https://www.ovirt.org/develop/projects/project-qa.html and improve oVirt
quality :-)
I just want to note here that despite oVirt Node is moving to CentOS
Stream, you can still install oVirt on RHEL, CentOS Linux and  any other
RHEL derivatives which doesn't break compatibility with RHEL. We have
people who started trying oVirt on Alma Linux and pushing patches to
support it (see Bug 1942023
 - [RFE] host-deploy:
Allow adding an AlmaLinux host)
and I would personally be happy to collaborate with any distribution
willing to support oVirt.



>
> Around Christmas VDO got dropped from a kernel update of CentOS8 (still
> non-stream) and my 4.4 oVirt HCI farm dropped dead, until I found out what
> happend.
>

I can't respond for CentOS QA, but you can get in touch with them
https://wiki.centos.org/QaWiki


>
> To me that was the final straw: I will phase oVirt out with CentOS7.
> IBM may have a few more paying customers, but oVirt will lose the edge,
> the only place outside the cloud where RedHat can grow without being taxed
> by the cloud service providers.
>



-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R RHV

Red Hat EMEA 

sbona...@redhat.com


*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/M53QGTKISDP33XTBSD6ICWDVUTGBA2HA/

[ovirt-users] How to reduce load during create VM

[ovirt . org]

Hi everyone, please, can you limit the "Create VM" process somewhere so that 
setting up quota does not load the server so much, especially storage when 
duplicating the template disk?
___
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/2PO6CSPZN6N4E2VHNDOSS2VHMP2ZFH7J/

[ovirt-users] Re: How to assign a server disk and nic profile via REST API?

[ovirt . org]

Thanks. Is it possible to do it like this via the REST-API?
I can't find it in the documentation. :-(
I don't use Python.
___
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/GBCOWSEHG6HR2FFWTY6MLD632EPOOQWT/

[ovirt-users] Re: host certification is about to expire

[Yedidyah Bar David]

On Tue, Apr 20, 2021 at 9:07 PM Bill James  wrote:
>
> Thank you for reply.
> Notice Enroll cert was done 4/15, but still getting notices.
>
>
> engine.log:
>
> 2021-04-19 20:05:59,922-07 WARN  
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
> (EE-ManagedThreadFactory-engineScheduled-Thread-58) [] EVENT_ID: 
> HOST_CERTIFICATION_IS_ABOUT_TO_EXPIRE(845), Host ovirt1.j2noc.com 
> certification is about to expire at 2021-05-12. Please renew the host's 
> certification.
>
> ..
>
>
>
> 2021-04-15 20:25:47,964-07 INFO  
> [org.ovirt.engine.core.bll.hostdeploy.HostEnrollCertificateCommand] (default 
> task-3) [6b9b252b-e78a-4f46-983c-58b4162c2818] Running command: 
> HostEnrollCertificateCommand internal: false. Entities affected :  ID: 
> 23d2c0ab-5dd1-43af-9db3-2a426a539faf Type: VDSAction group 
> EDIT_HOST_CONFIGURATION with role type ADMIN
>
> 2021-04-15 20:25:48,004-07 INFO  
> [org.ovirt.engine.core.bll.hostdeploy.HostEnrollCertificateInternalCommand] 
> (EE-ManagedThreadFactory-commandCoordinator-Thread-1) 
> [6b9b252b-e78a-4f46-983c-58b4162c2818] Running command: 
> HostEnrollCertificateInternalCommand internal: true. Entities affected :  ID: 
> 23d2c0ab-5dd1-43af-9db3-2a426a539faf Type: VDS
>
> 2021-04-15 20:25:48,012-07 INFO  
> [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] 
> (EE-ManagedThreadFactory-commandCoordinator-Thread-1) 
> [6b9b252b-e78a-4f46-983c-58b4162c2818] START, SetVdsStatusVDSCommand(HostName 
> = ovirt1.j2noc.com, 
> SetVdsStatusVDSCommandParameters:{hostId='23d2c0ab-5dd1-43af-9db3-2a426a539faf',
>  status='Installing', nonOperationalReason='NONE', 
> stopSpmFailureLogged='false', maintenanceReason='null'}), log id: 2c9a2bff
>
> 2021-04-15 20:25:48,021-07 INFO  
> [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] 
> (EE-ManagedThreadFactory-commandCoordinator-Thread-1) 
> [6b9b252b-e78a-4f46-983c-58b4162c2818] FINISH, SetVdsStatusVDSCommand, 
> return: , log id: 2c9a2bff
>
> 2021-04-15 20:25:48,037-07 INFO  
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
> (default task-3) [6b9b252b-e78a-4f46-983c-58b4162c2818] EVENT_ID: 
> HOST_CERTIFICATION_ENROLLMENT_STARTED(880), Enrolling certificate for host 
> ovirt1.j2noc.com was started (User: 
> bill.ja...@j2global.com@j2global.com-authz).
>
> 2021-04-15 20:25:48,058-07 INFO  
> [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] 
> (EE-ManagedThreadFactory-commandCoordinator-Thread-1) 
> [6b9b252b-e78a-4f46-983c-58b4162c2818] START, SetVdsStatusVDSCommand(HostName 
> = ovirt1.j2noc.com, 
> SetVdsStatusVDSCommandParameters:{hostId='23d2c0ab-5dd1-43af-9db3-2a426a539faf',
>  status='Maintenance', nonOperationalReason='NONE', 
> stopSpmFailureLogged='false', maintenanceReason='null'}), log id: e46428c
>
> 2021-04-15 20:25:48,062-07 INFO  
> [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] 
> (EE-ManagedThreadFactory-commandCoordinator-Thread-1) 
> [6b9b252b-e78a-4f46-983c-58b4162c2818] FINISH,
>
>  SetVdsStatusVDSCommand, return: , log id: e46428c
>
> 2021-04-15 20:25:48,069-07 INFO  
> [org.ovirt.engine.core.common.utils.ansible.AnsibleExecutor] 
> (EE-ManagedThreadFactory-commandCoordinator-Thread-1) 
> [6b9b252b-e78a-4f46-983c-58b4162c2818] Executing Ansible command:  
> /usr/bin/ansible-playbook --ssh-common-args=-F 
> /var/lib/ovirt-engine/.ssh/config -v 
> --private-key=/etc/pki/ovirt-engine/keys/engine_id_rsa 
> --inventory=/tmp/ansible-inventory8413305606879978005 
> --extra-vars=ovirt_organizationname="j2noc.com" 
> --extra-vars=ovirt_ca_cert="-BEGIN CERTIFICATE-
>
> MIIDrjCCApagAwIBAgICEAAwDQYJKoZIhvcNAQEFBQAwQTELMAkGA1UEBhMCVVMxEjAQBgNVBAoT
>
> CWoybm9jLmNvbTEeMBwGA1UEAxMVb3ZpcnQuajJub2MuY29tLjE4NjU1MB4XDTE2MDUxMjE0NDUz
>
> MloXDTI2MDUxMTE0NDUzMlowQTELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCWoybm9jLmNvbTEeMBwG
>
> A1UEAxMVb3ZpcnQuajJub2MuY29tLjE4NjU1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
>
> AQEAvGatrRaRs2lnC/uT2caEij9cAzrYeJvnskCUY/iJoVGZuERDmU0QanvEUIIKlcjAqJsAb3Z4
>
> 4h63RoXNshnvFUP7L0DR2YvfrKWnDV3AlA/rEQ8jwLedGGsvM/AxzTMaSlnlcJYSlJXeQKHEhc84
>
> OTF8k+KalJditE9XWS/Z+OV9T3RcnE5QpBNJDKgg0W42WU4Y2K8r+Jwpso0Ea7YZuMck8GORnQOD
>
> vlQbGvj/6pOBcMyAIeVa0puTFIsGuje0dM7VUYl/DP/2T8kwJJtDM7cgaV94KSUTJbjdBLshWSPI
>
> Jj5LK1s7k3FGqGlPdjiXsbccZ8wUs439HwjMm7C6SQIDAQABo4GvMIGsMB0GA1UdDgQWBBRVi07z
>
> FIlc0PPtHF2JNIljlPnhXzBqBgNVHSMEYzBhgBRVi07zFIlc0PPtHF2JNIljlPnhX6FFpEMwQTEL
>
> MAkGA1UEBhMCVVMxEjAQBgNVBAoTCWoybm9jLmNvbTEeMBwGA1UEAxMVb3ZpcnQuajJub2MuY29t
>
> LjE4NjU1ggIQADAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0BAQUF
>
> AAOCAQEAna9CJ3lO1OMMGrINg9L+0DrILXFB7BYdf+x+dbyFkok+GkXWnG9SUuXIRqu5myJUJxPB
>
> cUOdxUvtgqp1ZHQ4noCACk7qcBDUEvkCsPiVqH0ogGuVkHzq8fl+L8VIZDH4cHYt4orhXiziPz8Y
>
> +LQFzP+vgB91pW2fejd2vXOrHEldQmu+IOpy28m4KeP5f1cay8+GcwESBcwnnOssotT14oPmIs2Z
>
> IIqdUyTEF0ILgBlEBOZBs27QhkqEI7ugyQfYosglS2PNTteOPmplapJ85fay+jElgXAIFD3gXSqd
>
> PDGq+9R0ELaIbpx4VloTUgejgKgO4xcx24O6H5F+GDurQg==
>
> -END CERTIFICATE-
>
> "