Setting iotune limits on rbd

Setting iotune limits on rbd

[Andrey Korolyov]

Hi,

# virsh blkdeviotune Test vdb --write_iops_sec 50 //file block device

# virsh blkdeviotune Test vda --write_iops_sec 50 //rbd block device
error: Unable to change block I/O throttle
error: invalid argument: No device found for specified path

2012-04-03 07:38:49.170+0000: 30171: debug :
virDomainSetBlockIoTune:18317 : dom=0x1114590, (VM: name=Test,
uuid=8c27bf32-82dc-315a-d0ba-4653b1b3d595), disk=vda,
params=0x1114600, nparams=1, flags=0
2012-04-03 07:38:49.170+0000: 30169: debug :
virEventPollMakePollFDs:383 : Prepare n=8 w=11, f=16 e=1 d=0
2012-04-03 07:38:49.170+0000: 30169: debug :
virEventPollCalculateTimeout:325 : Calculate expiry of 4 timers
2012-04-03 07:38:49.170+0000: 30169: debug :
virEventPollCalculateTimeout:331 : Got a timeout scheduled for
1333438734170
2012-04-03 07:38:49.170+0000: 30171: error : qemuDiskPathToAlias:11338
: invalid argument: No device found for specified path
2012-04-03 07:38:49.170+0000: 30171: debug : virDomainFree:2313 :
dom=0x1114590, (VM: name=Test,
uuid=8c27bf32-82dc-315a-d0ba-4653b1b3d595)
2012-04-03 07:38:49.170+0000: 30171: debug : virUnrefDomain:276 :
unref domain 0x1114590 Test 1
2012-04-03 07:38:49.170+0000: 30171: debug : virReleaseDomain:238 :
release domain 0x1114590 Test 8c27bf32-82dc-315a-d0ba-4653b1b3d595
2012-04-03 07:38:49.170+0000: 30169: debug :
virEventPollCalculateTimeout:351 : Timeout at 1333438734170 due in
5000 ms
2012-04-03 07:38:49.170+0000: 30169: debug : virEventPollRunOnce:619 :
EVENT_POLL_RUN: nhandles=9 imeout=5000
2012-04-03 07:38:49.170+0000: 30171: debug : virReleaseDomain:246 :
unref connection 0x1177b10 2

libvir 0.9.10, json-escape patch applied, but seems that this problem
related to another incorrect path handle.

I`m in doubt if it belongs to libvirt ml or here.

Re: Setting iotune limits on rbd

[Wido den Hollander]

Hi,

Op 3-4-2012 10:02, Andrey Korolyov schreef:
> Hi,
>
> # virsh blkdeviotune Test vdb --write_iops_sec 50 //file block device
>
> # virsh blkdeviotune Test vda --write_iops_sec 50 //rbd block device
> error: Unable to change block I/O throttle
> error: invalid argument: No device found for specified path

That is correct. As far as I know iotune uses the underlying cgroups 
from the OS.

RBD devices (when using Qemu) are not block devices which can be managed 
by cgroups. That's why it's not working and you get the error that the 
device can't be found.

There is however somebody working on DiskIoThrottling inside Qemu: 
http://wiki.qemu.org/Features/DiskIOLimits

That would work with RBD (he even names Ceph :) )

Wido

>
> 2012-04-03 07:38:49.170+0000: 30171: debug :
> virDomainSetBlockIoTune:18317 : dom=0x1114590, (VM: name=Test,
> uuid=8c27bf32-82dc-315a-d0ba-4653b1b3d595), disk=vda,
> params=0x1114600, nparams=1, flags=0
> 2012-04-03 07:38:49.170+0000: 30169: debug :
> virEventPollMakePollFDs:383 : Prepare n=8 w=11, f=16 e=1 d=0
> 2012-04-03 07:38:49.170+0000: 30169: debug :
> virEventPollCalculateTimeout:325 : Calculate expiry of 4 timers
> 2012-04-03 07:38:49.170+0000: 30169: debug :
> virEventPollCalculateTimeout:331 : Got a timeout scheduled for
> 1333438734170
> 2012-04-03 07:38:49.170+0000: 30171: error : qemuDiskPathToAlias:11338
> : invalid argument: No device found for specified path
> 2012-04-03 07:38:49.170+0000: 30171: debug : virDomainFree:2313 :
> dom=0x1114590, (VM: name=Test,
> uuid=8c27bf32-82dc-315a-d0ba-4653b1b3d595)
> 2012-04-03 07:38:49.170+0000: 30171: debug : virUnrefDomain:276 :
> unref domain 0x1114590 Test 1
> 2012-04-03 07:38:49.170+0000: 30171: debug : virReleaseDomain:238 :
> release domain 0x1114590 Test 8c27bf32-82dc-315a-d0ba-4653b1b3d595
> 2012-04-03 07:38:49.170+0000: 30169: debug :
> virEventPollCalculateTimeout:351 : Timeout at 1333438734170 due in
> 5000 ms
> 2012-04-03 07:38:49.170+0000: 30169: debug : virEventPollRunOnce:619 :
> EVENT_POLL_RUN: nhandles=9 imeout=5000
> 2012-04-03 07:38:49.170+0000: 30171: debug : virReleaseDomain:246 :
> unref connection 0x1177b10 2
>
> libvir 0.9.10, json-escape patch applied, but seems that this problem
> related to another incorrect path handle.
>
> I`m in doubt if it belongs to libvirt ml or here.
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Setting iotune limits on rbd

[Andrey Korolyov]

But I am able to set static limits in the config for rbd :) All I want
is a change on-the-fly.

It is NOT cgroups mechanism, but completely qemu-driven.

On Tue, Apr 3, 2012 at 12:21 PM, Wido den Hollander <wido@widodh.nl> wrote:
> Hi,
>
> Op 3-4-2012 10:02, Andrey Korolyov schreef:
>
>> Hi,
>>
>> # virsh blkdeviotune Test vdb --write_iops_sec 50 //file block device
>>
>> # virsh blkdeviotune Test vda --write_iops_sec 50 //rbd block device
>> error: Unable to change block I/O throttle
>> error: invalid argument: No device found for specified path
>
>
> That is correct. As far as I know iotune uses the underlying cgroups from
> the OS.
>
> RBD devices (when using Qemu) are not block devices which can be managed by
> cgroups. That's why it's not working and you get the error that the device
> can't be found.
>
> There is however somebody working on DiskIoThrottling inside Qemu:
> http://wiki.qemu.org/Features/DiskIOLimits
>
> That would work with RBD (he even names Ceph :) )
>
> Wido
>
>>
>> 2012-04-03 07:38:49.170+0000: 30171: debug :
>> virDomainSetBlockIoTune:18317 : dom=0x1114590, (VM: name=Test,
>> uuid=8c27bf32-82dc-315a-d0ba-4653b1b3d595), disk=vda,
>> params=0x1114600, nparams=1, flags=0
>> 2012-04-03 07:38:49.170+0000: 30169: debug :
>> virEventPollMakePollFDs:383 : Prepare n=8 w=11, f=16 e=1 d=0
>> 2012-04-03 07:38:49.170+0000: 30169: debug :
>> virEventPollCalculateTimeout:325 : Calculate expiry of 4 timers
>> 2012-04-03 07:38:49.170+0000: 30169: debug :
>> virEventPollCalculateTimeout:331 : Got a timeout scheduled for
>> 1333438734170
>> 2012-04-03 07:38:49.170+0000: 30171: error : qemuDiskPathToAlias:11338
>> : invalid argument: No device found for specified path
>> 2012-04-03 07:38:49.170+0000: 30171: debug : virDomainFree:2313 :
>> dom=0x1114590, (VM: name=Test,
>> uuid=8c27bf32-82dc-315a-d0ba-4653b1b3d595)
>> 2012-04-03 07:38:49.170+0000: 30171: debug : virUnrefDomain:276 :
>> unref domain 0x1114590 Test 1
>> 2012-04-03 07:38:49.170+0000: 30171: debug : virReleaseDomain:238 :
>> release domain 0x1114590 Test 8c27bf32-82dc-315a-d0ba-4653b1b3d595
>> 2012-04-03 07:38:49.170+0000: 30169: debug :
>> virEventPollCalculateTimeout:351 : Timeout at 1333438734170 due in
>> 5000 ms
>> 2012-04-03 07:38:49.170+0000: 30169: debug : virEventPollRunOnce:619 :
>> EVENT_POLL_RUN: nhandles=9 imeout=5000
>> 2012-04-03 07:38:49.170+0000: 30171: debug : virReleaseDomain:246 :
>> unref connection 0x1177b10 2
>>
>> libvir 0.9.10, json-escape patch applied, but seems that this problem
>> related to another incorrect path handle.
>>
>> I`m in doubt if it belongs to libvirt ml or here.
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Setting iotune limits on rbd

[Wido den Hollander]

Op 3-4-2012 10:28, Andrey Korolyov schreef:
> But I am able to set static limits in the config for rbd :) All I want
> is a change on-the-fly.
>
> It is NOT cgroups mechanism, but completely qemu-driven.

Are you sure about that? 
http://libvirt.org/formatdomain.html#elementsBlockTuning

Browsing through the source code I found that this is indeed related to 
libvirt.

In the Qemu driver:

     if (disk->type != VIR_DOMAIN_DISK_TYPE_BLOCK &&
         disk->type != VIR_DOMAIN_DISK_TYPE_FILE)
         goto cleanup;
...
...
cleanup:
     if (!ret) {
         qemuReportError(VIR_ERR_INVALID_ARG,
                         "%s", _("No device found for specified path"));
     }


RBD devices are however of the type: VIR_DOMAIN_DISK_TYPE_NETWORK

That's why you get this error, it's assuming the device you want to set 
the limits on is a block device or a regular file.

Wido

>
> On Tue, Apr 3, 2012 at 12:21 PM, Wido den Hollander<wido@widodh.nl>  wrote:
>> Hi,
>>
>> Op 3-4-2012 10:02, Andrey Korolyov schreef:
>>
>>> Hi,
>>>
>>> # virsh blkdeviotune Test vdb --write_iops_sec 50 //file block device
>>>
>>> # virsh blkdeviotune Test vda --write_iops_sec 50 //rbd block device
>>> error: Unable to change block I/O throttle
>>> error: invalid argument: No device found for specified path
>>
>>
>> That is correct. As far as I know iotune uses the underlying cgroups from
>> the OS.
>>
>> RBD devices (when using Qemu) are not block devices which can be managed by
>> cgroups. That's why it's not working and you get the error that the device
>> can't be found.
>>
>> There is however somebody working on DiskIoThrottling inside Qemu:
>> http://wiki.qemu.org/Features/DiskIOLimits
>>
>> That would work with RBD (he even names Ceph :) )
>>
>> Wido
>>
>>>
>>> 2012-04-03 07:38:49.170+0000: 30171: debug :
>>> virDomainSetBlockIoTune:18317 : dom=0x1114590, (VM: name=Test,
>>> uuid=8c27bf32-82dc-315a-d0ba-4653b1b3d595), disk=vda,
>>> params=0x1114600, nparams=1, flags=0
>>> 2012-04-03 07:38:49.170+0000: 30169: debug :
>>> virEventPollMakePollFDs:383 : Prepare n=8 w=11, f=16 e=1 d=0
>>> 2012-04-03 07:38:49.170+0000: 30169: debug :
>>> virEventPollCalculateTimeout:325 : Calculate expiry of 4 timers
>>> 2012-04-03 07:38:49.170+0000: 30169: debug :
>>> virEventPollCalculateTimeout:331 : Got a timeout scheduled for
>>> 1333438734170
>>> 2012-04-03 07:38:49.170+0000: 30171: error : qemuDiskPathToAlias:11338
>>> : invalid argument: No device found for specified path
>>> 2012-04-03 07:38:49.170+0000: 30171: debug : virDomainFree:2313 :
>>> dom=0x1114590, (VM: name=Test,
>>> uuid=8c27bf32-82dc-315a-d0ba-4653b1b3d595)
>>> 2012-04-03 07:38:49.170+0000: 30171: debug : virUnrefDomain:276 :
>>> unref domain 0x1114590 Test 1
>>> 2012-04-03 07:38:49.170+0000: 30171: debug : virReleaseDomain:238 :
>>> release domain 0x1114590 Test 8c27bf32-82dc-315a-d0ba-4653b1b3d595
>>> 2012-04-03 07:38:49.170+0000: 30169: debug :
>>> virEventPollCalculateTimeout:351 : Timeout at 1333438734170 due in
>>> 5000 ms
>>> 2012-04-03 07:38:49.170+0000: 30169: debug : virEventPollRunOnce:619 :
>>> EVENT_POLL_RUN: nhandles=9 imeout=5000
>>> 2012-04-03 07:38:49.170+0000: 30171: debug : virReleaseDomain:246 :
>>> unref connection 0x1177b10 2
>>>
>>> libvir 0.9.10, json-escape patch applied, but seems that this problem
>>> related to another incorrect path handle.
>>>
>>> I`m in doubt if it belongs to libvirt ml or here.
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Setting iotune limits on rbd

[Andrey Korolyov]

At least, elements under <iotune> block applies to rbd and you can
test it by running fio, for example. I have suggested by reading
libvirt code that blkdeviotune call can be applied to pseudo-devices,
there are no counterpoints in code that shows different behavior for
iotune and blkdeviotune calls at all. Seems that libvirt folks did not
pushed workaround for sheepdog/ceph at all. I`ll try a dirty hack in
this code snippet (somehow, I overlooked such idea that there is no
non-block workaround) and report soon.

On Tue, Apr 3, 2012 at 12:45 PM, Wido den Hollander <wido@widodh.nl> wrote:
> Op 3-4-2012 10:28, Andrey Korolyov schreef:
>
>> But I am able to set static limits in the config for rbd :) All I want
>> is a change on-the-fly.
>>
>> It is NOT cgroups mechanism, but completely qemu-driven.
>
>
> Are you sure about that?
> http://libvirt.org/formatdomain.html#elementsBlockTuning
>
> Browsing through the source code I found that this is indeed related to
> libvirt.
>
> In the Qemu driver:
>
>    if (disk->type != VIR_DOMAIN_DISK_TYPE_BLOCK &&
>        disk->type != VIR_DOMAIN_DISK_TYPE_FILE)
>        goto cleanup;
> ...
> ...
> cleanup:
>    if (!ret) {
>        qemuReportError(VIR_ERR_INVALID_ARG,
>                        "%s", _("No device found for specified path"));
>    }
>
>
> RBD devices are however of the type: VIR_DOMAIN_DISK_TYPE_NETWORK
>
> That's why you get this error, it's assuming the device you want to set the
> limits on is a block device or a regular file.
>
> Wido
>
>
>>
>> On Tue, Apr 3, 2012 at 12:21 PM, Wido den Hollander<wido@widodh.nl>
>>  wrote:
>>>
>>> Hi,
>>>
>>> Op 3-4-2012 10:02, Andrey Korolyov schreef:
>>>
>>>> Hi,
>>>>
>>>> # virsh blkdeviotune Test vdb --write_iops_sec 50 //file block device
>>>>
>>>> # virsh blkdeviotune Test vda --write_iops_sec 50 //rbd block device
>>>> error: Unable to change block I/O throttle
>>>> error: invalid argument: No device found for specified path
>>>
>>>
>>>
>>> That is correct. As far as I know iotune uses the underlying cgroups from
>>> the OS.
>>>
>>> RBD devices (when using Qemu) are not block devices which can be managed
>>> by
>>> cgroups. That's why it's not working and you get the error that the
>>> device
>>> can't be found.
>>>
>>> There is however somebody working on DiskIoThrottling inside Qemu:
>>> http://wiki.qemu.org/Features/DiskIOLimits
>>>
>>> That would work with RBD (he even names Ceph :) )
>>>
>>> Wido
>>>
>>>>
>>>> 2012-04-03 07:38:49.170+0000: 30171: debug :
>>>> virDomainSetBlockIoTune:18317 : dom=0x1114590, (VM: name=Test,
>>>> uuid=8c27bf32-82dc-315a-d0ba-4653b1b3d595), disk=vda,
>>>> params=0x1114600, nparams=1, flags=0
>>>> 2012-04-03 07:38:49.170+0000: 30169: debug :
>>>> virEventPollMakePollFDs:383 : Prepare n=8 w=11, f=16 e=1 d=0
>>>> 2012-04-03 07:38:49.170+0000: 30169: debug :
>>>> virEventPollCalculateTimeout:325 : Calculate expiry of 4 timers
>>>> 2012-04-03 07:38:49.170+0000: 30169: debug :
>>>> virEventPollCalculateTimeout:331 : Got a timeout scheduled for
>>>> 1333438734170
>>>> 2012-04-03 07:38:49.170+0000: 30171: error : qemuDiskPathToAlias:11338
>>>> : invalid argument: No device found for specified path
>>>> 2012-04-03 07:38:49.170+0000: 30171: debug : virDomainFree:2313 :
>>>> dom=0x1114590, (VM: name=Test,
>>>> uuid=8c27bf32-82dc-315a-d0ba-4653b1b3d595)
>>>> 2012-04-03 07:38:49.170+0000: 30171: debug : virUnrefDomain:276 :
>>>> unref domain 0x1114590 Test 1
>>>> 2012-04-03 07:38:49.170+0000: 30171: debug : virReleaseDomain:238 :
>>>> release domain 0x1114590 Test 8c27bf32-82dc-315a-d0ba-4653b1b3d595
>>>> 2012-04-03 07:38:49.170+0000: 30169: debug :
>>>> virEventPollCalculateTimeout:351 : Timeout at 1333438734170 due in
>>>> 5000 ms
>>>> 2012-04-03 07:38:49.170+0000: 30169: debug : virEventPollRunOnce:619 :
>>>> EVENT_POLL_RUN: nhandles=9 imeout=5000
>>>> 2012-04-03 07:38:49.170+0000: 30171: debug : virReleaseDomain:246 :
>>>> unref connection 0x1177b10 2
>>>>
>>>> libvir 0.9.10, json-escape patch applied, but seems that this problem
>>>> related to another incorrect path handle.
>>>>
>>>> I`m in doubt if it belongs to libvirt ml or here.
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Setting iotune limits on rbd

[Andrey Korolyov]

Suggested hack works, seems that libvirt devs does not remove block
limitation as they count this feature as experimental, or forgot about
it.

On Tue, Apr 3, 2012 at 12:55 PM, Andrey Korolyov <andrey@xdel.ru> wrote:
> At least, elements under <iotune> block applies to rbd and you can
> test it by running fio, for example. I have suggested by reading
> libvirt code that blkdeviotune call can be applied to pseudo-devices,
> there are no counterpoints in code that shows different behavior for
> iotune and blkdeviotune calls at all. Seems that libvirt folks did not
> pushed workaround for sheepdog/ceph at all. I`ll try a dirty hack in
> this code snippet (somehow, I overlooked such idea that there is no
> non-block workaround) and report soon.
>
> On Tue, Apr 3, 2012 at 12:45 PM, Wido den Hollander <wido@widodh.nl> wrote:
>> Op 3-4-2012 10:28, Andrey Korolyov schreef:
>>
>>> But I am able to set static limits in the config for rbd :) All I want
>>> is a change on-the-fly.
>>>
>>> It is NOT cgroups mechanism, but completely qemu-driven.
>>
>>
>> Are you sure about that?
>> http://libvirt.org/formatdomain.html#elementsBlockTuning
>>
>> Browsing through the source code I found that this is indeed related to
>> libvirt.
>>
>> In the Qemu driver:
>>
>>    if (disk->type != VIR_DOMAIN_DISK_TYPE_BLOCK &&
>>        disk->type != VIR_DOMAIN_DISK_TYPE_FILE)
>>        goto cleanup;
>> ...
>> ...
>> cleanup:
>>    if (!ret) {
>>        qemuReportError(VIR_ERR_INVALID_ARG,
>>                        "%s", _("No device found for specified path"));
>>    }
>>
>>
>> RBD devices are however of the type: VIR_DOMAIN_DISK_TYPE_NETWORK
>>
>> That's why you get this error, it's assuming the device you want to set the
>> limits on is a block device or a regular file.
>>
>> Wido
>>
>>
>>>
>>> On Tue, Apr 3, 2012 at 12:21 PM, Wido den Hollander<wido@widodh.nl>
>>>  wrote:
>>>>
>>>> Hi,
>>>>
>>>> Op 3-4-2012 10:02, Andrey Korolyov schreef:
>>>>
>>>>> Hi,
>>>>>
>>>>> # virsh blkdeviotune Test vdb --write_iops_sec 50 //file block device
>>>>>
>>>>> # virsh blkdeviotune Test vda --write_iops_sec 50 //rbd block device
>>>>> error: Unable to change block I/O throttle
>>>>> error: invalid argument: No device found for specified path
>>>>
>>>>
>>>>
>>>> That is correct. As far as I know iotune uses the underlying cgroups from
>>>> the OS.
>>>>
>>>> RBD devices (when using Qemu) are not block devices which can be managed
>>>> by
>>>> cgroups. That's why it's not working and you get the error that the
>>>> device
>>>> can't be found.
>>>>
>>>> There is however somebody working on DiskIoThrottling inside Qemu:
>>>> http://wiki.qemu.org/Features/DiskIOLimits
>>>>
>>>> That would work with RBD (he even names Ceph :) )
>>>>
>>>> Wido
>>>>
>>>>>
>>>>> 2012-04-03 07:38:49.170+0000: 30171: debug :
>>>>> virDomainSetBlockIoTune:18317 : dom=0x1114590, (VM: name=Test,
>>>>> uuid=8c27bf32-82dc-315a-d0ba-4653b1b3d595), disk=vda,
>>>>> params=0x1114600, nparams=1, flags=0
>>>>> 2012-04-03 07:38:49.170+0000: 30169: debug :
>>>>> virEventPollMakePollFDs:383 : Prepare n=8 w=11, f=16 e=1 d=0
>>>>> 2012-04-03 07:38:49.170+0000: 30169: debug :
>>>>> virEventPollCalculateTimeout:325 : Calculate expiry of 4 timers
>>>>> 2012-04-03 07:38:49.170+0000: 30169: debug :
>>>>> virEventPollCalculateTimeout:331 : Got a timeout scheduled for
>>>>> 1333438734170
>>>>> 2012-04-03 07:38:49.170+0000: 30171: error : qemuDiskPathToAlias:11338
>>>>> : invalid argument: No device found for specified path
>>>>> 2012-04-03 07:38:49.170+0000: 30171: debug : virDomainFree:2313 :
>>>>> dom=0x1114590, (VM: name=Test,
>>>>> uuid=8c27bf32-82dc-315a-d0ba-4653b1b3d595)
>>>>> 2012-04-03 07:38:49.170+0000: 30171: debug : virUnrefDomain:276 :
>>>>> unref domain 0x1114590 Test 1
>>>>> 2012-04-03 07:38:49.170+0000: 30171: debug : virReleaseDomain:238 :
>>>>> release domain 0x1114590 Test 8c27bf32-82dc-315a-d0ba-4653b1b3d595
>>>>> 2012-04-03 07:38:49.170+0000: 30169: debug :
>>>>> virEventPollCalculateTimeout:351 : Timeout at 1333438734170 due in
>>>>> 5000 ms
>>>>> 2012-04-03 07:38:49.170+0000: 30169: debug : virEventPollRunOnce:619 :
>>>>> EVENT_POLL_RUN: nhandles=9 imeout=5000
>>>>> 2012-04-03 07:38:49.170+0000: 30171: debug : virReleaseDomain:246 :
>>>>> unref connection 0x1177b10 2
>>>>>
>>>>> libvir 0.9.10, json-escape patch applied, but seems that this problem
>>>>> related to another incorrect path handle.
>>>>>
>>>>> I`m in doubt if it belongs to libvirt ml or here.
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>>
>>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html