[ovirt-users] ha-agent and broker continually crashing after 4.2 update

2018-01-12 Thread Jayme
recently upgraded to 4.2 and had some problems with engine vm running, got
that cleared up now my only remaining issue is that now it seems
ovirt-ha-broker and ovirt-ha-agent are continually crashing on all three of
my hosts.  Everything is up and working fine otherwise, all VMs running and
hosted engine VM is running along with interface etc.

Jan 12 16:52:34 cultivar0 journal: vdsm storage.Dispatcher ERROR FINISH
prepareImage error=Volume does not exist:
(u'8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8',)
Jan 12 16:52:34 cultivar0 python: detected unhandled Python exception in
'/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker'
Jan 12 16:52:34 cultivar0 abrt-server: Not saving repeating crash in
'/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker'
Jan 12 16:52:34 cultivar0 systemd: ovirt-ha-broker.service: main process
exited, code=exited, status=1/FAILURE
Jan 12 16:52:34 cultivar0 systemd: Unit ovirt-ha-broker.service entered
failed state.
Jan 12 16:52:34 cultivar0 systemd: ovirt-ha-broker.service failed.
Jan 12 16:52:34 cultivar0 systemd: ovirt-ha-broker.service holdoff time
over, scheduling restart.
Jan 12 16:52:34 cultivar0 systemd: Cannot add dependency job for unit
lvm2-lvmetad.socket, ignoring: Unit is masked.
Jan 12 16:52:34 cultivar0 systemd: Started oVirt Hosted Engine High
Availability Communications Broker.
Jan 12 16:52:34 cultivar0 systemd: Starting oVirt Hosted Engine High
Availability Communications Broker...
Jan 12 16:52:36 cultivar0 journal: vdsm storage.TaskManager.Task ERROR
(Task='73141dec-9d8f-4164-9c4e-67c43a102eff') Unexpected error#012Traceback
(most recent call last):#012  File
"/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882, in
_run#012return fn(*args, **kargs)#012  File "", line 2, in
prepareImage#012  File
"/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 48, in
method#012ret = func(*args, **kwargs)#012  File
"/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 3162, in
prepareImage#012raise
se.VolumeDoesNotExist(leafUUID)#012VolumeDoesNotExist: Volume does not
exist: (u'8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8',)
Jan 12 16:52:36 cultivar0 journal: vdsm storage.Dispatcher ERROR FINISH
prepareImage error=Volume does not exist:
(u'8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8',)
Jan 12 16:52:36 cultivar0 python: detected unhandled Python exception in
'/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker'
Jan 12 16:52:36 cultivar0 abrt-server: Not saving repeating crash in
'/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker'
Jan 12 16:52:36 cultivar0 systemd: ovirt-ha-broker.service: main process
exited, code=exited, status=1/FAILURE
Jan 12 16:52:36 cultivar0 systemd: Unit ovirt-ha-broker.service entered
failed state.
Jan 12 16:52:36 cultivar0 systemd: ovirt-ha-broker.service failed.

Jan 12 16:52:36 cultivar0 systemd: ovirt-ha-broker.service holdoff time
over, scheduling restart.
Jan 12 16:52:36 cultivar0 systemd: Cannot add dependency job for unit
lvm2-lvmetad.socket, ignoring: Unit is masked.
Jan 12 16:52:36 cultivar0 systemd: Started oVirt Hosted Engine High
Availability Communications Broker.
Jan 12 16:52:36 cultivar0 systemd: Starting oVirt Hosted Engine High
Availability Communications Broker...
Jan 12 16:52:37 cultivar0 journal: vdsm storage.TaskManager.Task ERROR
(Task='bc7af1e2-0ab2-4164-ae88-d2bee03500f9') Unexpected error#012Traceback
(most recent call last):#012  File
"/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882, in
_run#012return fn(*args, **kargs)#012  File "", line 2, in
prepareImage#012  File
"/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 48, in
method#012ret = func(*args, **kwargs)#012  File
"/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 3162, in
prepareImage#012raise
se.VolumeDoesNotExist(leafUUID)#012VolumeDoesNotExist: Volume does not
exist: (u'8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8',)
Jan 12 16:52:37 cultivar0 journal: vdsm storage.Dispatcher ERROR FINISH
prepareImage error=Volume does not exist:
(u'8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8',)
Jan 12 16:52:37 cultivar0 python: detected unhandled Python exception in
'/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker'
Jan 12 16:52:38 cultivar0 abrt-server: Not saving repeating crash in
'/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker'
Jan 12 16:52:38 cultivar0 systemd: ovirt-ha-broker.service: main process
exited, code=exited, status=1/FAILURE
Jan 12 16:52:38 cultivar0 systemd: Unit ovirt-ha-broker.service entered
failed state.
Jan 12 16:52:38 cultivar0 systemd: ovirt-ha-broker.service failed.
Jan 12 16:52:38 cultivar0 systemd: ovirt-ha-broker.service holdoff time
over, scheduling restart.
Jan 12 16:52:38 cultivar0 systemd: Cannot add dependency job for unit
lvm2-lvmetad.socket, ignoring: Unit is masked.
Jan 12 16:52:38 cultivar0 systemd: start request repeated too quickly for
ovirt-ha-broker.service
Jan 12 16:52:38 cultivar0 systemd: Failed to start oVirt Hosted Engine High
Availability Communications Broker.
Jan 12 16:52:38 

Re: [ovirt-users] hosted-engine unknow stale-data

2018-01-12 Thread Artem Tambovskiy
Explored logs on both hosts.
broker.log shows no errors.

agent.log looking not good:

on host1 (which running hosted engine) :

MainThread::ERROR::2018-01-12
21:51:03,883::agent::205::ovirt_hosted_engine_ha.agent.agent.Agent::(_run_agent)
Traceback (most recent call last):
  File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py",
line 191, in _run_agent
return action(he)
  File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py",
line 64, in action_proper
return he.start_monitoring()
  File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py",
line 411, in start_monitoring
self._initialize_sanlock()
  File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py",
line 749, in _initialize_sanlock
"Failed to initialize sanlock, the number of errors has"
SanlockInitializationError: Failed to initialize sanlock, the number of
errors has exceeded the limit

MainThread::ERROR::2018-01-12
21:51:03,884::agent::206::ovirt_hosted_engine_ha.agent.agent.Agent::(_run_agent)
Trying to restart agent
MainThread::WARNING::2018-01-12
21:51:08,889::agent::209::ovirt_hosted_engine_ha.agent.agent.Agent::(_run_agent)
Restarting agent, attempt '1'
MainThread::INFO::2018-01-12
21:51:08,919::hosted_engine::242::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_get_hostname)
Found certificate common name: ovirt1.telia.ru
MainThread::INFO::2018-01-12
21:51:08,921::hosted_engine::604::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_initialize_vdsm)
Initializing VDSM
MainThread::INFO::2018-01-12
21:51:11,398::hosted_engine::630::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_initialize_storage_images)
Connecting the storage
MainThread::INFO::2018-01-12
21:51:11,399::storage_server::220::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(validate_storage_server)
Validating storage server
MainThread::INFO::2018-01-12
21:51:13,725::storage_server::239::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(connect_storage_server)
Connecting storage server
MainThread::INFO::2018-01-12
21:51:18,390::storage_server::246::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(connect_storage_server)
Connecting storage server
MainThread::INFO::2018-01-12
21:51:18,423::storage_server::253::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(connect_storage_server)
Refreshing the storage domain
MainThread::INFO::2018-01-12
21:51:18,689::hosted_engine::663::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_initialize_storage_images)
Preparing images
MainThread::INFO::2018-01-12
21:51:18,690::image::126::ovirt_hosted_engine_ha.lib.image.Image::(prepare_images)
Preparing images
MainThread::INFO::2018-01-12
21:51:21,895::hosted_engine::666::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_initialize_storage_images)
Refreshing vm.conf
MainThread::INFO::2018-01-12
21:51:21,895::config::493::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config::(refresh_vm_conf)
Reloading vm.conf from the shared storage domain
MainThread::INFO::2018-01-12
21:51:21,896::config::416::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config::(_get_vm_conf_content_from_ovf_store)
Trying to get a fresher copy of vm configuration from the OVF_STORE
MainThread::INFO::2018-01-12
21:51:21,896::ovf_store::132::ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(getEngineVMOVF)
Extracting Engine VM OVF from the OVF_STORE
MainThread::INFO::2018-01-12
21:51:21,897::ovf_store::134::ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(getEngineVMOVF)
OVF_STORE volume path:
/var/run/vdsm/storage/4a7f8717-9bb0-4d80-8016-498fa4b88162/5cabd8e1-5f4b-469e-becc-227469e03f5c/8048cbd7-77e2-4805-9af4-d109fa36dfcf
MainThread::INFO::2018-01-12
21:51:21,915::config::435::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config::(_get_vm_conf_content_from_ovf_store)
Found an OVF for HE VM, trying to convert
MainThread::INFO::2018-01-12
21:51:21,918::config::440::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config::(_get_vm_conf_content_from_ovf_store)
Got vm.conf from OVF_STORE
MainThread::INFO::2018-01-12
21:51:21,919::hosted_engine::509::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_initialize_broker)
Initializing ha-broker connection
MainThread::INFO::2018-01-12
21:51:21,919::brokerlink::130::ovirt_hosted_engine_ha.lib.brokerlink.BrokerLink::(start_monitor)
Starting monitor ping, options {'addr': '80.239.162.97'}
MainThread::INFO::2018-01-12
21:51:21,922::brokerlink::141::ovirt_hosted_engine_ha.lib.brokerlink.BrokerLink::(start_monitor)
Success, id 140547104457680
MainThread::INFO::2018-01-12
21:51:21,922::brokerlink::130::ovirt_hosted_engine_ha.lib.brokerlink.BrokerLink::(start_monitor)
Starting monitor mgmt-bridge, options {'use_ssl': 'true', 'bridge_name':
'ovirtmgmt', 'address': '0'}
MainThread::INFO::2018-01-12

Re: [ovirt-users] unable to bring up hosted engine after botched 4.2 upgrade

2018-01-12 Thread Martin Sivak
Hi,

the VM is up according to the status (at least for a while). You
should be able to use console and diagnose anything that happened
inside (line the need for fsck and such) now.

Check the presence of those links again now, the metadata file content
is not important, but the file has to exist (agents will populate it
with status data). I have no new idea about what is wrong with that
though.

Best regards

Martin



On Fri, Jan 12, 2018 at 5:47 PM, Jayme  wrote:
> The lock space issue was an issue I needed to clear but I don't believe it
> has resolved the problem.  I shutdown agent and broker on all hosts and
> disconnected hosted-storage then enabled broker/agent on just one host and
> connected storage.  I started the VM and actually didn't get any errors in
> the logs barely at all which was good to see, however the VM is still not
> running:
>
> HOST3:
>
> Engine status  : {"reason": "failed liveliness check",
> "health": "bad", "vm": "up", "detail": "Up"}
>
> ==> /var/log/messages <==
> Jan 12 12:42:57 cultivar3 kernel: ovirtmgmt: port 2(vnet0) entered disabled
> state
> Jan 12 12:42:57 cultivar3 kernel: device vnet0 entered promiscuous mode
> Jan 12 12:42:57 cultivar3 kernel: ovirtmgmt: port 2(vnet0) entered blocking
> state
> Jan 12 12:42:57 cultivar3 kernel: ovirtmgmt: port 2(vnet0) entered
> forwarding state
> Jan 12 12:42:57 cultivar3 lldpad: recvfrom(Event interface): No buffer space
> available
> Jan 12 12:42:57 cultivar3 systemd-machined: New machine qemu-111-Cultivar.
> Jan 12 12:42:57 cultivar3 systemd: Started Virtual Machine
> qemu-111-Cultivar.
> Jan 12 12:42:57 cultivar3 systemd: Starting Virtual Machine
> qemu-111-Cultivar.
> Jan 12 12:42:57 cultivar3 kvm: 3 guests now active
> Jan 12 12:44:38 cultivar3 libvirtd: 2018-01-12 16:44:38.737+: 1535:
> error : qemuDomainAgentAvailable:6010 : Guest agent is not responding: QEMU
> guest agent is not connected
>
> Interestingly though, now I'm seeing this in the logs which may be a new
> clue:
>
>
> ==> /var/log/vdsm/vdsm.log <==
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/nfsSD.py", line 126,
> in findDomain
> return NfsStorageDomain(NfsStorageDomain.findDomainPath(sdUUID))
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/nfsSD.py", line 116,
> in findDomainPath
> raise se.StorageDomainDoesNotExist(sdUUID)
> StorageDomainDoesNotExist: Storage domain does not exist:
> (u'248f46f0-d793-4581-9810-c9d965e2f286',)
> jsonrpc/4::ERROR::2018-01-12
> 12:40:30,380::dispatcher::82::storage.Dispatcher::(wrapper) FINISH
> getStorageDomainInfo error=Storage domain does not exist:
> (u'248f46f0-d793-4581-9810-c9d965e2f286',)
> periodic/42::ERROR::2018-01-12 12:40:35,430::api::196::root::(_getHaInfo)
> failed to retrieve Hosted Engine HA score '[Errno 2] No such file or
> directory'Is the Hosted Engine setup finished?
> periodic/43::ERROR::2018-01-12 12:40:50,473::api::196::root::(_getHaInfo)
> failed to retrieve Hosted Engine HA score '[Errno 2] No such file or
> directory'Is the Hosted Engine setup finished?
> periodic/40::ERROR::2018-01-12 12:41:05,519::api::196::root::(_getHaInfo)
> failed to retrieve Hosted Engine HA score '[Errno 2] No such file or
> directory'Is the Hosted Engine setup finished?
> periodic/43::ERROR::2018-01-12 12:41:20,566::api::196::root::(_getHaInfo)
> failed to retrieve Hosted Engine HA score '[Errno 2] No such file or
> directory'Is the Hosted Engine setup finished?
>
> ==> /var/log/ovirt-hosted-engine-ha/broker.log <==
>   File
> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/storage_broker.py",
> line 151, in get_raw_stats
> f = os.open(path, direct_flag | os.O_RDONLY | os.O_SYNC)
> OSError: [Errno 2] No such file or directory:
> '/var/run/vdsm/storage/248f46f0-d793-4581-9810-c9d965e2f286/14a20941-1b84-4b82-be8f-ace38d7c037a/8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8'
> StatusStorageThread::ERROR::2018-01-12
> 12:32:06,049::status_broker::92::ovirt_hosted_engine_ha.broker.status_broker.StatusBroker.Update::(run)
> Failed to read state.
> Traceback (most recent call last):
>   File
> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/status_broker.py",
> line 88, in run
> self._storage_broker.get_raw_stats()
>   File
> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/storage_broker.py",
> line 162, in get_raw_stats
> .format(str(e)))
> RequestError: failed to read metadata: [Errno 2] No such file or directory:
> '/var/run/vdsm/storage/248f46f0-d793-4581-9810-c9d965e2f286/14a20941-1b84-4b82-be8f-ace38d7c037a/8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8'
>
> On Fri, Jan 12, 2018 at 12:02 PM, Martin Sivak  wrote:
>>
>> The lock is the issue.
>>
>> - try running sanlock client status on all hosts
>> - also make sure you do not have some forgotten host still connected
>> to the lockspace, but without ha daemons running (and with the VM)
>>
>> I need to go to our president election now, I might check 

Re: [ovirt-users] oVirt NGN image customization troubles

2018-01-12 Thread Yuval Turgeman
Recent versions of livemedia-creator use qemu directly instead of libvirt,
and I think I saw a problem there also, but didn't get to fix it just yet.
You can use virt-builder to install a centos vm, or use an el7-based mock
environment.  You can follow the jenkins job here [1], basically you need
to do is:

1. clone ovirt-node-ng (you already did)
2. clone jenkins
3. cd ovirt-node-ng
4. ../jenkins/mock_configs/mock_runner.sh --build-only --mock-confs-dir
../jenkins/mock_configs/ --shell 'el7.*x86_64'

This will create a chroot environment in the same way we do in our CI, in
that chroot shell, do `cd ~` and then autogen, and make squashfs

[1]
http://jenkins.ovirt.org/job/ovirt-node-ng_ovirt-4.1_build-artifacts-el7-x86_64/403/consoleFull


On Thu, Jan 11, 2018 at 3:32 PM, Ryan Barry  wrote:

> I haven't tried to build on EL for a long time, but the easiest way to
> modify may simply be to unpack the squashfs, chroot inside of it, and
> repack it. Have you tried this?
>
> On Wed, Dec 27, 2017 at 11:33 AM, Giuseppe Ragusa <
> giuseppe.rag...@hotmail.com> wrote:
>
>> Hi all,
>>
>> I'm trying to modify the oVirt NGN image (to add RPMs, since imgbased
>> rpmpersistence currently seems to have a bug:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1528468 ) but I'm
>> unfortunately stuck at the very beginning: it seems that I'm unable to
>> recreate even the standard 4.1 squashfs image.
>>
>> I'm following the instructions at https://gerrit.ovirt.org/gitwe
>> b?p=ovirt-node-ng.git;a=blob;f=README
>>
>> I'm working inside a CentOS7 fully-updated vm (hosted inside VMware, with
>> nested virtualization enabled).
>>
>> I'm trying to work on the 4.1 branch, so I issued a:
>>
>> ./autogen.sh --with-ovirt-release-rpm-url=http://resources.ovirt.org/pub/
>> yum-repo/ovirt-release41.rpm
>>
>> And after that I'm stuck in the "make squashfs" step: it never ends
>> (keeps printing dots forever with no errors/warnings in log messages nor
>> any apparent activity on the virtual disk image).
>>
>> Invoking it in debug mode and connecting to the VNC console shows the
>> detailed Plymouth startup listing stuck (latest messages displayed:
>> "Starting udev Wait for Complete Device Initialization..." and "Starting
>> Device-Mapper Multipath Device Controller...")
>>
>> I wonder if it's actually supposed to be run only from a recent Fedora
>> (the "dnf" reference seems a good indicator): if so, which version?
>>
>> I kindly ask for advice: has anyone succeeded in modifying/reproducing
>> NGN squash images recently? If so, how? :-)
>>
>> Many thanks in advance,
>>
>> Giuseppe
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>
>
>
> --
>
> RYAN BARRY
>
> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHEV HYPERVISOR
>
> Red Hat NA 
>
> rba...@redhat.comM: +1-651-815-9306 IM: rbarry
> 
>
> ___
> 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 4.2 Bug with Permissons on the Vm Portal?

2018-01-12 Thread Michal Skrivanek


> On 12 Jan 2018, at 12:27, Giorgio Biacchi  wrote:
> 
> It's the same for me also.
> 
> Ovirt is connected to FreeIPA this time, so it seems not to be bound to a 
> specific AAA engine extension.
> 
> Do we have to submit a new bug on bugzilla??

Looks like https://github.com/oVirt/ovirt-web-ui/issues/460 
 ?
Somehow it diappeared in recent 4.2.1 builds, can you check that by any chance 
on your setup too?

Thanks,
michal

> 
> Regards
> 
> On 01/11/2018 02:04 PM, Latchezar Filtchev wrote:
>> Hi Guys,
>> The same here. Upgrade 4.1.8 to 4.2. oVirt connected to Active Directory. 
>> User cannot see machines in VM portal. Still playing with permissions.
>> Any ideas?
>> Thank you!
>> Best,
>> Latcho
>> *From:*users-boun...@ovirt.org [mailto:users-boun...@ovirt.org] *On Behalf 
>> Of *Thomas Fecke
>> *Sent:* Monday, January 08, 2018 3:17 PM
>> *To:* users@ovirt.org
>> *Subject:* [ovirt-users] Ovirt 4.2 Bug with Permissons on the Vm Portal?
>> Hello Guys,
>> i recently upgrade to 4.2
>> We used the User Portal before. Every User could see his__ VM´s, every Admin 
>> just could see his VM´s ( User View ).
>> After the Update:
>> Admin´s can see every VM in VM Portal
>> The Users can´t see Vm´s anymore. The Portal is Empty. Role “UserVMManager” 
>> is set.
>> We tested some Scenarios: If the User create a new Virtual Machine, it is 
>> shown in the VM Portal. When he log out and in again -> VM is gone in his 
>> View
>> Admin View: The VM was created, Permission where set. Everything seems to be 
>> good.
>> Any Ideas? Thanks Guys__
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
> 
> -- 
> gb
> 
> PGP Key: http://pgp.mit.edu/
> Primary key fingerprint: C510 0765 943E EBED A4F2 69D3 16CC DC90 B9CB 0F34
> ___
> 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] (no subject)

2018-01-12 Thread Artem Tambovskiy
Trying to fix one thing I broke another :(

I fixed mnt_options for hosted engine storage domain and installed latest
security patches to my hosts and hosted engine. All VM's up and running,
but  hosted_engine --vm-status reports about issues:

[root@ovirt1 ~]# hosted-engine --vm-status


--== Host 1 status ==--

conf_on_shared_storage : True
Status up-to-date  : False
Hostname   : ovirt2
Host ID: 1
Engine status  : unknown stale-data
Score  : 0
stopped: False
Local maintenance  : False
crc32  : 193164b8
local_conf_timestamp   : 8350
Host timestamp : 8350
Extra metadata (valid at timestamp):
metadata_parse_version=1
metadata_feature_version=1
timestamp=8350 (Fri Jan 12 19:03:54 2018)
host-id=1
score=0
vm_conf_refresh_time=8350 (Fri Jan 12 19:03:54 2018)
conf_on_shared_storage=True
maintenance=False
state=EngineUnexpectedlyDown
stopped=False
timeout=Thu Jan  1 05:24:43 1970


--== Host 2 status ==--

conf_on_shared_storage : True
Status up-to-date  : False
Hostname   : ovirt1.telia.ru
Host ID: 2
Engine status  : unknown stale-data
Score  : 0
stopped: True
Local maintenance  : False
crc32  : c7037c03
local_conf_timestamp   : 7530
Host timestamp : 7530
Extra metadata (valid at timestamp):
metadata_parse_version=1
metadata_feature_version=1
timestamp=7530 (Fri Jan 12 16:10:12 2018)
host-id=2
score=0
vm_conf_refresh_time=7530 (Fri Jan 12 16:10:12 2018)
conf_on_shared_storage=True
maintenance=False
state=AgentStopped
stopped=True
[root@ovirt1 ~]#



from second host situation looks a bit different:


[root@ovirt2 ~]# hosted-engine --vm-status


--== Host 1 status ==--

conf_on_shared_storage : True
Status up-to-date  : True
Hostname   : ovirt2
Host ID: 1
Engine status  : {"reason": "vm not running on this
host", "health": "bad", "vm": "down", "detail": "unknown"}
Score  : 0
stopped: False
Local maintenance  : False
crc32  : 78eabdb6
local_conf_timestamp   : 8403
Host timestamp : 8402
Extra metadata (valid at timestamp):
metadata_parse_version=1
metadata_feature_version=1
timestamp=8402 (Fri Jan 12 19:04:47 2018)
host-id=1
score=0
vm_conf_refresh_time=8403 (Fri Jan 12 19:04:47 2018)
conf_on_shared_storage=True
maintenance=False
state=EngineUnexpectedlyDown
stopped=False
timeout=Thu Jan  1 05:24:43 1970


--== Host 2 status ==--

conf_on_shared_storage : True
Status up-to-date  : False
Hostname   : ovirt1.telia.ru
Host ID: 2
Engine status  : unknown stale-data
Score  : 0
stopped: True
Local maintenance  : False
crc32  : c7037c03
local_conf_timestamp   : 7530
Host timestamp : 7530
Extra metadata (valid at timestamp):
metadata_parse_version=1
metadata_feature_version=1
timestamp=7530 (Fri Jan 12 16:10:12 2018)
host-id=2
score=0
vm_conf_refresh_time=7530 (Fri Jan 12 16:10:12 2018)
conf_on_shared_storage=True
maintenance=False
state=AgentStopped
stopped=True


WebGUI shows that engine running on host ovirt1.
Gluster looks fine
[root@ovirt1 ~]# gluster volume status engine
Status of volume: engine
Gluster process TCP Port  RDMA Port  Online  Pid
--
Brick ovirt1.telia.ru:/oVirt/engine 49169 0  Y
3244
Brick ovirt2.telia.ru:/oVirt/engine 49179 0  Y
20372
Brick ovirt3.telia.ru:/oVirt/engine 49206 0  Y
16609
Self-heal Daemon on localhost   N/A   N/AY
117868
Self-heal Daemon on ovirt2.telia.ru N/A   N/AY
20521
Self-heal Daemon on ovirt3  N/A   N/AY
25093

Task Status of Volume engine
--
There are no active volume tasks

How to resolve this issue?

Re: [ovirt-users] mount_options for hosted_engine storage domain

2018-01-12 Thread Artem Tambovskiy
Thanks a lot, Simeone!

hosted-engine --set-shared-config mnt_options
backup-volfile-servers=host1.domain.com:host2.domain.com --type=he_conf
 solved my issue!

Regards,
Artem

On Fri, Jan 12, 2018 at 3:39 PM, Simone Tiraboschi 
wrote:

>
>
> On Fri, Jan 12, 2018 at 1:22 PM, Artem Tambovskiy <
> artem.tambovs...@gmail.com> wrote:
>
>> Hi,
>>
>> I have deployed a small cluster with 2 ovirt hosts and GlusterFS cluster
>> some time ago. And recently during software upgrade I noticed that I made
>> some mistakes during the installation:
>>
>> if the host which was deployed first will be taken down for upgrade
>> (powered off or rebooted) the engine becomes unavailable (even all VM's and
>> hosted engine were migrated to second host in advance).
>>
>> I was thinking that this is due to missing mnt_options=backup-volfile--se
>> rvers=host1.domain.com;host2.domain.com option for hosted engine storage
>> domain.
>> Is there any good way to fix this? I have tried
>> edit /etc/ovirt-hosted-engine/hosted-engine.conf manually to add missing
>> mnt_options but after while I noticed that those changes are gone.
>>
>
> The master copy used at host-deploy time is on the shared storage domain,
> you can change it with:
> hosted-engine --set-shared-conf mnt_options=backup-volfile--servers=
> host1.domain.com;host2.domain.com
>
> And then edit /etc/ovirt-hosted-engine/hosted-engine.conf and restart
> ovirt-ha-agent on existing HE hosts.
>
>
>
>>
>> Any suggestions?
>>
>> Thanks in advance!
>> Artem
>>
>>
>>
>>
>> ___
>> 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] unable to bring up hosted engine after botched 4.2 upgrade

2018-01-12 Thread Martin Sivak
> Can you please stop all hosted engine tooling (

On all hosts I should have added.

Martin

On Fri, Jan 12, 2018 at 3:22 PM, Martin Sivak  wrote:
>> RequestError: failed to read metadata: [Errno 2] No such file or directory:
>> '/var/run/vdsm/storage/248f46f0-d793-4581-9810-c9d965e2f286/14a20941-1b84-4b82-be8f-ace38d7c037a/8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8'
>>
>>  ls -al
>> /var/run/vdsm/storage/248f46f0-d793-4581-9810-c9d965e2f286/14a20941-1b84-4b82-be8f-ace38d7c037a/8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8
>> -rw-rw. 1 vdsm kvm 1028096 Jan 12 09:59
>> /var/run/vdsm/storage/248f46f0-d793-4581-9810-c9d965e2f286/14a20941-1b84-4b82-be8f-ace38d7c037a/8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8
>>
>> Is this due to the symlink problem you guys are referring to that was
>> addressed in RC1 or something else?
>
> No, this file is the symlink. It should point to somewhere inside
> /rhev/. I see it is a 1G file in your case. That is really
> interesting.
>
> Can you please stop all hosted engine tooling (ovirt-ha-agent,
> ovirt-ha-broker), move the file (metadata file is not important when
> services are stopped, but better safe than sorry) and restart all
> services again?
>
>> Could there possibly be a permissions
>> problem somewhere?
>
> Maybe, but the file itself looks out of the ordinary. I wonder how it got 
> there.
>
> Best regards
>
> Martin Sivak
>
> On Fri, Jan 12, 2018 at 3:09 PM, Jayme  wrote:
>> Thanks for the help thus far.  Storage could be related but all other VMs on
>> same storage are running ok.  The storage is mounted via NFS from within one
>> of the three hosts, I realize this is not ideal.  This was setup by a
>> previous admin more as a proof of concept and VMs were put on there that
>> should not have been placed in a proof of concept environment.. it was
>> intended to be rebuilt with proper storage down the road.
>>
>> So the storage is on HOST0 and the other hosts mount NFS
>>
>> cultivar0.grove.silverorange.com:/exports/data  4861742080
>> 1039352832 3822389248  22%
>> /rhev/data-center/mnt/cultivar0.grove.silverorange.com:_exports_data
>> cultivar0.grove.silverorange.com:/exports/iso   4861742080
>> 1039352832 3822389248  22%
>> /rhev/data-center/mnt/cultivar0.grove.silverorange.com:_exports_iso
>> cultivar0.grove.silverorange.com:/exports/import_export 4861742080
>> 1039352832 3822389248  22%
>> /rhev/data-center/mnt/cultivar0.grove.silverorange.com:_exports_import__export
>> cultivar0.grove.silverorange.com:/exports/hosted_engine 4861742080
>> 1039352832 3822389248  22%
>> /rhev/data-center/mnt/cultivar0.grove.silverorange.com:_exports_hosted__engine
>>
>> Like I said, the VM data storage itself seems to be working ok, as all other
>> VMs appear to be running.
>>
>> I'm curious why the broker log says this file is not found when it is
>> correct and I can see the file at that path:
>>
>> RequestError: failed to read metadata: [Errno 2] No such file or directory:
>> '/var/run/vdsm/storage/248f46f0-d793-4581-9810-c9d965e2f286/14a20941-1b84-4b82-be8f-ace38d7c037a/8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8'
>>
>>  ls -al
>> /var/run/vdsm/storage/248f46f0-d793-4581-9810-c9d965e2f286/14a20941-1b84-4b82-be8f-ace38d7c037a/8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8
>> -rw-rw. 1 vdsm kvm 1028096 Jan 12 09:59
>> /var/run/vdsm/storage/248f46f0-d793-4581-9810-c9d965e2f286/14a20941-1b84-4b82-be8f-ace38d7c037a/8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8
>>
>> Is this due to the symlink problem you guys are referring to that was
>> addressed in RC1 or something else?  Could there possibly be a permissions
>> problem somewhere?
>>
>> Assuming that all three hosts have 4.2 rpms installed and the host engine
>> will not start is it safe for me to update hosts to 4.2 RC1 rpms?   Or
>> perhaps install that repo and *only* update the ovirt HA packages?
>> Assuming that I cannot yet apply the same updates to the inaccessible hosted
>> engine VM.
>>
>> I should also mention one more thing.  I originally upgraded the engine VM
>> first using new RPMS then engine-setup.  It failed due to not being in
>> global maintenance, so I set global maintenance and ran it again, which
>> appeared to complete as intended but never came back up after.  Just in case
>> this might have anything at all to do with what could have happened.
>>
>> Thanks very much again, I very much appreciate the help!
>>
>> - Jayme
>>
>> On Fri, Jan 12, 2018 at 8:44 AM, Simone Tiraboschi 
>> wrote:
>>>
>>>
>>>
>>> On Fri, Jan 12, 2018 at 11:11 AM, Martin Sivak  wrote:

 Hi,

 the hosted engine agent issue might be fixed by restarting
 ovirt-ha-broker or updating to newest ovirt-hosted-engine-ha and
 -setup. We improved handling of the missing symlink.
>>>
>>>
>>> Available just in oVirt 4.2.1 RC1
>>>


 All the other issues seem to point to some storage problem I am afraid.

 You said you started the VM, do you see it 

Re: [ovirt-users] unable to bring up hosted engine after botched 4.2 upgrade

2018-01-12 Thread Martin Sivak
> RequestError: failed to read metadata: [Errno 2] No such file or directory:
> '/var/run/vdsm/storage/248f46f0-d793-4581-9810-c9d965e2f286/14a20941-1b84-4b82-be8f-ace38d7c037a/8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8'
>
>  ls -al
> /var/run/vdsm/storage/248f46f0-d793-4581-9810-c9d965e2f286/14a20941-1b84-4b82-be8f-ace38d7c037a/8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8
> -rw-rw. 1 vdsm kvm 1028096 Jan 12 09:59
> /var/run/vdsm/storage/248f46f0-d793-4581-9810-c9d965e2f286/14a20941-1b84-4b82-be8f-ace38d7c037a/8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8
>
> Is this due to the symlink problem you guys are referring to that was
> addressed in RC1 or something else?

No, this file is the symlink. It should point to somewhere inside
/rhev/. I see it is a 1G file in your case. That is really
interesting.

Can you please stop all hosted engine tooling (ovirt-ha-agent,
ovirt-ha-broker), move the file (metadata file is not important when
services are stopped, but better safe than sorry) and restart all
services again?

> Could there possibly be a permissions
> problem somewhere?

Maybe, but the file itself looks out of the ordinary. I wonder how it got there.

Best regards

Martin Sivak

On Fri, Jan 12, 2018 at 3:09 PM, Jayme  wrote:
> Thanks for the help thus far.  Storage could be related but all other VMs on
> same storage are running ok.  The storage is mounted via NFS from within one
> of the three hosts, I realize this is not ideal.  This was setup by a
> previous admin more as a proof of concept and VMs were put on there that
> should not have been placed in a proof of concept environment.. it was
> intended to be rebuilt with proper storage down the road.
>
> So the storage is on HOST0 and the other hosts mount NFS
>
> cultivar0.grove.silverorange.com:/exports/data  4861742080
> 1039352832 3822389248  22%
> /rhev/data-center/mnt/cultivar0.grove.silverorange.com:_exports_data
> cultivar0.grove.silverorange.com:/exports/iso   4861742080
> 1039352832 3822389248  22%
> /rhev/data-center/mnt/cultivar0.grove.silverorange.com:_exports_iso
> cultivar0.grove.silverorange.com:/exports/import_export 4861742080
> 1039352832 3822389248  22%
> /rhev/data-center/mnt/cultivar0.grove.silverorange.com:_exports_import__export
> cultivar0.grove.silverorange.com:/exports/hosted_engine 4861742080
> 1039352832 3822389248  22%
> /rhev/data-center/mnt/cultivar0.grove.silverorange.com:_exports_hosted__engine
>
> Like I said, the VM data storage itself seems to be working ok, as all other
> VMs appear to be running.
>
> I'm curious why the broker log says this file is not found when it is
> correct and I can see the file at that path:
>
> RequestError: failed to read metadata: [Errno 2] No such file or directory:
> '/var/run/vdsm/storage/248f46f0-d793-4581-9810-c9d965e2f286/14a20941-1b84-4b82-be8f-ace38d7c037a/8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8'
>
>  ls -al
> /var/run/vdsm/storage/248f46f0-d793-4581-9810-c9d965e2f286/14a20941-1b84-4b82-be8f-ace38d7c037a/8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8
> -rw-rw. 1 vdsm kvm 1028096 Jan 12 09:59
> /var/run/vdsm/storage/248f46f0-d793-4581-9810-c9d965e2f286/14a20941-1b84-4b82-be8f-ace38d7c037a/8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8
>
> Is this due to the symlink problem you guys are referring to that was
> addressed in RC1 or something else?  Could there possibly be a permissions
> problem somewhere?
>
> Assuming that all three hosts have 4.2 rpms installed and the host engine
> will not start is it safe for me to update hosts to 4.2 RC1 rpms?   Or
> perhaps install that repo and *only* update the ovirt HA packages?
> Assuming that I cannot yet apply the same updates to the inaccessible hosted
> engine VM.
>
> I should also mention one more thing.  I originally upgraded the engine VM
> first using new RPMS then engine-setup.  It failed due to not being in
> global maintenance, so I set global maintenance and ran it again, which
> appeared to complete as intended but never came back up after.  Just in case
> this might have anything at all to do with what could have happened.
>
> Thanks very much again, I very much appreciate the help!
>
> - Jayme
>
> On Fri, Jan 12, 2018 at 8:44 AM, Simone Tiraboschi 
> wrote:
>>
>>
>>
>> On Fri, Jan 12, 2018 at 11:11 AM, Martin Sivak  wrote:
>>>
>>> Hi,
>>>
>>> the hosted engine agent issue might be fixed by restarting
>>> ovirt-ha-broker or updating to newest ovirt-hosted-engine-ha and
>>> -setup. We improved handling of the missing symlink.
>>
>>
>> Available just in oVirt 4.2.1 RC1
>>
>>>
>>>
>>> All the other issues seem to point to some storage problem I am afraid.
>>>
>>> You said you started the VM, do you see it in virsh -r list?
>>>
>>> Best regards
>>>
>>> Martin Sivak
>>>
>>> On Thu, Jan 11, 2018 at 10:00 PM, Jayme  wrote:
>>> > Please help, I'm really not sure what else to try at this point.  Thank
>>> > you
>>> > for reading!
>>> >
>>> >
>>> > I'm still working on trying to 

Re: [ovirt-users] unable to bring up hosted engine after botched 4.2 upgrade

2018-01-12 Thread Martin Sivak
The blockIoTune error should be harmless. It is just a result of a
data check by other component (mom) that encountered a VM that no
longer exists.

I thought we squashed all the logs like that though..

Martin

On Fri, Jan 12, 2018 at 3:12 PM, Jayme  wrote:
> One more thing to add, I've also been seeing a lot of this in the syslog as
> well:
>
> Jan 12 10:10:49 cultivar2 journal: vdsm jsonrpc.JsonRpcServer ERROR Internal
> server error#012Traceback (most recent call last):#012  File
> "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 606, in
> _handle_request#012res = method(**params)#012  File
> "/usr/lib/python2.7/site-packages/vdsm/rpc/Bridge.py", line 197, in
> _dynamicMethod#012result = fn(*methodArgs)#012  File "", line 2,
> in getAllVmIoTunePolicies#012  File
> "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 48, in
> method#012ret = func(*args, **kwargs)#012  File
> "/usr/lib/python2.7/site-packages/vdsm/API.py", line 1354, in
> getAllVmIoTunePolicies#012io_tune_policies_dict =
> self._cif.getAllVmIoTunePolicies()#012  File
> "/usr/lib/python2.7/site-packages/vdsm/clientIF.py", line 524, in
> getAllVmIoTunePolicies#012'current_values': v.getIoTune()}#012  File
> "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 3481, in
> getIoTune#012result = self.getIoTuneResponse()#012  File
> "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 3500, in
> getIoTuneResponse#012res = self._dom.blockIoTune(#012  File
> "/usr/lib/python2.7/site-packages/vdsm/virt/virdomain.py", line 47, in
> __getattr__#012% self.vmid)#012NotConnectedError: VM
> '4013c829-c9d7-4b72-90d5-6fe58137504c' was not defined yet or was undefined
>
> On Fri, Jan 12, 2018 at 10:09 AM, Jayme  wrote:
>>
>> Thanks for the help thus far.  Storage could be related but all other VMs
>> on same storage are running ok.  The storage is mounted via NFS from within
>> one of the three hosts, I realize this is not ideal.  This was setup by a
>> previous admin more as a proof of concept and VMs were put on there that
>> should not have been placed in a proof of concept environment.. it was
>> intended to be rebuilt with proper storage down the road.
>>
>> So the storage is on HOST0 and the other hosts mount NFS
>>
>> cultivar0.grove.silverorange.com:/exports/data  4861742080
>> 1039352832 3822389248  22%
>> /rhev/data-center/mnt/cultivar0.grove.silverorange.com:_exports_data
>> cultivar0.grove.silverorange.com:/exports/iso   4861742080
>> 1039352832 3822389248  22%
>> /rhev/data-center/mnt/cultivar0.grove.silverorange.com:_exports_iso
>> cultivar0.grove.silverorange.com:/exports/import_export 4861742080
>> 1039352832 3822389248  22%
>> /rhev/data-center/mnt/cultivar0.grove.silverorange.com:_exports_import__export
>> cultivar0.grove.silverorange.com:/exports/hosted_engine 4861742080
>> 1039352832 3822389248  22%
>> /rhev/data-center/mnt/cultivar0.grove.silverorange.com:_exports_hosted__engine
>>
>> Like I said, the VM data storage itself seems to be working ok, as all
>> other VMs appear to be running.
>>
>> I'm curious why the broker log says this file is not found when it is
>> correct and I can see the file at that path:
>>
>> RequestError: failed to read metadata: [Errno 2] No such file or
>> directory:
>> '/var/run/vdsm/storage/248f46f0-d793-4581-9810-c9d965e2f286/14a20941-1b84-4b82-be8f-ace38d7c037a/8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8'
>>
>>  ls -al
>> /var/run/vdsm/storage/248f46f0-d793-4581-9810-c9d965e2f286/14a20941-1b84-4b82-be8f-ace38d7c037a/8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8
>> -rw-rw. 1 vdsm kvm 1028096 Jan 12 09:59
>> /var/run/vdsm/storage/248f46f0-d793-4581-9810-c9d965e2f286/14a20941-1b84-4b82-be8f-ace38d7c037a/8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8
>>
>> Is this due to the symlink problem you guys are referring to that was
>> addressed in RC1 or something else?  Could there possibly be a permissions
>> problem somewhere?
>>
>> Assuming that all three hosts have 4.2 rpms installed and the host engine
>> will not start is it safe for me to update hosts to 4.2 RC1 rpms?   Or
>> perhaps install that repo and *only* update the ovirt HA packages?
>> Assuming that I cannot yet apply the same updates to the inaccessible hosted
>> engine VM.
>>
>> I should also mention one more thing.  I originally upgraded the engine VM
>> first using new RPMS then engine-setup.  It failed due to not being in
>> global maintenance, so I set global maintenance and ran it again, which
>> appeared to complete as intended but never came back up after.  Just in case
>> this might have anything at all to do with what could have happened.
>>
>> Thanks very much again, I very much appreciate the help!
>>
>> - Jayme
>>
>> On Fri, Jan 12, 2018 at 8:44 AM, Simone Tiraboschi 
>> wrote:
>>>
>>>
>>>
>>> On Fri, Jan 12, 2018 at 11:11 AM, Martin Sivak  wrote:

 Hi,

 the hosted engine agent issue might 

Re: [ovirt-users] unable to bring up hosted engine after botched 4.2 upgrade

2018-01-12 Thread Jayme
One more thing to add, I've also been seeing a lot of this in the syslog as
well:

Jan 12 10:10:49 cultivar2 journal: vdsm jsonrpc.JsonRpcServer ERROR
Internal server error#012Traceback (most recent call last):#012  File
"/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 606, in
_handle_request#012res = method(**params)#012  File
"/usr/lib/python2.7/site-packages/vdsm/rpc/Bridge.py", line 197, in
_dynamicMethod#012result = fn(*methodArgs)#012  File "", line
2, in getAllVmIoTunePolicies#012  File
"/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 48, in
method#012ret = func(*args, **kwargs)#012  File
"/usr/lib/python2.7/site-packages/vdsm/API.py", line 1354, in
getAllVmIoTunePolicies#012io_tune_policies_dict =
self._cif.getAllVmIoTunePolicies()#012  File
"/usr/lib/python2.7/site-packages/vdsm/clientIF.py", line 524, in
getAllVmIoTunePolicies#012'current_values': v.getIoTune()}#012  File
"/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 3481, in
getIoTune#012result = self.getIoTuneResponse()#012  File
"/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 3500, in
getIoTuneResponse#012res = self._dom.blockIoTune(#012  File
"/usr/lib/python2.7/site-packages/vdsm/virt/virdomain.py", line 47, in
__getattr__#012% self.vmid)#012NotConnectedError: VM
'4013c829-c9d7-4b72-90d5-6fe58137504c' was not defined yet or was undefined

On Fri, Jan 12, 2018 at 10:09 AM, Jayme  wrote:

> Thanks for the help thus far.  Storage could be related but all other VMs
> on same storage are running ok.  The storage is mounted via NFS from within
> one of the three hosts, I realize this is not ideal.  This was setup by a
> previous admin more as a proof of concept and VMs were put on there that
> should not have been placed in a proof of concept environment.. it was
> intended to be rebuilt with proper storage down the road.
>
> So the storage is on HOST0 and the other hosts mount NFS
>
> cultivar0.grove.silverorange.com:/exports/data  4861742080
> 1039352832 3822389248  22% /rhev/data-center/mnt/cultivar
> 0.grove.silverorange.com:_exports_data
> cultivar0.grove.silverorange.com:/exports/iso   4861742080
> 1039352832 3822389248  22% /rhev/data-center/mnt/cultivar
> 0.grove.silverorange.com:_exports_iso
> cultivar0.grove.silverorange.com:/exports/import_export 4861742080
> 1039352832 3822389248  22% /rhev/data-center/mnt/cultivar
> 0.grove.silverorange.com:_exports_import__export
> cultivar0.grove.silverorange.com:/exports/hosted_engine 4861742080
> 1039352832 3822389248  22% /rhev/data-center/mnt/cultivar
> 0.grove.silverorange.com:_exports_hosted__engine
>
> Like I said, the VM data storage itself seems to be working ok, as all
> other VMs appear to be running.
>
> I'm curious why the broker log says this file is not found when it is
> correct and I can see the file at that path:
>
> RequestError: failed to read metadata: [Errno 2] No such file or
> directory: '/var/run/vdsm/storage/248f46f0-d793-4581-9810-c9d965e2f286/
> 14a20941-1b84-4b82-be8f-ace38d7c037a/8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8'
>
>  ls -al /var/run/vdsm/storage/248f46f0-d793-4581-9810-c9d965e2f286/1
> 4a20941-1b84-4b82-be8f-ace38d7c037a/8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8
> -rw-rw. 1 vdsm kvm 1028096 Jan 12 09:59 /var/run/vdsm/storage/248f46f0
> -d793-4581-9810-c9d965e2f286/14a20941-1b84-4b82-be8f-ace38d7
> c037a/8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8
>
> Is this due to the symlink problem you guys are referring to that was
> addressed in RC1 or something else?  Could there possibly be a permissions
> problem somewhere?
>
> Assuming that all three hosts have 4.2 rpms installed and the host engine
> will not start is it safe for me to update hosts to 4.2 RC1 rpms?   Or
> perhaps install that repo and *only* update the ovirt HA packages?
>  Assuming that I cannot yet apply the same updates to the inaccessible
> hosted engine VM.
>
> I should also mention one more thing.  I originally upgraded the engine VM
> first using new RPMS then engine-setup.  It failed due to not being in
> global maintenance, so I set global maintenance and ran it again, which
> appeared to complete as intended but never came back up after.  Just in
> case this might have anything at all to do with what could have happened.
>
> Thanks very much again, I very much appreciate the help!
>
> - Jayme
>
> On Fri, Jan 12, 2018 at 8:44 AM, Simone Tiraboschi 
> wrote:
>
>>
>>
>> On Fri, Jan 12, 2018 at 11:11 AM, Martin Sivak  wrote:
>>
>>> Hi,
>>>
>>> the hosted engine agent issue might be fixed by restarting
>>> ovirt-ha-broker or updating to newest ovirt-hosted-engine-ha and
>>> -setup. We improved handling of the missing symlink.
>>>
>>
>> Available just in oVirt 4.2.1 RC1
>>
>>
>>>
>>> All the other issues seem to point to some storage problem I am afraid.
>>>
>>> You said you started the VM, do you see it in virsh -r list?
>>>
>>> Best regards
>>>
>>> Martin 

Re: [ovirt-users] unable to bring up hosted engine after botched 4.2 upgrade

2018-01-12 Thread Jayme
Thanks for the help thus far.  Storage could be related but all other VMs
on same storage are running ok.  The storage is mounted via NFS from within
one of the three hosts, I realize this is not ideal.  This was setup by a
previous admin more as a proof of concept and VMs were put on there that
should not have been placed in a proof of concept environment.. it was
intended to be rebuilt with proper storage down the road.

So the storage is on HOST0 and the other hosts mount NFS

cultivar0.grove.silverorange.com:/exports/data  4861742080
1039352832 3822389248  22% /rhev/data-center/mnt/cultivar
0.grove.silverorange.com:_exports_data
cultivar0.grove.silverorange.com:/exports/iso   4861742080
1039352832 3822389248  22% /rhev/data-center/mnt/cultivar
0.grove.silverorange.com:_exports_iso
cultivar0.grove.silverorange.com:/exports/import_export 4861742080
1039352832 3822389248  22% /rhev/data-center/mnt/cultivar
0.grove.silverorange.com:_exports_import__export
cultivar0.grove.silverorange.com:/exports/hosted_engine 4861742080
1039352832 3822389248  22% /rhev/data-center/mnt/cultivar
0.grove.silverorange.com:_exports_hosted__engine

Like I said, the VM data storage itself seems to be working ok, as all
other VMs appear to be running.

I'm curious why the broker log says this file is not found when it is
correct and I can see the file at that path:

RequestError: failed to read metadata: [Errno 2] No such file or directory:
'/var/run/vdsm/storage/248f46f0-d793-4581-9810-c9d965e2f286/
14a20941-1b84-4b82-be8f-ace38d7c037a/8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8'

 ls -al /var/run/vdsm/storage/248f46f0-d793-4581-9810-c9d965e2f286/
14a20941-1b84-4b82-be8f-ace38d7c037a/8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8
-rw-rw. 1 vdsm kvm 1028096 Jan 12 09:59 /var/run/vdsm/storage/248f46f0
-d793-4581-9810-c9d965e2f286/14a20941-1b84-4b82-be8f-
ace38d7c037a/8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8

Is this due to the symlink problem you guys are referring to that was
addressed in RC1 or something else?  Could there possibly be a permissions
problem somewhere?

Assuming that all three hosts have 4.2 rpms installed and the host engine
will not start is it safe for me to update hosts to 4.2 RC1 rpms?   Or
perhaps install that repo and *only* update the ovirt HA packages?
 Assuming that I cannot yet apply the same updates to the inaccessible
hosted engine VM.

I should also mention one more thing.  I originally upgraded the engine VM
first using new RPMS then engine-setup.  It failed due to not being in
global maintenance, so I set global maintenance and ran it again, which
appeared to complete as intended but never came back up after.  Just in
case this might have anything at all to do with what could have happened.

Thanks very much again, I very much appreciate the help!

- Jayme

On Fri, Jan 12, 2018 at 8:44 AM, Simone Tiraboschi 
wrote:

>
>
> On Fri, Jan 12, 2018 at 11:11 AM, Martin Sivak  wrote:
>
>> Hi,
>>
>> the hosted engine agent issue might be fixed by restarting
>> ovirt-ha-broker or updating to newest ovirt-hosted-engine-ha and
>> -setup. We improved handling of the missing symlink.
>>
>
> Available just in oVirt 4.2.1 RC1
>
>
>>
>> All the other issues seem to point to some storage problem I am afraid.
>>
>> You said you started the VM, do you see it in virsh -r list?
>>
>> Best regards
>>
>> Martin Sivak
>>
>> On Thu, Jan 11, 2018 at 10:00 PM, Jayme  wrote:
>> > Please help, I'm really not sure what else to try at this point.  Thank
>> you
>> > for reading!
>> >
>> >
>> > I'm still working on trying to get my hosted engine running after a
>> botched
>> > upgrade to 4.2.  Storage is NFS mounted from within one of the hosts.
>> Right
>> > now I have 3 centos7 hosts that are fully updated with yum packages from
>> > ovirt 4.2, the engine was fully updated with yum packages and failed to
>> come
>> > up after reboot.  As of right now, everything should have full yum
>> updates
>> > and all having 4.2 rpms.  I have global maintenance mode on right now
>> and
>> > started hosted-engine on one of the three host and the status is
>> currently:
>> > Engine status : {"reason": "failed liveliness check”; "health": "bad",
>> "vm":
>> > "up", "detail": "Up"}
>> >
>> >
>> > this is what I get when trying to enter hosted-vm --console
>> >
>> >
>> > The engine VM is running on this host
>> >
>> > error: failed to get domain 'HostedEngine'
>> >
>> > error: Domain not found: no domain with matching name 'HostedEngine'
>> >
>> >
>> > Here are logs from various sources when I start the VM on HOST3:
>> >
>> >
>> > hosted-engine --vm-start
>> >
>> > Command VM.getStats with args {'vmID':
>> > '4013c829-c9d7-4b72-90d5-6fe58137504c'} failed:
>> >
>> > (code=1, message=Virtual machine does not exist: {'vmId':
>> > u'4013c829-c9d7-4b72-90d5-6fe58137504c'})
>> >
>> >
>> > Jan 11 16:55:57 cultivar3 systemd-machined: New machine
>> qemu-110-Cultivar.
>> >
>> > Jan 11 16:55:57 

Re: [ovirt-users] Some major problems after 4.2 upgrade, could really use some assistance

2018-01-12 Thread Simone Tiraboschi
On Thu, Jan 11, 2018 at 6:15 AM, Jayme  wrote:

> I performed Ovirt 4.2 upgrade on a 3 host cluster with NFS shared
> storage.  The shared storage is mounted from one of the hosts.
>
> I upgraded the hosted engine first, downloading the 4.2 rpm, doing a yum
> update then engine setup which seemed to complete successfully, at the end
> it powered down the hosted VM but it never came back up.  I was unable to
> start it.
>
> I proceeded to upgrade the three hosts, ovirt 4.2 rpm and a full yum
> update.  I also rebooted each of the three hosts.
>
> After some time the hosts did come back and almost all of the VMs are
> running again and seem to be working ok with the exception of two:
>
> 1. The hosted VM still will not start, I've tried everything I can think
> of.
>
> 2. A VM that I know existed is not running and does not appear to exist, I
> have no idea where it is or how to start it.
>
> 1. Hosted engine
>
> From one of the hosts I get a weird error trying to start it:
>
> # hosted-engine --vm-start
> Command VM.getStats with args {'vmID': '4013c829-c9d7-4b72-90d5-6fe58137504c'}
> failed:
> (code=1, message=Virtual machine does not exist: {'vmId':
> u'4013c829-c9d7-4b72-90d5-6fe58137504c'})
>
> From the two other hosts I do not get the same error as above, sometimes
> it appears to start but --vm-status shows errors such as:  Engine status
>   : {"reason": "failed liveliness check", "health": "bad",
> "vm": "up", "detail": "Up"}
>
> Seeing these errors in syslog:
>
> Jan 11 01:06:30 host0 libvirtd: 2018-01-11 05:06:30.473+: 1910: error
> : qemuOpenFileAs:3183 : Failed to open file '/var/run/vdsm/storage/
> 248f46f0-d793-4581-9810-c9d965e2f286/c2dde892-f978-4dfc-a421-c8e04cf387f9/
> 23aa0a66-fa6c-4967-a1e5-fbe47c0cd705': No such file or directory
>
> Jan 11 01:06:30 host0 libvirtd: 2018-01-11 05:06:30.473+: 1910: error
> : qemuDomainStorageOpenStat:11492 : cannot stat file
> '/var/run/vdsm/storage/248f46f0-d793-4581-9810-c9d965e2f286/c2dde892-f978-
> 4dfc-a421-c8e04cf387f9/23aa0a66-fa6c-4967-a1e5-fbe47c0cd705': Bad file
> descriptor
>
> 2. Missing VM.  virsh -r list on each host does not show the VM at all.  I
> know it existed and is important.  The log on one of the hosts even shows
> that it started it recently then stopped in 10 or so minutes later:
>
> Jan 10 18:47:17 host3 systemd-machined: New machine qemu-9-Berna.
> Jan 10 18:47:17 host3 systemd: Started Virtual Machine qemu-9-Berna.
> Jan 10 18:47:17 host3 systemd: Starting Virtual Machine qemu-9-Berna.
> Jan 10 18:54:45 host3 systemd-machined: Machine qemu-9-Berna terminated.
>
> How can I find out the status of the "Berna" VM and get it running again?
>

Is it on the engine DB?


>
> Thanks so much!
>
> ___
> 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] unable to bring up hosted engine after botched 4.2 upgrade

2018-01-12 Thread Simone Tiraboschi
On Fri, Jan 12, 2018 at 11:11 AM, Martin Sivak  wrote:

> Hi,
>
> the hosted engine agent issue might be fixed by restarting
> ovirt-ha-broker or updating to newest ovirt-hosted-engine-ha and
> -setup. We improved handling of the missing symlink.
>

Available just in oVirt 4.2.1 RC1


>
> All the other issues seem to point to some storage problem I am afraid.
>
> You said you started the VM, do you see it in virsh -r list?
>
> Best regards
>
> Martin Sivak
>
> On Thu, Jan 11, 2018 at 10:00 PM, Jayme  wrote:
> > Please help, I'm really not sure what else to try at this point.  Thank
> you
> > for reading!
> >
> >
> > I'm still working on trying to get my hosted engine running after a
> botched
> > upgrade to 4.2.  Storage is NFS mounted from within one of the hosts.
> Right
> > now I have 3 centos7 hosts that are fully updated with yum packages from
> > ovirt 4.2, the engine was fully updated with yum packages and failed to
> come
> > up after reboot.  As of right now, everything should have full yum
> updates
> > and all having 4.2 rpms.  I have global maintenance mode on right now and
> > started hosted-engine on one of the three host and the status is
> currently:
> > Engine status : {"reason": "failed liveliness check”; "health": "bad",
> "vm":
> > "up", "detail": "Up"}
> >
> >
> > this is what I get when trying to enter hosted-vm --console
> >
> >
> > The engine VM is running on this host
> >
> > error: failed to get domain 'HostedEngine'
> >
> > error: Domain not found: no domain with matching name 'HostedEngine'
> >
> >
> > Here are logs from various sources when I start the VM on HOST3:
> >
> >
> > hosted-engine --vm-start
> >
> > Command VM.getStats with args {'vmID':
> > '4013c829-c9d7-4b72-90d5-6fe58137504c'} failed:
> >
> > (code=1, message=Virtual machine does not exist: {'vmId':
> > u'4013c829-c9d7-4b72-90d5-6fe58137504c'})
> >
> >
> > Jan 11 16:55:57 cultivar3 systemd-machined: New machine
> qemu-110-Cultivar.
> >
> > Jan 11 16:55:57 cultivar3 systemd: Started Virtual Machine
> > qemu-110-Cultivar.
> >
> > Jan 11 16:55:57 cultivar3 systemd: Starting Virtual Machine
> > qemu-110-Cultivar.
> >
> > Jan 11 16:55:57 cultivar3 kvm: 3 guests now active
> >
> >
> > ==> /var/log/vdsm/vdsm.log <==
> >
> >   File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 48,
> in
> > method
> >
> > ret = func(*args, **kwargs)
> >
> >   File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line
> 2718, in
> > getStorageDomainInfo
> >
> > dom = self.validateSdUUID(sdUUID)
> >
> >   File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line
> 304, in
> > validateSdUUID
> >
> > sdDom.validate()
> >
> >   File "/usr/lib/python2.7/site-packages/vdsm/storage/fileSD.py", line
> 515,
> > in validate
> >
> > raise se.StorageDomainAccessError(self.sdUUID)
> >
> > StorageDomainAccessError: Domain is either partially accessible or
> entirely
> > inaccessible: (u'248f46f0-d793-4581-9810-c9d965e2f286',)
> >
> > jsonrpc/2::ERROR::2018-01-11
> > 16:55:16,144::dispatcher::82::storage.Dispatcher::(wrapper) FINISH
> > getStorageDomainInfo error=Domain is either partially accessible or
> entirely
> > inaccessible: (u'248f46f0-d793-4581-9810-c9d965e2f286',)
> >
> >
> > ==> /var/log/libvirt/qemu/Cultivar.log <==
> >
> > LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
> > QEMU_AUDIO_DRV=spice /usr/libexec/qemu-kvm -name
> > guest=Cultivar,debug-threads=on -S -object
> > secret,id=masterKey0,format=raw,file=/var/lib/libvirt/
> qemu/domain-108-Cultivar/master-key.aes
> > -machine pc-i440fx-rhel7.3.0,accel=kvm,usb=off,dump-guest-core=off -cpu
> > Conroe -m 8192 -realtime mlock=off -smp
> > 2,maxcpus=16,sockets=16,cores=1,threads=1 -uuid
> > 4013c829-c9d7-4b72-90d5-6fe58137504c -smbios
> > 'type=1,manufacturer=oVirt,product=oVirt
> > Node,version=7-4.1708.el7.centos,serial=44454C4C-4300-
> 1034-8035-CAC04F424331,uuid=4013c829-c9d7-4b72-90d5-6fe58137504c'
> > -no-user-config -nodefaults -chardev
> > socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-
> 108-Cultivar/monitor.sock,server,nowait
> > -mon chardev=charmonitor,id=monitor,mode=control -rtc
> > base=2018-01-11T20:33:19,driftfix=slew -global
> > kvm-pit.lost_tick_policy=delay -no-hpet -no-reboot -boot strict=on
> -device
> > piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device
> > virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive
> > file=/var/run/vdsm/storage/248f46f0-d793-4581-9810-
> c9d965e2f286/c2dde892-f978-4dfc-a421-c8e04cf387f9/23aa0a66-fa6c-4967-a1e5-
> fbe47c0cd705,format=raw,if=none,id=drive-virtio-disk0,
> serial=c2dde892-f978-4dfc-a421-c8e04cf387f9,cache=none,
> werror=stop,rerror=stop,aio=threads
> > -device
> > virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-
> virtio-disk0,id=virtio-disk0,bootindex=1
> > -drive if=none,id=drive-ide0-1-0,readonly=on -device
> > ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev
> > 

Re: [ovirt-users] mount_options for hosted_engine storage domain

2018-01-12 Thread Simone Tiraboschi
On Fri, Jan 12, 2018 at 1:22 PM, Artem Tambovskiy <
artem.tambovs...@gmail.com> wrote:

> Hi,
>
> I have deployed a small cluster with 2 ovirt hosts and GlusterFS cluster
> some time ago. And recently during software upgrade I noticed that I made
> some mistakes during the installation:
>
> if the host which was deployed first will be taken down for upgrade
> (powered off or rebooted) the engine becomes unavailable (even all VM's and
> hosted engine were migrated to second host in advance).
>
> I was thinking that this is due to missing mnt_options=backup-volfile--
> servers=host1.domain.com;host2.domain.com option for hosted engine
> storage domain.
> Is there any good way to fix this? I have tried
> edit /etc/ovirt-hosted-engine/hosted-engine.conf manually to add missing
> mnt_options but after while I noticed that those changes are gone.
>

The master copy used at host-deploy time is on the shared storage domain,
you can change it with:
hosted-engine --set-shared-conf mnt_options=backup-volfile--servers=
host1.domain.com;host2.domain.com

And then edit /etc/ovirt-hosted-engine/hosted-engine.conf and restart
ovirt-ha-agent on existing HE hosts.



>
> Any suggestions?
>
> Thanks in advance!
> Artem
>
>
>
>
> ___
> 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] mount_options for hosted_engine storage domain

2018-01-12 Thread Artem Tambovskiy
Hi,

I have deployed a small cluster with 2 ovirt hosts and GlusterFS cluster
some time ago. And recently during software upgrade I noticed that I made
some mistakes during the installation:

if the host which was deployed first will be taken down for upgrade
(powered off or rebooted) the engine becomes unavailable (even all VM's and
hosted engine were migrated to second host in advance).

I was thinking that this is due to missing
mnt_options=backup-volfile--servers=host1.domain.com;host2.domain.com
option for hosted engine storage domain.
Is there any good way to fix this? I have tried
edit /etc/ovirt-hosted-engine/hosted-engine.conf manually to add missing
mnt_options but after while I noticed that those changes are gone.

Any suggestions?

Thanks in advance!
Artem
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] Ovirt 4.2 Bug with Permissons on the Vm Portal?

2018-01-12 Thread Giorgio Biacchi

It's the same for me also.

Ovirt is connected to FreeIPA this time, so it seems not to be bound to a 
specific AAA engine extension.


Do we have to submit a new bug on bugzilla??

Regards

On 01/11/2018 02:04 PM, Latchezar Filtchev wrote:

Hi Guys,

The same here. Upgrade 4.1.8 to 4.2. oVirt connected to Active Directory. User 
cannot see machines in VM portal. Still playing with permissions.


Any ideas?

Thank you!

Best,

Latcho

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

*Sent:* Monday, January 08, 2018 3:17 PM
*To:* users@ovirt.org
*Subject:* [ovirt-users] Ovirt 4.2 Bug with Permissons on the Vm Portal?

Hello Guys,

i recently upgrade to 4.2

We used the User Portal before. Every User could see his__ VM´s, every Admin 
just could see his VM´s ( User View ).


After the Update:

Admin´s can see every VM in VM Portal

The Users can´t see Vm´s anymore. The Portal is Empty. Role “UserVMManager” is 
set.

We tested some Scenarios: If the User create a new Virtual Machine, it is shown 
in the VM Portal. When he log out and in again -> VM is gone in his View


Admin View: The VM was created, Permission where set. Everything seems to be 
good.

Any Ideas? Thanks Guys__



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



--
gb

PGP Key: http://pgp.mit.edu/
Primary key fingerprint: C510 0765 943E EBED A4F2 69D3 16CC DC90 B9CB 0F34
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


[ovirt-users] unable to bring up hosted engine after botched 4.2 upgrade

2018-01-12 Thread Jayme
Please help, I'm really not sure what else to try at this point.  Thank you
for reading!


I'm still working on trying to get my hosted engine running after a botched
upgrade to 4.2.  Storage is NFS mounted from within one of the hosts.  Right
now I have 3 centos7 hosts that are fully updated with yum packages from
ovirt 4.2, the engine was fully updated with yum packages and failed to
come up after reboot.  As of right now, everything should have full yum
updates and all having 4.2 rpms.  I have global maintenance mode on right
now and started hosted-engine on one of the three host and the status is
currently: Engine status : {"reason": "failed liveliness check”; "health":
"bad", "vm": "up", "detail": "Up"}


this is what I get when trying to enter hosted-vm --console


The engine VM is running on this host

error: failed to get domain 'HostedEngine'

error: Domain not found: no domain with matching name 'HostedEngine'


Here are logs from various sources when I start the VM on HOST3:


hosted-engine --vm-start

Command VM.getStats with args {'vmID':
'4013c829-c9d7-4b72-90d5-6fe58137504c'} failed:

(code=1, message=Virtual machine does not exist: {'vmId':
u'4013c829-c9d7-4b72-90d5-6fe58137504c'})


Jan 11 16:55:57 cultivar3 systemd-machined: New machine qemu-110-Cultivar.

Jan 11 16:55:57 cultivar3 systemd: Started Virtual Machine
qemu-110-Cultivar.

Jan 11 16:55:57 cultivar3 systemd: Starting Virtual Machine
qemu-110-Cultivar.

Jan 11 16:55:57 cultivar3 kvm: 3 guests now active


==> /var/log/vdsm/vdsm.log <==

  File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 48, in
method

ret = func(*args, **kwargs)

  File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 2718,
in getStorageDomainInfo

dom = self.validateSdUUID(sdUUID)

  File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 304, in
validateSdUUID

sdDom.validate()

  File "/usr/lib/python2.7/site-packages/vdsm/storage/fileSD.py", line 515,
in validate

raise se.StorageDomainAccessError(self.sdUUID)

StorageDomainAccessError: Domain is either partially accessible or entirely
inaccessible: (u'248f46f0-d793-4581-9810-c9d965e2f286',)

jsonrpc/2::ERROR::2018-01-11
16:55:16,144::dispatcher::82::storage.Dispatcher::(wrapper) FINISH
getStorageDomainInfo error=Domain is either partially accessible or
entirely inaccessible: (u'248f46f0-d793-4581-9810-c9d965e2f286',)


==> /var/log/libvirt/qemu/Cultivar.log <==

LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
QEMU_AUDIO_DRV=spice /usr/libexec/qemu-kvm -name
guest=Cultivar,debug-threads=on -S -object
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-108-Cultivar/master-key.aes
-machine pc-i440fx-rhel7.3.0,accel=kvm,usb=off,dump-guest-core=off -cpu
Conroe -m 8192 -realtime mlock=off -smp
2,maxcpus=16,sockets=16,cores=1,threads=1 -uuid
4013c829-c9d7-4b72-90d5-6fe58137504c -smbios
'type=1,manufacturer=oVirt,product=oVirt
Node,version=7-4.1708.el7.centos,serial=44454C4C-4300-1034-8035-CAC04F424331,uuid=4013c829-c9d7-4b72-90d5-6fe58137504c'
-no-user-config -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-108-Cultivar/monitor.sock,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc
base=2018-01-11T20:33:19,driftfix=slew -global
kvm-pit.lost_tick_policy=delay -no-hpet -no-reboot -boot strict=on -device
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive
file=/var/run/vdsm/storage/248f46f0-d793-4581-9810-c9d965e2f286/c2dde892-f978-4dfc-a421-c8e04cf387f9/23aa0a66-fa6c-4967-a1e5-fbe47c0cd705,format=raw,if=none,id=drive-virtio-disk0,serial=c2dde892-f978-4dfc-a421-c8e04cf387f9,cache=none,werror=stop,rerror=stop,aio=threads
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
-drive if=none,id=drive-ide0-1-0,readonly=on -device
ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev
tap,fd=30,id=hostnet0,vhost=on,vhostfd=32 -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=00:16:3e:7f:d6:83,bus=pci.0,addr=0x3
-chardev
socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/4013c829-c9d7-4b72-90d5-6fe58137504c.com.redhat.rhevm.vdsm,server,nowait
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm
-chardev
socket,id=charchannel1,path=/var/lib/libvirt/qemu/channels/4013c829-c9d7-4b72-90d5-6fe58137504c.org.qemu.guest_agent.0,server,nowait
-device
virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0
-chardev spicevmc,id=charchannel2,name=vdagent -device
virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel2,id=channel2,name=com.redhat.spice.0
-chardev
socket,id=charchannel3,path=/var/lib/libvirt/qemu/channels/4013c829-c9d7-4b72-90d5-6fe58137504c.org.ovirt.hosted-engine-setup.0,server,nowait
-device

Re: [ovirt-users] wheel next to the up triangle in the UI

2018-01-12 Thread Luca 'remix_tj' Lorenzetto
On Fri, Jan 12, 2018 at 10:12 AM, Nathanaël Blanchet  wrote:
> You're right, if I manually stop and restart the vm through the ui, the
> wheel disappears. But, restarting the vm with vagrant, the wheel comes back,
> so I guess it comes from sdk4 action (ansible/vagrant), while I first
> guessed it came from cloud-init.


It's not directly related with cloud-init. If you want to use
cloud-init, vm has to start with "Run Once". That's why you find the
wheel.

Luca

-- 
"E' assurdo impiegare gli uomini di intelligenza eccellente per fare
calcoli che potrebbero essere affidati a chiunque se si usassero delle
macchine"
Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716)

"Internet è la più grande biblioteca del mondo.
Ma il problema è che i libri sono tutti sparsi sul pavimento"
John Allen Paulos, Matematico (1945-vivente)

Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] wheel next to the up triangle in the UI

2018-01-12 Thread Nathanaël Blanchet
You're right, if I manually stop and restart the vm through the ui, the 
wheel disappears. But, restarting the vm with vagrant, the wheel comes 
back, so I guess it comes from sdk4 action (ansible/vagrant), while I 
first guessed it came from cloud-init.



Le 11/01/2018 à 19:31, Luca 'remix_tj' Lorenzetto a écrit :

I suppose is because they're started with  "run once".

Happens the same also when you deploy with ansible using cloud-init. I 
think with vagrant is the same.


Luca

Il 11 gen 2018 7:24 PM, "Nathanaël Blanchet" > ha scritto:


Hi all,

I'm using vagrant ovirt4 plugin to provision some vms, and I
noticed that a wheel is still present next to the up status of
those vms. What does that mean?

-- 
Nathanaël Blanchet


Supervision réseau
Pôle Infrastrutures Informatiques
227 avenue Professeur-Jean-Louis-Viala


34193 MONTPELLIER CEDEX 5
Tél. 33 (0)4 67 54 84 55
Fax  33 (0)4 67 54 84 14
blanc...@abes.fr 

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




--
Nathanaël Blanchet

Supervision réseau
Pôle Infrastrutures Informatiques
227 avenue Professeur-Jean-Louis-Viala
34193 MONTPELLIER CEDEX 5   
Tél. 33 (0)4 67 54 84 55
Fax  33 (0)4 67 54 84 14
blanc...@abes.fr

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


[ovirt-users] [ANN] oVirt 4.2.1 First Release Candidate is now available

2018-01-12 Thread Sandro Bonazzola
The oVirt Project is pleased to announce the availability of the oVirt
4.2.1 First Release Candidate, as of January 12th, 2017

This update is the first in a series of stabilization updates to the 4.2
series.

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

This release supports Hypervisor Hosts running:
* Red Hat Enterprise Linux 7.4 or later
* CentOS Linux (or similar) 7.4 or later
* oVirt Node 4.2

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

Notes:
- oVirt Appliance is already available
- oVirt Live is already available [2]
- oVirt Node will be available soon [2]

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

[1] http://www.ovirt.org/release/4.2.1/
[2] http://resources.ovirt.org/pub/ovirt-4.2-pre/iso/

-- 

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R

Red Hat EMEA 

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


[ovirt-users] unlock_entity.sh oVirt 4.2

2018-01-12 Thread Grundmann, Christian
Hi,
i have a VM on oVirt 4.2 which is locked after a snapshot revert.

i unlocked the disk/snapshot and vm with unlock_entity.sh

it now shows no locks

/usr/share/ovirt-engine/setup/dbutils/unlock_entity.sh -t all -q
Locked VMs:

Locked templates:

Locked disks:

Locked snapshots:


But the VM still shows "Image Locked"

How can I unlock them?

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