Re: [ovirt-users] HE (3.6) on gluster storage, chicken and egg status

[Sahina Bose]

On 12/28/2015 12:43 AM, Roy Golan wrote:



On Sun, Dec 27, 2015 at 7:07 PM, Fil Di Noto > wrote:


I've managed to get hosted-engine running but could use some direction
for what comes next.

Summary:
4 Hosts, CentOS 7.2, oVirt 3.6 (from ovirt.org 
repo)
All hosts are in default/default datacenter/cluster
All 4 hosts are running glusterd
HE is installed on glusterfs volume, replica 3, on hosts 1,2, and 3. (
started with replica 4, but removed 4th brick to satisfy HE --deploy)

Status:
All hosts are active
Datacenter is not initialized

Issues:
Attach hosted_storage to Default datacenter fails
New volume dialog doesn't allow me to select a datacenter (list is
empty)

Questions:
1. Why doesn't replica 4 work as a glusterfs volume, is this just
because of the installer or is there a more fundamental reason?



3 way replica is the officially supported replica count for VM store use 
case. If you wish to work with replica 4, you can update the 
supported_replica_count in vdsm.conf



2. I assume the reason I can't create new volumes is because I don't
have a data storage domain configured yet. I want all of my data
storage to be glusterfs. How do I escape this chicken/egg puzzle?


 No chicken and egg here I think. You want a volume to be used as your 
master data domain and creating a new volume in a new gluster-cluster 
is independent of your datacenter status.


You mentioned your hosts are on default cluster - so make sure your 
cluster support gluster service (you should have picked gluster as a 
service during engine install)



If you mean, creating new gluster volumes - you need to make sure the 
gluster service is enabled on the Default cluster. The cluster that HE 
creates, has only virt service enabled by default. Engine should have 
been installed in "Both" mode like Roy mentioned.








3. What question should I be asking that I am not?

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


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

Re: [ovirt-users] Can I reduce the Java heap size of engine-backup???

[Yedidyah Bar David]

On Wed, Dec 30, 2015 at 7:50 PM, John Florian  wrote:
> On 12/29/2015 02:02 AM, Yedidyah Bar David wrote:
>> On Tue, Dec 29, 2015 at 12:51 AM, John Florian  
>> wrote:
>>> I'm trying to run the engine-backup script via a Bacula job using the
>>> RunScript option so that the engine-backup dumps its output someplace
>>> where Bacula will collect it once engine-backup finishes.  However the
>>> job is failing and with enough digging I eventually learned the script
>>> was writing the following in /tmp/hs_err_pid5789.log:
>>>
>>> #
>>> # There is insufficient memory for the Java Runtime Environment to continue.
>>> # Native memory allocation (mmap) failed to map 2555904 bytes for
>>> committing reserved memory.
>>> # Possible reasons:
>>> #   The system is out of physical RAM or swap space
>>> #   In 32 bit mode, the process size limit was hit
>>> # Possible solutions:
>>> #   Reduce memory load on the system
>>> #   Increase physical memory or swap space
>>> #   Check if swap backing store is full
>>> #   Use 64 bit Java on a 64 bit OS
>>> #   Decrease Java heap size (-Xmx/-Xms)
>>> #   Decrease number of Java threads
>>> #   Decrease Java thread stack sizes (-Xss)
>>> #   Set larger code cache with -XX:ReservedCodeCacheSize=
>>> # This output file may be truncated or incomplete.
>>> #
>>> #  Out of Memory Error (os_linux.cpp:2627), pid=5789, tid=140709998221056
>>> #
>>> # JRE version:  (8.0_65-b17) (build )
>>> # Java VM: OpenJDK 64-Bit Server VM (25.65-b01 mixed mode linux-amd64
>>> compressed oops)
>>> # Failed to write core dump. Core dumps have been disabled. To enable
>>> core dumping, try "ulimit -c unlimited" before starting Java again
>>> #
>>>
>>>
>>> So is there any good way to reduce the Java heap size?  I mean I know
>>> what -Xmx does, but where might I try setting it, ideally so that it
>>> affects the engine-backup only?  Any idea of good setting for a very
>>> small environment with a dozen VMs?
>> engine-backup does not directly call nor need java.
>>
>> AFAICS it only calls it indirectly as part of some other initialization
>> by running java-home [1], which is a script that decides what JAVA_HOME
>> to use for the engine. This script only runs 'java -version', which imo
>> should not need that much memory. Perhaps there is something else I do
>> not fully understand, such as bacula severely limiting available resources
>> for the process it runs, or something like that.
>>
>> If you only want to debug it, and not as a recommended final solution,
>> you can create a script [2] which only outputs the needed java home.
>> Simply run [1] and make [2] echo the same thing. If [2] exists, [1] will
>> only run it and nothing else, as you can see inside it.
>>
>> I do not think this will work - quite likely engine-backup will fail
>> shortly later, if indeed it gets access to so little memory. Please
>> report back. Thanks and good luck,
>>
>> [1] /usr/share/ovirt-engine/bin/java-home
>> [2] /usr/share/ovirt-engine/bin/java-home.local
> Thanks for the info and response Didi.  Doing the above did allow the
> backup to run successfully.

OK.

>  I had also replaced the Bacula RunScript
> with "bash -c ulimit" which reported unlimited but I don't play with
> those types of limits enough to know if that's correctly reporting to
> what engine-backup is constrained.

And was this enough?

>  I did occur to me that perhaps a
> better way to learn of any such constraints would be to query Bacula's
> file daemon (the only necessary Bacula component running on client
> systems that are getting backed up) since I suspect it must be this
> component that's actually spawning the RunScript client side.  From the
> Bacula Director (server side) I queried the status of the client which
> is my oVirt engine and it reports:
>
> europa.doubledog.org-fd Version: 5.2.13 (19 February 2013)
> x86_64-redhat-linux-gnu redhat (Core)
> Daemon started 28-Dec-15 16:08. Jobs: run=2 running=0.
>  Heap: heap=32,768 smbytes=190,247 max_bytes=1,599,864 bufs=100
> max_bufs=6,758
>  Sizeof: boffset_t=8 size_t=8 debug=0 trace=0
>
> Alas, I know of no way to increase any of the bacula-fd limits.  If I
> dead-end here, perhaps I'll query the Bacula mailing lists.

For both yourself and for others, I think it's best to continue with
this route.

Also note that I have no idea how much memory pg_dump might need on
a larger database, also including dwh which tends to get larger faster
than the engine's.

>
> Meanwhile I tried the following for a more permanent solution but this
> failed same as before:
>
> # diff -u java-home.orig-3.6.1.3 java-home
> --- java-home.orig-3.6.1.3  2015-12-10 13:07:44.0 -0500
> +++ java-home   2015-12-30 12:12:45.779462769 -0500
> @@ -13,7 +13,7 @@
> local ret=1
>
> if [ -x "${dir}/bin/java" ]; then
> -   local version="$("${dir}/bin/java" -version 2>&1 | sed \
> +   local version="$("${dir}/bin/java" -Xmx 8 

Re: [ovirt-users] Can I reduce the Java heap size of engine-backup???

[John Florian]

On 12/29/2015 02:02 AM, Yedidyah Bar David wrote:
> On Tue, Dec 29, 2015 at 12:51 AM, John Florian  wrote:
>> I'm trying to run the engine-backup script via a Bacula job using the
>> RunScript option so that the engine-backup dumps its output someplace
>> where Bacula will collect it once engine-backup finishes.  However the
>> job is failing and with enough digging I eventually learned the script
>> was writing the following in /tmp/hs_err_pid5789.log:
>>
>> #
>> # There is insufficient memory for the Java Runtime Environment to continue.
>> # Native memory allocation (mmap) failed to map 2555904 bytes for
>> committing reserved memory.
>> # Possible reasons:
>> #   The system is out of physical RAM or swap space
>> #   In 32 bit mode, the process size limit was hit
>> # Possible solutions:
>> #   Reduce memory load on the system
>> #   Increase physical memory or swap space
>> #   Check if swap backing store is full
>> #   Use 64 bit Java on a 64 bit OS
>> #   Decrease Java heap size (-Xmx/-Xms)
>> #   Decrease number of Java threads
>> #   Decrease Java thread stack sizes (-Xss)
>> #   Set larger code cache with -XX:ReservedCodeCacheSize=
>> # This output file may be truncated or incomplete.
>> #
>> #  Out of Memory Error (os_linux.cpp:2627), pid=5789, tid=140709998221056
>> #
>> # JRE version:  (8.0_65-b17) (build )
>> # Java VM: OpenJDK 64-Bit Server VM (25.65-b01 mixed mode linux-amd64
>> compressed oops)
>> # Failed to write core dump. Core dumps have been disabled. To enable
>> core dumping, try "ulimit -c unlimited" before starting Java again
>> #
>>
>>
>> So is there any good way to reduce the Java heap size?  I mean I know
>> what -Xmx does, but where might I try setting it, ideally so that it
>> affects the engine-backup only?  Any idea of good setting for a very
>> small environment with a dozen VMs?
> engine-backup does not directly call nor need java.
>
> AFAICS it only calls it indirectly as part of some other initialization
> by running java-home [1], which is a script that decides what JAVA_HOME
> to use for the engine. This script only runs 'java -version', which imo
> should not need that much memory. Perhaps there is something else I do
> not fully understand, such as bacula severely limiting available resources
> for the process it runs, or something like that.
>
> If you only want to debug it, and not as a recommended final solution,
> you can create a script [2] which only outputs the needed java home.
> Simply run [1] and make [2] echo the same thing. If [2] exists, [1] will
> only run it and nothing else, as you can see inside it.
>
> I do not think this will work - quite likely engine-backup will fail
> shortly later, if indeed it gets access to so little memory. Please
> report back. Thanks and good luck,
>
> [1] /usr/share/ovirt-engine/bin/java-home
> [2] /usr/share/ovirt-engine/bin/java-home.local
Thanks for the info and response Didi.  Doing the above did allow the
backup to run successfully.  I had also replaced the Bacula RunScript
with "bash -c ulimit" which reported unlimited but I don't play with
those types of limits enough to know if that's correctly reporting to
what engine-backup is constrained.  I did occur to me that perhaps a
better way to learn of any such constraints would be to query Bacula's
file daemon (the only necessary Bacula component running on client
systems that are getting backed up) since I suspect it must be this
component that's actually spawning the RunScript client side.  From the
Bacula Director (server side) I queried the status of the client which
is my oVirt engine and it reports:

europa.doubledog.org-fd Version: 5.2.13 (19 February 2013) 
x86_64-redhat-linux-gnu redhat (Core)
Daemon started 28-Dec-15 16:08. Jobs: run=2 running=0.
 Heap: heap=32,768 smbytes=190,247 max_bytes=1,599,864 bufs=100
max_bufs=6,758
 Sizeof: boffset_t=8 size_t=8 debug=0 trace=0

Alas, I know of no way to increase any of the bacula-fd limits.  If I
dead-end here, perhaps I'll query the Bacula mailing lists.

Meanwhile I tried the following for a more permanent solution but this
failed same as before:

# diff -u java-home.orig-3.6.1.3 java-home
--- java-home.orig-3.6.1.3  2015-12-10 13:07:44.0 -0500
+++ java-home   2015-12-30 12:12:45.779462769 -0500
@@ -13,7 +13,7 @@
local ret=1

if [ -x "${dir}/bin/java" ]; then
-   local version="$("${dir}/bin/java" -version 2>&1 | sed \
+   local version="$("${dir}/bin/java" -Xmx 8 -version 2>&1
| sed \
-e 's/^openjdk version "1\.8\.0.*/VERSION_OK/' \
-e 's/^java version "1\.7\.0.*/VERSION_OK/' \
-e 's/^OpenJDK .*(.*).*/VENDOR_OK/' \


If this script is merely checking the validity of  the JRE/JDK, should
it not be possible to have a test on the rpm details first and only
proceed as it does now if that doesn't work?  The current tests should
work w/o much regard for how the JRE/JDK 

[ovirt-users] How to manually restore ovirt-engine from sql dump file?

[Arman Khalatyan]

Hello,
Due to the HW error we lost ovirt-engine db.
We have only recent dump files from
/var/lib/ovirt-engine/backups/
Is it possible to restore database using dump files?
BTW the VMs are still running without ovirt-engine.

Thanks,
Arman.
***

 Dr. Arman Khalatyan  eScience -SuperComputing
 Leibniz-Institut für Astrophysik Potsdam (AIP)
 An der Sternwarte 16, 14482 Potsdam, Germany

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

Re: [ovirt-users] Dedicated NICs for gluster network

[Nicolas Ecarnot]

Hi Ivan, Nathanaël and everyone,

Today, I finally upgraded this oVirt 3.5.2 into 3.6.1, and I saw 
appearing the gluster network in the networks settings.

I'm not using it yet because I still have questions.

I think I perfectly understood your answer, but there are points I'd 
like to know better :


- I'm not sure that using DNS or /etc/hosts is making any difference. 
Once every dedicated NIC is using a dedicated ip address, with the 
dedicated DNS-record + PTR, I see no benefit to use /etc/hosts... ?


- The oVirt setup I'm working on in this discussion is an 
storage+compute setup (oVirt+gluster on the same hosts). That means that 
my oVirt nodes are both clients and servers of themselves - data storage 
speaking.

I'm worrying about not specifying any gateway for the gluster network :
* How will all my hosts - as gluster clients - be able to find a route 
towards the gluster network (gluster servers)?
* How will my guest - my VMs as gluster clients - be able to find a 
route towards the gluster network (indeed, sometimes also provided that 
way!) ?


- Obviously, all this wouldn't be that fun if is wasn't already in 
production (well OK, QA), and thus I have to change the ip of my gluster 
nodes 
(https://www.gluster.org/pipermail/gluster-users/2014-May/017328.html).


--
Nicolas ECARNOT

Le 27/11/2015 20:00, Ivan Bulatovic a écrit :

Hi Nicolas,

what works for me in 3.6 is creating a new network for gluster within
oVirt, marking it for gluster use only, optionally setting bonded
interface upon NIC's that are dedicated for gluster traffic and
providing it with an IP address without configuring a gateway, and then
modifying /etc/hosts so that hostnames are resolvable between nodes.
Every node should have two hostnames, one for ovirtmgmt network that is
resolvable via DNS (or via /etc/hosts), and the other for gluster
network that is resolvable purely via /etc/hosts (every node should
contain entries for themselves and for each gluster node).

Peers should be probed via their gluster hostnames, while ensuring that
gluster peer status contains only addresses and hostnames that are
dedicated for gluster on each node. Same goes for adding bricks,
creating a volume etc.

This way, no communication (except gluster one) should be allowed
through gluster dedicated vlan. To be on the safe side, we can also
force gluster to listen only on dedicated interfaces via
transport.socket.bind-address option (haven't tried this one, will do).

Separation of gluster (or in the future any storage network), live
migration network, vm and management network is always a good thing.
Perhaps, we could manage failover of those networks within oVirt, ie. in
case lm network is down - use gluster network for lm and vice versa.
Cool candidate for an RFE, but first we need this supported within
gluster itself. This may prove useful when there is not enough NIC's
available to do a bond beneath every defined network. But we can still
separate traffic and provide failover by selecting multiple networks
without actually doing any load balancing between the two.

As Nathanaël mentioned, marking network for gluster use is only
available in 3.6. I'm also interested if there is a better way around
this procedure, or perharps enhancing it.

Kind regards,

Ivan

On 11/27/2015 05:47 PM, Nathanaël Blanchet wrote:

Hello Nicolas,

Did you have a look to this :
http://www.ovirt.org/Features/Select_Network_For_Gluster ?
But it is only available from >=3.6...

Le 27/11/2015 17:02, Nicolas Ecarnot a écrit :

Hello,

[Here : oVirt 3.5.3, 3 x CentOS 7.0 hosts with replica-3 gluster SD
on the hosts].

On the switchs, I have created a dedicated VLAN to isolate the
glusterFS traffic, but I'm not using it yet.
I was thinking of creating a dedicated IP for each node's gluster
NIC, and a DNS record by the way ("my_nodes_name_GL"), but I fear
using this hostname or this ip in oVirt GUI host network interface
tab, leading oVirt think this is a different host.

Not being sure this fear is clearly described, let's say :
- On each node, I create a second ip+(dns record in the soa) used by
gluster, plugged on the correct VLAN
- in oVirt gui, in the host network setting tab, the interface will
be seen, with its ip, but reverse-dns-related to a different hostname.
Here, I fear oVirt might check this reverse DNS and declare this NIC
belongs to another host.

I would also prefer not use a reverse pointing to the name of the
host management ip, as this is evil and I'm a good guy.

On your side, how do you cope with a dedicated storage network in
case of storage+compute mixed hosts?








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

Re: [ovirt-users] R: Re: Network instability after upgrade 3.6.0 -> 3.6.1

[Stefano Danzi]

Hi Dan,
some info about my network setup:

- My bond is used only for VM networking. ovirtmgmt has a dedicated 
ethernet card.

- I haven't set any ethtool opts.
- Nics on bond specs:
04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network 
Connection

Subsystem: ASUSTeK Computer Inc. Motherboard
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at df20 (32-bit, non-prefetchable) [size=128K]
I/O ports at e000 [size=32]
Memory at df22 (32-bit, non-prefetchable) [size=16K]
Capabilities: [c8] Power Management version 2
Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [e0] Express Endpoint, MSI 00
Capabilities: [a0] MSI-X: Enable+ Count=5 Masked-
Capabilities: [100] Advanced Error Reporting
Kernel driver in use: e1000e

[root@ovirt01 ~]# ifconfig
DMZ: flags=4163  mtu 1500
txqueuelen 0  (Ethernet)
RX packets 43546  bytes 2758816 (2.6 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

LAN_HAW: flags=4163  mtu 1500
txqueuelen 0  (Ethernet)
RX packets 2090262  bytes 201078292 (191.7 MiB)
RX errors 0  dropped 86  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

bond0: flags=5187  mtu 1500
txqueuelen 0  (Ethernet)
RX packets 2408059  bytes 456371629 (435.2 MiB)
RX errors 0  dropped 185  overruns 0  frame 0
TX packets 118966  bytes 14862549 (14.1 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

bond0.1: flags=4163  mtu 1500
txqueuelen 0  (Ethernet)
RX packets 2160985  bytes 210157656 (200.4 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

bond0.3: flags=4163  mtu 1500
txqueuelen 0  (Ethernet)
RX packets 151195  bytes 185253584 (176.6 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 118663  bytes 13857950 (13.2 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp4s0: flags=6211  mtu 1500
txqueuelen 1000  (Ethernet)
RX packets 708141  bytes 95034564 (90.6 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 16714  bytes 5193108 (4.9 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
device interrupt 16  memory 0xdf20-df22

enp5s0: flags=6211  mtu 1500
txqueuelen 1000  (Ethernet)
RX packets 1699934  bytes 361339105 (344.5 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 102252  bytes 9669441 (9.2 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
device interrupt 17  memory 0xdf10-df12

enp6s1: flags=4163  mtu 1500
txqueuelen 1000  (Ethernet)
RX packets 2525232  bytes 362345893 (345.5 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 388452  bytes 208145492 (198.5 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
loop  txqueuelen 0  (Local Loopback)
RX packets 116465661  bytes 1515059255942 (1.3 TiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 116465661  bytes 1515059255942 (1.3 TiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ovirtmgmt: flags=4163  mtu 1500
inet 192.168.1.50  netmask 255.255.255.0  broadcast 
192.168.1.255

txqueuelen 0  (Ethernet)
RX packets 3784298  bytes 36509 (529.8 MiB)
RX errors 0  dropped 86  overruns 0  frame 0
TX packets 1737669  bytes 1401650369 (1.3 GiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vnet0: flags=4163  mtu 1500
txqueuelen 500  (Ethernet)
RX packets 558574  bytes 107521742 (102.5 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 1316892  bytes 487764500 (465.1 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vnet1: flags=4163  mtu 1500
txqueuelen 500  (Ethernet)
RX packets 42282  bytes 7373007 (7.0 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 40498  bytes 17598215 (16.7 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vnet2: 

Re: [ovirt-users] oVirt 3.6.1 ISO storage domain with all-in-one local disk install not working as expected

[Matthew Bohnsack]

Thanks.  I will be also testing NFS, as you used in the howto you
reference, but for this phase of my testing, I want to stick with local
disk.  As such, there appears to be a bug with all-in-one engine setup and
a local disk ISO domain.  Should I report a bug for this?  What's the right
way to do that?

I was able to work around the issue by creating a new ISO domain via the
web GUI (see the local-iso-on-host.jpg attachment) and then copying an ISO
into the right place by hand with something like this (your exact path may
vary):

[host ~]# cp CentOS-7-x86_64-Minimal-1511.iso
/home/ovirt-localdisk/iso2/d61c0b87-25cd-4da0-9704-f453143daa6c/images/----/

After taking the two above-mentioned steps, I was able to successfully
attach ISOs to my VMs.

-Matthew

On Tue, Dec 29, 2015 at 8:48 PM, Taste-Of-IT  wrote:

> Hello Matthew,
>
> i got similar problem, but this howto works for me :
> http://taste-of-it.de/ovirt-all-in-one-installation-auf-centos-7/
>
> Hope it works for you too.
> Taste
>
>
> Am 2015-12-29 23:02, schrieb Matthew Bohnsack:
>
>> Hello,
>>
>> I installed an all-in-one oVirt 3.6.1 system on CentOS 7.2 with local
>> disk configured for images and ISOs.  However, the engine web GUI
>> doesn't mention the ISO_DOMAIN, and I can't seem to select an uploaded
>> ISO and attach it to a VM.  Any idea what I'm doing wrong here?
>>
>> Thanks,
>>
>> -Matthew
>>
>> Additional detail...
>>
>> I did engine setup with this where all paths are on local disk:
>>
>> OVESETUP_CONFIG/isoDomainName=str:ISO_DOMAIN
>> OVESETUP_CONFIG/isoDomainACL=str:*(rw)
>> OVESETUP_CONFIG/isoDomainMountPoint=str:/home/ovirt-localdisk/iso
>> OVESETUP_AIO/storageDomainDir=str:/home/ovirt-localdisk/images/
>>
>> With this, I was able to upload an image like so:
>>
>> [root@host ~]#  engine-iso-uploader upload -i ISO_DOMAIN
>> ./CentOS-7-x86_64-Minimal-1511.iso
>> Please provide the REST API password for the admin@internal oVirt
>> Engine user (CTRL+D to abort):
>> Uploading, please wait...
>> INFO: Start uploading ./CentOS-7-x86_64-Minimal-1511.iso
>> Uploading: [] 100%
>>
>> INFO: ./CentOS-7-x86_64-Minimal-1511.iso uploaded successfully
>>
>> After this, the local filesystem had my image:
>>
>> [root@host ~]# find /home/ovirt-localdisk/iso/ -iname *.iso
>>
>> /home/ovirt-localdisk/iso/d33449b5-f660-4e90-abd4-5d55f9c27b85/images/----/CentOS-7-x86_64-Minimal-1511.iso
>>
>> But this seems to say something's wrong:
>>
>> [root@host ~]# engine-iso-uploader list
>> Please provide the REST API password for the admin@internal oVirt
>> Engine user (CTRL+D to abort):
>> ERROR: There are no ISO storage domains.
>>
>> Further, the engine web gui has no mention of the ISO storage domain
>> nor does CentOS-7-x86_64-Minimal-1511.iso show up as an option to
>> attach as a CDROM to guests.
>>
>>
>> ___
>> 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
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] oVirt 3.6.1 ISO storage domain with all-in-one local disk install not working as expected

[Taste-Of-IT]

Hi Matthew,

i also new with ovirt, but i try to help. what for an iso_domain you 
created? nfs,posix, glusterfs, iscsi or fibre? the point with iso upload 
should work like that: # engine-iso-uploader --iso-domain=local_iso 
upload what-ever.iso . ater that you can see this iso in your storage 
for your iso_domain. i dont know if other ways as good as that.


just my 2cents - Taste

Am 2015-12-30 18:28, schrieb Matthew Bohnsack:

Thanks.  I will be also testing NFS, as you used in the howto you
reference, but for this phase of my testing, I want to stick with
local disk.  As such, there appears to be a bug with all-in-one
engine setup and a local disk ISO domain.  Should I report a bug for
this?  What's the right way to do that?

I was able to work around the issue by creating a new ISO domain via
the web GUI (see the local-iso-on-host.jpg attachment) and then
copying an ISO into the right place by hand with something like this
(your exact path may vary):

[host ~]# cp CentOS-7-x86_64-Minimal-1511.iso
/home/ovirt-localdisk/iso2/d61c0b87-25cd-4da0-9704-f453143daa6c/images/----/

After taking the two above-mentioned steps, I was able to successfully
attach ISOs to my VMs.

-Matthew

On Tue, Dec 29, 2015 at 8:48 PM, Taste-Of-IT 
wrote:


Hello Matthew,

i got similar problem, but this howto works for me
:http://taste-of-it.de/ovirt-all-in-one-installation-auf-centos-7/
[2]

Hope it works for you too.
Taste

Am 2015-12-29 23:02, schrieb Matthew Bohnsack:


Hello,

I installed an all-in-one oVirt 3.6.1 system on CentOS 7.2 with
local
disk configured for images and ISOs.  However, the engine web
GUI
doesn't mention the ISO_DOMAIN, and I can't seem to select an
uploaded
ISO and attach it to a VM.  Any idea what I'm doing wrong here?

Thanks,

-Matthew

Additional detail...

I did engine setup with this where all paths are on local disk:

OVESETUP_CONFIG/isoDomainName=str:ISO_DOMAIN
OVESETUP_CONFIG/isoDomainACL=str:*(rw)
OVESETUP_CONFIG/isoDomainMountPoint=str:/home/ovirt-localdisk/iso
OVESETUP_AIO/storageDomainDir=str:/home/ovirt-localdisk/images/

With this, I was able to upload an image like so:

[root@host ~]#  engine-iso-uploader upload -i ISO_DOMAIN
./CentOS-7-x86_64-Minimal-1511.iso 
Please provide the REST API password for the admin@internal oVirt
Engine user (CTRL+D to abort): 
Uploading, please wait...
INFO: Start uploading ./CentOS-7-x86_64-Minimal-1511.iso 
Uploading: [] 100%

INFO: ./CentOS-7-x86_64-Minimal-1511.iso uploaded successfully

After this, the local filesystem had my image:

[root@host ~]# find /home/ovirt-localdisk/iso/ -iname *.iso




/home/ovirt-localdisk/iso/d33449b5-f660-4e90-abd4-5d55f9c27b85/images/----/CentOS-7-x86_64-Minimal-1511.iso


But this seems to say something's wrong:

[root@host ~]# engine-iso-uploader list
Please provide the REST API password for the admin@internal oVirt
Engine user (CTRL+D to abort): 
ERROR: There are no ISO storage domains.

Further, the engine web gui has no mention of the ISO storage
domain
nor does CentOS-7-x86_64-Minimal-1511.iso show up as an option
to
attach as a CDROM to guests.

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

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




Links:
--
[1] http://lists.ovirt.org/mailman/listinfo/users
[2] http://taste-of-it.de/ovirt-all-in-one-installation-auf-centos-7/

___
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

[ovirt-users] virt-viewer error

[靳占冰]

virt-viewer-x64-3.0.msi version can not connect a virtual machine.
Error: Can not find the specified file



When I select Console button to connect AD virtual machines, reported 
the following error: cannot find Application.

1.My client system is windows7
2.I use the Firefox browser
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Getting event message "The Hosted Engine Storage Domain isn't Active" every two hours

[Will Dennis]

Thought I’d start a new thread for this issue… Please also refer to my prior 
thread where 
I have the background to this. Again, I am running hosted engine on 
hyperconverged infra. Is this issue possibly related to Bug 
1269768 ?

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

Re: [ovirt-users] R: Re: Network instability after upgrade 3.6.0 -> 3.6.1

[Dan Kenigsberg]

On Tue, Dec 29, 2015 at 09:57:07PM +, Jon Archer wrote:
> Hi Stefano,
> 
> It's definitely not the switch, it seems to be the latest kernel package
> (kernel-3.10.0-327.3.1.el7.x86_64) which stops bonding working correctly,
> reverting back to the previous kernel brings the network up in 802.3ad mode
> (4).
> 
> I know, from reading the release notes of 7.2, that there were some changes
> to the bonding bits in the kernel so i'm guessing maybe some defaults have
> changed.
> 
> I'll keep digging and post back as soon as i have something.
> 
> Jon
> 
> On 29/12/15 19:55, Stefano Danzi wrote:
> >Hi! I didn't solve yet. I'm still using mode 2 on bond interface. What's
> >your switch model and firmware version?

Hi Jon and Stefano,

We've been testing bond mode 4 with (an earlier)
kernel-3.10.0-327.el7.x86_64 and experienced no such behaviour.

However, to better identify the suspected kernel bug, could you provide
more information regarding your network connectivity?

What is the make of your NICs? Which driver do you use?

Do you set special ethtool opts (LRO with bridge was broken in 7.2.0
kernel if I am not mistaken)?

You have the ovirtmgmt bridge on top of your bond, right?

Can you share your ifcfg*?

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