Thank you very much. Yes, I understand now. I look to the source code (as far as I can), they are looked for me like a pirmary key for database.
Can I assume that opaqueRef is consistent between xapi restart, master change, pool upgrade and so on? In other words, can I use OpaqueRef as full replacement for uuids? Thanks again. PS Can I post this reply to Xen wiki? I think it will be very userfull for XenAPI users. --- wBR, George. В Птн, 01/04/2011 в 18:31 +0100, Dave Scott пишет: > Hi George, > > Sorry for the delay replying to your message. > > > I am using XenAPI for a long time. We have found some performance > > issues > > with XenAPI: the conversion from OpaqueRef to UUID. Each OpaqueRef > > should be resolved manually, and this almost doubles request amount. > > > > I got used to them, but I still do not understand why they was > > introduced in XenAPI. > > > > Could someone describe me the reason behind OpaqueRefs? Why they are > > only valid within a single session? Why they are added in the fist > > place? > > Here's a brief history of what happened: > > First we wanted to create an API for managing VMs, VIFs, VBDs etc. We thought > we would have VMs etc being objects and "references" would be the primary way > to name them. We wanted to reserve the right to change what a reference looks > like, so that we could maybe encode some (eg) security-related information > (like a capability) or some scope-related information (eg if you had nested > pools) in the future. To discourage people from looking at the actual strings > too much, we put the prefix "OpaqueRef" on as a warning :) > > So far, everything is relatively clean. > > Since xen domains have uuids, we added a VM.uuid field. I think we also added > a VDI.uuid field at this point -- with hindsight this was a mistake. We > believed that each storage type could use a uuid to identify a disk but it > turned out that some storage types had nowhere convenient to actually store > the information so it could be retrieved efficiently. We added a VDI.location > field to contain the most appropriate primary key to identify a VDI within an > SR and the VDI.uuid field became a bit vestigial. > > So far, everything is still ok. > > We then started developing the "xe" cli. At this point we made the crucial > decision that OpaqueRef: strings were just too visually ugly to use in a > commandline interface and decided to name objects by uuid. This was fine for > VMs and VDIs but nothing else had a uuid field. Inevitably we then added > uuids to other objects so now they're almost ubiquitous. > > Now we have two parallel object naming mechanisms which is a bit strange. My > current rule of thumb is that: whenever I'm using the XenAPI directly (eg in > python) I will use refs exclusively (no uuids). When I write scripts that use > the "xe" CLI I will use uuids exclusively (no refs). > > Does that make sense (even if it is a little bit unfortunate!)? > > Cheers, > Dave _______________________________________________ xen-api mailing list [email protected] http://lists.xensource.com/mailman/listinfo/xen-api
