2011/5/29 Richard Laager <rlaager@xxxxxxxxxx>: > I would really like to use ZFS's zvols as storage for my guests. I > really like ZFS's snapshots, send/receive, and checksumming features. > (Compression and deduplication might be useful as well.) > > I'm roughly about half-way done writing a ZFS storage backend for > libvirt. It behaves like the LVM backend. I've been writing it on Linux. > However, ZFS on Linux is not yet production-ready. Interesting :) > So I tried building libvirt on Solaris 11 Express. The following > outlines the trouble (and successes) I've had so far. I assume your building from up-to-date git here? > First, I had to prune down the features being built: > > Â Â Â ÂI added --without-xen to deal with the following. I wasn't > Â Â Â Âintending on using Xen, so this doesn't bother me personally. > Â Â Â Â Â Â Â Âconfigure: error: You must install the Xen development package to compile Xen driver with -lxenstore That's strange, configure should automatically disable the Xen driver if it can't find the required headers and libs. The only way I can see from the logic in configure is that configure found libxenstore but can't find the headers such as xen/xen.h xen/version.h xen/dom0_ops.h xen/sys/privcmd.h xen/linux/privcmd.h. You can check config.log for the results of those checks. On my Linux system it looks like this: configure:46331: checking for xs_read in -lxenstore configure:46356: gcc -std=gnu99 -o conftest -g -ggdb -O0 conftest.c -lxenstore -ldl >&5 configure:46356: $? = 0 configure:46365: result: yes configure:46387: checking for xen/xen.h configure:46387: gcc -std=gnu99 -c -g -ggdb -O0 conftest.c >&5 configure:46387: $? = 0 configure:46387: result: yes configure:46387: checking for xen/version.h configure:46387: gcc -std=gnu99 -c -g -ggdb -O0 conftest.c >&5 configure:46387: $? = 0 configure:46387: result: yes configure:46387: checking for xen/dom0_ops.h configure:46387: gcc -std=gnu99 -c -g -ggdb -O0 conftest.c >&5 configure:46387: $? = 0 configure:46387: result: yes configure:46415: checking for xen/sys/privcmd.h configure:46415: gcc -std=gnu99 -c -g -ggdb -O0 conftest.c >&5 configure:46415: $? = 0 configure:46415: result: yes configure:46477: checking sys/inotify.h usability configure:46477: gcc -std=gnu99 -c -g -ggdb -O0 conftest.c >&5 configure:46477: $? = 0 configure:46477: result: yes configure:46477: checking sys/inotify.h presence configure:46477: gcc -E conftest.c configure:46477: $? = 0 configure:46477: result: yes configure found all libs and headers. In you case it probably found libxenstore but at least one of the headers is missing, so one of the results should be "no" in your case. > Â Â Â ÂI added --without-openvz to deal with the following. Likewise, > Â Â Â ÂI'm not using it. > Â Â Â Â Â Â Â Â ÂCC Â Â libvirt_driver_openvz_la-openvz_driver.lo > Â Â Â Â Â Â Â Âopenvz/openvz_driver.c:45:19: paths.h: No such file or directory > Â Â Â Â Â Â Â ÂIn file included from ../src/conf/domain_conf.h:40, > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â from openvz/openvz_conf.h:33, > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â from openvz/openvz_driver.c:56: > Â Â Â Â Â Â Â Â../src/conf/nwfilter_conf.h:521: warning: parameter has incomplete type configure should disable the OpenVZ driver on Solaris anyway, because OpenVZ is Linux specific. Also paths.h isn't used in here anyway and could be removed. I'll post patches for this. > Â Â Â ÂI added --without-network to deal with the following. I may need > Â Â Â Âto actually fix this at some point. > Â Â Â Â Â Â Â Â ÂCC Â Â libvirt_util_la-bridge.lo > Â Â Â Â Â Â Â Âutil/bridge.c:39:20: paths.h: No such file or directory > Â Â Â Â Â Â Â Âutil/bridge.c:42:55: linux/param.h: No such file or directory > Â Â Â Â Â Â Â Âutil/bridge.c:43:55: linux/sockios.h: No such file or directory > Â Â Â Â Â Â Â Âutil/bridge.c:44:55: linux/if_bridge.h: No such file or directory > Â Â Â Â Â Â Â Âutil/bridge.c:45:55: linux/if_tun.h: No such file or directory > Â Â Â Â Â Â Â Âutil/bridge.c: In function `ifSetInterfaceMac': > Â Â Â Â Â Â Â Âutil/bridge.c:313: error: `SIOCGIFHWADDR' undeclared (first use in this function) > Â Â Â Â Â Â Â Âutil/bridge.c:313: error: (Each undeclared identifier is reported only once > Â Â Â Â Â Â Â Âutil/bridge.c:313: error: for each function it appears in.) > Â Â Â Â Â Â Â Âutil/bridge.c:316: error: structure has no member named `ifr_hwaddr' > Â Â Â Â Â Â Â Âutil/bridge.c:318: error: `SIOCSIFHWADDR' undeclared (first use in this function) > Â Â Â Â Â Â Â Âutil/bridge.c: In function `ifGetMtu': > Â Â Â Â Â Â Â Âutil/bridge.c:347: error: `SIOCGIFMTU' undeclared (first use in this function) > Â Â Â Â Â Â Â Âutil/bridge.c: In function `ifSetMtu': > Â Â Â Â Â Â Â Âutil/bridge.c:378: error: `SIOCSIFMTU' undeclared (first use in this function) > Â Â Â Â Â Â Â Âutil/bridge.c: In function `brAddTap': > Â Â Â Â Â Â Â Âutil/bridge.c:501: error: `IFF_TAP' undeclared (first use in this function) > Â Â Â Â Â Â Â Âutil/bridge.c:501: error: `IFF_NO_PI' undeclared (first use in this function) > Â Â Â Â Â Â Â Âutil/bridge.c:515: error: `TUNSETIFF' undeclared (first use in this function) > Â Â Â Â Â Â Â Âutil/bridge.c:537: error: `TUNSETPERSIST' undeclared (first use in this function) > Â Â Â Â Â Â Â Âutil/bridge.c: In function `brDeleteTap': > Â Â Â Â Â Â Â Âutil/bridge.c:567: error: `IFF_TAP' undeclared (first use in this function) > Â Â Â Â Â Â Â Âutil/bridge.c:567: error: `IFF_NO_PI' undeclared (first use in this function) > Â Â Â Â Â Â Â Âutil/bridge.c:574: error: `TUNSETIFF' undeclared (first use in this function) > Â Â Â Â Â Â Â Âutil/bridge.c:575: error: `TUNSETPERSIST' undeclared (first use in this function) > Â Â Â Â Â Â Â Âutil/bridge.c: In function `brSetInterfaceUp': > Â Â Â Â Â Â Â Âutil/bridge.c:612: error: `SIOCGIFFLAGS' undeclared (first use in this function) > Â Â Â Â Â Â Â Âutil/bridge.c:620: error: `SIOCSIFFLAGS' undeclared (first use in this function) > Â Â Â Â Â Â Â Âutil/bridge.c: In function `brGetInterfaceUp': > Â Â Â Â Â Â Â Âutil/bridge.c:652: error: `SIOCGIFFLAGS' undeclared (first use in this function) libvirt's virtual network is Linux specific but configure doesn't disable it on non-Linux systems. > Then, I had to fix a trivial code error. I've mailed the patch to this > list with a subject of "[PATCH] Fix virExecWithHook Prototype". I've applied your patch. > At this point, libvirt builds and installs. I tested virsh against a > remote system using: virsh -c qemu+ssh://REMOTE/system > > This worked except for the fact that it was trying to attach > to /usr/local/var/run/libvirt-sock on the remote system due > to /usr/local being the --prefix used with the *local* virsh was built. > I'm not sure how that architectural issue should be addressed. For > testing, I just made a /usr/local/var -> /var symlink on the remote > system. > > > However, libvirtd will not start locally (on Solaris) which has pretty > much stopped my progress. I'm sure this must be something trivial. Is it > getting a bad prefix? Is something other than libvirtd supposed to make > the socket file? I did try making a /.libvirt directory for testing. > > # rm /usr/local/var/run/libvirtd.pid ; /usr/local/sbin/libvirtd -v > 20:13:33.663: 1: info : libvirt version: 0.9.1 > 20:13:33.663: 1: error : qemudListenUnix:605 : Failed to bind socket to > '@//.libvirt/libvirt-sock': No such file or directory '@//.libvirt/libvirt-sock' should actually look like this '@/home/<username>/.libvirt/libvirt-sock' as you're running libvirtd as non-root it tries to open a UNIX socket in the home directory of the user starting it. This path is build via this pattern: @<home-directory>/.libvirt/libvirt-sock The @ is later on replace by NUL to indicate that it should go in to the UNIX abstract namespace. It seems that your home directory is set to '/'. libvirt uses getpwuid_r to get the home directory. Maybe there is a Solaris specific problem here. To work around this you can try running libvirtd as root. In that case the UNIX socket will be opened at /usr/local/var/run/libvirt/libvirt-sock in your case. Matthias -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list