[ovirt-users] Re: Guest VM snapshots are not retained when importing data storage domain

[Alex K]

Has anyone been able to import a storage domain and still have access to VM
snapshots or this might be a missing feature/bug that needs to be reported?
Reading the redhat docs about the storage domain import it seems there is
no mention of VM snapshots if they should be accessible following the
import.
Thanx

On Thu, Jul 30, 2020 at 3:58 PM Alex K  wrote:

> Hi all,
>
> I have a dual node self hosted cluster v4.3 using gluster as storage so as
> to test an actual scenario which will need to be followed at production.
> The purpose is to rename the cluster FQDN to a new one, wiping out any
> reference to the old previous FQDN. I was not successful in using the
> engine-rename tool or other means as there are leftovers from previous FQDN
> that cause issues.
>
> The cluster has a data storage domain with one guest VM running on it
> which has one snapshot.
> I am testing a destructive scenario as below and I find out that when
> importing the storage domain to the newly configured cluster, while the
> guest VM is imported fine, I do not see the guest VM disk snapshots.
>
> Steps that I follow for this scenario:
>
> *Initial status: *
> I have an ovirt cluster with two hosts named v0 and v1.
> The gluster storage domain is configured at a separate network where the
> hosts are named gluster0 and gluster1.
> The cluster has an engine and data storage domain named "engine" and "vms"
> respectively.
> The "vms" storage domain hosts one guest VM with one guest VM disk
> snapshot.
> All are configured with fqdn *localdomain.local*
>
> *# Steps to rename all cluster to new fqdn lab.local and import "vms"
> storage domain*
> 1. Set v1 ovirt host at maintenance then remove it from GUI.
> 2.  At v1 install fresh CentOS7 using the new FQDN lab.local
> 3.  at v0 set global maintenance and shutdown engine. Remove the engine
> storage data. (complete wipe of any engine related data. What is important
> is only VM guests and their snapshots).
> 4.  at v0, remove bricks belonging to "engine" and "vms" gluster volumes
> of v1 and detach gluster peer v1.
>
> gluster volume remove-brick engine replica 1
> gluster1:/gluster/engine/brick force
> gluster volume remove-brick vms replica 1 gluster1:/gluster/vms/brick force
> gluster peer detach gluster1
>
> 5.  On v1, prepare gluster service, reattach peer and add bricks from v0.
> At this phase all data from vms gluster volume will be synced to the new
> host. Verify with `gluster heal info vms`.
> from v0 server run:
>
> gluster peer probe gluster1
> gluster volume add-brick engine replica 2 gluster1:/gluster/engine/brick
> gluster volume add-brick vms replica 2 gluster1:/gluster/vms/brick
>
> At this state all gluster volume are up and in sync. We confirm "vms" sync
> with
> gluster volume heal info vms
>
> 6.  At freshly installed v1 install engine using the same clean gluster
> engine volume:
> hosted-engine --deploy --config-append=/root/storage.conf
> --config-append=answers.conf (use new FQDN!)
>
> 7.  Upon completion of engine deployment and after having ensured the vms
> gluster volume is synced (step 5) remove bricks of v0 host (v0 now should
> not be visible at ovirt GUI) and detach gluster peer v0.
> at v1 host run:
> gluster volume remove-brick engine replica 1
> gluster0:/gluster/engine/brick force
> gluster volume remove-brick vms replica 1 gluster0:/gluster/vms/brick force
> gluster peer detach gluster0
>
> 8. Install fresh CentOS7 on v0 and prepare it with ovirt node packages,
> networking and gluster.
> 9. At v0, attach gluster bricks from v1. Confirm sync with gluster volume
> heal info.
> at v1 host:
> gluster peer probe gluster0
> gluster volume add-brick engine replica 2 gluster0:/gluster/engine/brick
> gluster volume add-brick vms replica 2 gluster0:/gluster/vms/brick
>
> 10. at engine, add entry for v0 host at /etc/hosts. At ovirt GUI, add v0.
> /etc/hosts:
> 10.10.10.220 node0 v0.lab.local
> 10.10.10.221 node1 v1.lab.local
> 10.10.10.222 engine.lab.local engine
>
> 10.100.100.1 gluster0
> 10.100.100.2 gluster1
>
> 11. At ovirt GUI import vms gluster volume as vms storage domain.
> At this step I have to approve operation:
> [image: image.png]
>
>
> 12. At ovirt GUI, import VMs from vms storage domain.
> At this step the VM is found and imported from the imported storage domain
> "vms", but the VM does not show the previously available disk snapshot.
>
> The import of the storage domain should have retained the guest VM
> snapshot.
> How can this be troubleshooted? Do I have to keep some type of engine DB
> backup so as to make the snapshots visible? If yes, is it possible to
> restore this backup to a fresh engine that has a new FQDN?
> Thanx very much for any advise and hint.
>
> Alex
>
>
___
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/communit

[ovirt-users] Re: Guest VM snapshots are not retained when importing data storage domain

[Strahil Nikolov via Users]

Theoretically, all the data for the snapshot is both in the Engine's DB and on 
storage (OVF file).

I was afraid to migrate from 4.3  to  4.4  ,  as I was planning  to  wipe the 
engine  and  just import the VMs..., but  I was  not sure  about the snapshots.

Most probably this is a bug.

@Sandro,

can you assist with this one  ?

Best Regards,
Strahil Nikolov

На 31 юли 2020 г. 10:01:17 GMT+03:00, Alex K  написа:
>Has anyone been able to import a storage domain and still have access
>to VM
>snapshots or this might be a missing feature/bug that needs to be
>reported?
>Reading the redhat docs about the storage domain import it seems there
>is
>no mention of VM snapshots if they should be accessible following the
>import.
>Thanx
>
>On Thu, Jul 30, 2020 at 3:58 PM Alex K  wrote:
>
>> Hi all,
>>
>> I have a dual node self hosted cluster v4.3 using gluster as storage
>so as
>> to test an actual scenario which will need to be followed at
>production.
>> The purpose is to rename the cluster FQDN to a new one, wiping out
>any
>> reference to the old previous FQDN. I was not successful in using the
>> engine-rename tool or other means as there are leftovers from
>previous FQDN
>> that cause issues.
>>
>> The cluster has a data storage domain with one guest VM running on it
>> which has one snapshot.
>> I am testing a destructive scenario as below and I find out that when
>> importing the storage domain to the newly configured cluster, while
>the
>> guest VM is imported fine, I do not see the guest VM disk snapshots.
>>
>> Steps that I follow for this scenario:
>>
>> *Initial status: *
>> I have an ovirt cluster with two hosts named v0 and v1.
>> The gluster storage domain is configured at a separate network where
>the
>> hosts are named gluster0 and gluster1.
>> The cluster has an engine and data storage domain named "engine" and
>"vms"
>> respectively.
>> The "vms" storage domain hosts one guest VM with one guest VM disk
>> snapshot.
>> All are configured with fqdn *localdomain.local*
>>
>> *# Steps to rename all cluster to new fqdn lab.local and import "vms"
>> storage domain*
>> 1. Set v1 ovirt host at maintenance then remove it from GUI.
>> 2.  At v1 install fresh CentOS7 using the new FQDN lab.local
>> 3.  at v0 set global maintenance and shutdown engine. Remove the
>engine
>> storage data. (complete wipe of any engine related data. What is
>important
>> is only VM guests and their snapshots).
>> 4.  at v0, remove bricks belonging to "engine" and "vms" gluster
>volumes
>> of v1 and detach gluster peer v1.
>>
>> gluster volume remove-brick engine replica 1
>> gluster1:/gluster/engine/brick force
>> gluster volume remove-brick vms replica 1 gluster1:/gluster/vms/brick
>force
>> gluster peer detach gluster1
>>
>> 5.  On v1, prepare gluster service, reattach peer and add bricks from
>v0.
>> At this phase all data from vms gluster volume will be synced to the
>new
>> host. Verify with `gluster heal info vms`.
>> from v0 server run:
>>
>> gluster peer probe gluster1
>> gluster volume add-brick engine replica 2
>gluster1:/gluster/engine/brick
>> gluster volume add-brick vms replica 2 gluster1:/gluster/vms/brick
>>
>> At this state all gluster volume are up and in sync. We confirm "vms"
>sync
>> with
>> gluster volume heal info vms
>>
>> 6.  At freshly installed v1 install engine using the same clean
>gluster
>> engine volume:
>> hosted-engine --deploy --config-append=/root/storage.conf
>> --config-append=answers.conf (use new FQDN!)
>>
>> 7.  Upon completion of engine deployment and after having ensured the
>vms
>> gluster volume is synced (step 5) remove bricks of v0 host (v0 now
>should
>> not be visible at ovirt GUI) and detach gluster peer v0.
>> at v1 host run:
>> gluster volume remove-brick engine replica 1
>> gluster0:/gluster/engine/brick force
>> gluster volume remove-brick vms replica 1 gluster0:/gluster/vms/brick
>force
>> gluster peer detach gluster0
>>
>> 8. Install fresh CentOS7 on v0 and prepare it with ovirt node
>packages,
>> networking and gluster.
>> 9. At v0, attach gluster bricks from v1. Confirm sync with gluster
>volume
>> heal info.
>> at v1 host:
>> gluster peer probe gluster0
>> gluster volume add-brick engine replica 2
>gluster0:/gluster/engine/brick
>> gluster volume add-brick vms replica 2 gluster0:/gluster/vms/brick
>>
>> 10. at engine, add entry for v0 host at /etc/hosts. At ovirt GUI, add
>v0.
>> /etc/hosts:
>> 10.10.10.220 node0 v0.lab.local
>> 10.10.10.221 node1 v1.lab.local
>> 10.10.10.222 engine.lab.local engine
>>
>> 10.100.100.1 gluster0
>> 10.100.100.2 gluster1
>>
>> 11. At ovirt GUI import vms gluster volume as vms storage domain.
>> At this step I have to approve operation:
>> [image: image.png]
>>
>>
>> 12. At ovirt GUI, import VMs from vms storage domain.
>> At this step the VM is found and imported from the imported storage
>domain
>> "vms", but the VM does not show the previously available disk
>snapshot.
>>
>> The import of the storage domain should have retained the gue

[ovirt-users] Re: Guest VM snapshots are not retained when importing data storage domain

[Alex K]

On Fri, Jul 31, 2020 at 12:30 PM Strahil Nikolov 
wrote:

> Theoretically, all the data for the snapshot is both in the Engine's DB
> and on storage (OVF file).
>
> I was afraid to migrate from 4.3  to  4.4  ,  as I was planning  to  wipe
> the engine  and  just import the VMs..., but  I was  not sure  about the
> snapshots.
>
I did not check the actual backing chain of the VM disk image. I reset my
test env and will need to repeat some time to check it. In case there is
still a chain of images referring to the child image then it could be that
we need engine DB informed about this, thus wiping out engine seems not a
viable option. There should be some engine DB import type that could
restore those images and make them visible (again, if they really exist
under the hood which is still to be checked).

>
> Most probably this is a bug.
>
> @Sandro,
>
> can you assist with this one  ?
>
> Best Regards,
> Strahil Nikolov
>
> На 31 юли 2020 г. 10:01:17 GMT+03:00, Alex K 
> написа:
> >Has anyone been able to import a storage domain and still have access
> >to VM
> >snapshots or this might be a missing feature/bug that needs to be
> >reported?
> >Reading the redhat docs about the storage domain import it seems there
> >is
> >no mention of VM snapshots if they should be accessible following the
> >import.
> >Thanx
> >
> >On Thu, Jul 30, 2020 at 3:58 PM Alex K  wrote:
> >
> >> Hi all,
> >>
> >> I have a dual node self hosted cluster v4.3 using gluster as storage
> >so as
> >> to test an actual scenario which will need to be followed at
> >production.
> >> The purpose is to rename the cluster FQDN to a new one, wiping out
> >any
> >> reference to the old previous FQDN. I was not successful in using the
> >> engine-rename tool or other means as there are leftovers from
> >previous FQDN
> >> that cause issues.
> >>
> >> The cluster has a data storage domain with one guest VM running on it
> >> which has one snapshot.
> >> I am testing a destructive scenario as below and I find out that when
> >> importing the storage domain to the newly configured cluster, while
> >the
> >> guest VM is imported fine, I do not see the guest VM disk snapshots.
> >>
> >> Steps that I follow for this scenario:
> >>
> >> *Initial status: *
> >> I have an ovirt cluster with two hosts named v0 and v1.
> >> The gluster storage domain is configured at a separate network where
> >the
> >> hosts are named gluster0 and gluster1.
> >> The cluster has an engine and data storage domain named "engine" and
> >"vms"
> >> respectively.
> >> The "vms" storage domain hosts one guest VM with one guest VM disk
> >> snapshot.
> >> All are configured with fqdn *localdomain.local*
> >>
> >> *# Steps to rename all cluster to new fqdn lab.local and import "vms"
> >> storage domain*
> >> 1. Set v1 ovirt host at maintenance then remove it from GUI.
> >> 2.  At v1 install fresh CentOS7 using the new FQDN lab.local
> >> 3.  at v0 set global maintenance and shutdown engine. Remove the
> >engine
> >> storage data. (complete wipe of any engine related data. What is
> >important
> >> is only VM guests and their snapshots).
> >> 4.  at v0, remove bricks belonging to "engine" and "vms" gluster
> >volumes
> >> of v1 and detach gluster peer v1.
> >>
> >> gluster volume remove-brick engine replica 1
> >> gluster1:/gluster/engine/brick force
> >> gluster volume remove-brick vms replica 1 gluster1:/gluster/vms/brick
> >force
> >> gluster peer detach gluster1
> >>
> >> 5.  On v1, prepare gluster service, reattach peer and add bricks from
> >v0.
> >> At this phase all data from vms gluster volume will be synced to the
> >new
> >> host. Verify with `gluster heal info vms`.
> >> from v0 server run:
> >>
> >> gluster peer probe gluster1
> >> gluster volume add-brick engine replica 2
> >gluster1:/gluster/engine/brick
> >> gluster volume add-brick vms replica 2 gluster1:/gluster/vms/brick
> >>
> >> At this state all gluster volume are up and in sync. We confirm "vms"
> >sync
> >> with
> >> gluster volume heal info vms
> >>
> >> 6.  At freshly installed v1 install engine using the same clean
> >gluster
> >> engine volume:
> >> hosted-engine --deploy --config-append=/root/storage.conf
> >> --config-append=answers.conf (use new FQDN!)
> >>
> >> 7.  Upon completion of engine deployment and after having ensured the
> >vms
> >> gluster volume is synced (step 5) remove bricks of v0 host (v0 now
> >should
> >> not be visible at ovirt GUI) and detach gluster peer v0.
> >> at v1 host run:
> >> gluster volume remove-brick engine replica 1
> >> gluster0:/gluster/engine/brick force
> >> gluster volume remove-brick vms replica 1 gluster0:/gluster/vms/brick
> >force
> >> gluster peer detach gluster0
> >>
> >> 8. Install fresh CentOS7 on v0 and prepare it with ovirt node
> >packages,
> >> networking and gluster.
> >> 9. At v0, attach gluster bricks from v1. Confirm sync with gluster
> >volume
> >> heal info.
> >> at v1 host:
> >> gluster peer probe gluster0
> >> gluster volume add-brick engine repli

[ovirt-users] Changing FQDN

[Alex K]

Hi all,

I am running ovirt 4.2.8
I did change ovirt engine FQDN using ovirt-engine-rename tool following

https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/html/administration_guide/chap-Utilities#Updating_SSL_Certificates

Hosts FQDN is also changed and all seem fine apart from OVN connection and
ImageIO proxy.

About OVN, i just configured OVN and when I test connection I get:

Failed with error Certificate for  doesn't match any of the
subject alternative names: [old fqdn] and code 5050)

about Imageio proxy when I test the connection I do get nothing. No error
at engine.log or at GUI.

Thus it seems that I have to generate/replace new certs.
Is there a way I can fix this until I switch to 4.3 and eventually to 4.4
where it seems that this is handled from the rename tool?

Thanks for any assistance.
Alex.
___
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/XKOUI5FPDDUY3FGGOEBHTX5JQDMZ4DY6/

[ovirt-users] Re: Changing FQDN

[Dominik Holler]

On Fri, Jul 31, 2020 at 2:44 PM Alex K  wrote:

> Hi all,
>
> I am running ovirt 4.2.8
> I did change ovirt engine FQDN using ovirt-engine-rename tool following
>
>
> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/html/administration_guide/chap-Utilities#Updating_SSL_Certificates
>
> Hosts FQDN is also changed and all seem fine apart from OVN connection and
> ImageIO proxy.
>
> About OVN, i just configured OVN and when I test connection I get:
>
> Failed with error Certificate for  doesn't match any of the
> subject alternative names: [old fqdn] and code 5050)
>


Can you please replace all occurrences of the old fqdn by the new fqdn in
/etc/ovirt-provider-ovn/conf.d/10-setup-ovirt-provider-ovn.conf
and
systemctl restart ovirt-provider-ovn
and let us know if this solves the problem?

This step is not yet automated by ovirt-engine-rename in oVirt-4.2. ,
please find more details in
https://bugzilla.redhat.com/1501798





>
> about Imageio proxy when I test the connection I do get nothing. No error
> at engine.log or at GUI.
>
> Thus it seems that I have to generate/replace new certs.
> Is there a way I can fix this until I switch to 4.3 and eventually to 4.4
> where it seems that this is handled from the rename tool?
>
> Thanks for any assistance.
> Alex.
>
> ___
> 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/XKOUI5FPDDUY3FGGOEBHTX5JQDMZ4DY6/
>
___
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/KGLUWBFXDZDEOFEGSIBCDE3FHUTVZX37/

[ovirt-users] Re: 4.4.x - VLAN-based logical network can't attach to bonds?

[Dominik Holler]

On Fri, Jul 31, 2020 at 12:54 AM Mark R  wrote:

> Following up, as noted in the bug report (
> https://bugzilla.redhat.com/show_bug.cgi?id=1860479 ) this doesn't appear
> to be oVirt / VDSM having issues. You can replicate the same inability to
> attach a bond to a bridge by simply booting the 8.2.2004 installation media
> and trying a few manual 'ip' commands. With older 8.1 or any 7.x install
> media, there's no problem, but starting with 8.2, you can't attach a bond
> to a bridge anymore.
>
> It looks like there may be some similar reports on bugzilla recently. I
> just wanted to note here on the list that this isn't an oVirt problem,
> looks to be an issue with the OS (kernel?).
>
> Thanks again!
>

Thanks for reporting the bug, providing additional information, and this
update. This is a very productive way to solve this issue.



> Mark
> ___
> 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/KUUZJTAF5CWWIUFZPTZMKZFY5QIXUNKI/
>
___
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/7VT7B2CDHIDES26SAGVKS3X5IRFDTIKD/

[ovirt-users] Re: oVirt 4.4.1 HCI single server deployment failed nested-kvm

[thomas]

That's exactly the point: Running oVirt on top of a vanilla KVM seems to be the 
only case supported, because the Redhat engineers use that themselves for 
development, testing and demoing.

Running virtual machines nested inside an oVirt VM via KVM also works per se, 
as HostedEngineLocal during the setup is working, can be talked to etc. from 
the host that is running the setup, because it uses a local bridge. You can 
even reach everyone from within that nested VM on the outside, but the VM 
itsself is only accessible from the host at the point (normal in all cases).

But in the next stage of the installation that locally prepared VM is modified 
to run on the cluster storage, gluster in the HCI case and use the overlay 
network and that's where it loses network connectivity, I guess because overlay 
networks lack nesting (I guess there is still a non-overlay way to run oVirt 
and then perhaps it even works...)

And while I admire that network overlay stuff, it's also black magic to me, and 
evidently not trivial if not downright impossible to resolve, which is most 
likey why the Redhat engineers don't seem to pursue that path. At least that's 
what I read from this comment, which really should be somewhere right next to 
where  "nested virtualization" is ever mentioned, to ensure expectations are 
properly managed. 
https://lists.ovirt.org/pipermail/users/2017-March/080219.html 
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/G5HWL5XN3EEI3UHQACSUNTXVNFZ2V56X/

[ovirt-users] Re: oVirt 4.4.1 HCI single server deployment failed nested-kvm

[thomas]

Just looking at the release notes, using anything 'older' in the case of 4.4 
seems very rough going... 

Testing 4.4 was actually how I got into the nesting domain this time around, 
because I didn't have physical hardware left for another HCI cluster.

Testing of oVirt 4.4 on top of oVirt 4.3 including migration scenarios is 
probably the most sensible use of nesting overall

Alas I had similarly bad luck during my first evaluation of oVirt about a year 
(or two?) ago, when I tried nesting oVirt on top of a big windows workstation 
with VMware Workstation: Everything seemed to work just fine, but nested VMs 
just stopped right at boot, without any error, but also no progress.

I had a vSphere cluster run no problem on that setup...
___
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/XRIK4SK7TFQS7JASUPCVFGWCJI6YS6SM/

[ovirt-users] testing ovirt 4.4 as single node VM inside 4.3

[Philip Brown]

I'm having problems importing OVA exports from vmware 4, into ovirt 4.3

I've read that basically, this is a known issue and that ovirt 4.4 improves the 
import situation greatly.
But I'd like to be able to prove it helps us, before comitting to large 
undertakings. 

Is it going to be doable to run a single node ovirt cluster as  a VM inside 
another one?
Or do I need to run it on bare metal?



--
Philip Brown| Sr. Linux System Administrator | Medata, Inc. 
5 Peters Canyon Rd Suite 250 
Irvine CA 92606 
Office 714.918.1310| Fax 714.918.1325 
pbr...@medata.com| www.medata.com
___
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/RTUBZGCEIQW4PPEYI5AUUAU4X5S7OKOT/

[ovirt-users] Re: testing ovirt 4.4 as single node VM inside 4.3

[Gianluca Cecchi]

On Fri, Jul 31, 2020 at 5:37 PM Philip Brown  wrote:

>
>
> I'm having problems importing OVA exports from vmware 4, into ovirt 4.3
>

So do you mean an OVA created in vSphere and to be used then in oVirt?
What kind of problems? Too generic...
You can also select
Compute --> Virtual Machines
Select the 3 dots at top right and choose "Import"
Between the available sources you can choose VMware where you have to
specify vcenter server and related ESXi credentials, load virtual machine
list as sources and decide which ones to import into oVirt.
This though requires network communication availability between vSphere and
oVirt
I'have used it with success in the past, eg to import a WIndows 2008 R2 VM
with a production Oracle database from vSphere 5.5. to oVirt 4.2 (about two
years ago).



> I've read that basically, this is a known issue and that ovirt 4.4
> improves the import situation greatly.
>

Perhaps, not tested.

But I'd like to be able to prove it helps us, before comitting to large
> undertakings.
>

Understandable

>
> Is it going to be doable to run a single node ovirt cluster as  a VM
> inside another one?
> Or do I need to run it on bare metal?
>
> Can you elaborate better? How do this relate with the previous point?

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

[ovirt-users] Re: testing ovirt 4.4 as single node VM inside 4.3

[Philip Brown]

well, this was related to my thread here a day or two ago, about "where are the 
error logs for import?" I give more details there.

The resulting logs are of no use.
ovirt 4.3 fails on direct import from Vsphere. and it fails on importing a 
manually exported OVA file from vsphere.
With no feedback as to where the failure is caused.

Therefore, I have concluded my only option is to try out 4.4 somehow.
Which is difficult since I dont have centos 8 running on bare metal anywhere.



- Original Message -
From: "Gianluca Cecchi" 
To: "Philip Brown" 
Cc: "users" 
Sent: Friday, July 31, 2020 9:13:12 AM
Subject: Re: [ovirt-users] testing ovirt 4.4 as single node VM inside 4.3

On Fri, Jul 31, 2020 at 5:37 PM Philip Brown  wrote:

>
>
> I'm having problems importing OVA exports from vmware 4, into ovirt 4.3
>

So do you mean an OVA created in vSphere and to be used then in oVirt?
What kind of problems? Too generic...
...
___
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/UK73PEGJ3TK2TANJ7NDIEL37BI4KF6RW/

[ovirt-users] Re: Changing FQDN

[Alex K]

On Fri, Jul 31, 2020, 21:00 Alex K  wrote:

>
>
> On Fri, Jul 31, 2020, 18:26 Dominik Holler  wrote:
>
>>
>>
>> On Fri, Jul 31, 2020 at 4:00 PM Alex K  wrote:
>>
>>>
>>>
>>> On Fri, Jul 31, 2020 at 4:50 PM Dominik Holler 
>>> wrote:
>>>


 On Fri, Jul 31, 2020 at 2:44 PM Alex K  wrote:

> Hi all,
>
> I am running ovirt 4.2.8
> I did change ovirt engine FQDN using ovirt-engine-rename tool following
>
>
> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/html/administration_guide/chap-Utilities#Updating_SSL_Certificates
>
> Hosts FQDN is also changed and all seem fine apart from OVN connection
> and ImageIO proxy.
>
> About OVN, i just configured OVN and when I test connection I get:
>
> Failed with error Certificate for  doesn't match any of the
> subject alternative names: [old fqdn] and code 5050)
>


 Can you please replace all occurrences of the old fqdn by the new fqdn
 in
 /etc/ovirt-provider-ovn/conf.d/10-setup-ovirt-provider-ovn.conf
 and
 systemctl restart ovirt-provider-ovn
 and let us know if this solves the problem?

>>> DId it and the same error is reported.
>>> Then tried to engine-setup and still same issue.
>>>
>>
>> Can you please check if adjusting both URLs of the ovirt-provider-ovn
>> external network provider in oVirt Engine in the
>> oVirt Administration Portal -> Administration -> Providers ->
>> ovirt-provider-ovn -> Edit
>> solves the issue?
>>
> Forgot to mention that I had already changed that to reflect new fqdn.
> Both url and hostname.
>
I think that the issue lies at the ca subject still referring to previous
fqdn.

>
>>
>>
>>>
 This step is not yet automated by ovirt-engine-rename in oVirt-4.2. ,
 please find more details in
 https://bugzilla.redhat.com/1501798
 




>
> about Imageio proxy when I test the connection I do get nothing. No
> error at engine.log or at GUI.
>
> Thus it seems that I have to generate/replace new certs.
> Is there a way I can fix this until I switch to 4.3 and eventually to
> 4.4 where it seems that this is handled from the rename tool?
>
> Thanks for any assistance.
> Alex.
>
> ___
> 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/XKOUI5FPDDUY3FGGOEBHTX5JQDMZ4DY6/
>

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

[ovirt-users] Re: testing ovirt 4.4 as single node VM inside 4.3

[Nir Soffer]

On Fri, Jul 31, 2020 at 8:09 PM Philip Brown  wrote:
>
> well, this was related to my thread here a day or two ago, about "where are 
> the error logs for import?" I give more details there.
>
> The resulting logs are of no use.
> ovirt 4.3 fails on direct import from Vsphere. and it fails on importing a 
> manually exported OVA file from vsphere.
> With no feedback as to where the failure is caused.

Steven, do we know about any issue in 4.3 with importing ovas?

> Therefore, I have concluded my only option is to try out 4.4 somehow.

This is a good idea, you will not get any fixes in 4.3 at this point. We usually
support only the latest version.

> Which is difficult since I dont have centos 8 running on bare metal anywhere.

Nested VM should work, we use this internally for development. But you will
not get the best performance this way.

Nir

> - Original Message -
> From: "Gianluca Cecchi" 
> To: "Philip Brown" 
> Cc: "users" 
> Sent: Friday, July 31, 2020 9:13:12 AM
> Subject: Re: [ovirt-users] testing ovirt 4.4 as single node VM inside 4.3
>
> On Fri, Jul 31, 2020 at 5:37 PM Philip Brown  wrote:
>
> >
> >
> > I'm having problems importing OVA exports from vmware 4, into ovirt 4.3
> >
>
> So do you mean an OVA created in vSphere and to be used then in oVirt?
> What kind of problems? Too generic...
> ...
> ___
> 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/UK73PEGJ3TK2TANJ7NDIEL37BI4KF6RW/
___
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/33VSVTIWIK52NK4KNXJ2JT6JBMTAZ2RE/

[ovirt-users] Re: testing ovirt 4.4 as single node VM inside 4.3

[thomas]

Hi Nir,

performance is not really an issue here, we're most interested in functional 
testing and migration support.

That's where nesting 4.4 on top of 4.3 would be a crucial migration enabler, 
especially since you don't support a 7/8 or 4.3/4.4 mix that much elsewhere.

Currently my tests reveal, that ovirt/ovirt nesting does not work at all, oVirt 
on KVM is the only case useds/tested by Redhat internally.

The other issue is that OVA exports on oVirt fail silently, which is about the 
worst to happen. I get full sized OVA files full of zeros that obviously won't 
work imported (without errors, btw).

And for lack of 4.4. nested on 4.3 I couldn't even tell if the export domains 
already deprecated on 4.3 would work at all on 4.4, which would be the only 
other alternative to migrate VMs.

Please, please, please, if you can make OVA export/import, export domains and 
even nested oVirt working, I'd kiss your feet (wearing my Corona mask, of 
course ;-)
___
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/3BODKC2D7DGNMUQ5UXC3S6QYP6LD56U5/

[ovirt-users] Re: OVA export creates empty and unusable images

[thomas]

Wow, it seems a good find for a potential reason!

I'd totally subscribe to the cause, if it only affected my Atom HCI clusters, 
who have had timing issues so bad, even the initial 3 node HCI setup had to be 
run on a 5 GHz Kaby Lake to succeed, because my J5005 Atoms evidently were too 
slow.

But I see the very same effect also on another farm, not using quite the newest 
generation of hardware, but even a 28 core Broadwell Xeon, so if timing is the 
issue, somebody from QA needs a serious performance review.

Did you get a chance to test the OVA export/import cycle?
___
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/YG7226PSQYDKSCVHPON5IAC3PT4ZNVJX/

[ovirt-users] Re: OVA export creates empty and unusable images

[Gianluca Cecchi]

On Sat, Aug 1, 2020 at 12:36 AM  wrote:

> Wow, it seems a good find for a potential reason!
>

Yes, but did you check the files at the path I gave you?


>
> Did you get a chance to test the OVA export/import cycle?
>
>
Right now.
Environment with oVirt 4.3.10. I have a CentOS 8 VM with a 20Gb
preallocated disk (and inside the VM 4Gb actually used).
I shutdown the VM and then export as OVA.
The process completes, apparently successfully, and on the engine in
/var/log/ovirt-engine/ova 3 files are created (ov301 is the host chosen for
the export):

ovirt-export-ova-validate-ansible-20200801011543-ov301.mydomain-bc243185-2c3b-4f22-ac8c-8a59ecab5610.log
ovirt-image-measure-ansible-20200801011608-ov301.mydomain-476aff3d.log
ovirt-export-ova-ansible-20200801011610-ov301.mydomain-476aff3d.log

and as described inside the bug I referred I see in the third file:

"
converting disk:
/rhev/data-center/mnt/blockSD/fa33df49-b09d-4f86-9719-ede649542c21/images/ff10a405-
cc61-4d00-a83f-3ee04b19f381/146d7e09-a6df-41d1-9a88-fb5c0174b099, offset
13312
qemu-img: /dev/loop0: error while converting qcow2: Could not open device:
Permission denied

STDERR:

Shared connection to ov301 closed.
"
On ov301 apparently the file has been created:
[g.cecchi@ov301 ~]$ ll /tmp/c8client.ova
-rw---. 1 root root 21478389760 Aug  1 01:16 /tmp/c8client.ova
[g.cecchi@ov301 ~]$

But:

[g.cecchi@ov301 ~]$ du -sh /tmp/c8client.ova
20K /tmp/c8client.ova
[g.cecchi@ov301 ~]$

So I think this is a severe problem, much more because it doesn't give any
error and gives false sensation of a good backup (until you try to import
it anywhere... )
I already asked in the bugzilla to backport to 4.3.
Otherwise if there is no will/time/resources to solve it, at least to
disable the functionality.
Post your comments to it too.

Let's see and monitor the bug...

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

[ovirt-users] Re: where is error log for OVA import

[Philip Brown]

good news and bad news and more good news on my OVA import front. Devs are 
especially encouraged to read to the end :)


Initial good news is, I managed to successfully upgrade ONE of my "node"s in my 
4.3 cluster to 4.4.1


The bad news is:
doing the exact same thing as before; copying the .OVA file to /root on a node, 
and attempting an import, doesnt work.
and it fails even harder this time.
It doesnt just pretend to load it and die at 99%.
It fails to allow me to load it at all, with no visible errors?



on the native 4.3 node, I do (import OVA)
I put in the path as "/root"
I press the load button, and it shows me the OVA file in there.

BUT. on the 4.4.1 node running in the 4.3 cluster.
I put in the path as "/root"
I press the load button...
and it shows me NO FILES.


perms on /root on both nodes, is
dr-xr-x--- root root

so its not a perms issue.
and its literally the same file and name.
I just scp'd the file from the 4.4.1 node, to the 4.3 node.

I was going to ask for suggestions, but then, one whacky thing I came up with 
myself. get the dialog to recognize the file, for the 4.3 node.
So then it shows up in the first dialog.
But then CHANGE the selected node to the 4.4.1 node, before pressing okay??
It takes a bug to fight a bug??. lol.

but it started the import on the actual 4.4.1 node...and still failed.

But I figured out that the important file is NOT in the engine VM, but in the 
node that is selected as involved in the import.

So in /var/log/vdsm/import/X, I found a few errors.


juggled things around...
Forced "preallocate" instead of "thin provision".
and
it worked? !

yay.


So, suggestion to devs to test more on the local import, rather than just the 
"import domain" thing.

suggestion #2:
I think that in ovirt 4.3, default perms on /root were okay. but in 4.4 a 
non-root user is used, so it fails to READ THE DIRECTORY.
This error should really be passed up to the GUI.
___
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/NXTBINJ7KPUQHERO5WKXBLV5POVDBTNR/