Bug 977582 - Make file extensions an internal detail of volume API
Make file extensions an internal detail of volume API
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Libvirt Maintainers
Depends On:
  Show dependency treegraph
Reported: 2013-06-24 20:16 EDT by Zeeshan Ali
Modified: 2016-09-19 21:43 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-04-09 19:45:44 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Zeeshan Ali 2013-06-24 20:16:58 EDT
The libvirt API provides a nice volume manipulation API and it more or less abstracts the app developer from underlying files. However, apps currently need to have an extension as part of the volume's name as libvirt maps volume's name directly to the name of the underlying file.

Since the format of the volume is known to libvirt, it can automatically assign the proper extension to the underlying file at the time of volume creation and free the app developer from worrying about file extensions.
Comment 1 Cole Robinson 2016-04-09 19:45:44 EDT
For directory/fs volumes the convention has always been that volname==filename, so I'm not sure how we could deviate from that in this case. Maybe we could add an XML option for volume creation that says 'use the format as the file extension' but honestly I don't think it saves API users all that much work

Note You need to log in before you can comment on or make changes to this bug.