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