Re: [ovirt-users] Failed to start self hosted engine after upgrading oVirt to 4.0

2016-06-26 Thread Dan Kenigsberg 
On Fri, Jun 24, 2016 at 06:45:24PM +0200, Stefano Danzi wrote:
> HI!!
> 
> I found a workaround
> 
> the brocker process try to connect to vdsm to IPV4 host address using an
> IPV6 connection
> (I noticed that doing a strace to the process),
> but ipv6 is not intialized at boot. (why connect to IPV4 address using
> IPV6?)

Acutally, we take an effort to disable ipv6 on ovirt host networks.
Keeping them open without explicit request was deemed a security issue.

Can you share your strace line and the relevant lines in vdsm.log? I
don't understand what is the issue that you are reporting.

> 
> I added the following lines to crontab:
> 
> @reboot echo 'echo 0 > /proc/sys/net/ipv6/conf/lo/disable_ipv6' |
> /usr/bin/at now+1 minutes
> @reboot echo 'echo 0 > /proc/sys/net/ipv6/conf/ovirtmgmt/disable_ipv6' |
> /usr/bin/at now+1 minutes
> @reboot echo '/usr/sbin/route add default gw 192.168.1.254'  | /usr/bin/at
> now+1 minutes
> 
> 
> 
> Il 24/06/2016 12.36, Stefano Danzi ha scritto:
> > How I can change self hosted engine configuration to mount directly
> > gluster storage without pass through gluster NFS?
> > 
> > Maybe this solve
> > 
> > Il 24/06/2016 10.16, Stefano Danzi ha scritto:
> > > After an additional yum clean all && yum update was updated some
> > > other rpms.
> > > 
> > > Something changed.
> > > My setup has engine storage on gluster, but mounted with NFS.
> > > Now gluster daemon don't automatically start at boot. After starting
> > > manually gluster the error is the same:
> > > 
> > > ==> /var/log/ovirt-hosted-engine-ha/broker.log <==
> > > Thread-19::ERROR::2016-06-24 
> > > 10:10:36,758::listener::182::ovirt_hosted_engine_ha.broker.listener.ConnectionHandler::(handle)
> > > Error while serving connection
> > > Traceback (most recent call last):
> > >   File 
> > > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/listener.py",
> > > line 166, in handle
> > > data)
> > >   File 
> > > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/listener.py",
> > > line 299, in _dispatch
> > > .set_storage_domain(client, sd_type, **options)
> > >   File 
> > > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/storage_broker.py",
> > > line 66, in set_storage_domain
> > > self._backends[client].connect()
> > >   File 
> > > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/storage_backends.py",
> > > line 400, in connect
> > > volUUID=volume.volume_uuid
> > >   File 
> > > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/storage_backends.py",
> > > line 245, in _get_volume_path
> > > volUUID
> > >   File "/usr/lib64/python2.7/xmlrpclib.py", line 1233, in __call__
> > > return self.__send(self.__name, args)
> > >   File "/usr/lib64/python2.7/xmlrpclib.py", line 1587, in __request
> > > verbose=self.__verbose
> > >   File "/usr/lib64/python2.7/xmlrpclib.py", line 1273, in request
> > > return self.single_request(host, handler, request_body, verbose)
> > >   File "/usr/lib64/python2.7/xmlrpclib.py", line 1301, in single_request
> > > self.send_content(h, request_body)
> > >   File "/usr/lib64/python2.7/xmlrpclib.py", line 1448, in send_content
> > > connection.endheaders(request_body)
> > >   File "/usr/lib64/python2.7/httplib.py", line 975, in endheaders
> > > self._send_output(message_body)
> > >   File "/usr/lib64/python2.7/httplib.py", line 835, in _send_output
> > > self.send(msg)
> > >   File "/usr/lib64/python2.7/httplib.py", line 797, in send
> > > self.connect()
> > >   File "/usr/lib/python2.7/site-packages/vdsm/m2cutils.py", line
> > > 203, in connect
> > > sock = socket.create_connection((self.host, self.port), self.timeout)
> > >   File "/usr/lib64/python2.7/socket.py", line 571, in create_connection
> > > raise err
> > > error: [Errno 101] Network is unreachable
> > > 
> > > 
> > > VDSM.log
> > > 
> > > jsonrpc.Executor/5::DEBUG::2016-06-24
> > > 10:10:21,694::task::995::Storage.TaskManager.Task::(_decref)
> > > Task=`5c3b6f30-d3a8-431e-9dd0-8df79b171709`::ref 0
> > > aborting False
> > > jsonrpc.Executor/5::WARNING::2016-06-24
> > > 10:10:21,694::vdsmapi::143::SchemaCache::(_report_inconsistency)
> > > Following parameters ['type'] were not recogn
> > > ized
> > > jsonrpc.Executor/5::WARNING::2016-06-24
> > > 10:10:21,694::vdsmapi::143::SchemaCache::(_report_inconsistency)
> > > Provided value "2" not defined in DiskType en
> > > um for Volume.getInfo
> > > jsonrpc.Executor/5::WARNING::2016-06-24
> > > 10:10:21,694::vdsmapi::143::SchemaCache::(_report_inconsistency)
> > > Parameter capacity is not uint type
> > > jsonrpc.Executor/5::WARNING::2016-06-24
> > > 10:10:21,694::vdsmapi::143::SchemaCache::(_report_inconsistency)
> > > Required property allocType is not provided w
> > > hen calling Volume.getInfo
> > > jsonrpc.Executor/5::WARNING::2016-06-24
> > > 10:10:21,694::vdsmapi::143::SchemaCache::(_report_inconsistency)
> > > Parameter mtime

Re: [ovirt-users] oVirt 4.0 Host install fail cause of dnf api

2016-06-26 Thread Pilař Vojtěch 
Thank you for confirming my thoughts. 

There is an easier way, than to use completely different build - i used gerrit 
[1] repo and found the minidnf.py file, where the signture checking is and 
simply removed it for the time being.

If anyone is interested you can "fix" it in:

/usr/lib/python2.7/site-packages/otopi/minidnf.py and remove L:626-638  


[1] https://gerrit.ovirt.org/#/c/59494/1/src/otopi/minidnf.py

Best Regards,
Vojtech



Od: Yedidyah Bar David 
Odesláno: 26. června 2016 8:50
Komu: Pilař Vojtěch
Kopie: users@ovirt.org
Předmět: Re: [ovirt-users] oVirt 4.0 Host install fail cause of dnf api

On Sat, Jun 25, 2016 at 9:22 PM, Pilař Vojtěch  wrote:
>
> Hi all,
>
> iam trying to install host from oVirt Engine Web Admin, but with no success
> so far. Everything dies on sigCheckPkg bug from dnf
> (https://bugzilla.redhat.com/show_bug.cgi?id=1344270).

Indeed.

Above bug can only be fixed once dnf publishes an official api for
checking signatures. For now we just dropped the check, see this bug:

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

which is targeted to 4.0.1.

>
> 2016-06-25 19:36:22 INFO otopi.plugins.otopi.packagers.dnfpackager
> dnfpackager.info:79 DNF Downloaded libselinux-python-2.4-4.fc23.x86_64.rpm
> The 'sigCheckPkg' function is not a part of DNF API and will be removed in
> the upcoming DNF release. Please use only officially supported API
> functions. DNF API documentation is available at
> https://dnf.readthedocs.org/en/latest/api.html.
> 2016-06-25 19:36:22 ERROR otopi.plugins.otopi.packagers.dnfpackager
> dnfpackager.error:84 DNF 'NoneType' object is not iterable
> 2016-06-25 19:36:22 DEBUG otopi.plugins.otopi.packagers.dnfpackager
> dnfpackager.verbose:75 DNF Closing transaction with rollback
>
> Is there any workaround? I see no way to deploy hosts.

For now the only workaround I am aware of is to use a fixed
build, which you can get from jenkins [1] or from the nightly snapshots [2].

[1] http://jenkins.ovirt.org/job/otopi_4.0_build-artifacts-el7-x86_64/
[2] 
https://www.ovirt.org/develop/dev-process/install-nightly-snapshot/#from-40-branches

Best,
--
Didi
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] oVirt and Ceph

2016-06-26 Thread Nicolás 

Hi Nir,

El 25/06/16 a las 22:57, Nir Soffer escribió:

On Sat, Jun 25, 2016 at 11:47 PM, Nicolás  wrote:

Hi,

We're using Ceph along with an iSCSI gateway, so our storage domain is
actually an iSCSI backend. So far, we have had zero issues with cca. 50 high
IO rated VMs. Perhaps [1] might shed some light on how to set it up.

Can you share more details on this setup and how you integrate with ovirt?

For example, are you using ceph luns in regular iscsi storage domain, or
attaching luns directly to vms?


Fernando Frediani (responding to this thread) hit the nail on the head. 
Actually we have a 3-node Ceph infrastructure, so we created a few 
volumes on the Ceph nodes side (RBD) and then exported them to iSCSI, so 
it's oVirt who creates the LVs on the top, this way we don't need to 
attach luns directly.


Once the volumes are exported on the iSCSI side, adding an iSCSI domain 
on oVirt is enough to make the whole thing work.


As for experience, we have done a few tests and so far we've had zero 
issues:


 * The main bottleneck is the iSCSI gateway interface bandwith. In our
   case we have a balance-alb bond over two 1G network interfaces.
   Later we realized this kind of bonding is useless because MAC
   addresses won't change, so in practice only 1G will be used at most.
   Making some heavy tests (i.e., powering on 50 VMs at a time) we've
   reached this threshold at specific points but it didn't affect
   performance significantly.
 * Doing some additional heavy tests (powering on and off all VMs at a
   time), we've reached the maximum value of cca. 1200 IOPS at a time.
   In normal conditions we don't surpass 200 IOPS, even when these 50
   VMs do lots of disk operations.
 * We've also done some tolerance tests, like removing one or more
   disks from a Ceph node, reinserting them, suddenly shut down one
   node, restoring it... The only problem we've experienced is a slower
   access to the iSCSI backend, which results in a message in the oVirt
   manager warning about this: something like "Storage is taking to
   long to respond...", which was maybe 15-20 seconds. We got no VM
   pauses at any time, though, nor any significant issue.


Did you try our dedicated cinder/ceph support and compared it with ceph
iscsi gateway?


Not actually, in order to avoid deploying Cinder we directly implemented 
the gateway as it looked easier to us.



Nir


Hope this helps.

Regards.


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

Re: [ovirt-users] oVirt 4.0 Host install fail cause of dnf api

2016-06-26 Thread Yedidyah Bar David 
On Sun, Jun 26, 2016 at 11:47 AM, Pilař Vojtěch  wrote:
> Thank you for confirming my thoughts.
>
> There is an easier way, than to use completely different build - i used 
> gerrit [1] repo and found the minidnf.py file, where the signture checking is 
> and simply removed it for the time being.
>
> If anyone is interested you can "fix" it in:
>
> /usr/lib/python2.7/site-packages/otopi/minidnf.py and remove L:626-638
>
>
> [1] https://gerrit.ovirt.org/#/c/59494/1/src/otopi/minidnf.py

Well, some people might disagree about what's "easier", but thanks for
your report anyway!

You can also check the git log of otopi-1.5 branch in [1], to see other
changes you get from the nightly snapshot:

[1] 
https://gerrit.ovirt.org/gitweb?p=otopi.git;a=shortlog;h=refs/heads/otopi-1.5

Best,

>
> Best Regards,
> Vojtech
>
>
> 
> Od: Yedidyah Bar David 
> Odesláno: 26. června 2016 8:50
> Komu: Pilař Vojtěch
> Kopie: users@ovirt.org
> Předmět: Re: [ovirt-users] oVirt 4.0 Host install fail cause of dnf api
>
> On Sat, Jun 25, 2016 at 9:22 PM, Pilař Vojtěch  wrote:
>>
>> Hi all,
>>
>> iam trying to install host from oVirt Engine Web Admin, but with no success
>> so far. Everything dies on sigCheckPkg bug from dnf
>> (https://bugzilla.redhat.com/show_bug.cgi?id=1344270).
>
> Indeed.
>
> Above bug can only be fixed once dnf publishes an official api for
> checking signatures. For now we just dropped the check, see this bug:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1343382
>
> which is targeted to 4.0.1.
>
>>
>> 2016-06-25 19:36:22 INFO otopi.plugins.otopi.packagers.dnfpackager
>> dnfpackager.info:79 DNF Downloaded libselinux-python-2.4-4.fc23.x86_64.rpm
>> The 'sigCheckPkg' function is not a part of DNF API and will be removed in
>> the upcoming DNF release. Please use only officially supported API
>> functions. DNF API documentation is available at
>> https://dnf.readthedocs.org/en/latest/api.html.
>> 2016-06-25 19:36:22 ERROR otopi.plugins.otopi.packagers.dnfpackager
>> dnfpackager.error:84 DNF 'NoneType' object is not iterable
>> 2016-06-25 19:36:22 DEBUG otopi.plugins.otopi.packagers.dnfpackager
>> dnfpackager.verbose:75 DNF Closing transaction with rollback
>>
>> Is there any workaround? I see no way to deploy hosts.
>
> For now the only workaround I am aware of is to use a fixed
> build, which you can get from jenkins [1] or from the nightly snapshots [2].
>
> [1] http://jenkins.ovirt.org/job/otopi_4.0_build-artifacts-el7-x86_64/
> [2] 
> https://www.ovirt.org/develop/dev-process/install-nightly-snapshot/#from-40-branches
>
> Best,
> --
> Didi



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

Re: [ovirt-users] latest CentOS libvirt updates safe?

2016-06-26 Thread Christophe TREFOIS 
This is how I upgrade.

Works.

Dr Christophe Trefois, Dipl.-Ing.  
Technical Specialist / Post-Doc

UNIVERSITÉ DU LUXEMBOURG

LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
Campus Belval | House of Biomedicine  
6, avenue du Swing 
L-4367 Belvaux  
T: +352 46 66 44 6124 
F: +352 46 66 44 6949  
http://www.uni.lu/lcsb




This message is confidential and may contain privileged information. 
It is intended for the named recipient only. 
If you receive it in error please notify me and permanently delete the original 
message and any copies. 


  

> On 26 Jun 2016, at 08:57, Yedidyah Bar David  wrote:
> 
> On Sun, Jun 26, 2016 at 4:14 AM, Brett I. Holcomb  
> wrote:
>> 
>> 
>> On 06/25/2016 08:10 PM, Nir Soffer wrote:
>>> 
>>> On Sat, Jun 25, 2016 at 8:51 PM, Brett I. Holcomb 
>>> wrote:
 
 
 On 06/25/2016 10:57 AM, Robert Story wrote:
 
 I have oVirt 3.5.x on CentOS 7 hosts. These hosts have updates which
 include livbirt:
 
  libvirt-client   x86_64  1.2.17-13.el7_2.5  updates
 4.3 M
  libvirt-daemon   x86_64  1.2.17-13.el7_2.5  updates
 585 k
  libvirt-daemon-config-nwfilter   x86_64  1.2.17-13.el7_2.5  updates
 122 k
  libvirt-daemon-driver-interface  x86_64  1.2.17-13.el7_2.5  updates
 162 k
  libvirt-daemon-driver-networkx86_64  1.2.17-13.el7_2.5  updates
 302 k
  libvirt-daemon-driver-nodedevx86_64  1.2.17-13.el7_2.5  updates
 161 k
  libvirt-daemon-driver-nwfilter   x86_64  1.2.17-13.el7_2.5  updates
 185 k
  libvirt-daemon-driver-qemu   x86_64  1.2.17-13.el7_2.5  updates
 571 k
  libvirt-daemon-driver-secret x86_64  1.2.17-13.el7_2.5  updates
 155 k
  libvirt-daemon-driver-storagex86_64  1.2.17-13.el7_2.5  updates
 328 k
  libvirt-daemon-kvm   x86_64  1.2.17-13.el7_2.5  updates
 118 k
  libvirt-lock-sanlock
 
 Is it safe to let yum update these packages while the host has running
 VMs?
 in maintenance mode? or not at all?
 
 
 Robert
 
 
 
 ___
 Users mailing list
 Users@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/users
 
 
 I saw a response where we are supposed to go to maintenance mode and then
 VMs will migrate but i've got nowhere to migrate to as I'm on a host with
 hosted Engine and no other host to migrate to.  So do I shutdown all VMs
 and
 then go to maintenance mode and then update and reboot my host?
>>> 
>>> In this case you cannot put the host into maintenance, since hosted
>>> engine is running on this host.
>>> 
>>> Adding Simone to add more details on hosted engine upgrades.
>>> 
>>> Nir
>> 
>> Thanks.  That will be a big help.
> 
> Didn't test, I think this will work:
> 
> 1. Shutdown all other VMs (as you already did)
> 2. Move to global maintenance: hosted-engine --set-maintenance --mode=global
> 3. Cleanly shutdown engine vm
> 4. stop HA daemons: service ovirt-ha-agent stop ; service ovirt-ha-broker stop
> 5. yum update what you need/want
> 6. Reboot (perhaps not always needed)
> 7. See that HA daemons started
> 8. Exit global maintenance: hosted-engine --set-maintenance --mode=none
> 9. Start engine vm (or see that HA starts it)
> -- 
> Didi
> ___
> 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] Network Interface order changed after reboot

2016-06-26 Thread Yevgeny Zaspitsky 
Christoph,

Are those nodes bare-metal or they're VMs?

Regards,
Yevgeny

On Thu, Jun 23, 2016 at 3:49 PM,  wrote:

> Hi List,
>
> I have two nodes (running CentOS 7) and the network interface order
> changed for some interfaces after every reboot.
>
> The configurations are done through the oVirt GUI. So the ifcfg-ethX
> scripts are configured automatically by VDSM.
>
> Is there any option to get this configured to be stable?
>
> Best regards and thank you
>
> Christoph
>
> ___
> 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] Network Interface order changed after reboot

2016-06-26 Thread Yevgeny Zaspitsky 
BTW, what oVirt (vdsm&engine) version do you use?

On Sun, Jun 26, 2016 at 3:15 PM, Yevgeny Zaspitsky 
wrote:

> Christoph,
>
> Are those nodes bare-metal or they're VMs?
>
> Regards,
> Yevgeny
>
> On Thu, Jun 23, 2016 at 3:49 PM,  wrote:
>
>> Hi List,
>>
>> I have two nodes (running CentOS 7) and the network interface order
>> changed for some interfaces after every reboot.
>>
>> The configurations are done through the oVirt GUI. So the ifcfg-ethX
>> scripts are configured automatically by VDSM.
>>
>> Is there any option to get this configured to be stable?
>>
>> Best regards and thank you
>>
>> Christoph
>>
>> ___
>> 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] direct mounting of vm disks?

2016-06-26 Thread Scott 
Hi Robert,

I've modified disk images for oVirt virtual machines before.  I mostly run
servers so they all use preallocated as opposed to thin provisioned disks.
I'm not sure if that matters, but it means my VM disk images are raw files
(as opposed to qcow).  Therefore, I used something like the following guide
to get into the disk image.  These directions don't use kpartx or
libguestfs, but I guess those would work too.  I think it goes without
saying, your VM should be off before you modify its disk without its
knowledge.

https://major.io/2010/12/14/mounting-a-raw-partition-file-made-with-dd-or-dd_rescue-in-linux/

For me, the biggest problem I had was the partition in the disk image was
really an LVM PV.  And that LVM group had the same volume group name as one
on the server I was doing this modification.  I had two volume groups with
the same name, which made things a little tricky.  But I'll leave that to
you to figure out :)

Scott

On Sat, Jun 25, 2016 at 11:41 PM Robert Story  wrote:

> Hello,
>
> I'm using oVirt 3.5.x w/nfs for vm file storage. I'm trying to restore a vm
> from backup, which entails:
>
>  - scp backup.tar to vm
>  - untar backup on vm
>
> this means all the data makes 3 trips over the network, each of which
> causes a load spike on my nfs server. That nfs load, of course, affects all
> other vms.
>
> what I'd like to be able to do is
>
>  - scp backup.tar to nfs server
>  - stop vm
>  - mount vm disks on nfs server
>  - untar backup on nfs server (using ionice to minimze load impact)
>  - unmount vm disks
>  - start vm
>
> I remember that I used to use kpartx to mount regular KVM disks, so I'm
> hoping that it can also be done here. Anyone else tried to make this work?
>
>
> Robert
>
> --
> Senior Software Engineer @ Parsons
> ___
> 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] Create a Virtual Disk failed

2016-06-26 Thread Yaniv Dary 
Adding Tal.
What version are you using? Can you attach logs?

Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109

Tel : +972 (9) 7692306
8272306
Email: yd...@redhat.com
IRC : ydary


On Sat, Jun 25, 2016 at 12:26 PM, Dewey Du  wrote:

> I use glusterfs as storage. When I tried to create a virtual disk for a
> vm, I got the following error in UI logs.
>
> ERROR [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService]
> (default task-48) [] Permutation name: B003B5EDCB6FC4308644D5D001F65B4C
> ERROR [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService]
> (default task-48) [] Uncaught exception: :
> com.google.gwt.core.client.JavaScriptException: (TypeError)
>  __gwt$exception: : a is undefined
> at Unknown._kj(Unknown Source)
> at Unknown.JUq(Unknown Source)
> at Unknown.Fbr(Unknown Source)
> at Unknown.Hno(Unknown Source)
> at Unknown.t0n(Unknown Source)
> at Unknown.w0n(Unknown Source)
> at Unknown.q3n(Unknown Source)
> at Unknown.t3n(Unknown Source)
> at Unknown.S2n(Unknown Source)
> at Unknown.V2n(Unknown Source)
> at Unknown.bMe(Unknown Source)
> at Unknown.V7(Unknown Source)
> at Unknown.k8(Unknown Source)
> at Unknown.czf/c.onreadystatechange<(Unknown Source)
> at Unknown.Ux(Unknown Source)
> at Unknown.Yx(Unknown Source)
> at Unknown.Xx/<(Unknown Source)
> at Unknown.anonymous(Unknown Source)
>
>
> ___
> 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] Accessing VM over WAN

2016-06-26 Thread Yaniv Dary 
I would ask this in the spice mailing lists.

Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109

Tel : +972 (9) 7692306
8272306
Email: yd...@redhat.com
IRC : ydary


On Sun, Jun 26, 2016 at 7:06 AM, RK RK  wrote:

> Hi,
>
> I am planning to deploy oVirt 4.0.0 in a production environment where
> initially it will host 150 VDIs and will expand by 20 to 25 in subsequent
> years with Windows 7, 8.1 and 10.
>
> Users will be accessing these VDIs from their android tab or any tiny thin
> client devices which will have only very small footprint OS with HTML5
> supported browser.
>
> I wish to give users to access the VDIs over WAN(from their home or on
> travel). Is it possible to access the VDIs via spice-html5 over the WAN.
>
> Any special configurations to be made to enable it? How should I make
> spice-html5 as the default protocol to access the VDIs?
>
> --
>
> With Regards,
> RK,
> +91 9840483044
>
> ___
> 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 to 4.0 Upgrade

2016-06-26 Thread Yaniv Dary 
What OS are you running the engine on?

Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109

Tel : +972 (9) 7692306
8272306
Email: yd...@redhat.com
IRC : ydary


On Sun, Jun 26, 2016 at 7:54 AM, Brett I. Holcomb 
wrote:

> In order to not hijack another thread I wanted to separate this from the
> "latest CentOS libvirt updates safe?" thread since this is different than
> what the OP on that thread wants to do.
>
> I've been digging through the 4.0 documentation since I'd like to upgrade
> in the not to distant future so I'm doing research and I'm confused.
>
> I'm running 3.6.6 in a hosted Engine environment.  My engine runs in a vm
> on the host.  The host is a physical box and the VMs are stored on a NAS
> accessed by an iSCSI LUN,  I have no other hosts running so I can not
> migrate.
>
> According to this link, https://www.ovirt.org/release/4.0.0/, I'm told to
> simply run yum update ovirt-engine-setup and then engine-setup but I assume
> that's for a non hosted-engine environment.  I then go to the link for
> Hosted_Engine_HOwto#Upgrade_Hosted_Engine guide and am told to do this.
>
> Set hosted-engine maintenance mode to global and other stuff that is
> written assuming I have some place to migrate my VMs to.  I do not have
> another host.
>
> So how do I properly move to oVirt 4.0 from 3.6.6 on a single physical
> host running a hosted Engine VM?
>
> 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

Re: [ovirt-users] oVirt and Ceph

2016-06-26 Thread Yaniv Dary 
Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109

Tel : +972 (9) 7692306
8272306
Email: yd...@redhat.com
IRC : ydary


On Sun, Jun 26, 2016 at 11:49 AM, Nicolás  wrote:

> Hi Nir,
>
> El 25/06/16 a las 22:57, Nir Soffer escribió:
>
> On Sat, Jun 25, 2016 at 11:47 PM, Nicolás  
>  wrote:
>
> Hi,
>
> We're using Ceph along with an iSCSI gateway, so our storage domain is
> actually an iSCSI backend. So far, we have had zero issues with cca. 50 high
> IO rated VMs. Perhaps [1] might shed some light on how to set it up.
>
> Can you share more details on this setup and how you integrate with ovirt?
>
> For example, are you using ceph luns in regular iscsi storage domain, or
> attaching luns directly to vms?
>
>
> Fernando Frediani (responding to this thread) hit the nail on the head.
> Actually we have a 3-node Ceph infrastructure, so we created a few volumes
> on the Ceph nodes side (RBD) and then exported them to iSCSI, so it's oVirt
> who creates the LVs on the top, this way we don't need to attach luns
> directly.
>
> Once the volumes are exported on the iSCSI side, adding an iSCSI domain on
> oVirt is enough to make the whole thing work.
>
> As for experience, we have done a few tests and so far we've had zero
> issues:
>
>- The main bottleneck is the iSCSI gateway interface bandwith. In our
>case we have a balance-alb bond over two 1G network interfaces. Later we
>realized this kind of bonding is useless because MAC addresses won't
>change, so in practice only 1G will be used at most. Making some heavy
>tests (i.e., powering on 50 VMs at a time) we've reached this threshold at
>specific points but it didn't affect performance significantly.
>
>
Did you try using ISCSI bonding to allow use of more than one path?


>
>- Doing some additional heavy tests (powering on and off all VMs at a
>time), we've reached the maximum value of cca. 1200 IOPS at a time. In
>normal conditions we don't surpass 200 IOPS, even when these 50 VMs do lots
>of disk operations.
>- We've also done some tolerance tests, like removing one or more
>disks from a Ceph node, reinserting them, suddenly shut down one node,
>restoring it... The only problem we've experienced is a slower access to
>the iSCSI backend, which results in a message in the oVirt manager warning
>about this: something like "Storage is taking to long to respond...", which
>was maybe 15-20 seconds. We got no VM pauses at any time, though, nor any
>significant issue.
>
> Did you try our dedicated cinder/ceph support and compared it with ceph
> iscsi gateway?
>
>
> Not actually, in order to avoid deploying Cinder we directly implemented
> the gateway as it looked easier to us.
>
> Nir
>
>
> Hope this helps.
>
> Regards.
>
>
> ___
> 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] Network Interface order changed after reboot

2016-06-26 Thread Edward Haas 
On Thu, Jun 23, 2016 at 3:49 PM,  wrote:

> Hi List,
>
> I have two nodes (running CentOS 7) and the network interface order
> changed for some interfaces after every reboot.
>
> The configurations are done through the oVirt GUI. So the ifcfg-ethX
> scripts are configured automatically by VDSM.
>
> Is there any option to get this configured to be stable?
>
> Best regards and thank you
>
> Christoph
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>

Hi Christoph,

VDSM indeed edits and takes ownership of the interfaces for the networks it
manages.
However, editing the ifcfg files should not change anything in the order of
the devices, unless it was originally set
in an unsupported fashion. An ifcfg file is bound to a specific device name
and I'm not familiar to device names
floating around randomly.
Perhaps you should elaborate more on what it means by 'order changed'.

Here is an example of a setup we do not support (pre adding the host to
Engine):
The initial ifcfg file name: ifcfg-eth0
The initial ifcfg file content: DEVICE="eth1"
In this configuration, the name of the ifcfg file is inconsistent with the
name of the device it represents.
VDSM expects them to me in sync.

Please provide the ifcfg files before and after you add the host to Engine.

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

Re: [ovirt-users] Network Interface order changed after reboot

2016-06-26 Thread Yedidyah Bar David 
On Sun, Jun 26, 2016 at 3:51 PM, Edward Haas  wrote:
>
>
> On Thu, Jun 23, 2016 at 3:49 PM,  wrote:
>>
>> Hi List,
>>
>> I have two nodes (running CentOS 7) and the network interface order
>> changed for some interfaces after every reboot.
>>
>> The configurations are done through the oVirt GUI. So the ifcfg-ethX
>> scripts are configured automatically by VDSM.
>>
>> Is there any option to get this configured to be stable?
>>
>> Best regards and thank you
>>
>> Christoph
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>
>
> Hi Christoph,
>
> VDSM indeed edits and takes ownership of the interfaces for the networks it
> manages.
> However, editing the ifcfg files should not change anything in the order of
> the devices, unless it was originally set
> in an unsupported fashion. An ifcfg file is bound to a specific device name
> and I'm not familiar to device names
> floating around randomly.
> Perhaps you should elaborate more on what it means by 'order changed'.
>
> Here is an example of a setup we do not support (pre adding the host to
> Engine):
> The initial ifcfg file name: ifcfg-eth0
> The initial ifcfg file content: DEVICE="eth1"
> In this configuration, the name of the ifcfg file is inconsistent with the
> name of the device it represents.
> VDSM expects them to me in sync.
>
> Please provide the ifcfg files before and after you add the host to Engine.

Perhaps Christoph refers to the problem that [1] was meant to solve?

[1] 
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
-- 
Didi
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Network redundancy with Manual balancing per VLAN

2016-06-26 Thread Yevgeny Zaspitsky 
Dan, Edy,

Could you guys answer this?

IIUC, the requirements are:

   - stream the traffic of few VLANs(network roles) through a single bond
   - be able to bind a VLAN to a bond slave with an option of fallback
   - have redundancy
   - assign different QoS to every VLAN (my addition)

I guess this is a new RFC that we do not support currently, but would we be
able to provide in any future?

-- Forwarded message --
From: Fernando Frediani 
Date: Sat, Jun 25, 2016 at 11:17 PM
Subject: [ovirt-users] Network redundancy with Manual balancing per VLAN
To: users@ovirt.org


Hello,

In VMware it is possible to bond two network interfaces and for each
Portgroup (equivalent to a VLAN) is possible to tell which of the physical
interfaces underneath it you wish the traffic to flow primarily and which
stays as secondary(bond mode=1 equivalent). So for certain VLANs
(Management, Live Migration, etc) is possible to force traffic flow via one
physical NIC of the bond and for other VLANs (Virtual Machine's traffic)
outs via the other NIC with failover to each other should a cable or switch
fails.

This is specially good for better utilize the fewer NICs available and
still have redundancy.

In oVirt it is also possible to have bonds, but would it still be possible
to do that same and favor the traffic per VLAN basis ? I guess it is
something related to Linux Bond module but perhaps someone has done this
already.

Thanks

Fernando

___
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] Network Interface order changed after reboot

2016-06-26 Thread ovirt 

Hi Yevgeny,

this are real machines.

Best regards
Christoph

Am 26.06.2016 um 14:15 schrieb Yevgeny Zaspitsky:

Christoph,

Are those nodes bare-metal or they're VMs?

Regards,
Yevgeny

On Thu, Jun 23, 2016 at 3:49 PM, > wrote:


Hi List,

I have two nodes (running CentOS 7) and the network interface
order changed for some interfaces after every reboot.

The configurations are done through the oVirt GUI. So the
ifcfg-ethX scripts are configured automatically by VDSM.

Is there any option to get this configured to be stable?

Best regards and thank you

Christoph

___
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] Network Interface order changed after reboot

2016-06-26 Thread ovirt 

Hi,

I'm using currently the following:

But the problem is not new.

ovirt-engine.noarch   3.6.6.2-1.el7.centos @ovirt-3.6

vdsm.noarch   4.17.28-1.el7 @centos-ovirt36

Best regards

Christoph


Am 26.06.2016 um 14:19 schrieb Yevgeny Zaspitsky:

BTW, what oVirt (vdsm&engine) version do you use?

On Sun, Jun 26, 2016 at 3:15 PM, Yevgeny Zaspitsky 
mailto:yzasp...@redhat.com>> wrote:


Christoph,

Are those nodes bare-metal or they're VMs?

Regards,
Yevgeny

On Thu, Jun 23, 2016 at 3:49 PM, mailto:ov...@timmi.org>> wrote:

Hi List,

I have two nodes (running CentOS 7) and the network interface
order changed for some interfaces after every reboot.

The configurations are done through the oVirt GUI. So the
ifcfg-ethX scripts are configured automatically by VDSM.

Is there any option to get this configured to be stable?

Best regards and thank you

Christoph

___
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] Network Interface order changed after reboot

2016-06-26 Thread ovirt 

Hi Edy,

please find some config files below. I did the interface config only 
through the oVirt GUI.


I mean by reordering that after every reboot some interfaces are not the 
same as before. That means I need to change the cables after reboot.


[root@lxedna ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
# Generated by VDSM version 4.17.28-1.el7
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
MTU=1500
DEFROUTE=yes
NM_CONTROLLED=no
IPV6INIT=no
[root@lxedna ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1
# Generated by VDSM version 4.17.23-0.el7.centos
DEVICE=eth1
BRIDGE=Test-LAN-SW1
ONBOOT=yes
MTU=1500
NM_CONTROLLED=no
IPV6INIT=no
[root@lxedna ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth2
# Generated by VDSM version 4.17.23-0.el7.centos
DEVICE=eth2
BRIDGE=PC-LAN
ONBOOT=yes
MTU=1500
NM_CONTROLLED=no
IPV6INIT=no

Best regards
Christoph

Am 26.06.2016 um 14:51 schrieb Edward Haas:



On Thu, Jun 23, 2016 at 3:49 PM, > wrote:


Hi List,

I have two nodes (running CentOS 7) and the network interface
order changed for some interfaces after every reboot.

The configurations are done through the oVirt GUI. So the
ifcfg-ethX scripts are configured automatically by VDSM.

Is there any option to get this configured to be stable?

Best regards and thank you

Christoph

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


Hi Christoph,

VDSM indeed edits and takes ownership of the interfaces for the 
networks it manages.
However, editing the ifcfg files should not change anything in the 
order of the devices, unless it was originally set
in an unsupported fashion. An ifcfg file is bound to a specific device 
name and I'm not familiar to device names

floating around randomly.
Perhaps you should elaborate more on what it means by 'order changed'.

Here is an example of a setup we do not support (pre adding the host 
to Engine):

The initial ifcfg file name: ifcfg-eth0
The initial ifcfg file content: DEVICE="eth1"
In this configuration, the name of the ifcfg file is inconsistent with 
the name of the device it represents.

VDSM expects them to me in sync.

Please provide the ifcfg files before and after you add the host to 
Engine.


Thanks,
Edy.



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

Re: [ovirt-users] oVirt 3.6 to 4.0 Upgrade

2016-06-26 Thread Christophe TREFOIS 
Hi,

 

For CentOS 7, I set the host in global maintenance, and then upgrade the engine.

 

After that, reboot cleanly the engine and set the maintenance back to none.

 

Then you should update the host itself. To do that, you are strongly advised to 
shutdown the VMs first.

If sanlock or vdsm get upgraded in the process, all your VMs will be terminated 
anyway, and this oculd lead to bad results.

 

So if you don’t have another host, shutdown everything except engine, set to 
maintenance global, update engine, reboot engine, shutdown engine, update host, 
and then set maintenance back to none.

 

Does that make sense?

 

From: users-boun...@ovirt.org [mailto:users-boun...@ovirt.org] On Behalf Of 
Yaniv Dary
Sent: dimanche 26 juin 2016 14:43
To: biholc...@l1049h.com
Cc: users 
Subject: Re: [ovirt-users] oVirt 3.6 to 4.0 Upgrade

 

What OS are you running the engine on?




Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109
 
Tel : +972 (9) 7692306
8272306
Email: yd...@redhat.com  
IRC : ydary

 

On Sun, Jun 26, 2016 at 7:54 AM, Brett I. Holcomb mailto:biholc...@l1049h.com> > wrote:

In order to not hijack another thread I wanted to separate this from the 
"latest CentOS libvirt updates safe?" thread since this is different than what 
the OP on that thread wants to do.

I've been digging through the 4.0 documentation since I'd like to upgrade in 
the not to distant future so I'm doing research and I'm confused.

I'm running 3.6.6 in a hosted Engine environment.  My engine runs in a vm on 
the host.  The host is a physical box and the VMs are stored on a NAS accessed 
by an iSCSI LUN,  I have no other hosts running so I can not migrate.

According to this link, https://www.ovirt.org/release/4.0.0/, I'm told to 
simply run yum update ovirt-engine-setup and then engine-setup but I assume 
that's for a non hosted-engine environment.  I then go to the link for 
Hosted_Engine_HOwto#Upgrade_Hosted_Engine guide and am told to do this.

Set hosted-engine maintenance mode to global and other stuff that is written 
assuming I have some place to migrate my VMs to.  I do not have another host.

So how do I properly move to oVirt 4.0 from 3.6.6 on a single physical host 
running a hosted Engine VM?

Thanks.



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

 



smime.p7s
Description: S/MIME cryptographic signature
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Network Interface order changed after reboot

2016-06-26 Thread Edward Haas 
On Sun, Jun 26, 2016 at 4:48 PM,  wrote:

> Hi Edy,
>
> please find some config files below. I did the interface config only
> through the oVirt GUI.
>
> I mean by reordering that after every reboot some interfaces are not the
> same as before. That means I need to change the cables after reboot.
>

This sounds like the problem Didi referenced to.

Before you configured the interfaces through oVirt, wasn't there any ifcfg
files?
(just to understand why you have not seen this before, without vdsm on the
host)


>
> [root@lxedna ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
> # Generated by VDSM version 4.17.28-1.el7
> DEVICE=eth0
> ONBOOT=yes
> BOOTPROTO=dhcp
> MTU=1500
> DEFROUTE=yes
> NM_CONTROLLED=no
> IPV6INIT=no
> [root@lxedna ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1
> # Generated by VDSM version 4.17.23-0.el7.centos
> DEVICE=eth1
> BRIDGE=Test-LAN-SW1
> ONBOOT=yes
> MTU=1500
> NM_CONTROLLED=no
> IPV6INIT=no
> [root@lxedna ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth2
> # Generated by VDSM version 4.17.23-0.el7.centos
> DEVICE=eth2
> BRIDGE=PC-LAN
> ONBOOT=yes
> MTU=1500
> NM_CONTROLLED=no
> IPV6INIT=no
>
> Best regards
> Christoph
>
>
> Am 26.06.2016 um 14:51 schrieb Edward Haas:
>
>
>
> On Thu, Jun 23, 2016 at 3:49 PM,  wrote:
>
>> Hi List,
>>
>> I have two nodes (running CentOS 7) and the network interface order
>> changed for some interfaces after every reboot.
>>
>> The configurations are done through the oVirt GUI. So the ifcfg-ethX
>> scripts are configured automatically by VDSM.
>>
>> Is there any option to get this configured to be stable?
>>
>> Best regards and thank you
>>
>> Christoph
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>
> Hi Christoph,
>
> VDSM indeed edits and takes ownership of the interfaces for the networks
> it manages.
> However, editing the ifcfg files should not change anything in the order
> of the devices, unless it was originally set
> in an unsupported fashion. An ifcfg file is bound to a specific device
> name and I'm not familiar to device names
> floating around randomly.
> Perhaps you should elaborate more on what it means by 'order changed'.
>
> Here is an example of a setup we do not support (pre adding the host to
> Engine):
> The initial ifcfg file name: ifcfg-eth0
> The initial ifcfg file content: DEVICE="eth1"
> In this configuration, the name of the ifcfg file is inconsistent with the
> name of the device it represents.
> VDSM expects them to me in sync.
>
> Please provide the ifcfg files before and after you add the host to Engine.
>
> Thanks,
> Edy.
>
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Maintenance and hosted engine issue with Ovirt 4.0

2016-06-26 Thread Bertrand Caplet 
Hi there,
I have hosted engine configured in my infrastructure and I just upgraded
from Ovirt 3.6 to Ovirt 4.0 yesterday.

Upgrade of hosted engine and my 2 nodes did ok. But now when I put one
node in maintenance, it prepares for maintenance ; unset SPM if it was
then migrate all the VMs to the another node. All of this steps are ok
but VM stays locked and in migration mode like this :
. Btw for the hosted engine I did migrate it manually.

So all the others VMs are stuck locked and in migration mode.
I did noticed every 10 minutes or so (pretty random), the
ovirt-hosted-engine HA is sending mail in this order :

 1. EngineUnexpectedlyDown
 2. (StartState-ReinitializeFSM sometimes)
 3. EngineDown-EngineStart
 4. EngineStart-EngineStarting
 5. EngineStarting-EngineUnexpectedlyDown
 6. Repeat

The hosted engine is pingable all this long, the web UI is reacheable
all this long too.

Anyone having this type of issues ? Do I open a bug on BugZilla ?
Thanks in advance,
Regards,

-- 
CHUNKZ.NET - script kiddie and computer technician
Bertrand Caplet, Flers (FR)
Feel free to send encrypted/signed messages
Key ID: 6E494EB9
GPG FP: CB1B 664A 9165 98F8 459F 0807 CA35 B76F 6E49 4EB9



signature.asc
Description: OpenPGP digital signature
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Create a Virtual Disk failed

2016-06-26 Thread Dewey Du 
the content attached above is ui.log, and there is no logs in server.log
and engine.log.

I'm using oVirt 3.6. Finally I found out I can create the disk from the
edit page of the vm.

On Sun, Jun 26, 2016 at 8:40 PM, Yaniv Dary  wrote:

> Adding Tal.
> What version are you using? Can you attach logs?
>
> Yaniv Dary
> Technical Product Manager
> Red Hat Israel Ltd.
> 34 Jerusalem Road
> Building A, 4th floor
> Ra'anana, Israel 4350109
>
> Tel : +972 (9) 7692306
> 8272306
> Email: yd...@redhat.com
> IRC : ydary
>
>
> On Sat, Jun 25, 2016 at 12:26 PM, Dewey Du  wrote:
>
>> I use glusterfs as storage. When I tried to create a virtual disk for a
>> vm, I got the following error in UI logs.
>>
>> ERROR [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService]
>> (default task-48) [] Permutation name: B003B5EDCB6FC4308644D5D001F65B4C
>> ERROR [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService]
>> (default task-48) [] Uncaught exception: :
>> com.google.gwt.core.client.JavaScriptException: (TypeError)
>>  __gwt$exception: : a is undefined
>> at Unknown._kj(Unknown Source)
>> at Unknown.JUq(Unknown Source)
>> at Unknown.Fbr(Unknown Source)
>> at Unknown.Hno(Unknown Source)
>> at Unknown.t0n(Unknown Source)
>> at Unknown.w0n(Unknown Source)
>> at Unknown.q3n(Unknown Source)
>> at Unknown.t3n(Unknown Source)
>> at Unknown.S2n(Unknown Source)
>> at Unknown.V2n(Unknown Source)
>> at Unknown.bMe(Unknown Source)
>> at Unknown.V7(Unknown Source)
>> at Unknown.k8(Unknown Source)
>> at Unknown.czf/c.onreadystatechange<(Unknown Source)
>> at Unknown.Ux(Unknown Source)
>> at Unknown.Yx(Unknown Source)
>> at Unknown.Xx/<(Unknown Source)
>> at Unknown.anonymous(Unknown Source)
>>
>>
>> ___
>> 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] Network Interface order changed after reboot

2016-06-26 Thread ovirt 
No I just eth0 was configured during OS installation. All other 
interface have been configured through the oVirt GUI.


Best regards
Christoph

Am 26.06.2016 um 16:08 schrieb Edward Haas:




On Sun, Jun 26, 2016 at 4:48 PM, > wrote:


Hi Edy,

please find some config files below. I did the interface config
only through the oVirt GUI.

I mean by reordering that after every reboot some interfaces are
not the same as before. That means I need to change the cables
after reboot.


This sounds like the problem Didi referenced to.

Before you configured the interfaces through oVirt, wasn't there any 
ifcfg files?
(just to understand why you have not seen this before, without vdsm on 
the host)



[root@lxedna ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
# Generated by VDSM version 4.17.28-1.el7
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
MTU=1500
DEFROUTE=yes
NM_CONTROLLED=no
IPV6INIT=no
[root@lxedna ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1
# Generated by VDSM version 4.17.23-0.el7.centos
DEVICE=eth1
BRIDGE=Test-LAN-SW1
ONBOOT=yes
MTU=1500
NM_CONTROLLED=no
IPV6INIT=no
[root@lxedna ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth2
# Generated by VDSM version 4.17.23-0.el7.centos
DEVICE=eth2
BRIDGE=PC-LAN
ONBOOT=yes
MTU=1500
NM_CONTROLLED=no
IPV6INIT=no

Best regards
Christoph


Am 26.06.2016 um 14:51 schrieb Edward Haas:



On Thu, Jun 23, 2016 at 3:49 PM, mailto:ov...@timmi.org>> wrote:

Hi List,

I have two nodes (running CentOS 7) and the network interface
order changed for some interfaces after every reboot.

The configurations are done through the oVirt GUI. So the
ifcfg-ethX scripts are configured automatically by VDSM.

Is there any option to get this configured to be stable?

Best regards and thank you

Christoph

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


Hi Christoph,

VDSM indeed edits and takes ownership of the interfaces for the
networks it manages.
However, editing the ifcfg files should not change anything in
the order of the devices, unless it was originally set
in an unsupported fashion. An ifcfg file is bound to a specific
device name and I'm not familiar to device names
floating around randomly.
Perhaps you should elaborate more on what it means by 'order
changed'.

Here is an example of a setup we do not support (pre adding the
host to Engine):
The initial ifcfg file name: ifcfg-eth0
The initial ifcfg file content: DEVICE="eth1"
In this configuration, the name of the ifcfg file is inconsistent
with the name of the device it represents.
VDSM expects them to me in sync.

Please provide the ifcfg files before and after you add the host
to Engine.

Thanks,
Edy.






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

Re: [ovirt-users] Maintenance and hosted engine issue with Ovirt 4.0

2016-06-26 Thread Yaniv Dary 
Please open bug with logs.

Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109

Tel : +972 (9) 7692306
8272306
Email: yd...@redhat.com
IRC : ydary


On Sun, Jun 26, 2016 at 6:17 PM, Bertrand Caplet  wrote:

> Hi there,
> I have hosted engine configured in my infrastructure and I just upgraded
> from Ovirt 3.6 to Ovirt 4.0 yesterday.
>
> Upgrade of hosted engine and my 2 nodes did ok. But now when I put one
> node in maintenance, it prepares for maintenance ; unset SPM if it was then
> migrate all the VMs to the another node. All of this steps are ok but VM
> stays locked and in migration mode like this :
> . Btw for the hosted engine I did migrate it manually.
>
> So all the others VMs are stuck locked and in migration mode.
> I did noticed every 10 minutes or so (pretty random), the
> ovirt-hosted-engine HA is sending mail in this order :
>
>1. EngineUnexpectedlyDown
>2. (StartState-ReinitializeFSM sometimes)
>3. EngineDown-EngineStart
>4. EngineStart-EngineStarting
>5. EngineStarting-EngineUnexpectedlyDown
>6. Repeat
>
> The hosted engine is pingable all this long, the web UI is reacheable all
> this long too.
>
> Anyone having this type of issues ? Do I open a bug on BugZilla ?
> Thanks in advance,
> Regards,
>
> -- CHUNKZ.NET - script kiddie and computer technician
> Bertrand Caplet, Flers (FR)
> Feel free to send encrypted/signed messages
> Key ID: 6E494EB9
> GPG FP: CB1B 664A 9165 98F8 459F 0807 CA35 B76F 6E49 4EB9
>
>
> ___
> 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 and Ceph

2016-06-26 Thread Kevin Hrpcek 
Hello Charles,

The solution I came up with to solve this problem was to use RDO. I have
oVirt engine running on dedicated hardware. The best way to have oVirt
engine and RDO running on the same hardware is to build a VM on the same
hardware as the engine with virt manager or virsh using the local disk as
storage (you could possibly replace the VM with docker but I never explored
that option). I found it necessary to do this because the oVirt engine and
RDO http configs didn't play well together. They could probably be made to
work on the same OS instance, but it was taking much more time than I
wanted to figure out how to make httpd work with both. Once the VM is up
and running I set up the RDO repos on it and installed packstack. Use
packstack to generate an answers file, then go through the answers file and
set it up so that it only installs Cinder, Keystone, MariaDB, and RabbitMQ.
These are the only necessary pieces of openstack for cinder to work
correctly. Once it is installed you need to configure cinder and keystone
how you want since they only come with the admin tenant,user,project,etc...
I set up a ovirt user,tenant,project and configured cinder to use my ceph
cluster/pool.

It is much simpler to do than that long paragraph may make it seem at
first. I've also tested using CephFS as a POSIX storage domain in oVirt. It
works but in my experience there was at least a 25% performance decrease
over Cinder/RBD.

Kevin

On Fri, Jun 24, 2016 at 3:23 PM, Charles Gomes 
wrote:

> Hello
>
>
>
> I’ve been reading lots of material about implementing oVirt with Ceph,
> however all talk about using Cinder.
>
> Is there a way to get oVirt with Ceph without having to implement entire
> Openstack ?
>
> I’m already currently using Foreman to deploy Ceph and KVM nodes, trying
> to minimize the amount of moving parts. I heard something about oVirt
> providing a managed Cinder appliance, have any seen this ?
>
>
>
> ___
> 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 to 4.0 Upgrade

2016-06-26 Thread Brett I. Holcomb 

Centos 7.2



On 06/26/2016 08:43 AM, Yaniv Dary wrote:

What OS are you running the engine on?

Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem 
Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 
7692306 8272306 Email: yd...@redhat.com  IRC 
: ydary


On Sun, Jun 26, 2016 at 7:54 AM, Brett I. Holcomb 
mailto:biholc...@l1049h.com>> wrote:


In order to not hijack another thread I wanted to separate this
from the "latest CentOS libvirt updates safe?" thread since this
is different than what the OP on that thread wants to do.

I've been digging through the 4.0 documentation since I'd like to
upgrade in the not to distant future so I'm doing research and I'm
confused.

I'm running 3.6.6 in a hosted Engine environment.  My engine runs
in a vm on the host.  The host is a physical box and the VMs are
stored on a NAS accessed by an iSCSI LUN,  I have no other hosts
running so I can not migrate.

According to this link, https://www.ovirt.org/release/4.0.0/, I'm
told to simply run yum update ovirt-engine-setup and then
engine-setup but I assume that's for a non hosted-engine
environment.  I then go to the link for
Hosted_Engine_HOwto#Upgrade_Hosted_Engine guide and am told to do
this.

Set hosted-engine maintenance mode to global and other stuff that
is written assuming I have some place to migrate my VMs to.  I do
not have another host.

So how do I properly move to oVirt 4.0 from 3.6.6 on a single
physical host running a hosted Engine VM?

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

Re: [ovirt-users] 3.6 to 4.0 upgrade cert issue

2016-06-26 Thread Matt Haught 
On Fri, Jun 24, 2016 at 2:58 PM, Martin Perina  wrote:
>
>
> This is not a correct solution although it's working for now. Correct steps 
> are described at [1].
>
> Thanks
>
> Martin Perina
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1336838
>

So I followed the bug report and put my CA cert into
/etc/pki/ca-trust/source/anchors/ and ran update-ca-trust. I created a
/etc/ovirt-engine/engine.conf.d/99-custom-truststore.conf as shown,
but after restarting ovirt-engine I got

Keystore was tampered with, or password was incorrect

when trying to log in. So I ended up doing a

 keytool -storepasswd -keystore  /etc/pki/ca-trust/extracted/java/cacerts

using "changeit" and set a password and put that in
99-custom-truststore.conf . Things appear to be working now.

Thanks,

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

Re: [ovirt-users] oVirt 3.6 to 4.0 Upgrade

2016-06-26 Thread Brett I. Holcomb 

Yes, that makes sense.  Thanks.



On 06/26/2016 10:00 AM, Christophe TREFOIS wrote:


Hi,

For CentOS 7, I set the host in global maintenance, and then upgrade 
the engine.


After that, reboot cleanly the engine and set the maintenance back to 
none.


Then you should update the host itself. To do that, you are strongly 
advised to shutdown the VMs first.


If sanlock or vdsm get upgraded in the process, all your VMs will be 
terminated anyway, and this oculd lead to bad results.


So if you don’t have another host, shutdown everything except engine, 
set to maintenance global, update engine, reboot engine, shutdown 
engine, update host, and then set maintenance back to none.


Does that make sense?

*From:*users-boun...@ovirt.org [mailto:users-boun...@ovirt.org] *On 
Behalf Of *Yaniv Dary

*Sent:* dimanche 26 juin 2016 14:43
*To:* biholc...@l1049h.com
*Cc:* users 
*Subject:* Re: [ovirt-users] oVirt 3.6 to 4.0 Upgrade

What OS are you running the engine on?


Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109
Tel : +972 (9) 7692306
8272306
Email: yd...@redhat.com 
IRC : ydary

On Sun, Jun 26, 2016 at 7:54 AM, Brett I. Holcomb 
mailto:biholc...@l1049h.com>> wrote:


In order to not hijack another thread I wanted to separate this
from the "latest CentOS libvirt updates safe?" thread since this
is different than what the OP on that thread wants to do.

I've been digging through the 4.0 documentation since I'd like to
upgrade in the not to distant future so I'm doing research and I'm
confused.

I'm running 3.6.6 in a hosted Engine environment.  My engine runs
in a vm on the host.  The host is a physical box and the VMs are
stored on a NAS accessed by an iSCSI LUN,  I have no other hosts
running so I can not migrate.

According to this link, https://www.ovirt.org/release/4.0.0/, I'm
told to simply run yum update ovirt-engine-setup and then
engine-setup but I assume that's for a non hosted-engine
environment.  I then go to the link for
Hosted_Engine_HOwto#Upgrade_Hosted_Engine guide and am told to do
this.

Set hosted-engine maintenance mode to global and other stuff that
is written assuming I have some place to migrate my VMs to.  I do
not have another host.

So how do I properly move to oVirt 4.0 from 3.6.6 on a single
physical host running a hosted Engine VM?

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

Re: [ovirt-users] vm pauses with "vm has paused due to unknown storage error

2016-06-26 Thread Krutika Dhananjay 
Hi Bill,

After glusterfs 3.7.11, around 4-5 bugs were found in sharding and
replicate modules and fixed, some of them causing the VM(s) to pause. Could
you share the glusterfs client logs from around the time the issue was
seen? This will help me confirm it's the same issue, or even debug further
if this is a new issue.

-Krutika

On Fri, Jun 24, 2016 at 10:02 AM, Sahina Bose  wrote:

> Can you post the gluster mount logs from the node where paused VM was
> running (under
> /var/log/glusterfs/rhev-datarhev-data-center-mnt-glusterSD.log)
> ?
> Which version of glusterfs are you running?
>
>
> On 06/24/2016 07:49 AM, Bill Bill wrote:
>
> Hello,
>
>
>
> Have 3 nodes running both oVirt and Gluster on 4 SSD’s each. At the
> moment, there are two physical nics, one has public internet access and the
> other is a non-routable network used for ovirtmgmt & gluster.
>
>
>
> In the logical networks, I have selected gluster for the nonroutable
> network running ovirtmgmt and gluster however, two VM’s randomly pause for
> what seems like no reason. They can both be resumed without issue.
>
>
>
> One test VM has 4GB of memory and a small disk – no problems with this
> one. Two others have 800GB disks and 32GB of RAM – both vm’s exhibit the
> same issue.
>
>
>
> I also see these in the oVirt dashboard:
>
>
>
>
>
> Failed to update OVF disks 9e60328d-29af-4533-84f9-633d87f548a7, OVF data
> isn't updated on those OVF stores (Data Center x, Storage Domain
> sr-volume01).
>
>
>
> Jun 23, 2016 9:54:03 PM
>
>
>
> VDSM command failed: Could not acquire resource. Probably resource factory
> threw an exception.: ()
>
>
>
> ///
>
>
>
> VM x has been paused due to unknown storage error.
>
>
>
> ///
>
>
>
> In the error log on the engine, I see these:
>
>
>
> ERROR
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (ForkJoinPool-1-worker-7) [10caf93e] Correlation ID: null, Call Stack:
> null, Custom Event ID: -1, Message: VM xx has been paused due to
> unknown storage error.
>
>
>
> INFO
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (ForkJoinPool-1-worker-11) [10caf93e] Correlation ID: null, Call Stack:
> null, Custom Event ID: -1, Message: VM xx has recovered from paused
> back to up.
>
>
>
> ///
>
>
>
> Hostnames are all local to /etc/hosts on all servers – they also resolve
> without issue from each host.
>
>
>
> //
>
>
>
> 2016-06-23 22:08:59,611 WARN
> [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturnForXmlRpc]
> (DefaultQuartzScheduler_Worker-76) [1c1cf4f] Could not associate brick
> 'ovirt3435:/mnt/data/sr-volume01' of volume
> '93e36cdc-ab1b-41ec-ac7f-966cf3856b59' with correct network as no gluster
> network found in cluster '75bd64de-04b2-4a99-9cd0-b63e919b9aca'
>
> 2016-06-23 22:08:59,614 WARN
> [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturnForXmlRpc]
> (DefaultQuartzScheduler_Worker-76) [1c1cf4f] Could not associate brick
> 'ovirt3637:/mnt/data/sr-volume01' of volume
> '93e36cdc-ab1b-41ec-ac7f-966cf3856b59' with correct network as no gluster
> network found in cluster '75bd64de-04b2-4a99-9cd0-b63e919b9aca'
>
> 2016-06-23 22:08:59,616 WARN
> [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturnForXmlRpc]
> (DefaultQuartzScheduler_Worker-76) [1c1cf4f] Could not associate brick
> 'ovirt3839:/mnt/data/sr-volume01' of volume
> '93e36cdc-ab1b-41ec-ac7f-966cf3856b59' with correct network as no gluster
> network found in cluster '75bd64de-04b2-4a99-9cd0-b63e919b9aca'
>
> 2016-06-23 22:08:59,618 WARN
> [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturnForXmlRpc]
> (DefaultQuartzScheduler_Worker-76) [1c1cf4f] Could not associate brick
> 'ovirt3435:/mnt/data/distributed' of volume
> 'b887b05e-2ea6-496e-9552-155d658eeaa6' with correct network as no gluster
> network found in cluster '75bd64de-04b2-4a99-9cd0-b63e919b9aca'
>
> 2016-06-23 22:08:59,620 WARN
> [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturnForXmlRpc]
> (DefaultQuartzScheduler_Worker-76) [1c1cf4f] Could not associate brick
> 'ovirt3637:/mnt/data/distributed' of volume
> 'b887b05e-2ea6-496e-9552-155d658eeaa6' with correct network as no gluster
> network found in cluster '75bd64de-04b2-4a99-9cd0-b63e919b9aca'
>
> 2016-06-23 22:08:59,622 WARN
> [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturnForXmlRpc]
> (DefaultQuartzScheduler_Worker-76) [1c1cf4f] Could not associate brick
> 'ovirt3839:/mnt/data/distributed' of volume
> 'b887b05e-2ea6-496e-9552-155d658eeaa6' with correct network as no gluster
> network found in cluster '75bd64de-04b2-4a99-9cd0-b63e919b9aca'
>
> 2016-06-23 22:08:59,624 WARN
> [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturnForXmlRpc]
> (DefaultQuartzScheduler_Worker-76) [1c1cf4f] Could not associate brick
> 'ovirt3435:/mnt/data/iso' of volume '89f32457-c8c3-490e-b491-16dd27de0073'
> with correct network as no gluster network found

Re: [ovirt-users] Network redundancy with Manual balancing per VLAN

2016-06-26 Thread Edward Haas 
On Sun, Jun 26, 2016 at 4:37 PM, Yevgeny Zaspitsky 
wrote:

> Dan, Edy,
>
> Could you guys answer this?
>
> IIUC, the requirements are:
>
>- stream the traffic of few VLANs(network roles) through a single bond
>- be able to bind a VLAN to a bond slave with an option of fallback
>- have redundancy
>- assign different QoS to every VLAN (my addition)
>
> I guess this is a new RFC that we do not support currently, but would we
> be able to provide in any future?
>
> -- Forwarded message --
> From: Fernando Frediani 
> Date: Sat, Jun 25, 2016 at 11:17 PM
> Subject: [ovirt-users] Network redundancy with Manual balancing per VLAN
> To: users@ovirt.org
>
>
> Hello,
>
> In VMware it is possible to bond two network interfaces and for each
> Portgroup (equivalent to a VLAN) is possible to tell which of the physical
> interfaces underneath it you wish the traffic to flow primarily and which
> stays as secondary(bond mode=1 equivalent). So for certain VLANs
> (Management, Live Migration, etc) is possible to force traffic flow via one
> physical NIC of the bond and for other VLANs (Virtual Machine's traffic)
> outs via the other NIC with failover to each other should a cable or switch
> fails.
>
> This is specially good for better utilize the fewer NICs available and
> still have redundancy.
>
> In oVirt it is also possible to have bonds, but would it still be possible
> to do that same and favor the traffic per VLAN basis ? I guess it is
> something related to Linux Bond module but perhaps someone has done this
> already.
>
>


> Thanks
>
> Fernando
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
Hello Fernando,

As you mentioned, oVirt is using the Linux Bond and the solution you are
looking for is not supported.
The oVirt way to handle this is by applying QoS on the networks, providing
the guaranteed rates for each and utilizing the bond for throughput beyond
the one link limit.

With the introduction of OVS as an alternative networking infrastructure
for the hosts, you could create a hook that implements some special
functionality, but ovs is not in yet.

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

Re: [ovirt-users] InClusterUpgrade Scheduling Policy

2016-06-26 Thread Roman Mohr 
On Fri, Jun 24, 2016 at 6:34 PM, Scott  wrote:
> Actually, I figured out a work around. I changed the HostedEngine VM's
> vds_group_id in the database to the vds_group_id of my temporary cluster
> (found from the vds_groups table). This worked and I could put my main
> cluster in upgrade mode. Now to continue the process...
>
That's exactly what I had in mind.  I hope you made it  through the
whole process.

Roman

> Thanks,
> Scott
>
>
> On Fri, Jun 24, 2016, 9:29 AM Scott  wrote:
>>
>> Hi Roman,
>>
>> I made it through step 6 however it does look like the problem you
>> mentioned has occurred.  My engine VM is running on my host in the temporary
>> cluster.  The stats under Hosts show this.  But in the Virtual Machines tab
>> this VM still thinks its on my main cluster and I can't change that setting.
>> Did you have a suggestion on how to work around this?  Thankfully only one
>> of my RHEV instances has this upgrade path.
>>
>> Thanks for your help,
>> Scott
>>
>> On Fri, Jun 24, 2016 at 2:15 AM Roman Mohr  wrote:
>>>
>>> On Thu, Jun 23, 2016 at 10:26 PM, Scott  wrote:
>>> > Hi Roman,
>>> >
>>> > Thanks for the detailed steps.  I follow the idea you have outlined and
>>> > I
>>> > think its easier than what I thought of (moving my self hosted engine
>>> > back
>>> > to physical hardware, upgrading and moving it back to self hosted).  I
>>> > will
>>> > give it a spin in my build RHEV cluster tomorrow and let you know how I
>>> > get
>>> > on.
>>> >
>>>
>>> Thanks.
>>>
>>> The bug is here: https://bugzilla.redhat.com/show_bug.cgi?id=1349745.
>>>
>>> I thought about the solution and I see one possible problem with this
>>> approach. It might be that the engine still thinks that the VM is on
>>> the old cluster.
>>> Let me know if this happens, we can work around that too.
>>>
>>> Roman
>>>
>>> > Thanks again,
>>> > Scott
>>> >
>>> > On Thu, Jun 23, 2016 at 2:41 PM Roman Mohr  wrote:
>>> >>
>>> >> Hi Scott,
>>> >>
>>> >> On Thu, Jun 23, 2016 at 8:54 PM, Scott  wrote:
>>> >> > Hello list,
>>> >> >
>>> >> > I'm trying to upgrade a self-hosted engine RHEV environment running
>>> >> > 3.5/el6
>>> >> > to 3.6/el7.  I'm following the process outlined in these two
>>> >> > documents:
>>> >> >
>>> >> >
>>> >> >
>>> >> > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6/html/Self-Hosted_Engine_Guide/Upgrading_the_Self-Hosted_Engine_from_6_to_7.html
>>> >> > https://access.redhat.com/solutions/2300331
>>> >> >
>>> >> > The problem I'm having is I don't seem to be able to apply the
>>> >> > "InClusterUpgrade" policy (procedure 5.5, step 4).  I get the
>>> >> > following
>>> >> > error:
>>> >> >
>>> >> > Can not start cluster upgrade mode, see below for details:
>>> >> > VM HostedEngine with id 5ca9cb38-82e5-4eea-8ff6-e2bc33598211 is
>>> >> > configured
>>> >> > to be not migratable.
>>> >> >
>>> >> That is correct, only the he-agents on each host decide where the
>>> >> hosted engine VM can start
>>> >>
>>> >> > But the HostedEngine VM is not one I can edit due to being
>>> >> > mid-upgrade.
>>> >> > And
>>> >> > even if I could, the setting its complaining about can't be managed
>>> >> > by
>>> >> > the
>>> >> > engine (I tried in another RHEV instance).
>>> >> >
>>> >> Also true, it is very limited what you can currently do with the
>>> >> hosted engine VM.
>>> >>
>>> >>
>>> >> > Is this a bug?  What am I missing to be able to move on?  As it
>>> >> > seems
>>> >> > now,
>>> >> > the InClusterUpgrade scheduling policy is useless and can't actually
>>> >> > be
>>> >> > used.
>>> >>
>>> >> That is indeed something the InClusterUpgrade does not take into
>>> >> consideration. I will file a bug report.
>>> >>
>>> >>  But what you can do is the following:
>>> >>
>>> >> You can create a temporary cluster, move one host and the hosted
>>> >> engine VM there, upgrade all hosts and then start the hosted-engine VM
>>> >> in the original cluster again.
>>> >>
>>> >> The detailed steps are:
>>> >>
>>> >> 1) Enter the global maintenance mode
>>> >> 2) Create a temporary cluster
>>> >> 3) Put one of the hosted engine hosts which does not currently host
>>> >> the engine into maintenance
>>> >> 4) Move this host to the temporary cluster
>>> >> 5) Stop the hosted-engine-vm with `hosted-engine --destroy-vm` (it
>>> >> should not come up again since you are in maintenance mode)
>>> >> 6) Start the hosted-egine-vm with `hosted-engine --start-vm` on the
>>> >> host in the temporary cluster
>>> >> 7) Now you can enable the InClusterUpgrade policy on your main cluster
>>> >> 7) Proceed with your main cluster like described in
>>> >>
>>> >>
>>> >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6/html/Self-Hosted_Engine_Guide/Upgrading_the_Self-Hosted_Engine_from_6_to_7.html
>>> >> 8) When all hosts are upgraded and InClusterUpgrade policy is disabled
>>> >> again, move the hosted-engine-vm back to the original cluster
>>> >> 9) Upgrade the last host
>>> >> 10) Migrate

Re: [ovirt-users] Network Interface order changed after reboot

2016-06-26 Thread Dan Kenigsberg 
On Sun, Jun 26, 2016 at 03:59:31PM +0300, Yedidyah Bar David wrote:
> On Sun, Jun 26, 2016 at 3:51 PM, Edward Haas  wrote:
> >
> >
> > On Thu, Jun 23, 2016 at 3:49 PM,  wrote:
> >>
> >> Hi List,
> >>
> >> I have two nodes (running CentOS 7) and the network interface order
> >> changed for some interfaces after every reboot.
> >>
> >> The configurations are done through the oVirt GUI. So the ifcfg-ethX
> >> scripts are configured automatically by VDSM.
> >>
> >> Is there any option to get this configured to be stable?
> >>
> >> Best regards and thank you
> >>
> >> Christoph
> >>
> >> ___
> >> Users mailing list
> >> Users@ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/users
> >
> >
> > Hi Christoph,
> >
> > VDSM indeed edits and takes ownership of the interfaces for the networks it
> > manages.
> > However, editing the ifcfg files should not change anything in the order of
> > the devices, unless it was originally set
> > in an unsupported fashion. An ifcfg file is bound to a specific device name
> > and I'm not familiar to device names
> > floating around randomly.
> > Perhaps you should elaborate more on what it means by 'order changed'.
> >
> > Here is an example of a setup we do not support (pre adding the host to
> > Engine):
> > The initial ifcfg file name: ifcfg-eth0
> > The initial ifcfg file content: DEVICE="eth1"
> > In this configuration, the name of the ifcfg file is inconsistent with the
> > name of the device it represents.
> > VDSM expects them to me in sync.
> >
> > Please provide the ifcfg files before and after you add the host to Engine.
> 
> Perhaps Christoph refers to the problem that [1] was meant to solve?
> 
> [1] 
> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

To add on what didi says, this should be the default with el7's systemd.
It is surprising that your nics are named eth*, and not by the
predictable nic name scheme.

Maybe if you share your `lspci -vvv` and /var/log/messages of two
different boots, we can have a hint regarding your instability.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users