Cole Robinson | 13 Aug 02:17
Favicon

[PATCH] virtinst: add storage builders for logical pools and volumes

The attached patch adds virtinst support for building
logical pools and volumes. Sort of. This will allow
creating new volumes, but not creating pools (aka
volume groups) from a specified set of physical disks.
I believe libvirt supports this, but I haven't tried it
yet.

However this does allow the user to point at an existing
lvm volume group and have it recognized as a storage pool
which will be by far the common case. The nice thing
about this is that it will all become immediately available
in the virt-manager UI (posted previously).

One thing I've encountered with this though: does a volume's
target path have any significance upon creation? File volumes
just seem to create a file based on the passed 'name', not
target path. Disk volumes ignore both when creating. Logical
vols also only use the name, but try to validate the target
path after creation, which we shouldn't need passed (the result
should simply be vgpath + "/" + volname). So it seems like
target path has no real meaning when defining a volume. Am
I missing something?

Thanks,
Cole

_______________________________________________
(Continue reading)

Daniel P. Berrange | 13 Aug 12:56
Favicon

Re: [PATCH] virtinst: add storage builders for logical pools and volumes

On Tue, Aug 12, 2008 at 08:21:15PM -0400, Cole Robinson wrote:
> The attached patch adds virtinst support for building
> logical pools and volumes. Sort of. This will allow
> creating new volumes, but not creating pools (aka
> volume groups) from a specified set of physical disks.
> I believe libvirt supports this, but I haven't tried it
> yet.

Not a huge issue - using a pre-existing volume group is by
far the most important use case here.

> However this does allow the user to point at an existing
> lvm volume group and have it recognized as a storage pool
> which will be by far the common case. The nice thing
> about this is that it will all become immediately available
> in the virt-manager UI (posted previously).

Looks good.

> One thing I've encountered with this though: does a volume's
> target path have any significance upon creation? File volumes
> just seem to create a file based on the passed 'name', not
> target path. Disk volumes ignore both when creating. Logical
> vols also only use the name, but try to validate the target
> path after creation, which we shouldn't need passed (the result
> should simply be vgpath + "/" + volname). So it seems like
> target path has no real meaning when defining a volume. Am
> I missing something?

That is correct - the target path for a volume is filled in
(Continue reading)

Cole Robinson | 14 Aug 19:15
Favicon

Re: [PATCH] virtinst: add storage builders for logical pools and volumes

Daniel P. Berrange wrote:
> On Tue, Aug 12, 2008 at 08:21:15PM -0400, Cole Robinson wrote:
>> The attached patch adds virtinst support for building
>> logical pools and volumes. Sort of. This will allow
>> creating new volumes, but not creating pools (aka
>> volume groups) from a specified set of physical disks.
>> I believe libvirt supports this, but I haven't tried it
>> yet.
> 
> Not a huge issue - using a pre-existing volume group is by
> far the most important use case here.
> 
>> However this does allow the user to point at an existing
>> lvm volume group and have it recognized as a storage pool
>> which will be by far the common case. The nice thing
>> about this is that it will all become immediately available
>> in the virt-manager UI (posted previously).
> 
> Looks good.
> 
>> One thing I've encountered with this though: does a volume's
>> target path have any significance upon creation? File volumes
>> just seem to create a file based on the passed 'name', not
>> target path. Disk volumes ignore both when creating. Logical
>> vols also only use the name, but try to validate the target
>> path after creation, which we shouldn't need passed (the result
>> should simply be vgpath + "/" + volname). So it seems like
>> target path has no real meaning when defining a volume. Am
>> I missing something?
> 
(Continue reading)


Gmane