[libvirt] [PATCH 6/6] storage:dir: adapts .refreshVol .refreshPool for ploop volumes

Ján Tomko jtomko at redhat.com
Mon Feb 22 13:47:37 UTC 2016

On Thu, Feb 18, 2016 at 07:39:37PM +0300, Olga Krishtal wrote:
> On 18/02/16 18:17, Ján Tomko wrote:
> > On Thu, Feb 18, 2016 at 05:04:16PM +0300, Maxim Nestratov wrote:
> >> 18.02.2016 16:46, Ján Tomko пишет:
> >>> On Wed, Feb 17, 2016 at 02:40:05PM +0300, Olga Krishtal wrote:
> >>>> To update information about ploop volumes inside the a single pool we need
> >>>> to be sure that it is the ploop directory and not some other directory.
> >>>> Ploop volume directory obligatory contains root.hds - image file and disk
> >>>> descriptor - DiskDescriptor.xml. If path to a volume is a path to some
> >>>> directory, we check the existance of this files.
> >>>>
> >>> With each ploop volume being a directory with a ploop disk image and the
> >>> XML, I think they deserve a separate pool type.
> > On second thought, the pool is still just a directory, it's the volumes
> > that are different, so it does belong in the directory-based pools.
> The main idea of ploop is to have an image file, use it as a block device,
> and create and use a file system on that device. It is looks like loop 
> device.
> However, we do need DiskDescriptor.xml store at the same directory
> that root.hds (file, that contains ploop).

What will happen if the root.hds file will be placed directly in the
pool directory, with no DiskDescriptor.xml? It seems this code would
detect it as a ploop image.

> >
> > That leaves the mixing of the ploop volumes with the ploop disk images,
> > don't we need a new STORAGE_VOL type?
> At the beginning I also had thoughts about it, but:
> 1) New STORAGE_VOL type will be exclusively for us. No one else will use it.
> So, we have volume time only for one format.

Well this is the only format that has its headers stored externally.

> 2) We can avoid such situation, because our ploop format looks a bit 
> like qcow format.
> (Of course they have have different internal structure, but still, the 
> only difference in such case -
> DiskDescriptor.xml, that can not be stored in the same file)
> 3) And we are able to work with STORAGE_VOL_FILE, because we are a file 
> upon loop device.

Isn't creating this loop device outside of libvirt's control? All it
sees is a directory with two files in it.


More information about the libvir-list mailing list