On Tue, Aug 21, 2012 at 10:32:51AM +0100, Daniel P. Berrange wrote: > On Mon, Aug 20, 2012 at 10:07:43PM +0100, Richard W.M. Jones wrote: > > In the first case (using "/dev/sdX" names), some magic already happens > > translating these to the real names underneath, but currently that > > magic is just "/dev/sdX" -> "/dev/vdX" for the virtio case. > > Ah I didn't realize that you already do device name remapping > between what the kernel shows & what the API shows. I maybe wasn't completely clear. We only (currently) do the mapping for parameters. Return values contain the kernel device names. So we don't rewrite the output of guestfs_list_devices, we just suppress the device corresponding to the appliance root filesystem. This both is and isn't a problem at the moment. If you treat the returned strings as opaque blobs, you can pass them back to API functions. However if you want to print them it's a different matter, and lots of tools try to canonicalize the names before printing them, eg: consider the following code in an old version of virt-filesystems: https://github.com/libguestfs/libguestfs/blob/16fdcb4baabcd96dcc16acf1ec7eae34f7304cce/cat/virt-filesystems.c#L707 In fact this canonicalization code was used so widely, I added it to the API in later versions: https://github.com/libguestfs/libguestfs/blob/99759da25c29a7376490074da3d2c22602a2acec/cat/virt-filesystems.c#L642 https://github.com/libguestfs/libguestfs/blob/faf548a4bdd36b476ee6838bfc7d0c134435a331/src/guestfs.c#L1084 For parameters, the mapping process is documented here: http://libguestfs.org/guestfs.3.html#algorithm-for-block-device-name-translation The main reason for mapping parameters is so you can write guestfish scripts which are portable across many versions of libguestfs, eg: guestfish -a foo.img -m /dev/sda1 will just work. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list