[ovirt-users] Reinstalling the whole infrastructure

[Markus Schaufler]

Hi,


I’m not sure if my thread before is correctly received by everyone when posted 
via the website...therefore again via email.

Sorry if now everyone received this twice...


---

We are running our ovirt 4.3 test infrastructure on 4 Centos hosts. Our 
self-hosted engine further manages several stand alone hosts as separate 
datacenters.


We'd like now to reinstall the whole thing in a best practice way with oVirt 
node and a fresh hosted engine. We have planned to:

- set up 2 of the 4 hosts with ovirt node

- shut down the old hosted engine

- set up the new hosted engine with the same name

- move the VM's from the old cluster to the export domain in a maintenance 
windows

- import the VMs to the new cluster

- attach the stand alone hosts to the new hosted engine in again separate 
datacenters


Is this way possible to go or are there other ways e.g. without the need of a 
maintenance window?


Thanks for your thoughts!

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

[ovirt-users] Re: HE on single oVirt node

[Mike Davis]

Ok.  The oVirt Node installation sets up partitions to use the entire 
disk.  (Documentation recommends using the default layout.)  The Cockpit 
HE deployment tries to use gluster, but on a different disk 
(non-existent).  Do you recommend that I not use the default 
partitioning when installing oVirt Node; instead, I should set aside a 
partition for gluster (not formatting, etc)?


Thanks,
Mike

On 6/25/2019 7:26 PM, femi adegoke wrote:

Mike,

Keep it simple. It has to be a bare, plain disk.
Do not format or put a file system on the disk or the gluster install 
will fail.


On Jun 25 2019, at 3:53 pm, Mike Davis  wrote:

I installed oVirt node for oVirt v4.3.4 on a single server (default
partitioning).  I know a single node is not best practice, but
fits our
current need.

Now, I am trying to deploy the hosted engine, but getting the error
"Device /dev/sdb not found" (full output below). /dev/sdb does not
exist.  Changing to /dev/sda fails (as I would expect) with "Creating
physical volume '/dev/sda' failed".  There is only one logical disk on
this server (RAID), which is /dev/sda.

The process does not seem correct to me.  Why would the wizard try to
build gluster volumes on bare partitions rather than in a file system
like root?  What do we need to do to deploy the HE?

I used Cockpit and "Hyperconverged : Configure Gluster storage and
oVirt
hosted engine".  Since it is a single node, I selected "Run Gluster
Wizard For Single Node".

Host1 set to the IP address of the eno1 Ethernet interface (10.0.0.11)
No Packages, Update Hosts
Volumes left at defaults (engine, data, and vmstore)
Bricks left at defaults
 - (Raid 6  / 256 / 12)
 - Host 10.0.0.11
 - device name /dev/sdb (all LVs)
 - engine 100GB, data 500GB, vmstore 500GB

Output after "Deployment failed":

PLAY [Setup backend]
***

TASK [Gathering Facts]
*
ok: [10.0.0.11]

TASK [gluster.infra/roles/firewall_config : Start firewalld if not
already started] ***
ok: [10.0.0.11]

TASK [gluster.infra/roles/firewall_config : check if required
variables
are set] ***
skipping: [10.0.0.11]

TASK [gluster.infra/roles/firewall_config : Open/Close firewalld
ports]

ok: [10.0.0.11] => (item=2049/tcp)
ok: [10.0.0.11] => (item=54321/tcp)
ok: [10.0.0.11] => (item=5900/tcp)
ok: [10.0.0.11] => (item=5900-6923/tcp)
ok: [10.0.0.11] => (item=5666/tcp)
ok: [10.0.0.11] => (item=16514/tcp)

TASK [gluster.infra/roles/firewall_config : Add/Delete services to
firewalld rules] ***
ok: [10.0.0.11] => (item=glusterfs)

TASK [gluster.infra/roles/backend_setup : Gather facts to
determine the
OS distribution] ***
ok: [10.0.0.11]

TASK [gluster.infra/roles/backend_setup : Change to Install lvm tools
for debian systems.] ***
skipping: [10.0.0.11]

TASK [gluster.infra/roles/backend_setup : Change to Install lvm tools
for RHEL systems.] ***
ok: [10.0.0.11]

TASK [gluster.infra/roles/backend_setup : Install python-yaml package
for Debian systems] ***
skipping: [10.0.0.11]

TASK [gluster.infra/roles/backend_setup : Initialize vdo_devs array]
***
ok: [10.0.0.11]

TASK [gluster.infra/roles/backend_setup : Record VDO devices (if any)]
*
skipping: [10.0.0.11] => (item={u'vgname': u'gluster_vg_sdb',
u'pvname':
u'/dev/sdb'})

TASK [gluster.infra/roles/backend_setup : Enable and start vdo
service]

skipping: [10.0.0.11]

TASK [gluster.infra/roles/backend_setup : Create VDO with specified
size] **
skipping: [10.0.0.11]

TASK [gluster.infra/roles/backend_setup : Check if valid disktype is
provided] ***
skipping: [10.0.0.11]

TASK [gluster.infra/roles/backend_setup : Set PV data alignment for
JBOD] **
skipping: [10.0.0.11]

TASK [gluster.infra/roles/backend_setup : Set PV data alignment for
RAID] **
ok: [10.0.0.11]

TASK [gluster.infra/roles/backend_setup : Set VG physical extent size
for RAID] ***
ok: [10.0.0.11]

TASK [gluster.infra/roles/backend_setup : Create volume groups]

failed: [10.0.0.11] (item={u'vgname': u'gluster_vg_sdb', u'pvname':
u'/dev/sdb'}) => {"ansible_loop_var": "item", "changed": false,
"item":
{"pvname": "/dev/sdb", "vgname": "gluster_vg_sdb"}, "msg": "Device
/dev/sdb not found."}

NO MORE HOSTS LEFT
*

NO MORE HOSTS LEFT
*

PLAY RECAP
*
10.0.0.11  : ok=9    changed=0 unreachable=0
failed=1    skippe

[ovirt-users] Re: HE on single oVirt node

[femi adegoke]

Mike,

Keep it simple. It has to be a bare, plain disk.
Do not format or put a file system on the disk or the gluster install will fail.

On Jun 25 2019, at 3:53 pm, Mike Davis  wrote:
> I installed oVirt node for oVirt v4.3.4 on a single server (default
> partitioning). I know a single node is not best practice, but fits our
> current need.
>
> Now, I am trying to deploy the hosted engine, but getting the error
> "Device /dev/sdb not found" (full output below). /dev/sdb does not
> exist. Changing to /dev/sda fails (as I would expect) with "Creating
> physical volume '/dev/sda' failed". There is only one logical disk on
> this server (RAID), which is /dev/sda.
>
> The process does not seem correct to me. Why would the wizard try to
> build gluster volumes on bare partitions rather than in a file system
> like root? What do we need to do to deploy the HE?
>
> I used Cockpit and "Hyperconverged : Configure Gluster storage and oVirt
> hosted engine". Since it is a single node, I selected "Run Gluster
> Wizard For Single Node".
>
> Host1 set to the IP address of the eno1 Ethernet interface (10.0.0.11)
> No Packages, Update Hosts
> Volumes left at defaults (engine, data, and vmstore)
> Bricks left at defaults
> - (Raid 6 / 256 / 12)
> - Host 10.0.0.11
> - device name /dev/sdb (all LVs)
> - engine 100GB, data 500GB, vmstore 500GB
>
> Output after "Deployment failed":
> PLAY [Setup backend]
> ***
>
> TASK [Gathering Facts]
> *
> ok: [10.0.0.11]
>
> TASK [gluster.infra/roles/firewall_config : Start firewalld if not
> already started] ***
> ok: [10.0.0.11]
>
> TASK [gluster.infra/roles/firewall_config : check if required variables
> are set] ***
> skipping: [10.0.0.11]
>
> TASK [gluster.infra/roles/firewall_config : Open/Close firewalld ports]
> 
> ok: [10.0.0.11] => (item=2049/tcp)
> ok: [10.0.0.11] => (item=54321/tcp)
> ok: [10.0.0.11] => (item=5900/tcp)
> ok: [10.0.0.11] => (item=5900-6923/tcp)
> ok: [10.0.0.11] => (item=5666/tcp)
> ok: [10.0.0.11] => (item=16514/tcp)
>
> TASK [gluster.infra/roles/firewall_config : Add/Delete services to
> firewalld rules] ***
> ok: [10.0.0.11] => (item=glusterfs)
>
> TASK [gluster.infra/roles/backend_setup : Gather facts to determine the
> OS distribution] ***
> ok: [10.0.0.11]
>
> TASK [gluster.infra/roles/backend_setup : Change to Install lvm tools
> for debian systems.] ***
> skipping: [10.0.0.11]
>
> TASK [gluster.infra/roles/backend_setup : Change to Install lvm tools
> for RHEL systems.] ***
> ok: [10.0.0.11]
>
> TASK [gluster.infra/roles/backend_setup : Install python-yaml package
> for Debian systems] ***
> skipping: [10.0.0.11]
>
> TASK [gluster.infra/roles/backend_setup : Initialize vdo_devs array]
> ***
> ok: [10.0.0.11]
>
> TASK [gluster.infra/roles/backend_setup : Record VDO devices (if any)]
> *
> skipping: [10.0.0.11] => (item={u'vgname': u'gluster_vg_sdb', u'pvname':
> u'/dev/sdb'})
>
> TASK [gluster.infra/roles/backend_setup : Enable and start vdo service]
> 
> skipping: [10.0.0.11]
>
> TASK [gluster.infra/roles/backend_setup : Create VDO with specified
> size] **
> skipping: [10.0.0.11]
>
> TASK [gluster.infra/roles/backend_setup : Check if valid disktype is
> provided] ***
> skipping: [10.0.0.11]
>
> TASK [gluster.infra/roles/backend_setup : Set PV data alignment for
> JBOD] **
> skipping: [10.0.0.11]
>
> TASK [gluster.infra/roles/backend_setup : Set PV data alignment for
> RAID] **
> ok: [10.0.0.11]
>
> TASK [gluster.infra/roles/backend_setup : Set VG physical extent size
> for RAID] ***
> ok: [10.0.0.11]
>
> TASK [gluster.infra/roles/backend_setup : Create volume groups]
> 
> failed: [10.0.0.11] (item={u'vgname': u'gluster_vg_sdb', u'pvname':
> u'/dev/sdb'}) => {"ansible_loop_var": "item", "changed": false, "item":
> {"pvname": "/dev/sdb", "vgname": "gluster_vg_sdb"}, "msg": "Device
> /dev/sdb not found."}
>
> NO MORE HOSTS LEFT
> *
>
> NO MORE HOSTS LEFT
> *
>
> PLAY RECAP
> *
> 10.0.0.11 : ok=9 changed=0 unreachable=0
> failed=1 skipped=8 rescued=0 ignored=0
>
> ---
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/SWYYE4YEDRIMK2I24NCTVHQRRIFQKYIF/
>

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
htt

[ovirt-users] HE on single oVirt node

[Mike Davis]

I installed oVirt node for oVirt v4.3.4 on a single server (default 
partitioning).  I know a single node is not best practice, but fits our 
current need.


Now, I am trying to deploy the hosted engine, but getting the error 
"Device /dev/sdb not found" (full output below).  /dev/sdb does not 
exist.  Changing to /dev/sda fails (as I would expect) with "Creating 
physical volume '/dev/sda' failed".  There is only one logical disk on 
this server (RAID), which is /dev/sda.


The process does not seem correct to me.  Why would the wizard try to 
build gluster volumes on bare partitions rather than in a file system 
like root?  What do we need to do to deploy the HE?


I used Cockpit and "Hyperconverged : Configure Gluster storage and oVirt 
hosted engine".  Since it is a single node, I selected "Run Gluster 
Wizard For Single Node".


Host1 set to the IP address of the eno1 Ethernet interface (10.0.0.11)
No Packages, Update Hosts
Volumes left at defaults (engine, data, and vmstore)
Bricks left at defaults
 - (Raid 6  / 256 / 12)
 - Host 10.0.0.11
 - device name /dev/sdb (all LVs)
 - engine 100GB, data 500GB, vmstore 500GB

Output after "Deployment failed":

PLAY [Setup backend] 
***


TASK [Gathering Facts] 
*

ok: [10.0.0.11]

TASK [gluster.infra/roles/firewall_config : Start firewalld if not 
already started] ***

ok: [10.0.0.11]

TASK [gluster.infra/roles/firewall_config : check if required variables 
are set] ***

skipping: [10.0.0.11]

TASK [gluster.infra/roles/firewall_config : Open/Close firewalld ports] 


ok: [10.0.0.11] => (item=2049/tcp)
ok: [10.0.0.11] => (item=54321/tcp)
ok: [10.0.0.11] => (item=5900/tcp)
ok: [10.0.0.11] => (item=5900-6923/tcp)
ok: [10.0.0.11] => (item=5666/tcp)
ok: [10.0.0.11] => (item=16514/tcp)

TASK [gluster.infra/roles/firewall_config : Add/Delete services to 
firewalld rules] ***

ok: [10.0.0.11] => (item=glusterfs)

TASK [gluster.infra/roles/backend_setup : Gather facts to determine the 
OS distribution] ***

ok: [10.0.0.11]

TASK [gluster.infra/roles/backend_setup : Change to Install lvm tools 
for debian systems.] ***

skipping: [10.0.0.11]

TASK [gluster.infra/roles/backend_setup : Change to Install lvm tools 
for RHEL systems.] ***

ok: [10.0.0.11]

TASK [gluster.infra/roles/backend_setup : Install python-yaml package 
for Debian systems] ***

skipping: [10.0.0.11]

TASK [gluster.infra/roles/backend_setup : Initialize vdo_devs array] 
***

ok: [10.0.0.11]

TASK [gluster.infra/roles/backend_setup : Record VDO devices (if any)] 
*
skipping: [10.0.0.11] => (item={u'vgname': u'gluster_vg_sdb', u'pvname': 
u'/dev/sdb'})


TASK [gluster.infra/roles/backend_setup : Enable and start vdo service] 


skipping: [10.0.0.11]

TASK [gluster.infra/roles/backend_setup : Create VDO with specified 
size] **

skipping: [10.0.0.11]

TASK [gluster.infra/roles/backend_setup : Check if valid disktype is 
provided] ***

skipping: [10.0.0.11]

TASK [gluster.infra/roles/backend_setup : Set PV data alignment for 
JBOD] **

skipping: [10.0.0.11]

TASK [gluster.infra/roles/backend_setup : Set PV data alignment for 
RAID] **

ok: [10.0.0.11]

TASK [gluster.infra/roles/backend_setup : Set VG physical extent size 
for RAID] ***

ok: [10.0.0.11]

TASK [gluster.infra/roles/backend_setup : Create volume groups] 

failed: [10.0.0.11] (item={u'vgname': u'gluster_vg_sdb', u'pvname': 
u'/dev/sdb'}) => {"ansible_loop_var": "item", "changed": false, "item": 
{"pvname": "/dev/sdb", "vgname": "gluster_vg_sdb"}, "msg": "Device 
/dev/sdb not found."}


NO MORE HOSTS LEFT 
*


NO MORE HOSTS LEFT 
*


PLAY RECAP 
*
10.0.0.11  : ok=9    changed=0    unreachable=0 
failed=1    skipped=8    rescued=0    ignored=0


---


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

[ovirt-users] Re: Can't import some VMs after storage domain detach and reattach to new datacenter.

[Dmitry Filonov]

I have at least one of those VMs with DISKTYPE=1 on my old oVirt farm. Am
pretty sure nobody ever touched metadata files outside of oVirt, but the
disks were not created by oVirt but rather produced by virt-v2v and then
imported into older version of oVirt.
That happened several years ago and I wasn't involved with the project so
don't have details.

Fil
--
Dmitry Filonov
Linux Administrator
SBGrid Core | Harvard Medical School
250 Longwood Ave, SGM-114
Boston, MA 02115


On Tue, Jun 25, 2019 at 3:35 PM Nir Soffer  wrote:

> On Tue, Jun 25, 2019 at 8:39 PM Dmitry Filonov <
> filo...@hkl.hms.harvard.edu> wrote:
>
>> Sorry, don't have any logs from back then. That was some time ago and it
>> was easy to fix so I didn't bother keeping logs.
>> DISKTYPE and DESCRIPTION were the only two lines I had to fix to get
>> disks imported nicely.
>> If you like I can probably re-create situation by creating a VM, then
>> unregistering it, changing the .meta file and try re-importing it back.
>>
>
> Sure, reproducing it easy.
>
> But we want to support only valid value created by older version of oVirt.
> if such
> volumes actually exists in the field, the system should handle the import
> transparently,
> translating the disk type to "DATA".
>
> Are you sure the metadata was not modified outside of oVirt?
>
> Nir
>
>> On Tue, Jun 25, 2019 at 10:42 AM Nir Soffer  wrote:
>>
>>> On Tue, Jun 25, 2019 at 3:15 PM Dmitry Filonov <
>>> filo...@hkl.hms.harvard.edu> wrote:
>>>
 Hi Nir -

  in my case these VMs were migrated from VirtualBox to oVirt using some
 of the VMWare provided tool
 and then virt-v2v to convert images. Here's the example of the meta
 file -

 DOMAIN=92be9db3-eab4-47ed-9ee9-87b8616b7c8c
 VOLTYPE=LEAF
 CTIME=1529005629
 MTIME=1529005629
 IMAGE=f0d0b3b3-5a31-4c9f-b551-90586bf946a5
 DISKTYPE=1
 PUUID=----
 LEGALITY=LEGAL
 POOL_UUID=
 SIZE=41943040
 FORMAT=RAW
 TYPE=SPARSE
 DESCRIPTION=generated by virt-v2v
 1.36.10rhel_7,release_6.el7_5.2,libvirt
 EOF

 These disks worked fine on 4.2.3.8 but I wasn't able to import them
 into 4.3.4.3 unless I changed DISKTYPE line manually.

>>>
>>> Do you have engine and vdsm logs from the time you imported this vm?
>>>
>>> Which engine version was used during the import?
>>>
>>> Nir
>>>
>>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/OBPSIZFWULENOCUHRBQRH4QHDDUG6X6E/

[ovirt-users] Re: Can't import some VMs after storage domain detach and reattach to new datacenter.

[Nir Soffer]

On Tue, Jun 25, 2019 at 8:39 PM Dmitry Filonov 
wrote:

> Sorry, don't have any logs from back then. That was some time ago and it
> was easy to fix so I didn't bother keeping logs.
> DISKTYPE and DESCRIPTION were the only two lines I had to fix to get disks
> imported nicely.
> If you like I can probably re-create situation by creating a VM, then
> unregistering it, changing the .meta file and try re-importing it back.
>

Sure, reproducing it easy.

But we want to support only valid value created by older version of oVirt.
if such
volumes actually exists in the field, the system should handle the import
transparently,
translating the disk type to "DATA".

Are you sure the metadata was not modified outside of oVirt?

Nir

> On Tue, Jun 25, 2019 at 10:42 AM Nir Soffer  wrote:
>
>> On Tue, Jun 25, 2019 at 3:15 PM Dmitry Filonov <
>> filo...@hkl.hms.harvard.edu> wrote:
>>
>>> Hi Nir -
>>>
>>>  in my case these VMs were migrated from VirtualBox to oVirt using some
>>> of the VMWare provided tool
>>> and then virt-v2v to convert images. Here's the example of the meta file
>>> -
>>>
>>> DOMAIN=92be9db3-eab4-47ed-9ee9-87b8616b7c8c
>>> VOLTYPE=LEAF
>>> CTIME=1529005629
>>> MTIME=1529005629
>>> IMAGE=f0d0b3b3-5a31-4c9f-b551-90586bf946a5
>>> DISKTYPE=1
>>> PUUID=----
>>> LEGALITY=LEGAL
>>> POOL_UUID=
>>> SIZE=41943040
>>> FORMAT=RAW
>>> TYPE=SPARSE
>>> DESCRIPTION=generated by virt-v2v 1.36.10rhel_7,release_6.el7_5.2,libvirt
>>> EOF
>>>
>>> These disks worked fine on 4.2.3.8 but I wasn't able to import them into
>>> 4.3.4.3 unless I changed DISKTYPE line manually.
>>>
>>
>> Do you have engine and vdsm logs from the time you imported this vm?
>>
>> Which engine version was used during the import?
>>
>> Nir
>>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/ML7DK2FPFLCNI6ZPFB3Z52HWIJCSZDOH/

[ovirt-users] Re: Can't import some VMs after storage domain detach and reattach to new datacenter.

[Dmitry Filonov]

Sorry, don't have any logs from back then. That was some time ago and it
was easy to fix so I didn't bother keeping logs.
DISKTYPE and DESCRIPTION were the only two lines I had to fix to get disks
imported nicely.
If you like I can probably re-create situation by creating a VM, then
unregistering it, changing the .meta file and try re-importing it back.



--
Dmitry Filonov
Linux Administrator
SBGrid Core | Harvard Medical School
250 Longwood Ave, SGM-114
Boston, MA 02115


On Tue, Jun 25, 2019 at 10:42 AM Nir Soffer  wrote:

> On Tue, Jun 25, 2019 at 3:15 PM Dmitry Filonov <
> filo...@hkl.hms.harvard.edu> wrote:
>
>> Hi Nir -
>>
>>  in my case these VMs were migrated from VirtualBox to oVirt using some
>> of the VMWare provided tool
>> and then virt-v2v to convert images. Here's the example of the meta file
>> -
>>
>> DOMAIN=92be9db3-eab4-47ed-9ee9-87b8616b7c8c
>> VOLTYPE=LEAF
>> CTIME=1529005629
>> MTIME=1529005629
>> IMAGE=f0d0b3b3-5a31-4c9f-b551-90586bf946a5
>> DISKTYPE=1
>> PUUID=----
>> LEGALITY=LEGAL
>> POOL_UUID=
>> SIZE=41943040
>> FORMAT=RAW
>> TYPE=SPARSE
>> DESCRIPTION=generated by virt-v2v 1.36.10rhel_7,release_6.el7_5.2,libvirt
>> EOF
>>
>> These disks worked fine on 4.2.3.8 but I wasn't able to import them into
>> 4.3.4.3 unless I changed DISKTYPE line manually.
>>
>
> Do you have engine and vdsm logs from the time you imported this vm?
>
> Which engine version was used during the import?
>
> Nir
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/CVJLXIG2W5YMCTTFVUAY3WLSDBD64UFM/

[ovirt-users] Re: Error virNetTLSContextLoadCertFromFile after upgrade from oVirt 4.2 to 4.3.4

[Stefano Danzi]

Il 25/06/2019 14:26, Stefano Danzi ha scritto:


I don't remember to ever seen a question about this during 
engine-setup,

but it could be.
In /etc/pki/vdsm/certs/ I can see an old cert and ca with subjet:

[root@ovirt01 ~]# su - vdsm -s /bin/bash -c 'openssl x509 -in
/etc/pki/vdsm/certs/cacert.pem.20150205093608 -text'
Certificate:
  Data:
  Version: 3 (0x2)
  Serial Number: 1423056193 (0x54d21d41)
  Signature Algorithm: sha256WithRSAEncryption
  Issuer: CN=VDSM Certificate Authority
  Validity
  Not Before: Feb  4 13:23:13 2015 GMT
  Not After : Feb  4 13:23:13 2016 GMT
  Subject: CN=VDSM Certificate Authority
  Subject Public Key Info:

[CUT]

[root@ovirt01 ~]# su - vdsm -s /bin/bash -c 'openssl x509 -in
/etc/pki/vdsm/certs/vdsmcert.pem.20150205093609 -text'
Certificate:
  Data:
  Version: 3 (0x2)
  Serial Number: 1423056193 (0x54d21d41)
  Signature Algorithm: sha256WithRSAEncryption
  Issuer: CN=VDSM Certificate Authority
  Validity
  Not Before: Feb  4 13:23:13 2015 GMT
  Not After : Feb  4 13:23:13 2016 GMT
  Subject: CN=ovirt01.hawai.lan, O=VDSM Certificate
  Subject Public Key Info:
  Public Key Algorithm: rsaEncryption


I think that was certs made during first hosted engine installation.
Could it work if I manually create certs like this?
Just to start libvirtd, vdsm and hosted-engine.

I think it's worth a try. Just create a self-signed CA, a keypair
signed by it, and place them correctly, should work.

The engine won't be able to talk with the host, but you can then more
easily reinstall/re-enroll-certs.

Good luck,

This workaround works!
I have hosted engine running!

So I have to find how reinstall/re-enroll-certs on host. From engine 
UI host status is "NonResponsive" and I can't do nothing
___ 


Status:

now Host status is "Unassiged".  Engine can't reach host for "General 
SSLEngine problem" and It's ok because certs are "home made".

I can't switch host to maintenance because it's not operational.
I can't enroll certificate because is not in maintenance status.

hou I can enroll host cert manually?


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

[ovirt-users] Re: USB Passtrough device problem

[jplor...@gmail.com]

Hi Strahil

Sorry for the late reply but google sent ovirt mails to spam. I have tried
and thought I get audio, it sounds like its played at an incorrect bitrate
(I recorded audio ant soundls like slow motion audio).
Is there any other way to present the usb device than throught console usb
emulation?
Regards
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/5WJAFVIXSV5AVRXK53X5T5R2PAPTDLWP/

[ovirt-users] Re: iso files

[Jonkery Huang]

Hi Benny,

What is the rpm package with ovirt-imageio? I checked oVirt 4.3 
repositories, did not find rpm with that command.


Thanks
Jonkery

On 6/24/2019 9:48 AM, Benny Zlotnik wrote:

yes, you can use ovirt-imageio[1]

[1] - 
https://ovirt.org/develop/release-management/features/storage/image-upload.html


On Mon, Jun 24, 2019 at 4:34 PM > wrote:


Hi,

is possible to install a VM without an ISO domain? for version
4.3.4.3 ?

Thanks


-- 


Jose Ferradeira
http://www.logicworks.pt
___
Users mailing list -- users@ovirt.org 
To unsubscribe send an email to users-le...@ovirt.org

Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:

https://lists.ovirt.org/archives/list/users@ovirt.org/message/P2XUVZKEHSZBDWGSNGCZYDME4HJS34WA/


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

[ovirt-users] Re: Can't import some VMs after storage domain detach and reattach to new datacenter.

[Nir Soffer]

On Tue, Jun 25, 2019 at 3:15 PM Dmitry Filonov 
wrote:

> Hi Nir -
>
>  in my case these VMs were migrated from VirtualBox to oVirt using some of
> the VMWare provided tool
> and then virt-v2v to convert images. Here's the example of the meta file -
>
> DOMAIN=92be9db3-eab4-47ed-9ee9-87b8616b7c8c
> VOLTYPE=LEAF
> CTIME=1529005629
> MTIME=1529005629
> IMAGE=f0d0b3b3-5a31-4c9f-b551-90586bf946a5
> DISKTYPE=1
> PUUID=----
> LEGALITY=LEGAL
> POOL_UUID=
> SIZE=41943040
> FORMAT=RAW
> TYPE=SPARSE
> DESCRIPTION=generated by virt-v2v 1.36.10rhel_7,release_6.el7_5.2,libvirt
> EOF
>
> These disks worked fine on 4.2.3.8 but I wasn't able to import them into
> 4.3.4.3 unless I changed DISKTYPE line manually.
>

Do you have engine and vdsm logs from the time you imported this vm?

Which engine version was used during the import?

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

[ovirt-users] Re: Error virNetTLSContextLoadCertFromFile after upgrade from oVirt 4.2 to 4.3.4

[Stefano Danzi]

I don't remember to ever seen a question about this during engine-setup,
but it could be.
In /etc/pki/vdsm/certs/ I can see an old cert and ca with subjet:

[root@ovirt01 ~]# su - vdsm -s /bin/bash -c 'openssl x509 -in
/etc/pki/vdsm/certs/cacert.pem.20150205093608 -text'
Certificate:
  Data:
  Version: 3 (0x2)
  Serial Number: 1423056193 (0x54d21d41)
  Signature Algorithm: sha256WithRSAEncryption
  Issuer: CN=VDSM Certificate Authority
  Validity
  Not Before: Feb  4 13:23:13 2015 GMT
  Not After : Feb  4 13:23:13 2016 GMT
  Subject: CN=VDSM Certificate Authority
  Subject Public Key Info:

[CUT]

[root@ovirt01 ~]# su - vdsm -s /bin/bash -c 'openssl x509 -in
/etc/pki/vdsm/certs/vdsmcert.pem.20150205093609 -text'
Certificate:
  Data:
  Version: 3 (0x2)
  Serial Number: 1423056193 (0x54d21d41)
  Signature Algorithm: sha256WithRSAEncryption
  Issuer: CN=VDSM Certificate Authority
  Validity
  Not Before: Feb  4 13:23:13 2015 GMT
  Not After : Feb  4 13:23:13 2016 GMT
  Subject: CN=ovirt01.hawai.lan, O=VDSM Certificate
  Subject Public Key Info:
  Public Key Algorithm: rsaEncryption


I think that was certs made during first hosted engine installation.
Could it work if I manually create certs like this?
Just to start libvirtd, vdsm and hosted-engine.

I think it's worth a try. Just create a self-signed CA, a keypair
signed by it, and place them correctly, should work.

The engine won't be able to talk with the host, but you can then more
easily reinstall/re-enroll-certs.

Good luck,

This workaround works!
I have hosted engine running!

So I have to find how reinstall/re-enroll-certs on host. From engine UI 
host status is "NonResponsive" and I can't do nothing

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

[ovirt-users] Re: Can't import some VMs after storage domain detach and reattach to new datacenter.

[Dmitry Filonov]

Hi Nir -

 in my case these VMs were migrated from VirtualBox to oVirt using some of
the VMWare provided tool
and then virt-v2v to convert images. Here's the example of the meta file -

DOMAIN=92be9db3-eab4-47ed-9ee9-87b8616b7c8c
VOLTYPE=LEAF
CTIME=1529005629
MTIME=1529005629
IMAGE=f0d0b3b3-5a31-4c9f-b551-90586bf946a5
DISKTYPE=1
PUUID=----
LEGALITY=LEGAL
POOL_UUID=
SIZE=41943040
FORMAT=RAW
TYPE=SPARSE
DESCRIPTION=generated by virt-v2v 1.36.10rhel_7,release_6.el7_5.2,libvirt
EOF

These disks worked fine on 4.2.3.8 but I wasn't able to import them into
4.3.4.3 unless I changed DISKTYPE line manually.

Fil

--
Dmitry Filonov
Linux Administrator
SBGrid Core | Harvard Medical School
250 Longwood Ave, SGM-114
Boston, MA 02115


On Tue, Jun 25, 2019 at 5:41 AM Nir Soffer  wrote:

> On Mon, Jun 24, 2019 at 7:47 PM Dmitry Filonov <
> filo...@hkl.hms.harvard.edu> wrote:
>
>>
>> Take a look at the corresponding .meta file for the disks you can not
>> import.
>> I had the very same problem and it was caused by
>> DISKTYPE=1 in .meta.
>>
>
> I want more info on this. We think that the only value ever used for
> DISKTYPE is 2.
>
> Do you have any info on how these disks were created? Maybe by some
> ancient version?
>
> Nir
>
>
>> When changed to
>> DISKTYPE=DATA I was able to import disks correctly.
>> Not the whole VM though..
>>
>>
>> --
>> Dmitry Filonov
>> Linux Administrator
>> SBGrid Core | Harvard Medical School
>> 250 Longwood Ave, SGM-114
>> Boston, MA 02115
>>
>>
>> On Sun, Jun 23, 2019 at 4:29 AM m black  wrote:
>>
>>> Hi.
>>>
>>> I have a problem with importing some VMs after importing storage domain
>>> in new datacenter.
>>>
>>> I have 5 servers with oVirt version 4.1.7, hosted-engine setup and
>>> datacenter with iscsi, fc and nfs storages. Also i have 3 servers with
>>> oVirt 4.3.4, hosted-engine and nfs storage.
>>>
>>> I've set iscsi and fc storages to maintenance and detached them
>>> successfully on 4.1.7 datacenter.
>>> Then i've imported these storage domains via Import Domain in 4.3.4
>>> datacenter successfully.
>>>
>>> After storage domains were imported to new 4.3.4 datacenter i've tried
>>> to import VMs from VM Import tab on storages.
>>>
>>> On the FC storage it was good, all VMs imported and started, all VMs in
>>> place.
>>>
>>> And with iSCSI storage i've got problems:
>>> On the iSCSI storage some VMs imported and started, but some of them
>>> missing, some of missing VMs disks are showing at Disk Import, i've tried
>>> to import disks from Disk Import tab and got error - 'Failed to register
>>> disk'.
>>> Tried to scan disks with 'Scan Disks' in storage domain, also tried
>>> 'Update OVF' - no result.
>>>
>>> What caused this? What can i do to recover missing VMs? What logs to
>>> examine?
>>> Can it be storage domain disk corruption?
>>>
>>> Please, help.
>>>
>>> Thank you.
>>>
>>> ___
>>> Users mailing list -- users@ovirt.org
>>> To unsubscribe send an email to users-le...@ovirt.org
>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>>> oVirt Code of Conduct:
>>> https://www.ovirt.org/community/about/community-guidelines/
>>> List Archives:
>>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/MF5IUXURKIQZNNG4YW6ELENFD4GZIDQZ/
>>>
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/BMXCPVIHKKQ3T767KVGMB44BLJOKLP6K/
>>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/IIN57PBXOIVVBFRUYPVNTI7DJGK2Z3Q5/

[ovirt-users] Re: iso files

[suporte]

So, it's better to configure an ISO Domain, for now. 

Thanks 

José 


De: "Gianluca Cecchi"  
Para: supo...@logicworks.pt 
Cc: "Strahil Nikolov" , "users"  
Enviadas: Terça-feira, 25 De Junho de 2019 11:27:39 
Assunto: Re: [ovirt-users] Re: iso files 

On Tue, Jun 25, 2019 at 11:01 AM < supo...@logicworks.pt > wrote: 



The bug only refers version 4.2. The problem remains on version 4.3? 

José 





Yes, detected in 4.2 but still remains. 
You can see now inside bugzilla: 
Target Milestone: ovirt-4.3.6 
[snip] 

BQ_BEGIN


Just remind this: 
https://bugzilla.redhat.com/show_bug.cgi?id=1589763 

so that if you have to deploy an OS that needs to change CD during installation 
you have problems 
Or if you need to swap CD on a running VM for any reason. 

Gianluca 

BQ_END


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

[ovirt-users] Re: iso files

[Gianluca Cecchi]

On Tue, Jun 25, 2019 at 11:01 AM  wrote:

> The bug only refers version 4.2. The problem remains on version 4.3?
>
> José
>
>
> Yes, detected in 4.2 but still remains.
You can see now inside bugzilla:
Target Milestone: ovirt-4.3.6

[snip]

>
> Just remind this:
> https://bugzilla.redhat.com/show_bug.cgi?id=1589763
>
> so that if you have to deploy an OS that needs to change CD during
> installation you have problems
> Or if you need to swap CD on a running VM for any reason.
>
> Gianluca
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/76KJO4AWN4C2WKWMA67TLSNDY7RZIERX/

[ovirt-users] Re: Can't import some VMs after storage domain detach and reattach to new datacenter.

[Nir Soffer]

On Tue, Jun 25, 2019 at 9:40 AM  wrote:

> That's interesting.
>
> Where can i find meta for block storage?
>

In block storage metadata is kept in the "metadata" logical volume.

To find metadata for particular volume, you need to to look at the logical
volume tags:

lvs -o tags vg-name/lv-name
Which will output tags like MD_42

The metadata for this volume is at slot number 42.

To find the metadata, you need to calculate the offset in the metadata
logical volume.

On storage domain V4 format, the offset is:

offset=$((42 * 512))

On storage domain V5 format, the offset is:

offset=$((1048576 + 42 * 8192))

You can read the metadata like this:

dd if=/dev/vg-name/metadata bs=512 count=1 skip=$offset conv=skip_bytes
iflag=direct

If you need help you can copy the metadata logical volume and share it here:

dd if=/dev/vg-name/metadata bs=1M count=17 iflag=direct of=metadata-$(date
+%Y-%m-%d-%H-%M)
xz metadata-*

Nir

On NFS storage these files are located next to the disk image.
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/KX2MVSAKJOPAVTKQXOR76QSIISTMCJQE/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/RWIWK5PKSPGMHHK2DR7IRR4FEGCDJIKC/

[ovirt-users] Re: Can't import some VMs after storage domain detach and reattach to new datacenter.

[Nir Soffer]

On Mon, Jun 24, 2019 at 7:47 PM Dmitry Filonov 
wrote:

>
> Take a look at the corresponding .meta file for the disks you can not
> import.
> I had the very same problem and it was caused by
> DISKTYPE=1 in .meta.
>

I want more info on this. We think that the only value ever used for
DISKTYPE is 2.

Do you have any info on how these disks were created? Maybe by some ancient
version?

Nir


> When changed to
> DISKTYPE=DATA I was able to import disks correctly.
> Not the whole VM though..
>
>
> --
> Dmitry Filonov
> Linux Administrator
> SBGrid Core | Harvard Medical School
> 250 Longwood Ave, SGM-114
> Boston, MA 02115
>
>
> On Sun, Jun 23, 2019 at 4:29 AM m black  wrote:
>
>> Hi.
>>
>> I have a problem with importing some VMs after importing storage domain
>> in new datacenter.
>>
>> I have 5 servers with oVirt version 4.1.7, hosted-engine setup and
>> datacenter with iscsi, fc and nfs storages. Also i have 3 servers with
>> oVirt 4.3.4, hosted-engine and nfs storage.
>>
>> I've set iscsi and fc storages to maintenance and detached them
>> successfully on 4.1.7 datacenter.
>> Then i've imported these storage domains via Import Domain in 4.3.4
>> datacenter successfully.
>>
>> After storage domains were imported to new 4.3.4 datacenter i've tried to
>> import VMs from VM Import tab on storages.
>>
>> On the FC storage it was good, all VMs imported and started, all VMs in
>> place.
>>
>> And with iSCSI storage i've got problems:
>> On the iSCSI storage some VMs imported and started, but some of them
>> missing, some of missing VMs disks are showing at Disk Import, i've tried
>> to import disks from Disk Import tab and got error - 'Failed to register
>> disk'.
>> Tried to scan disks with 'Scan Disks' in storage domain, also tried
>> 'Update OVF' - no result.
>>
>> What caused this? What can i do to recover missing VMs? What logs to
>> examine?
>> Can it be storage domain disk corruption?
>>
>> Please, help.
>>
>> Thank you.
>>
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/MF5IUXURKIQZNNG4YW6ELENFD4GZIDQZ/
>>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/BMXCPVIHKKQ3T767KVGMB44BLJOKLP6K/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/XI2QRQFHJ7LYJHXU5GQNMLDRDPEKEDK3/

[ovirt-users] Re: Error virNetTLSContextLoadCertFromFile after upgrade from oVirt 4.2 to 4.3.4

[Yedidyah Bar David]

On Tue, Jun 25, 2019 at 12:28 PM Stefano Danzi  wrote:
>
>
>
> Il 25/06/2019 10:08, Yedidyah Bar David ha scritto:
> > On Tue, Jun 25, 2019 at 10:26 AM Stefano Danzi  wrote:
> >>
> >>
> >> Il 25/06/2019 08:27, Yedidyah Bar David ha scritto:
> >>> On Mon, Jun 24, 2019 at 7:56 PM Stefano Danzi  wrote:
>  I've found that this issue is related to:
> 
>  https://bugzilla.redhat.com/show_bug.cgi?id=1648190
> >>> Are you sure?
> >>>
> >>> That bug is about an old cert, generated by an old version, likely
> >>> before we fixed bug 1210486 (even though it's not mentioned in above
> >>> bug).
> >> Yes! Malformed "Not Before" date/time in certs
> >>
>  But i've no idea how fix it
> 
>  Il 24/06/2019 18:19, Stefano Danzi ha scritto:
> > I've just upgraded my test environment from ovirt 4.2 to 4.3.4.
> >>> Was it installed as 4.2, or upgraded? From which first version?
> >> I don't remember the first installed version. Maybe 4.0... I always
> >> upgraded the original installation.
> >>
> > System has only one host (Centos 7.6.1810) and run a self hosted engine.
> >
> > After upgrade I'm not able to run vdsmd (and so hosted engine)
> >
> > Above the error in log:
> >
> >journalctl -xe
> >
> > -- L'unità libvirtd.service ha iniziato la fase di avvio.
> > giu 24 18:09:17 ovirt01.hawai.lan libvirtd[8176]: 2019-06-24
> > 16:09:17.006+: 8176: info : libvirt version: 4.5.0, package:
> > 10.el7_6.12 (CentOS BuildSystem ,
> > 2019-06-20-15:01:15, x86-01.bsys.
> > giu 24 18:09:17 ovirt01.hawai.lan libvirtd[8176]: 2019-06-24
> > 16:09:17.006+: 8176: info : hostname: ovirt01.hawai.lan
> > giu 24 18:09:17 ovirt01.hawai.lan libvirtd[8176]: 2019-06-24
> > 16:09:17.006+: 8176: error : virNetTLSContextLoadCertFromFile:513
> > : Unable to import server certificate /etc/pki/vdsm/certs/vdsmcert.pem
> >>> Did you check this file? Does it exist?
> >>>
> >>> ls -l /etc/pki/vdsm/certs/vdsmcert.pem
> >>>
> >>> Can vdsm user read it?
> >>>
> >>> su - vdsm -s /bin/bash -c 'cat /etc/pki/vdsm/certs/vdsmcert.pem > 
> >>> /dev/null'
> >>>
> >>> Please check/share output of:
> >>>
> >>> openssl x509 -in /etc/pki/vdsm/certs/vdsmcert.pem -text
> >>>
> >>> Thanks and best regards,
> >> vdsm can read vdsmcert. The problem is "Not Before" date:
> >>
> >> [root@ovirt01 ~]# su - vdsm -s /bin/bash -c 'openssl x509 -in
> >> /etc/pki/vdsm/certs/vdsmcert.pem -text'
> >> Certificate:
> >>   Data:
> >>   Version: 3 (0x2)
> >>   Serial Number: 4102 (0x1006)
> >>   Signature Algorithm: sha1WithRSAEncryption
> >>   Issuer: C=US, O=hawai.lan, CN=ovirtbk-sheng.hawai.lan.63272
> >>   Validity
> >>   Not Before: Feb  4 08:36:07 2015
> >>   Not After : Feb  4 08:36:07 2020 GMT
> >> [CUT]
> >>
> >>
> >> [root@ovirt01 ~]# su - vdsm -s /bin/bash -c 'openssl x509 -in
> >> /etc/pki/vdsm/certs/cacert.pem -text'
> >> Certificate:
> >>   Data:
> >>   Version: 3 (0x2)
> >>   Serial Number: 4096 (0x1000)
> >>   Signature Algorithm: sha1WithRSAEncryption
> >>   Issuer: C=US, O=hawai.lan, CN=ovirtbk-sheng.hawai.lan.63272
> >>   Validity
> >>   Not Before: Feb  4 00:06:25 2015
> >>   Not After : Feb  2 00:06:25 2025 GMT
> >>
> > OK :-(
> >
> > So it will be rather difficult to fix.
> >
> > You should have been prompted by engine-setup long ago to renew PKI,
> > weren't you? And when you did, didn't you have to reinstall (or Re-
> > Enroll Certificates, in later versions) all hosts?
>
> I don't remember to ever seen a question about this during engine-setup,
> but it could be.
> In /etc/pki/vdsm/certs/ I can see an old cert and ca with subjet:
>
> [root@ovirt01 ~]# su - vdsm -s /bin/bash -c 'openssl x509 -in
> /etc/pki/vdsm/certs/cacert.pem.20150205093608 -text'
> Certificate:
>  Data:
>  Version: 3 (0x2)
>  Serial Number: 1423056193 (0x54d21d41)
>  Signature Algorithm: sha256WithRSAEncryption
>  Issuer: CN=VDSM Certificate Authority
>  Validity
>  Not Before: Feb  4 13:23:13 2015 GMT
>  Not After : Feb  4 13:23:13 2016 GMT
>  Subject: CN=VDSM Certificate Authority
>  Subject Public Key Info:
>
> [CUT]
>
> [root@ovirt01 ~]# su - vdsm -s /bin/bash -c 'openssl x509 -in
> /etc/pki/vdsm/certs/vdsmcert.pem.20150205093609 -text'
> Certificate:
>  Data:
>  Version: 3 (0x2)
>  Serial Number: 1423056193 (0x54d21d41)
>  Signature Algorithm: sha256WithRSAEncryption
>  Issuer: CN=VDSM Certificate Authority
>  Validity
>  Not Before: Feb  4 13:23:13 2015 GMT
>  Not After : Feb  4 13:23:13 2016 GMT
>  Subject: CN=ovirt01.hawai.lan, O=VDSM Certificate
>  Subject Public Key Info:
>  Public Key Algorithm: rsaEncryption
>
>
> I think that was certs made during fi

[ovirt-users] Re: Error virNetTLSContextLoadCertFromFile after upgrade from oVirt 4.2 to 4.3.4

[Stefano Danzi]

Il 25/06/2019 10:08, Yedidyah Bar David ha scritto:

On Tue, Jun 25, 2019 at 10:26 AM Stefano Danzi  wrote:



Il 25/06/2019 08:27, Yedidyah Bar David ha scritto:

On Mon, Jun 24, 2019 at 7:56 PM Stefano Danzi  wrote:

I've found that this issue is related to:

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

Are you sure?

That bug is about an old cert, generated by an old version, likely
before we fixed bug 1210486 (even though it's not mentioned in above
bug).

Yes! Malformed "Not Before" date/time in certs


But i've no idea how fix it

Il 24/06/2019 18:19, Stefano Danzi ha scritto:

I've just upgraded my test environment from ovirt 4.2 to 4.3.4.

Was it installed as 4.2, or upgraded? From which first version?

I don't remember the first installed version. Maybe 4.0... I always
upgraded the original installation.


System has only one host (Centos 7.6.1810) and run a self hosted engine.

After upgrade I'm not able to run vdsmd (and so hosted engine)

Above the error in log:

   journalctl -xe

-- L'unità libvirtd.service ha iniziato la fase di avvio.
giu 24 18:09:17 ovirt01.hawai.lan libvirtd[8176]: 2019-06-24
16:09:17.006+: 8176: info : libvirt version: 4.5.0, package:
10.el7_6.12 (CentOS BuildSystem ,
2019-06-20-15:01:15, x86-01.bsys.
giu 24 18:09:17 ovirt01.hawai.lan libvirtd[8176]: 2019-06-24
16:09:17.006+: 8176: info : hostname: ovirt01.hawai.lan
giu 24 18:09:17 ovirt01.hawai.lan libvirtd[8176]: 2019-06-24
16:09:17.006+: 8176: error : virNetTLSContextLoadCertFromFile:513
: Unable to import server certificate /etc/pki/vdsm/certs/vdsmcert.pem

Did you check this file? Does it exist?

ls -l /etc/pki/vdsm/certs/vdsmcert.pem

Can vdsm user read it?

su - vdsm -s /bin/bash -c 'cat /etc/pki/vdsm/certs/vdsmcert.pem > /dev/null'

Please check/share output of:

openssl x509 -in /etc/pki/vdsm/certs/vdsmcert.pem -text

Thanks and best regards,

vdsm can read vdsmcert. The problem is "Not Before" date:

[root@ovirt01 ~]# su - vdsm -s /bin/bash -c 'openssl x509 -in
/etc/pki/vdsm/certs/vdsmcert.pem -text'
Certificate:
  Data:
  Version: 3 (0x2)
  Serial Number: 4102 (0x1006)
  Signature Algorithm: sha1WithRSAEncryption
  Issuer: C=US, O=hawai.lan, CN=ovirtbk-sheng.hawai.lan.63272
  Validity
  Not Before: Feb  4 08:36:07 2015
  Not After : Feb  4 08:36:07 2020 GMT
[CUT]


[root@ovirt01 ~]# su - vdsm -s /bin/bash -c 'openssl x509 -in
/etc/pki/vdsm/certs/cacert.pem -text'
Certificate:
  Data:
  Version: 3 (0x2)
  Serial Number: 4096 (0x1000)
  Signature Algorithm: sha1WithRSAEncryption
  Issuer: C=US, O=hawai.lan, CN=ovirtbk-sheng.hawai.lan.63272
  Validity
  Not Before: Feb  4 00:06:25 2015
  Not After : Feb  2 00:06:25 2025 GMT


OK :-(

So it will be rather difficult to fix.

You should have been prompted by engine-setup long ago to renew PKI,
weren't you? And when you did, didn't you have to reinstall (or Re-
Enroll Certificates, in later versions) all hosts?


I don't remember to ever seen a question about this during engine-setup, 
but it could be.

In /etc/pki/vdsm/certs/ I can see an old cert and ca with subjet:

[root@ovirt01 ~]# su - vdsm -s /bin/bash -c 'openssl x509 -in 
/etc/pki/vdsm/certs/cacert.pem.20150205093608 -text'

Certificate:
    Data:
    Version: 3 (0x2)
    Serial Number: 1423056193 (0x54d21d41)
    Signature Algorithm: sha256WithRSAEncryption
    Issuer: CN=VDSM Certificate Authority
    Validity
    Not Before: Feb  4 13:23:13 2015 GMT
    Not After : Feb  4 13:23:13 2016 GMT
    Subject: CN=VDSM Certificate Authority
    Subject Public Key Info:

[CUT]

[root@ovirt01 ~]# su - vdsm -s /bin/bash -c 'openssl x509 -in 
/etc/pki/vdsm/certs/vdsmcert.pem.20150205093609 -text'

Certificate:
    Data:
    Version: 3 (0x2)
    Serial Number: 1423056193 (0x54d21d41)
    Signature Algorithm: sha256WithRSAEncryption
    Issuer: CN=VDSM Certificate Authority
    Validity
    Not Before: Feb  4 13:23:13 2015 GMT
    Not After : Feb  4 13:23:13 2016 GMT
    Subject: CN=ovirt01.hawai.lan, O=VDSM Certificate
    Subject Public Key Info:
    Public Key Algorithm: rsaEncryption


I think that was certs made during first hosted engine installation.
Could it work if I manually create certs like this?
Just to start libvirtd, vdsm and hosted-engine.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/CBJGZAFKMBRK3RM4TOGWAJ64Y7W5NT7O/

[ovirt-users] Reinstall the whole infrastructure

[Markus Schaufler]

Hi!

We have installed our test infrastructure on 4 Centos hosts. Our self-hosted 
engine further manages serveral stand alone hosts as separate datacenters. 

We'd like now to reinstall the whole thing in a best practice way with oVirt 
node and a fresh hosted engine. 

We have planned to:
- set up 2 of the 4 hosts with ovirt node
- shut down the old hosted engine
- set up the new hosted engine with the same name
- move the VM's from the old cluster to the export domain in a maintenance 
windows
- import the VMs to the new cluster
- attach the stand alone hosts to the new hosted engine in again separate 
datacenters

Is this way possible to go or are there other ways e.g. without the need of a 
maintenance window?

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

[ovirt-users] Re: iso files

[suporte]

The bug only refers version 4.2. The problem remains on version 4.3? 

José 


De: "Gianluca Cecchi"  
Para: "Strahil Nikolov"  
Cc: "users" , supo...@logicworks.pt 
Enviadas: Terça-feira, 25 De Junho de 2019 7:41:27 
Assunto: Re: [ovirt-users] Re: iso files 

On Mon, Jun 24, 2019 at 9:26 PM Strahil Nikolov < hunter86...@yahoo.com > 
wrote: 



Iso domains are deprecated. You can upload an ISO to a data domain via UI (and 
maybe API). 

Best Regards, 
Strahil Nikolov 

В понеделник, 24 юни 2019 г., 16:33:57 ч. Гринуич+3, < supo...@logicworks.pt > 
написа: 


Hi, 

is possible to install a VM without an ISO domain? for version 4.3.4.3 ? 

Thanks 



Just remind this: 
https://bugzilla.redhat.com/show_bug.cgi?id=1589763 

so that if you have to deploy an OS that needs to change CD during installation 
you have problems 
Or if you need to swap CD on a running VM for any reason. 

Gianluca 

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

[ovirt-users] Re: McAfee.com/Activate

[jeff root]

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

[ovirt-users] Re: Error virNetTLSContextLoadCertFromFile after upgrade from oVirt 4.2 to 4.3.4

[Yedidyah Bar David]

On Tue, Jun 25, 2019 at 10:26 AM Stefano Danzi  wrote:
>
>
>
> Il 25/06/2019 08:27, Yedidyah Bar David ha scritto:
> > On Mon, Jun 24, 2019 at 7:56 PM Stefano Danzi  wrote:
> >> I've found that this issue is related to:
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1648190
> > Are you sure?
> >
> > That bug is about an old cert, generated by an old version, likely
> > before we fixed bug 1210486 (even though it's not mentioned in above
> > bug).
>
> Yes! Malformed "Not Before" date/time in certs
>
> >> But i've no idea how fix it
> >>
> >> Il 24/06/2019 18:19, Stefano Danzi ha scritto:
> >>> I've just upgraded my test environment from ovirt 4.2 to 4.3.4.
> > Was it installed as 4.2, or upgraded? From which first version?
>
> I don't remember the first installed version. Maybe 4.0... I always
> upgraded the original installation.
>
> >>> System has only one host (Centos 7.6.1810) and run a self hosted engine.
> >>>
> >>> After upgrade I'm not able to run vdsmd (and so hosted engine)
> >>>
> >>> Above the error in log:
> >>>
> >>>   journalctl -xe
> >>>
> >>> -- L'unità libvirtd.service ha iniziato la fase di avvio.
> >>> giu 24 18:09:17 ovirt01.hawai.lan libvirtd[8176]: 2019-06-24
> >>> 16:09:17.006+: 8176: info : libvirt version: 4.5.0, package:
> >>> 10.el7_6.12 (CentOS BuildSystem ,
> >>> 2019-06-20-15:01:15, x86-01.bsys.
> >>> giu 24 18:09:17 ovirt01.hawai.lan libvirtd[8176]: 2019-06-24
> >>> 16:09:17.006+: 8176: info : hostname: ovirt01.hawai.lan
> >>> giu 24 18:09:17 ovirt01.hawai.lan libvirtd[8176]: 2019-06-24
> >>> 16:09:17.006+: 8176: error : virNetTLSContextLoadCertFromFile:513
> >>> : Unable to import server certificate /etc/pki/vdsm/certs/vdsmcert.pem
> > Did you check this file? Does it exist?
> >
> > ls -l /etc/pki/vdsm/certs/vdsmcert.pem
> >
> > Can vdsm user read it?
> >
> > su - vdsm -s /bin/bash -c 'cat /etc/pki/vdsm/certs/vdsmcert.pem > /dev/null'
> >
> > Please check/share output of:
> >
> > openssl x509 -in /etc/pki/vdsm/certs/vdsmcert.pem -text
> >
> > Thanks and best regards,
>
> vdsm can read vdsmcert. The problem is "Not Before" date:
>
> [root@ovirt01 ~]# su - vdsm -s /bin/bash -c 'openssl x509 -in
> /etc/pki/vdsm/certs/vdsmcert.pem -text'
> Certificate:
>  Data:
>  Version: 3 (0x2)
>  Serial Number: 4102 (0x1006)
>  Signature Algorithm: sha1WithRSAEncryption
>  Issuer: C=US, O=hawai.lan, CN=ovirtbk-sheng.hawai.lan.63272
>  Validity
>  Not Before: Feb  4 08:36:07 2015
>  Not After : Feb  4 08:36:07 2020 GMT
> [CUT]
>
>
> [root@ovirt01 ~]# su - vdsm -s /bin/bash -c 'openssl x509 -in
> /etc/pki/vdsm/certs/cacert.pem -text'
> Certificate:
>  Data:
>  Version: 3 (0x2)
>  Serial Number: 4096 (0x1000)
>  Signature Algorithm: sha1WithRSAEncryption
>  Issuer: C=US, O=hawai.lan, CN=ovirtbk-sheng.hawai.lan.63272
>  Validity
>  Not Before: Feb  4 00:06:25 2015
>  Not After : Feb  2 00:06:25 2025 GMT
>

OK :-(

So it will be rather difficult to fix.

You should have been prompted by engine-setup long ago to renew PKI,
weren't you? And when you did, didn't you have to reinstall (or Re-
Enroll Certificates, in later versions) all hosts?

Anyway:

If at all possible, please try to downgrade whatever upgrade that
caused this to fail. You can check 'yum history', 'yum history info
$ID', 'yum history undo $ID'. Then start your engine vm, start the
engine, re-install or re-enroll-certs all hosts. See also:

https://www.ovirt.org/develop/release-management/releases/3.5.4/#pki

Then upgrade again what you downgraded.

If that's impossible, it will be harder. I can think of two choices:

1. Consider the engine is completely dead and reinstall everything
from scratch. Hopefully, attaching to the existing storage domains and
importing all VMs will not be too hard and will not loose too much
information. Alternatively, if you have an engine-backup backup, you
can try restore from it. hosted-engine in recent versions can do this
mostly-automatically. Search the web for "hosted-engine
--restore-from-file".

2. Try to manually fix. Something like:

- Find the image of the engine vm on the hosted-engine storage
- Use some means to "edit" it - e.g. guestfish (but there are also
older, less comfortable means - e.g. copy the image elsewhere and
start a new kvm VM from it, or something like that). Assuming you
manage to get to some environment that lets you run commands inside
the engine vm image, in its context:
- I do not find a csr for the vdsm key on a host I am checking.
Assuming you don't either, you should generate one from its private
key. So do this on the host (not engine):

openssl req -new -days 365 -key /etc/pki/vdsm/keys/vdsmkey.pem -out
/tmp/vdsm.req -batch -subj /

Somehow copy /tmp/vdsm.req to the engine machine to e.g.
/etc/pki/ovirt-engine/requests/new-host1.req

Run on the engine machine something like:

/usr/share/ov

[ovirt-users] Re: Error virNetTLSContextLoadCertFromFile after upgrade from oVirt 4.2 to 4.3.4

[Stefano Danzi]

Il 25/06/2019 08:27, Yedidyah Bar David ha scritto:

On Mon, Jun 24, 2019 at 7:56 PM Stefano Danzi  wrote:

I've found that this issue is related to:

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

Are you sure?

That bug is about an old cert, generated by an old version, likely
before we fixed bug 1210486 (even though it's not mentioned in above
bug).


Yes! Malformed "Not Before" date/time in certs


But i've no idea how fix it

Il 24/06/2019 18:19, Stefano Danzi ha scritto:

I've just upgraded my test environment from ovirt 4.2 to 4.3.4.

Was it installed as 4.2, or upgraded? From which first version?


I don't remember the first installed version. Maybe 4.0... I always 
upgraded the original installation.



System has only one host (Centos 7.6.1810) and run a self hosted engine.

After upgrade I'm not able to run vdsmd (and so hosted engine)

Above the error in log:

  journalctl -xe

-- L'unità libvirtd.service ha iniziato la fase di avvio.
giu 24 18:09:17 ovirt01.hawai.lan libvirtd[8176]: 2019-06-24
16:09:17.006+: 8176: info : libvirt version: 4.5.0, package:
10.el7_6.12 (CentOS BuildSystem ,
2019-06-20-15:01:15, x86-01.bsys.
giu 24 18:09:17 ovirt01.hawai.lan libvirtd[8176]: 2019-06-24
16:09:17.006+: 8176: info : hostname: ovirt01.hawai.lan
giu 24 18:09:17 ovirt01.hawai.lan libvirtd[8176]: 2019-06-24
16:09:17.006+: 8176: error : virNetTLSContextLoadCertFromFile:513
: Unable to import server certificate /etc/pki/vdsm/certs/vdsmcert.pem

Did you check this file? Does it exist?

ls -l /etc/pki/vdsm/certs/vdsmcert.pem

Can vdsm user read it?

su - vdsm -s /bin/bash -c 'cat /etc/pki/vdsm/certs/vdsmcert.pem > /dev/null'

Please check/share output of:

openssl x509 -in /etc/pki/vdsm/certs/vdsmcert.pem -text

Thanks and best regards,


vdsm can read vdsmcert. The problem is "Not Before" date:

[root@ovirt01 ~]# su - vdsm -s /bin/bash -c 'openssl x509 -in 
/etc/pki/vdsm/certs/vdsmcert.pem -text'

Certificate:
    Data:
    Version: 3 (0x2)
    Serial Number: 4102 (0x1006)
    Signature Algorithm: sha1WithRSAEncryption
    Issuer: C=US, O=hawai.lan, CN=ovirtbk-sheng.hawai.lan.63272
    Validity
    Not Before: Feb  4 08:36:07 2015
    Not After : Feb  4 08:36:07 2020 GMT
[CUT]


[root@ovirt01 ~]# su - vdsm -s /bin/bash -c 'openssl x509 -in 
/etc/pki/vdsm/certs/cacert.pem -text'

Certificate:
    Data:
    Version: 3 (0x2)
    Serial Number: 4096 (0x1000)
    Signature Algorithm: sha1WithRSAEncryption
    Issuer: C=US, O=hawai.lan, CN=ovirtbk-sheng.hawai.lan.63272
    Validity
    Not Before: Feb  4 00:06:25 2015
    Not After : Feb  2 00:06:25 2025 GMT


giu 24 18:09:17 ovirt01.hawai.lan systemd[1]: libvirtd.service: main
process exited, code=exited, status=6/NOTCONFIGURED
giu 24 18:09:17 ovirt01.hawai.lan systemd[1]: Failed to start
Virtualization daemon.
-- Subject: L'unità libvirtd.service è fallita


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

[ovirt-users] Re: Can't import some VMs after storage domain detach and reattach to new datacenter.

[mblack0]

Sorry for the delay.

vdsm logs are huge, i'll cut when i moved storage domains and attach the logs.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/LJYLA54GQVTZSDC4ESF5MPUHKESQG5FJ/