>>> On 3/11/2010 at 6:13 PM, in message <4B997922.1080407@xxxxxxxx>, Jeremy
Fitzhardinge <jeremy@xxxxxxxx> wrote:
> On 03/11/2010 02:01 PM, Ky Srinivasan wrote:
>>
>>
>>>>> On 3/11/2010 at 4:44 PM, in message<4B996436.1000600@xxxxxxxx>, Jeremy
>>>>>
>> Fitzhardinge<jeremy@xxxxxxxx> wrote:
>>
>>> On 03/11/2010 12:15 PM, Pasi Kärkkäinen wrote:
>>>
>>>> On Tue, Mar 09, 2010 at 01:39:23PM -0700, Ky Srinivasan wrote:
>>>>
>>>>
>>>>>
>>>>>
>>>>>>>> On 3/9/2010 at 3:35 PM, in
>>>>>>>> message<20100309203557.GJ1878@xxxxxxxxxxx>, Pasi
>>>>>>>>
>>>>>>>>
>>>>> Kärkkäinen<pasik@xxxxxx> wrote:
>>>>>
>>>>>
>>>>>> On Tue, Mar 09, 2010 at 01:31:17PM -0700, Ky Srinivasan wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>> On 3/9/2010 at 3:15 PM, in
>>>>>>>>>> message<20100309201529.GH1878@xxxxxxxxxxx>, Pasi
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> Kärkkäinen<pasik@xxxxxx> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On Tue, Mar 09, 2010 at 12:56:11PM -0700, Ky Srinivasan wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> The attached patch supports dynamic resizing of vbds.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Nice! Did you also implement the xm/xend side of resizing?
>>>>>>>>
>>>>>>>>
>>>>>>> My goal was to not have the end-user do anything other than what
>>>>>>> was minimally required to resizing the device on the host side.
>>>>>>> Once the device is resized on the host side, this capacity change
>>>>>>> is propagated to the guest without having to invoke any xm command.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Oh, even better!
>>>>>> What version of the kernel did you test with? 2.6.27?
>>>>>>
>>>>>>
>>>>> I tested this on 2.6.32. The patches should apply to earlier kernels
>>>>> without
>>>>>
>>> too much trouble.
>>>
>>>>>
>>>>>
>>>> Great!
>>>>
>>>> Jeremy: Hopefully you can add this patch to your tree.
>>>>
>>>>
>>> It applied fairly cleanly, but I haven't tested it yet. Ky, by 2.6.32 I
>>> assume I mean your one, not pvops? (Because your patch is touching
>>> blkfront in the wrong place.)
>>>
>> Yes. This patch was against our sles11 sp1.
>>
>
> What happens if the frontend doesn't support the resize, and the device
> shrinks? Will the backend just raise IO errors for out of range requests?
Clearly, resizing is an operation that ought to be done with great care and
co-ordination between the administrators of the guest and the host. If the
device on the host side is shrunk without co-ordinating with the guest, seeing
I/O errors will be the least of our problems!
The situation you describe can occur today without this patch - consider the
case where an LVM based device is resized on the host side (device is shrunk as
in your example). We will be generating I/O errors for out of range request on
the backend in this scenario. Assuming all the co-ordination is done, this
patch automates propagating the capacity change without having to detach and
attach the storage from the guest.
Regards,
K. Y
>
> J
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home