From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kip Macy Subject: Re: [PATCH] Guest boot loader support [1/2] Date: Thu, 14 Apr 2005 13:09:01 -0700 Message-ID: References: <20050414182213.GE1350@vienna.egenera.com> <200504142011.18919.mark.williamson@cl.cam.ac.uk> <20050414194316.GG1350@vienna.egenera.com> Reply-To: Kip Macy Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20050414194316.GG1350@vienna.egenera.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Philip R Auld Cc: Mike Wray , Ian Pratt , xen-devel@lists.xensource.com, Mark Williamson List-Id: xen-devel@lists.xenproject.org > > You could work round this currently using the block config scripts. I.= e. > > similar to the file: syntax now, you could easily hack up nbd:, iscsi:,= etc. > > Then network block devices can be connected up at create / migrate / re= store > > time, without relying on a particular device node. >=20 > Thanks. I'm not really looking for a work around though :) I think > this is an issue that we should look at in more depth. >=20 I don't think this is necessarily a "workaround". On filers (and presumably everyone else's boxes) iSCSI and FCP LUNs have full path names. The device number is purely a function of the local machine. Adding some logic to xend so that it thinks in terms of LUNs instead of device nodes would be highly useful to some of us. > My concern is for SAN attached devices primarily. These will > show up as scsi devices with /dev/sdXX names (barring custom > udev configs). >=20 > I suppose though that if xen doesn't care about the actual names. Then > making a link in /dev/ could work. Maybe this is not really an issue afte= r > all. e.g. /dev/my_domU_1_disk -> /dev/sdb. Then as long as something > on the other end can tell where the disk showed up it can make the > appropriate link -- /dev/my_domU_1_disk -> /dev/sdq. I have a script that takes as an argument the number of LUNs, the size of the LUNs, and the name of the VM. These LUNs are all mapped in a probe and creation dependent order. I have a script that iterates through all the scsi generic devices (passthrough), sends them an inquiry - if they're LUNs it sends the device a vendor specific mode page to get the full pathname. The pathname contains the VM the LUN belongs to allowing the script to create a device node corresponding to the sd device in /dev/vm/. I've added the following snippet for mapping the LUNs in at VM creation time: globstr =3D "/dev/vm/%s/*"%name disknamelist =3D glob.glob(globstr) count =3D 1 for diskname in disknamelist: disk.append('phy:%s,loop%s,w'%(diskname,count)) count +=3D 1 I'm not entirely thrilled with SAN management in this model. If I delete LUNs on the server all the mappings get shifted down due to the 1-dimensional nature of the device node namespace. >=20 > What is a physical device number in this context? The name it > ends up with is often detection order dependent. /dev/sdb has little > relation to physical device numbers. Also, with the better support > for hotplug in 2.6 devices can come and go. Yep. There are some open issues here. major / minor numbers that are a function of probe order are clumsy at best. -Kip