On Thu, 2005-04-14 at 21:43 +0100, Ian Pratt wrote:
> > 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.
Things start getting odd if you start mixing anything that natively
shows up as scsi with a vbd scsi, though, don't they? And upstream has
been fairly resistant to other !scsi or !ide devices sitting on those
devices. I've had this argument with Jeff Garzik before about a few of
the esoteric SATA drivers that don't even pretend to be scsi. And
things like partitioning tools and hardware probing will start showing
more problems with ioctls not working as that starts to show up.
> 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.
Yeah, I can see this being useful.
Jeremy
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home