On 06/05/09 11:32, Liam Merwick wrote: > Steffen Weiberle wrote, On 05/06/2009 16:19: >> On 06/05/09 11:06, Octave Orgeron wrote: >>> Hi, >>> >>> Well the *given* names from the control domain will not carry over to >>> the device names in the guest OS, as devices are named after the >>> device name (in this case vnet and c#d#s#) and enumerated based on >>> the instance order seen in path_to_inst which is inherited from the OBP. >> >> Yes, I noticed that, and made a point to not name them vnet* in the >> control domain to highlight the change in name. >> >> >>> Typically, what I do is this: >>> >>> <guest domain name>-vnet# >>> <guest domain name>-vdsk# >>> >>> This way I keep the vnet and vdisk names in the control domain >>> readable and organized. As for the guest OS's, if the numeration is >>> important, add them in the order that will give you the 0,1,etc. >>> ordering that you'd like. >> >> So you are confirming what the customer complained about and what I >> saw. More-so, the order they are added is important. So if they want >> to maintain vdisks 0, 2, and 4 since that their current application >> configuration, they will have to keep something around to occupy 1 and >> 3, and (now I am speculating) if they make a change in the middle, >> they will have to remove all and add them again in the proper order >> (this may be their real issue). I will try this out some more--it may >> be easier with vdisks than vnets, as I could have dummy files with a >> single >> directory and file to help show changes. >> >> The customer is asking for an RFE to keep the ordering in place. >> > > What you want is 6801884 Removing a vdisk can change remaining disk > paths in guest domain > (This is fixed in the soon-to-be-released LDoms 1.2). This allows you to > explicitly specify > the instance number and prevents it being changed underneath you) > > - Liam
Hi Liam, thanks. That sounds like it. Is this an ldm improvement or does it also require firmware update? Thanks Steffen
