Re: [ovirt-users] Unable to set up oVirt 4.0 HE using glusterfs storage

2016-07-02 Thread Kevin Hung
Looks like there still needs to be some work done on oVirt 4.0 Node and 
ovirt-hosted-engine-setup before it's ready for general consumption. I 
have spent days trying to get this to work, and only got it running (on 
one host) after encountering 8 serious issues (7 below and the initial 
glusterfs one). I have not been able to successfully deploy a second 
host (see issue 7 below). I will be moving back to deploying hosts using 
CentOS (with either oVirt 4.0 or oVirt 3.6) as I need a working oVirt 
deployment up and running.

In case anyone is interested in reproducing the issues, I used the Node 
ISO here [1] and the latest (7/2/2016) engine appliance OVA here [2]. 
Those seem to be the "official" files as far as I can tell (which is 
difficult as the documentation is not clear).

List of issues:
1. The error I mentioned seems to be an problem with the code. I 
bypassed it by deleting 
2. ovirt-hosted-engine-setup is unable to connect to the vdsm service if 
the FQDN of the node is not resolvable (i.e. if a DNS server is not 
entered in the initial setup). This should be checked in either the 
initial oVirt Node setup process or the beginning of 
3. The management bridge does not get created properly when the server 
is set up with a manually configured DNS server and running 
NetworkManager (the default on Node). It seems like a bug has been filed 
for this back in 2014. [3]
4. Using cloud-init with default values to customize the engine 
appliance can fail on the line "Creating/refreshing DWH database schema" 
if it takes longer than 600 seconds to return output. This may apply to 
any other step that takes a long time to complete. The VM no longer 
appears to be exist after the setup exits that so I am unable to debug.
5. Without using cloud-init, the setup creates an engine VM that I 
cannot log into (it does not seem to use the engine admin password or a 
blank password).
6. Destroying the VM (option 4) leaves the files intact on the shared 
storage so I cannot restart setup without deleting those first. This may 
be intentional, but the use of kvm terminology (destroy for power off) 
is not common, not to mention that "virsh -r list --all" does not list 
the VM anymore.
7. Unable to deploy second host through web UI (error "Failed to 
configure management network on host node2 due to setup networks 
failure.") or using ovirt-hosted-engine-setup (it looks like it can't 
connect to or doesn't start the broker service).
8. Random errors to stderr: "vcpu0 unhandled rdmsr" (this seems to be an 
upstream bug) and "multipath: error getting device" (this has been an 
issue for years with oVirt and seems to be due to multipathing being on 
by default even for systems where that does not apply).



On 7/1/2016 8:37 PM, Kevin Hung wrote:
It looks like I'm now getting an error when the deployment tries to 
configure the management bridge.

Setup log:

2016-07-01 20:29:47 INFO 

372 Configuring the management bridge
2016-07-01 20:29:48 DEBUG 
:384 networks: {'ovirtmgmt': {'nic': 'eno1', 'ipaddr': 
u'', 'netmask': u'', 'bootproto': u'none', 
'gateway': u'', 'defaultRoute': True}}
2016-07-01 20:29:48 DEBUG 

:385 bonds: {}
2016-07-01 20:29:48 DEBUG 

:386 options: {'connectivityCheck': False}
2016-07-01 20:29:48 DEBUG otopi.context context._executeMethod:142 
method exception

Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/otopi/", line 132, 
in _executeMethod

line 387, in _misc

_setupNetworks(conn, networks, bonds, options)
line 405, in _setupNetworks

'message: "%s"' % (networks, code, message))
RuntimeError: Failed to setup networks {'ovirtmgmt': {'nic': 'eno1', 
'ipaddr': u'', 'netmask': u'', 'bootproto': 
u'none', 'gateway': u'', 'defaultRoute': True}}. Error 
code: "78" message: "Hook error: Hook Error: ('Traceback (most recent 
call last):\n  File 
"/usr/libexec/vdsm/hooks/before_network_setup/50_fcoe", line 18, in 
\nfrom vdsm.netconfpersistence import 
RunningConfig\nImportError: No module named netconfpersistence\n',)"
2016-07-01 20:29:48 ERROR otopi.context context._executeMethod:151 

Re: [ovirt-users] ovirt-shell compatible with version 4?

2016-07-02 Thread Gregor Binder
Hash: SHA256

UPDATE: after deleting ~/.ovirtshellrc a connection to the engine is

- -- 
GPG-Key: 67F1534F

On 02/07/16 22:19, gregor wrote:
> Hi,
> after upgrading to oVirt 4.* the ovirt-shell won't connect.
> That's the installed version: 
> ovirt-engine-cli-
> Should this version work with the latest engine, this came from
> repo ovirt-4.0 ? Can't find ovirt-engine-cli-4.* in the repos.
> cheers gregor ___ Users
> mailing list 
Version: GnuPG v2

Users mailing list

[ovirt-users] ovirt-shell compatible with version 4?

2016-07-02 Thread gregor

after upgrading to oVirt 4.* the ovirt-shell won't connect.

That's the installed version:

Should this version work with the latest engine, this came from repo
ovirt-4.0 ?
Can't find ovirt-engine-cli-4.* in the repos.

Users mailing list

[ovirt-users] Change admin password: new password already used

2016-07-02 Thread gregor

I had to change the admin password, it returns "new password already used".

That's the command I have used: "ovirt-aaa-jdbc-tool user password-reset

Can somebody help?

Users mailing list

Re: [ovirt-users] 3.5 to 3.6 upgrade

2016-07-02 Thread gregor
Can you please add your solution!


On 16/06/16 01:14, Fernando Fuentes wrote:
> I think I fix my own issue.
> TIA! :D
Users mailing list

[ovirt-users] moVirt and spice problem

2016-07-02 Thread Gianluca Cecchi
I'm testing moVirt 1.4 on Samsung Note Pro (Android 5.1) to connect through
spice to a self hosted engine configuration with single host, version
3.6.6, configured with spice proxy (squid)

I can walk through all parts inside the app (always better in new versions,
thanks!) but not the console to vm

mOvirt connection configured as
ignore certificate checking in advanced settings

In mOvirt I receive, after about one minute when I click "Console":

Unable to connect or authenticate, please check server address, password,
and cert authority and subject.

In engine.log, as I click connect to console in mOvirt I see these lines

2016-07-02 19:23:30,868 INFO
[org.ovirt.engine.core.bll.SetVmTicketCommand] (default task-12) [32908848]
Running command: SetVmTicketCommand internal: false. Entities affected :
ID: e9491274-460a-40a1-84bb-503078df9f29 Type: VMAction group CONNECT_TO_VM
with role type USER
2016-07-02 19:23:30,872 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] (default
task-12) [32908848] START, SetVmTicketVDSCommand(HostName =
hosted_engine_1, SetVmTicketVDSCommandParameters:{runAsync='true',
vmId='e9491274-460a-40a1-84bb-503078df9f29', protocol='SPICE',
ticket='X5TDD2OB3FI3', validTime='7200', userName='admin',
disconnectAction='LOCK_SCREEN'}), log id: 507f589b
2016-07-02 19:23:31,891 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] (default
task-12) [32908848] FINISH, SetVmTicketVDSCommand, log id: 507f589b
2016-07-02 19:23:31,902 INFO
(default task-12) [32908848] Correlation ID: 32908848, Call Stack: null,
Custom Event ID: -1, Message: User admin@internal initiated console session
for VM f24

no more

I have verified that through web browser, both in user portal and in admin
portal, the user "admin" can connect to f24 VM and open spice connection
going trough squid proxy.
Actually on squid logs I don't see any access when I use mOvirt, so it
seems it doesn't reach it at all...
Actually I think the problem doesn't depend in squid setting and I would
have the problem also without it. It seems problem between tablet and
engine connection

Is there any particular restriction to be able to use spice console with
mOvirt 1.4? For example am I force to use and trust certificate to use
spice console?

Thanks in advance for any help,
Users mailing list

Re: [ovirt-users] disk not bootable

2016-07-02 Thread Nir Soffer
On Sat, Jul 2, 2016 at 1:33 AM, Fernando Fuentes  wrote:
> Nir,
> Ok I ran another test and this one I moved from NFS domain to iSCSI and
> stop working than I moved it back and still unable to run... Windows VM
> is saying "no available boot disk"
> VM: Win7-Test
> Host: Zeta
> Info as requested:

We need a working xml to compare to.

> Now here is an example of one that I migrated from the NFS domain to the
> iscsi domain and stop working:
> VM: Win7-QA5
> Host: Alpha
> Info as requested:
> The same VM I moved it back to the NFS domain and boot it just fine:
> VM: Win7-QA5
> Host: Zeta
> Info as requested:

Diffing both xmls show:

$ diff -u win-qa5-iscsi.txt win-qa5-nfs.txt
--- win-qa5-iscsi.txt 2016-07-02 12:10:17.094202558 +0300
+++ win-qa5-nfs.txt 2016-07-02 12:11:06.729375231 +0300
@@ -60,13 +60,13 @@

Expected, one vm is using block based disk and the other file based disk


Expected, file and block disks are mounted on different paths


Expected, we use different io for file and block

@@ -78,7 +78,7 @@
  oVirt Node
- C938F077-55E2-3E50-A694-9FCB7661FD89
+ 735C7A01-1F16-3CF0-AF8C-A99823E95AC0

Not expected - maybe this is confusing windows?

Francesco, why vm serial has changed after moving disks from one storage domain
to another?


> --
> Fernando Fuentes
> On Fri, Jul 1, 2016, at 03:22 PM, Nir Soffer wrote:
>> Fernando,
>> These logs do not contain the libvirt xml.
>> I want to see the part that start like this:
>> Thread-17656::INFO::2016-07-01 23:17:33,845::vm::2032::virt.vm::(_run)
>> vmId=`f66da2b0-0f71-490b-a57e-eceb9be9cade`::> encoding="utf-8"?>
>> test-iscsi
>> f66da2b0-0f71-490b-a57e-eceb9be9cade
>> ...
>> The most important part is the devices sections showing the disks:
>> > type="drive" unit="0"/>
>> > dev="/rhev/data-center/f9374c0e-ae24-4bc1-a596-f61d5f05bc5f/5f35b5c0-17d7-4475-9125-e97f1cdb06f9/images/8f61b697-b3e4-4f63-8951-bdf9b6b39192/f409cc48-8248-4239-a4ea-66b0b1084416"/>
>> 8f61b697-b3e4-4f63-8951-bdf9b6b39192
>> > io="native" name="qemu" type="qcow2"/>
>> Please try to find the logs (probably already rotated to vdsm.log.N.xz)
>> containing the xml for this vm when running on nfs and iscsi.
>> Nir
>> On Fri, Jul 1, 2016 at 10:31 PM, Fernando Fuentes 
>> wrote:
>> > Nir.
>> >
>> > Thank you for your reply.
>> >
>> > Attached is the vdsm log of the hosts that power on the vm in this
>> > example.
>> >
>> > VM name is Win7-QA5
>> > vdsm_alpha.log was the host that started the VM when it got transfer to
>> > the iscsi domain.
>> > vdsm_zeta.log was the host that started the VM when it got transfer back
>> > to the nfs domain.
>> >
>> > I included everything for trouble shooting purposes.
>> >
>> > Also here is the engine log that talks about it as well:
>> >
>> >
>> > Hope this helps.
>> >
>> > Regards,
>> > --
>> > Fernando Fuentes
>> >
>> >
>> >
>> > On Fri, Jul 1, 2016, at 01:58 PM, Nir Soffer wrote:
>> >> On Fri, Jul 1, 2016 at 7:58 PM, Fernando Fuentes 
>> >> wrote:
>> >> > Pavel,
>> >> >
>> >> > Thanks for your reply, But thats not the problem
>> >> > The disk is active and is set with to bootable. The problem presents it
>> >> > self only if I move Windows VM DIsks.
>> >> > All my Linux VM Disk's move across storage domains just fine.
>> >> >
>> >> > As a matter of fact I moved the disk back to the original nfs domain and
>> >> > it started working.
>> >> > Could this be a bug?
>> >>
>> >> Can you share the vdsm log showing startup of the vm when the disk is on
>> >> on nfs storage domain (vm starts) and iscsi storage domain (vm fail)?
>> >>
>> >> The most interesting part in the logs is the libvirt xml describing the
>> >> vm.
>> >>
>> >> Nir
>> >>
>> >> > Regards,
>> >> >
>> >> > --
>> >> > Fernando Fuentes
>> >> >
>> >> >
>> >> >
>> >> > On Fri, Jul 1, 2016, at 11:33 AM, Pavel Gashev wrote:
>> >> >> Fernando,
>> >> >>
>> >> >> One from VM disks have to have bootable flag.
>> >> >> See
>> >> >>
>> >> >>
>> >> >> On 01/07/16 19:09, " on behalf of Fernando
>> >> >> Fuentes" 
>> >> >> wrote:
>> >> >>
>> >> >> Team,
>> >> >>
>> >> >> After I successfully copy my template 

[ovirt-users] [ANN] oVirt 3.6 won't receive further updates

2016-07-02 Thread Sandro Bonazzola
due to the release of recent 4.0.0 major release of the oVirt project,
and upcoming release of its first maintenance release 4.0.1,
the last 3.6 release is 3.6.7 we released this week.

We recommend anyone hitting issued existing in 3.6
to upgrade to 4.0 to get the fixes since 3.6 won't receive further updates.


Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at
Users mailing list