[ovirt-users] Fwd: Disk from FC storage not removed

[Krzysztof Dajka]

Hi,

Recently I tried to delete 1TB disk created on top ~3TB LUN from
ovirtengine.
Disk is preallocated and I backuped data to other disk so I could recreate
it once again as thin volume. I couldn't remove this disk when it was
attached to a VM. But once I detached it I could remove it permanently. The
thing is it only disappeared from ovirtengine GUI.

I've got 4 hosts with FC HBA attached to storage array and all of them are
saying that this 1TB disk which should be gone is opened by all
hosts simultaneously.

[root@wrops1 BLUE ~]# lvdisplay -m
/dev/e69d1c16-36d1-4375-aaee-69f5a5ce1616/ee53af81-820d-4916-b766-5236ca99daf8
  --- Logical volume ---



  LV Path
 /dev/e69d1c16-36d1-4375-aaee-69f5a5ce1616/ee53af81-820d-4916-b766-5236ca99daf8


  LV Nameee53af81-820d-4916-b766-5236ca99daf8



  VG Namee69d1c16-36d1-4375-aaee-69f5a5ce1616



  LV UUIDsBdBRk-tNyZ-Rval-F4lw-ka6X-wOe8-AQenTb



  LV Write Accessread/write



  LV Creation host, time wrops1.blue, 2015-07-31 10:40:57 +0200



  LV Status  available



  # open 1



  LV Size1.00 TiB



  Current LE 8192



  Segments   1



  Allocation inherit



  Read ahead sectors auto



  - currently set to 8192



  Block device   253:29







  --- Segments ---
  Logical extents 0 to 8191:
Typelinear
Physical volume /dev/mapper/360e00d240572
Physical extents8145 to 16336

Deactivating LV doesn't work:
[root@wrops1 BLUE ~]# lvchange -an
/dev/e69d1c16-36d1-4375-aaee-69f5a5ce1616/ee53af81-820d-4916-b766-5236ca99daf8
  Logical volume
e69d1c16-36d1-4375-aaee-69f5a5ce1616/ee53af81-820d-4916-b766-5236ca99daf8
is used by another device.


Removing from hypervisor doesn't work either.
[root@wrops1 BLUE ~]# lvremove --force
/dev/e69d1c16-36d1-4375-aaee-69f5a5ce1616/ee53af81-820d-4916-b766-5236ca99daf8
  Logical volume
e69d1c16-36d1-4375-aaee-69f5a5ce1616/ee53af81-820d-4916-b766-5236ca99daf8
is used by another device.

I tried and rebooted one host and as soon as it booted the volume became
opened once again. Lsof on all hosts doesn't give anything meaningful
regarding this LV. As opposed to other LV which are used by qemu-kvm.

Has anyone encountered similar problem? How can I remove this LV?

Regards
Krzysztof Dajka
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Terribly slow web consile post migration of oVirt Engine from one host to another host

[Anantha Raghava]

Hello Nicholas,

We are using bare-metal server with CentOS 7 OS and oVirt version is 
3.6.6 GA.


--

Thanks & Regards,

Anantha Raghava


On Thursday 09 June 2016 06:41 PM, Nicolas Ecarnot wrote:

Le 09/06/2016 08:58, Anantha Raghava a écrit :

Hello Alexander,

You are right. The FQDN was the culprit. Once I entered the FQDN in
/etc/hosts file, the problem got resolved.


Hello,

I have not understood clearly whether your were using hosted engine or 
bare-metal?


I'm asking that because - as Alex knows it - I'm facing this terribly 
slowness since months, and we took a lot a time trying to figure it 
out, to no avail.

We're using 3.6.5 and bare-metal engine.
I triple checked DNS resolution, added (anyway) relevant fqdn in 
/etc/hosts, install (anyway) haveged and rebooted.

We checked all that with Alex, but seeing nothing obvious.

So far, the web gui usage is still a real daily pain.



___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Terribly slow web consile post migration of oVirt Engine from one host to another host

[Anantha Raghava]

Hi,

We need to understand Postgress backup & restore process to understand 
these properly. Not having such an expertise with Postgress.


Any way, interesting discussions..worth spending time to understand it 
properly. That answers many questions


--

Thanks & Regards,

Anantha Raghava


On Thursday 09 June 2016 06:41 PM, Yedidyah Bar David wrote:

On Thu, Jun 9, 2016 at 3:33 PM, Anantha Raghava
 wrote:

Hi,

Thanks for taking time and reverting back to me.

I have seen this explanation from engine-backup help and realise that it is
something to do with Postgres DB restore activity. But not much said about
it. I feel it instructs Postgress DB to restore the DB without privileges
with which the object was created, but use new permissions & privileges
passed along with --change-db-credentials and others passed during
engine-backup --mode=restore.

Exactly.

And if you do not pass --change-db-credentials, you'll simply get the
default, which is to just give permissions to the user creating the
schema.

Bottom line: If you used only defaults, and did not create users
and give them grants, there is no difference between the options.
They'll create the exact same database. If you did add grants, you
must choose.

I agree it's not very user-friendly to require choice, but please
take into consideration that if you had a large setup (say hundreds
of VMs or more) with dwh history included over some time, you'll have
a large database, and I think it will be much less friendly if we
"just try" restoring (which can take several hours then) and fail
in the end due to missing users.

Please also see the discussion on these bugs for more details:

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

Best,


However not sure.

--

Thanks & Regards,

Anantha Raghava
On Thursday 09 June 2016 05:47 PM, Alexander Wels wrote:

On Thursday, June 09, 2016 12:28:41 PM Anantha Raghava wrote:

Hello Alexander,

You are right. The FQDN was the culprit. Once I entered the FQDN in
/etc/hosts file, the problem got resolved.

Thanks for your guidance.

By the way any document that explains what is --restore-permissions in
engine-backup process?

If you type engine-backup --help you will get a list and explanation of all
the possible options.

Affects only the custom dump format. Will not pass to pg_restore '--no-owner
--
no-privileges'. Might not work as expected with the --*db-user options.

Is what the --help says, not sure what that means though.

Hi,

I will try both options tomorrow & revert back here.

Regards,
Anantha Raghava

On Jun 8, 2016 10:04 PM, "Alexander Wels" mailto:aw...@redhat.com>> wrote:
 On Wednesday, June 08, 2016 08:49:16 PM Anantha Raghava wrote:
 > Hi,
 >
 > I was able to migrate the oVirt Engine from one host to another

 using

 > engine-backup utility. On the new host, the data is loaded

 properly but

 > the Administration Portal is terribly slow.
 >
 > It take about 2 to 3 minutes to allow me to enter user name &

 password.

 > Once logged in, it takes hell a lot of time to show up the data.

 Click

 > on a tab, we need to wait for a good amount of time to see the

 actual

 > data. Even the refresh is taking time to execute although it is

 set to 5

 > Seconds.
 >
 > But if I enable old server and connect, every thing works quickly.
 >
 > Note:
 >
 > 1. We do not have DNS in our environment.
 > 2. Engine name & even the IP is retained the same.
 > 3. Before migration, we stopped ovirt-engine on old server, took the
 > backup, shutdown & disconnected the old server.
 > 4. We installed the ovirt-engine on new server, run engine

 setup, noted

 > down the DB password, did engine-cleanup, restored the data using
 > engine-backup utility and executed engine-setup again. It did

 recognize

 > restored data and only httpd configuration was sought and we

 selected

 > the defaults.

 It is highly likely 1 of 2 things:

 1. The entropy mentioned by Brett, however that is mostly
 applicable on hosted
 engine as VMs don't usually have good entropy.
 2. The engine cannot resolve itself (which looking at your
 description is the
 likely culprit). Since you don't have DNS, you need to add the fqdn to
 /etc/hosts so it can resolve itself.

 > Result is terribly slow Web Console.
 >
 > First, we attempted to setup ovirt-reports and later removed it

 thinking

 > that may be slowing down the engine server. Yet the same result.
 >
 > Commands used to backup from old server: "engine-backup

 --mode=backup

 > --file= --log= --provision-db"
 > Command used to restore on new server: "engine-backup --mode=restore
 > --file= --log=

 --change-db-credentials

 > --db-host=localhost --db-user=engine --db-name=engine
 > --db-password=

[ovirt-users] Issues importing VMs in oVirt

[Cam Mac]

Hi,

I am trying to import and convert some VMWare guests from a VMWare cluster
with vCenter version 6, to a KVM (oVirt) host. The KVM node (RHEL 7.2) has
virt-v2v 1.28.1, though I've also tried using Fedora 23 which has 1.32.4.

The details are:

vCenter server: nssesxi-mgmt
Datacenter name: North Sutton Street
esxi server which runs the VM: nssesxi-mgmt04
folder name: Systems
VM name: wvm2
cluster name: nssesxi

I tried via the 'Import' option in the oVirt GUI, and put the details above
in, and after thinking about it for a while, it returns a 500 internal
server error. As I'm authing against AD, I put my username as cam@ARDA. I
have attached the log (gzipped).


I've also tried via the command line, and the result is much the same. I
did post the below to the libvirt-users mailing list but have not had a
response, so I thought I'd see if anyone here might know what is going on.

Unfortunately, spaces were put in the name of the datacenter, so I escape
them with %20

So the final URI is constructed as:

vpx:/


The error I get is:

# virt-v2v -v -x -ic
vpx://ARDA%5ccam@nssesxi-mgmt/Systems/North%20Sutton%20Street/nssesxi04-mgmt?no_verify=1
wvm2
virt-v2v: libguestfs 1.28.1 (x86_64)
[   0.0] Opening the source -i libvirt -ic
vpx://ARDA%5ccam@nssesxi-mgmt/Systems/North%20Sutton%20Street/nssesxi04-mgmt?no_verify=1
wvm2
input_libvirt_vcenter_https: source: scheme vpx server nssesxi-mgmt
Enter ARDA\cam's password for nssesxi-mgmt:
libvirt: ESX Driver error : internal error: Could not find compute resource
specified in '/Systems/North Sutton Street/nssesxi04-mgmt'
virt-v2v: error: internal error: invalid argument: cannot open libvirt
connection
'vpx://ARDA%5ccam@nssesxi-mgmt
/Systems/North%20Sutton%20Street/nssesxi04-mgmt?no_verify=1'

If reporting bugs, run virt-v2v with debugging enabled and include the
complete output:

  virt-v2v -v -x [...]
#


# virsh -c 
'vpx://ARDA%5ccam@nssesxi-mgmt/Systems/North%20Sutton%20Street/nssesxi04-mgmt?no_verify=1'
list --all
Enter ARDA\cam's password for nssesxi-mgmt:
error: failed to connect to the hypervisor
error: internal error: Could not find compute resource specified in
'/Systems/North Sutton Street/nssesxi04-mgmt'
#

I can access via http a list of VMs at the following URL:

https://nssesxi-mgmt/folder?dcPath=North%2520Sutton%2520Street&dsName=nssesxi%252dc2%252dr10%252dlun2

Below is the URI to the vm itself (once shutdown, it gets the name 'vm2_1'):

https://nssesxi-mgmt/folder/wvm2_1?dcPath=North%2520Sutton%2520Street&dsName=nssesxi%252dc1%252dr10%252dlun2

Any ideas?

Cheers,

-Cam


ovirt-vmware-error.txt.gz
Description: GNU Zip compressed data
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Problem accessing to hosted-engine after wrong network config

[Alexis HAUSER]

Actually I found my answer : it was just a problem on the NFS share, no 
relationship with ovirt itself, sorry about that.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Problem accessing to hosted-engine after wrong network config

[Alexis HAUSER]

I actually found out the problem was somewhere else. By deleting the file, 
which seems to be the lockfile in the data domain called "__DIRECT_IO_TEST__". 
The VM can now start again without crashing.

Anyway, datacenter is in "non responsive" mode and data domain are now 
"inavtive" and "unknown"

Any ideas ?






- Mail original -
De: "Alexis HAUSER" 
À: "Martin Polednik" 
Cc: "users" 
Envoyé: Mercredi 8 Juin 2016 23:20:51
Objet: Re: [ovirt-users] Problem accessing to hosted-engine after wrong network 
config

>Wouldn't there be another way to access console from the hypervisor to the 
>hosted-engine (without X) ?
>Not really if you don't have network afaik. Have you done the virsh
>command with root permissions? 
>sudo virsh list
>sudo virsh console vm
>If list even under root permissions doesn't show anything, make sure
>that the qemu process is running.

I can't see it with "virsh list" but I can see it with vdsClient -s 0 list

However the status id "Down" with "exitMessage = Failed to acquire lock: No 
space left on device"

I can't actually run the VM anymore since I changed the VLAN of ovirtmgmt...
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Terribly slow web consile post migration of oVirt Engine from one host to another host

[Alexander Wels]

On Thursday, June 09, 2016 03:47:17 PM Nicolas Ecarnot wrote:
> Le 09/06/2016 15:31, Alexander Wels a écrit :
> > On Thursday, June 09, 2016 03:11:07 PM Nicolas Ecarnot wrote:
> >> Le 09/06/2016 08:58, Anantha Raghava a écrit :
> >>> Hello Alexander,
> >>> 
> >>> You are right. The FQDN was the culprit. Once I entered the FQDN in
> >>> /etc/hosts file, the problem got resolved.
> >> 
> >> Hello,
> >> 
> >> I have not understood clearly whether your were using hosted engine or
> >> bare-metal?
> >> 
> >> I'm asking that because - as Alex knows it - I'm facing this terribly
> >> slowness since months, and we took a lot a time trying to figure it out,
> >> to no avail.
> >> We're using 3.6.5 and bare-metal engine.
> >> I triple checked DNS resolution, added (anyway) relevant fqdn in
> >> /etc/hosts, install (anyway) haveged and rebooted.
> >> We checked all that with Alex, but seeing nothing obvious.
> >> 
> >> So far, the web gui usage is still a real daily pain.
> > 
> > And we verified the ping between your browser machine and the engine was
> > low. The load on the engine was near 0. That your browser was either
> > Chrome/FF and that the machine running the browser is plenty powerful.
> > 
> > Did you ever disable the repos besides the 3.6 one and run a yum update
> > (on
> > the engine)?
> 
> Yes, I did.
> Two DC are still running on 3.6.3, and four others are running on 3.6.5.
> Amongst the 3.6.5, some were updated from below, and some were installed
> from scratch (so no negative legacy nor prehistoric RPMs or repos).
> 
> > Greg one of the other maintainers recently did some performance
> > improvements, I just don't remember which version they go into. either
> > 3.6.5 or 3.6.6.
> 
> May you Cc: to Greg?
> 

I asked him, he said 3.6.5 and 4.0. So if your 3.6.5 is the same then it 
didn't solve your issue obviously. I am completely out of things to try or see 
that could possibly be the problem.

> > If I remember correctly for some reason it takes a long time to get
> > data from the engine to your browser, we just don't know why it takes so
> > long as we profiled the engine running in your environment and that was
> > all fine as well.
> 
> I recall correctly.
> 
> I'm also witnessing memory leaks, that I think were fixed recently.

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Terribly slow web consile post migration of oVirt Engine from one host to another host

[Nicolas Ecarnot]

Le 09/06/2016 15:31, Alexander Wels a écrit :

On Thursday, June 09, 2016 03:11:07 PM Nicolas Ecarnot wrote:

Le 09/06/2016 08:58, Anantha Raghava a écrit :

Hello Alexander,

You are right. The FQDN was the culprit. Once I entered the FQDN in
/etc/hosts file, the problem got resolved.


Hello,

I have not understood clearly whether your were using hosted engine or
bare-metal?

I'm asking that because - as Alex knows it - I'm facing this terribly
slowness since months, and we took a lot a time trying to figure it out,
to no avail.
We're using 3.6.5 and bare-metal engine.
I triple checked DNS resolution, added (anyway) relevant fqdn in
/etc/hosts, install (anyway) haveged and rebooted.
We checked all that with Alex, but seeing nothing obvious.

So far, the web gui usage is still a real daily pain.


And we verified the ping between your browser machine and the engine was low.
The load on the engine was near 0. That your browser was either Chrome/FF and
that the machine running the browser is plenty powerful.

Did you ever disable the repos besides the 3.6 one and run a yum update (on
the engine)?


Yes, I did.
Two DC are still running on 3.6.3, and four others are running on 3.6.5.
Amongst the 3.6.5, some were updated from below, and some were installed 
from scratch (so no negative legacy nor prehistoric RPMs or repos).



Greg one of the other maintainers recently did some performance
improvements, I just don't remember which version they go into. either 3.6.5
or 3.6.6.


May you Cc: to Greg?


If I remember correctly for some reason it takes a long time to get
data from the engine to your browser, we just don't know why it takes so long
as we profiled the engine running in your environment and that was all fine as
well.


I recall correctly.

I'm also witnessing memory leaks, that I think were fixed recently.

--
Nicolas ECARNOT
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Terribly slow web consile post migration of oVirt Engine from one host to another host

[Alexander Wels]

On Thursday, June 09, 2016 03:11:07 PM Nicolas Ecarnot wrote:
> Le 09/06/2016 08:58, Anantha Raghava a écrit :
> > Hello Alexander,
> > 
> > You are right. The FQDN was the culprit. Once I entered the FQDN in
> > /etc/hosts file, the problem got resolved.
> 
> Hello,
> 
> I have not understood clearly whether your were using hosted engine or
> bare-metal?
> 
> I'm asking that because - as Alex knows it - I'm facing this terribly
> slowness since months, and we took a lot a time trying to figure it out,
> to no avail.
> We're using 3.6.5 and bare-metal engine.
> I triple checked DNS resolution, added (anyway) relevant fqdn in
> /etc/hosts, install (anyway) haveged and rebooted.
> We checked all that with Alex, but seeing nothing obvious.
> 
> So far, the web gui usage is still a real daily pain.

And we verified the ping between your browser machine and the engine was low. 
The load on the engine was near 0. That your browser was either Chrome/FF and 
that the machine running the browser is plenty powerful. 

Did you ever disable the repos besides the 3.6 one and run a yum update (on 
the engine)? Greg one of the other maintainers recently did some performance 
improvements, I just don't remember which version they go into. either 3.6.5 
or 3.6.6. If I remember correctly for some reason it takes a long time to get 
data from the engine to your browser, we just don't know why it takes so long 
as we profiled the engine running in your environment and that was all fine as 
well. 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Terribly slow web consile post migration of oVirt Engine from one host to another host

[Yedidyah Bar David]

On Thu, Jun 9, 2016 at 3:33 PM, Anantha Raghava
 wrote:
> Hi,
>
> Thanks for taking time and reverting back to me.
>
> I have seen this explanation from engine-backup help and realise that it is
> something to do with Postgres DB restore activity. But not much said about
> it. I feel it instructs Postgress DB to restore the DB without privileges
> with which the object was created, but use new permissions & privileges
> passed along with --change-db-credentials and others passed during
> engine-backup --mode=restore.

Exactly.

And if you do not pass --change-db-credentials, you'll simply get the
default, which is to just give permissions to the user creating the
schema.

Bottom line: If you used only defaults, and did not create users
and give them grants, there is no difference between the options.
They'll create the exact same database. If you did add grants, you
must choose.

I agree it's not very user-friendly to require choice, but please
take into consideration that if you had a large setup (say hundreds
of VMs or more) with dwh history included over some time, you'll have
a large database, and I think it will be much less friendly if we
"just try" restoring (which can take several hours then) and fail
in the end due to missing users.

Please also see the discussion on these bugs for more details:

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

Best,

>
> However not sure.
>
> --
>
> Thanks & Regards,
>
> Anantha Raghava
> On Thursday 09 June 2016 05:47 PM, Alexander Wels wrote:
>
> On Thursday, June 09, 2016 12:28:41 PM Anantha Raghava wrote:
>
> Hello Alexander,
>
> You are right. The FQDN was the culprit. Once I entered the FQDN in
> /etc/hosts file, the problem got resolved.
>
> Thanks for your guidance.
>
> By the way any document that explains what is --restore-permissions in
> engine-backup process?
>
> If you type engine-backup --help you will get a list and explanation of all
> the possible options.
>
> Affects only the custom dump format. Will not pass to pg_restore '--no-owner
> --
> no-privileges'. Might not work as expected with the --*db-user options.
>
> Is what the --help says, not sure what that means though.
>
> Hi,
>
> I will try both options tomorrow & revert back here.
>
> Regards,
> Anantha Raghava
>
> On Jun 8, 2016 10:04 PM, "Alexander Wels" 
> > wrote:
> On Wednesday, June 08, 2016 08:49:16 PM Anantha Raghava wrote:
> > Hi,
> >
> > I was able to migrate the oVirt Engine from one host to another
>
> using
>
> > engine-backup utility. On the new host, the data is loaded
>
> properly but
>
> > the Administration Portal is terribly slow.
> >
> > It take about 2 to 3 minutes to allow me to enter user name &
>
> password.
>
> > Once logged in, it takes hell a lot of time to show up the data.
>
> Click
>
> > on a tab, we need to wait for a good amount of time to see the
>
> actual
>
> > data. Even the refresh is taking time to execute although it is
>
> set to 5
>
> > Seconds.
> >
> > But if I enable old server and connect, every thing works quickly.
> >
> > Note:
> >
> > 1. We do not have DNS in our environment.
> > 2. Engine name & even the IP is retained the same.
> > 3. Before migration, we stopped ovirt-engine on old server, took the
> > backup, shutdown & disconnected the old server.
> > 4. We installed the ovirt-engine on new server, run engine
>
> setup, noted
>
> > down the DB password, did engine-cleanup, restored the data using
> > engine-backup utility and executed engine-setup again. It did
>
> recognize
>
> > restored data and only httpd configuration was sought and we
>
> selected
>
> > the defaults.
>
> It is highly likely 1 of 2 things:
>
> 1. The entropy mentioned by Brett, however that is mostly
> applicable on hosted
> engine as VMs don't usually have good entropy.
> 2. The engine cannot resolve itself (which looking at your
> description is the
> likely culprit). Since you don't have DNS, you need to add the fqdn to
> /etc/hosts so it can resolve itself.
>
> > Result is terribly slow Web Console.
> >
> > First, we attempted to setup ovirt-reports and later removed it
>
> thinking
>
> > that may be slowing down the engine server. Yet the same result.
> >
> > Commands used to backup from old server: "engine-backup
>
> --mode=backup
>
> > --file= --log= --provision-db"
> > Command used to restore on new server: "engine-backup --mode=restore
> > --file= --log=
>
> --change-db-credentials
>
> > --db-host=localhost --db-user=engine --db-name=engine
> > --db-password=
>
> --no-restore-permissions"
>
> > The command executed without any errors, resulting in a terribly
>
> slow
>
> > web console.
> >
> > Note: Without --restore-permissions, 

Re: [ovirt-users] Terribly slow web consile post migration of oVirt Engine from one host to another host

[Nicolas Ecarnot]

Le 09/06/2016 08:58, Anantha Raghava a écrit :

Hello Alexander,

You are right. The FQDN was the culprit. Once I entered the FQDN in
/etc/hosts file, the problem got resolved.


Hello,

I have not understood clearly whether your were using hosted engine or 
bare-metal?


I'm asking that because - as Alex knows it - I'm facing this terribly 
slowness since months, and we took a lot a time trying to figure it out, 
to no avail.

We're using 3.6.5 and bare-metal engine.
I triple checked DNS resolution, added (anyway) relevant fqdn in 
/etc/hosts, install (anyway) haveged and rebooted.

We checked all that with Alex, but seeing nothing obvious.

So far, the web gui usage is still a real daily pain.

--
Nicolas ECARNOT
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Upload img file to Storage Domain

[Fernando Frediani]

Thanks for that.
That worked.

I installed a temporary Linux distribution, downloded the .img file to 
its filesystem, made a dd to /dev/vdb and remove the temporary Linux 
distribution disk, then let the disk boot from the remaining disk. Far 
from ideal but at least worked.


Fernando

Em 08/06/2016 10:12, Barak Korren escreveu:

On 8 June 2016 at 15:58, Fernando Frediani  wrote:

Hi there,

I'm spending a fair amount of time to find out how (if possible) to upload a
.img image to a oVirt Storage Domain and be able to mount it in a VM as a
disk.

It is a OpenWRT image and there is no OVF from it, so it's a raw image which
I wanted to use as a disc. Tried both with engine-iso-uploader and
engine-image-uploader but they refure for diferent reasons.

Is that possible at all ?


Uploading of QCOW images from GUI will hopefully land in 4.0.

In the meantime you can work around it like this:
1. Create a VM and install centos/some other Linux on it
2. Create a new VM disk and attach to VM, not the disk device
3. Copy the image from the file to the disk device with virt-resize.
4. Detach the disk from the VM and build a new VM around it

Optionally:
1. Convert the VM from step #4 to a template
2. Re use the VM from step #1 to upload more images.

HTH,



___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Terribly slow web consile post migration of oVirt Engine from one host to another host

[Anantha Raghava]

Hi,

Thanks for taking time and reverting back to me.

I have seen this explanation from engine-backup help and realise that it 
is something to do with Postgres DB restore activity. But not much said 
about it. I feel it instructs Postgress DB to restore the DB without 
privileges with which the object was created, but use new permissions & 
privileges passed along with --change-db-credentials and others passed 
during engine-backup --mode=restore.


However not sure.

--

Thanks & Regards,

Anantha Raghava


On Thursday 09 June 2016 05:47 PM, Alexander Wels wrote:

On Thursday, June 09, 2016 12:28:41 PM Anantha Raghava wrote:

Hello Alexander,

You are right. The FQDN was the culprit. Once I entered the FQDN in
/etc/hosts file, the problem got resolved.

Thanks for your guidance.

By the way any document that explains what is --restore-permissions in
engine-backup process?


If you type engine-backup --help you will get a list and explanation of all
the possible options.

Affects only the custom dump format. Will not pass to pg_restore '--no-owner --
no-privileges'. Might not work as expected with the --*db-user options.

Is what the --help says, not sure what that means though.


Hi,

I will try both options tomorrow & revert back here.

Regards,
Anantha Raghava

On Jun 8, 2016 10:04 PM, "Alexander Wels" mailto:aw...@redhat.com>> wrote:
 On Wednesday, June 08, 2016 08:49:16 PM Anantha Raghava wrote:
 > Hi,
 >
 > I was able to migrate the oVirt Engine from one host to another
 
 using
 
 > engine-backup utility. On the new host, the data is loaded
 
 properly but
 
 > the Administration Portal is terribly slow.

 >
 > It take about 2 to 3 minutes to allow me to enter user name &
 
 password.
 
 > Once logged in, it takes hell a lot of time to show up the data.
 
 Click
 
 > on a tab, we need to wait for a good amount of time to see the
 
 actual
 
 > data. Even the refresh is taking time to execute although it is
 
 set to 5
 
 > Seconds.

 >
 > But if I enable old server and connect, every thing works quickly.
 >
 > Note:
 >
 > 1. We do not have DNS in our environment.
 > 2. Engine name & even the IP is retained the same.
 > 3. Before migration, we stopped ovirt-engine on old server, took the
 > backup, shutdown & disconnected the old server.
 > 4. We installed the ovirt-engine on new server, run engine
 
 setup, noted
 
 > down the DB password, did engine-cleanup, restored the data using

 > engine-backup utility and executed engine-setup again. It did
 
 recognize
 
 > restored data and only httpd configuration was sought and we
 
 selected
 
 > the defaults.
 
 It is highly likely 1 of 2 things:
 
 1. The entropy mentioned by Brett, however that is mostly

 applicable on hosted
 engine as VMs don't usually have good entropy.
 2. The engine cannot resolve itself (which looking at your
 description is the
 likely culprit). Since you don't have DNS, you need to add the fqdn to
 /etc/hosts so it can resolve itself.
 
 > Result is terribly slow Web Console.

 >
 > First, we attempted to setup ovirt-reports and later removed it
 
 thinking
 
 > that may be slowing down the engine server. Yet the same result.

 >
 > Commands used to backup from old server: "engine-backup
 
 --mode=backup
 
 > --file= --log= --provision-db"

 > Command used to restore on new server: "engine-backup --mode=restore
 > --file= --log=
 
 --change-db-credentials
 
 > --db-host=localhost --db-user=engine --db-name=engine

 > --db-password=
 
 --no-restore-permissions"
 
 > The command executed without any errors, resulting in a terribly
 
 slow
 
 > web console.

 >
 > Note: Without --restore-permissions, the restore fails. Did not
 > understand what to give as restore permissions. Hence used
 > --no-restore-permissions.
 >
 > *Hardware configuration:*
 > *
 > **Old Server:* i3 Processor, 4 GB Memory, 1 Gbps NIC
 > *New Server :* Lenovo x3250 M5 Server with Intel Xeon Processor,
 
 16 GB
 
 > RAM, 2 X 1 Gbps NIC.

 >
 > Just unable to understand why it is terribly slow.


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Terribly slow web consile post migration of oVirt Engine from one host to another host

[Alexander Wels]

On Thursday, June 09, 2016 12:28:41 PM Anantha Raghava wrote:
> Hello Alexander,
> 
> You are right. The FQDN was the culprit. Once I entered the FQDN in
> /etc/hosts file, the problem got resolved.
> 
> Thanks for your guidance.
> 
> By the way any document that explains what is --restore-permissions in
> engine-backup process?
> 

If you type engine-backup --help you will get a list and explanation of all 
the possible options. 

Affects only the custom dump format. Will not pass to pg_restore '--no-owner --
no-privileges'. Might not work as expected with the --*db-user options.

Is what the --help says, not sure what that means though.

> > Hi,
> > 
> > I will try both options tomorrow & revert back here.
> > 
> > Regards,
> > Anantha Raghava
> > 
> > On Jun 8, 2016 10:04 PM, "Alexander Wels"  > 
> > > wrote:
> > On Wednesday, June 08, 2016 08:49:16 PM Anantha Raghava wrote:
> > > Hi,
> > > 
> > > I was able to migrate the oVirt Engine from one host to another
> > 
> > using
> > 
> > > engine-backup utility. On the new host, the data is loaded
> > 
> > properly but
> > 
> > > the Administration Portal is terribly slow.
> > > 
> > > It take about 2 to 3 minutes to allow me to enter user name &
> > 
> > password.
> > 
> > > Once logged in, it takes hell a lot of time to show up the data.
> > 
> > Click
> > 
> > > on a tab, we need to wait for a good amount of time to see the
> > 
> > actual
> > 
> > > data. Even the refresh is taking time to execute although it is
> > 
> > set to 5
> > 
> > > Seconds.
> > > 
> > > But if I enable old server and connect, every thing works quickly.
> > > 
> > > Note:
> > > 
> > > 1. We do not have DNS in our environment.
> > > 2. Engine name & even the IP is retained the same.
> > > 3. Before migration, we stopped ovirt-engine on old server, took the
> > > backup, shutdown & disconnected the old server.
> > > 4. We installed the ovirt-engine on new server, run engine
> > 
> > setup, noted
> > 
> > > down the DB password, did engine-cleanup, restored the data using
> > > engine-backup utility and executed engine-setup again. It did
> > 
> > recognize
> > 
> > > restored data and only httpd configuration was sought and we
> > 
> > selected
> > 
> > > the defaults.
> > 
> > It is highly likely 1 of 2 things:
> > 
> > 1. The entropy mentioned by Brett, however that is mostly
> > applicable on hosted
> > engine as VMs don't usually have good entropy.
> > 2. The engine cannot resolve itself (which looking at your
> > description is the
> > likely culprit). Since you don't have DNS, you need to add the fqdn to
> > /etc/hosts so it can resolve itself.
> > 
> > > Result is terribly slow Web Console.
> > > 
> > > First, we attempted to setup ovirt-reports and later removed it
> > 
> > thinking
> > 
> > > that may be slowing down the engine server. Yet the same result.
> > > 
> > > Commands used to backup from old server: "engine-backup
> > 
> > --mode=backup
> > 
> > > --file= --log= --provision-db"
> > > Command used to restore on new server: "engine-backup --mode=restore
> > > --file= --log=
> > 
> > --change-db-credentials
> > 
> > > --db-host=localhost --db-user=engine --db-name=engine
> > > --db-password=
> > 
> > --no-restore-permissions"
> > 
> > > The command executed without any errors, resulting in a terribly
> > 
> > slow
> > 
> > > web console.
> > > 
> > > Note: Without --restore-permissions, the restore fails. Did not
> > > understand what to give as restore permissions. Hence used
> > > --no-restore-permissions.
> > > 
> > > *Hardware configuration:*
> > > *
> > > **Old Server:* i3 Processor, 4 GB Memory, 1 Gbps NIC
> > > *New Server :* Lenovo x3250 M5 Server with Intel Xeon Processor,
> > 
> > 16 GB
> > 
> > > RAM, 2 X 1 Gbps NIC.
> > > 
> > > Just unable to understand why it is terribly slow.

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] oVirt 3.6.7 Third Release Candidate is now available for testing

[Rafael Martins]

The oVirt Project is pleased to announce the availability of the Third Release 
Candidate of oVirt 3.6.7 for testing, as of June 9th, 2016

This release is available now for:
* Fedora 22
* Red Hat Enterprise Linux 6.7 or later
* CentOS Linux (or similar) 6.7 or later

* Red Hat Enterprise Linux 7.2 or later
* CentOS Linux (or similar) 7.2 or later

This release supports Hypervisor Hosts running:
* Red Hat Enterprise Linux 7.2 or later
* CentOS Linux (or similar) 7.2 or later
* Fedora 22

This release candidate includes the following updated packages:

* ovirt-engine
* ovirt-hosted-engine-setup
* vdsm
* otopi
* mom

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

Notes:
* A new oVirt Live ISO is available [2].
* Mirrors[3] might need up to one day to synchronize.

Additional Resources:
* Read more about the oVirt 3.6.7 release highlights: 
http://www.ovirt.org/release/3.6.7/
* Get more oVirt Project updates on Twitter: https://twitter.com/ovirt
* Check out the latest project news on the oVirt blog: 
http://www.ovirt.org/blog/

[1] http://www.ovirt.org/release/3.6.7/
[2] http://resources.ovirt.org/pub/ovirt-3.6-pre/iso/ovirt-live/
[3] http://www.ovirt.org/Repository_mirrors#Current_mirrors
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] oVirt Windows Guest Tools & Live Migration issues.

[Anantha Raghava]

Hello Michal,

The live migration fails as mentioned in below mail thread. Events does 
not provide much details, but shows fails. Screen shot is attached. Host 
upgrade also fails as it cannot move running VM to another host, put 
host in maintenance mode.


Capture


--

Thanks & Regards,

Anantha Raghava


On Wednesday 08 June 2016 07:58 PM, Anantha Raghava wrote:

Hello Michal,

The Live Migration fails. Events does not show any information but 
just mentioning migration failed. This happens even when we put the 
host into maintenance. VMs do not migrate and host fails to move into 
maintenance mode.


Attempted to upgrade the Hosts, but failed, no reasons attached.

I am a bit lost at this stage. Should we check for some more 
information in some logs? If yes, where do we find the logs?


--

Thanks & Regards,

Anantha Raghava


On Tuesday 07 June 2016 11:13 PM, Anantha Raghava wrote:

Hello Michal,

Guest tools are working and getting all details about guest vm as needed.

But one thing I didn't understand. What is the relationship between 
virtioserial driver and oVirt Guest Service? Without virtio serial 
driver, guest services does not start.


Also, how do we install memory baloon driver?

Tomorrow morning, I will post about Live Migration events after I 
attempt it.


--

Thanks & Regards,


Anantha Raghava


On Friday 03 June 2016 04:36 PM, Michal Skrivanek wrote:


On 03 Jun 2016, at 12:57, Anantha Raghava 
 wrote:


Hello Michal,

Thanks for quick feed back.

Windows Guests Agents - Where do I download them from? Not getting 
the proper links. Or is to a part of virt-drivers that we use 
during installation.


Hi Anantha,
it’s part of ovirt-guest-tools. See 
http://lists.ovirt.org/pipermail/users/2016-May/039779.html




Live migration failure - These are pretty busy VMs if not big. The 
event does not show any specific message but just as migration 
failed. Is the reason logged somewhere? Please share the log 
location so that I can check & share the log for meaningful message 
and proper screen shots.


There should be more details in the events at the bottom of the 
webadmin page (just make it a bit bigger it may not be te last message)
If they are busy VMs then you may have issues migrating them. There 
is some simple tuning available and it may help. You can increase 
the maximum downtime in VM properties dialog (500ms by default, you 
can go up to whatever is feasible for your VM, seconds, tens of seconds)
Bandwidth is limited to work on 1Gb network, if you have 10Gb 
availabl you can also tune /etc/vdsm.conf on each host and increase 
the maximum bandwidth 10 times


Thanks,
michal



--

Thanks & Regards,


Anantha Raghava


On 03 Jun 2016, at 07:14, Anantha Raghava 
 wrote:


Hi,

We have just installed oVirt 3.6 on 3 hosts with storage volumes 
on Fibre Channel storage box. Every thing is working fine except 
the following.


1. We have created 15 Virtual Machines all VM with Windows Server 
2012 R2 OS. VM properties does not report the Operating System 
nor it shows the IP and FQDN in the Admin Portal. There is always 
an exclamation mark that reports about OS being different from 
the template and timezone issues. We have changed the timezone to 
Indian Standard Time in both VM and Host, same result continues. 
We have installed Windows Gues Tools, same result continues. 
Screen shot is below.


you doesn’t seem to run the guest agent. Make sure the service is 
started and works, then you’ll see IPs and more detailed info 
about each guest, and exclamation marks should go away






2. When we manually tried to migrate the VMs from one host to 
another one, the migration gets initiated, but will eventually fail.


Any specific setting missing here or is it a bug.


are they big or busy VMs? What does it fail on? There should be a 
menaingful message even if it’s just a timeout




Note:

All hosts are installed with CentOS 7.2 minimal installation 
oVirt node is installed and activated.

We do not have a DNS in our environment. We have to do with IPs.


as long as engine works with FQDN it’s ok


We are yet to apply the 3.6.6 patch on Engine and Nodes.


that may help with some of the issues above, so please try to do that

Thanks,
michal


We are running a stand alone engine, not a Hosted Engine.
--

Thanks & Regards,


Anantha Raghava

eXza Technology Consulting & Services


___
Users mailing list
Users@ovirt.org 
http://lists.ovirt.org/mailman/listinfo/users












___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users