On Sun, Jan 20, 2008 at 12:20:03PM +0000, Richard W.M. Jones wrote: > Daniel P. Berrange wrote: > >On Sat, Jan 19, 2008 at 01:47:30PM +0000, Richard W.M. Jones wrote: > >>This function confuses me a bit. It takes a virStoragePoolPtr as > >>parameter, but it only uses pool->conn. The other two > >>virStorageVolLookupBy* functions take a virConnectPtr directly. > > > >There are 3 levels of unique identifiers in storage volumes > > > > - name - unique within the scope of a Pool > > - key - unique across any machine accessing the same pool > > - path - unique within scope of a host (optionally across any host, > > if the pool impl supports that). > > > >So, since name is unique within scope of a volume, while the others > >are unique within scope of a host, the virStorageVolLookupByName > >method is different, taking a virStoragePoolPtr instead of a > >virConnectPtr. > > A few examples would go a long way to helping me understand this. Can > you give examples of name/key/path in the context of > iscsi/partition/directory? The key stuff is not really implemented yet, but the examples of how it would look are: * iscsi: There are a choice of paths - if no /dev/disk/by-* is specified then it falls back to non-stable /dev/sd* name: '0:2:0:1' path: /dev/disk/by-path/ip-192.168.122.170:3260-iscsi-demo-tgt-a-lun-3 /dev/disk/by-id/.... (can't remember format of this offhand) /dev/sdc key: ip-192.168.122.170:3260-iscsi-demo-tgt-a-lun-3 * disk: Again a choice of paths name: part1 path: /dev/sda1 /dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0-part1 /dev/disk/by-id/scsi-SATA_HTS721010G9SA00_MPCZ12Y0GNGWSE-part1 key: TBD (will extract unique key from sysfs metadata) * directory: name: demo.img path: /var/lib/xen/images/demo.img key: combo of unique key of underlying block dev + inode The directory part of the 'path' in all these examples is determined by the value of the <target>/some/dir/</target> parameter in the pool definition. For block devices we really need to stay away from /dev/sd* nodes whenever possible since they are effectively randomly allocated at boot time, no not really stable. So when defining a pool that uses block devices the recommendation will be to specify a <target> element pointing to /dev/disk/by-id or /dev/disk/by-uuid which is where predictable stable paths live. These stable paths are created by udev rules. It is apparently fairly common for people to create their own additional udev rules to provide custom naming schemes, so allowing it to be specified with <target></target> in the pool is quite handy. Btw, patch 'storage-examples' sticks some example XML inputs into the docs/storage directory. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list