From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Stodden Subject: Re: xm/xl block-detach issue Date: Sun, 10 Jul 2011 11:19:34 -0700 Message-ID: <1310321977.2685.370.camel@ramone> References: <4E186702.6050601@swisscenter.com> <4E188FC3.1010009@swisscenter.com> <1310288759.2685.356.camel@ramone> <4E19961F.9070109@swisscenter.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <4E19961F.9070109@swisscenter.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: =?ISO-8859-1?Q?S=E9bastien?= Riccio Cc: "dmeyer@cs.ubc.ca" , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Sun, 2011-07-10 at 08:07 -0400, S=C3=A9bastien Riccio wrote: > On 10.07.2011 11:05, Daniel Stodden wrote: > > To just-get-me-that partition: Plug into dom0, so you'll get xvda1-n. > > Oh wait, that was what didn't work either in the original mail.. :-) > > > > Daniel > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > >=20 > Hi Daniel, >=20 > Thanks a lot for your answers :) Well yes my original problem is to be=20 > able to > attach and detach a vhd file as a block device in the dom0, so I can=20 > provision it. >=20 > Attaching it to dom0 with block-attach works well, can access, partitio= n=20 > it, format > partitions, mount partitions, copy files... but then I can't detach it=20 > and I'm stuck :) Okay, that needs to get fixed, but I don't know where. In XCP that's how it's exclusively done, because it's the most general approach. > That's why I tried other ways to do it and got then stuck again on the=20 > "can't access > a partition" problem with the tap-ctl method. > > So talking about tap-ctl, yes IMHO it would be interesting to be able t= o=20 > access them > for such operations. Partitions normally work by adding some stride between the 'part0' (the entire disk) nodes allocated. E.g. scsi disks would allocate every 16th minor for a new disk, and the space in between is partitions. brw-rw---- 1 root disk 8, 0 Jul 7 09:47 /dev/sda brw-rw---- 1 root disk 8, 1 Jul 7 09:47 /dev/sda1 brw-rw---- 1 root disk 8, 2 Jul 7 09:47 /dev/sda2 We don't have that, so partitions are off. # l /dev/td* brw-rw---- 1 root disk 254, 0 Jul 10 10:58 /dev/tda brw-rw---- 1 root disk 254, 1 Jul 10 11:18 /dev/tdb Problem is I'm not sure if just doing so wouldn't break sth, because we work so much with minor numbers in the toolstack. kpartx should work, I don't think that is tapdisk-related. After all it doesn't really do any magic. It reads the partition table from the start of the device and maybe lands a couple standard ioctls to query disk size etc. The rest is DM. Can you check if it works with some normal disk? Check out modules, install lvm2, make sure you have dm-linear loaded, etc... You were running a custom kernel, right? You're probably just missing sth. Daniel