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 > Thanks > Steffen > >> It unfortunately does take some additional effort, but this is the >> same with physical servers where you have to place cards in the lowest >> to highest PCI/PCI-E slots per controller. Brings up fun memories of >> Serengeti servers:) >> >> >> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* >> >> >> Octave J. Orgeron >> Solaris Virtualization Architect and Consultant >> Web: http://unixconsole.blogspot.com >> E-Mail: unixconsole at yahoo.com >> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* >> >> >> >> >> >> ----- Original Message ---- >> From: Steffen Weiberle <Steffen.Weiberle at Sun.COM> >> To: ldoms-discuss at opensolaris.org >> Sent: Friday, June 5, 2009 9:45:56 AM >> Subject: [ldoms-discuss] ?: how do you handle vdisk/vnet device >> numbering changes? >> >> Since Solaris 2[.0] and SunOS 5.0 came out, one of the hardware >> characteristics of Solaris was the remembering of device numbering. If >> you put HBAs or NICs into slots a, b, and c, they were numbers 0, 1, >> and 2, or however the bus probing found them. Then, if you removed the >> device in slot b and added a different one in slot d, the last one was >> device 3, and device 1 would be missing. >> >> This has its challenges as across systems in trying to get them to >> look the same, while keeping a single system the same as hardware is >> added and removed. >> >> With LDoms, this does not happen. Lets say I add to a guest >> mynet1 at vsw-primary, mynet2 at vsw-primary, and mynet3 at vswprimary, they >> turn out to be vnet0, vnet1, and vnet2. If I drop mynet2 at vsw-primary, >> and add mynet4 at vsw-primary, the latter will end up as vnet1. >> >> This may not as critical for networks, however, I have heard the same >> happens for vdisks. >> >> How do you handle this situation? A customer is struggling with this >> and is keeping all intermediate vdisks in place even if they are >> 'empty', just to keep the vdisk ordering consistent over time. >> >> Is there a CR or RFE to make the configuration more static? >> >> Thanks >> Steffen >> _______________________________________________ >> ldoms-discuss mailing list >> ldoms-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/ldoms-discuss >> >> >> >> > > _______________________________________________ > ldoms-discuss mailing list > ldoms-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/ldoms-discuss
