[ovirt-users] Re: Error exporting into ova

[thomas]

I am testing the migration from CentOS7/oVirt 4.3 to CentOS8/oVirt 4.4.

Exporting all VMs to OVAs, and re-importing them on a new cluster built from 
scratch seems the safest and best method, because in the step-by-step 
migration, there is simply far too many things that can go wrong and no easy 
way to fail-back after each step.

But of course it requires that one of the most essential operations in a 
hypervisor actualy works.

For me a hypervisor turns a machine into a file and a file into a machine: 
That's the most appreciated and fundamental quality of it.

oVirt fails right there, repeatedly, and for different reasons and without even 
reporting an error.

So I have manually put the single-line fix in, which settles udev to ensure 
that disks are not exported as zeros. That's the bug which renders the final 
release oVirt 4.3 forever unfit, 4 years before the end of maintenance of 
CentOS7, because it won't be fixed there.

Exporting VMs and re-importing them on another farm generally seemed to work 
after that.

But just as I was exporting not one of the trivial machines, that I have been 
using for testing, but one of the bigger ones, that actually contain a 
significant amout of data, I find myself hitting this timeout bug.

The disks for both the trival and less-trivial are defined at 500GB, thinly 
allocated. The trivial is the naked OS at something like 7GB actually 
allocated, the 'real' has 113GB allocated. In both cases the OVA export file to 
a local SSD xfs partition is 500GB, with lots of zeros and sparse allocation in 
the case of the first one.

The second came to 72GB of 500GB actually allocated, which didn't seem like a 
good sign already, but perhaps there was some compression involved?

Still the export finished without error or incident and the import on the other 
side went just as well. The machine even boots and runs, it was only once I 
started using it, that I suddenly had all types of file system errors... it 
turns out 113-73GB were actually really cut off and missing from the OVA 
export, and there is nobody and nothing checking for that.

I now know that qemu-img is used in the process, which actually runs in a pipe. 
There is no checksumming or any other logic involved to ensure that the format 
conversion of the disk image has retained the integrity of the image. There is 
no obvious simple solution that I can think of, but the combination of 
processing the image through a pipe and an impatient ansible timeout results in 
a hypervisor which fails on the most important elementary task: Turn a machine 
into a file and back into a machine.

IMHO it makes oVirt a toy, not a tool. And worst of all, I am pretty sure that 
RHV has the same quality, even if the sticker price is probably quite different.

I have the export domain backup running right now, but I'm not sure it's not 
using the same mechanism under the cover with potentially similar results.

Yes, I know there is a Python script that will do the backup, and probably with 
full fidelity. And perhaps with this new infrastructure as code approach, that 
is how it should be done anyway.

But if you have a GUI, that should just work: No excuses.

P.S. The allocation size of the big VM in the export domain is again 72GB, with 
the file size at 500GB. I'll run the import on the other end, but by now I am 
pretty sure, the result will be no different.

Unless you resort to Python or some external tool, there is no reliable way to 
back up and restore a VM of less than 80 seconds worth of data transfer and no 
warning, when corruption occurs.

I am not sure you can compete with Nutanix and VMware at this level of 
reliability.

P.P.S. So just where (and on which machine) do I need to change the timeout?
___
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/H6E2LNT76IPMDKBG6UHJQHVU5X3PUTPJ/

[ovirt-users] Compatibilty issue

[carl langlois]

Hi,

I have upgraded ovirt to 4.3 and now I have some vm that I can start
because of the cluster compatibility version. Those VM where in save state
when I updated the cluster compatibility version. Now they are in a down
state but if i try to run it I get this message.

Cannot run VM. The Custom Compatibility Version of VM vmfpgatest (4.2) is
not supported in Data Center compatibility version 4.3.

any suggestions?
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/BASF5UWZ4FHGCRT24PKPVA57WQCVN34X/

[ovirt-users] Re: TroubleshootingoVirt Node deploy FQDN not reachable

[thomas]

Just fresh from a single node HCI setup (CentOS 8 + oVirt 4.4.1) I did 
yesterday on an Intel i7-8559U NUC with a single 1TB NVMe storage stick and 
64GB of RAM:

The HCI wizard pretty much assumes a "second disk", but a partition will 
actually do. And it doesn't even have to be in /dev/mapper, even if the wizard 
seems to have some logic requiring that.

But it requires a partition to be present, which you'll need to create (empty) 
by hand and which in my case was something like /dev/nvme0n1p10 where the 
wizard puts /dev/sdb. That's because the wizard will then try to put VDO on 
that storage, which requires a block layer underneath, and then puts thin 
allocation LVs on to of that for the ultimate flexibility and the ability to 
worry much more about performance than detail planning of storage allocations.

And it needs to be really empty, if there is a file system or left-overs of 
one, the Wizard will fail with a not very helpful "device xx has been 
blacklisted" or similar.

Of course, without the HCI (first choice you make in the Wizard), you can set 
up your storage, even with Gluster, in many other ways, but I've found it 
easier to stick with the HCI route, at least given the equipment I had (no SAN, 
no NFS filer).
___
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/5XV5PYBJE2P6SGO3WJN765V2JE5ZQG2I/

[ovirt-users] Re: Is the Hosted Engine setup finished + Can't connect vdsm storage

[thomas]

It would be interesting to know, how the previous team got to six nodes: I 
don't remember seeing any documentation how to do that easily...

However, this state of affairs also seems to be quite normal, whenever I reboot 
a single node HCI setup: I've seen that with two systems now, one running 
4.3.11 on CentOS 7.8, the other 4.4.1 on CentOS 8.2.

What seems to happen in my case is some sort of a race condition or time-out, 
ovirt-ha-broker, ovirt-ha-agent and vdsmd all seem to fail in various ways, 
because glusterd isn't showing perfect connectivity between all storage nodes 
(actually in this case, it still fails to be perfect, even if there is only one 
node...)

I tend to restart glusterd carefully on any node that is seen as disconnected 
or not up (gluster volume status all), and once that is perfect and any gluster 
heals are through, I restart ovirt-ha-broker, ovirt-ha-agent and vdsmd nice and 
slow and not really in any particilar order, I just have a look to see if they 
stop complaining or stopping via systemctl status .

In the mean-time I check with hosted-engine --vm-status on all nodes to see if 
this "is the hosted engine setup finished" message disappears and with a bit of 
patience, it tends to come back. You might also went to make sure, that none of 
the nodes are on local maintenance or the whole data center is on global 
maintenance.

Let me tell you that I have pulled a lot of hair when I started with oVirt, 
because I tend to expect immediate reactions to any command I give. But here 
there is such a lot of automation going on in the background, that commands are 
really more like a bit of grease on the cogs of a giant gearbox and most of the 
time it just works automagically.
___
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/X5MDHFRIQDN4KMYUWS7J56VQTGY2Z2H7/

[ovirt-users] Re: Gluster Volume Type Distributed

[thomas]

Replicated is pretty much hard coded into all the Ansible scripts for the HCI 
setup. So you can't do anything but replicated and only choose between arbiter 
or full replica there. Distributed give you anything with three nodes, but with 
five, seven, nine or really high numbers, it becomes quite attractive.

Thing is, Gluster and oVirt are basically originally unrelated products and HCI 
is just a shuffle some people at Redhat thought cool (and it is). Not every 
permutation of aggregates between the two is supported, through: This is no 
Nutanix!

But of course, you have the source code...

Since I managed to scavange another 5 storage heavy nodes after I had started 
out with 3 nodes in a HCI cluster, I tried to see what I could do in terms of 
integration. Doing a full rebuild was out of the question, but adding another 
distributed volume (4+1) and a set of compute hosts seemed attractive, right?

I managed to get it done, twiddling ansible scripts and taking advantage of the 
fact that ansible won't do things it already considers done. So where it 
expected a replicated volume, I simply gave it a distributed volume, that 
looked every way on the top as the replicated would have looked as well.

I immediately forgot how I got it done, and of course I didn't take notes, but 
it works so far.
The hosted-engine is pretty generous in accepting volumes and nodes that look 
just like they had been done by the HCI setup; I guess it's because it really 
been designed to use this auto-discovery like setup, to avoid having to insert 
some key configuration data somehow.

That's why it shouldn't be too difficult to switch from a 3node HCI to a 5, 6 
or 9 node HCI, if you're a Gluster virtuozo and manage to restore/copy the data.

What I found most disappointing is the fact that Gluster doesn't seem to 
support converting replicated volumes into distributed ones, once you have 
enough bricks to make that attractive.

There again with oVirt you should be able to migrate disks and VMs by attaching 
volumes and copying images. The only thing a bit tricky is copying the hosted 
engine, but compared to how they inject that thing doing a HCI installation, 
all that would be easy

If you are deep enough into oVirt to understand what they are doing there.
___
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/WWMJQKOP42WQ7O6GCXILUVUESWYG4XGH/

[ovirt-users] Re: i/o wait and slow system

[info--- via Users]

Thank you. Reboot of the engine and afterwards the backup server helped :-)

Before the change -> 53 minutes for 10% and the restore broke at 98% ...
- [2020-08-26:20:45:30] Restore Imaging: 1/1 - 10% Imaging in progress
- [2020-08-26:20:41:22] Restore Imaging: 1/1 - 9% Imaging in progress...
- [2020-08-26:20:37:33] Restore Imaging: 1/1 - 8% Imaging in progress.
- [2020-08-26:20:32:04] Restore Imaging: 1/1 - 7% Imaging in progress...
- [2020-08-26:20:25:38] Restore Imaging: 1/1 - 6% Imaging in progress...
- [2020-08-26:20:21:34] Restore Imaging: 1/1 - 5% Imaging in progress...
- [2020-08-26:20:18:57] Restore Imaging: 1/1 - 3% Imaging in progress.
- [2020-08-26:20:03:15] Restore Imaging: 1/1 - 2% Imaging in progress
- [2020-08-26:19:57:10] Restore Imaging: 1/1 - 1% Imaging in progress.
- [2020-08-26:19:53:20] Restore Imaging: 1/1 - 0% Imaging in progress...
- [2020-08-26:19:53:17] Restore Imaging: 1/1 - 0% Started Imaging Disk1.img.lzo 
to /dev/sdb

After the change -> 10 minutes for 10%
- [2020-08-27:22:08:59] Restore Imaging: 1/1 - 10% Imaging in progress...
- [2020-08-27:22:08:02] Restore Imaging: 1/1 - 9% Imaging in progress...
- [2020-08-27:22:07:05] Restore Imaging: 1/1 - 8% Imaging in progress...
- [2020-08-27:22:05:34] Restore Imaging: 1/1 - 7% Imaging in progress...
- [2020-08-27:22:04:43] Restore Imaging: 1/1 - 6% Imaging in progress..
- [2020-08-27:22:03:34] Restore Imaging: 1/1 - 5% Imaging in progress..
- [2020-08-27:22:02:27] Restore Imaging: 1/1 - 4% Imaging in 
progress.
- [2020-08-27:22:01:39] Restore Imaging: 1/1 - 3% Imaging in progress
- [2020-08-27:22:00:16] Restore Imaging: 1/1 - 2% Imaging in progress...
- [2020-08-27:21:59:24] Restore Imaging: 1/1 - 1% Imaging in progress
- [2020-08-27:21:58:16] Restore Imaging: 1/1 - 0% Imaging in progress..
- [2020-08-27:21:58:13] Restore Imaging: 1/1 - 0% Started Imaging Disk1.img.lzo 
to /dev/sdb

Should I revert some of my previous changes? Reduce the write window size?
- gluster volume set vmstore performance.read-ahead on
- gluster volume set vmstore performance.stat-prefetch on
- gluster volume set vmstore performance.write-behind-window-size 64MB
- gluster volume set vmstore performance.flush-behind on
- gluster volume set vmstore cluster.choose-local on

Now I will reboot the other VMs and go on with moving from thin provisioned 
disk to preallocated.
___
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/4NYU6QTVX2LESDTEYO5FHASS43RQE7RG/

[ovirt-users] ovirt 4.4 self-hosted deployment questions

[Michael Thomas]

I have not been able to find answers to a couple of questions in the 
self-hosted engine documentation[1].


* When installing a new Enterprise Linux host for ovirt, what are the 
network requirements?  Specifically, am I supposed to set up the 
ovirtmgmt bridge myself on new hosts, or am I supposed to let that be 
handled by the engine when I add the new host to the engine?


* In the 'New Host' dialog on the engine management page, does the 
Hostname/IP that I enter have to be the host's name on the ovirtmgmt 
LAN?  If so, then it seems to me that I need to configure the ovirtmgmt 
bridge myself on new hosts.


* Does the engine need to be able to route outside of the cluster (eg to 
the WAN), or is it allowed to restrict the engine's routing to the local 
cluster?


* In the 'New Host' dialog on the engine management page, what is the 
meaning of 'Choose hosted engine deployment action'?  From the way it is 
phrased, it sounds like this will create a second engine in my cluster, 
which doesn't make sense.  Or does this mean that the new host will be 
able to run the Engine VM in a HA manner?



In my current test deployment I have 3 subnets in my cluster.  Network 
WAN is the WAN.  Network CLUSTER is for communication between cluster 
compute nodes, storage servers, and management servers.  Network OVIRT 
is for ovirt management and VM migration between hosts.


My first self-hosted engine host is connected to networks CLUSTER and 
OVIRT.  The engine VM is only connected to network OVIRT through a 
bridge on the host, but has a gateway that lets it route traffic to 
network CLUSTER (but not network WAN).


Is this an appropriate network setup for ovirt, or should there be no 
distinction between the CLUSTER and OVIRT networks?


--Mike


[1]https://www.ovirt.org/documentation/installing_ovirt_as_a_self-hosted_engine_using_the_command_line/
___
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/6ZQUYBF2IL7XN3ORTBZRRBQANVAJ6427/

[ovirt-users] Re: Impossible to install Windows VMs on 4.4.1

[Facundo Garat]

I installed the ones from the repo and even downloaded the latest ones from
Fedora repos.

On Thu, Aug 27, 2020 at 4:20 PM Michael Jones  wrote:

> I know 4.4.1 had a new windows driver iso... so you need to make sure
> you're using that newer one.
>
> On 27/08/2020 20:18, Michael Jones wrote:
> > just need to load the extra drivers,
> >
> > in virt viewer;
> >
> > 1. boot windows installer
> > 2. proceed installer until you see the windows with no disks present
> > 3. in virt-viewer swap the cd for the ovirt windows add-ons, this iso
> > has changed names a few times...
> > 4. load the driver from the iso
> > 5. refresh disks
> > 6. virtual disk will appear ready for windows to use.
> >
> > Kind Regards,
> >
> > Mike
> >
> > On 27/08/2020 13:21, fga...@gmail.com wrote:
> >> Hi,
> >>  I'm having problem after I upgraded to 4.4.1 with Windows machines.
> >>
> >>  The installation sees no disk. Even IDE disk doesn't get detected and
> installation won't move forward no matter what driver i use for the disk.
> >>
> >>   Any one else having this issue?.
> >>
> >> Regards,
> >> Facundo
> >> ___
> >> 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/LRM6X3MPFWOZ6GH7WXZBQE6VOTAFMIX7/
>
___
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/BRIC54HKWWFPGOIFPNCBIQFXCC5QGQH2/

[ovirt-users] Re: Impossible to install Windows VMs on 4.4.1

[Facundo Garat]

Hi Michael, try that but doesn't work. Not even on IDE disks.

The installer keep requesting drivers and no disk shows up.

Regards,
Facundo

On Thu, Aug 27, 2020 at 4:18 PM Michael Jones  wrote:

> just need to load the extra drivers,
>
> in virt viewer;
>
> 1. boot windows installer
> 2. proceed installer until you see the windows with no disks present
> 3. in virt-viewer swap the cd for the ovirt windows add-ons, this iso
> has changed names a few times...
> 4. load the driver from the iso
> 5. refresh disks
> 6. virtual disk will appear ready for windows to use.
>
> Kind Regards,
>
> Mike
>
> On 27/08/2020 13:21, fga...@gmail.com wrote:
> > Hi,
> >  I'm having problem after I upgraded to 4.4.1 with Windows machines.
> >
> >  The installation sees no disk. Even IDE disk doesn't get detected and
> installation won't move forward no matter what driver i use for the disk.
> >
> >   Any one else having this issue?.
> >
> > Regards,
> > Facundo
> > ___
> > 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/LRM6X3MPFWOZ6GH7WXZBQE6VOTAFMIX7/
>
___
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/P5EBLSBG7YJTUTNRG3NWBV7NYVBDDZTJ/

[ovirt-users] Re: POWER9 (ppc64le) Support on oVirt 4.4.1

[Arik Hadas]

On Thu, Aug 27, 2020 at 10:23 PM Arik Hadas  wrote:

>
>
> On Thu, Aug 27, 2020 at 10:13 PM Vinícius Ferrão <
> fer...@versatushpc.com.br> wrote:
>
>>
>>
>> On 27 Aug 2020, at 16:03, Arik Hadas  wrote:
>>
>>
>>
>> On Thu, Aug 27, 2020 at 8:40 PM Vinícius Ferrão via Users <
>> users@ovirt.org> wrote:
>>
>>> Hi Michal,
>>>
>>> On 27 Aug 2020, at 05:08, Michal Skrivanek 
>>> wrote:
>>>
>>>
>>>
>>> On 26 Aug 2020, at 20:50, Vinícius Ferrão via Users 
>>> wrote:
>>>
>>> Okay here we go Arik.
>>>
>>> With your insight I’ve done the following:
>>>
>>> # rpm -Va
>>>
>>> This showed what’s zeroed on the machine, since it was a lot of things,
>>> I’ve just gone crazy and done:
>>>
>>>
>>> you should still have host deploy logs on the engine machine. it’s weird
>>> it succeeded, unless it somehow happened afterwards?
>>>
>>>
>>> It only succeeded my yum reinstall rampage.
>>>
>>> yum list installed | cut -f 1 -d " " > file
>>> yum -y reinstall `cat file | xargs`
>>>
>>> Reinstalled everything.
>>>
>>> Everything worked as expected and I finally added the machine back to
>>> the cluster. It’s operational.
>>>
>>>
>>> eh, I wouldn’t trust it much. did you run redeploy at least?
>>>
>>>
>>> I’ve done reinstall on the web interface of the engine. I can reinstall
>>> the host, there’s nothing running on it… gonna try a third format.
>>>
>>>
>>>
>>> Now I’ve another issue, I have 3 VM’s that are ppc64le, when trying to
>>> import them, the Hosted Engine identifies them as x86_64:
>>>
>>> 
>>>
>>> So…
>>>
>>> This appears to be a bug. Any ideia on how to force it back to ppc64? I
>>> can’t manually force the import on the Hosted Engine since there’s no
>>> buttons to do this…
>>>
>>>
>>> how exactly did you import them? could be a bug indeed.
>>> we don’t support changing it as it doesn’t make sense, the guest can’t
>>> be converted
>>>
>>>
>>> Yeah. I done the normal procedure, added the storage domain to the
>>> engine and clicked on “Import VM”. Immediately it was detected as x86_64.
>>>
>>> Since I wasn’t able to upgrade my environment from 4.3.10 to 4.4.1 due
>>> to random errors when redeploying the engine with the backup from 4.3.10, I
>>> just reinstalled it, reconfigured everything and them imported the storage
>>> domains.
>>>
>>> I don’t know where the information about architecture is stored in the
>>> storage domain, I tried to search for some metadata files inside the domain
>>> but nothing come up. Is there a way to force this change? It must be a way.
>>>
>>> I even tried to import the machine as x86_64. So I can delete the VM and
>>> just reattach the disks in a new only, effectively not losing the data, but…
>>>
>>> 
>>>
>>> Yeah, so something is broken. The check during the import appears to be
>>> OK, but the interface does not me allow to import it to the ppc64le
>>> machine, since it’s read as x86_64.
>>>
>>
>> Could you please provide the output of the following query from the
>> database:
>> select * from unregistered_ovf_of_entities where entity_name='
>> energy.versatushpc.com.br';
>>
>>
>> Sure, there you go:
>>
>>  46ad1d80-2649-48f5-92e6-e5489d11d30c | energy.versatushpc.com.br | VM
>>|1 | |
>> d19456e4-0051-456e-b33c-57348a78c2e0 |
>>  http://schemas.dmtf.org/ovf/envelope/1/; xmlns:rasd="
>> http://schemas.dmtf.org/wbem/wscim/1/cim
>> -schema/2/CIM_ResourceAllocationSettingData" xmlns:vssd="
>> http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_VirtualSystemSettingData;
>> xmlns:xsi="http://ww
>> w.w3.org/2001/XMLSchema-instance"
>> ovf:version="4.1.0.0">> ovf:href="775b24a9-6a32-431a-831f-4ac9b3b31152/b1d9832e-076f-48f3-a300-0b5cdf0949af
>> " ovf:id="b1d9832e-076f-48f3-a300-0b5cdf0949af" ovf:size="512"
>> ovf:description="Active VM" ovf:disk_storage_type="IMAGE"
>> ovf:cinder_volume_type="">> eferences>List of networks> ovf:name="legacyservers">> xsi:type="ovf:DiskSection_Type">
>> List of Virtual Disks> ovf:diskId="b1d9832e-076f-48f3-a300-0b5cdf0949af" ovf:size="40"
>> ovf:actual_size="1" ovf:vm_snapshot_id="6de58683-c586
>> -4e97-b0e8-ee7ee3baf754" ovf:parentRef=""
>> ovf:fileRef="775b24a9-6a32-431a-831f-4ac9b3b31152/b1d9832e-076f-48f3-a300-0b5cdf0949af"
>> ovf:format="http://www.vmwa
>> re.com/specifications/vmdk.html#sparse" ovf:volume-format="RAW"
>> ovf:volume-type="Sparse" ovf:disk-interface="VirtIO_SCSI"
>> ovf:read-only="false" ovf:shareable
>> ="false" ovf:boot="true" ovf:pass-discard="false"
>> ovf:disk-alias="energy.versatushpc.com.br_Disk1" ovf:disk-description=""
>> ovf:wipe-after-delete="false">> sk>> xsi:type="ovf:VirtualSystem_Type">energy.versatushpc.com.brHolds
>> Kosen backend and frontend prod
>>  services (nginx +
>> docker)2020/08/19
>> 20:11:332020/08/20 18:37:41>
>> eProtected>falseguest_agentfalse1>
>> >Etc/GMT984.3>
>> mType>1AUTO_RESUME2730falsefalse>
>> nAndPause>false16ea16f22-45d7-11ea-bd83-00163e518b7c0>
>> igrationSupport>falsetruetrue>
>> ceCopyPasteEnabled>trueLOCK_SCREEN>
>> CustomEmulatedMachine>0>
>> 

[ovirt-users] Re: POWER9 (ppc64le) Support on oVirt 4.4.1

[Arik Hadas]

On Thu, Aug 27, 2020 at 10:13 PM Vinícius Ferrão 
wrote:

>
>
> On 27 Aug 2020, at 16:03, Arik Hadas  wrote:
>
>
>
> On Thu, Aug 27, 2020 at 8:40 PM Vinícius Ferrão via Users 
> wrote:
>
>> Hi Michal,
>>
>> On 27 Aug 2020, at 05:08, Michal Skrivanek 
>> wrote:
>>
>>
>>
>> On 26 Aug 2020, at 20:50, Vinícius Ferrão via Users 
>> wrote:
>>
>> Okay here we go Arik.
>>
>> With your insight I’ve done the following:
>>
>> # rpm -Va
>>
>> This showed what’s zeroed on the machine, since it was a lot of things,
>> I’ve just gone crazy and done:
>>
>>
>> you should still have host deploy logs on the engine machine. it’s weird
>> it succeeded, unless it somehow happened afterwards?
>>
>>
>> It only succeeded my yum reinstall rampage.
>>
>> yum list installed | cut -f 1 -d " " > file
>> yum -y reinstall `cat file | xargs`
>>
>> Reinstalled everything.
>>
>> Everything worked as expected and I finally added the machine back to the
>> cluster. It’s operational.
>>
>>
>> eh, I wouldn’t trust it much. did you run redeploy at least?
>>
>>
>> I’ve done reinstall on the web interface of the engine. I can reinstall
>> the host, there’s nothing running on it… gonna try a third format.
>>
>>
>>
>> Now I’ve another issue, I have 3 VM’s that are ppc64le, when trying to
>> import them, the Hosted Engine identifies them as x86_64:
>>
>> 
>>
>> So…
>>
>> This appears to be a bug. Any ideia on how to force it back to ppc64? I
>> can’t manually force the import on the Hosted Engine since there’s no
>> buttons to do this…
>>
>>
>> how exactly did you import them? could be a bug indeed.
>> we don’t support changing it as it doesn’t make sense, the guest can’t be
>> converted
>>
>>
>> Yeah. I done the normal procedure, added the storage domain to the engine
>> and clicked on “Import VM”. Immediately it was detected as x86_64.
>>
>> Since I wasn’t able to upgrade my environment from 4.3.10 to 4.4.1 due to
>> random errors when redeploying the engine with the backup from 4.3.10, I
>> just reinstalled it, reconfigured everything and them imported the storage
>> domains.
>>
>> I don’t know where the information about architecture is stored in the
>> storage domain, I tried to search for some metadata files inside the domain
>> but nothing come up. Is there a way to force this change? It must be a way.
>>
>> I even tried to import the machine as x86_64. So I can delete the VM and
>> just reattach the disks in a new only, effectively not losing the data, but…
>>
>> 
>>
>> Yeah, so something is broken. The check during the import appears to be
>> OK, but the interface does not me allow to import it to the ppc64le
>> machine, since it’s read as x86_64.
>>
>
> Could you please provide the output of the following query from the
> database:
> select * from unregistered_ovf_of_entities where entity_name='
> energy.versatushpc.com.br';
>
>
> Sure, there you go:
>
>  46ad1d80-2649-48f5-92e6-e5489d11d30c | energy.versatushpc.com.br | VM
>|1 | |
> d19456e4-0051-456e-b33c-57348a78c2e0 |
>  http://schemas.dmtf.org/ovf/envelope/1/; xmlns:rasd="
> http://schemas.dmtf.org/wbem/wscim/1/cim
> -schema/2/CIM_ResourceAllocationSettingData" xmlns:vssd="
> http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_VirtualSystemSettingData;
> xmlns:xsi="http://ww
> w.w3.org/2001/XMLSchema-instance" ovf:version="4.1.0.0"> ovf:href="775b24a9-6a32-431a-831f-4ac9b3b31152/b1d9832e-076f-48f3-a300-0b5cdf0949af
> " ovf:id="b1d9832e-076f-48f3-a300-0b5cdf0949af" ovf:size="512"
> ovf:description="Active VM" ovf:disk_storage_type="IMAGE"
> ovf:cinder_volume_type=""> eferences>List of networks ovf:name="legacyservers"> xsi:type="ovf:DiskSection_Type">
> List of Virtual Disks ovf:diskId="b1d9832e-076f-48f3-a300-0b5cdf0949af" ovf:size="40"
> ovf:actual_size="1" ovf:vm_snapshot_id="6de58683-c586
> -4e97-b0e8-ee7ee3baf754" ovf:parentRef=""
> ovf:fileRef="775b24a9-6a32-431a-831f-4ac9b3b31152/b1d9832e-076f-48f3-a300-0b5cdf0949af"
> ovf:format="http://www.vmwa
> re.com/specifications/vmdk.html#sparse" ovf:volume-format="RAW"
> ovf:volume-type="Sparse" ovf:disk-interface="VirtIO_SCSI"
> ovf:read-only="false" ovf:shareable
> ="false" ovf:boot="true" ovf:pass-discard="false"
> ovf:disk-alias="energy.versatushpc.com.br_Disk1" ovf:disk-description=""
> ovf:wipe-after-delete="false"> sk>
> energy.versatushpc.com.brHolds Kosen backend and
> frontend prod
>  services (nginx +
> docker)2020/08/19
> 20:11:332020/08/20 18:37:41
> eProtected>falseguest_agentfalse1
> >Etc/GMT984.3
> mType>1AUTO_RESUME2730falsefalse
> nAndPause>false16ea16f22-45d7-11ea-bd83-00163e518b7c0
> igrationSupport>falsetruetrue
> ceCopyPasteEnabled>trueLOCK_SCREEN
> CustomEmulatedMachine>0
> roperties>16384truefalseBlastoise
> ame>----Blanktrue0
> id>32644894-755e-4588-b967-8fb9dc3277952false000
>
> 0----Blankfalse stVersion>2020/08/20 17:52:35 ovf:id="46ad1d80-2649-48f5-92e6-e5489d11d30c" ovf:required="false"
> 

[ovirt-users] Re: Impossible to install Windows VMs on 4.4.1

[Michael Jones]

I know 4.4.1 had a new windows driver iso... so you need to make sure
you're using that newer one.

On 27/08/2020 20:18, Michael Jones wrote:
> just need to load the extra drivers,
>
> in virt viewer;
>
> 1. boot windows installer
> 2. proceed installer until you see the windows with no disks present
> 3. in virt-viewer swap the cd for the ovirt windows add-ons, this iso
> has changed names a few times...
> 4. load the driver from the iso
> 5. refresh disks
> 6. virtual disk will appear ready for windows to use.
>
> Kind Regards,
>
> Mike
>
> On 27/08/2020 13:21, fga...@gmail.com wrote:
>> Hi, 
>>  I'm having problem after I upgraded to 4.4.1 with Windows machines.
>>
>>  The installation sees no disk. Even IDE disk doesn't get detected and 
>> installation won't move forward no matter what driver i use for the disk.
>>
>>   Any one else having this issue?.
>>
>> Regards,
>> Facundo
>> ___
>> 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/LRM6X3MPFWOZ6GH7WXZBQE6VOTAFMIX7/
___
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/JWZDSDH3QCWTGTGABBXTX5IK4EZC3B4H/

[ovirt-users] Re: Impossible to install Windows VMs on 4.4.1

[Michael Jones]

just need to load the extra drivers,

in virt viewer;

1. boot windows installer
2. proceed installer until you see the windows with no disks present
3. in virt-viewer swap the cd for the ovirt windows add-ons, this iso
has changed names a few times...
4. load the driver from the iso
5. refresh disks
6. virtual disk will appear ready for windows to use.

Kind Regards,

Mike

On 27/08/2020 13:21, fga...@gmail.com wrote:
> Hi, 
>  I'm having problem after I upgraded to 4.4.1 with Windows machines.
>
>  The installation sees no disk. Even IDE disk doesn't get detected and 
> installation won't move forward no matter what driver i use for the disk.
>
>   Any one else having this issue?.
>
> Regards,
> Facundo
> ___
> 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/LRM6X3MPFWOZ6GH7WXZBQE6VOTAFMIX7/
___
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/2O3WJAKMVIZ23WIAEPXJURXVX7JKGJGQ/

[ovirt-users] Re: POWER9 (ppc64le) Support on oVirt 4.4.1

[Vinícius Ferrão via Users]

On 27 Aug 2020, at 16:03, Arik Hadas 
mailto:aha...@redhat.com>> wrote:



On Thu, Aug 27, 2020 at 8:40 PM Vinícius Ferrão via Users 
mailto:users@ovirt.org>> wrote:
Hi Michal,

On 27 Aug 2020, at 05:08, Michal Skrivanek 
mailto:michal.skriva...@redhat.com>> wrote:



On 26 Aug 2020, at 20:50, Vinícius Ferrão via Users 
mailto:users@ovirt.org>> wrote:

Okay here we go Arik.

With your insight I’ve done the following:

# rpm -Va

This showed what’s zeroed on the machine, since it was a lot of things, I’ve 
just gone crazy and done:

you should still have host deploy logs on the engine machine. it’s weird it 
succeeded, unless it somehow happened afterwards?

It only succeeded my yum reinstall rampage.

yum list installed | cut -f 1 -d " " > file
yum -y reinstall `cat file | xargs`

Reinstalled everything.

Everything worked as expected and I finally added the machine back to the 
cluster. It’s operational.

eh, I wouldn’t trust it much. did you run redeploy at least?

I’ve done reinstall on the web interface of the engine. I can reinstall the 
host, there’s nothing running on it… gonna try a third format.



Now I’ve another issue, I have 3 VM’s that are ppc64le, when trying to import 
them, the Hosted Engine identifies them as x86_64:



So…

This appears to be a bug. Any ideia on how to force it back to ppc64? I can’t 
manually force the import on the Hosted Engine since there’s no buttons to do 
this…

how exactly did you import them? could be a bug indeed.
we don’t support changing it as it doesn’t make sense, the guest can’t be 
converted

Yeah. I done the normal procedure, added the storage domain to the engine and 
clicked on “Import VM”. Immediately it was detected as x86_64.

Since I wasn’t able to upgrade my environment from 4.3.10 to 4.4.1 due to 
random errors when redeploying the engine with the backup from 4.3.10, I just 
reinstalled it, reconfigured everything and them imported the storage domains.

I don’t know where the information about architecture is stored in the storage 
domain, I tried to search for some metadata files inside the domain but nothing 
come up. Is there a way to force this change? It must be a way.

I even tried to import the machine as x86_64. So I can delete the VM and just 
reattach the disks in a new only, effectively not losing the data, but…



Yeah, so something is broken. The check during the import appears to be OK, but 
the interface does not me allow to import it to the ppc64le machine, since it’s 
read as x86_64.

Could you please provide the output of the following query from the database:
select * from unregistered_ovf_of_entities where 
entity_name='energy.versatushpc.com.br';

Sure, there you go:

 46ad1d80-2649-48f5-92e6-e5489d11d30c | 
energy.versatushpc.com.br | VM  | 
   1 | | d19456e4-0051-456e-b33c-57348a78c2e0 |
 http://schemas.dmtf.org/ovf/envelope/1/; 
xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim
-schema/2/CIM_ResourceAllocationSettingData" 
xmlns:vssd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_VirtualSystemSettingData;
 xmlns:xsi="http://ww
w.w3.org/2001/XMLSchema-instance" 
ovf:version="4.1.0.0">List of networks
List of Virtual Diskshttp://www.vmwa
re.com/specifications/vmdk.html#sparse"
 ovf:volume-format="RAW" ovf:volume-type="Sparse" 
ovf:disk-interface="VirtIO_SCSI" ovf:read-only="false" ovf:shareable
="false" ovf:boot="true" ovf:pass-discard="false" 
ovf:disk-alias="energy.versatushpc.com.br_Disk1" ovf:disk-description="" 
ovf:wipe-after-delete="false">energy.versatushpc.com.brHolds
 Kosen backend and frontend prod
 services (nginx + 
docker)2020/08/19 
20:11:332020/08/20 18:37:41falseguest_agentfalse1Etc/GMT984.31AUTO_RESUME2730falsefalsefalse16ea16f22-45d7-11ea-bd83-00163e518b7c0falsetruetruetrueLOCK_SCREEN016384truefalseBlastoise----Blanktrue032644894-755e-4588-b967-8fb9dc3277952false000
0----Blankfalse2020/08/20 17:52:35Guest Operating 
Systemother_linux_ppc642 CPU, 4096 MemoryENGINE 
4.1.0.02 virtual 
cpuNumber of virtual 
CPU132111624096 
>MB of memoryMemory Size24MegaBytes4096energy.versatushpc.com.br_Disk1b1d9832e-076f-48f3-a300-0b5cdf0949af17775b24a9-6a32-431a-831f-4ac9b3b31152/b1d9832e-076f-48f3-a300-0b5cdf0949af--------d19456e4-0051-456e-b33c-57348a78c2e06c54f91e-89bf-45b4-bc48-56e74c4efd5e2020/08/19 
20:13:051970/01/01 
00:00:002020/08
/20 
18:37:41diskdisk{type=drive,
 bus=0, controller=1, target=0, unit=0}<
BootOrder>1truefalseua-775b24a9-6a32-431a-831f-4ac9b3b31152Ethernet adapter on 
legacyserverse6e37ae1-f263-4986-a039-e8e01e72d1f410legacyservers3legacyserverstruenic1nic156:6f:f0:b3:00:23

[ovirt-users] Re: POWER9 (ppc64le) Support on oVirt 4.4.1

[Arik Hadas]

On Thu, Aug 27, 2020 at 8:40 PM Vinícius Ferrão via Users 
wrote:

> Hi Michal,
>
> On 27 Aug 2020, at 05:08, Michal Skrivanek 
> wrote:
>
>
>
> On 26 Aug 2020, at 20:50, Vinícius Ferrão via Users 
> wrote:
>
> Okay here we go Arik.
>
> With your insight I’ve done the following:
>
> # rpm -Va
>
> This showed what’s zeroed on the machine, since it was a lot of things,
> I’ve just gone crazy and done:
>
>
> you should still have host deploy logs on the engine machine. it’s weird
> it succeeded, unless it somehow happened afterwards?
>
>
> It only succeeded my yum reinstall rampage.
>
> yum list installed | cut -f 1 -d " " > file
> yum -y reinstall `cat file | xargs`
>
> Reinstalled everything.
>
> Everything worked as expected and I finally added the machine back to the
> cluster. It’s operational.
>
>
> eh, I wouldn’t trust it much. did you run redeploy at least?
>
>
> I’ve done reinstall on the web interface of the engine. I can reinstall
> the host, there’s nothing running on it… gonna try a third format.
>
>
>
> Now I’ve another issue, I have 3 VM’s that are ppc64le, when trying to
> import them, the Hosted Engine identifies them as x86_64:
>
> 
>
> So…
>
> This appears to be a bug. Any ideia on how to force it back to ppc64? I
> can’t manually force the import on the Hosted Engine since there’s no
> buttons to do this…
>
>
> how exactly did you import them? could be a bug indeed.
> we don’t support changing it as it doesn’t make sense, the guest can’t be
> converted
>
>
> Yeah. I done the normal procedure, added the storage domain to the engine
> and clicked on “Import VM”. Immediately it was detected as x86_64.
>
> Since I wasn’t able to upgrade my environment from 4.3.10 to 4.4.1 due to
> random errors when redeploying the engine with the backup from 4.3.10, I
> just reinstalled it, reconfigured everything and them imported the storage
> domains.
>
> I don’t know where the information about architecture is stored in the
> storage domain, I tried to search for some metadata files inside the domain
> but nothing come up. Is there a way to force this change? It must be a way.
>
> I even tried to import the machine as x86_64. So I can delete the VM and
> just reattach the disks in a new only, effectively not losing the data, but…
>
>
> Yeah, so something is broken. The check during the import appears to be
> OK, but the interface does not me allow to import it to the ppc64le
> machine, since it’s read as x86_64.
>

Could you please provide the output of the following query from the
database:
select * from unregistered_ovf_of_entities where entity_name='
energy.versatushpc.com.br';


>
>
> Thanks,
> michal
>
>
> Ideias?
>
> On 26 Aug 2020, at 15:04, Vinícius Ferrão 
> wrote:
>
> What a strange thing is happening here:
>
> [root@power ~]# file /usr/bin/vdsm-client
> /usr/bin/vdsm-client: empty
> [root@power ~]# ls -l /usr/bin/vdsm-client
> -rwxr-xr-x. 1 root root 0 Jul  3 06:23 /usr/bin/vdsm-client
>
> A lot of files are just empty, I’ve tried reinstalling vdsm-client, it
> worked, but there’s other zeroed files:
>
> Transaction test succeeded.
> Running transaction
>   Preparing:
>
>   1/1
>   Reinstalling : vdsm-client-4.40.22-1.el8ev.noarch
>
>   1/2
>   Cleanup  : vdsm-client-4.40.22-1.el8ev.noarch
>
>   2/2
>   Running scriptlet: vdsm-client-4.40.22-1.el8ev.noarch
>
>   2/2
> /sbin/ldconfig: File /lib64/libkadm5clnt.so is empty, not checked.
> /sbin/ldconfig: File /lib64/libkadm5clnt_mit.so is empty, not checked.
> /sbin/ldconfig: File /lib64/libkadm5clnt_mit.so.11 is empty, not checked.
> /sbin/ldconfig: File /lib64/libkadm5clnt_mit.so.11.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libkadm5srv.so is empty, not checked.
> /sbin/ldconfig: File /lib64/libkadm5srv_mit.so is empty, not checked.
> /sbin/ldconfig: File /lib64/libkadm5srv_mit.so.11 is empty, not checked.
> /sbin/ldconfig: File /lib64/libkadm5srv_mit.so.11.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libsensors.so.4 is empty, not checked.
> /sbin/ldconfig: File /lib64/libsensors.so.4.4.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libvirt-admin.so.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libvirt-admin.so.0.6000.0 is empty, not
> checked.
> /sbin/ldconfig: File /lib64/libvirt-lxc.so.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libvirt-lxc.so.0.6000.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libvirt-qemu.so.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libvirt-qemu.so.0.6000.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libvirt.so.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libvirt.so.0.6000.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libisns.so.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libiscsi.so.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libopeniscsiusr.so.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libopeniscsiusr.so.0.2.0 is empty, not checked.
>
> /sbin/ldconfig: File 

[ovirt-users] Re: POWER9 (ppc64le) Support on oVirt 4.4.1

[Vinícius Ferrão via Users]

Hi Michal,

On 27 Aug 2020, at 05:08, Michal Skrivanek 
mailto:michal.skriva...@redhat.com>> wrote:



On 26 Aug 2020, at 20:50, Vinícius Ferrão via Users 
mailto:users@ovirt.org>> wrote:

Okay here we go Arik.

With your insight I’ve done the following:

# rpm -Va

This showed what’s zeroed on the machine, since it was a lot of things, I’ve 
just gone crazy and done:

you should still have host deploy logs on the engine machine. it’s weird it 
succeeded, unless it somehow happened afterwards?

It only succeeded my yum reinstall rampage.

yum list installed | cut -f 1 -d " " > file
yum -y reinstall `cat file | xargs`

Reinstalled everything.

Everything worked as expected and I finally added the machine back to the 
cluster. It’s operational.

eh, I wouldn’t trust it much. did you run redeploy at least?

I’ve done reinstall on the web interface of the engine. I can reinstall the 
host, there’s nothing running on it… gonna try a third format.



Now I’ve another issue, I have 3 VM’s that are ppc64le, when trying to import 
them, the Hosted Engine identifies them as x86_64:



So…

This appears to be a bug. Any ideia on how to force it back to ppc64? I can’t 
manually force the import on the Hosted Engine since there’s no buttons to do 
this…

how exactly did you import them? could be a bug indeed.
we don’t support changing it as it doesn’t make sense, the guest can’t be 
converted

Yeah. I done the normal procedure, added the storage domain to the engine and 
clicked on “Import VM”. Immediately it was detected as x86_64.

Since I wasn’t able to upgrade my environment from 4.3.10 to 4.4.1 due to 
random errors when redeploying the engine with the backup from 4.3.10, I just 
reinstalled it, reconfigured everything and them imported the storage domains.

I don’t know where the information about architecture is stored in the storage 
domain, I tried to search for some metadata files inside the domain but nothing 
come up. Is there a way to force this change? It must be a way.

I even tried to import the machine as x86_64. So I can delete the VM and just 
reattach the disks in a new only, effectively not losing the data, but…

[cid:254FDE4F-5CBC-472A-9C89-0B728E4B0894]

Yeah, so something is broken. The check during the import appears to be OK, but 
the interface does not me allow to import it to the ppc64le machine, since it’s 
read as x86_64.


Thanks,
michal


Ideias?

On 26 Aug 2020, at 15:04, Vinícius Ferrão 
mailto:fer...@versatushpc.com.br>> wrote:

What a strange thing is happening here:

[root@power ~]# file /usr/bin/vdsm-client
/usr/bin/vdsm-client: empty
[root@power ~]# ls -l /usr/bin/vdsm-client
-rwxr-xr-x. 1 root root 0 Jul  3 06:23 /usr/bin/vdsm-client

A lot of files are just empty, I’ve tried reinstalling vdsm-client, it worked, 
but there’s other zeroed files:

Transaction test succeeded.
Running transaction
  Preparing:
 1/1
  Reinstalling : vdsm-client-4.40.22-1.el8ev.noarch 
 1/2
  Cleanup  : vdsm-client-4.40.22-1.el8ev.noarch 
 2/2
  Running scriptlet: vdsm-client-4.40.22-1.el8ev.noarch 
 2/2
/sbin/ldconfig: File /lib64/libkadm5clnt.so is empty, not checked.
/sbin/ldconfig: File /lib64/libkadm5clnt_mit.so is empty, not checked.
/sbin/ldconfig: File /lib64/libkadm5clnt_mit.so.11 is empty, not checked.
/sbin/ldconfig: File /lib64/libkadm5clnt_mit.so.11.0 is empty, not checked.
/sbin/ldconfig: File /lib64/libkadm5srv.so is empty, not checked.
/sbin/ldconfig: File /lib64/libkadm5srv_mit.so is empty, not checked.
/sbin/ldconfig: File /lib64/libkadm5srv_mit.so.11 is empty, not checked.
/sbin/ldconfig: File /lib64/libkadm5srv_mit.so.11.0 is empty, not checked.
/sbin/ldconfig: File /lib64/libsensors.so.4 is empty, not checked.
/sbin/ldconfig: File /lib64/libsensors.so.4.4.0 is empty, not checked.
/sbin/ldconfig: File /lib64/libvirt-admin.so.0 is empty, not checked.
/sbin/ldconfig: File /lib64/libvirt-admin.so.0.6000.0 is empty, not checked.
/sbin/ldconfig: File /lib64/libvirt-lxc.so.0 is empty, not checked.
/sbin/ldconfig: File /lib64/libvirt-lxc.so.0.6000.0 is empty, not checked.
/sbin/ldconfig: File /lib64/libvirt-qemu.so.0 is empty, not checked.
/sbin/ldconfig: File /lib64/libvirt-qemu.so.0.6000.0 is empty, not checked.
/sbin/ldconfig: File /lib64/libvirt.so.0 is empty, not checked.
/sbin/ldconfig: File /lib64/libvirt.so.0.6000.0 is empty, not checked.
/sbin/ldconfig: File /lib64/libisns.so.0 is empty, not checked.
/sbin/ldconfig: File /lib64/libiscsi.so.0 is empty, not checked.
/sbin/ldconfig: File /lib64/libopeniscsiusr.so.0 is empty, not checked.

[ovirt-users] Re: i/o wait and slow system

[Darrell Budic]

Looks like you’ve got a posix or nfs mount there? Is your gluster storage 
domain of type GlusterFS? And make sure you restarted the ovirt-engine after 
enabling LibfgApiSupported, before stopping and restarting the vm.

An active libgf mount looks like:


  
  

  


> On Aug 26, 2020, at 1:12 PM, info--- via Users  wrote:
> 
> I enabled libgfapi and powered off / on the VM.
> 
> - engine-config --all
> - LibgfApiSupported: true version: 4.3
> 
> How can I see that this is active on the VM? The disk looks the same like 
> before.
> 
> - virsh dumpxml 15
>
>   io='threads'/>
>   file='/rhev/data-center/mnt/glusterSD/10.9.9.101:_vmstore/f2c621de-42bf-4dbf-920c-adf4506b786d/images/1e231e3e-d98c-491a-9236-907814d4837/c755aaa3-7d3d-4c0d-8184-c6aae37229ba'>
>
>  
>  
>  
>  
>
> 
> Here is the Volume setup:
> 
> Volume Name: vmstore
> Type: Distributed-Replicate
> Volume ID: 195e2a05-9667-4b8b-b0b7-82294631de50
> Status: Started
> Snapshot Count: 0
> Number of Bricks: 2 x 3 = 6
> Transport-type: tcp
> Bricks:
> Brick1: 10.9.9.101:/gluster_bricks/vmstore/vmstore
> Brick2: 10.9.9.102:/gluster_bricks/vmstore/vmstore
> Brick3: 10.9.9.103:/gluster_bricks/vmstore/vmstore
> Brick4: 10.9.9.101:/gluster_bricks/S4CYNF0M219849L/S4CYNF0M219849L
> Brick5: 10.9.9.102:/gluster_bricks/S4CYNF0M219836L/S4CYNF0M219836L
> Brick6: 10.9.9.103:/gluster_bricks/S4CYNF0M219801Y/S4CYNF0M219801Y
> Options Reconfigured:
> performance.write-behind-window-size: 64MB
> performance.flush-behind: on
> performance.stat-prefetch: on
> performance.client-io-threads: on
> nfs.disable: on
> transport.address-family: inet
> performance.strict-o-direct: on
> performance.quick-read: off
> performance.read-ahead: on
> performance.io-cache: off
> performance.low-prio-threads: 32
> network.remote-dio: off
> cluster.eager-lock: enable
> cluster.quorum-type: auto
> cluster.server-quorum-type: server
> cluster.data-self-heal-algorithm: full
> cluster.locking-scheme: granular
> cluster.shd-max-threads: 8
> cluster.shd-wait-qlength: 1
> features.shard: on
> user.cifs: off
> cluster.choose-local: on
> client.event-threads: 4
> server.event-threads: 4
> network.ping-timeout: 30
> storage.owner-uid: 36
> storage.owner-gid: 36
> cluster.granular-entry-heal: enable
> 
> Thank you for your support.
> ___
> 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/Z3JD7MQV2PIQZJSMW6NKPL4W7JLBGPKN/

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

[ovirt-users] Re: Gluster Volume Type Distributed

[Jason Brooks]

On Thu, Aug 27, 2020 at 8:30 AM Dominique Deschênes
 wrote:
>
> Hi Everyone,
>
> I would like to use Distrbuted Volume type but the volume type is Gray out. I 
> can only use the replicate type.
>
> It's normal ?
>
> 3 ovirt Servers 4.4.1-2020080418
>
> Can I configure a replicate volume for the engine domain and Distributed for 
> the data domain?

You should be able to do it later, through the engine, once it's up
and running. The thing to be careful about is that if your data domain
is distributed, and one of the hosts is down, for updates or
something, part of your data will be unavailable. I use some
distributed-replicated domains for data, and the replicas let you
bring down a host for maintenance without losing access to your data.

>
>
>
>
> Thank you
>
> Dominique Deschênes
> Ingénieur chargé de projets, Responsable TI
> 816, boulevard Guimond, Longueuil J4G 1T5
> 450 670-8383 x105 450 670-2259
>
>
>
>
> ___
> 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/7TMGYCS4EF3KDKED46BVIL7JH3H4EKSH/



-- 
Jason Brooks
He/Him
Manager, Community Architects & Infrastructure
Red Hat Open Source Program Office (OSPO)
https://community.redhat.com | https://osci.io
___
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/GXL5LKXL2XIOB6YIIFH3QVI7Z2XHW7CT/

[ovirt-users] Gluster Volume Type Distributed

[Dominique Deschênes]

Hi Everyone,

I would like to use Distrbuted Volume type but the volume type is Gray out. I 
can only use the replicate type. 


It's normal ?


3 ovirt Servers 4.4.1-2020080418

Can I configure a replicate volume for the engine domain and Distributed for 
the data domain?





Thank you


Dominique Deschênes
Ingénieur chargé de projets, Responsable TI
816, boulevard Guimond, Longueuil J4G 1T5
 450 670-8383 x105  450 670-2259


          


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

[ovirt-users] Re: Host has no default route

[Bernadette Pfau via Users]

Wesley,

I had this happen on two newly built hosts and have no clue why.  I was likely 
running 4.3.6 or 4.3.7 at the time.  

I simply fixed things by hand using "ip route show" and "ip route add default 
via xxx.xxx.xxx.x dev ovirtmgmt0", etc.  I never figured out why it happened, 
but this fixed things up without any repercussions.

Bernadette
___
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/K2RSXMOB6TWS3KOQHRVXUBT6CN5TNFJL/

[ovirt-users] Re: [ANN] oVirt 4.4.2 Fifth Release Candidate is now available for testing

[Lev Veyde]

Hi Gianluca,

As Didi already mentioned you can check the updates to the 4.4.2 release
notes history, if you want to see what changed specifically between i.e.
RC4 and RC5.

The specific commit is this one:
https://github.com/oVirt/ovirt-site/commit/f021f5d204712dff237c6beec664e498f1188341#diff-539ead6dd4f7c8834254b1ef4f854d15

Thanks in advance,

On Thu, Aug 27, 2020 at 12:41 PM Yedidyah Bar David  wrote:

> On Thu, Aug 27, 2020 at 12:33 PM Gianluca Cecchi
>  wrote:
> >
> >
> >
> > On Thu, Aug 27, 2020 at 11:06 AM Lev Veyde  wrote:
> >>
> >> oVirt 4.4.2 Fifth Release Candidate is now available for testing
> >>
> >>
> >> The oVirt Project is pleased to announce the availability of oVirt
> 4.4.2 Fifth Release Candidate for testing, as of August 27th, 2020.
> >>
> >>
> >> This update is the second in a series of stabilization updates to the
> 4.4 series.
> >>
> >>
> >>
> >
> > Hi Lev, thanks for this update.
> > Is there a tracking to understand the need of this 5thrc and so a
> tracking of things fixed/enhanced from rc4 (that I'm testing) and rc5, so
> that I can address only those specific things in further tests after
> installing rc5?
>
> You can see what Lev changed in the release notes page:
>
>
> https://github.com/oVirt/ovirt-site/commits/master/source/release/4.4.2/index.md
>
> This page is generated by a script, you can try reading/adapting it
> and query bugzilla/git yourself:
>
> https://github.com/oVirt/releng-tools/blob/master/release_notes_git.py
>
> Best regards,
> --
> Didi
>
>

-- 

Lev Veyde

Senior Software Engineer, RHCE | RHCVA | MCITP

Red Hat Israel



l...@redhat.com | lve...@redhat.com

TRIED. TESTED. TRUSTED. 
___
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/Q3N4NTRHQM34WGUMABHM6FNKYA5ORWRU/

[ovirt-users] Impossible to install Windows VMs on 4.4.1

[fgarat]

Hi, 
 I'm having problem after I upgraded to 4.4.1 with Windows machines.

 The installation sees no disk. Even IDE disk doesn't get detected and 
installation won't move forward no matter what driver i use for the disk.

  Any one else having this issue?.

Regards,
Facundo
___
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/LRM6X3MPFWOZ6GH7WXZBQE6VOTAFMIX7/

[ovirt-users] Problem installing Windows VM on 4.4.1

[fgarat]

Hi, 
 I'm having problem after I upgraded to 4.4.1 with Windows machines.

 The installation sees no disk. Even IDE disk doesn't get detected and 
installation won't move forward no matter what driver i use for the disk.

  Any one else having this issue?.

Regards,
Facundo
___
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/NWECE32ZPJKUCN7CZK45A3MXCHZPI5CX/

[ovirt-users] Is the Hosted Engine setup finished + Can't connect vdsm storage

[Bielej SRE]

Hi,
We have 6 node oVirt setup with Compatibility version 4.3 running on CentOS 
7.6.1810
Recently We have found out some very interesting log entries on a few of our 
nodes.

/var/log/ovirt-hosted-engine-ha/broker.log:
MainThread::INFO::2020-08-27 
12:51:50,279::storage_backends::345::ovirt_hosted_engine_ha.lib.storage_backends::(connect)
 Connecting the storage
MainThread::INFO::2020-08-27 
12:51:50,280::storage_server::349::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(connect_storage_server)
 Connecting storage server
MainThread::warning::2020-08-27 
12:51:50,284::storage_broker::97::ovirt_hosted_engine_ha.broker.storage_broker.StorageBroker::(__init__)
 Can't connect vdsm storage: 'NoneType' object has no attribute 'startswith'

/var/log/messages
Aug 27 12:52:11 ildeco25 vdsm[6909]: ERROR failed to retrieve Hosted Engine HA 
score '[Errno 2] No such file or directory'Is the Hosted Engine setup finished?
We have inherited that setup from the previous team but I'm fairly certain the 
the Hosted Engine setup is finished.
Also, this line is not present on all hosts.
Should We worry about ovirt-ha-broker service not running on some hosts?
host24Active: inactive (dead)
host25Active: failed (Result: start-limit) since Thu 2020-08-27 12:56:13 
CEST; 2s ago
host26Active: active (running) since Sun 2020-08-23 22:55:01 CEST; 3 days 
ago
host27Active: inactive (dead)
host28Active: failed (Result: start-limit) since Thu 2020-08-27 12:56:18 
CEST; 4s ago
host29Active: inactive (dead)
Currently the hosted engine VM is running on host26.
I'd be very grateful for any help.

Kind regards,
Michal Bielejewski
___
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/GAB3IAVMRV4VGENRERAHHRNC6W2JAWP3/

[ovirt-users] Re: [ANN] oVirt 4.4.2 Fifth Release Candidate is now available for testing

[Yedidyah Bar David]

On Thu, Aug 27, 2020 at 12:33 PM Gianluca Cecchi
 wrote:
>
>
>
> On Thu, Aug 27, 2020 at 11:06 AM Lev Veyde  wrote:
>>
>> oVirt 4.4.2 Fifth Release Candidate is now available for testing
>>
>>
>> The oVirt Project is pleased to announce the availability of oVirt 4.4.2 
>> Fifth Release Candidate for testing, as of August 27th, 2020.
>>
>>
>> This update is the second in a series of stabilization updates to the 4.4 
>> series.
>>
>>
>>
>
> Hi Lev, thanks for this update.
> Is there a tracking to understand the need of this 5thrc and so a tracking of 
> things fixed/enhanced from rc4 (that I'm testing) and rc5, so that I can 
> address only those specific things in further tests after installing rc5?

You can see what Lev changed in the release notes page:

https://github.com/oVirt/ovirt-site/commits/master/source/release/4.4.2/index.md

This page is generated by a script, you can try reading/adapting it
and query bugzilla/git yourself:

https://github.com/oVirt/releng-tools/blob/master/release_notes_git.py

Best regards,
-- 
Didi
___
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/RYXZDNPSJV2LN7RMIYL2ZS36P5ROSSV4/

[ovirt-users] Re: [ANN] oVirt 4.4.2 Fifth Release Candidate is now available for testing

[Gianluca Cecchi]

On Thu, Aug 27, 2020 at 11:06 AM Lev Veyde  wrote:

> oVirt 4.4.2 Fifth Release Candidate is now available for testing
>
> The oVirt Project is pleased to announce the availability of oVirt 4.4.2
> Fifth Release Candidate for testing, as of August 27th, 2020.
>
> This update is the second in a series of stabilization updates to the 4.4
> series.
>
>
>
Hi Lev, thanks for this update.
Is there a tracking to understand the need of this 5thrc and so a tracking
of things fixed/enhanced from rc4 (that I'm testing) and rc5, so that I can
address only those specific things in further tests after installing rc5?

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

[ovirt-users] Re: Error exporting into ova

[Gianluca Cecchi]

On Tue, Aug 25, 2020 at 3:29 PM Tommaso - Shellrent 
wrote:

> Hi Gianluca.
>
> We have a problem wit "export as ova" too.
>
> In our env we back up all the vm with a python script that run an export.
>
> If we run multiple export at the same time, also on different
> datacenter[but same engine], the wait for each other and do not run in
> async mode.
>
> If only one of those export takes 10h, all of them taskes 10+h too.
>
> seems that all the export have to end a step of the playbook to go on, but
> we see only one "nasible-playbook" process at a time.
>
> Have you got any hint?
>
>
> Regards,
> Tommaso.
>
>
>
>
>
>
>
My post was one year old.
In the meantime you can check these two posts in archives by Jayme (I cc
him):
https://lists.ovirt.org/archives/list/users@ovirt.org/thread/U65CV5A6WC6SCB2R5N66Y7HPXQ3ZQT2H/#FAVZG32TPSX67DTXIHMGIQXUXNG3W3OE
and
https://lists.ovirt.org/archives/list/users@ovirt.org/message/JNSY6GYNS6LPNUJXERUO2EOG5F3P7B2M/

In the first post it appears that by default the exports were of type fire
and forget (that is what you need) and so he included a wait_for task to
instead have them sequential.
I think you can borrow from his github playbooks and adapt to your needs.
Or Jayme, you could apply a general change where you set a variable (eg
sequential_flow) that by default is true and then you modify the
export_vm.yml playbook in the task

- name: "Wait for export"

with the wait condition becoming of kind

when: (export_result is not failed) or (sequential_flow|bool == False)

This way by default the play workflow remains unchanged, but a user can set
sequential_flow to False
What do you think about it?
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/P4XQXETOVU3VS6JMAWNXHS2CZCVGMO7R/

[ovirt-users] [ANN] oVirt 4.4.2 Fifth Release Candidate is now available for testing

[Lev Veyde]

oVirt 4.4.2 Fifth Release Candidate is now available for testing

The oVirt Project is pleased to announce the availability of oVirt 4.4.2
Fifth Release Candidate for testing, as of August 27th, 2020.

This update is the second in a series of stabilization updates to the 4.4
series.
Important notes before you try it

Please note this is a pre-release build.

The oVirt Project makes no guarantees as to its suitability or usefulness.

This pre-release must not be used in production.
Installation instructions

For installation instructions and additional information please refer to:

https://ovirt.org/documentation/

This release is available now on x86_64 architecture for:

* Red Hat Enterprise Linux 8.2 or newer

* CentOS Linux (or similar) 8.2 or newer

This release supports Hypervisor Hosts on x86_64 and ppc64le architectures
for:

* Red Hat Enterprise Linux 8.2 or newer

* CentOS Linux (or similar) 8.2 or newer

* oVirt Node 4.4 based on CentOS Linux 8.2 (available for x86_64 only)

See the release notes [1] for installation instructions and a list of new
features and bugs fixed.

Notes:

- oVirt Appliance is already available for CentOS Linux 8

- oVirt Node NG is already available for CentOS Linux 8

Additional Resources:

* Read more about the oVirt 4.4.2 release highlights:
http://www.ovirt.org/release/4.4.2/

* Get more oVirt project updates on Twitter: https://twitter.com/ovirt

* Check out the latest project news on the oVirt blog:
http://www.ovirt.org/blog/


[1] http://www.ovirt.org/release/4.4.2/

[2] http://resources.ovirt.org/pub/ovirt-4.4-pre/iso/

-- 

Lev Veyde

Senior Software Engineer, RHCE | RHCVA | MCITP

Red Hat Israel



l...@redhat.com | lve...@redhat.com

TRIED. TESTED. TRUSTED. 
___
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/QLLKJNX3KN4YPISJ6KFCMFW77I3DNBAE/

[ovirt-users] Re: POWER9 (ppc64le) Support on oVirt 4.4.1

[Michal Skrivanek]

> On 26 Aug 2020, at 20:50, Vinícius Ferrão via Users  wrote:
> 
> Okay here we go Arik.
> 
> With your insight I’ve done the following:
> 
> # rpm -Va 
> 
> This showed what’s zeroed on the machine, since it was a lot of things, I’ve 
> just gone crazy and done:

you should still have host deploy logs on the engine machine. it’s weird it 
succeeded, unless it somehow happened afterwards?

> yum list installed | cut -f 1 -d " " > file
> yum -y reinstall `cat file | xargs`
> 
> Reinstalled everything.
> 
> Everything worked as expected and I finally added the machine back to the 
> cluster. It’s operational.

eh, I wouldn’t trust it much. did you run redeploy at least?

> 
> Now I’ve another issue, I have 3 VM’s that are ppc64le, when trying to import 
> them, the Hosted Engine identifies them as x86_64:
> 
> 
> 
> So…
> 
> This appears to be a bug. Any ideia on how to force it back to ppc64? I can’t 
> manually force the import on the Hosted Engine since there’s no buttons to do 
> this…

how exactly did you import them? could be a bug indeed.
we don’t support changing it as it doesn’t make sense, the guest can’t be 
converted

Thanks,
michal

> 
> Ideias?
> 
>> On 26 Aug 2020, at 15:04, Vinícius Ferrão > > wrote:
>> 
>> What a strange thing is happening here:
>> 
>> [root@power ~]# file /usr/bin/vdsm-client
>> /usr/bin/vdsm-client: empty
>> [root@power ~]# ls -l /usr/bin/vdsm-client
>> -rwxr-xr-x. 1 root root 0 Jul  3 06:23 /usr/bin/vdsm-client
>> 
>> A lot of files are just empty, I’ve tried reinstalling vdsm-client, it 
>> worked, but there’s other zeroed files:
>> 
>> Transaction test succeeded.
>> Running transaction
>>   Preparing: 
>> 
>> 1/1 
>>   Reinstalling : vdsm-client-4.40.22-1.el8ev.noarch  
>> 
>> 1/2 
>>   Cleanup  : vdsm-client-4.40.22-1.el8ev.noarch  
>> 
>> 2/2 
>>   Running scriptlet: vdsm-client-4.40.22-1.el8ev.noarch  
>> 
>> 2/2 
>> /sbin/ldconfig: File /lib64/libkadm5clnt.so is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5clnt_mit.so is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5clnt_mit.so.11 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5clnt_mit.so.11.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5srv.so is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5srv_mit.so is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5srv_mit.so.11 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5srv_mit.so.11.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libsensors.so.4 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libsensors.so.4.4.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libvirt-admin.so.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libvirt-admin.so.0.6000.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libvirt-lxc.so.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libvirt-lxc.so.0.6000.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libvirt-qemu.so.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libvirt-qemu.so.0.6000.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libvirt.so.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libvirt.so.0.6000.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libisns.so.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libiscsi.so.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libopeniscsiusr.so.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libopeniscsiusr.so.0.2.0 is empty, not checked.
>> 
>> /sbin/ldconfig: File /lib64/libkadm5clnt.so is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5clnt_mit.so is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5clnt_mit.so.11 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5clnt_mit.so.11.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5srv.so is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5srv_mit.so is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5srv_mit.so.11 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5srv_mit.so.11.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libsensors.so.4 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libsensors.so.4.4.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libvirt-admin.so.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libvirt-admin.so.0.6000.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libvirt-lxc.so.0 is empty, not checked.
>> /sbin/ldconfig: File 

[ovirt-users] Re: TroubleshootingoVirt Node deploy FQDN not reachable

[Gianluca Cecchi]

On Thu, Aug 27, 2020 at 2:49 AM David White via Users 
wrote:

>
>
> The responses to the bugzilla make it sound like a second, unused, disk,
> is required. Is that the case?
>

yes, it is required to install the OS from the ovirt-node-ng iso on the
first disk and then select the second empty disk for gluster bricks/volumes
during the wizard phase.
Please note also that when you run anaconda from the iso it by default
selects both the disks as target of the OS install (with a warning), so
that you have to click on the second disk (and deselect it this way) and
proceed with the install on only the first disk
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/WVHQ5V6UKCIJB3HLAJL34Q6EAJ72FZ6P/