[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.

Jan




More information about the libvir-list mailing list