I was trying to create a storage pool from /dev/mapper to have a nice interface for crypto devices (that were unlocked from the host). This did not work with any Storage Pool Type. File system directory chokes on /dev/mapper/control ("illegal seek") Physicsal Disk drive does not apply, one would need one storage pool per mapped volume Pre-formatted block device directly tries to mount a single device LVM volume group tries to vgchange -ay a volume group named mapper I didn't try iSCSI device, SCSI device or network exported directory. I think that a "device mapper" type which would handle /dev/mapper's contents would be a good idea. Its functionality would be very similiar to the type LVM volume group.
*** Bug 729138 has been marked as a duplicate of this bug. ***
virt-manager 0.9.0 exposes libvirt's mpath pool type which I believe does what you want. Can you confirm?
When I try adding an mpth storage pool with a target path of /dev/mapper, and I then click on the new pool, I get an empty volumes list. When googling for libvirt mpath, most one finds are archives of this bug and of the discussions of this issue on the libvirt mailing lists and software patches, and incomplete docs in the wiki. How is this feature supposed to be used? Greetings Marc P.S.: $ ls -al /dev/mapper/ total 0 drwxr-xr-x 2 root root 760 Aug 20 08:27 ./ drwxr-xr-x 16 root root 4.1K Aug 20 08:28 ../ lrwxrwxrwx 1 root root 8 Aug 18 22:22 agent -> ../dm-34 lrwxrwxrwx 1 root root 8 Aug 18 21:49 bigstuff -> ../dm-30 lrwxrwxrwx 1 root root 8 Aug 18 21:49 boot -> ../dm-24 crw------- 1 root root 10, 236 Aug 18 21:49 control lrwxrwxrwx 1 root root 8 Aug 18 21:49 home -> ../dm-27 lrwxrwxrwx 1 root root 8 Aug 18 21:49 root -> ../dm-22 lrwxrwxrwx 1 root root 8 Aug 18 21:49 root32 -> ../dm-31 lrwxrwxrwx 1 root root 8 Aug 18 21:49 scyw00225 -> ../dm-29 lrwxrwxrwx 1 root root 8 Aug 18 21:49 swap0 -> ../dm-23 lrwxrwxrwx 1 root root 8 Aug 18 21:49 swivel-c_agent -> ../dm-11 lrwxrwxrwx 1 root root 7 Aug 18 21:49 swivel-c_bigstuff -> ../dm-8 lrwxrwxrwx 1 root root 8 Aug 18 21:49 swivel-c_boot -> ../dm-19 lrwxrwxrwx 1 root root 7 Aug 18 21:49 swivel-c_boot32 -> ../dm-5 lrwxrwxrwx 1 root root 8 Aug 18 21:49 swivel-c_centos2 -> ../dm-14 lrwxrwxrwx 1 root root 7 Aug 18 21:49 swivel-c_home -> ../dm-6 lrwxrwxrwx 1 root root 8 Aug 18 21:49 swivel-c_music -> ../dm-21 lrwxrwxrwx 1 root root 8 Aug 18 21:49 swivel-c_nechayev -> ../dm-13 lrwxrwxrwx 1 root root 8 Aug 18 21:49 swivel-c_nechayev_old -> ../dm-12 lrwxrwxrwx 1 root root 8 Aug 18 21:49 swivel-c_root -> ../dm-17 lrwxrwxrwx 1 root root 7 Aug 18 21:49 swivel-c_root32 -> ../dm-0 lrwxrwxrwx 1 root root 8 Aug 18 21:49 swivel-c_rootkey -> ../dm-15 lrwxrwxrwx 1 root root 7 Aug 18 21:49 swivel-c_rootkey32 -> ../dm-3 lrwxrwxrwx 1 root root 7 Aug 18 21:49 swivel-c_scyw00225 -> ../dm-7 lrwxrwxrwx 1 root root 7 Aug 18 21:49 swivel-c_swap0 -> ../dm-4 lrwxrwxrwx 1 root root 8 Aug 18 21:49 swivel-c_swivelalt -> ../dm-20 lrwxrwxrwx 1 root root 8 Aug 18 21:49 swivel-c_usr -> ../dm-16 lrwxrwxrwx 1 root root 7 Aug 18 21:49 swivel-c_usr32 -> ../dm-1 lrwxrwxrwx 1 root root 8 Aug 18 21:49 swivel-c_var -> ../dm-18 lrwxrwxrwx 1 root root 7 Aug 18 21:49 swivel-c_var32 -> ../dm-2 lrwxrwxrwx 1 root root 7 Aug 18 21:49 swivel-c_vm -> ../dm-9 lrwxrwxrwx 1 root root 8 Aug 18 21:49 swivel-video -> ../dm-10 lrwxrwxrwx 1 root root 8 Aug 18 21:49 usr -> ../dm-25 lrwxrwxrwx 1 root root 8 Aug 18 21:49 usr32 -> ../dm-32 lrwxrwxrwx 1 root root 8 Aug 18 21:49 var -> ../dm-26 lrwxrwxrwx 1 root root 8 Aug 18 21:49 var32 -> ../dm-33 lrwxrwxrwx 1 root root 8 Aug 18 21:49 vm -> ../dm-28
I have worked around by creating a directory /dev/luksdev and creating symlinks to the appropriate /dev/dm-xx devices there. That directory can then successfully be used as a file system directory pool. This needs manual work after each reboot thought, so it's only a quickfix until a solution has been found.
Hmm, I don't know much about dm but maybe libvirt mpath pool should just handle this. Reassigning to libvirt. Dave, any input?
The multipath pool is really just intended to provide a simple way to get at all the multipath devices available on a host, as my experience is that there is a set of users who only care about multipath devices to back their VMs. It's really just syntactic sugar. I have a couple of ideas for making /dev/mapper work as a directory pool. The easiest is probably to automate what you've done: set up udev rules that create the links for you in /dev/luksdev which wouldn't require any code changes to libvirt. The other possibility, though, if you're able to do a small amount of coding, is to make the directory pool not choke on /dev/mapper/control (or other files it fails to probe). That should be a relatively straightforward patch to src/storage/storage_backend_fs.c
This bug is *really* critical to usability for some people, any chance that it could be addressed at some point in the near future? The crux of the problem is that a DM target (say /dev/mapper) can't be used as a browsable data source by applications like virt-manager. For anyone providing custom DM targets (I've heard dm-crypt mentioned) - which is what I'm doing, users would need to know the exact path and type it all in by hand! This is the fix that I apply to systems here to circumvent the issue, although I'm guessing the original author could provide something a little more comprehensive - this does seem to do the job. src/util/virstoragefile.c lines 706-708; if (lseek(fd, 0, SEEK_SET) == (off_t)-1) { // -- virReportSystemError(errno, _("cannot seek to start of '%s'"), path); // -- goto cleanup; goto done; } Essentially libvirt does not recognise any folder with a character special file in it - which surely must be a bug ?! I guess in this specific instance we could test specifically for seek failures on char special files, but on the whole the filter just seems way too fussy. Just ignoring files that can't be lseek'd would see more logical ??
(In reply to Gareth Bult from comment #7) > This bug is *really* critical to usability for some people, any chance that > it could be addressed at some point in the near future? > > The crux of the problem is that a DM target (say /dev/mapper) can't be used > as a browsable data source by applications like virt-manager. For anyone > providing custom DM targets (I've heard dm-crypt mentioned) - which is what > I'm doing, users would need to know the exact path and type it all in by > hand! > > This is the fix that I apply to systems here to circumvent the issue, > although I'm guessing the original author could provide something a little > more comprehensive - this does seem to do the job. > > src/util/virstoragefile.c lines 706-708; > > if (lseek(fd, 0, SEEK_SET) == (off_t)-1) { > // -- virReportSystemError(errno, _("cannot seek to start of '%s'"), > path); > // -- goto cleanup; > goto done; > } > > Essentially libvirt does not recognise any folder with a character special > file in it - which surely must be a bug ?! I guess in this specific instance > we could test specifically for seek failures on char special files, but on > the whole the filter just seems way too fussy. Just ignoring files that > can't be lseek'd would see more logical ?? CCing some libvirt devs who have done work in the storage driver recently.
Tvm. It's something that's been irking me (and others) for years, but now I'm working with systems that exclusively use the DM to provide VM storage, it's a serious blocker when it comes to exposing 'users' to VM GUi's. <code nazi> ps - I would be very happy if someone could remove the "goto" from my fix ... </code nazi>
I have proposed a patch upstream: https://www.redhat.com/archives/libvir-list/2014-March/msg01289.html
Fixed upstream by commit 0edfc9ef63b338bbcb8eb4b98653589c3889726e Author: Ján Tomko <jtomko> CommitDate: 2014-03-20 18:13:57 +0100 Ignore char devices in storage pools by default Without this, using /dev/mapper as a directory pool fails in virStorageBackendUpdateVolTargetInfoFD: cannot seek to end of file '/dev/mapper/control': Illegal seek Skip over character devices by default. https://bugzilla.redhat.com/show_bug.cgi?id=710866 git describe: v1.2.2-280-g0edfc9e