Re: [PATCH 5/6] libxl: introduce libxl__alloc_vdev

[Stefano Stabellini <stefano.stabellini@eu.citrix.com>]

On Fri, 30 Mar 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [PATCH 5/6] libxl: introduce libxl__alloc_vdev"):
> > On Tue, 27 Mar 2012, Ian Jackson wrote:
> > > Furthermore, for the purpose for which you're using this, you should
> > > not start at zero (xvda).  You should start at at least 26 (xvdA) and
> > > possibly later.  That way you are less likely to clash with other
> > > statically-allocated vbds.
> >  
> > Another interesting observation but I disagree: why should we expect
> > "statically-allocated vbds" below xvdA? How many do you think we are
> > going to find? Why 26? I think it is very arbitrary.
> > We should just make sure that our allocation policy works well and start
> > from 0.
> 
> Your design assumes that the system administrator has not configured,
> for themselves, any disks to be exposed to dom0 (eg by a driver
> domain).  If they have (eg, run "xl block-attach 0 vdev=xvda ...")
> then they will expect it to work, and they will expect to be able to
> control the device name that this appears as in dom0.  Therefore the
> namespace of xvd* names in dom0 is not freely available to us as libxl
> programmers; we need to avoid trampling all over it.
> 
> Since we need to be able to allocate some vbds dynamically, the right
> approach is to decree that some portion of the dom0 vbd space is
> reserved for static allocations by the administrator, and that the
> remainder is for dynamic allocations by software which picks a free
> vbd.  Naturally the static space should come first.

When you hotplug a new disk on your system, for example a new USB disk
to your native Linux box, usually Linux chooses the device name for
you. I don't see why this should be any different.
The admin is going to call instead:

xl block-attach 0

and then checkout dmesg.


> > > Of course you can't then using the resulting vdev as a pathname in
> > > /dev/ but that's nonportable anyway; different guest OSs (and here we
> > > are playing the role of the guest) may have different conventions.
> > > You need a separate function to convert vdev numbers (as returned from
> > > _disk_dev_number) to pathnames in /dev.
> > 
> > This is a good point and the key issue here.
> > 
> > The frontend is actually free to choose whatever name it wants for the
> > device it is going to create from the dev number.
> 
> I don't think that is true.  On each individual guest platform, the
> relationship between vbd numbers (the actual interface between
> frontend and backend), and whatever that guest has for device names,
> needs to be statically defined.

I disagree: when we introduced docs/txt/misc/vbd-interface.txt we never
specified what names the guest kernel is allowed to choose for a
particular vbd encoding. See the following quote:

"The Xen interface does not specify what name a device should have in the
guest (nor what major/minor device number it should have in the guest,
if the guest has such a concept)."


> > So I think that the best thing we can do is rely on it to find out the
> > device name, either doing:
> > 
> > [1] xvd(a + i) -> libxl__device_disk_dev_number -> xs_read
> 
> This is not correct, because the device name in the guest is not
> written to xenstore anywhere.  It is private to the guest.
> 
> (In this case the "guest" is actually dom0, but the point stands.)
> 
> > or reading the "dev" node under the xenstore backend path, that is
> > generated using the same libxl function (this is what I am doing now).
> > I fail to see why one of these two approaches would be better than the
> > other, but if you think that [1] is the best, I can change my code.
> 
> Again, you are confusing the virtual name given in the domain config
> file with the actual device name in the guest's /dev, which may not be
> the same.

What I find confusing is that before you say that "the relationship
between vbd numbers and whatever that guest has for device names needs
to be statically defined", but then you say that "the device name in the
guest is not written to xenstore anywhere.  It is private to the guest."


In any case that was a conscious decision: considering that we have no
way to know the device name in the guest (see above quote), the best
thing we can do is guessing.  The best guess we can have is using the
mapping implemented in libxl__device_disk_dev_number.

Maybe we can slightly improve the situation moving libxl__alloc_vdev to
an OS specific file so that we can have a Linux and a BSD implementation.
Both are going to be "guessing", in particular the Linux version is just
going to use libxl__device_disk_dev_number, but the BSD version might
want to do something different.