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: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1

To: "Jeremy Katz" <katzj@xxxxxxxxxx>, "Philip R Auld" <pauld@xxxxxxxxxxx>
Subject: RE: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2])
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Thu, 14 Apr 2005 21:43:40 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 14 Apr 2005 20:43:30 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcVBMWB5rXHea0GMREuWhVqKOEP5pQAAMdiQ
Thread-topic: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2])
> On Thu, 2005-04-14 at 14:22 -0400, Philip R Auld wrote:
> > 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.
> 
> To be even slightly more radical, I don't think that for the 
> guests, the vbds should be being exposed as SCSI or IDE since 
> they're not.  By being presented as such, there's a set of 
> assumptions about ioctls and behaviors which aren't the case 
> for disks on blkfront.  Even with all of the pain using your 
> own major/minor for a disk device is, I think it probably is 
> the right thing to do.  And I've added the code to 
> parted/lvm2/.../etc enough to be able to do it in my sleep 
> this point if this route is taken :)

I don't think there's a huge problem with exposing vbd's as sdX/hdX
within a guest. We used to have our own xdX device, but it just broke
too much stuff, hence we hijacked had/sda. I haven't seen too many
problems with ioctls.

I think the key issue is that in domain configs, you want to specify the
source of the vbd in some high-level name and have the control tools do
the necessary to map it to a local device and then export it. This
already happens with file: disk paths. We just need something similar
for iscsi.

Ian

 

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