Sure.
Here''s the sequence of events. Provision LVM for a VM. This creates
a DM device. It has a certain size. Boot the VM on it.
Later on, customers wants more space. We expand the logical volume
with LVM, which does some cleverness with the DM device to cause it to
grow bigger. This is pretty much plain-jane LVM up to this point.
When we check the size of the block device from outside the VM, it
shows the new size. From within, it shows the old, smaller size. In
the olden days, you could do "xm block-configure ...." to cause the VM
to pick up the changes. That hasn''t worked for me for ages (and
digging in the code turned up some interesting comments indicating
that it may have not been re-implemented during a rewrite).
On Apr 13, 2008, at 8:58 AM, Mark Williamson wrote:
>> Our business currently provides literally thousands of VMs with
>> filesystems via blkback / blkfront.
>
> Wow! Cool :-)
>
>> For security purposes, it''s
>> absolutely critical that we keep LVM outside of the VMs.
>
> OK. I generally recommend keeping LVM outside VMs anyhow, to ease
> administration.
>
>> What is the
>> feasibility of getting block-configure to actually update the DomUs
>> concept of the disk of a block device device?
>>
>> It hasn''t worked for us for quite a while.
>
> I don''t quite understand what you''re trying to do? Could
you please
> provide a
> little more detail?
>
> Is the idea just to make the resizing of LVM volumes visible to the
> guest?
> I''m not sure exactly why this would be broken but I can imagine it
> might have
> been. It''d certainly be a useful feature to have back.
>
> Cheers,
> Mark
>
> --
> Push Me Pull You - Distributed SCM tool
(http://www.cl.cam.ac.uk/~maw48/pmpu/
> )
--
Jayson Vantuyl
Systems Architect
Engine Yard
jvantuyl@engineyard.com
1 866 518 9275 ext 204
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel