Re: [ovirt-users] vm freezes when using yum update

[M Mahboubian]

Hi Yaniv,
Thanks for your reply. Apologies for my late reply we had a long holiday here. 
To answer you:
Yes the  guest VM become completely frozen and non responsive as soon as its 
disk has any activity for example when we shutdown or do a yum update. 

Versions of all the components involved - guest OS, host OS (qemu-kvm version), 
how do you run the VM (vdsm log would be helpful here), exact storage 
specification (1Gb or 10Gb link? What is the NFS version? What is it hosted on? 
etc.) Y.
Some facts about our environment:
1) Previously, this environment was using XEN using raw disk and we change it 
to Ovirt (Ovirt were able to read the VMs's disks without any conversion.) 2) 
The issue we are facing is not happening for any of the existing VMs. 3) This 
issue only happens for new VMs.4) Guest (kernel v3.10) and host(kernel v4.1) 
OSes are both CentOS 7 minimal installation. 5) NFS version 4 and Using Ovirt 
4.16) The network speed is 1 GB.7) The output for rpm -qa | grep qemu-kvm 
shows:     qemu-kvm-common-ev-2.6.0-28.e17_3.6.1.x86_64
     qemu-kvm-tools-ev-2.6.0-28.e17_3.6.1.x86_64     
qemu-kvm-ev-2.6.0-28.e17_3.6.1.x86_648) The storage is from a SAN device which 
is connected to the NFS server using fiber channel.
So for example during shutdown also it froze and shows something like this in 
event section:
VM ILMU_WEB has been paused due to storage I/O problem.

More information:
VDSM log at the time of this issue (The issue happened at Jul 3, 2017 9:50:43 
AM):
2017-07-03 09:50:37,113+0800 INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer] RPC call 
Host.getAllVmStats succeeded in 0.00 seconds (__init__:515)
2017-07-03 09:50:37,897+0800 INFO  (jsonrpc/1) [jsonrpc.JsonRpcServer] RPC call 
Host.getAllVmIoTunePolicies succeeded in 0.02 seconds (__init__:515)
2017-07-03 09:50:42,510+0800 INFO  (jsonrpc/2) [jsonrpc.JsonRpcServer] RPC call 
Host.getAllVmStats succeeded in 0.00 seconds (__init__:515)
2017-07-03 09:50:43,548+0800 INFO  (jsonrpc/3) [dispatcher] Run and protect: 
repoStats(options=None) (logUtils:51)
2017-07-03 09:50:43,548+0800 INFO  (jsonrpc/3) [dispatcher] Run and protect: 
repoStats, Return response: {u'e01186c1-7e44-4808-b551-4722f0f8e84b': {'code': 
0, 'actual': True, 'version': 4, 'acquired': True, 'delay': '0.000144822', 
'lastCheck': '8.9', 'valid': True}, u'721b5233-b0ba-4722-8a7d-ba2a372190a0': 
{'code': 0, 'actual': True, 'version': 4, 'acquired': True, 'delay': 
'0.000327909', 'lastCheck': '8.9', 'valid': True}, 
u'94775bd3-3244-45b4-8a06-37eff8856afa': {'code': 0, 'actual': True, 'version': 
4, 'acquired': True, 'delay': '0.000256425', 'lastCheck': '8.9', 'valid': 
True}, u'731bb771-5b73-4b5c-ac46-56499df97721': {'code': 0, 'actual': True, 
'version': 0, 'acquired': True, 'delay': '0.000238159', 'lastCheck': '8.9', 
'valid': True}, u'f620781f-93d4-4410-8697-eb41045cacd6': {'code': 0, 'actual': 
True, 'version': 4, 'acquired': True, 'delay': '0.00022004', 'lastCheck': 
'8.9', 'valid': True}, u'a1a7d0a4-e3b6-4bd5-862b-96e70dae3f29': {'code': 0, 
'actual': True, 'version': 0, 'acquired': True, 'delay': '0.000298581', 
'lastCheck': '8.8', 'valid': True}} (logUtils:54)
2017-07-03 09:50:43,563+0800 INFO  (jsonrpc/3) [jsonrpc.JsonRpcServer] RPC call 
Host.getStats succeeded in 0.01 seconds (__init__:515)
2017-07-03 09:50:46,737+0800 INFO  (periodic/3) [dispatcher] Run and protect: 
getVolumeSize(sdUUID=u'721b5233-b0ba-4722-8a7d-ba2a372190a0', 
spUUID=u'b04ca6e4-2660-4eaa-acdb-c1dae4e21f2d', 
imgUUID=u'3c26476e-1dae-44d7-9208-531b91ae5ae1', 
volUUID=u'a7e789fb-6646-4d0a-9b51-f5ab8242c8d5', options=None) (logUtils:51)
2017-07-03 09:50:46,738+0800 INFO  (periodic/0) [dispatcher] Run and protect: 
getVolumeSize(sdUUID=u'f620781f-93d4-4410-8697-eb41045cacd6', 
spUUID=u'b04ca6e4-2660-4eaa-acdb-c1dae4e21f2d', 
imgUUID=u'2158fdae-54e1-413d-a844-73da5d1bb4ca', 
volUUID=u'6ee0b0eb-0bba-4e18-9c00-c1539b632e8a', options=None) (logUtils:51)
2017-07-03 09:50:46,740+0800 INFO  (periodic/2) [dispatcher] Run and protect: 
getVolumeSize(sdUUID=u'f620781f-93d4-4410-8697-eb41045cacd6', 
spUUID=u'b04ca6e4-2660-4eaa-acdb-c1dae4e21f2d', 
imgUUID=u'a967016d-a56b-41e8-b7a2-57903cbd2825', 
volUUID=u'784514cb-2b33-431c-b193-045f23c596d8', options=None) (logUtils:51)
2017-07-03 09:50:46,741+0800 INFO  (periodic/1) [dispatcher] Run and protect: 
getVolumeSize(sdUUID=u'721b5233-b0ba-4722-8a7d-ba2a372190a0', 
spUUID=u'b04ca6e4-2660-4eaa-acdb-c1dae4e21f2d', 
imgUUID=u'bb35c163-f068-4f08-a1c2-28c4cb1b76d9', 
volUUID=u'fce7e0a0-7411-4d8c-b72c-2f46c4b4db1e', options=None) (logUtils:51)
2017-07-03 09:50:46,743+0800 INFO  (periodic/0) [dispatcher] Run and protect: 
getVolumeSize, Return response: {'truesize': '6361276416', 'apparentsize': 
'107374182400'} (logUtils:54)

2017-07-03 09:52:16,941+0800 INFO  (libvirt/events) [virt.vm] 
(vmId='c84f519e-398d-40a3-85b2-b7e53f3d7f67') abnormal vm stop device 
scsi0-0-0-0 error eio (vm:4112)
2017-07-03 09:52:16,941+0800 INFO  (libvirt/events) [virt.vm] 

Re: [ovirt-users] Failed to create template

[aduckers]

Thanks for the assistance.  Versions are:

vdsm.x86_64 4.19.15-1.el7.centos
ovirt-engine.noarch4.1.2.2-1.el7.centos 

Logs are attached.  The GUI shows a creation date of 2017-06-23 11:30:13 for 
the disk image that is stuck finalizing, so that might be a good place to start 
in the logs.




logs.tar.z
Description: Unix compressed data


> On Jul 2, 2017, at 3:52 AM, Fred Rolland  wrote:
> 
> Hi,
> 
> Thanks for the logs.
> 
> What exact version are you using ? (VDSM,engine)
> 
> Regarding the upload issue, can you please provide imageio-proxy and 
> imageio-daemon logs ?
> Issue in [1] looks with the same symptoms, but we need more info.
> 
> Regarding the template issue, it looks like [2]. 
> There were some issues when calculating the estimated size target volume, 
> that should be already fixed.
> Please provide the exact versions, so I can check if it includes the fixes.
> 
> Thanks,
> 
> Fred
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1357269
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1448606
> 
> 
> On Fri, Jun 30, 2017 at 5:11 AM, aduckers  wrote:
> 
> 
> Attached.  I’ve also got an image upload to the ISO domain stuck in 
> “Finalizing”, and can’t cancel or clear it.  Not sure if related or not, but 
> it might show in the logs and if that can be cleared that’d be great too.
> 
> Thanks
> 
>  
>> On Jun 29, 2017, at 9:20 AM, Fred Rolland  wrote:
>> 
>> Can you please attach engine and Vdsm logs ?
>> 
>> On Thu, Jun 29, 2017 at 6:21 PM, aduckers  wrote:
>> I’m running 4.1 with a hosted engine, using FC SAN storage.  I’ve uploaded a 
>> qcow2 image, then created a VM and attached that image.
>> When trying to create a template from that VM, we get failures with:
>> 
>> failed: low level image copy failed
>> VDSM command DeleteImageGroupVDS failed: Image does not exist in domain
>> failed to create template
>> 
>> What should I be looking at to resolve this?  Anyone recognize this issue?
>> 
>> 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

[ovirt-users] vdsm (4.1) restarts glusterd when activating a node, even if it's already running

[Darrell Budic]

Upgrading some nodes today, and noticed that vdsmd restarts glusterd on a node 
when it activates it. This is causing a short break in healing when the shd 
gets disconnected, forcing some extra healing when the healing process reports 
“Transport Endpoint Disconnected” (N/A in the ovirt gui).

This is on a converged cluster (3 nodes, gluster replica volume across all 3, 
ovirt-engine running elsewhere). Centos 7 install, just upgraded to Ovirt 
4.1.2, running cluster 3.10 from the Centos SIG.

The process I’m observing:

Place a node into maintenance via GUI
Update node from command line
Reboot node (kernel update)
Watch gluster heal itself after reboot
Activate node in GUI
gluster is completely stopped on this node
gluster is started on this node
healing begins again, but isn’t working
“gluster vol heal  info” reports this node’s information not available 
because “Transport endpoint not connected”.
This clears up in 5-10 minutes, then volume heals normally

Someone with a similar setup want to check this and see if it’s something 
specific to my nodes, or just a general problem with the way it’s restarting 
gluster? Looking for a little confirmation before I file a bug report on it.

Or a dev want to comment on why it stops and starts gluster, instead of a 
restart which would presumably leave the brick processes and shd running and 
not causing this effect?

Thanks,

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

[ovirt-users] vdsm changing disk scheduler when starting, configurable?

[Darrell Budic]

It seems vdsmd under 4.1.x (or something under it’s control) changes the disk 
schedulers when it starts or a host node is activated, and I’d like to avoid 
this. Is it preventable? Or configurable anywhere? This was probably happening 
under earlier version, but I just noticed it while upgrading some converged 
boxes today.

It likes to set deadline, which I understand is the RHEL default for centos 7 
on non SATA disks. But I’d rather have NOOP on my SSDs because SSDs, and NOOP 
on my SATA spinning platters because ZFS does it’s own scheduling, and running 
anything other than NOOP can cause increased CPU utilization for no gain. It’s 
also fighting ZFS, which tires to set NOOP on whole disks it controls, and my 
kernel command line setting.

Thanks,

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

Re: [ovirt-users] Cloning VM on NFS Leads to Locked Disks

[Fred Rolland]

Seems you hit [1].
Can you tell me what is the exact version of the engine ?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1395793

On Thu, May 11, 2017 at 10:29 PM, Charles Tassell 
wrote:

> Sure, it's pretty big so I've put it online for download at
> http://krissy.islandadmin.ca/public/engine.log.txt
>
>
> On 2017-05-11 04:08 PM, Fred Rolland wrote:
>
> The locking is on the engine side and restarting the vdsm will not affect
> it .
> Can you send the whole engine log ?
> Which exact version are you using ?
>
>
> On Thu, May 11, 2017 at 9:30 PM, Charles Tassell 
> wrote:
>
>> Just as an update, I created a new VM and had the same issue: the disk
>> remains locked.  So I then added a new data store (this one iSCSI not NFS)
>> and create a new VM on that.  Again, the disk remains locked.  So the
>> problem seems to be that any action that sets to modify a disk image on my
>> cluster locks the disk and keeps it locked permanently.
>>
>> I tried restarting the vdsm daemon, but that didn't make a difference.
>> I'm seeing this in my sanlock.log file though, which worries me:
>>
>>
>> 017-05-07 07:51:41-0300 1738538 [13575]: s2 renewal error -202
>> delta_length 10 last_success 1738508
>> 2017-05-07 07:51:41-0300 1738538 [11513]: s1 renewal error -202
>> delta_length 10 last_success 1738508
>>
>> Here's the last 20 lines:
>> 2017-05-07 07:51:41-0300 1738538 [13580]: s3 renewal error -202
>> delta_length 10 last_success 1738508
>> 2017-05-07 07:51:41-0300 1738538 [13575]: 20423d5e aio timeout RD
>> 0x7fe1440008c0:0x7fe1440008d0:0x7fe160255000 ioto 10 to_count 67
>> 2017-05-07 07:51:41-0300 1738538 [13575]: s2 delta_renew read timeout 10
>> sec offset 0 /rhev/data-center/mnt/192.168.130.217:_media_ovirt/20423d5e-
>> 188c-4e10-9893-588ceb81b354/dom_md/ids
>> 2017-05-07 07:51:41-0300 1738538 [13575]: s2 renewal error -202
>> delta_length 10 last_success 1738508
>> 2017-05-07 07:51:41-0300 1738538 [11513]: hosted-e aio timeout RD
>> 0x7fe1480008c0:0x7fe1480008d0:0x7fe14e6fc000 ioto 10 to_count 65
>> 2017-05-07 07:51:41-0300 1738538 [11513]: s1 delta_renew read timeout 10
>> sec offset 0 /var/run/vdsm/storage/5dccd07d-a923-4d4b-9cb1-3b51ebfdca4d/
>> 5a9c284f-0faa-4a25-94ce-c9efdae07484/ab2443f1-95ed-475d-886c-c1653257cf04
>> 2017-05-07 07:51:41-0300 1738538 [11513]: s1 renewal error -202
>> delta_length 10 last_success 1738508
>> 2017-05-07 07:51:47-0300 1738544 [13575]: 20423d5e aio collect RD
>> 0x7fe1440008c0:0x7fe1440008d0:0x7fe160255000 result 1048576:0 match reap
>> 2017-05-07 07:51:47-0300 1738544 [13580]: 5dccd07d aio collect RD
>> 0x7fe13c0008c0:0x7fe13c0008d0:0x7fe14e5fa000 result 1048576:0 match reap
>> 2017-05-07 07:51:47-0300 1738544 [11513]: hosted-e aio collect RD
>> 0x7fe1480008c0:0x7fe1480008d0:0x7fe14e6fc000 result 1048576:0 match reap
>> 2017-05-07 07:53:57-0300 1738674 [13590]: s2:r15 resource
>> 20423d5e-188c-4e10-9893-588ceb81b354:SDM:/rhev/data-center/
>> mnt/192.168.130.217:_media_ovirt/20423d5e-188c-4e10-9893-
>> 588ceb81b354/dom_md/leases:1048576 for 7,21,78395
>> 2017-05-07 07:59:49-0300 1739027 [13575]: s2 delta_renew long write time
>> 10 sec
>> 2017-05-09 08:38:34-0300 1914151 [13590]: s2:r16 resource
>> 20423d5e-188c-4e10-9893-588ceb81b354:SDM:/rhev/data-center/
>> mnt/192.168.130.217:_media_ovirt/20423d5e-188c-4e10-9893-
>> 588ceb81b354/dom_md/leases:1048576 for 7,21,78395
>> 2017-05-11 15:07:45-0300 2110302 [13590]: s2:r17 resource
>> 20423d5e-188c-4e10-9893-588ceb81b354:SDM:/rhev/data-center/
>> mnt/192.168.130.217:_media_ovirt/20423d5e-188c-4e10-9893-
>> 588ceb81b354/dom_md/leases:1048576 for 7,21,112346
>> 2017-05-11 15:17:24-0300 2110881 [13590]: s4 lockspace
>> b010093e-1924-46e1-bd57-2cf2b2445087:1:/dev/b010093e-1924-
>> 46e1-bd57-2cf2b2445087/ids:0
>> 2017-05-11 15:17:45-0300 2110902 [1395]: s4 host 1 1 2110881
>> 44ae07eb-3371-4750-8728-ab3b049dbae2.ovirt730-0
>> 2017-05-11 15:17:45-0300 2110902 [1400]: s4:r18 resource
>> b010093e-1924-46e1-bd57-2cf2b2445087:SDM:/dev/b010093e-1924-
>> 46e1-bd57-2cf2b2445087/leases:1048576 for 7,21,112346
>> 2017-05-11 15:17:52-0300 2110909 [1399]: s5 lockspace
>> b010093e-1924-46e1-bd57-2cf2b2445087:1:/dev/b010093e-1924-
>> 46e1-bd57-2cf2b2445087/ids:0
>> 2017-05-11 15:18:13-0300 2110930 [1395]: s5 host 1 2 2110909
>> 44ae07eb-3371-4750-8728-ab3b049dbae2.ovirt730-0
>> 2017-05-11 15:18:13-0300 2110930 [1395]: s5 host 2 1 2110065
>> 4d31313f-b2dd-4368-bf31-d39835e10afb.ovirt730-0
>>
>>
>> On 2017-05-11 10:09 AM, Charles Tassell wrote:
>>
>> Hi Freddy,
>>
>>   Sure, thanks for looking into this.  Here you go:
>>
>> 2017-05-10 11:35:30,249-03 INFO  
>> [org.ovirt.engine.core.bll.aaa.SessionDataContainer]
>> (DefaultQuartzScheduler8) [1c84abac] Not removing session
>> 'vZyqrcCljPC7hQtcILsk4uDug3QsiinZBOyoGDiQKkYYT2znGyWe4fasrPb
>> jYxdjbfyR3DBnp+UZ9/k20dGsMA==', session has running commands for user
>> 'admin@internal-authz'.[snip]
>> On 2017-05-11 04:30 AM, Fred Rolland wrote:
>>
>> Hi,
>>
>> 

Re: [ovirt-users] Gluster issue with /var/lib/glusterd/peers/ file

[Gianluca Cecchi]

On Sun, Jul 2, 2017 at 2:08 AM, Mike DePaulo  wrote:

> Hi everyone,
>
> I have ovirt 4.1.1/4.1.2 running on 3 hosts with a gluster hosted engine.
>
> I was working on setting up a network for gluster storage and
> migration. The addresses for it will be 10.0.20.x, rather than
> 192.168.1.x for the management network.  However, I switched gluster
> storage and migration back over to the management network.
>
> I updated and rebooted one of my hosts (death-star, 10.0.20.52) and on
> reboot, the glusterd service would start, but wouldn't seem to work.
> The engine webgui reported that its bricks were down, and commands
> like this would fail:
>
> [root@death-star glusterfs]# gluster pool list
> pool list: failed
> [root@death-star glusterfs]# gluster peer status
> peer status: failed
>
> Upon further investigation, I had under /var/lib/glusterd/peers/ the 2
> existing UUID files, plus a new 3rd one:
> [root@death-star peers]# cat 10.0.20.53
> uuid=----
> state=0
> hostname1=10.0.20.53
>
> I moved that file out of there, restarted glusterd, and now gluster is
> working again.
>
> I am guessing that this is a bug. Let me know if I should attach other
> log files; I am not sure which ones.
>
> And yes, 10.0.20.53 is the IP of one of the other hosts.
>
> -Mike
>

Hello,
I'm trying to accomplish the same.
See also comments here at my answer today:
http://lists.ovirt.org/pipermail/users/2017-July/082990.html

So at the end you rollback?

Can you list with detail what were your modifications and operating steps
with hosts, before trying to restart with the new network config?
Did you try to set the new network as gluster role in oVirt?

I'm using 4 volumes at the moment: data, engine, iso, export and based on
some analysis that I'm doing right now, one should modify at least these
files for each vol_name accordingly under /var/lib/glusterd on the 3 hosts:

./vols/vol_name/info
./vols/vol_name/bricks/ovirt01.localdomain.local:-gluster-brick1-engine
./vols/vol_name/bricks/ovirt02.localdomain.local:-gluster-brick1-engine
./vols/vol_name/bricks/ovirt03.localdomain.local:-gluster-brick1-engine
./vols/vol_name/trusted-engine.tcp-fuse.vol
./vols/vol_name/engine.tcp-fuse.vol

plus one has to rename 3 of these files themselves. Suppose hostnames are
ovirtN.localdomain.local and that you decide to assign hostname
glovirtN.localdomain.local to the interfaces on the new gluster network,
they should become:

./vols/vol_name/bricks/glovirt01.localdomain.local:-gluster-brick1-engine
./vols/vol_name/bricks/glovirt02.localdomain.local:-gluster-brick1-engine
./vols/vol_name/bricks/glovirt03.localdomain.local:-gluster-brick1-engine


And also change these files on each node (with related uid files of the
other two nodes)s:

./peers/ec81a04c-a19c-4d31-9d82-7543cefe79f3
./peers/e9717281-a356-42aa-a579-a4647a29a0bc
./glustershd/glustershd-server.vol

I see no problems for the migration network chenage though. I did it,
changing role in check box under Cluster --> Default --> Logical Networks
subpane --> Manage Networks
You have to assign an ip to the interface for every host in Hosts -->
Network Interfaces --> Setup Host Networks

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

Re: [ovirt-users] Storage, extend or new lun ?

[Fred Rolland]

Hi,

You can manually do the resize (Steps here are for FC) :
- Move the Storage Domain to maintenance
- First locate the LUN ID you want to refresh with :multipath -ll
On each hosts:
 - Run : rescan-scsi-bus.sh
 - Run: multipathd resize map 3600a0b800075de8f0e3a52ddf25f   (replace
with your LUN_ID)
 - Check that the size was updated in multipat -ll
On the SPM:
 - Run: pvresize  /dev/mapper/3600a0b800075de8f0e3a52ddf25f
 - Check with vgs

Move the domain to active again.
I am not sure that the engine will see the new size immediately. An engine
restart might be needed.

Regards,

Fred

On Wed, Jun 28, 2017 at 9:18 AM, Enrico Becchetti Gmail <
enrico.becche...@gmail.com> wrote:

>  Hi All,
> There are other ways to avoid using two lun ? If necessary I can also
> shutdown the entire cluster.
> thanks a lot !
> Bye
> Enrico
>
>
>
> Il 26/06/2017 12:32, Fred Rolland ha scritto:
>
> Hi,
>
> The support for refreshing the LUN size in an existing storage domain has
> been introduced in 3.6, so it is not relevant for you.
>
> You can add an additional LUN to an existing storage domain.
>
> Regards,
>
> Fred
>
> [1] https://www.ovirt.org/develop/release-management/features/
> storage/lun-resize/
>
> On Mon, Jun 26, 2017 at 9:35 AM, Enrico Becchetti Gmail <
> enrico.becche...@gmail.com> wrote:
>
>> Dear All,
>> I've oVirt 3.5.3-1-1.el6 with two kind of storage , NFS and Fibre
>> Channel.  Each Hypervisor
>> has HBA controller and Data CLutser has four Storage named: DATA_FC,
>> DATA_NFS, EXPORT
>> and ISO-DOMAIN.
>>
>> Anybody know how can I extend a DATA_FC ? Which is the best practies ?
>> Extend LUN from HP MSA controller or adding a new lun ?
>> if I extend lun inside HP MSA oVirt see the new size ?
>> Enrico
>> Thanks a lot.
>> Best 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] Cannot find master domain

[Fred Rolland]

Hi,

Can you provide the VDSM logs ?

Thanks,
Fred

On Sat, Jul 1, 2017 at 11:21 AM, Iman Darabi  wrote:

> hi.
> i moved my host to maintenance mode and upgrade it. then restarted server.
> after restarting, i activated server but the data domain is inactive and i
> get the following error:
>  "Cannot find master domain: 
> u'spUUID=9a1584cf-81bb-4ce8-975f-659e643a14b5,
> msdUUID=193072f2-9c4a-405c-86a8-c4b036413171'", 'code': 304
>
> The output of "multipath -v2" is as follows:
>
> Jul 01 12:38:34 | sdb: emc prio: path not correctly configured for failover
> Jul 01 12:38:34 | sdc: emc prio: path not correctly configured for failover
> Jul 01 12:38:34 | 3600508b1001cbeb7dc20cfc250a2e506: ignoring map
> Jul 01 12:38:34 | sdb: emc prio: path not correctly configured for failover
> Jul 01 12:38:34 | sdc: emc prio: path not correctly configured for failover
> Jul 01 12:38:34 | DM message failed [fail_if_no_path]
> reject: 3600601604d003a00036e268de611 undef DGC ,VNX5400WDVR
> size=2.0T features='0' hwhandler='1 emc' wp=undef
> |-+- policy='service-time 0' prio=0 status=undef
> | |- 12:0:0:16384 sdb 8:16 undef faulty running
> | `- 12:0:1:16384 sdc 8:32 undef faulty running
> |-+- policy='service-time 0' prio=50 status=undef
> | `- 11:0:1:0 sde 8:64 undef ready  running
> `-+- policy='service-time 0' prio=10 status=undef
>   `- 11:0:0:0 sdd 8:48 undef ready  running
>
> thanks.
>
> --
> R expert at Ferdowsi University of Mashhadhttps://ir.linkedin.com/in/ima
> ndarabi
> 
>
> ___
> 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] import data domain

[Elad Ben Aharon]

In which state was the domain before it got destroyed? If it was in
maintenance state and your oVirt version is higher than 4.0, the VMs
configuration files (ovf) are saved on the domain upon its movement to
maintenance.
Hence, in case it went through a graceful maintenance procedure, all
configuration of the VMs that had disks attached, reside on that domain,
should exist on it.
After import to this domain, you'll be able to register these VMs.

On Sat, Jul 1, 2017 at 11:34 AM, Iman Darabi  wrote:

> hi.
> what happen if we destroy a data domain and then again import it? do we
> lost all vm's and it's configurations?
>
> --
> R expert at Ferdowsi University of Mashhadhttps://ir.linkedin.com/in/ima
> ndarabi
> 
>
> ___
> 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] Failed to create template

[Fred Rolland]

Hi,

Thanks for the logs.

What exact version are you using ? (VDSM,engine)

Regarding the upload issue, can you please provide imageio-proxy and
imageio-daemon logs ?
Issue in [1] looks with the same symptoms, but we need more info.

Regarding the template issue, it looks like [2].
There were some issues when calculating the estimated size target volume,
that should be already fixed.
Please provide the exact versions, so I can check if it includes the fixes.

Thanks,

Fred

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1357269
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1448606


On Fri, Jun 30, 2017 at 5:11 AM, aduckers  wrote:

>
>
> Attached.  I’ve also got an image upload to the ISO domain stuck in
> “Finalizing”, and can’t cancel or clear it.  Not sure if related or not,
> but it might show in the logs and if that can be cleared that’d be great
> too.
>
> Thanks
>
>
>
> On Jun 29, 2017, at 9:20 AM, Fred Rolland  wrote:
>
> Can you please attach engine and Vdsm logs ?
>
> On Thu, Jun 29, 2017 at 6:21 PM, aduckers  wrote:
>
>> I’m running 4.1 with a hosted engine, using FC SAN storage.  I’ve
>> uploaded a qcow2 image, then created a VM and attached that image.
>> When trying to create a template from that VM, we get failures with:
>>
>> failed: low level image copy failed
>> VDSM command DeleteImageGroupVDS failed: Image does not exist in domain
>> failed to create template
>>
>> What should I be looking at to resolve this?  Anyone recognize this issue?
>>
>> 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] Upgrading HC from 4.0 to 4.1

[Gianluca Cecchi]

On Sat, Jul 1, 2017 at 8:51 PM, Doug Ingham  wrote:

>
> Only problem I would like to manage is that I have gluster network shared
>> with ovirtmgmt one.
>> Can I move it now with these updated packages?
>>
>
> Are the gluster peers configured with the same hostnames/IPs as your hosts
> within oVirt?
>

Yes.
>From gluster point of view:

[root@ovirt01 ~]# gluster peer status
Number of Peers: 2

Hostname: ovirt03.localdomain.local
Uuid: ec81a04c-a19c-4d31-9d82-7543cefe79f3
State: Peer in Cluster (Connected)

Hostname: ovirt02.localdomain.local
Uuid: b89311fe-257f-4e44-8e15-9bff6245d689
State: Peer in Cluster (Connected)
[root@ovirt01 ~]#

[root@ovirt02 ~]# gluster peer status
Number of Peers: 2

Hostname: ovirt03.localdomain.local
Uuid: ec81a04c-a19c-4d31-9d82-7543cefe79f3
State: Peer in Cluster (Connected)

Hostname: ovirt01.localdomain.local
Uuid: e9717281-a356-42aa-a579-a4647a29a0bc
State: Peer in Cluster (Connected)


In oVirt, the hosts are defined with Hostname/IP field as
ovirt01.localdomain.local
192.168.150.103
ovirt03.localdomain.local

I don't remember why for the second host I used its ip instead of its
hostname... possily I used the ip for test when adding it because I want to
crosscheck the "Name" and the "Hostname/IP" columns of Hosts tab (the host
from which I executed gdeploy was added with "Name" hosted_engine_1; I see
that field is editable... but not the "Hostname/IP" one obviously)
The node from which I initially executed the gdeploy job in 4.0.5 was
ovirt01.localdomain.local

BTW: during upgrade of hosts there was an errore with ansible19

Error: ansible1.9 conflicts with ansible-2.3.1.0-1.el7.noarch

So the solution for updating nodes after enabling ovirt 4.1 repo was:
yum remove ansible gdeploy
yum install ansible gdeploy
yum update

Probably the ansible and gdeploy packages are not neede any more after
initial deploy though. But they can come useful on hand in case of
maintenance of config files.



> Once they're configured on the same network, separating them might be a
> bit difficult. Also, the last time I looked, oVirt still doesn't support
> managing HCI oVirt/Gluster nodes running each service on a different
> interface (see below).
>
> In theory, the procedure would involve stopping all of the Gluster
> processes on all of the peers, updating the peer addresses in the gluster
> configs on all of the nodes, then restarting glusterd & the bricks. I've
> not tested this however, and it's not a "supported" procedure. I've no idea
> how oVirt would deal with these changes either.
>

I could try, creating a snapshot before, as the oVirt hosts are vsphere VMs
themselves.
But what about this new network configuration inside oVirt? Should I
configure it as gluster network within cluster "logical networks" tab with
an ip for each host configured within oVirt, or should I set the network as
unmanaged by oVirt at all?



>
>
> To properly separate my own storage & management networks from the
> beginning, I configured each host with 2 IPs on different subnets and a
> different hostname corresponding to each IP. For example, "v0" points to
> the management interface of the first node, and "s0" points to the storage
> interface.
>
> Do you have the gluster dedicated network configured as "gluster network"
in oVirt?



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