Re: Why does so much virt stuff depend on glusterfs?
On Wed, Jul 24, 2013 at 01:39:14PM -0400, Cole Robinson wrote: On 07/24/2013 01:36 PM, Cole Robinson wrote: On 07/24/2013 05:18 AM, Daniel P. Berrange wrote: On Tue, Jul 23, 2013 at 11:28:20AM -0700, Adam Williamson wrote: On Tue, 2013-07-23 at 18:15 +0100, Richard W.M. Jones wrote: On Tue, Jul 23, 2013 at 12:57:50PM -0400, Dave Jones wrote: On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote: So this thread is complaining about.. Removing: glusterfs x86_64 3.4.0-2.fc19 @updates-testing 4.7 M Removing for dependencies: glusterfs-api x86_64 3.4.0-2.fc19 @updates-testing 88 k glusterfs-fuse x86_64 3.4.0-2.fc19 @updates-testing 233 k 5M of deps, meanwhile.. qemu-system-alpha x86_64 2:1.4.2-4.fc19 @updates-testing 4.1 M qemu-system-arm x86_64 2:1.4.2-4.fc19 @updates-testing 5.2 M qemu-system-crisx86_64 2:1.4.2-4.fc19 @updates-testing 2.8 M qemu-system-lm32x86_64 2:1.4.2-4.fc19 @updates-testing 2.8 M qemu-system-m68kx86_64 2:1.4.2-4.fc19 @updates-testing 3.8 M qemu-system-microblaze x86_64 2:1.4.2-4.fc19 @updates-testing 5.6 M qemu-system-mipsx86_64 2:1.4.2-4.fc19 @updates-testing 21 M qemu-system-or32x86_64 2:1.4.2-4.fc19 @updates-testing 2.7 M qemu-system-ppc x86_64 2:1.4.2-4.fc19 @updates-testing 18 M qemu-system-s390x x86_64 2:1.4.2-4.fc19 @updates-testing 3.1 M qemu-system-sh4 x86_64 2:1.4.2-4.fc19 @updates-testing 7.5 M qemu-system-sparc x86_64 2:1.4.2-4.fc19 @updates-testing 7.3 M qemu-system-unicore32 x86_64 2:1.4.2-4.fc19 @updates-testing 2.7 M qemu-system-xtensa x86_64 2:1.4.2-4.fc19 @updates-testing 5.6 M Do we really *need* all those ? Hopefully those *are* removable. Unfortunately some packages depend on the 'qemu' meta package which pulls in all of the emulators. I don't know if that's the case for me, I just did a 'yum install @Virtualization' on the host in question which is why I have all the stuff the metapackages pull in. I know about that, which is why I didn't complain about it. Hmm, if @Virtualization pulls in all the QEMU emulators then we probably have a bogus comps config. I'd say @Virtualization should probably only pull in the KVM binary, leaving the QEMU emulators alone, since few people will want them. Yeah comps still has a dep on plain 'libvirt' which will pull all of that in. If no one objects, I'll push a change to make it libvirt-daemon-driver-kvm which should only pull in the required libvirt bits. Err, s/libvirt-daemon-driver-kvm/libvirt-daemon-kvm/ Yes, that sounds like a good idea. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Wed, Jul 24, 2013 at 02:02:42PM -0400, Bill Nottingham wrote: Daniel P. Berrange (berra...@redhat.com) said: But the qemu-kvm binary can still run in TCG mode - you don't need to install the QEMU emulators too. So your dep could be %ifarch %{ix86} x86_64 Requires: libvirt-daemon-kvm = 0.10.2-3 %else Requires: libvirt-daemon-qemu = 0.10.2-3 %endif thus avoiding install of QEMU emulators unless they're the only option available. libvirt-sandbox-libs also brings in libvirt-daemon-qemu - that seems strange at first glance. Yes, that needs fixing in the same way as above too really Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Thu, Jul 25, 2013 at 09:55:14AM +0100, Daniel P. Berrange wrote: On Wed, Jul 24, 2013 at 02:02:42PM -0400, Bill Nottingham wrote: Daniel P. Berrange (berra...@redhat.com) said: But the qemu-kvm binary can still run in TCG mode - you don't need to install the QEMU emulators too. So your dep could be %ifarch %{ix86} x86_64 Requires: libvirt-daemon-kvm = 0.10.2-3 %else Requires: libvirt-daemon-qemu = 0.10.2-3 %endif thus avoiding install of QEMU emulators unless they're the only option available. libvirt-sandbox-libs also brings in libvirt-daemon-qemu - that seems strange at first glance. Yes, that needs fixing in the same way as above too really I have changed the libguestfs dependency now. 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://people.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On 07/23/2013 10:27 PM, Dave Jones wrote: On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote: So this thread is complaining about.. Removing: glusterfs x86_64 3.4.0-2.fc19 @updates-testing 4.7 M Removing for dependencies: glusterfs-api x86_64 3.4.0-2.fc19 @updates-testing 88 k glusterfs-fuse x86_64 3.4.0-2.fc19 @updates-testing 233 k 5M of deps, meanwhile.. qemu-system-alpha x86_64 2:1.4.2-4.fc19 @updates-testing 4.1 M qemu-system-arm x86_64 2:1.4.2-4.fc19 @updates-testing 5.2 M qemu-system-crisx86_64 2:1.4.2-4.fc19 @updates-testing 2.8 M qemu-system-lm32x86_64 2:1.4.2-4.fc19 @updates-testing 2.8 M qemu-system-m68kx86_64 2:1.4.2-4.fc19 @updates-testing 3.8 M qemu-system-microblaze x86_64 2:1.4.2-4.fc19 @updates-testing 5.6 M qemu-system-mipsx86_64 2:1.4.2-4.fc19 @updates-testing 21 M qemu-system-or32x86_64 2:1.4.2-4.fc19 @updates-testing 2.7 M qemu-system-ppc x86_64 2:1.4.2-4.fc19 @updates-testing 18 M qemu-system-s390x x86_64 2:1.4.2-4.fc19 @updates-testing 3.1 M qemu-system-sh4 x86_64 2:1.4.2-4.fc19 @updates-testing 7.5 M qemu-system-sparc x86_64 2:1.4.2-4.fc19 @updates-testing 7.3 M qemu-system-unicore32 x86_64 2:1.4.2-4.fc19 @updates-testing 2.7 M qemu-system-xtensa x86_64 2:1.4.2-4.fc19 @updates-testing 5.6 M Do we really *need* all those ? (And why are mips ppc so much bigger ?) To get a minimal working KVM based virt, I used to run: $ yum install libvirt-daemon-kvm libvirt-daemon-config-network \ libvirt-daemon-config-nwfilter -y $ yum install virt-install -y # This is what is pulling in all the other arch qemu deps $ yum install libguestfs libguestfs-tools libguestfs-tools-c -y -- /kashyap -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Tue, Jul 23, 2013 at 09:46:30PM +0100, Richard W.M. Jones wrote: On Tue, Jul 23, 2013 at 03:00:46PM -0400, Bill Nottingham wrote: Richard W.M. Jones (rjo...@redhat.com) said: On Tue, Jul 23, 2013 at 06:15:32PM +0100, Richard W.M. Jones wrote: However for some reason I can't quite understand, libvirt-daemon depends on 'qemu'. That may be a bug? I meant to write: 'libvirt-daemon-qemu' depends on 'qemu'. Isn't it simplest for that to depend on a virtual 'qemu-system', which is provided by qemu-kvm on KVM arches, and qemu-system-XYZ on non-KVM arches? Right, which is why I said this may be a bug. Dan Berrange (CC'd on this subthread) will know. The libvirt-daemon-qemu package is intended to pull in the QEMU emulators. If you only want to pull in KVM, then you should depend on the separate libvirt-daemon-kvm package instead. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Tue, Jul 23, 2013 at 11:28:20AM -0700, Adam Williamson wrote: On Tue, 2013-07-23 at 18:15 +0100, Richard W.M. Jones wrote: On Tue, Jul 23, 2013 at 12:57:50PM -0400, Dave Jones wrote: On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote: So this thread is complaining about.. Removing: glusterfs x86_64 3.4.0-2.fc19 @updates-testing 4.7 M Removing for dependencies: glusterfs-api x86_64 3.4.0-2.fc19 @updates-testing 88 k glusterfs-fuse x86_64 3.4.0-2.fc19 @updates-testing 233 k 5M of deps, meanwhile.. qemu-system-alpha x86_64 2:1.4.2-4.fc19 @updates-testing 4.1 M qemu-system-arm x86_64 2:1.4.2-4.fc19 @updates-testing 5.2 M qemu-system-crisx86_64 2:1.4.2-4.fc19 @updates-testing 2.8 M qemu-system-lm32x86_64 2:1.4.2-4.fc19 @updates-testing 2.8 M qemu-system-m68kx86_64 2:1.4.2-4.fc19 @updates-testing 3.8 M qemu-system-microblaze x86_64 2:1.4.2-4.fc19 @updates-testing 5.6 M qemu-system-mipsx86_64 2:1.4.2-4.fc19 @updates-testing 21 M qemu-system-or32x86_64 2:1.4.2-4.fc19 @updates-testing 2.7 M qemu-system-ppc x86_64 2:1.4.2-4.fc19 @updates-testing 18 M qemu-system-s390x x86_64 2:1.4.2-4.fc19 @updates-testing 3.1 M qemu-system-sh4 x86_64 2:1.4.2-4.fc19 @updates-testing 7.5 M qemu-system-sparc x86_64 2:1.4.2-4.fc19 @updates-testing 7.3 M qemu-system-unicore32 x86_64 2:1.4.2-4.fc19 @updates-testing 2.7 M qemu-system-xtensa x86_64 2:1.4.2-4.fc19 @updates-testing 5.6 M Do we really *need* all those ? Hopefully those *are* removable. Unfortunately some packages depend on the 'qemu' meta package which pulls in all of the emulators. I don't know if that's the case for me, I just did a 'yum install @Virtualization' on the host in question which is why I have all the stuff the metapackages pull in. I know about that, which is why I didn't complain about it. Hmm, if @Virtualization pulls in all the QEMU emulators then we probably have a bogus comps config. I'd say @Virtualization should probably only pull in the KVM binary, leaving the QEMU emulators alone, since few people will want them. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Wed, Jul 24, 2013 at 10:17:14AM +0100, Daniel P. Berrange wrote: On Tue, Jul 23, 2013 at 09:46:30PM +0100, Richard W.M. Jones wrote: On Tue, Jul 23, 2013 at 03:00:46PM -0400, Bill Nottingham wrote: Richard W.M. Jones (rjo...@redhat.com) said: On Tue, Jul 23, 2013 at 06:15:32PM +0100, Richard W.M. Jones wrote: However for some reason I can't quite understand, libvirt-daemon depends on 'qemu'. That may be a bug? I meant to write: 'libvirt-daemon-qemu' depends on 'qemu'. Isn't it simplest for that to depend on a virtual 'qemu-system', which is provided by qemu-kvm on KVM arches, and qemu-system-XYZ on non-KVM arches? Right, which is why I said this may be a bug. Dan Berrange (CC'd on this subthread) will know. The libvirt-daemon-qemu package is intended to pull in the QEMU emulators. If you only want to pull in KVM, then you should depend on the separate libvirt-daemon-kvm package instead. In libguestfs I have: Requires: libvirt-daemon-qemu = 0.10.2-3 %ifarch %{ix86} x86_64 Requires: libvirt-daemon-kvm = 0.10.2-3 %endif because I don't know if I'm going to be needing TCG or can use KVM. Although, qemu-kvm is now an empty package .. So all I really want is qemu-system-%{arch}. There's also code in libguestfs (src/launch-libvirt.c:parse_capabilities) to parse the capabilities output looking for qemu or kvm. It would be nice if there was a best option instead. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Wed, Jul 24, 2013 at 11:08:41AM +0100, Richard W.M. Jones wrote: On Wed, Jul 24, 2013 at 10:17:14AM +0100, Daniel P. Berrange wrote: On Tue, Jul 23, 2013 at 09:46:30PM +0100, Richard W.M. Jones wrote: On Tue, Jul 23, 2013 at 03:00:46PM -0400, Bill Nottingham wrote: Richard W.M. Jones (rjo...@redhat.com) said: On Tue, Jul 23, 2013 at 06:15:32PM +0100, Richard W.M. Jones wrote: However for some reason I can't quite understand, libvirt-daemon depends on 'qemu'. That may be a bug? I meant to write: 'libvirt-daemon-qemu' depends on 'qemu'. Isn't it simplest for that to depend on a virtual 'qemu-system', which is provided by qemu-kvm on KVM arches, and qemu-system-XYZ on non-KVM arches? Right, which is why I said this may be a bug. Dan Berrange (CC'd on this subthread) will know. The libvirt-daemon-qemu package is intended to pull in the QEMU emulators. If you only want to pull in KVM, then you should depend on the separate libvirt-daemon-kvm package instead. In libguestfs I have: Requires: libvirt-daemon-qemu = 0.10.2-3 %ifarch %{ix86} x86_64 Requires: libvirt-daemon-kvm = 0.10.2-3 %endif because I don't know if I'm going to be needing TCG or can use KVM. But the qemu-kvm binary can still run in TCG mode - you don't need to install the QEMU emulators too. So your dep could be %ifarch %{ix86} x86_64 Requires: libvirt-daemon-kvm = 0.10.2-3 %else Requires: libvirt-daemon-qemu = 0.10.2-3 %endif thus avoiding install of QEMU emulators unless they're the only option available. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On 07/24/2013 05:18 AM, Daniel P. Berrange wrote: On Tue, Jul 23, 2013 at 11:28:20AM -0700, Adam Williamson wrote: On Tue, 2013-07-23 at 18:15 +0100, Richard W.M. Jones wrote: On Tue, Jul 23, 2013 at 12:57:50PM -0400, Dave Jones wrote: On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote: So this thread is complaining about.. Removing: glusterfs x86_64 3.4.0-2.fc19 @updates-testing 4.7 M Removing for dependencies: glusterfs-api x86_64 3.4.0-2.fc19 @updates-testing 88 k glusterfs-fuse x86_64 3.4.0-2.fc19 @updates-testing 233 k 5M of deps, meanwhile.. qemu-system-alpha x86_64 2:1.4.2-4.fc19 @updates-testing 4.1 M qemu-system-arm x86_64 2:1.4.2-4.fc19 @updates-testing 5.2 M qemu-system-crisx86_64 2:1.4.2-4.fc19 @updates-testing 2.8 M qemu-system-lm32x86_64 2:1.4.2-4.fc19 @updates-testing 2.8 M qemu-system-m68kx86_64 2:1.4.2-4.fc19 @updates-testing 3.8 M qemu-system-microblaze x86_64 2:1.4.2-4.fc19 @updates-testing 5.6 M qemu-system-mipsx86_64 2:1.4.2-4.fc19 @updates-testing 21 M qemu-system-or32x86_64 2:1.4.2-4.fc19 @updates-testing 2.7 M qemu-system-ppc x86_64 2:1.4.2-4.fc19 @updates-testing 18 M qemu-system-s390x x86_64 2:1.4.2-4.fc19 @updates-testing 3.1 M qemu-system-sh4 x86_64 2:1.4.2-4.fc19 @updates-testing 7.5 M qemu-system-sparc x86_64 2:1.4.2-4.fc19 @updates-testing 7.3 M qemu-system-unicore32 x86_64 2:1.4.2-4.fc19 @updates-testing 2.7 M qemu-system-xtensa x86_64 2:1.4.2-4.fc19 @updates-testing 5.6 M Do we really *need* all those ? Hopefully those *are* removable. Unfortunately some packages depend on the 'qemu' meta package which pulls in all of the emulators. I don't know if that's the case for me, I just did a 'yum install @Virtualization' on the host in question which is why I have all the stuff the metapackages pull in. I know about that, which is why I didn't complain about it. Hmm, if @Virtualization pulls in all the QEMU emulators then we probably have a bogus comps config. I'd say @Virtualization should probably only pull in the KVM binary, leaving the QEMU emulators alone, since few people will want them. Yeah comps still has a dep on plain 'libvirt' which will pull all of that in. If no one objects, I'll push a change to make it libvirt-daemon-driver-kvm which should only pull in the required libvirt bits. - Cole -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On 07/24/2013 01:36 PM, Cole Robinson wrote: On 07/24/2013 05:18 AM, Daniel P. Berrange wrote: On Tue, Jul 23, 2013 at 11:28:20AM -0700, Adam Williamson wrote: On Tue, 2013-07-23 at 18:15 +0100, Richard W.M. Jones wrote: On Tue, Jul 23, 2013 at 12:57:50PM -0400, Dave Jones wrote: On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote: So this thread is complaining about.. Removing: glusterfs x86_64 3.4.0-2.fc19 @updates-testing 4.7 M Removing for dependencies: glusterfs-api x86_64 3.4.0-2.fc19 @updates-testing 88 k glusterfs-fuse x86_64 3.4.0-2.fc19 @updates-testing 233 k 5M of deps, meanwhile.. qemu-system-alpha x86_64 2:1.4.2-4.fc19 @updates-testing 4.1 M qemu-system-arm x86_64 2:1.4.2-4.fc19 @updates-testing 5.2 M qemu-system-crisx86_64 2:1.4.2-4.fc19 @updates-testing 2.8 M qemu-system-lm32x86_64 2:1.4.2-4.fc19 @updates-testing 2.8 M qemu-system-m68kx86_64 2:1.4.2-4.fc19 @updates-testing 3.8 M qemu-system-microblaze x86_64 2:1.4.2-4.fc19 @updates-testing 5.6 M qemu-system-mipsx86_64 2:1.4.2-4.fc19 @updates-testing 21 M qemu-system-or32x86_64 2:1.4.2-4.fc19 @updates-testing 2.7 M qemu-system-ppc x86_64 2:1.4.2-4.fc19 @updates-testing 18 M qemu-system-s390x x86_64 2:1.4.2-4.fc19 @updates-testing 3.1 M qemu-system-sh4 x86_64 2:1.4.2-4.fc19 @updates-testing 7.5 M qemu-system-sparc x86_64 2:1.4.2-4.fc19 @updates-testing 7.3 M qemu-system-unicore32 x86_64 2:1.4.2-4.fc19 @updates-testing 2.7 M qemu-system-xtensa x86_64 2:1.4.2-4.fc19 @updates-testing 5.6 M Do we really *need* all those ? Hopefully those *are* removable. Unfortunately some packages depend on the 'qemu' meta package which pulls in all of the emulators. I don't know if that's the case for me, I just did a 'yum install @Virtualization' on the host in question which is why I have all the stuff the metapackages pull in. I know about that, which is why I didn't complain about it. Hmm, if @Virtualization pulls in all the QEMU emulators then we probably have a bogus comps config. I'd say @Virtualization should probably only pull in the KVM binary, leaving the QEMU emulators alone, since few people will want them. Yeah comps still has a dep on plain 'libvirt' which will pull all of that in. If no one objects, I'll push a change to make it libvirt-daemon-driver-kvm which should only pull in the required libvirt bits. Err, s/libvirt-daemon-driver-kvm/libvirt-daemon-kvm/ - COle -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
Daniel P. Berrange (berra...@redhat.com) said: But the qemu-kvm binary can still run in TCG mode - you don't need to install the QEMU emulators too. So your dep could be %ifarch %{ix86} x86_64 Requires: libvirt-daemon-kvm = 0.10.2-3 %else Requires: libvirt-daemon-qemu = 0.10.2-3 %endif thus avoiding install of QEMU emulators unless they're the only option available. libvirt-sandbox-libs also brings in libvirt-daemon-qemu - that seems strange at first glance. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Mon, Jul 22, 2013 at 08:26:18PM -0400, Matthew Miller wrote: On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote: Today in Absurd Dependency Bingo: glusterfs x86_64 3.4.0-2.fc19 @updates-testing 4.7 M [...] qemu-common x86_64 2:1.4.2-4.fc19 @updates-testing 624 k $ rpm -q --changelog qemu-common [...] * Wed May 15 2013 Cole Robinson crobi...@redhat.com - 2:1.4.1-2 - Enable gluster support And then all the rest just falls out from there because they require qemu. vinagre x86_64 3.8.2-1.fc19 @side 3.0 M (This one requires spice.) At 4.7M glusterfs isn't exactly tiny, and is another one of these things that's not so useful unless configured (even though that's awesomely easy); maybe the libs could be split out? The problem is that qemu's block layer isn't a stable API with pluggable / loadable modules. There's been some talk and even patches upstream trying making it so (at least, the loadable modules part, the stable API part will probably never happen). But it's not done yet. qemu's internal block API: http://git.qemu.org/?p=qemu.git;a=blob;f=include/block/block_int.h;h=c6ac871e210ea21f91d799e44a102119048dde54;hb=HEAD#l83 Therefore if you want to use qemu to access, in this case, a glusterfs cluster, then you have to compile qemu with gluster support, and that pulls in glusterfs. We could compile it out, but then no one would be able to use gluster to store their virtual machines at all. Not sure if glusterfs could be split into client and server parts and/or if that would help (only a client bit is needed). There's not a good way around this except a bunch of work in qemu upstream. 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://people.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On 07/23/2013 03:44 PM, Richard W.M. Jones wrote: Not sure if glusterfs could be split into client and server parts and/or if that would help (only a client bit is needed). glusterfs already exists in client (glusterfs and/or glusterfs-api and associated -devel rpms) and server (glusterfs-server) parts. -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Tue, Jul 23, 2013 at 03:49:37PM +0530, Kaleb KEITHLEY wrote: On 07/23/2013 03:44 PM, Richard W.M. Jones wrote: Not sure if glusterfs could be split into client and server parts and/or if that would help (only a client bit is needed). glusterfs already exists in client (glusterfs and/or glusterfs-api and associated -devel rpms) and server (glusterfs-server) parts. Perhaps it could be made lighter? I didn't think that glusterfsd the translators were required for a pure client. Rich. $ rpm -ql glusterfs /etc/logrotate.d/glusterd /etc/logrotate.d/glusterfs-fuse /etc/logrotate.d/glusterfsd /etc/sysconfig/glusterd /etc/sysconfig/glusterfsd /usr/lib64/glusterfs /usr/lib64/glusterfs/3.4.0beta4 /usr/lib64/glusterfs/3.4.0beta4/auth /usr/lib64/glusterfs/3.4.0beta4/auth/addr.so /usr/lib64/glusterfs/3.4.0beta4/auth/login.so /usr/lib64/glusterfs/3.4.0beta4/rpc-transport /usr/lib64/glusterfs/3.4.0beta4/rpc-transport/socket.so /usr/lib64/glusterfs/3.4.0beta4/xlator /usr/lib64/glusterfs/3.4.0beta4/xlator/cluster /usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/afr.so /usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/dht.so /usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/distribute.so /usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/nufa.so /usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/pump.so /usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/replicate.so /usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/stripe.so /usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/switch.so /usr/lib64/glusterfs/3.4.0beta4/xlator/debug /usr/lib64/glusterfs/3.4.0beta4/xlator/debug/error-gen.so /usr/lib64/glusterfs/3.4.0beta4/xlator/debug/io-stats.so /usr/lib64/glusterfs/3.4.0beta4/xlator/debug/trace.so /usr/lib64/glusterfs/3.4.0beta4/xlator/encryption /usr/lib64/glusterfs/3.4.0beta4/xlator/encryption/rot-13.so /usr/lib64/glusterfs/3.4.0beta4/xlator/features /usr/lib64/glusterfs/3.4.0beta4/xlator/features/access-control.so /usr/lib64/glusterfs/3.4.0beta4/xlator/features/index.so /usr/lib64/glusterfs/3.4.0beta4/xlator/features/locks.so /usr/lib64/glusterfs/3.4.0beta4/xlator/features/mac-compat.so /usr/lib64/glusterfs/3.4.0beta4/xlator/features/marker.so /usr/lib64/glusterfs/3.4.0beta4/xlator/features/quiesce.so /usr/lib64/glusterfs/3.4.0beta4/xlator/features/quota.so /usr/lib64/glusterfs/3.4.0beta4/xlator/features/read-only.so /usr/lib64/glusterfs/3.4.0beta4/xlator/features/worm.so /usr/lib64/glusterfs/3.4.0beta4/xlator/mount /usr/lib64/glusterfs/3.4.0beta4/xlator/performance /usr/lib64/glusterfs/3.4.0beta4/xlator/performance/io-cache.so /usr/lib64/glusterfs/3.4.0beta4/xlator/performance/io-threads.so /usr/lib64/glusterfs/3.4.0beta4/xlator/performance/md-cache.so /usr/lib64/glusterfs/3.4.0beta4/xlator/performance/open-behind.so /usr/lib64/glusterfs/3.4.0beta4/xlator/performance/quick-read.so /usr/lib64/glusterfs/3.4.0beta4/xlator/performance/read-ahead.so /usr/lib64/glusterfs/3.4.0beta4/xlator/performance/stat-prefetch.so /usr/lib64/glusterfs/3.4.0beta4/xlator/performance/write-behind.so /usr/lib64/glusterfs/3.4.0beta4/xlator/protocol /usr/lib64/glusterfs/3.4.0beta4/xlator/protocol/client.so /usr/lib64/glusterfs/3.4.0beta4/xlator/system /usr/lib64/glusterfs/3.4.0beta4/xlator/system/posix-acl.so /usr/lib64/glusterfs/3.4.0beta4/xlator/testing /usr/lib64/glusterfs/3.4.0beta4/xlator/testing/performance /usr/lib64/glusterfs/3.4.0beta4/xlator/testing/performance/symlink-cache.so /usr/lib64/libgfrpc.so.0 /usr/lib64/libgfrpc.so.0.0.0 /usr/lib64/libgfxdr.so.0 /usr/lib64/libgfxdr.so.0.0.0 /usr/lib64/libglusterfs.so.0 /usr/lib64/libglusterfs.so.0.0.0 /usr/libexec/glusterfs /usr/libexec/glusterfs/gsyncd /usr/libexec/glusterfs/python /usr/libexec/glusterfs/python/syncdaemon /usr/libexec/glusterfs/python/syncdaemon/README.md /usr/libexec/glusterfs/python/syncdaemon/__init__.py /usr/libexec/glusterfs/python/syncdaemon/__init__.pyc /usr/libexec/glusterfs/python/syncdaemon/__init__.pyo /usr/libexec/glusterfs/python/syncdaemon/configinterface.py /usr/libexec/glusterfs/python/syncdaemon/configinterface.pyc /usr/libexec/glusterfs/python/syncdaemon/configinterface.pyo /usr/libexec/glusterfs/python/syncdaemon/gconf.py /usr/libexec/glusterfs/python/syncdaemon/gconf.pyc /usr/libexec/glusterfs/python/syncdaemon/gconf.pyo /usr/libexec/glusterfs/python/syncdaemon/gsyncd.py /usr/libexec/glusterfs/python/syncdaemon/gsyncd.pyc /usr/libexec/glusterfs/python/syncdaemon/gsyncd.pyo /usr/libexec/glusterfs/python/syncdaemon/ipaddr.py /usr/libexec/glusterfs/python/syncdaemon/ipaddr.pyc /usr/libexec/glusterfs/python/syncdaemon/ipaddr.pyo /usr/libexec/glusterfs/python/syncdaemon/libcxattr.py /usr/libexec/glusterfs/python/syncdaemon/libcxattr.pyc /usr/libexec/glusterfs/python/syncdaemon/libcxattr.pyo /usr/libexec/glusterfs/python/syncdaemon/master.py /usr/libexec/glusterfs/python/syncdaemon/master.pyc /usr/libexec/glusterfs/python/syncdaemon/master.pyo /usr/libexec/glusterfs/python/syncdaemon/monitor.py /usr/libexec/glusterfs/python/syncdaemon/monitor.pyc
Re: Why does so much virt stuff depend on glusterfs?
On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote: Today in Absurd Dependency Bingo: Dependencies Resolved Package Arch Version Repository Size Removing: glusterfs x86_64 3.4.0-2.fc19 @updates-testing 4.7 M Removing for dependencies: glusterfs-api x86_64 3.4.0-2.fc19 @updates-testing 88 k glusterfs-fuse x86_64 3.4.0-2.fc19 @updates-testing 233 k gnome-boxes x86_64 3.8.3-1.fc19 @fedora 4.1 M libcacard x86_64 2:1.4.2-4.fc19 @updates-testing 81 k libvirt x86_64 1.0.5.4-1.fc19 @updates-testing 0.0 libvirt-daemon x86_64 1.0.5.4-1.fc19 @updates-testing 4.5 M libvirt-daemon-config-network x86_64 1.0.5.4-1.fc19 @updates-testing 0.0 libvirt-daemon-config-nwfilter x86_64 1.0.5.4-1.fc19 @updates-testing 6.1 k libvirt-daemon-driver-interface x86_64 1.0.5.4-1.fc19 @updates-testing 93 k libvirt-daemon-driver-libxl x86_64 1.0.5.4-1.fc19 @updates-testing 197 k libvirt-daemon-driver-lxc x86_64 1.0.5.4-1.fc19 @updates-testing 219 k libvirt-daemon-driver-network x86_64 1.0.5.4-1.fc19 @updates-testing 126 k libvirt-daemon-driver-nodedev x86_64 1.0.5.4-1.fc19 @updates-testing 93 k libvirt-daemon-driver-nwfilter x86_64 1.0.5.4-1.fc19 @updates-testing 159 k libvirt-daemon-driver-qemu x86_64 1.0.5.4-1.fc19 @updates-testing 919 k libvirt-daemon-driver-secretx86_64 1.0.5.4-1.fc19 @updates-testing 76 k libvirt-daemon-driver-storage x86_64 1.0.5.4-1.fc19 @updates-testing 192 k libvirt-daemon-driver-uml x86_64 1.0.5.4-1.fc19 @updates-testing 115 k libvirt-daemon-driver-xen x86_64 1.0.5.4-1.fc19 @updates-testing 226 k libvirt-daemon-kvm x86_64 1.0.5.4-1.fc19 @updates-testing 0.0 libvirt-daemon-qemu x86_64 1.0.5.4-1.fc19 @updates-testing 0.0 qemux86_64 2:1.4.2-4.fc19 @updates-testing 0.0 qemu-common x86_64 2:1.4.2-4.fc19 @updates-testing 624 k qemu-imgx86_64 2:1.4.2-4.fc19 @updates-testing 1.9 M qemu-kvmx86_64 2:1.4.2-4.fc19 @updates-testing 0.0 qemu-system-alpha x86_64 2:1.4.2-4.fc19 @updates-testing 4.1 M qemu-system-arm x86_64 2:1.4.2-4.fc19 @updates-testing 5.2 M qemu-system-crisx86_64 2:1.4.2-4.fc19 @updates-testing 2.8 M qemu-system-lm32x86_64 2:1.4.2-4.fc19 @updates-testing 2.8 M qemu-system-m68kx86_64 2:1.4.2-4.fc19 @updates-testing 3.8 M qemu-system-microblaze x86_64 2:1.4.2-4.fc19 @updates-testing 5.6 M qemu-system-mipsx86_64 2:1.4.2-4.fc19 @updates-testing 21 M qemu-system-or32x86_64 2:1.4.2-4.fc19 @updates-testing 2.7 M qemu-system-ppc x86_64 2:1.4.2-4.fc19 @updates-testing 18 M qemu-system-s390x x86_64 2:1.4.2-4.fc19 @updates-testing 3.1 M qemu-system-sh4 x86_64 2:1.4.2-4.fc19 @updates-testing 7.5 M qemu-system-sparc x86_64 2:1.4.2-4.fc19 @updates-testing 7.3 M qemu-system-unicore32 x86_64 2:1.4.2-4.fc19 @updates-testing 2.7 M qemu-system-x86 x86_64 2:1.4.2-4.fc19 @updates-testing 11 M qemu-system-xtensa x86_64 2:1.4.2-4.fc19 @updates-testing 5.6 M qemu-user x86_64 2:1.4.2-4.fc19 @updates-testing 52 M spice-glib x86_64 0.20-2.fc19 @updates-testing 1.2 M spice-gtk x86_64 0.20-2.fc19 @updates-testing 134 k spice-gtk-pythonx86_64 0.20-2.fc19 @updates-testing 52 k spice-gtk3 x86_64 0.20-2.fc19 @updates-testing 228 k vinagre x86_64 3.8.2-1.fc19 @side 3.0 M virt-managernoarch 0.10.0-1.fc19@updates-testing 3.6 M virt-viewer x86_64 0.5.6-1.fc19 @updates-testing 990 k WAT? There are many things going on here First, 'yum remove' is being overly dramtic. It is possible to remove glusterfs without removing 'libvirt' - only the 'libvirt-daemon' package depends on glusterfs-client. yum seems to want to remove far more than is strictly required by the deps. There is a genuine bogus dep from libcacard.so to the glusterfs libraries, likely caused by bad Makefile linker
Re: Why does so much virt stuff depend on glusterfs?
On Tue, Jul 23, 2013 at 12:32:23PM +0100, Daniel P. Berrange wrote: On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote: Today in Absurd Dependency Bingo: There are many things going on here First, 'yum remove' is being overly dramtic. It is possible to remove glusterfs without removing 'libvirt' - only the 'libvirt-daemon' package depends on glusterfs-client. yum seems to want to remove far more than is strictly required by the deps. There is a genuine bogus dep from libcacard.so to the glusterfs libraries, likely caused by bad Makefile linker flags in QEMU. This means that when you try to remove gluster, it needs to pull out libcacard which pulls out spice, which pulls out virt-manage, virt-viewer, vinagre. Fixing libcacard deps would improve things here Now filed https://bugzilla.redhat.com/show_bug.cgi?id=987441 The glusterfs packaging is sub-optimal too - the client library APIs should be isolated from the rest of the RPM, so QEMU linking against glusterfs doesn't automatically pull in everything. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Tue, Jul 23, 2013 at 03:49:37PM +0530, Kaleb KEITHLEY wrote: On 07/23/2013 03:44 PM, Richard W.M. Jones wrote: Not sure if glusterfs could be split into client and server parts and/or if that would help (only a client bit is needed). glusterfs already exists in client (glusterfs and/or glusterfs-api and associated -devel rpms) and server (glusterfs-server) parts. Hmm, I wonder if there's another QEMU linkage problem here. QEMU seems to only use glfs_* functions in its code, but it is linking to -lgfapi -lgfrpc -lgfxdr. It seems like it could probably link to just libgfapi.so, and thus only depend on glusterfs-api and not main glusterfs RPM. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Tue, Jul 23, 2013 at 12:45:59PM +0100, Daniel P. Berrange wrote: On Tue, Jul 23, 2013 at 03:49:37PM +0530, Kaleb KEITHLEY wrote: On 07/23/2013 03:44 PM, Richard W.M. Jones wrote: Not sure if glusterfs could be split into client and server parts and/or if that would help (only a client bit is needed). glusterfs already exists in client (glusterfs and/or glusterfs-api and associated -devel rpms) and server (glusterfs-server) parts. Hmm, I wonder if there's another QEMU linkage problem here. QEMU seems to only use glfs_* functions in its code, but it is linking to -lgfapi -lgfrpc -lgfxdr. It seems like it could probably link to just libgfapi.so, and thus only depend on glusterfs-api and not main glusterfs RPM. Ah yes, that's the key ... $ rpm -ql glusterfs-api /usr/lib64/glusterfs/3.4.0beta4/xlator/mount/api.so /usr/lib64/libgfapi.so.0 /usr/lib64/libgfapi.so.0.0.0 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Tue, Jul 23, 2013 at 12:32:23PM +0100, Daniel P. Berrange wrote: First, 'yum remove' is being overly dramtic. It is possible to remove glusterfs without removing 'libvirt' - only the 'libvirt-daemon' package depends on glusterfs-client. yum seems to want to remove far more than is strictly required by the deps. Hey, I think you're casting the blame in the wrong place here. Yum is just following the deps and not being dramatic. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On 07/23/2013 04:41 PM, Richard W.M. Jones wrote: On Tue, Jul 23, 2013 at 03:49:37PM +0530, Kaleb KEITHLEY wrote: On 07/23/2013 03:44 PM, Richard W.M. Jones wrote: Not sure if glusterfs could be split into client and server parts and/or if that would help (only a client bit is needed). glusterfs already exists in client (glusterfs and/or glusterfs-api and associated -devel rpms) and server (glusterfs-server) parts. Perhaps it could be made lighter? I didn't think that glusterfsd the translators were required for a pure client. /usr/sbin/glusterfs is a symlink to /usr/sbin/glusterfsd; glusterfs(d) is absolutely required for a client-side fuse mount, as are most of the translators — that's how gluster works. You can't predict, you can't second guess which translators will be required by any client — that's determined by how the server administrator configures the volumes. Rich. $ rpm -ql glusterfs /etc/logrotate.d/glusterd /etc/logrotate.d/glusterfs-fuse /etc/logrotate.d/glusterfsd /etc/sysconfig/glusterd /etc/sysconfig/glusterfsd /usr/lib64/glusterfs /usr/lib64/glusterfs/3.4.0beta4 /usr/lib64/glusterfs/3.4.0beta4/auth /usr/lib64/glusterfs/3.4.0beta4/auth/addr.so /usr/lib64/glusterfs/3.4.0beta4/auth/login.so /usr/lib64/glusterfs/3.4.0beta4/rpc-transport /usr/lib64/glusterfs/3.4.0beta4/rpc-transport/socket.so /usr/lib64/glusterfs/3.4.0beta4/xlator /usr/lib64/glusterfs/3.4.0beta4/xlator/cluster /usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/afr.so /usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/dht.so /usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/distribute.so /usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/nufa.so /usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/pump.so /usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/replicate.so /usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/stripe.so /usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/switch.so /usr/lib64/glusterfs/3.4.0beta4/xlator/debug /usr/lib64/glusterfs/3.4.0beta4/xlator/debug/error-gen.so /usr/lib64/glusterfs/3.4.0beta4/xlator/debug/io-stats.so /usr/lib64/glusterfs/3.4.0beta4/xlator/debug/trace.so /usr/lib64/glusterfs/3.4.0beta4/xlator/encryption /usr/lib64/glusterfs/3.4.0beta4/xlator/encryption/rot-13.so /usr/lib64/glusterfs/3.4.0beta4/xlator/features /usr/lib64/glusterfs/3.4.0beta4/xlator/features/access-control.so /usr/lib64/glusterfs/3.4.0beta4/xlator/features/index.so /usr/lib64/glusterfs/3.4.0beta4/xlator/features/locks.so /usr/lib64/glusterfs/3.4.0beta4/xlator/features/mac-compat.so /usr/lib64/glusterfs/3.4.0beta4/xlator/features/marker.so /usr/lib64/glusterfs/3.4.0beta4/xlator/features/quiesce.so /usr/lib64/glusterfs/3.4.0beta4/xlator/features/quota.so /usr/lib64/glusterfs/3.4.0beta4/xlator/features/read-only.so /usr/lib64/glusterfs/3.4.0beta4/xlator/features/worm.so /usr/lib64/glusterfs/3.4.0beta4/xlator/mount /usr/lib64/glusterfs/3.4.0beta4/xlator/performance /usr/lib64/glusterfs/3.4.0beta4/xlator/performance/io-cache.so /usr/lib64/glusterfs/3.4.0beta4/xlator/performance/io-threads.so /usr/lib64/glusterfs/3.4.0beta4/xlator/performance/md-cache.so /usr/lib64/glusterfs/3.4.0beta4/xlator/performance/open-behind.so /usr/lib64/glusterfs/3.4.0beta4/xlator/performance/quick-read.so /usr/lib64/glusterfs/3.4.0beta4/xlator/performance/read-ahead.so /usr/lib64/glusterfs/3.4.0beta4/xlator/performance/stat-prefetch.so /usr/lib64/glusterfs/3.4.0beta4/xlator/performance/write-behind.so /usr/lib64/glusterfs/3.4.0beta4/xlator/protocol /usr/lib64/glusterfs/3.4.0beta4/xlator/protocol/client.so /usr/lib64/glusterfs/3.4.0beta4/xlator/system /usr/lib64/glusterfs/3.4.0beta4/xlator/system/posix-acl.so /usr/lib64/glusterfs/3.4.0beta4/xlator/testing /usr/lib64/glusterfs/3.4.0beta4/xlator/testing/performance /usr/lib64/glusterfs/3.4.0beta4/xlator/testing/performance/symlink-cache.so /usr/lib64/libgfrpc.so.0 /usr/lib64/libgfrpc.so.0.0.0 /usr/lib64/libgfxdr.so.0 /usr/lib64/libgfxdr.so.0.0.0 /usr/lib64/libglusterfs.so.0 /usr/lib64/libglusterfs.so.0.0.0 /usr/libexec/glusterfs /usr/libexec/glusterfs/gsyncd /usr/libexec/glusterfs/python /usr/libexec/glusterfs/python/syncdaemon /usr/libexec/glusterfs/python/syncdaemon/README.md /usr/libexec/glusterfs/python/syncdaemon/__init__.py /usr/libexec/glusterfs/python/syncdaemon/__init__.pyc /usr/libexec/glusterfs/python/syncdaemon/__init__.pyo /usr/libexec/glusterfs/python/syncdaemon/configinterface.py /usr/libexec/glusterfs/python/syncdaemon/configinterface.pyc /usr/libexec/glusterfs/python/syncdaemon/configinterface.pyo /usr/libexec/glusterfs/python/syncdaemon/gconf.py /usr/libexec/glusterfs/python/syncdaemon/gconf.pyc /usr/libexec/glusterfs/python/syncdaemon/gconf.pyo /usr/libexec/glusterfs/python/syncdaemon/gsyncd.py /usr/libexec/glusterfs/python/syncdaemon/gsyncd.pyc /usr/libexec/glusterfs/python/syncdaemon/gsyncd.pyo /usr/libexec/glusterfs/python/syncdaemon/ipaddr.py /usr/libexec/glusterfs/python/syncdaemon/ipaddr.pyc /usr/libexec/glusterfs/python/syncdaemon/ipaddr.pyo
Re: Why does so much virt stuff depend on glusterfs?
On 07/23/2013 05:20 PM, Richard W.M. Jones wrote: On Tue, Jul 23, 2013 at 12:45:59PM +0100, Daniel P. Berrange wrote: On Tue, Jul 23, 2013 at 03:49:37PM +0530, Kaleb KEITHLEY wrote: On 07/23/2013 03:44 PM, Richard W.M. Jones wrote: Not sure if glusterfs could be split into client and server parts and/or if that would help (only a client bit is needed). glusterfs already exists in client (glusterfs and/or glusterfs-api and associated -devel rpms) and server (glusterfs-server) parts. Hmm, I wonder if there's another QEMU linkage problem here. QEMU seems to only use glfs_* functions in its code, but it is linking to -lgfapi -lgfrpc -lgfxdr. It seems like it could probably link to just libgfapi.so, and thus only depend on glusterfs-api and not main glusterfs RPM. Ah yes, that's the key ... $ rpm -ql glusterfs-api /usr/lib64/glusterfs/3.4.0beta4/xlator/mount/api.so /usr/lib64/libgfapi.so.0 /usr/lib64/libgfapi.so.0.0.0 Even if libgfapi (from glusterfs-api) is used instead of client-side gluster fuse mount you still need the translators (from glusterfs) -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Tue, Jul 23, 2013 at 05:27:20PM +0530, Kaleb KEITHLEY wrote: $ rpm -ql glusterfs-api /usr/lib64/glusterfs/3.4.0beta4/xlator/mount/api.so /usr/lib64/libgfapi.so.0 /usr/lib64/libgfapi.so.0.0.0 Even if libgfapi (from glusterfs-api) is used instead of client-side gluster fuse mount you still need the translators (from glusterfs) Can this work without any client-side configuration? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On 07/23/2013 05:34 PM, Matthew Miller wrote: On Tue, Jul 23, 2013 at 05:27:20PM +0530, Kaleb KEITHLEY wrote: $ rpm -ql glusterfs-api /usr/lib64/glusterfs/3.4.0beta4/xlator/mount/api.so /usr/lib64/libgfapi.so.0 /usr/lib64/libgfapi.so.0.0.0 Even if libgfapi (from glusterfs-api) is used instead of client-side gluster fuse mount you still need the translators (from glusterfs) Can this work without any client-side configuration? Huh? qemu, when it's using glusterfs, is — by definition — a glusterfs client. -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Tue, Jul 23, 2013 at 05:27:20PM +0530, Kaleb KEITHLEY wrote: On 07/23/2013 05:20 PM, Richard W.M. Jones wrote: On Tue, Jul 23, 2013 at 12:45:59PM +0100, Daniel P. Berrange wrote: On Tue, Jul 23, 2013 at 03:49:37PM +0530, Kaleb KEITHLEY wrote: On 07/23/2013 03:44 PM, Richard W.M. Jones wrote: Not sure if glusterfs could be split into client and server parts and/or if that would help (only a client bit is needed). glusterfs already exists in client (glusterfs and/or glusterfs-api and associated -devel rpms) and server (glusterfs-server) parts. Hmm, I wonder if there's another QEMU linkage problem here. QEMU seems to only use glfs_* functions in its code, but it is linking to -lgfapi -lgfrpc -lgfxdr. It seems like it could probably link to just libgfapi.so, and thus only depend on glusterfs-api and not main glusterfs RPM. Ah yes, that's the key ... $ rpm -ql glusterfs-api /usr/lib64/glusterfs/3.4.0beta4/xlator/mount/api.so /usr/lib64/libgfapi.so.0 /usr/lib64/libgfapi.so.0.0.0 Even if libgfapi (from glusterfs-api) is used instead of client-side gluster fuse mount you still need the translators (from glusterfs) OK I see that glusterfs-api depends on the other libraries which would pull in glusterfs. So it seems there is no way to fix this except to split up qemu's block drivers, although there is a minor packaging problem that could be fixed too. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Tue, Jul 23, 2013 at 05:27:20PM +0530, Kaleb KEITHLEY wrote: On 07/23/2013 05:20 PM, Richard W.M. Jones wrote: On Tue, Jul 23, 2013 at 12:45:59PM +0100, Daniel P. Berrange wrote: On Tue, Jul 23, 2013 at 03:49:37PM +0530, Kaleb KEITHLEY wrote: On 07/23/2013 03:44 PM, Richard W.M. Jones wrote: Not sure if glusterfs could be split into client and server parts and/or if that would help (only a client bit is needed). glusterfs already exists in client (glusterfs and/or glusterfs-api and associated -devel rpms) and server (glusterfs-server) parts. Hmm, I wonder if there's another QEMU linkage problem here. QEMU seems to only use glfs_* functions in its code, but it is linking to -lgfapi -lgfrpc -lgfxdr. It seems like it could probably link to just libgfapi.so, and thus only depend on glusterfs-api and not main glusterfs RPM. Ah yes, that's the key ... $ rpm -ql glusterfs-api /usr/lib64/glusterfs/3.4.0beta4/xlator/mount/api.so /usr/lib64/libgfapi.so.0 /usr/lib64/libgfapi.so.0.0.0 Even if libgfapi (from glusterfs-api) is used instead of client-side gluster fuse mount you still need the translators (from glusterfs) Hmm, so normally the point of putting libraries in a sub-RPM is that you can install it without pulling in the main toolchain, to save space. Since the glusterfs-api RPM depends on glusterfs, you obviously can't do that. So I'm curious as to what the purpose of having glusterfs-api as a sub-RPM is ? Removing it saves 80 KB of disk space, so I guess it isn't space related. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Tue, Jul 23, 2013 at 05:40:03PM +0530, Kaleb KEITHLEY wrote: Can this work without any client-side configuration? Huh? qemu, when it's using glusterfs, is — by definition — a glusterfs client. Sorry, let me rephrase. Is the qemu-level configuration all you need, or do you also need to have pre-configured gluster on the system first? (I think gluster is neat but I haven't used it much, as you can see!) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
- Original Message - On 07/23/2013 05:20 PM, Richard W.M. Jones wrote: Ah yes, that's the key ... $ rpm -ql glusterfs-api /usr/lib64/glusterfs/3.4.0beta4/xlator/mount/api.so /usr/lib64/libgfapi.so.0 /usr/lib64/libgfapi.so.0.0.0 Even if libgfapi (from glusterfs-api) is used instead of client-side gluster fuse mount you still need the translators (from glusterfs) -- Kaleb Even if we're talking about use as *just* a client? I thought the translators were only needed if you're hosting the bricks on the same machine. I thought it was possible to have just libgfapi on the client, and then the machine with the bricks would need glusterfs. -JM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Tue, 2013-07-23 at 11:14 +0100, Richard W.M. Jones wrote: On Mon, Jul 22, 2013 at 08:26:18PM -0400, Matthew Miller wrote: On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote: Today in Absurd Dependency Bingo: glusterfs x86_64 3.4.0-2.fc19 @updates-testing 4.7 M [...] qemu-common x86_64 2:1.4.2-4.fc19 @updates-testing 624 k $ rpm -q --changelog qemu-common [...] * Wed May 15 2013 Cole Robinson crobi...@redhat.com - 2:1.4.1-2 - Enable gluster support And then all the rest just falls out from there because they require qemu. vinagre x86_64 3.8.2-1.fc19 @side 3.0 M (This one requires spice.) At 4.7M glusterfs isn't exactly tiny, and is another one of these things that's not so useful unless configured (even though that's awesomely easy); maybe the libs could be split out? The problem is that qemu's block layer isn't a stable API with pluggable / loadable modules. There's been some talk and even patches upstream trying making it so (at least, the loadable modules part, the stable API part will probably never happen). But it's not done yet. qemu's internal block API: http://git.qemu.org/?p=qemu.git;a=blob;f=include/block/block_int.h;h=c6ac871e210ea21f91d799e44a102119048dde54;hb=HEAD#l83 Therefore if you want to use qemu to access, in this case, a glusterfs cluster, then you have to compile qemu with gluster support, and that pulls in glusterfs. We could compile it out, but then no one would be able to use gluster to store their virtual machines at all. Not sure if glusterfs could be split into client and server parts and/or if that would help (only a client bit is needed). There's not a good way around this except a bunch of work in qemu upstream. Well. Will qemu still actually _run_ without glusterfs being present? If so, do we actually need to express a dependency on glusterfs? To me, the semantics of 'X requires Y' are fairly close to 'X will not function correctly without Y'. 'X can do some extra stuff if Y is present' does not seem to meet the case. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Tue, Jul 23, 2013 at 08:47:14AM -0700, Adam Williamson wrote: Well. Will qemu still actually _run_ without glusterfs being present? If so, do we actually need to express a dependency on glusterfs? No, I don't think so. I think it'll fail to start up because of a missing library. We could change qemu so it includes the block drivers, but each block drive dlopen(3)'s the special libraries it needs on start up, but that would make the code more complex. I really think the way to fix this is to make the block drivers loadable, and that is something which as far as I understand is desirable upstream too, just no one has written a set of patches which is acceptable. If we did this, packaging it right in Fedora would be simple; you'd end up with: qemu-block-gluster qemu-block-iscsi qemu-block-ssh etc. which would be independently installable subpackages that would depend on the correct libraries. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote: So this thread is complaining about.. Removing: glusterfs x86_64 3.4.0-2.fc19 @updates-testing 4.7 M Removing for dependencies: glusterfs-api x86_64 3.4.0-2.fc19 @updates-testing 88 k glusterfs-fuse x86_64 3.4.0-2.fc19 @updates-testing 233 k 5M of deps, meanwhile.. qemu-system-alpha x86_64 2:1.4.2-4.fc19 @updates-testing 4.1 M qemu-system-arm x86_64 2:1.4.2-4.fc19 @updates-testing 5.2 M qemu-system-crisx86_64 2:1.4.2-4.fc19 @updates-testing 2.8 M qemu-system-lm32x86_64 2:1.4.2-4.fc19 @updates-testing 2.8 M qemu-system-m68kx86_64 2:1.4.2-4.fc19 @updates-testing 3.8 M qemu-system-microblaze x86_64 2:1.4.2-4.fc19 @updates-testing 5.6 M qemu-system-mipsx86_64 2:1.4.2-4.fc19 @updates-testing 21 M qemu-system-or32x86_64 2:1.4.2-4.fc19 @updates-testing 2.7 M qemu-system-ppc x86_64 2:1.4.2-4.fc19 @updates-testing 18 M qemu-system-s390x x86_64 2:1.4.2-4.fc19 @updates-testing 3.1 M qemu-system-sh4 x86_64 2:1.4.2-4.fc19 @updates-testing 7.5 M qemu-system-sparc x86_64 2:1.4.2-4.fc19 @updates-testing 7.3 M qemu-system-unicore32 x86_64 2:1.4.2-4.fc19 @updates-testing 2.7 M qemu-system-xtensa x86_64 2:1.4.2-4.fc19 @updates-testing 5.6 M Do we really *need* all those ? (And why are mips ppc so much bigger ?) Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Tue, Jul 23, 2013 at 12:57:50PM -0400, Dave Jones wrote: On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote: So this thread is complaining about.. Removing: glusterfs x86_64 3.4.0-2.fc19 @updates-testing 4.7 M Removing for dependencies: glusterfs-api x86_64 3.4.0-2.fc19 @updates-testing 88 k glusterfs-fuse x86_64 3.4.0-2.fc19 @updates-testing 233 k 5M of deps, meanwhile.. qemu-system-alpha x86_64 2:1.4.2-4.fc19 @updates-testing 4.1 M qemu-system-arm x86_64 2:1.4.2-4.fc19 @updates-testing 5.2 M qemu-system-crisx86_64 2:1.4.2-4.fc19 @updates-testing 2.8 M qemu-system-lm32x86_64 2:1.4.2-4.fc19 @updates-testing 2.8 M qemu-system-m68kx86_64 2:1.4.2-4.fc19 @updates-testing 3.8 M qemu-system-microblaze x86_64 2:1.4.2-4.fc19 @updates-testing 5.6 M qemu-system-mipsx86_64 2:1.4.2-4.fc19 @updates-testing 21 M qemu-system-or32x86_64 2:1.4.2-4.fc19 @updates-testing 2.7 M qemu-system-ppc x86_64 2:1.4.2-4.fc19 @updates-testing 18 M qemu-system-s390x x86_64 2:1.4.2-4.fc19 @updates-testing 3.1 M qemu-system-sh4 x86_64 2:1.4.2-4.fc19 @updates-testing 7.5 M qemu-system-sparc x86_64 2:1.4.2-4.fc19 @updates-testing 7.3 M qemu-system-unicore32 x86_64 2:1.4.2-4.fc19 @updates-testing 2.7 M qemu-system-xtensa x86_64 2:1.4.2-4.fc19 @updates-testing 5.6 M Do we really *need* all those ? Hopefully those *are* removable. Unfortunately some packages depend on the 'qemu' meta package which pulls in all of the emulators. Libvirt will happily manage any subset of qemu-system-* that you have installed. It probes for what binaries are available when the libvirtd daemon starts up. However for some reason I can't quite understand, libvirt-daemon depends on 'qemu'. That may be a bug? (And why are mips ppc so much bigger ?) ppc is really three separate emulator binaries for different ppc-related architectures (ppc, ppc64 and embedded ppc). mips is also three binaries (mips, mips64 and something called mips64el). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Tue, 2013-07-23 at 12:57 -0400, Dave Jones wrote: qemu-system-alpha x86_64 2:1.4.2-4.fc19 @updates-testing 4.1 M qemu-system-arm x86_64 2:1.4.2-4.fc19 @updates-testing 5.2 M qemu-system-crisx86_64 2:1.4.2-4.fc19 @updates-testing 2.8 M qemu-system-lm32x86_64 2:1.4.2-4.fc19 @updates-testing 2.8 M qemu-system-m68kx86_64 2:1.4.2-4.fc19 @updates-testing 3.8 M qemu-system-microblaze x86_64 2:1.4.2-4.fc19 @updates-testing 5.6 M qemu-system-mipsx86_64 2:1.4.2-4.fc19 @updates-testing 21 M qemu-system-or32x86_64 2:1.4.2-4.fc19 @updates-testing 2.7 M qemu-system-ppc x86_64 2:1.4.2-4.fc19 @updates-testing 18 M qemu-system-s390x x86_64 2:1.4.2-4.fc19 @updates-testing 3.1 M qemu-system-sh4 x86_64 2:1.4.2-4.fc19 @updates-testing 7.5 M qemu-system-sparc x86_64 2:1.4.2-4.fc19 @updates-testing 7.3 M qemu-system-unicore32 x86_64 2:1.4.2-4.fc19 @updates-testing 2.7 M qemu-system-xtensa x86_64 2:1.4.2-4.fc19 @updates-testing 5.6 M Do we really *need* all those ? (And why are mips ppc so much bigger ?) qemu-system-mips{,64}{,el} and qemu-system-ppc{,64,emb}. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Tue, Jul 23, 2013 at 06:15:32PM +0100, Richard W.M. Jones wrote: However for some reason I can't quite understand, libvirt-daemon depends on 'qemu'. That may be a bug? I meant to write: 'libvirt-daemon-qemu' depends on 'qemu'. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
Am 23.07.2013 19:18, schrieb Richard W.M. Jones: On Tue, Jul 23, 2013 at 06:15:32PM +0100, Richard W.M. Jones wrote: However for some reason I can't quite understand, libvirt-daemon depends on 'qemu'. That may be a bug? I meant to write: 'libvirt-daemon-qemu' depends on 'qemu' IMHO it is generally a problem to depend on meta-packages pulling half of the world - in this case one big and fat package would be the same and finally more efficient that's not the idea behind sub-packages signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Tue, 2013-07-23 at 18:15 +0100, Richard W.M. Jones wrote: On Tue, Jul 23, 2013 at 12:57:50PM -0400, Dave Jones wrote: On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote: So this thread is complaining about.. Removing: glusterfs x86_64 3.4.0-2.fc19 @updates-testing 4.7 M Removing for dependencies: glusterfs-api x86_64 3.4.0-2.fc19 @updates-testing 88 k glusterfs-fuse x86_64 3.4.0-2.fc19 @updates-testing 233 k 5M of deps, meanwhile.. qemu-system-alpha x86_64 2:1.4.2-4.fc19 @updates-testing 4.1 M qemu-system-arm x86_64 2:1.4.2-4.fc19 @updates-testing 5.2 M qemu-system-crisx86_64 2:1.4.2-4.fc19 @updates-testing 2.8 M qemu-system-lm32x86_64 2:1.4.2-4.fc19 @updates-testing 2.8 M qemu-system-m68kx86_64 2:1.4.2-4.fc19 @updates-testing 3.8 M qemu-system-microblaze x86_64 2:1.4.2-4.fc19 @updates-testing 5.6 M qemu-system-mipsx86_64 2:1.4.2-4.fc19 @updates-testing 21 M qemu-system-or32x86_64 2:1.4.2-4.fc19 @updates-testing 2.7 M qemu-system-ppc x86_64 2:1.4.2-4.fc19 @updates-testing 18 M qemu-system-s390x x86_64 2:1.4.2-4.fc19 @updates-testing 3.1 M qemu-system-sh4 x86_64 2:1.4.2-4.fc19 @updates-testing 7.5 M qemu-system-sparc x86_64 2:1.4.2-4.fc19 @updates-testing 7.3 M qemu-system-unicore32 x86_64 2:1.4.2-4.fc19 @updates-testing 2.7 M qemu-system-xtensa x86_64 2:1.4.2-4.fc19 @updates-testing 5.6 M Do we really *need* all those ? Hopefully those *are* removable. Unfortunately some packages depend on the 'qemu' meta package which pulls in all of the emulators. I don't know if that's the case for me, I just did a 'yum install @Virtualization' on the host in question which is why I have all the stuff the metapackages pull in. I know about that, which is why I didn't complain about it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Tue, Jul 23, 2013 at 11:14 AM, Richard W.M. Jones rjo...@redhat.com wrote: On Mon, Jul 22, 2013 at 08:26:18PM -0400, Matthew Miller wrote: On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote: Today in Absurd Dependency Bingo: glusterfs x86_64 3.4.0-2.fc19 @updates-testing 4.7 M [...] qemu-common x86_64 2:1.4.2-4.fc19 @updates-testing 624 k $ rpm -q --changelog qemu-common [...] * Wed May 15 2013 Cole Robinson crobi...@redhat.com - 2:1.4.1-2 - Enable gluster support And then all the rest just falls out from there because they require qemu. vinagre x86_64 3.8.2-1.fc19 @side 3.0 M (This one requires spice.) At 4.7M glusterfs isn't exactly tiny, and is another one of these things that's not so useful unless configured (even though that's awesomely easy); maybe the libs could be split out? The problem is that qemu's block layer isn't a stable API with pluggable / loadable modules. There's been some talk and even patches upstream trying making it so (at least, the loadable modules part, the stable API part will probably never happen). But it's not done yet. qemu's internal block API: http://git.qemu.org/?p=qemu.git;a=blob;f=include/block/block_int.h;h=c6ac871e210ea21f91d799e44a102119048dde54;hb=HEAD#l83 Therefore if you want to use qemu to access, in this case, a glusterfs cluster, then you have to compile qemu with gluster support, and that pulls in glusterfs. We could compile it out, but then no one would be able to use gluster to store their virtual machines at all. Not sure if glusterfs could be split into client and server parts and/or if that would help (only a client bit is needed). I thought gluster 3.4 was suppose to support a libgfapi which integrated into qemu [1] so in theory the bare minimum qemu should need is libgfapi. [1] http://www.gluster.org/2013/07/glusterfs-3-4-is-here/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Tue, Jul 23, 2013 at 11:19 AM, Kaleb KEITHLEY kkeit...@redhat.com wrote: On 07/23/2013 03:44 PM, Richard W.M. Jones wrote: Not sure if glusterfs could be split into client and server parts and/or if that would help (only a client bit is needed). glusterfs already exists in client (glusterfs and/or glusterfs-api and associated -devel rpms) and server (glusterfs-server) parts. Can't it be split out into libgfapi for things that use that like, in theory, qemu and then the fuse client etc. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Tue, Jul 23, 2013 at 12:57 PM, Kaleb KEITHLEY kkeit...@redhat.com wrote: On 07/23/2013 05:20 PM, Richard W.M. Jones wrote: On Tue, Jul 23, 2013 at 12:45:59PM +0100, Daniel P. Berrange wrote: On Tue, Jul 23, 2013 at 03:49:37PM +0530, Kaleb KEITHLEY wrote: On 07/23/2013 03:44 PM, Richard W.M. Jones wrote: Not sure if glusterfs could be split into client and server parts and/or if that would help (only a client bit is needed). glusterfs already exists in client (glusterfs and/or glusterfs-api and associated -devel rpms) and server (glusterfs-server) parts. Hmm, I wonder if there's another QEMU linkage problem here. QEMU seems to only use glfs_* functions in its code, but it is linking to -lgfapi -lgfrpc -lgfxdr. It seems like it could probably link to just libgfapi.so, and thus only depend on glusterfs-api and not main glusterfs RPM. Ah yes, that's the key ... $ rpm -ql glusterfs-api /usr/lib64/glusterfs/3.4.0beta4/xlator/mount/api.so /usr/lib64/libgfapi.so.0 /usr/lib64/libgfapi.so.0.0.0 Even if libgfapi (from glusterfs-api) is used instead of client-side gluster fuse mount you still need the translators (from glusterfs) Can't you split the translators into a glusterfs-common (or something) that libgfapi depends on and then have glusterfs-fuse and other sub packages. An in the case of translators why no split out all but the defaults and any others the server admin should deal with. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
Richard W.M. Jones (rjo...@redhat.com) said: On Tue, Jul 23, 2013 at 06:15:32PM +0100, Richard W.M. Jones wrote: However for some reason I can't quite understand, libvirt-daemon depends on 'qemu'. That may be a bug? I meant to write: 'libvirt-daemon-qemu' depends on 'qemu'. Isn't it simplest for that to depend on a virtual 'qemu-system', which is provided by qemu-kvm on KVM arches, and qemu-system-XYZ on non-KVM arches? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Tue, Jul 23, 2013 at 07:54:31PM +0100, Peter Robinson wrote: I thought gluster 3.4 was suppose to support a libgfapi which integrated into qemu [1] so in theory the bare minimum qemu should need is libgfapi. [1] http://www.gluster.org/2013/07/glusterfs-3-4-is-here/ Right, and that's what is happening. However that dependency on libgfapi is pulling in the glusterfs package. By splitting out the qemu gluster driver into a loadable module it would be possible to have a separate Fedora qemu-block-glusterfs subpackage which have the libgfapi dependency. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Tue, Jul 23, 2013 at 03:00:46PM -0400, Bill Nottingham wrote: Richard W.M. Jones (rjo...@redhat.com) said: On Tue, Jul 23, 2013 at 06:15:32PM +0100, Richard W.M. Jones wrote: However for some reason I can't quite understand, libvirt-daemon depends on 'qemu'. That may be a bug? I meant to write: 'libvirt-daemon-qemu' depends on 'qemu'. Isn't it simplest for that to depend on a virtual 'qemu-system', which is provided by qemu-kvm on KVM arches, and qemu-system-XYZ on non-KVM arches? Right, which is why I said this may be a bug. Dan Berrange (CC'd on this subthread) will know. 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://people.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On 07/24/2013 12:29 AM, Peter Robinson wrote: Can't you split the translators into a glusterfs-common (or something) The glusterfs RPM already is the glusterfs-common RPM that you want. If you look, you'll see that the other things in the glusterfs RPM really aren't that big; moving the translators to a different RPM doesn't buy you anything. that libgfapi depends on and then have glusterfs-fuse and other sub packages. An in the case of translators why no split out all but the defaults and any others the server admin should deal with. Again, you can't second guess which translators are defaults. Server admins configure volumes and options and the client-side could need any of them. -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote: Today in Absurd Dependency Bingo: glusterfs x86_64 3.4.0-2.fc19 @updates-testing 4.7 M [...] qemu-common x86_64 2:1.4.2-4.fc19 @updates-testing 624 k $ rpm -q --changelog qemu-common [...] * Wed May 15 2013 Cole Robinson crobi...@redhat.com - 2:1.4.1-2 - Enable gluster support And then all the rest just falls out from there because they require qemu. vinagre x86_64 3.8.2-1.fc19 @side 3.0 M (This one requires spice.) At 4.7M glusterfs isn't exactly tiny, and is another one of these things that's not so useful unless configured (even though that's awesomely easy); maybe the libs could be split out? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On Jul 22, 2013, at 6:26 PM, Matthew Miller mat...@fedoraproject.org wrote: On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote: Today in Absurd Dependency Bingo: glusterfs x86_64 3.4.0-2.fc19 @updates-testing 4.7 M [...] qemu-common x86_64 2:1.4.2-4.fc19 @updates-testing 624 k $ rpm -q --changelog qemu-common [...] * Wed May 15 2013 Cole Robinson crobi...@redhat.com - 2:1.4.1-2 - Enable gluster support And then all the rest just falls out from there because they require qemu. vinagre x86_64 3.8.2-1.fc19 @side 3.0 M (This one requires spice.) At 4.7M glusterfs isn't exactly tiny, and is another one of these things that's not so useful unless configured (even though that's awesomely easy); maybe the libs could be split out? glusterfs is included on Desktop/live install media. And it produces a big red FAIL in systemctl status listing by default. It seemed at first this was due to an avc denial, but that's since been fixed, yet the failure to start by default remains. https://bugzilla.redhat.com/show_bug.cgi?id=980683 Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel