|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] Re: Question on "xen-blkfront: handle Xen major numbers
On Wed, 2011-07-13 at 11:47 +0100, Stefano Stabellini wrote:
> On Wed, 13 Jul 2011, Stefan Bader wrote:
> > This is /me trying to understand the background of
> >
> > commit c80a420995e721099906607b07c09a24543b31d9
> > Author: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> > Date: Thu Dec 2 17:55:00 2010 +0000
> >
> > xen-blkfront: handle Xen major numbers other than XENVBD
> >
> > My guess would be that it has its reason from running HVM guests. The issue
> > I in
> > some way hear in complaints is, that running as PVM guest (at least) people
> > seem
> > to have used for example "sda1" in the instance configuration and then
> > relied on
> > the device being called that way within the instance. Now it is suddenly
> > called
> > "xvde1".
> > This is maybe a broken assumption in the first place, and not that hard to
> > cope
> > with (its just surprising and maybe breaks some automation). I mainly want
> > to
> > understand the reasoning, so I can explain it where I get asked.
>
> The rationale behind this is that it wouldn't be correct for
> xen-blkfront to "steal" the major number of the scsi, sata or ide
> subsystems.
It should be pointed out that the out of mainline "classic" PV Xen
patches do exactly that (although I at least have been discouraging the
use of this configuration for many years now). But it's not something we
felt would fly with upstream.
Ian.
> Of course if a LABEL or UUID is specified everything should work as
> expected without any changes.
> We do print a warning at boot time to make sure users know of the naming
> change:
>
> printk(KERN_INFO "Blkfront and the Xen platform PCI driver have
> "
> "been compiled for this kernel: unplug
> emulated disks.\n"
> "You might have to change the root
> device\n"
> "from /dev/hd[a-d] to /dev/xvd[a-d]\n"
> "in your root= kernel command line
> option\n");
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Xen-devel] Question on "xen-blkfront: handle Xen major numbers other than XENVBD", Stefan Bader
- [Xen-devel] Re: Question on "xen-blkfront: handle Xen major numbers other than XENVBD", Stefano Stabellini
- Re: [Xen-devel] Re: Question on "xen-blkfront: handle Xen major numbers other than XENVBD",
Ian Campbell <=
- Re: [Xen-devel] Re: Question on "xen-blkfront: handle Xen major numbers other than XENVBD", Stefan Bader
- Re: [Xen-devel] Re: Question on "xen-blkfront: handle Xen major numbers other than XENVBD", Stefano Stabellini
- Re: [Xen-devel] Re: Question on "xen-blkfront: handle Xen major numbers other than XENVBD", Stefan Bader
- Re: [Xen-devel] Re: Question on "xen-blkfront: handle Xen major numbers other than XENVBD", Stefano Stabellini
- Re: [Xen-devel] Re: Question on "xen-blkfront: handle Xen major numbers other than XENVBD", Stefan Bader
- Re: [Xen-devel] Re: Question on "xen-blkfront: handle Xen major numbers other than XENVBD", Stefano Stabellini
- Re: [Xen-devel] Re: Question on "xen-blkfront: handle Xen major numbers other than XENVBD", John Haxby
- Re: [Xen-devel] Re: Question on "xen-blkfront: handle Xen major numbers other than XENVBD", Stefan Bader
- [Xen-devel] [PATCH 1/3] xen-blkfront: Drop name and minor adjustments for emulated scsi devices, Stefan Bader
- [Xen-devel] Re: [PATCH 1/3] xen-blkfront: Drop name and minor adjustments for emulated scsi devices, Stefano Stabellini
|
|
|
|
|