MORITA Kazutaka <morita.kazutaka at lab.ntt.co.jp> writes: > At Wed, 3 Aug 2011 13:50:32 +0100, > Chris Webb wrote: > > > > MORITA Kazutaka <morita.kazutaka at lab.ntt.co.jp> writes: > > > > > Sheepdog also uses a hash value of the vdi name to look up vdi > > > objects, so it is already difficult to implement vdi rename simply, > > > but I think it is not impossible. For example, if we log all the vdi > > > rename operations, we can traverse the renamed vdi name and get the > > > correct hash value based on the old vdi name. > > > > Or perhaps make the vdi 'name' an internal uniquely allocated 'id' value and > > the displayed name be an attribute of the vdi? (This is what I'm already > > doing with sheepdog in our system, as I want to be able to guarantee unique > > 'names'.) > > Let me clarify some points. > > In this approach, when we rename a vdi, we specify the vdi 'id' and > change the attribute of the vdi, yes? > > What is specified in the qemu command line option as a Sheepdog volume > name? Is it vdi 'name' (an attribute of the vdi) or vdi 'id' (the 32 > bit integer)? I was imagining that the vdi was internally addressed by its 'id' and the name was just an attribute for user convenience, a bit like we fundamentally identify snapshots by their vid but might one day give them a convenience tag name as qcow2 snapshots have. I'm already using the vdi 'name' in this way inside our management system, allocating a unique value to it rather than setting it to the user-provided drive name. Cheers, Chris. |