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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
