From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Lalancette Subject: Greater than 16 xvd devices for blkfront Date: Tue, 06 May 2008 13:36:05 -0400 Message-ID: <48209705.4030005@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel List-Id: xen-devel@lists.xenproject.org All, We've had a number of requests to increase the number of xvd devices that a PV guest can have. Currently, if you try to connect > 16 disks, you get an error from xend. The problem ends up being that both xend and blkfront assume that for dev_t, major/minor is 8 bits each, where in fact there are actually 10 bits for major and 22 bits for minor. Therefore, it shouldn't really be a problem giving lots of disks to guests. The problem is in backwards compatibility, and the details. What I am initially proposing to do is to leave things where they are for /dev/xvd[a-p]; that is, still put the xenstore entries in the same place, and use 8 bits for the major and 8 bits for the minor. For anything above that, we would end up putting the xenstore entry in a different place, and pushing the major into the top 10 bits (leaving the bottom 22 bits for the minor); that way old guests won't fire when the entry is added, and we will add code to newer guests blkfront so that they will fire when they see that entry. Does anyone see any problems with this setup, or have any ideas how to do it better? Thanks, Chris Lalancette