Re: [Libvir] Repository for work-in-progress storage patches
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 -=|