WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] Guest boot loader support [1/2]

Hi Mark,

Rumor has it that on Thu, Apr 14, 2005 at 08:11:18PM +0100 Mark Williamson said:
> > As a slight but related digression, has any thought been given to
> > using something other than /dev/[hs]d* names for specifying block
> > devices? The name /dev/sdb only has meaning for the current
> > state of the running dom0 OS. It may not mean the same device
> > on a different dom0. This can lead to problems in say migration.
> > In fact, it may not be the same when the domain is restored locally.
> 
> 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 / restore 
> time, without relying on a particular device node.

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. 

My concern is for SAN attached devices primarily.  These will
show up as scsi devices with /dev/sdXX names (barring custom 
udev configs). 

BTW, how would you do this with iSCSI? iSCSI target LUNs show 
up as scsi devices and get block device names. It'll have the same
issues as FC SAN. 

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 after 
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.
 
> 
> This can be done by writing a shell script to bind the device to a node and 
> adding a config parameter to Xend.
> 
> I'd imagine we can rely on actual physical device numbers generally staying 
> the same but this could be fixed by a similar mechanism.
> 

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. 

Cheers,
Phil

> Cheers,
> Mark
> 
> > Having to configure all the possible migration targets to see all
> > the same devices in the same order at all times is not realistic.
> > In a dynamic environment it would be ideal to make a device visible
> > to the target dom0 only as it was needed to migrate a given VM to
> > that dom0. Naming it /dev/sdb may not be a possiblity in this case.
> >
> >
> > Cheers,
> >
> > Phil
> >
> > > Cheers,
> > > Ian
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > > http://lists.xensource.com/xen-devel

-- 
Philip R. Auld, Ph.D.                          Egenera, Inc.    
Software Architect                            165 Forest St.
(508) 858-2628                            Marlboro, MA 01752

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel