6:10 p.m.
Hello,
I'm testing GlusterFS on 3.3 with fedora 19 systems.
One engine (ovirt) + 2 nodes (ovnode01 and ovnode02)
Successfully created gluster volume composed by two bricks (one for
each vdsm node) distributed replicated
Suggestion:
If page
http://www.ovirt.org/Features/GlusterFS_Storage_Domain
is the reference, perhaps it would be better to explicitly specify
that one has to start the created volume before going to add a storage
domain based on the created volume.
Not knowing Gluster could lead to think that the start phase is
responsibility of storage domain creation itself ...
All seems ok from a configuration point of view.
Uploaded a CentOS 6.4 iso image ito my ISO_DOMAIN (nfs exported from
engine.. this will be another thread...)
Created a server VM with 10Gb of disk with thin allocation.
I get an error when starting the VM
on engine.log
2013-09-25 00:43:16,027 ERROR
[org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo]
(DefaultQuartzScheduler_Worker-44) Rerun vm
409c5dbe-5e70-40de-bf73-46ef484ea2d7. Called from vds ovnode02
2013-09-25 00:43:16,031 INFO
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(pool-6-thread-48) Correlation ID: 5ea15175, Job ID:
48128550-3633-4da4-8d9c-ab704be02f02, Call Stack: null, Custom Event
ID: -1, Message: Failed to run VM C6 on Host ovnode02.
2013-09-25 00:43:16,057 INFO [org.ovirt.engine.core.bll.RunVmCommand]
(pool-6-thread-48) Lock Acquired to object EngineLock [exclusiveLocks=
key: 409c5dbe-5e70-40de-bf73-46ef484ea2d7 value: VM
, sharedLocks= ]
2013-09-25 00:43:16,070 INFO
[org.ovirt.engine.core.vdsbroker.IsVmDuringInitiatingVDSCommand]
(pool-6-thread-48) START, IsVmDuringInitiatingVDSCommand( vmId =
409c5dbe-5e70-40de-bf73-46ef484ea2d7), log id: 7979c53b
2013-09-25 00:43:16,071 INFO
[org.ovirt.engine.core.vdsbroker.IsVmDuringInitiatingVDSCommand]
(pool-6-thread-48) FINISH, IsVmDuringInitiatingVDSCommand, return:
false, log id: 7979c53b
2013-09-25 00:43:16,086 INFO [org.ovirt.engine.core.bll.RunVmCommand]
(pool-6-thread-48) Running command: RunVmCommand internal: false.
Entities affected : ID: 409c5dbe-5e70-40de-bf73-46ef484ea2d7 Type: VM
2013-09-25 00:43:16,110 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.IsoPrefixVDSCommand]
(pool-6-thread-48) START, IsoPrefixVDSCommand( storagePoolId =
6b3175e6-6fa2-473f-ba21-38917c413ba9, ignoreFailoverLimit = false),
log id: 7fd62f0f
2013-09-25 00:43:16,111 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.IsoPrefixVDSCommand]
(pool-6-thread
...
On node vdsm.log
Thread-2915::ERROR::2013-09-25
00:43:20,108::vm::2062::vm.Vm::(_startUnderlyingVm)
vmId=`409c5dbe-5e70-40de-bf73-46ef484ea2d7`::The vm start process
failed
Traceback (most recent call last):
File "/usr/share/vdsm/vm.py", line 2022, in _startUnderlyingVm
self._run()
File "/usr/share/vdsm/vm.py", line 2906, in _run
self._connection.createXML(domxml, flags),
File "/usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py",
line 76, in wrapper
ret = f(*args, **kwargs)
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2805, in createXML
if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
libvirtError: Unable to read from monitor: Connection reset by peer
Thread-2915::DEBUG::2013-09-25
00:43:20,176::vm::2448::vm.Vm::(setDownStatus)
vmId=`409c5dbe-5e70-40de-bf73-46ef484ea2d7`::Changed state to Down:
Unable to read from monitor: Connection reset by peer
libvirtEventLoop::WARNING::2013-09-25
00:43:20,114::clientIF::337::vds::(teardownVolumePath) Drive is not a
vdsm image: VOLWM_CHUNK_MB:1024 VOLWM_CHUNK_REPLICATE_MULT:2
VOLWM_FREE_PCT:50 _blockDev:False _checkIoTuneCategories:<bound method
Drive._checkIoTuneCategories of <vm.Drive object at 0x2b12950>>
_customize:<bound method Drive._customize of <vm.Drive object at
0x2b12950>> _deviceXML:<disk device="cdrom" snapshot="no"
type="file"><source
file="/var/run/vdsm/payload/409c5dbe-5e70-40de-bf73-46ef484ea2d7.393db1d8c9e756483db001b30a239296.img"
startupPolicy="optional"/><target bus="ide"
dev="hdd"/><readonly/><serial></serial></disk>
_makeName:<bound method
Drive._makeName of <vm.Drive object at 0x2b12950>>
_validateIoTuneParams:<bound method Drive._validateIoTuneParams of
<vm.Drive object at 0x2b12950>> apparentsize:0 blockDev:False
cache:none conf:{'status': 'Down', 'acpiEnable': 'true',
'emulatedMachine': 'pc-1.0', 'vmId':
'409c5dbe-5e70-40de-bf73-46ef484ea2d7', 'pid': '0',
'memGuaranteedSize': 1365, 'timeOffset': '0',
'keyboardLayout':
'en-us', 'displayPort': '-1', 'displaySecurePort':
'-1',
'spiceSslCipherSuite': 'DEFAULT', 'cpuType': 'Nehalem',
'custom': {},
'clientIp': '', 'exitCode': 1, 'nicModel':
'rtl8139,pv',
'smartcardEnable': 'false', 'kvmEnable': 'true',
'pitReinjection':
'false', 'transparentHugePages': 'true', 'devices':
[{'device':
'scsi', 'model': 'virtio-scsi', 'type':
'controller'}, {'device':
'qxl', 'specParams': {'vram': '65536'}, 'type':
'video', 'deviceId':
'70eadea2-6b53-
Let me know if you need full logs
The disk image itself seems ok:
[root@ovnode02 ~]# ll
/rhev/data-center/mnt/glusterSD/ovnode01\:gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/
total 1025
-rw-rw----. 1 vdsm kvm 10737418240 Sep 25 00:42
dff09892-bc60-4de5-85c0-2a1fa215a161
-rw-rw----. 1 vdsm kvm 1048576 Sep 25 00:42
dff09892-bc60-4de5-85c0-2a1fa215a161.lease
-rw-r--r--. 1 vdsm kvm 268 Sep 25 00:42
dff09892-bc60-4de5-85c0-2a1fa215a161.meta
[root@ovnode02 ~]# qemu-img info
/rhev/data-center/mnt/glusterSD/ovnode01\:gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161
image:
/rhev/data-center/mnt/glusterSD/ovnode01:gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161
file format: raw
virtual size: 10G (10737418240 bytes)
disk size: 0
Also on the other node
[root@ovnode01 vdsm]# ll
/rhev/data-center/mnt/glusterSD/ovnode01\:gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/
total 1025
-rw-rw----. 1 vdsm kvm 10737418240 Sep 25 00:42
dff09892-bc60-4de5-85c0-2a1fa215a161
-rw-rw----. 1 vdsm kvm 1048576 Sep 25 00:42
dff09892-bc60-4de5-85c0-2a1fa215a161.lease
-rw-r--r--. 1 vdsm kvm 268 Sep 25 00:42
dff09892-bc60-4de5-85c0-2a1fa215a161.meta
[root@ovnode01 vdsm]# qemu-img info
/rhev/data-center/mnt/glusterSD/ovnode01\:gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161
image:
/rhev/data-center/mnt/glusterSD/ovnode01:gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161
file format: raw
virtual size: 10G (10737418240 bytes)
disk size: 0
[root@ovnode02 ~]# gluster volume list
gv01
[root@ovnode02 ~]# gluster volume info
Volume Name: gv01
Type: Replicate
Volume ID: 7cf18f87-eef8-47cb-b469-8e5f92bfcd98
Status: Started
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: 192.168.33.41:/export/brick1/sdb1
Brick2: 192.168.33.42:/export/brick1/sdb1
Options Reconfigured:
storage.owner-gid: 36
storage.owner-uid: 36
auth.allow: *
user.cifs: on
nfs.disable: off
I notice during the volume creation this message that I don't know if
could be of impact:
Volume Option group=virt could not be set on gv01
See also this image for events generated on egine gui.
https://docs.google.com/file/d/0BwoPbcrMv8mvZEp6UmhPV0ttaVU/edit?usp=sharing
Possibly the openstack related ones could be misunderstood and
sincerely I haven't understood their meaning....
Gianluca
11:58 p.m.
On 09/25/2013 04:40 AM, Gianluca Cecchi wrote:
Hello,
I'm testing GlusterFS on 3.3 with fedora 19 systems.
One engine (ovirt) + 2 nodes (ovnode01 and ovnode02)
Successfully created gluster volume composed by two bricks (one for
each vdsm node) distributed replicated
Suggestion:
If page
http://www.ovirt.org/Features/GlusterFS_Storage_Domain
is the reference, perhaps it would be better to explicitly specify
that one has to start the created volume before going to add a storage
domain based on the created volume.
Not knowing Gluster could lead to think that the start phase is
responsibility of storage domain creation itself ...
All seems ok from a configuration point of view.
Uploaded a CentOS 6.4 iso image ito my ISO_DOMAIN (nfs exported from
engine.. this will be another thread...)
Created a server VM with 10Gb of disk with thin allocation.
I get an error when starting the VM
on engine.log
2013-09-25 00:43:16,027 ERROR
[org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo]
(DefaultQuartzScheduler_Worker-44) Rerun vm
409c5dbe-5e70-40de-bf73-46ef484ea2d7. Called from vds ovnode02
2013-09-25 00:43:16,031 INFO
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(pool-6-thread-48) Correlation ID: 5ea15175, Job ID:
48128550-3633-4da4-8d9c-ab704be02f02, Call Stack: null, Custom Event
ID: -1, Message: Failed to run VM C6 on Host ovnode02.
2013-09-25 00:43:16,057 INFO [org.ovirt.engine.core.bll.RunVmCommand]
(pool-6-thread-48) Lock Acquired to object EngineLock [exclusiveLocks=
key: 409c5dbe-5e70-40de-bf73-46ef484ea2d7 value: VM
, sharedLocks= ]
2013-09-25 00:43:16,070 INFO
[org.ovirt.engine.core.vdsbroker.IsVmDuringInitiatingVDSCommand]
(pool-6-thread-48) START, IsVmDuringInitiatingVDSCommand( vmId =
409c5dbe-5e70-40de-bf73-46ef484ea2d7), log id: 7979c53b
2013-09-25 00:43:16,071 INFO
[org.ovirt.engine.core.vdsbroker.IsVmDuringInitiatingVDSCommand]
(pool-6-thread-48) FINISH, IsVmDuringInitiatingVDSCommand, return:
false, log id: 7979c53b
2013-09-25 00:43:16,086 INFO [org.ovirt.engine.core.bll.RunVmCommand]
(pool-6-thread-48) Running command: RunVmCommand internal: false.
Entities affected : ID: 409c5dbe-5e70-40de-bf73-46ef484ea2d7 Type: VM
2013-09-25 00:43:16,110 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.IsoPrefixVDSCommand]
(pool-6-thread-48) START, IsoPrefixVDSCommand( storagePoolId =
6b3175e6-6fa2-473f-ba21-38917c413ba9, ignoreFailoverLimit = false),
log id: 7fd62f0f
2013-09-25 00:43:16,111 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.IsoPrefixVDSCommand]
(pool-6-thread
...
On node vdsm.log
Thread-2915::ERROR::2013-09-25
00:43:20,108::vm::2062::vm.Vm::(_startUnderlyingVm)
vmId=`409c5dbe-5e70-40de-bf73-46ef484ea2d7`::The vm start process
failed
Traceback (most recent call last):
File "/usr/share/vdsm/vm.py", line 2022, in _startUnderlyingVm
self._run()
File "/usr/share/vdsm/vm.py", line 2906, in _run
self._connection.createXML(domxml, flags),
File "/usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py",
line 76, in wrapper
ret = f(*args, **kwargs)
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2805, in
createXML
if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
libvirtError: Unable to read from monitor: Connection reset by peer
Thread-2915::DEBUG::2013-09-25
00:43:20,176::vm::2448::vm.Vm::(setDownStatus)
vmId=`409c5dbe-5e70-40de-bf73-46ef484ea2d7`::Changed state to Down:
Unable to read from monitor: Connection reset by peer
libvirtEventLoop::WARNING::2013-09-25
00:43:20,114::clientIF::337::vds::(teardownVolumePath) Drive is not a
vdsm image: VOLWM_CHUNK_MB:1024 VOLWM_CHUNK_REPLICATE_MULT:2
VOLWM_FREE_PCT:50 _blockDev:False _checkIoTuneCategories:<bound method
Drive._checkIoTuneCategories of <vm.Drive object at 0x2b12950>>
_customize:<bound method Drive._customize of <vm.Drive object at
0x2b12950>> _deviceXML:<disk device="cdrom" snapshot="no"
type="file"><source
file="/var/run/vdsm/payload/409c5dbe-5e70-40de-bf73-46ef484ea2d7.393db1d8c9e756483db001b30a239296.img"
startupPolicy="optional"/><target bus="ide"
dev="hdd"/><readonly/><serial></serial></disk>
_makeName:<bound method
Drive._makeName of <vm.Drive object at 0x2b12950>>
_validateIoTuneParams:<bound method Drive._validateIoTuneParams of
<vm.Drive object at 0x2b12950>> apparentsize:0 blockDev:False
cache:none conf:{'status': 'Down', 'acpiEnable': 'true',
'emulatedMachine': 'pc-1.0', 'vmId':
'409c5dbe-5e70-40de-bf73-46ef484ea2d7', 'pid': '0',
'memGuaranteedSize': 1365, 'timeOffset': '0',
'keyboardLayout':
'en-us', 'displayPort': '-1', 'displaySecurePort':
'-1',
'spiceSslCipherSuite': 'DEFAULT', 'cpuType': 'Nehalem',
'custom': {},
'clientIp': '', 'exitCode': 1, 'nicModel':
'rtl8139,pv',
'smartcardEnable': 'false', 'kvmEnable': 'true',
'pitReinjection':
'false', 'transparentHugePages': 'true', 'devices':
[{'device':
'scsi', 'model': 'virtio-scsi', 'type':
'controller'}, {'device':
'qxl', 'specParams': {'vram': '65536'}, 'type':
'video', 'deviceId':
'70eadea2-6b53-
Let me know if you need full logs
The disk image itself seems ok:
[root@ovnode02 ~]# ll
/rhev/data-center/mnt/glusterSD/ovnode01\:gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/
total 1025
-rw-rw----. 1 vdsm kvm 10737418240 Sep 25 00:42
dff09892-bc60-4de5-85c0-2a1fa215a161
-rw-rw----. 1 vdsm kvm 1048576 Sep 25 00:42
dff09892-bc60-4de5-85c0-2a1fa215a161.lease
-rw-r--r--. 1 vdsm kvm 268 Sep 25 00:42
dff09892-bc60-4de5-85c0-2a1fa215a161.meta
[root@ovnode02 ~]# qemu-img info
/rhev/data-center/mnt/glusterSD/ovnode01\:gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161
image:
/rhev/data-center/mnt/glusterSD/ovnode01:gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161
file format: raw
virtual size: 10G (10737418240 bytes)
disk size: 0
Also on the other node
[root@ovnode01 vdsm]# ll
/rhev/data-center/mnt/glusterSD/ovnode01\:gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/
total 1025
-rw-rw----. 1 vdsm kvm 10737418240 Sep 25 00:42
dff09892-bc60-4de5-85c0-2a1fa215a161
-rw-rw----. 1 vdsm kvm 1048576 Sep 25 00:42
dff09892-bc60-4de5-85c0-2a1fa215a161.lease
-rw-r--r--. 1 vdsm kvm 268 Sep 25 00:42
dff09892-bc60-4de5-85c0-2a1fa215a161.meta
[root@ovnode01 vdsm]# qemu-img info
/rhev/data-center/mnt/glusterSD/ovnode01\:gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161
image:
/rhev/data-center/mnt/glusterSD/ovnode01:gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161
file format: raw
virtual size: 10G (10737418240 bytes)
disk size: 0
[root@ovnode02 ~]# gluster volume list
gv01
[root@ovnode02 ~]# gluster volume info
Volume Name: gv01
Type: Replicate
Volume ID: 7cf18f87-eef8-47cb-b469-8e5f92bfcd98
Status: Started
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: 192.168.33.41:/export/brick1/sdb1
Brick2: 192.168.33.42:/export/brick1/sdb1
Options Reconfigured:
storage.owner-gid: 36
storage.owner-uid: 36
auth.allow: *
user.cifs: on
nfs.disable: off
I notice during the volume creation this message that I don't know if
could be of impact:
Volume Option group=virt could not be set on gv01
This should not be an issue. This is about performance tuning, not about
the functionality.
See also this image for events generated on egine gui.
https://docs.google.com/file/d/0BwoPbcrMv8mvZEp6UmhPV0ttaVU/edit?usp=sharing
Possibly the openstack related ones could be misunderstood and
sincerely I haven't understood their meaning....
Gianluca
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
1:06 a.m.
oVirt hosts are VMs inside an ESX 5.1 infra.
I think all is ok in terms of nested virtualization though
CPU of ESX host is E7-4870 and cluster defined as "Intel Nehalem Family"
selinux is in permissive mode
[root@ovnode01 libvirt]# vdsClient -s localhost getVdsCapabilities
HBAInventory = {'FC': [], 'iSCSI': [{'InitiatorName':
'iqn.1994-05.com.redhat:6344c23973df'}]}
ISCSIInitiatorName = 'iqn.1994-05.com.redhat:6344c23973df'
bondings = {'bond0': {'addr': '',
'cfg': {},
'hwaddr': '8e:a1:3b:0c:83:47',
'ipv6addrs': [],
'mtu': '1500',
'netmask': '',
'slaves': []}}
bridges = {'ovirtmgmt': {'addr': '192.168.33.41',
'cfg': {'BOOTPROTO': 'none',
'DEFROUTE': 'yes',
'DELAY': '0',
'DEVICE': 'ovirtmgmt',
'GATEWAY': '192.168.33.15',
'IPADDR': '192.168.33.41',
'NETMASK': '255.255.255.0',
'NM_CONTROLLED': 'no',
'ONBOOT': 'yes',
'STP': 'no',
'TYPE': 'Bridge'},
'gateway': '192.168.33.15',
'ipv6addrs':
['fe80::250:56ff:fe9f:686b/64'],
'ipv6gateway': '::',
'mtu': '1500',
'netmask': '255.255.255.0',
'ports': ['eth0'],
'stp': 'off'}}
clusterLevels = ['3.0', '3.1', '3.2', '3.3']
cpuCores = '4'
cpuFlags =
'fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,mmx,fxsr,sse,sse2,ss,syscall,nx,rdtscp,lm,constant_tsc,arch_perfmon,pebs,bts,nopl,xtopology,tsc_reliable,nonstop_tsc,aperfmperf,pni,monitor,vmx,ssse3,cx16,sse4_1,sse4_2,x2apic,popcnt,lahf_lm,ida,arat,epb,dtherm,tpr_shadow,vnmi,ept,vpid,model_Nehalem,model_Conroe,model_coreduo,model_core2duo,model_Penryn,model_n270'
cpuModel = 'Intel(R) Xeon(R) CPU E7- 4870 @ 2.40GHz'
cpuSockets = '4'
cpuSpeed = '2394.000'
cpuThreads = '4'
emulatedMachines = ['pc',
'q35',
'isapc',
'pc-0.10',
'pc-0.11',
'pc-0.12',
'pc-0.13',
'pc-0.14',
'pc-0.15',
'pc-1.0',
'pc-1.1',
'pc-1.2',
'pc-1.3',
'none']
guestOverhead = '65'
hooks = {}
kvmEnabled = 'true'
lastClient = '192.168.33.40'
lastClientIface = 'ovirtmgmt'
management_ip = '0.0.0.0'
memSize = '16050'
netConfigDirty = 'False'
networks = {'ovirtmgmt': {'addr': '192.168.33.41',
'bridged': True,
'cfg': {'BOOTPROTO': 'none',
'DEFROUTE': 'yes',
'DELAY': '0',
'DEVICE': 'ovirtmgmt',
'GATEWAY': '192.168.33.15',
'IPADDR': '192.168.33.41',
'NETMASK': '255.255.255.0',
'NM_CONTROLLED': 'no',
'ONBOOT': 'yes',
'STP': 'no',
'TYPE': 'Bridge'},
'gateway': '192.168.33.15',
'iface': 'ovirtmgmt',
'ipv6addrs':
['fe80::250:56ff:fe9f:686b/64'],
'ipv6gateway': '::',
'mtu': '1500',
'netmask': '255.255.255.0',
'ports': ['eth0'],
'stp': 'off'}}
nics = {'ens224': {'addr': '192.168.230.31',
'cfg': {'BOOTPROTO': 'static',
'DEVICE': 'ens224',
'HWADDR': '00:50:56:9F:3C:B0',
'IPADDR': '192.168.230.31',
'NETMASK': '255.255.255.0',
'NM_CONTROLLED': 'no',
'ONBOOT': 'yes',
'TYPE': 'Ethernet'},
'hwaddr': '00:50:56:9f:3c:b0',
'ipv6addrs': ['fe80::250:56ff:fe9f:3cb0/64'],
'mtu': '1500',
'netmask': '255.255.255.0',
'speed': 10000},
'eth0': {'addr': '',
'cfg': {'BRIDGE': 'ovirtmgmt',
'DEVICE': 'eth0',
'HWADDR': '00:50:56:9f:68:6b',
'MTU': '1500',
'NM_CONTROLLED': 'no',
'ONBOOT': 'yes',
'STP': 'no'},
'hwaddr': '00:50:56:9f:68:6b',
'ipv6addrs': ['fe80::250:56ff:fe9f:686b/64'],
'mtu': '1500',
'netmask': '',
'speed': 10000},
'p256p1': {'addr': '',
'cfg': {},
'hwaddr': '00:50:56:9f:3b:86',
'ipv6addrs': [],
'mtu': '1500',
'netmask': '',
'speed': 0}}
operatingSystem = {'name': 'Fedora', 'release':
'3', 'version': '19'}
packages2 = {'glusterfs': {'buildtime': 1375786850,
'release': '8.fc19',
'version': '3.4.0'},
'glusterfs-fuse': {'buildtime': 1375786850,
'release': '8.fc19',
'version': '3.4.0'},
'glusterfs-rdma': {'buildtime': 1375786850,
'release': '8.fc19',
'version': '3.4.0'},
'glusterfs-server': {'buildtime': 1375786850,
'release': '8.fc19',
'version': '3.4.0'},
'kernel': {'buildtime': 1379163891.0,
'release': '200.fc19.x86_64',
'version': '3.11.1'},
'libvirt': {'buildtime': 1375400611,
'release': '1.fc19',
'version': '1.0.5.5'},
'mom': {'buildtime': 1375215820, 'release':
'3.fc19', 'version': '0.3.2'},
'qemu-img': {'buildtime': 1378374475,
'release': '9.fc19',
'version': '1.4.2'},
'qemu-kvm': {'buildtime': 1378374475,
'release': '9.fc19',
'version': '1.4.2'},
'spice-server': {'buildtime': 1375454091,
'release': '1.fc19',
'version': '0.12.4'},
'vdsm': {'buildtime': 1378818342, 'release':
'2.fc19', 'version': '4.12.1'}}
reservedMem = '321'
software_revision = '2'
software_version = '4.12'
supportedENGINEs = ['3.0', '3.1', '3.2', '3.3']
supportedProtocols = ['2.2', '2.3']
uuid = '421F7170-C703-34E3-9628-4588D841F8B1'
version_name = 'Snow Man'
vlans = {}
vmTypes = ['kvm']
qemu log for the VM:
2013-09-25 05:42:29.130+0000: starting up
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
QEMU_AUDIO_DRV=spice /usr/bin/qemu-kvm -name C6 -S -machine
pc-1.0,accel=kvm,usb=off -cpu Nehalem -m 2048 -smp
1,sockets=1,cores=1,threads=1 -uuid
409c5dbe-5e70-40de-bf73-46ef484ea2d7 -smbios
type=1,manufacturer=oVirt,product=oVirt
Node,version=19-3,serial=421F7170-C703-34E3-9628-4588D841F8B1,uuid=409c5dbe-5e70-40de-bf73-46ef484ea2d7
-no-user-config -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/C6.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc
base=2013-09-25T05:42:28,driftfix=slew -no-shutdown -device
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device
virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 -device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive
if=none,id=drive-ide0-1-0,readonly=on,format=raw,serial= -device
ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive
file=gluster://ovnode01/gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161,if=none,id=drive-virtio-disk0,format=raw,serial=d004045e-620b-4d90-8a7f-6c6d26393a08,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
-netdev tap,fd=27,id=hostnet0,vhost=on,vhostfd=28 -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:bb:9f:10,bus=pci.0,addr=0x3
-chardev
socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/409c5dbe-5e70-40de-bf73-46ef484ea2d7.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/409c5dbe-5e70-40de-bf73-46ef484ea2d7.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
-spice
tls-port=5900,addr=0,x509-dir=/etc/pki/vdsm/libvirt-spice,tls-channel=main,tls-channel=display,tls-channel=inputs,tls-channel=cursor,tls-channel=playback,tls-channel=record,tls-channel=smartcard,tls-channel=usbredir,seamless-migration=on
-k en-us -vga qxl -global qxl-vga.ram_size=67108864 -global
qxl-vga.vram_size=67108864 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7
qemu-system-x86_64: -drive
file=gluster://ovnode01/gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161,if=none,id=drive-virtio-disk0,format=raw,serial=d004045e-620b-4d90-8a7f-6c6d26393a08,cache=none,werror=stop,rerror=stop,aio=threads:
Gluster connection failed for server=ovnode01 port=0 volume=gv01
image=20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161
transport=tcp
qemu-system-x86_64: -drive
file=gluster://ovnode01/gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161,if=none,id=drive-virtio-disk0,format=raw,serial=d004045e-620b-4d90-8a7f-6c6d26393a08,cache=none,werror=stop,rerror=stop,aio=threads:
could not open disk image
gluster://ovnode01/gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161:
No data available
2013-09-25 05:42:32.291+0000: shutting down
1:10 a.m.
So it seems the probelm is
file=gluster://ovnode01/gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161,if=none,id=drive-virtio-disk0,format=raw,serial=d004045e-620b-4d90-8a7f-6c6d26393a08,cache=none,werror=stop,rerror=stop,aio=threads:
Gluster connection failed for server=ovnode01 port=0 volume=gv01
image=20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161
transport=tcp
qemu-system-x86_64: -drive
file=gluster://ovnode01/gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161,if=none,id=drive-virtio-disk0,format=raw,serial=d004045e-620b-4d90-8a7f-6c6d26393a08,cache=none,werror=stop,rerror=stop,aio=threads:
could not open disk image
it is the same in qemu.log of both hosts
On the other one I have:
2013-09-25 05:42:35.454+0000: starting up
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
QEMU_AUDIO_DRV=spice /usr/bin/qemu-kvm -name C6 -S -machine
pc-1.0,accel=kvm,usb=off -cpu Nehalem -m 2048 -smp
1,sockets=1,cores=1,threads=1 -uuid
409c5dbe-5e70-40de-bf73-46ef484ea2d7 -smbios
type=1,manufacturer=oVirt,product=oVirt
Node,version=19-3,serial=421FAF48-83D1-08DC-F2ED-F2894F8BC56D,uuid=409c5dbe-5e70-40de-bf73-46ef484ea2d7
-no-user-config -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/C6.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc
base=2013-09-25T05:42:35,driftfix=slew -no-shutdown -device
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device
virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 -device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive
if=none,id=drive-ide0-1-0,readonly=on,format=raw,serial= -device
ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive
file=gluster://ovnode01/gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161,if=none,id=drive-virtio-disk0,format=raw,serial=d004045e-620b-4d90-8a7f-6c6d26393a08,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
-netdev tap,fd=27,id=hostnet0,vhost=on,vhostfd=28 -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:bb:9f:10,bus=pci.0,addr=0x3
-chardev
socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/409c5dbe-5e70-40de-bf73-46ef484ea2d7.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/409c5dbe-5e70-40de-bf73-46ef484ea2d7.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
-spice
tls-port=5900,addr=0,x509-dir=/etc/pki/vdsm/libvirt-spice,tls-channel=main,tls-channel=display,tls-channel=inputs,tls-channel=cursor,tls-channel=playback,tls-channel=record,tls-channel=smartcard,tls-channel=usbredir,seamless-migration=on
-k en-us -vga qxl -global qxl-vga.ram_size=67108864 -global
qxl-vga.vram_size=67108864 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7
qemu-system-x86_64: -drive
file=gluster://ovnode01/gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161,if=none,id=drive-virtio-disk0,format=raw,serial=d004045e-620b-4d90-8a7f-6c6d26393a08,cache=none,werror=stop,rerror=stop,aio=threads:
Gluster connection failed for server=ovnode01 port=0 volume=gv01
image=20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161
transport=tcp
qemu-system-x86_64: -drive
file=gluster://ovnode01/gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161,if=none,id=drive-virtio-disk0,format=raw,serial=d004045e-620b-4d90-8a7f-6c6d26393a08,cache=none,werror=stop,rerror=stop,aio=threads:
could not open disk image
gluster://ovnode01/gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161:
No data available
2013-09-25 05:42:38.620+0000: shutting down
Currently iptables as setup by install is this (I checked to set up
iptables from the gui when I added the host)
Do I have to add anything for gluster?
[root@ovnode01 qemu]# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state
RELATED,ESTABLISHED
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:54321
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:161
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:16514
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0
multiport dports 5634:6166
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0
multiport dports 49152:49216
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:24007
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:111
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:38465
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:38466
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:111
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:38467
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:2049
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:39543
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:55863
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:38468
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:963
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:965
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:4379
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:139
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:445
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp
dpts:24009:24108
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp
dpts:49152:49251
REJECT all -- 0.0.0.0/0 0.0.0.0/0
reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV
match ! --physdev-is-bridged reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
1:11 a.m.
On 09/25/2013 11:36 AM, Gianluca Cecchi wrote:
qemu-system-x86_64: -drive
file=gluster://ovnode01/gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161,if=none,id=drive-virtio-disk0,format=raw,serial=d004045e-620b-4d90-8a7f-6c6d26393a08,cache=none,werror=stop,rerror=stop,aio=threads:
Gluster connection failed for server=ovnode01 port=0 volume=gv01
image=20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161
transport=tcp
qemu-system-x86_64: -drive
file=gluster://ovnode01/gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161,if=none,id=drive-virtio-disk0,format=raw,serial=d004045e-620b-4d90-8a7f-6c6d26393a08,cache=none,werror=stop,rerror=stop,aio=threads:
could not open disk image
gluster://ovnode01/gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161:
No data available
2013-09-25 05:42:32.291+0000: shutting down
Have the following configuration changes been done?
1) gluster volume set <volname> server.allow-insecure on
2) Edit /etc/glusterfs/glusterd.vol on all gluster nodes to contain this
line:
option rpc-auth-allow-insecure on
Post 2), restarting glusterd would be necessary.
Regards,
Vijay
1:21 a.m.
On Wed, Sep 25, 2013 at 8:11 AM, Vijay Bellur wrote:
Have the following configuration changes been done?
1) gluster volume set <volname> server.allow-insecure on
2) Edit /etc/glusterfs/glusterd.vol on all gluster nodes to contain this
line:
option rpc-auth-allow-insecure on
Post 2), restarting glusterd would be necessary.
Regards,
Vijay
No, because I didn't find find this kind of info anywhere... ;-)
Done on both hosts (step 1 only one time) and I see that the gui
detects the change in volume setting.
Now the VM can start (I see the qemu process on ovnode02) but it seems
to remain in hourglass state icon.....
After 5 minutes it still remains in "executing" phase in tasks
Eventually I'm going to restart the nodes completely....
2:11 a.m.
On 09/25/2013 11:51 AM, Gianluca Cecchi wrote:
On Wed, Sep 25, 2013 at 8:11 AM, Vijay Bellur wrote:
>
>
> Have the following configuration changes been done?
>
> 1) gluster volume set <volname> server.allow-insecure on
>
> 2) Edit /etc/glusterfs/glusterd.vol on all gluster nodes to contain this
> line:
> option rpc-auth-allow-insecure on
>
> Post 2), restarting glusterd would be necessary.
>
> Regards,
> Vijay
No, because I didn't find find this kind of info anywhere... ;-)
The feature page wiki does provide this information but it gets missed
in the details. Should we highlight it more?
Done on both hosts (step 1 only one time) and I see that the gui
detects the change in volume setting.
Now the VM can start (I see the qemu process on ovnode02) but it seems
to remain in hourglass state icon.....
After 5 minutes it still remains in "executing" phase in tasks
Let us know how this goes.
-Vijay
4:07 a.m.
This is a multi-part message in MIME format.
--------------030900090306020400090109
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
On 25.09.2013 09:11, Vijay Bellur wrote:
On 09/25/2013 11:51 AM, Gianluca Cecchi wrote:
> On Wed, Sep 25, 2013 at 8:11 AM, Vijay Bellur wrote:
>
>>
>>
>> Have the following configuration changes been done?
>>
>> 1) gluster volume set <volname> server.allow-insecure on
>>
>> 2) Edit /etc/glusterfs/glusterd.vol on all gluster nodes to contain
>> this
>> line:
>> option rpc-auth-allow-insecure on
>>
>> Post 2), restarting glusterd would be necessary.
>>
>> Regards,
>> Vijay
>
>
> No, because I didn't find find this kind of info anywhere... ;-)
The feature page wiki does provide this information but it gets missed
in the details. Should we highlight it more?
>
> Done on both hosts (step 1 only one time) and I see that the gui
> detects the change in volume setting.
> Now the VM can start (I see the qemu process on ovnode02) but it seems
> to remain in hourglass state icon.....
> After 5 minutes it still remains in "executing" phase in tasks
>
Let us know how this goes.
-Vijay
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
I found a bug report on your issue.
https://bugzilla.redhat.com/show_bug.cgi?id=988299
Scroll to the end. (
https://bugzilla.redhat.com/show_bug.cgi?id=988299#c46 )
There is a modified glusterVolume.py. I have the same issue as well, I'm
trying to fix this it right now.
Regards David
--------------030900090306020400090109
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><br>
<br>
On 25.09.2013 09:11, Vijay Bellur wrote:<br>
</div>
<blockquote cite="mid:52428CAA.2050707@redhat.com"
type="cite">On
09/25/2013 11:51 AM, Gianluca Cecchi wrote:
<br>
<blockquote type="cite">On Wed, Sep 25, 2013 at 8:11 AM, Vijay
Bellur wrote:
<br>
<br>
<blockquote type="cite">
<br>
<br>
Have the following configuration changes been done?
<br>
<br>
1) gluster volume set <volname> server.allow-insecure on
<br>
<br>
2) Edit /etc/glusterfs/glusterd.vol on all gluster nodes to
contain this
<br>
line:
<br>
option rpc-auth-allow-insecure on
<br>
<br>
Post 2), restarting glusterd would be necessary.
<br>
<br>
Regards,
<br>
Vijay
<br>
</blockquote>
<br>
<br>
No, because I didn't find find this kind of info anywhere... ;-)
<br>
</blockquote>
<br>
The feature page wiki does provide this information but it gets
missed in the details. Should we highlight it more?
<br>
<br>
<blockquote type="cite">
<br>
Done on both hosts (step 1 only one time) and I see that the gui
<br>
detects the change in volume setting.
<br>
Now the VM can start (I see the qemu process on ovnode02) but it
seems
<br>
to remain in hourglass state icon.....
<br>
After 5 minutes it still remains in "executing" phase in tasks
<br>
<br>
</blockquote>
<br>
Let us know how this goes.
<br>
<br>
-Vijay
<br>
_______________________________________________
<br>
Users mailing list
<br>
<a class="moz-txt-link-abbreviated"
href="mailto:Users@ovirt.org">Users@ovirt.org</a>
<br>
<a class="moz-txt-link-freetext"
href="http://lists.ovirt.org/mailman/listinfo/users">http://...
<br>
</blockquote>
<br>
I found a bug report on your issue.<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a
href="https://bugzilla.redhat.com/show_bug.cgi?id=988299">ht...
<br>
Scroll to the end. (
<a class="moz-txt-link-freetext"
href="https://bugzilla.redhat.com/show_bug.cgi?id=988299#c46"&g...
)<br>
There is a modified
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
glusterVolume.py. I have the same issue as well, I'm trying to fix
this it right now.<br>
<br>
Regards David<br>
<br>
</body>
</html>
--------------030900090306020400090109--
4:41 a.m.
On Thu, Sep 26, 2013 at 11:07 AM, David Riedl wrote:
g report on your issue.
https://bugzilla.redhat.com/show_bug.cgi?id=988299
Scroll to the end. ( https://bugzilla.redhat.com/show_bug.cgi?id=988299#c46
)
There is a modified glusterVolume.py. I have the same issue as well, I'm
trying to fix this it right now.
Regards David
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
Unfortunately I have the esx infra down for a scheduled maintenance right now.
Later today I'm going to verify and test when up again as suggested to
me in the previous message..
But it doesn't appear as the same thing to me...
My volume is gv01 and without any _ or / in it.
Also the message is a bit different
On vdsm.log of host:
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2805, in createXML
if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
libvirtError: Unable to read from monitor: Connection reset by peer
In qemu.log of the VM
Gluster connection failed for server=ovnode01 port=0 volume=gv01
image=20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161
transport=tcp
Gianluca
3:54 p.m.
I was able to restart engine and the two hosts.
All restarted again.
Now the effect to run the VM is that it remains in paused state
- start VM (about 21:54 today)
it starts and goes into paused mode (arrow icon near VM)
From image
https://docs.google.com/file/d/0BwoPbcrMv8mvRXlaa19sdFpmQ0E/edit?usp=sharing
you see that apparently the execute action terminates at 21:54 but the
VM maintains paused state.
- if I try other actions on the same VM there is no message preventing
me from that....
and it stays in paused mode
see several attempt actions to solve situation
- at 21:58 host becomes unreponsive from the gui, no network ping from
engine and if I go into its console I see the login prompt but not
able to connect...
- power off ovnode01
icon near VM becomes now question mark (?)
- power on ovnode01
vm goes into stop mode (red square)
ovnode01 joins again cluster
vdsm log in gzip format starting today before start of vm
https://docs.google.com/file/d/0BwoPbcrMv8mvXzY2eEcwR0VXazQ/edit?usp=sharing
engine.log in gzip format
https://docs.google.com/file/d/0BwoPbcrMv8mvU1RuLVRVYVZ0SXM/edit?usp=sharing
PS: at the moment no fenging action set up. COuld I set any agent for
host virtualized inside VMware?
from a gluster point of view on ovnode01 under /var/log/glusterfs
[root@ovnode01 glusterfs]# ls -lrt
total 2008
drwxr-xr-x. 2 root root 4096 Sep 25 00:05 bricks
-rw-------. 1 root root 59038 Sep 26 22:09 nfs.log
-rw-------. 1 root root 51992 Sep 26 22:09 glustershd.log
-rw-------. 1 root root 40230 Sep 26 22:09
rhev-data-center-mnt-glusterSD-ovnode01:gv01.log
-rw-------. 1 root root 422757 Sep 26 22:47 etc-glusterfs-glusterd.vol.log
-rw-------. 1 root root 1449411 Sep 26 22:47 cli.log
In etc-glusterfs-glusterd.vol.log
I see several lines like this
[2013-09-26 20:19:53.450793] I
[glusterd-handler.c:1007:__glusterd_handle_cli_get_volume] 0-glusterd:
Received get vol req
qemu process:
qemu 4565 1 0 22:21 ? 00:00:09
/usr/bin/qemu-system-x86_64 -machine accel=kvm -name C6 -S -machine
pc-1.0,accel=kvm,usb=off -cpu Nehalem -m 2048 -smp
1,sockets=1,cores=1,threads=1 -uuid
409c5dbe-5e70-40de-bf73-46ef484ea2d7 -smbios
type=1,manufacturer=oVirt,product=oVirt
Node,version=19-3,serial=421F7170-C703-34E3-9628-4588D841F8B1,uuid=409c5dbe-5e70-40de-bf73-46ef484ea2d7
-no-user-config -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/C6.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc
base=2013-09-26T20:21:00,driftfix=slew -no-shutdown -device
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device
virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 -device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive
file=/rhev/data-center/mnt/ovirt.localdomain.local:_var_lib_exports_iso/6e80607d-5437-4fc5-b73c-66794f6381e0/images/11111111-1111-1111-1111-111111111111/CentOS-6.4-x86_64-bin-DVD1.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw,serial=
-device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1
-drive
file=gluster://ovnode01/gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161,if=none,id=drive-virtio-disk0,format=raw,serial=d004045e-620b-4d90-8a7f-6c6d26393a08,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=2
-netdev tap,fd=27,id=hostnet0,vhost=on,vhostfd=28 -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:bb:9f:10,bus=pci.0,addr=0x3,bootindex=3
-chardev
socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/409c5dbe-5e70-40de-bf73-46ef484ea2d7.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/409c5dbe-5e70-40de-bf73-46ef484ea2d7.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
-spice
tls-port=5900,addr=0,x509-dir=/etc/pki/vdsm/libvirt-spice,tls-channel=main,tls-channel=display,tls-channel=inputs,tls-channel=cursor,tls-channel=playback,tls-channel=record,tls-channel=smartcard,tls-channel=usbredir,seamless-migration=on
-k en-us -vga qxl -global qxl-vga.ram_size=67108864 -global
qxl-vga.vram_size=67108864 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7
The VM result as started in events of the gui but its icon remains in pause.
See the image:
https://docs.google.com/file/d/0BwoPbcrMv8mvZ1RnUkg4aVhlckk/edit?usp=sharing
Gianluca
4:57 p.m.
Today I was able to work again on this matter and it seems related to spice
Every time I start the VM (that is defined with spice) it goes in
paused state and after a few minutes the node gets unreachable, down
form the gui, no response also inside its console and forced to power
off it.
So I tried to create a vm taken from oVirt generated xml using gluster
to see if it is the problem in any way...
and start it via virsh and libvirt on the node.
See in attach:
I got the ovirt generated xml file, under /var/run/libvirt/qemu/C6.xml
myvm.xml the derived vm that defined and started and is able to go and
remain running
[root@ovnode02 ~]# virsh define myvm.xml
Please enter your authentication name: vuser
Please enter your password:
Domain myvm defined from myvm.xml
[root@ovnode02 ~]# virsh list --all
Please enter your authentication name: vuser
Please enter your password:
Id Name State
----------------------------------------------------
- myvm shut off
[root@ovnode02 ~]# virsh start myvm
Please enter your authentication name: vuser
Please enter your password:
Domain myvm started
[root@ovnode02 ~]# virsh list --all
Please enter your authentication name: vuser
Please enter your password:
Id Name State
----------------------------------------------------
2 myvm running
In this case
[root@ovnode02 ~]# ps -ef|grep qemu
qemu 1617 574 0 18:24 ? 00:00:00 [python] <defunct>
qemu 6083 1 7 18:40 ? 00:00:14
/usr/bin/qemu-system-x86_64 -machine accel=kvm -name myvm -S -machine
pc-1.0,accel=kvm,usb=off -cpu Nehalem -m 2048 -smp
1,sockets=1,cores=1,threads=1 -uuid
dfadc661-6288-4f21-8faa-012daf29478f -nographic -no-user-config
-nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/myvm.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc
base=2013-10-01T16:40:55,driftfix=slew -no-shutdown -device
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device
virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 -device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive
file=gluster://ovnode01/gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161,if=none,id=drive-virtio-disk0,format=raw,cache=none
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3
root 7137 7083 0 18:44 pts/2 00:00:00 grep --color=auto qemu
If I undefine and redefine myvm adding the spice parts in it, I get
the same bad behaviour as in oVirt
[root@ovnode02 ~]# virsh list --all
Please enter your authentication name: vuser
Please enter your password:
Id Name State
----------------------------------------------------
3 myvm paused
A confirmation of spice involvement I get if I run once C6 from oVirt
using vnc instead of spice.
Now the VM goes running and I can access its console from vnc and the
qemu commandline is:
qemu 10786 1 9 21:05 ? 00:00:14
/usr/bin/qemu-system-x86_64 -machine accel=kvm -name C6 -S -machine
pc-1.0,accel=kvm,usb=off -cpu Nehalem -m 2048 -smp
1,sockets=1,cores=1,threads=1 -uuid
409c5dbe-5e70-40de-bf73-46ef484ea2d7 -smbios
type=1,manufacturer=oVirt,product=oVirt
Node,version=19-3,serial=421F7170-C703-34E3-9628-4588D841F8B1,uuid=409c5dbe-5e70-40de-bf73-46ef484ea2d7
-no-user-config -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/C6.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc
base=2013-10-01T19:05:47,driftfix=slew -no-shutdown -device
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device
virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 -device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive
file=/rhev/data-center/mnt/ovirt.localdomain.local:_var_lib_exports_iso/6e80607d-5437-4fc5-b73c-66794f6381e0/images/11111111-1111-1111-1111-111111111111/CentOS-6.4-x86_64-bin-DVD1.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw,serial=
-device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1
-drive
file=gluster://ovnode01/gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161,if=none,id=drive-virtio-disk0,format=raw,serial=d004045e-620b-4d90-8a7f-6c6d26393a08,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=2
-netdev tap,fd=27,id=hostnet0,vhost=on,vhostfd=28 -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:bb:9f:10,bus=pci.0,addr=0x3,bootindex=3
-chardev
socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/409c5dbe-5e70-40de-bf73-46ef484ea2d7.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/409c5dbe-5e70-40de-bf73-46ef484ea2d7.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
-device usb-tablet,id=input0 -vnc 0:0,password -k en-us -vga cirrus
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7
Any info about how to debug?
Anyone got the former logs and see any information?
Take in mind that the environment is nested virtualization inside ESXi
5.1, so it can take a part too in the problem.
Anyone using spice over glusterfs on f19 without any problem?
On nodes:
[root@ovnode01 ~]# rpm -qa|grep vdsm
vdsm-python-4.12.1-2.fc19.x86_64
vdsm-python-cpopen-4.12.1-2.fc19.x86_64
vdsm-gluster-4.12.1-2.fc19.noarch
vdsm-cli-4.12.1-2.fc19.noarch
vdsm-4.12.1-2.fc19.x86_64
vdsm-xmlrpc-4.12.1-2.fc19.noarch
On engine
[root@ovirt ~]# rpm -qa|grep ovirt
ovirt-engine-restapi-3.3.0-4.fc19.noarch
ovirt-engine-sdk-python-3.3.0.6-1.fc19.noarch
ovirt-log-collector-3.3.0-1.fc19.noarch
ovirt-engine-lib-3.3.0-4.fc19.noarch
ovirt-engine-3.3.0-4.fc19.noarch
ovirt-release-fedora-8-1.noarch
ovirt-iso-uploader-3.3.0-1.fc19.noarch
ovirt-engine-cli-3.3.0.4-1.fc19.noarch
ovirt-engine-setup-3.3.0-4.fc19.noarch
ovirt-engine-dbscripts-3.3.0-4.fc19.noarch
ovirt-host-deploy-java-1.1.1-1.fc19.noarch
ovirt-image-uploader-3.3.0-1.fc19.noarch
ovirt-host-deploy-1.1.1-1.fc19.noarch
ovirt-engine-webadmin-portal-3.3.0-4.fc19.noarch
ovirt-engine-backend-3.3.0-4.fc19.noarch
ovirt-engine-userportal-3.3.0-4.fc19.noarch
ovirt-engine-tools-3.3.0-4.fc19.noarch
Thanks in advance,
Gianluca
2:16 p.m.
On 10/02/2013 12:57 AM, Gianluca Cecchi wrote:
Today I was able to work again on this matter and it seems related to
spice
Every time I start the VM (that is defined with spice) it goes in
and this doesn't happen if the VM is defined with vnc?
paused state and after a few minutes the node gets unreachable, down
form the gui, no response also inside its console and forced to power
off it.
So I tried to create a vm taken from oVirt generated xml using gluster
to see if it is the problem in any way...
and start it via virsh and libvirt on the node.
See in attach:
I got the ovirt generated xml file, under /var/run/libvirt/qemu/C6.xml
myvm.xml the derived vm that defined and started and is able to go and
remain running
[root@ovnode02 ~]# virsh define myvm.xml
Please enter your authentication name: vuser
Please enter your password:
Domain myvm defined from myvm.xml
[root@ovnode02 ~]# virsh list --all
Please enter your authentication name: vuser
Please enter your password:
Id Name State
----------------------------------------------------
- myvm shut off
[root@ovnode02 ~]# virsh start myvm
Please enter your authentication name: vuser
Please enter your password:
Domain myvm started
[root@ovnode02 ~]# virsh list --all
Please enter your authentication name: vuser
Please enter your password:
Id Name State
----------------------------------------------------
2 myvm running
In this case
[root@ovnode02 ~]# ps -ef|grep qemu
qemu 1617 574 0 18:24 ? 00:00:00 [python] <defunct>
qemu 6083 1 7 18:40 ? 00:00:14
/usr/bin/qemu-system-x86_64 -machine accel=kvm -name myvm -S -machine
pc-1.0,accel=kvm,usb=off -cpu Nehalem -m 2048 -smp
1,sockets=1,cores=1,threads=1 -uuid
dfadc661-6288-4f21-8faa-012daf29478f -nographic -no-user-config
-nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/myvm.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc
base=2013-10-01T16:40:55,driftfix=slew -no-shutdown -device
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device
virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 -device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive
file=gluster://ovnode01/gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161,if=none,id=drive-virtio-disk0,format=raw,cache=none
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3
root 7137 7083 0 18:44 pts/2 00:00:00 grep --color=auto qemu
If I undefine and redefine myvm adding the spice parts in it, I get
the same bad behaviour as in oVirt
[root@ovnode02 ~]# virsh list --all
Please enter your authentication name: vuser
Please enter your password:
Id Name State
----------------------------------------------------
3 myvm paused
A confirmation of spice involvement I get if I run once C6 from oVirt
using vnc instead of spice.
Now the VM goes running and I can access its console from vnc and the
qemu commandline is:
qemu 10786 1 9 21:05 ? 00:00:14
/usr/bin/qemu-system-x86_64 -machine accel=kvm -name C6 -S -machine
pc-1.0,accel=kvm,usb=off -cpu Nehalem -m 2048 -smp
1,sockets=1,cores=1,threads=1 -uuid
409c5dbe-5e70-40de-bf73-46ef484ea2d7 -smbios
type=1,manufacturer=oVirt,product=oVirt
Node,version=19-3,serial=421F7170-C703-34E3-9628-4588D841F8B1,uuid=409c5dbe-5e70-40de-bf73-46ef484ea2d7
-no-user-config -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/C6.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc
base=2013-10-01T19:05:47,driftfix=slew -no-shutdown -device
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device
virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 -device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive
file=/rhev/data-center/mnt/ovirt.localdomain.local:_var_lib_exports_iso/6e80607d-5437-4fc5-b73c-66794f6381e0/images/11111111-1111-1111-1111-111111111111/CentOS-6.4-x86_64-bin-DVD1.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw,serial=
-device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1
-drive
file=gluster://ovnode01/gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161,if=none,id=drive-virtio-disk0,format=raw,serial=d004045e-620b-4d90-8a7f-6c6d26393a08,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=2
-netdev tap,fd=27,id=hostnet0,vhost=on,vhostfd=28 -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:bb:9f:10,bus=pci.0,addr=0x3,bootindex=3
-chardev
socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/409c5dbe-5e70-40de-bf73-46ef484ea2d7.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/409c5dbe-5e70-40de-bf73-46ef484ea2d7.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
-device usb-tablet,id=input0 -vnc 0:0,password -k en-us -vga cirrus
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7
Any info about how to debug?
Anyone got the former logs and see any information?
Take in mind that the environment is nested virtualization inside ESXi
5.1, so it can take a part too in the problem.
Anyone using spice over glusterfs on f19 without any problem?
On nodes:
[root@ovnode01 ~]# rpm -qa|grep vdsm
vdsm-python-4.12.1-2.fc19.x86_64
vdsm-python-cpopen-4.12.1-2.fc19.x86_64
vdsm-gluster-4.12.1-2.fc19.noarch
vdsm-cli-4.12.1-2.fc19.noarch
vdsm-4.12.1-2.fc19.x86_64
vdsm-xmlrpc-4.12.1-2.fc19.noarch
On engine
[root@ovirt ~]# rpm -qa|grep ovirt
ovirt-engine-restapi-3.3.0-4.fc19.noarch
ovirt-engine-sdk-python-3.3.0.6-1.fc19.noarch
ovirt-log-collector-3.3.0-1.fc19.noarch
ovirt-engine-lib-3.3.0-4.fc19.noarch
ovirt-engine-3.3.0-4.fc19.noarch
ovirt-release-fedora-8-1.noarch
ovirt-iso-uploader-3.3.0-1.fc19.noarch
ovirt-engine-cli-3.3.0.4-1.fc19.noarch
ovirt-engine-setup-3.3.0-4.fc19.noarch
ovirt-engine-dbscripts-3.3.0-4.fc19.noarch
ovirt-host-deploy-java-1.1.1-1.fc19.noarch
ovirt-image-uploader-3.3.0-1.fc19.noarch
ovirt-host-deploy-1.1.1-1.fc19.noarch
ovirt-engine-webadmin-portal-3.3.0-4.fc19.noarch
ovirt-engine-backend-3.3.0-4.fc19.noarch
ovirt-engine-userportal-3.3.0-4.fc19.noarch
ovirt-engine-tools-3.3.0-4.fc19.noarch
Thanks in advance,
Gianluca
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
5:21 p.m.
On Wed, Oct 2, 2013 at 9:16 PM, Itamar Heim wrote:
On 10/02/2013 12:57 AM, Gianluca Cecchi wrote:
>
> Today I was able to work again on this matter and it seems related to
> spice
> Every time I start the VM (that is defined with spice) it goes in
and this doesn't happen if the VM is defined with vnc?
No, reproduced both from oVirt and through virsh.
with spice defined in boot options or in xml (for virsh) the vm
remains in paused state and after a few minutes it seems the node
hangs...
with vnc the VM goes in runnign state
I'm going to put same config on 2 physical nodes with only local
storage and see what happens and report...
Gianluca
7:53 a.m.
On Thu, Oct 3, 2013 at 12:21 AM, Gianluca Cecchi wrote:
On Wed, Oct 2, 2013 at 9:16 PM, Itamar Heim wrote:
> On 10/02/2013 12:57 AM, Gianluca Cecchi wrote:
>>
>> Today I was able to work again on this matter and it seems related to
>> spice
>> Every time I start the VM (that is defined with spice) it goes in
>
>
> and this doesn't happen if the VM is defined with vnc?
No, reproduced both from oVirt and through virsh.
with spice defined in boot options or in xml (for virsh) the vm
remains in paused state and after a few minutes it seems the node
hangs...
with vnc the VM goes in runnign state
I'm going to put same config on 2 physical nodes with only local
storage and see what happens and report...
Gianluca
So I was able to configure 2xHP blades BL685c G1 (Opteron G2 in oVirt)
with only one internal 72Gb disk each.
It seems here GlusterFS works quite well form the initial tests done.
I used same config as the problematic nested one.
Created a CentOS 6.4 VM, configured as server in oVirt but installed
as default Desktop in anaconda.
The 2 servers are on a Gigabit network
The install phase of the 1089 packages had an elapsed of about 17
minutes before completion.
During install I see (with command "bwm-ng -t 1000") throughput goes
at 55MB/s so it seems quite ok.
Also at the moment the distributed-replicated volume is on ovirtmgmt
itself and I don't see any disconnection from hosts in webadmin.....
I'm going to test more on this infra, and check/compare with the
nested environment that was configured quite the same...
unfortunately not much disk space to use and stress... ;-(
Gianluca
7:54 a.m.
On 10/03/2013 01:21 AM, Gianluca Cecchi wrote:
On Wed, Oct 2, 2013 at 9:16 PM, Itamar Heim wrote:
> On 10/02/2013 12:57 AM, Gianluca Cecchi wrote:
>>
>> Today I was able to work again on this matter and it seems related to
>> spice
>> Every time I start the VM (that is defined with spice) it goes in
>
>
> and this doesn't happen if the VM is defined with vnc?
No, reproduced both from oVirt and through virsh.
with spice defined in boot options or in xml (for virsh) the vm
remains in paused state and after a few minutes it seems the node
hangs...
with vnc the VM goes in runnign state
I'm going to put same config on 2 physical nodes with only local
storage and see what happens and report...
Gianluca
adding spice-devel mailing list as the VM only hangs if started with
spice and not with vnc, from virsh as well.
1:02 a.m.
On 09/25/2013 02:10 AM, Gianluca Cecchi wrote:
Hello,
I'm testing GlusterFS on 3.3 with fedora 19 systems.
One engine (ovirt) + 2 nodes (ovnode01 and ovnode02)
Successfully created gluster volume composed by two bricks (one for
each vdsm node) distributed replicated
Suggestion:
If page
http://www.ovirt.org/Features/GlusterFS_Storage_Domain
is the reference, perhaps it would be better to explicitly specify
that one has to start the created volume before going to add a storage
domain based on the created volume.
Not knowing Gluster could lead to think that the start phase is
responsibility of storage domain creation itself ...
its a wiki - please edit/fix it ;)
1:23 a.m.
On Wed, Sep 25, 2013 at 8:02 AM, Itamar Heim wrote:
> Suggestion:
> If page
> http://www.ovirt.org/Features/GlusterFS_Storage_Domain
> is the reference, perhaps it would be better to explicitly specify
> that one has to start the created volume before going to add a storage
> domain based on the created volume.
> Not knowing Gluster could lead to think that the start phase is
> responsibility of storage domain creation itself ...
its a wiki - please edit/fix it ;)
I was in doubt because it is not explictly set as wiki but more as infra ...
I'll do
3881
days inactive
3890
days old
16 comments
5 participants
participants (5)
-
David Riedl -
Gianluca Cecchi -
Itamar Heim -
Kanagaraj -
Vijay Bellur