On Tue, Jan 13, 2015 at 04:12:32PM -0500, John Ferlan wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1138516 > > The disk backend uses 'parted' in order to create and delete partitions > on the disk for use in the pool. At creation time, one can specify a > specific "name" for the volume as well as a specific volume target > format type. The name and volume target type "survive" only as long > as the pool is not refreshed or the libvirtd not restarted/reloaded. > > The action immediately prior to the calling all the backend refreshPool > API's is to clear out all the existing volumes from the pool. The > theory being the refresh will be able to find all elements of the > pool using some mechanism. The disk refreshPool backend will use the > libvirt_parthelper utility to read the partitions found on the disk > in order to regenerate the elements of the pool Unfortunately, since > the "name" and target format type cannot be encoded, the data is now > lost and the defaults are used (for the "name", the partition path > is used and the default of 'none' is used for the target format type). > > This patch solves this by adding the ability to save the XML generated > at create time into the stateDir and then use that during the refreshPool > backend API call to restore the specific fields that are lost. I don't really think we should be adding a lookaside cache for this. We should simply not permit arbitrary user supplied names for disk based volumes. The names should be required to match the defined naming scheme for disk partitions. I could have sworn that we had enforced that already when I first wrote this, but perhaps that check got lost somewhere along the way. Likewise for the format - we should just rely on partition table format data Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list