[Libvir] PATCH: 0/7 Implementation of storage APIs
Daniel P. Berrange
berrange at redhat.com
Mon Oct 29 13:52:04 UTC 2007
On Mon, Oct 29, 2007 at 12:03:34PM +0000, Richard W.M. Jones wrote:
> General comments. (I haven't yet read the patches line by line, but
> there are some things that I noticed that we can get back to later.)
>
> I patched up my libvirt with all the patches (the remote patches turned
> out to be necessary after all for reasons I now understand -- see below).
>
> Out of the box, I can do:
>
> # virsh pool-list
> Name State Autostart
> -----------------------------------------
>
> Now I have to add my storage pools manually. Even after reading
> previous mail on the XML formats, it was very unclear what the correct
> format to use was:
>
> # cat /tmp/pool.xml
> <pool type="fs">
> <name>xenimages</name>
> <uuid>12345678-1234-1234-1234-123456781234</uuid>
> <target dir="/var/lib/xen/images"/>
> <permissions>
> <mode>0700</mode>
> <owner>0</owner>
> <group>0</group>
> <label>xen_image_t</label>
> </permissions>
> </pool>
>
> # src/virsh pool-create /tmp/pool.xml
> Pool xenimages created from /tmp/pool.xml
As we did with virsh attach-disk/attach-interface, vs attach-device
I think it would be helpful to provide a 'virsh vol-create' variant
which took a handful of explicit args as an alternative to the XML,
eg virsh pool-create --type fs xenimages /var/lib/xen/images
It wouldn't have the full capabilities to set every single XML
attribute/element, but would be good enough so that admins didn't
need to write the XML for the 95% common case.
>
> The first problem here is that we've got the "secret config files"
> again. I know that Xen made this idiotic mistake of hiding the config
> files from the world, and in libvirt we have to work around it for
> domains, but there's no particular reason why we have to copy this bad,
> non-Unix-like design decision into other parts of our API.
The config file are not hidden/secret - they're in the usual libvirt
daemon config location /etc/libvirt/storage/[pool name].xml
As we do with the 'default' network, we can easily ship a canned config
file for say, /var/lib/virt/images as a local directory based pool.
Any other type of pool is going to be site-specific, but we can provide
a selection of common example configs as needed.
> I was envisaging a much more straightforward config file:
>
> /etc/libvirt.conf -------------------
>
> disk_storage_pools: [ "/var/lib/xen/images" ]
> lvm_volgroups: [ "/dev/MyXenImages" ]
> -------------------------------------
That is not sufficient to describe all the metadata for the different
types of storage pool.
> With this, you don't need to put storage logic into libvirtd. It can
> all be discovered on demand, just using the config file and the commands
> already included in storage_backend_*.c The upshot is that we don't
> need a daemon to manage storage pools, except in the remote case where
> it's just there to do things remotely.
To be honest even in the local case we need the daemon. The only reason
we previously get away without having a daemon when running locally, is
that the entire virt-manager app has run as root. Long term I think
pretty much all libvirt clients will be going via the daemon, whether
local or remote.
> (To be fair, the proposed patch seems to have a config file in
> /etc/libvirt/storage/storage.conf, but it's not implemented at the
> moment and it is unclear what will go in here, and whether a suitable
> default can be created to allow storage pools to default to something
> sensible on Fedora).
>
> # src/virsh pool-list
> Name State Autostart
> -----------------------------------------
> libvir: Storage error : pool has no config file
> xenimages active no autostart
Opps, that error message is a bug.
> There's no pool-info binding in virsh yet, but there is a corresponding
> call at the libvirt level and thankfully the output is a struct.
Yep, I was planning to add a pool-info API to list the capacity vs
allocation of the pool & name, uuid, etc, as with dom-info. Likeiwise
for the vol-info API
>
> Create a volume:
>
> # cat /tmp/vol.xml
> <volume>
> <name>tempvol</name>
> <uuid>12345678-1234-1234-1234-123456781234</uuid>
> <capacity>100000</capacity>
> <allocation>100000</allocation>
> <format>
> <type>raw</type>
> </format>
> <permissions>
> <mode>0700</mode>
> <owner>0</owner>
> <group>0</group>
> <label>xen_image_t</label>
> </permissions>
> </volume>
>
> # src/virsh vol-create xenimages /tmp/vol.xml
> (libvirtd dumped core at this point)
The format type was not quite right <format type='raw'>. It obviously
shouldn't dump core though!
NB, <format> is actually optional - it defaults to raw. Permissions
should be optional, but currently aren't. Allocation is optional too,
without it, you will get a sparse file.
> And I still don't think that passing XML descriptions is a good idea.
>
> But because you're envisaging being able to create complex volumes like
> qcow, encrypted, etc., I will temper this by saying that we should have
> a small core XML which all drivers MUST support.
>
> For example, every driver must support pools and volumes described like
> this (verbatim, with no extra fields):
>
> <pool type="xxx">
> <name>xenimages</name>
> <!-- target should make sense for the xxx driver, eg. path for fs,
> LUN name for iSCSI, etc. There is no need for the dir=...
> attribute -->
> <target>/var/lib/xen/images</target>
> <!-- permissions should default to sensible values -->
> </pool>
Yep, I intended permissions to be optional. Not all pools have a target,
some only have a source. Basically name,and either target or source
is the minimal set. Everything else should be optional.
> and:
>
> <volume>
> <name>tempvol</name>
> <!-- I noticed that units are missing from original -->
> <capacity unit="GiB">10</capacity>
> <!-- permissions and format should default to sensible -->
> </volume>
Yes, adding units is a good idea. That looks good as a minimal dataset.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
More information about the libvir-list
mailing list