From bclark at redhat.com Fri Feb 8 14:17:52 2008 From: bclark at redhat.com (Bryan W Clark) Date: Fri, 08 Feb 2008 09:17:52 -0500 Subject: [Ovirt-devel] first post Message-ID: <47AC6490.3030207@redhat.com> bet you didn't think that would happen. oh snap! From mdehaan at redhat.com Tue Feb 12 16:55:29 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 12 Feb 2008 11:55:29 -0500 Subject: [Ovirt-devel] Re: [internal-et-mgmt] ovirt integration w/ cobbler In-Reply-To: <20080212163809.GD6534@redhat.com> References: <47B1C8DA.2000501@redhat.com> <20080212163809.GD6534@redhat.com> Message-ID: <47B1CF81.9070903@redhat.com> Hugh O. Brock wrote: > On Tue, Feb 12, 2008 at 11:27:06AM -0500, Michael DeHaan wrote: > >> Is there a list/repo for ovirt development? >> >> I know the subject of provisioning integration came up, and wanted to know >> what I could do to help. >> >> > Hey Michael. Ovirt list is ovirt-devel at redhat.com -- we are about to > announce it. virt-devel at redhat.com will also work. Yes, figuring out > how to do provisioning integration with cobbler is on our list > although we aren't thinking about it quite yet beyond the level of "we > need some way to manage images that are pxe-able as well as a directory of > ISOs." My guess is that cobbler now does this quite well although I am > not using anything like the current version. Any thoughts you have > will be much appreciated... > > Take care, > --Hugh > It doesn't do ISOs yet, but that's something that could be added. It would require some minor cobbler/koan changes. If someone is interested in working with me on that, that's great... if not, if I can better understand the requirements it should not be that complex to add myself. Basically I'm guessing you want to either do: (a) fullvirt provisioning where there is no PXE server, and you can't do kernel+initrd installs like koan does now (like Xen FV works on F8) (b) non-Linux installs (make koan deploy an arbitrary OS) Either way it doesn't seem to be hard to add. Lately I've mostly been working on making sure Cobbler can handle the needs of some of the larger install bases -- which is coming along pretty well. One thing that might also be interesting for ovirt is the koan live CD ... basically it allows you to insert a CD/USB-image into any baremetal machine, boot it, and it will install to whatever cobbler profile you want... this can be either a preset profile, e.g. "foo", or can be detected based on the MAC address. This could be any distro as well, so a F8/F9 based installer image could install EL4. Kinda neat if you need to add new machines to your "cloud" and ovirt isn't the "official" provisioning server. Anyhow, let me know more about what features you need, and I'd be glad to help. The APIs are pretty solid at this point -- Virt-Factory was using them, Cobbler's web UI is using them now, and I can add anything that isn't there. Auth is also pluggable now so we can write a module to use whatever authentication system ovirt might be using. --Michael From hbrock at redhat.com Wed Feb 13 14:22:32 2008 From: hbrock at redhat.com (Hugh O. Brock) Date: Wed, 13 Feb 2008 09:22:32 -0500 Subject: [Ovirt-devel] ovirt freenode IRC channel Message-ID: <20080213142232.GA15291@redhat.com> ... is now up: freenode.irc.net:6667 #ovirt We will be moving as much project discussion as we can over there. Please join us! Take care, --Hugh From berrange at redhat.com Thu Feb 14 22:58:22 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 14 Feb 2008 22:58:22 +0000 Subject: [Ovirt-devel] Re: ovirt integration w/ cobbler In-Reply-To: <47B1CF81.9070903@redhat.com> References: <47B1C8DA.2000501@redhat.com> <20080212163809.GD6534@redhat.com> <47B1CF81.9070903@redhat.com> Message-ID: <20080214225822.GP6826@redhat.com> On Tue, Feb 12, 2008 at 11:55:29AM -0500, Michael DeHaan wrote: > > It doesn't do ISOs yet, but that's something that could be added. > > It would require some minor cobbler/koan changes. If someone is > interested in working with me on that, that's great... > if not, if I can better understand the requirements it should not be > that complex to add myself. > > Basically I'm guessing you want to either do: > (a) fullvirt provisioning where there is no PXE server, and you can't > do kernel+initrd installs like koan does now (like Xen FV works on F8) > (b) non-Linux installs (make koan deploy an arbitrary OS) Yep, we've got 2 core use cases: - Deploying the 'managed host' images. This is a pre-built minimal Fedora image essentially onl running libvirt. The idea being you turn on a physical host, it PXE's this image and joins itself to the oVirt management server and can now have guests deployed on it We can build images such that they have a kernel+initrd if needed. - Deploying the guest OS'. This can be any OS, be it Linux, Windows BSD, Solaris, etc. Obviously Fedora / RHEL are trivial since we can always do kernel+initrd from the main distro trees. > One thing that might also be interesting for ovirt is the koan live CD > ... basically it allows you to insert a CD/USB-image into any baremetal > machine, > boot it, and it will install to whatever cobbler profile you want... > this can be either a preset profile, e.g. "foo", or can be detected > based on the MAC > address. This could be any distro as well, so a F8/F9 based installer > image could install EL4. Kinda neat if you need to add new machines > to your "cloud" and ovirt isn't the "official" provisioning server. That sounds like a nice idea for places where we can't directly use PXE. > The APIs are pretty solid at this point -- Virt-Factory was using them, > Cobbler's web UI is using them now, and I can add anything that isn't there. > Auth is also pluggable now so we can write a module to use whatever > authentication system ovirt might be using. Are there any docs on the APIs available for controlling Cobbler ? For authentication we're basically Kerberos enabled throughout. All the services and users have kerberos tickets / principals. If the Cobbler APIs can be setup to go via Apache's mod_kerb that should do the trick quite nicely. At worse we can copy the FreeIPA approach of having Apache do the auth and then proxypass the request through to Cobbler which can read the authenticated username from the HTTP request. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From veillard at redhat.com Fri Feb 15 11:26:26 2008 From: veillard at redhat.com (Daniel Veillard) Date: Fri, 15 Feb 2008 06:26:26 -0500 Subject: [Ovirt-devel] A few things (rather long actually) Message-ID: <20080215112625.GA18204@redhat.com> Hugh asked me yesterday to post on the list the issues i found out when going though the docs/download/install steps, so here there are: + lack of global overview, it's very hard just by reading the docs to see what ovirt requires, what it provides. Suggested some kind of diagram might help, see attached a rough first version using xfig, that may do it until someone with graphic skills and taste refines it (and assuming i got all concepts right) see attached ovirt.fig and ovirt.png + related to it, it's really good to have a glossary, use only the same terms though the documentation for the same pieces of the infrastructure. Ideally this should match libvirt terminology (Node/Hypervisor/Domain), in the graphic I made: - Console Node: for the physical machine running the WUI appliance - Cluster Nodes: for the physical barebone machines used to run the user domains - WUI appliance: the domain running the services needed for ovirt provisionning, authentication and management - managed domains: for the domains the user actually want to run and control those terms are my pick, I find 'oVirt host(s)' and 'oVirt management host' too similar to the point they are confusing and not matching libvirt own terminology, sorry :-) + it's hard to see the requirement for installing my current list so far is: - one 64bits machine with an existing OS and KVM support to run the WUI appliance domain, 2-3 GB available in the root user directory (Xen based fully virt may work also with tweaking) - at least one node for the cluster, a bare machine, able to PXE boot (ideally otherwise booting from a CD or USB key) 64bits with hardware virtualization support - at least one network connecting the machines and DNS and DHCP for that network are under the user control (this may be relaxed in the future) General feedback is that this is a very contraining set, which may put many 'would be' testers off, it's really better to put those upfront nothing is worse from their viewpoint than spending time for nothing, on the other hand being explicit may get some of them in an helping mood since we generally want to remove/ease a lot of those requirements. + some errors in the installation documentation at http://ovirt.org/install-instructions.html - "Move the image (wui-appliance.dsk.bz2) to /root and unzip it: # tar -jxvf /root/wui-appliance.dsk.bz2" This is actually a bzipped image and tar should not be used # bunzip2 /root/wui-appliance.dsk.bz2 - in the default wui-appliance.xml, it is set up to boot from a CDRom image: and later the first definition should be changed to and the block describing the CDRom should be removed so that the appliance actually boots from /root/wui-appliance.dsk image. - WUI domain creation instruction should be for KVM as the XML provided is for KVM, so the command: # virsh create /path/to/wui-appliance.xml needs an extra -c qemu:///system argument to actually work - Building the appliance from a kickstart is actually hard to set up, do not suggest it as a way to avoid the time of the download "Booting and provisioning a host or a VM with a kickstart is left as an exercise for the reader." is condescending, actually very hard, get rid of the section, assume user will follow the standard track (download + using KVM), but document separately the process for rebuilding the appliance, and changes needed to run it as a Xen fully-virt domain (I assume only the xml and way to launch the applicance need changes) I guess it's all so far, i hope it will help going forward and ease newcomers willing to test and help :-) Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -------------- next part -------------- #FIG 3.2 Produced by xfig version 3.2.5 Landscape Center Inches Letter 100.00 Single -2 1200 2 6 6075 1125 11175 5100 2 2 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 6150 1200 8550 1200 8550 5025 6150 5025 6150 1200 2 2 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 8700 1200 11100 1200 11100 5025 8700 5025 8700 1200 2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2 6150 4425 8550 4425 2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2 8700 4425 11100 4425 2 3 0 1 0 1 50 -1 20 0.000 0 0 0 0 0 7 6780 4912 6975 4800 6975 4574 6780 4462 6585 4575 6585 4800 6780 4912 2 3 0 1 0 1 50 -1 20 0.000 0 0 0 0 0 7 9255 4912 9450 4800 9450 4574 9255 4462 9060 4575 9060 4800 9255 4912 2 4 0 2 0 7 50 -1 -1 6.000 0 0 7 0 0 5 8325 2550 8325 1425 6375 1425 6375 2550 8325 2550 2 4 0 2 0 7 50 -1 -1 6.000 0 0 7 0 0 5 8325 3900 8325 2775 6375 2775 6375 3900 8325 3900 2 4 0 2 0 7 50 -1 -1 6.000 0 0 7 0 0 5 10875 3000 10875 1875 8925 1875 8925 3000 10875 3000 4 0 0 50 -1 0 18 0.0000 4 255 1095 6825 1950 managed\001 4 0 0 50 -1 0 18 0.0000 4 195 915 6900 2250 domain\001 4 0 0 50 -1 0 18 0.0000 4 255 1095 6825 3300 managed\001 4 0 0 50 -1 0 18 0.0000 4 195 915 6900 3600 domain\001 4 0 0 50 -1 0 18 0.0000 4 255 1095 9375 2400 managed\001 4 0 0 50 -1 0 18 0.0000 4 195 915 9450 2700 domain\001 -6 2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 1050 4425 4125 4425 2 2 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 1050 1200 4125 1200 4125 5025 1050 5025 1050 1200 2 4 0 2 0 7 50 -1 -1 0.000 0 0 7 0 0 5 3975 4200 2025 4200 2025 1425 3975 1425 3975 4200 2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 1 1 6.00 60.00 120.00 2775 5925 2775 5025 2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 1 1 6.00 60.00 120.00 7275 5925 7275 5025 2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 1 1 6.00 60.00 120.00 9675 5925 9675 5025 2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 1 1 2 1 1 6.00 60.00 120.00 1 1 6.00 60.00 120.00 675 5925 11850 5925 2 4 1 1 0 7 50 -1 -1 4.000 0 0 7 0 0 5 3900 4125 3900 3150 2100 3150 2100 4125 3900 4125 2 3 0 1 0 1 50 -1 20 0.000 0 0 0 0 0 7 3420 3937 3615 3825 3615 3599 3420 3487 3225 3600 3225 3825 3420 3937 2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 3 3300 1425 3975 900 3975 525 2 1 1 2 1 7 50 -1 -1 6.000 0 0 -1 1 0 3 1 1 6.00 60.00 120.00 7425 5850 9975 5850 9975 4875 2 1 1 2 1 7 50 -1 -1 6.000 0 0 7 1 1 4 1 1 6.00 60.00 120.00 1 1 6.00 60.00 120.00 3075 4050 3075 5850 7425 5850 7425 4800 2 4 1 1 0 7 50 -1 -1 4.000 0 0 7 0 0 5 3375 3075 3375 2325 2100 2325 2100 3075 3375 3075 2 4 1 1 0 7 50 -1 -1 4.000 0 0 7 0 0 5 3825 2175 3825 1500 2700 1500 2700 2175 3825 2175 4 0 0 50 -1 0 18 0.0000 4 195 1635 1425 4725 KVM or Xen\001 4 0 0 50 -1 0 18 0.0000 4 195 810 2175 3450 DHCP\001 4 0 0 50 -1 0 18 0.0000 4 255 765 2175 3825 Image\001 4 0 0 50 -1 0 18 0.0000 4 195 690 3150 3450 TFTP\001 4 0 0 50 -1 0 26 0.0000 4 300 2490 6900 900 Cluster Nodes\001 4 0 0 50 -1 0 26 0.0000 4 300 2505 900 900 Console Node\001 4 0 0 50 -1 0 18 0.0000 4 270 1860 4125 675 WUI appliance\001 4 0 0 50 -1 0 18 0.0000 4 195 915 4125 975 domain\001 4 0 0 50 -1 0 18 0.0000 4 195 1125 2175 2625 Kerberos\001 4 0 0 50 -1 0 18 0.0000 4 195 615 2400 2925 DNS\001 4 0 0 50 -1 0 18 0.0000 4 195 900 2850 1800 WebUI\001 4 0 0 50 -1 0 18 0.0000 4 255 930 2850 2100 Apache\001 4 0 -1 50 -1 0 18 0.0000 4 255 1590 4200 1950 Management\001 4 0 -1 50 -1 0 18 0.0000 4 255 1710 4200 3600 Provisionning\001 4 0 -1 50 -1 0 18 0.0000 4 195 1830 4200 2850 Authentication\001 -------------- next part -------------- A non-text attachment was scrubbed... Name: ovirt.png Type: image/png Size: 10244 bytes Desc: not available URL: From berrange at redhat.com Fri Feb 15 14:32:29 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 15 Feb 2008 14:32:29 +0000 Subject: [Ovirt-devel] A few things (rather long actually) In-Reply-To: <20080215112625.GA18204@redhat.com> References: <20080215112625.GA18204@redhat.com> Message-ID: <20080215143229.GB15860@redhat.com> On Fri, Feb 15, 2008 at 06:26:26AM -0500, Daniel Veillard wrote: > + related to it, it's really good to have a glossary, use only the > same terms though the documentation for the same pieces of the > infrastructure. Ideally this should match libvirt terminology > (Node/Hypervisor/Domain), in the graphic I made: > - Console Node: for the physical machine running the WUI appliance That's a reasonable choice, or possibly 'Admin node'. > - Cluster Nodes: for the physical barebone machines used to run > the user domains The choice of the word 'cluster' is not good - the managed nodes can be standalone, or they can be clustered. I prefer 'Managed nodes'. > - WUI appliance: the domain running the services needed for ovirt > provisionning, authentication and management > - managed domains: for the domains the user actually want to run and > control > those terms are my pick, I find > 'oVirt host(s)' and 'oVirt management host' too similar to the point > they are confusing and not matching libvirt own terminology, sorry :-) We can add a glossary of terms to the documentation area of the website, or even better put it in the wiki so anyone can add entries for things they think need explaining. > + it's hard to see the requirement for installing my current list so > far is: > - one 64bits machine with an existing OS and KVM support to run the > WUI appliance domain, 2-3 GB available in the root user directory > (Xen based fully virt may work also with tweaking) > - at least one node for the cluster, a bare machine, able to > PXE boot (ideally otherwise booting from a CD or USB key) > 64bits with hardware virtualization support > - at least one network connecting the machines and DNS and DHCP > for that network are under the user control (this may be relaxed > in the future) > General feedback is that this is a very contraining set, which may put > many 'would be' testers off, it's really better to put those upfront > nothing is worse from their viewpoint than spending time for nothing, > on the other hand being explicit may get some of them in an helping mood > since we generally want to remove/ease a lot of those requirements. I've expanded the detail in the FAQ to give much more info about the requirements for deployment - can you take a look at it on the website now. I think it covers the points you raise here. > - Building the appliance from a kickstart is actually hard to set up, > do not suggest it as a way to avoid the time of the download > "Booting and provisioning a host or a VM with a kickstart is left > as an exercise for the reader." > is condescending, actually very hard, get rid of the section, assume > user will follow the standard track (download + using KVM), but document > separately the process for rebuilding the appliance, and changes needed > to run it as a Xen fully-virt domain (I assume only the xml and way to > launch the applicance need changes) I'd like to get to a place where building an either the wui appliance, or the managed host appliance consists of nothing more than invoking the Fedora livecd-creator tool. There is some work going on to make the livecd-creator more general purpose, so I think this is doable in the the Fedora 9 timescale. Just a reminder to anyone with suggestions - the wiki is available for any adhoc content you think will be useful to others... Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From berrange at redhat.com Fri Feb 15 15:02:45 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 15 Feb 2008 15:02:45 +0000 Subject: [Ovirt-devel] Some architecture diagrams Message-ID: <20080215150245.GD15860@redhat.com> Attached are a couple of diagrams we're thinking about adding to the website to show the logical & physical architecture of oVirt. Yes, they're missing iSCSI storage server, but that's a simple addition. Comments... ? Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -------------- next part -------------- A non-text attachment was scrubbed... Name: physical_arch.gif Type: image/gif Size: 15369 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logical_arch.gif Type: image/gif Size: 17019 bytes Desc: not available URL: From rjones at redhat.com Fri Feb 15 15:15:46 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 15 Feb 2008 15:15:46 +0000 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <20080215150245.GD15860@redhat.com> References: <20080215150245.GD15860@redhat.com> Message-ID: <47B5ACA2.3070607@redhat.com> Daniel P. Berrange wrote: > Attached are a couple of diagrams we're thinking about adding to the website > to show the logical & physical architecture of oVirt. Yes, they're missing > iSCSI storage server, but that's a simple addition. Comments... ? It's not clear from the diagram that (a) the FreeIPA server must be a separate guest (or separate machine) and (b) it needs to have a steady IP address and be available to other machines on the network. In particular requirement (b) tends to rule out using qemu or KVM (for me, because I've never really worked out how to get user networking to have an IP address which isn't on the private 192.168.122.* network). I'm unclear on why FreeIPA needs to be its own machine though. Can we not set it up so it uses just its own port number by default? Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From berrange at redhat.com Fri Feb 15 15:23:59 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 15 Feb 2008 15:23:59 +0000 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <47B5ACA2.3070607@redhat.com> References: <20080215150245.GD15860@redhat.com> <47B5ACA2.3070607@redhat.com> Message-ID: <20080215152359.GF15860@redhat.com> On Fri, Feb 15, 2008 at 03:15:46PM +0000, Richard W.M. Jones wrote: > Daniel P. Berrange wrote: > >Attached are a couple of diagrams we're thinking about adding to the > >website > >to show the logical & physical architecture of oVirt. Yes, they're missing > >iSCSI storage server, but that's a simple addition. Comments... ? > > It's not clear from the diagram that (a) the FreeIPA server must be a > separate guest (or separate machine) and (b) it needs to have a steady > IP address and be available to other machines on the network. In > particular requirement (b) tends to rule out using qemu or KVM (for me, > because I've never really worked out how to get user networking to have > an IP address which isn't on the private 192.168.122.* network). You ned to bridge the KVM guest to the real LAN, rather than using the virtual networking. Option 2, in this doc: http://www.watzmann.net/blog/index.php/2007/04/27/networking_with_kvm_and_libvirt Then you're guests just talk to the real LAN dhcp server where you can assign permanent addresses. In terms of separate guest / machine for FreeIPA, this is really a deployment choice. I think it'll be most trouble-free if you keep FreeIPA and the oVirt WUI in separate virtual machines. I should be possible to run them in the same VM with suitably clever Apache config, but unless you're really familiar with this I think it'll cause more development pain. The physical diagram is intended to show the minimal recommended dev setup - 2 physical machines. 1 for running guests, and 1 for running the admin console & associated services like FreIPA, iSCSI, DHCP, DHNS. We need a second version of the physical diagram to show a 'production' level setup, with multiple managed nodes for running guests, and each of oVirt WUI, FreeIPA, iSCSI running on separate hosts. > I'm unclear on why FreeIPA needs to be its own machine though. Can we > not set it up so it uses just its own port number by default? In theory yes, but we were having some trouble with mod_kerberos wrt to the service principles. I think its doable, but we need to spend more time poking the apache configs. Dan -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From veillard at redhat.com Fri Feb 15 15:29:14 2008 From: veillard at redhat.com (Daniel Veillard) Date: Fri, 15 Feb 2008 10:29:14 -0500 Subject: [Ovirt-devel] A few things (rather long actually) In-Reply-To: <20080215143229.GB15860@redhat.com> References: <20080215112625.GA18204@redhat.com> <20080215143229.GB15860@redhat.com> Message-ID: <20080215152914.GD20281@redhat.com> On Fri, Feb 15, 2008 at 02:32:29PM +0000, Daniel P. Berrange wrote: > On Fri, Feb 15, 2008 at 06:26:26AM -0500, Daniel Veillard wrote: > > + related to it, it's really good to have a glossary, use only the > > same terms though the documentation for the same pieces of the > > infrastructure. Ideally this should match libvirt terminology > > (Node/Hypervisor/Domain), in the graphic I made: > > - Console Node: for the physical machine running the WUI appliance > > That's a reasonable choice, or possibly 'Admin node'. > > > - Cluster Nodes: for the physical barebone machines used to run > > the user domains > > The choice of the word 'cluster' is not good - the managed nodes can > be standalone, or they can be clustered. I prefer 'Managed nodes'. Fine by me, just use Node to indicate a physical machine like in libvirt. > > - WUI appliance: the domain running the services needed for ovirt > > provisionning, authentication and management > > - managed domains: for the domains the user actually want to run and > > control > > those terms are my pick, I find > > 'oVirt host(s)' and 'oVirt management host' too similar to the point > > they are confusing and not matching libvirt own terminology, sorry :-) > > We can add a glossary of terms to the documentation area of the website, > or even better put it in the wiki so anyone can add entries for things > they think need explaining. hum, maybe the core terms should really go in the doc, actually close to the architecture diagram would be best i think. > > + it's hard to see the requirement for installing my current list so > > far is: > > - one 64bits machine with an existing OS and KVM support to run the > > WUI appliance domain, 2-3 GB available in the root user directory > > (Xen based fully virt may work also with tweaking) > > - at least one node for the cluster, a bare machine, able to > > PXE boot (ideally otherwise booting from a CD or USB key) > > 64bits with hardware virtualization support > > - at least one network connecting the machines and DNS and DHCP > > for that network are under the user control (this may be relaxed > > in the future) > > General feedback is that this is a very contraining set, which may put > > many 'would be' testers off, it's really better to put those upfront > > nothing is worse from their viewpoint than spending time for nothing, > > on the other hand being explicit may get some of them in an helping mood > > since we generally want to remove/ease a lot of those requirements. > > I've expanded the detail in the FAQ to give much more info about the > requirements for deployment - can you take a look at it on the website > now. I think it covers the points you raise here. amount of disk on the root user, and memeory required by the appliance VM could be added. I'm not sure this really pertains only to the FAQ, but at the beginning of the installation informations. > > - Building the appliance from a kickstart is actually hard to set up, > > do not suggest it as a way to avoid the time of the download > > "Booting and provisioning a host or a VM with a kickstart is left > > as an exercise for the reader." > > is condescending, actually very hard, get rid of the section, assume > > user will follow the standard track (download + using KVM), but document > > separately the process for rebuilding the appliance, and changes needed > > to run it as a Xen fully-virt domain (I assume only the xml and way to > > launch the applicance need changes) > > I'd like to get to a place where building an either the wui appliance, > or the managed host appliance consists of nothing more than invoking the > Fedora livecd-creator tool. There is some work going on to make the > livecd-creator more general purpose, so I think this is doable in the > the Fedora 9 timescale. when it will be easy with standard tools, sure, indicate so, but at the moment this is rather misleading > > Just a reminder to anyone with suggestions - the wiki is available for any > adhoc content you think will be useful to others... Hum, but a Wiki does not replace a complete and clear documentation ;-) Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard at redhat.com Fri Feb 15 15:32:06 2008 From: veillard at redhat.com (Daniel Veillard) Date: Fri, 15 Feb 2008 10:32:06 -0500 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <20080215150245.GD15860@redhat.com> References: <20080215150245.GD15860@redhat.com> Message-ID: <20080215153206.GE20281@redhat.com> On Fri, Feb 15, 2008 at 03:02:45PM +0000, Daniel P. Berrange wrote: > Attached are a couple of diagrams we're thinking about adding to the website > to show the logical & physical architecture of oVirt. Yes, they're missing > iSCSI storage server, but that's a simple addition. Comments... ? Hum, the first one makes my head spin. And I really think my suggestion gives a better overview of the various parts and what they are used for. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From rjones at redhat.com Fri Feb 15 15:34:39 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 15 Feb 2008 15:34:39 +0000 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <20080215152359.GF15860@redhat.com> References: <20080215150245.GD15860@redhat.com> <47B5ACA2.3070607@redhat.com> <20080215152359.GF15860@redhat.com> Message-ID: <47B5B10F.2010103@redhat.com> Daniel P. Berrange wrote: > In terms of separate guest / machine for FreeIPA, this is really a deployment > choice. I think it'll be most trouble-free if you keep FreeIPA and the oVirt > WUI in separate virtual machines. I should be possible to run them in the > same VM with suitably clever Apache config, but unless you're really familiar > with this I think it'll cause more development pain. But think about this in terms of "I'm just an ordinary sysadmin who wants to test out ovirt". They've got past the screenshots and text on the website and want to get to the next step. Two questions: (1) Can we make it so 'yum install ovirt' on an existing Fedora machine pulls down enough software so that ovirt WUI can start up? (2) Are the managed hosts and iSCSI servers _really_ necessary? Question (1) => we could make package ovirt depend on the parts of FreeIPA necessary (ipa-server & ipa-client I think). _If_ we can persuade FreeIPA to be a good citizen and not require its own server. Question (2) => we shouldn't need any managed hosts or other servers, just to start up the WUI. Obviously it won't be very functional, but it should at least start up. > In theory yes, but we were having some trouble with mod_kerberos wrt to > the service principles. I think its doable, but we need to spend more > time poking the apache configs. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From mdehaan at redhat.com Fri Feb 15 15:28:00 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 15 Feb 2008 10:28:00 -0500 Subject: [Ovirt-devel] Re: ovirt integration w/ cobbler In-Reply-To: <20080214225822.GP6826@redhat.com> References: <47B1C8DA.2000501@redhat.com> <20080212163809.GD6534@redhat.com> <47B1CF81.9070903@redhat.com> <20080214225822.GP6826@redhat.com> Message-ID: <47B5AF80.2040107@redhat.com> Daniel P. Berrange wrote: > On Tue, Feb 12, 2008 at 11:55:29AM -0500, Michael DeHaan wrote: > >> It doesn't do ISOs yet, but that's something that could be added. >> >> It would require some minor cobbler/koan changes. If someone is >> interested in working with me on that, that's great... >> if not, if I can better understand the requirements it should not be >> that complex to add myself. >> >> Basically I'm guessing you want to either do: >> (a) fullvirt provisioning where there is no PXE server, and you can't >> do kernel+initrd installs like koan does now (like Xen FV works on F8) >> (b) non-Linux installs (make koan deploy an arbitrary OS) >> > > Yep, we've got 2 core use cases: > > - Deploying the 'managed host' images. This is a pre-built minimal > Fedora image essentially onl running libvirt. The idea being you > turn on a physical host, it PXE's this image and joins itself to > the oVirt management server and can now have guests deployed on it > We can build images such that they have a kernel+initrd if needed. > Neat! > - Deploying the guest OS'. This can be any OS, be it Linux, Windows > BSD, Solaris, etc. Obviously Fedora / RHEL are trivial since we > can always do kernel+initrd from the main distro trees. > > >> One thing that might also be interesting for ovirt is the koan live CD >> ... basically it allows you to insert a CD/USB-image into any baremetal >> machine, >> boot it, and it will install to whatever cobbler profile you want... >> this can be either a preset profile, e.g. "foo", or can be detected >> based on the MAC >> address. This could be any distro as well, so a F8/F9 based installer >> image could install EL4. Kinda neat if you need to add new machines >> to your "cloud" and ovirt isn't the "official" provisioning server. >> > > That sounds like a nice idea for places where we can't directly use PXE. > > >> The APIs are pretty solid at this point -- Virt-Factory was using them, >> Cobbler's web UI is using them now, and I can add anything that isn't there. >> Auth is also pluggable now so we can write a module to use whatever >> authentication system ovirt might be using. >> > > Are there any docs on the APIs available for controlling Cobbler ? > https://fedorahosted.org/cobbler/wiki/CobblerXmlrpc see also remote.py in the source tree for exposed methods plus the WebUI source for further examples. (the Cobbler WebUI isn't that complicated -- basically just one python file -- ./cobbler/webui/CobblerWeb.py) Virt-Factory just used cobbler's Python API directly -- which is a bit cleaner than going the XMLRPC route -- though the XMLRPC API is not too bad either. > For authentication we're basically Kerberos enabled throughout. All the > services and users have kerberos tickets / principals. If the Cobbler > APIs can be setup to go via Apache's mod_kerb that should do the trick > quite nicely. At worse we can copy the FreeIPA approach of having Apache > do the auth and then proxypass the request through to Cobbler which can > read the authenticated username from the HTTP request. > Cobbler's authn system is pluggable, so technically you can swap out the default digest file implementation for something else (/etc/cobbler/modules.conf). The existing kerberos stuff (off by default) in there for Cobbler is not very good or finished (definitely it's "fake kerberos"), so it would probably need to be redone. By default we use the Apache auth handlers to just send the username/password back down to cobblerd, where it is checked there (communicating with cobblerd) to return pass/fail. The FreeIPA style hack you mention with mod_kerb may work.... I'll look into how (if?) we can get at those headers from Python's XMLRPC server. From berrange at redhat.com Fri Feb 15 15:40:08 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 15 Feb 2008 15:40:08 +0000 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <47B5B10F.2010103@redhat.com> References: <20080215150245.GD15860@redhat.com> <47B5ACA2.3070607@redhat.com> <20080215152359.GF15860@redhat.com> <47B5B10F.2010103@redhat.com> Message-ID: <20080215154008.GG15860@redhat.com> On Fri, Feb 15, 2008 at 03:34:39PM +0000, Richard W.M. Jones wrote: > Daniel P. Berrange wrote: > >In terms of separate guest / machine for FreeIPA, this is really a > >deployment > >choice. I think it'll be most trouble-free if you keep FreeIPA and the > >oVirt > >WUI in separate virtual machines. I should be possible to run them in the > >same VM with suitably clever Apache config, but unless you're really > >familiar > >with this I think it'll cause more development pain. > > But think about this in terms of "I'm just an ordinary sysadmin who > wants to test out ovirt". They've got past the screenshots and text on > the website and want to get to the next step. > > Two questions: > > (1) Can we make it so 'yum install ovirt' on an existing Fedora machine > pulls down enough software so that ovirt WUI can start up? Probably can for F9 - FreeIPA rpms should be going into F9. We can add ovirt RPMs to F9 too, so the whole thing should be yum installable. Would need to document / provide a setup script for the post-install config steps - eg the postgresql database. > (2) Are the managed hosts and iSCSI servers _really_ necessary? Only if you want something to manage. In theory the oVirt WUI ought to be able to manage any machine running libvirtd. Only hard part would be if the machine in question already had guests running - we'd need to make sure oVirt could 'import' them to its world view in some sensible way. > Question (1) => we could make package ovirt depend on the parts of > FreeIPA necessary (ipa-server & ipa-client I think). _If_ we can > persuade FreeIPA to be a good citizen and not require its own server. Yes, i'd be good to have a vhost config file you can drop into the /etc/httpd/config.d that would play nicely with the world - eg have everything under /freeipa instead of taking over the entire apache server namespace. > Question (2) => we shouldn't need any managed hosts or other servers, > just to start up the WUI. Obviously it won't be very functional, but it > should at least start up. Sure, it'll start up just fine. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From sseago at redhat.com Fri Feb 15 15:53:08 2008 From: sseago at redhat.com (Scott Seago) Date: Fri, 15 Feb 2008 10:53:08 -0500 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <20080215154008.GG15860@redhat.com> References: <20080215150245.GD15860@redhat.com> <47B5ACA2.3070607@redhat.com> <20080215152359.GF15860@redhat.com> <47B5B10F.2010103@redhat.com> <20080215154008.GG15860@redhat.com> Message-ID: <47B5B564.6090402@redhat.com> Daniel P. Berrange wrote: > >> Two questions: >> >> (1) Can we make it so 'yum install ovirt' on an existing Fedora machine >> pulls down enough software so that ovirt WUI can start up? >> > > Probably can for F9 - FreeIPA rpms should be going into F9. We can add > ovirt RPMs to F9 too, so the whole thing should be yum installable. > Would need to document / provide a setup script for the post-install > config steps - eg the postgresql database. > > Although if we go ahead with providing the auth and permissions disabled mode, we wouldn't want FreeIPA to be a package dependency -- on top of that we wouldn't want to depend on that at the package level since FreeIPA would still be on a different guest/host in some instances. However, this non-security mode will make the 'yum install ovirt' case even easier than FreeIPA RPMs since all you'd need to do to run the WUI is to disable the kerberos auth and set the "turn security off" config param (and the standard db setup, etc. of course). Scott From hbrock at redhat.com Fri Feb 15 16:00:08 2008 From: hbrock at redhat.com (Hugh O. Brock) Date: Fri, 15 Feb 2008 11:00:08 -0500 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <20080215154008.GG15860@redhat.com> References: <20080215150245.GD15860@redhat.com> <47B5ACA2.3070607@redhat.com> <20080215152359.GF15860@redhat.com> <47B5B10F.2010103@redhat.com> <20080215154008.GG15860@redhat.com> Message-ID: <20080215160007.GV15422@redhat.com> On Fri, Feb 15, 2008 at 03:40:08PM +0000, Daniel P. Berrange wrote: > On Fri, Feb 15, 2008 at 03:34:39PM +0000, Richard W.M. Jones wrote: > > Two questions: > > > > (1) Can we make it so 'yum install ovirt' on an existing Fedora machine > > pulls down enough software so that ovirt WUI can start up? > > Probably can for F9 - FreeIPA rpms should be going into F9. We can add > ovirt RPMs to F9 too, so the whole thing should be yum installable. > Would need to document / provide a setup script for the post-install > config steps - eg the postgresql database. We already have a setup script for the appliance that does this, so not a big deal. One other thing we should do to make the oVirt WUI play nicely I think (we talked about this some yesterday) is mount the whole thing under a top-level URL servlet-style -- so http://example.com/ovirt or something. Then we don't necessarily care who else is using Apache or for what purpose, provided of course they don't already have something proxied at /ovirt, which I think is a reasonable requirement. I think the first thing we need to do to make things easier is what Scott is already working on, namely make it possible to run the WUI and its supporting workers without a kerberos server at all. This will for the moment free developers from having to worry about FreeIPA or any network configuration at all, really. > > (2) Are the managed hosts and iSCSI servers _really_ necessary? > > Only if you want something to manage. In theory the oVirt WUI ought to be > able to manage any machine running libvirtd. Only hard part would be if > the machine in question already had guests running - we'd need to make > sure oVirt could 'import' them to its world view in some sensible way. We should point out in the documentation that the oVirt host image is stateless -- i.e. if you boot a machine with it it's not going to touch the disk on that machine. This makes borrowing a machine to use as a managed node much less painful. We depend on more than just libvirtd being on the managed node -- we also use mDNS to advertise the existence of the host to the admin node, and collectd to forward stats to it. On the other hand if we really wanted to we could provide a way to look for a host running libvirt at a particular IP, and if found manage that host. I suppose that makes the admin node more useful for the general case, but I'm not sure how high a priority we should make it. > > Question (2) => we shouldn't need any managed hosts or other servers, > > just to start up the WUI. Obviously it won't be very functional, but it > > should at least start up. > > Sure, it'll start up just fine. Well, once we remove the Kerberos requirement, it'll start up just fine . But that is on the way. Take care, --Hugh > _______________________________________________ > Ovirt-devel mailing list > Ovirt-devel at redhat.com > https://www.redhat.com/mailman/listinfo/ovirt-devel From ssorce at redhat.com Fri Feb 15 16:34:16 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 15 Feb 2008 11:34:16 -0500 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <20080215154008.GG15860@redhat.com> References: <20080215150245.GD15860@redhat.com> <47B5ACA2.3070607@redhat.com> <20080215152359.GF15860@redhat.com> <47B5B10F.2010103@redhat.com> <20080215154008.GG15860@redhat.com> Message-ID: <1203093256.15201.7.camel@localhost.localdomain> On Fri, 2008-02-15 at 15:40 +0000, Daniel P. Berrange wrote: > On Fri, Feb 15, 2008 at 03:34:39PM +0000, Richard W.M. Jones wrote: > > > Question (1) => we could make package ovirt depend on the parts of > > FreeIPA necessary (ipa-server & ipa-client I think). _If_ we can > > persuade FreeIPA to be a good citizen and not require its own server. > > Yes, i'd be good to have a vhost config file you can drop into the > /etc/httpd/config.d that would play nicely with the world - eg have > everything under /freeipa instead of taking over the entire apache > server namespace. Patches welcome :-) Btw while I am reading this list, we are planning on using something like rmanager to handle the FreeIPA components so that if one piece goes down it is either restarted or all the (interdependent) pieces go down. Would this cause any problem to ovirt ? However to answer Richard question, FreeIPA itself does not require to be the only thing running on the server (modulo the mentioned apache configuration problem that can be probably solved). But given its nature it is better, for security reasons, if it is. After all it contains all the Keys to the REALM :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From berrange at redhat.com Fri Feb 15 16:41:44 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 15 Feb 2008 16:41:44 +0000 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <1203093256.15201.7.camel@localhost.localdomain> References: <20080215150245.GD15860@redhat.com> <47B5ACA2.3070607@redhat.com> <20080215152359.GF15860@redhat.com> <47B5B10F.2010103@redhat.com> <20080215154008.GG15860@redhat.com> <1203093256.15201.7.camel@localhost.localdomain> Message-ID: <20080215164144.GC4588@redhat.com> On Fri, Feb 15, 2008 at 11:34:16AM -0500, Simo Sorce wrote: > > On Fri, 2008-02-15 at 15:40 +0000, Daniel P. Berrange wrote: > > On Fri, Feb 15, 2008 at 03:34:39PM +0000, Richard W.M. Jones wrote: > > > > > Question (1) => we could make package ovirt depend on the parts of > > > FreeIPA necessary (ipa-server & ipa-client I think). _If_ we can > > > persuade FreeIPA to be a good citizen and not require its own server. > > > > Yes, i'd be good to have a vhost config file you can drop into the > > /etc/httpd/config.d that would play nicely with the world - eg have > > everything under /freeipa instead of taking over the entire apache > > server namespace. > > Patches welcome :-) > > Btw while I am reading this list, we are planning on using something > like rmanager to handle the FreeIPA components so that if one piece goes > down it is either restarted or all the (interdependent) pieces go down. To be honest, that sounds like something that is more OS / integration policy rather than something which should be a fundamental part of the FreeIPA app. > However to answer Richard question, FreeIPA itself does not require to > be the only thing running on the server (modulo the mentioned apache > configuration problem that can be probably solved). > But given its nature it is better, for security reasons, if it is. After > all it contains all the Keys to the REALM :-) Yep, we're mainly wanting to do the shared apache server for purposes of development to reduce the number of machines required for developers. Obviously a production deployment would take FreeIPA sercurity much more seriously and use a separate machine. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From ssorce at redhat.com Fri Feb 15 17:43:56 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 15 Feb 2008 12:43:56 -0500 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <20080215164144.GC4588@redhat.com> References: <20080215150245.GD15860@redhat.com> <47B5ACA2.3070607@redhat.com> <20080215152359.GF15860@redhat.com> <47B5B10F.2010103@redhat.com> <20080215154008.GG15860@redhat.com> <1203093256.15201.7.camel@localhost.localdomain> <20080215164144.GC4588@redhat.com> Message-ID: <1203097436.15201.13.camel@localhost.localdomain> On Fri, 2008-02-15 at 16:41 +0000, Daniel P. Berrange wrote: > On Fri, Feb 15, 2008 at 11:34:16AM -0500, Simo Sorce wrote: > > > > On Fri, 2008-02-15 at 15:40 +0000, Daniel P. Berrange wrote: > > > On Fri, Feb 15, 2008 at 03:34:39PM +0000, Richard W.M. Jones wrote: > > > > > > > Question (1) => we could make package ovirt depend on the parts of > > > > FreeIPA necessary (ipa-server & ipa-client I think). _If_ we can > > > > persuade FreeIPA to be a good citizen and not require its own server. > > > > > > Yes, i'd be good to have a vhost config file you can drop into the > > > /etc/httpd/config.d that would play nicely with the world - eg have > > > everything under /freeipa instead of taking over the entire apache > > > server namespace. > > > > Patches welcome :-) > > > > Btw while I am reading this list, we are planning on using something > > like rmanager to handle the FreeIPA components so that if one piece goes > > down it is either restarted or all the (interdependent) pieces go down. > > To be honest, that sounds like something that is more OS / integration > policy rather than something which should be a fundamental part of > the FreeIPA app. The problem is that if FDS dies but the KDC is up bad things happen. In a multimaster environment with multiple FreeIPA servers for redundancy you really want to take a server down completely if one of the pieces misbehave. That's why I think this should be part of IPA, it's for reliability, as it is a core network service that can break all the client if it misbehave badly. For example if FDS is down but the KDC is up, any client using that KDC would get the bad surprise of getting all ticket request denied. > > However to answer Richard question, FreeIPA itself does not require to > > be the only thing running on the server (modulo the mentioned apache > > configuration problem that can be probably solved). > > But given its nature it is better, for security reasons, if it is. After > > all it contains all the Keys to the REALM :-) > > Yep, we're mainly wanting to do the shared apache server for purposes of > development to reduce the number of machines required for developers. > Obviously a production deployment would take FreeIPA sercurity much > more seriously and use a separate machine. Yeah the only concern is making sure that the service then works correctly even if it is on another machine. Its easy to take shortcuts, or not notice network related effects when all is on the same machine, but I see the value in that, so if you have specific requests to accomodate the apache conf let us know. Simo. -- Simo Sorce * Red Hat, Inc * New York From hbrock at redhat.com Fri Feb 15 17:49:48 2008 From: hbrock at redhat.com (Hugh O. Brock) Date: Fri, 15 Feb 2008 12:49:48 -0500 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <1203097436.15201.13.camel@localhost.localdomain> References: <20080215150245.GD15860@redhat.com> <47B5ACA2.3070607@redhat.com> <20080215152359.GF15860@redhat.com> <47B5B10F.2010103@redhat.com> <20080215154008.GG15860@redhat.com> <1203093256.15201.7.camel@localhost.localdomain> <20080215164144.GC4588@redhat.com> <1203097436.15201.13.camel@localhost.localdomain> Message-ID: <20080215174948.GX15422@redhat.com> On Fri, Feb 15, 2008 at 12:43:56PM -0500, Simo Sorce wrote: > > On Fri, 2008-02-15 at 16:41 +0000, Daniel P. Berrange wrote: > > > > Yep, we're mainly wanting to do the shared apache server for purposes of > > development to reduce the number of machines required for developers. > > Obviously a production deployment would take FreeIPA sercurity much > > more seriously and use a separate machine. > > Yeah the only concern is making sure that the service then works > correctly even if it is on another machine. Its easy to take shortcuts, > or not notice network related effects when all is on the same machine, > but I see the value in that, so if you have specific requests to > accomodate the apache conf let us know. > > Simo. I suppose the obvious thing would be to consider rooting the FreeIPA pages one level down the URL tree (maybe as a config option even) -- so that e.g. if FreeIPA was running in a shared Apache, you would always browse to http://example.com/freeipa. Then other packages on the same Apache don't have to worry about invading freeipa's URL space. We thought about using name-based vhosting to do this but it doesn't play nicely with kerberos, of course... Thanks, --Hugh From ssorce at redhat.com Fri Feb 15 17:56:41 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 15 Feb 2008 12:56:41 -0500 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <20080215174948.GX15422@redhat.com> References: <20080215150245.GD15860@redhat.com> <47B5ACA2.3070607@redhat.com> <20080215152359.GF15860@redhat.com> <47B5B10F.2010103@redhat.com> <20080215154008.GG15860@redhat.com> <1203093256.15201.7.camel@localhost.localdomain> <20080215164144.GC4588@redhat.com> <1203097436.15201.13.camel@localhost.localdomain> <20080215174948.GX15422@redhat.com> Message-ID: <1203098201.15201.18.camel@localhost.localdomain> On Fri, 2008-02-15 at 12:49 -0500, Hugh O. Brock wrote: > > We thought about using name-based vhosting to do this but it doesn't > play nicely with kerberos, of course... Nor with SSL, actually kerberos can probably be made to work anyway if you use CNAMEs and A names the right way, the real problem is SSL. So I guess we need to try to move all under /ipa, will se if we can do this easily, but it may be too late for 1.0 Simo. -- Simo Sorce * Red Hat, Inc * New York From hbrock at redhat.com Fri Feb 15 18:03:28 2008 From: hbrock at redhat.com (Hugh O. Brock) Date: Fri, 15 Feb 2008 13:03:28 -0500 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <1203098201.15201.18.camel@localhost.localdomain> References: <20080215150245.GD15860@redhat.com> <47B5ACA2.3070607@redhat.com> <20080215152359.GF15860@redhat.com> <47B5B10F.2010103@redhat.com> <20080215154008.GG15860@redhat.com> <1203093256.15201.7.camel@localhost.localdomain> <20080215164144.GC4588@redhat.com> <1203097436.15201.13.camel@localhost.localdomain> <20080215174948.GX15422@redhat.com> <1203098201.15201.18.camel@localhost.localdomain> Message-ID: <20080215180328.GY15422@redhat.com> On Fri, Feb 15, 2008 at 12:56:41PM -0500, Simo Sorce wrote: > > On Fri, 2008-02-15 at 12:49 -0500, Hugh O. Brock wrote: > > > > We thought about using name-based vhosting to do this but it doesn't > > play nicely with kerberos, of course... > > Nor with SSL, actually kerberos can probably be made to work anyway if > you use CNAMEs and A names the right way, the real problem is SSL. > > So I guess we need to try to move all under /ipa, will se if we can do > this easily, but it may be too late for 1.0 > Yes, that's right, SSL is also going to be an issue. Didn't think of using CNAMEs, that might indeed fix the vhost issue... Anyway, thanks, let us know what you come up with, --Hugh From berrange at redhat.com Sun Feb 17 02:18:11 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Sun, 17 Feb 2008 02:18:11 +0000 Subject: [Ovirt-devel] [FW: [Fedora-livecd-list] PATCH: Disk (appliance) creator tool] Message-ID: <20080217021811.GI24669@redhat.com> FYI, see attached mail for details of some changes to livecd tools to allow creation of the fully-partitioned & ready-to-run appliance straight from a kickstart file. Tested with the ovirt WUI appliance & it works very nicely indeed. It reduces the instructions for building the WUI appliance to merely be: # disk-creator wui-appliance.ks Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -------------- next part -------------- An embedded message was scrubbed... From: "Daniel P. Berrange" Subject: [Fedora-livecd-list] PATCH: Disk (appliance) creator tool Date: Sun, 17 Feb 2008 02:14:43 +0000 Size: 45882 URL: From hbrock at redhat.com Mon Feb 18 13:01:32 2008 From: hbrock at redhat.com (Hugh O. Brock) Date: Mon, 18 Feb 2008 08:01:32 -0500 Subject: [Ovirt-devel] [FW: [Fedora-livecd-list] PATCH: Disk (appliance) creator tool] In-Reply-To: <20080217021811.GI24669@redhat.com> References: <20080217021811.GI24669@redhat.com> Message-ID: <20080218130127.GA31337@redhat.com> On Sun, Feb 17, 2008 at 02:18:11AM +0000, Daniel P. Berrange wrote: > FYI, see attached mail for details of some changes to livecd tools to > allow creation of the fully-partitioned & ready-to-run appliance straight > from a kickstart file. Tested with the ovirt WUI appliance & it works > very nicely indeed. It reduces the instructions for building the WUI > appliance to merely be: > > # disk-creator wui-appliance.ks > Nifty! In what package does one find disk-creator? I will update the docs accordingly. --H From berrange at redhat.com Mon Feb 18 14:28:08 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 18 Feb 2008 14:28:08 +0000 Subject: [Ovirt-devel] [FW: [Fedora-livecd-list] PATCH: Disk (appliance) creator tool] In-Reply-To: <20080218130127.GA31337@redhat.com> References: <20080217021811.GI24669@redhat.com> <20080218130127.GA31337@redhat.com> Message-ID: <20080218142808.GA30725@redhat.com> On Mon, Feb 18, 2008 at 08:01:32AM -0500, Hugh O. Brock wrote: > On Sun, Feb 17, 2008 at 02:18:11AM +0000, Daniel P. Berrange wrote: > > FYI, see attached mail for details of some changes to livecd tools to > > allow creation of the fully-partitioned & ready-to-run appliance straight > > from a kickstart file. Tested with the ovirt WUI appliance & it works > > very nicely indeed. It reduces the instructions for building the WUI > > appliance to merely be: > > > > # disk-creator wui-appliance.ks > > > Nifty! In what package does one find disk-creator? I will update the > docs accordingly. None yet - its just a bunch of patches. Eventually something like it will hopefully get into livecd-tools, but its premature to update the docs yet. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From mlanglie at redhat.com Tue Feb 19 14:19:20 2008 From: mlanglie at redhat.com (Mike Langlie) Date: Tue, 19 Feb 2008 09:19:20 -0500 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <47BAE296.6060302@redhat.com> References: <47BAE296.6060302@redhat.com> Message-ID: <47BAE568.9050207@redhat.com> > On Fri, Feb 15, 2008 at 03:02:45PM +0000, Daniel P. Berrange wrote: >> Attached are a couple of diagrams we're thinking about adding to the >> website >> to show the logical & physical architecture of oVirt. Yes, they're >> missing >> iSCSI storage server, but that's a simple addition. Comments... ? > > Hum, the first one makes my head spin. > And I really think my suggestion gives a better overview of the various > parts and what they are used for. > > Daniel > Hi Daniel, How about this version of your diagram? Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: diagram3.png Type: image/png Size: 25574 bytes Desc: not available URL: From hbrock at redhat.com Tue Feb 19 14:35:49 2008 From: hbrock at redhat.com (Hugh O. Brock) Date: Tue, 19 Feb 2008 09:35:49 -0500 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <47BAE568.9050207@redhat.com> References: <47BAE296.6060302@redhat.com> <47BAE568.9050207@redhat.com> Message-ID: <20080219143533.GA32262@redhat.com> On Tue, Feb 19, 2008 at 09:19:20AM -0500, Mike Langlie wrote: > > Hi Daniel, > > How about this version of your diagram? > > Mike > That's prettier but I don't know what the blue hexagon is? Also, yeah, we need to show the storage server... --H > _______________________________________________ > Ovirt-devel mailing list > Ovirt-devel at redhat.com > https://www.redhat.com/mailman/listinfo/ovirt-devel From berrange at redhat.com Tue Feb 19 14:39:02 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 19 Feb 2008 14:39:02 +0000 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <47BAE568.9050207@redhat.com> References: <47BAE296.6060302@redhat.com> <47BAE568.9050207@redhat.com> Message-ID: <20080219143902.GA17472@redhat.com> On Tue, Feb 19, 2008 at 09:19:20AM -0500, Mike Langlie wrote: > > >On Fri, Feb 15, 2008 at 03:02:45PM +0000, Daniel P. Berrange wrote: > >>Attached are a couple of diagrams we're thinking about adding to the > >>website > >>to show the logical & physical architecture of oVirt. Yes, they're > >>missing > >>iSCSI storage server, but that's a simple addition. Comments... ? > > > > Hum, the first one makes my head spin. > >And I really think my suggestion gives a better overview of the various > >parts and what they are used for. > > > >Daniel > > > > Hi Daniel, > > How about this version of your diagram? We need to use the terms 'Admin node' and 'Managed nodes' at the top of the diagram. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From mlanglie at redhat.com Tue Feb 19 14:44:53 2008 From: mlanglie at redhat.com (Mike Langlie) Date: Tue, 19 Feb 2008 09:44:53 -0500 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <20080219143902.GA17472@redhat.com> References: <47BAE296.6060302@redhat.com> <47BAE568.9050207@redhat.com> <20080219143902.GA17472@redhat.com> Message-ID: <47BAEB65.8040302@redhat.com> Daniel P. Berrange wrote: > We need to use the terms 'Admin node' and 'Managed nodes' at the top > of the diagram. > Daniel: In place of "Console / Cluster Nodes"? Hugh O. Brock wrote: > That's prettier but I don't know what the blue hexagon is? Also, yeah, > we need to show the storage server... > Hugh: Should Storage Server be another box within Console Node (Admin Node)? How would you word it? Blue hexagons are our secret ingredient! Mike From berrange at redhat.com Tue Feb 19 14:49:37 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 19 Feb 2008 14:49:37 +0000 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <47BAEB65.8040302@redhat.com> References: <47BAE296.6060302@redhat.com> <47BAE568.9050207@redhat.com> <20080219143902.GA17472@redhat.com> <47BAEB65.8040302@redhat.com> Message-ID: <20080219144937.GB17472@redhat.com> On Tue, Feb 19, 2008 at 09:44:53AM -0500, Mike Langlie wrote: > Daniel P. Berrange wrote: > >We need to use the terms 'Admin node' and 'Managed nodes' at the top > >of the diagram. > > > > Daniel: In place of "Console / Cluster Nodes"? Yes, that's correct. > Hugh: Should Storage Server be another box within Console Node (Admin > Node)? How would you word it? I'd have the storage separate main box - 'Storage node' and inside the box have 'iSCSI server' Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From veillard at redhat.com Tue Feb 19 15:09:46 2008 From: veillard at redhat.com (Daniel Veillard) Date: Tue, 19 Feb 2008 10:09:46 -0500 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <20080219143533.GA32262@redhat.com> References: <47BAE296.6060302@redhat.com> <47BAE568.9050207@redhat.com> <20080219143533.GA32262@redhat.com> Message-ID: <20080219150946.GB18052@redhat.com> On Tue, Feb 19, 2008 at 09:35:49AM -0500, Hugh O. Brock wrote: > On Tue, Feb 19, 2008 at 09:19:20AM -0500, Mike Langlie wrote: > > > > Hi Daniel, > > > > How about this version of your diagram? Hum, it's better to have different shape for domain and host (the physical machine) I used rounded corners for domains, I think it helps. As others have reported there is some missing names. the arrows indicating the network are dark grey on black, you don't see it unless you know what to look for > > > > That's prettier but I don't know what the blue hexagon is? Also, yeah, Well it was my way to indicate the hypervisor/domain 0/ i.e. the base OS on the managed Nodes And the blue arrow is the provisionning from the console domain, which is why the blue arrow were one way > we need to show the storage server... that's easy to add later, a standard disk shape connected to the network should be sufficient. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From mlanglie at redhat.com Tue Feb 19 15:48:02 2008 From: mlanglie at redhat.com (Mike Langlie) Date: Tue, 19 Feb 2008 10:48:02 -0500 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <20080219150946.GB18052@redhat.com> References: <47BAE296.6060302@redhat.com> <47BAE568.9050207@redhat.com> <20080219143533.GA32262@redhat.com> <20080219150946.GB18052@redhat.com> Message-ID: <47BAFA32.1000707@redhat.com> Daniel Veillard wrote: > Hum, it's better to have different shape for domain and host (the physical > machine) I used rounded corners for domains, I think it helps. > As others have reported there is some missing names. > the arrows indicating the network are dark grey on black, you don't > see it unless you know what to look for > > >> That's prettier but I don't know what the blue hexagon is? Also, yeah, >> > > Well it was my way to indicate the hypervisor/domain 0/ i.e. the base OS > on the managed Nodes > And the blue arrow is the provisionning from the console domain, which is > why the blue arrow were one way > > >> we need to show the storage server... >> > > that's easy to add later, a standard disk shape connected to the network > should be sufficient. > > Daniel > > How's this one: warmer or colder? Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: diagram4.png Type: image/png Size: 31438 bytes Desc: not available URL: From berrange at redhat.com Tue Feb 19 15:51:25 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 19 Feb 2008 15:51:25 +0000 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <47BAFA32.1000707@redhat.com> References: <47BAE296.6060302@redhat.com> <47BAE568.9050207@redhat.com> <20080219143533.GA32262@redhat.com> <20080219150946.GB18052@redhat.com> <47BAFA32.1000707@redhat.com> Message-ID: <20080219155125.GE17472@redhat.com> On Tue, Feb 19, 2008 at 10:48:02AM -0500, Mike Langlie wrote: > Daniel Veillard wrote: > > Hum, it's better to have different shape for domain and host (the > > physical > >machine) I used rounded corners for domains, I think it helps. > > As others have reported there is some missing names. > > the arrows indicating the network are dark grey on black, you don't > >see it unless you know what to look for > > > > > >>That's prettier but I don't know what the blue hexagon is? Also, yeah, > >> > > > > Well it was my way to indicate the hypervisor/domain 0/ i.e. the base OS > >on the managed Nodes > > And the blue arrow is the provisionning from the console domain, which is > >why the blue arrow were one way > > > >>we need to show the storage server... > > > > that's easy to add later, a standard disk shape connected to the network > >should be sufficient. > > > How's this one: warmer or colder? That gets my vote Dan -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From hbrock at redhat.com Tue Feb 19 16:07:04 2008 From: hbrock at redhat.com (Hugh O. Brock) Date: Tue, 19 Feb 2008 11:07:04 -0500 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <20080219155125.GE17472@redhat.com> References: <47BAE296.6060302@redhat.com> <47BAE568.9050207@redhat.com> <20080219143533.GA32262@redhat.com> <20080219150946.GB18052@redhat.com> <47BAFA32.1000707@redhat.com> <20080219155125.GE17472@redhat.com> Message-ID: <20080219160704.GC32262@redhat.com> > > > > > How's this one: warmer or colder? > > That gets my vote > > Dan > -- Yeah, that looks great. I want to put it on the front "documentation" page... --H From veillard at redhat.com Tue Feb 19 18:23:14 2008 From: veillard at redhat.com (Daniel Veillard) Date: Tue, 19 Feb 2008 13:23:14 -0500 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <47BAFA32.1000707@redhat.com> References: <47BAE296.6060302@redhat.com> <47BAE568.9050207@redhat.com> <20080219143533.GA32262@redhat.com> <20080219150946.GB18052@redhat.com> <47BAFA32.1000707@redhat.com> Message-ID: <20080219182314.GA32513@redhat.com> On Tue, Feb 19, 2008 at 10:48:02AM -0500, Mike Langlie wrote: > Daniel Veillard wrote: > > Hum, it's better to have different shape for domain and host (the > > physical > >machine) I used rounded corners for domains, I think it helps. > > As others have reported there is some missing names. > > the arrows indicating the network are dark grey on black, you don't > >see it unless you know what to look for > > > > > >>That's prettier but I don't know what the blue hexagon is? Also, yeah, > >> > > > > Well it was my way to indicate the hypervisor/domain 0/ i.e. the base OS > >on the managed Nodes > > And the blue arrow is the provisionning from the console domain, which is > >why the blue arrow were one way > > > > > >>we need to show the storage server... > >> > > > > that's easy to add later, a standard disk shape connected to the network > >should be sufficient. > > > >Daniel > > > > > How's this one: warmer or colder? Quite better, but of course I have a few problems left (remember, I'm french !): - there are strange white artefacts on the side of the blue line going into Admin Node - the blue arrow into the admin node makes no sense, hypervisors are downloaded from it, it's one way, not two ways - I don't understand the two white lines cutting the bottom blue line - the arrows and lines represneting the network are dark gey on a black background and hence nearly invisible thanks ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From bclark at redhat.com Tue Feb 19 18:27:29 2008 From: bclark at redhat.com (Bryan W Clark) Date: Tue, 19 Feb 2008 13:27:29 -0500 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <20080219182314.GA32513@redhat.com> References: <47BAE296.6060302@redhat.com> <47BAE568.9050207@redhat.com> <20080219143533.GA32262@redhat.com> <20080219150946.GB18052@redhat.com> <47BAFA32.1000707@redhat.com> <20080219182314.GA32513@redhat.com> Message-ID: <47BB1F91.1090402@redhat.com> Daniel Veillard wrote: > On Tue, Feb 19, 2008 at 10:48:02AM -0500, Mike Langlie wrote: > >> Daniel Veillard wrote: >> >>> Hum, it's better to have different shape for domain and host (the >>> physical >>> machine) I used rounded corners for domains, I think it helps. >>> As others have reported there is some missing names. >>> the arrows indicating the network are dark grey on black, you don't >>> see it unless you know what to look for >>> >>> >>> >>>> That's prettier but I don't know what the blue hexagon is? Also, yeah, >>>> >>>> >>> Well it was my way to indicate the hypervisor/domain 0/ i.e. the base OS >>> on the managed Nodes >>> And the blue arrow is the provisionning from the console domain, which is >>> why the blue arrow were one way >>> >>> >>> >>>> we need to show the storage server... >>>> >>>> >>> that's easy to add later, a standard disk shape connected to the network >>> should be sufficient. >>> >>> Daniel >>> >>> >>> >> How's this one: warmer or colder? >> > > Quite better, but of course I have a few problems left (remember, > I'm french !): > - there are strange white artefacts on the side of the blue line > going into Admin Node > That's to give some visual separation as the line goes inside the admin node, I don't think there's a problem with that. > - the blue arrow into the admin node makes no sense, hypervisors > are downloaded from it, it's one way, not two ways > - I don't understand the two white lines cutting the bottom blue line > - the arrows and lines represneting the network are dark gey on a black > background and hence nearly invisible > I think you're looking at this image with an invisible (square block) or black background. You need to place the image on a white background. (with eog, go to preferences and set the background) There is no background set for the png though it obviously assumes a while background in a few places as you can see by the white cutting the blue; which looks normal on a while background. ~ Bryan From veillard at redhat.com Tue Feb 19 18:55:46 2008 From: veillard at redhat.com (Daniel Veillard) Date: Tue, 19 Feb 2008 13:55:46 -0500 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <47BB1F91.1090402@redhat.com> References: <47BAE296.6060302@redhat.com> <47BAE568.9050207@redhat.com> <20080219143533.GA32262@redhat.com> <20080219150946.GB18052@redhat.com> <47BAFA32.1000707@redhat.com> <20080219182314.GA32513@redhat.com> <47BB1F91.1090402@redhat.com> Message-ID: <20080219185546.GB32513@redhat.com> On Tue, Feb 19, 2008 at 01:27:29PM -0500, Bryan W Clark wrote: > Daniel Veillard wrote: > >On Tue, Feb 19, 2008 at 10:48:02AM -0500, Mike Langlie wrote: > > > >>Daniel Veillard wrote: > >> > >>> Hum, it's better to have different shape for domain and host (the > >>> physical > >>>machine) I used rounded corners for domains, I think it helps. > >>> As others have reported there is some missing names. > >>> the arrows indicating the network are dark grey on black, you don't > >>>see it unless you know what to look for > >>> > >>> > >>> > >>>>That's prettier but I don't know what the blue hexagon is? Also, yeah, > >>>> > >>>> > >>> Well it was my way to indicate the hypervisor/domain 0/ i.e. the base OS > >>>on the managed Nodes > >>> And the blue arrow is the provisionning from the console domain, which > >>> is > >>>why the blue arrow were one way > >>> > >>> > >>> > >>>>we need to show the storage server... > >>>> > >>>> > >>> that's easy to add later, a standard disk shape connected to the network > >>>should be sufficient. > >>> > >>>Daniel > >>> > >>> > >>> > >>How's this one: warmer or colder? > >> > > > > Quite better, but of course I have a few problems left (remember, > >I'm french !): > > - there are strange white artefacts on the side of the blue line > > going into Admin Node > > > That's to give some visual separation as the line goes inside the admin > node, I don't think there's a problem with that. Then why doesn't it stop at the node boundary ? > > - the blue arrow into the admin node makes no sense, hypervisors > > are downloaded from it, it's one way, not two ways > > - I don't understand the two white lines cutting the bottom blue line > > - the arrows and lines represneting the network are dark gey on a black > > background and hence nearly invisible > > > I think you're looking at this image with an invisible (square block) or > black background. You need to place the image on a white background. > (with eog, go to preferences and set the background) There is no > background set for the png though it obviously assumes a while > background in a few places as you can see by the white cutting the blue; > which looks normal on a while background. Well I let you juge the effect I get, see enclosed :-) Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: diagram4.gif Type: image/gif Size: 54917 bytes Desc: not available URL: From berrange at redhat.com Tue Feb 19 20:36:39 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 19 Feb 2008 20:36:39 +0000 Subject: [Ovirt-devel] Appliance disk format Message-ID: <20080219203639.GQ17472@redhat.com> The current oVirt WUI appliance we distribute is a raw disk, gzipped for purposes of download. When deployed it takes up 4 GB. I've been testing with qcow2 files instead. The disk creator tool installs in a raw file, but at the last step converts it to qcow2 format. This gives a uncompressed qcow2 file, with no 'wasted' space since qemu-img compresses runs of 0's. This comes in at 1.9 GB Asking it to generate a compressed qcow2 file reduces that to 683 MB. The nice thing about this is that you can deploy & run the disk straight off in this format, so the savings in space are useful both for download and deployment - whereas raw + gzip only benefits download time. To see if there's any further compression to be had for helping downloads I tried various compression programs with the following results: - gzip - 661M - bzip2 - 662M - p7zip - 617M - rzip - 586M All used their default compression levels. rzip is pretty impressive, and p7zip is not too shabby. It is clearly not worth using gzip/bzip though. IMHO, once we remove firefox / X / gnome stuff from the WUI image we'll be small enough that we need not bother with additional compression over what qcow already gives us. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From jim at meyering.net Tue Feb 19 21:15:45 2008 From: jim at meyering.net (Jim Meyering) Date: Tue, 19 Feb 2008 22:15:45 +0100 Subject: [Ovirt-devel] Appliance disk format In-Reply-To: <20080219203639.GQ17472@redhat.com> (Daniel P. Berrange's message of "Tue, 19 Feb 2008 20:36:39 +0000") References: <20080219203639.GQ17472@redhat.com> Message-ID: <87tzk4k5q6.fsf@rho.meyering.net> "Daniel P. Berrange" wrote: ... > To see if there's any further compression to be had for helping downloads > I tried various compression programs with the following results: > > - gzip - 661M > - bzip2 - 662M > - p7zip - 617M > - rzip - 586M > > All used their default compression levels. rzip is pretty impressive, and > p7zip is not too shabby. It is clearly not worth using gzip/bzip though. Neat. If you want maximum compression, you probably don't want to use the default level. For maximum compression, try lzma with its -9 option. [yum install lzma aka http://tukaani.org/lzma/ ] But with such a big file, it'll take a long time. Though maybe it's worth it... On some quick tests, lzma -9 produced a file 15% smaller than rzip -9 did. Note that p7zip is more of an archiving program, like tar. p7zip can use LZMA for compression. The lzma program is more like gzip and bzip2. From mlanglie at redhat.com Tue Feb 19 21:45:52 2008 From: mlanglie at redhat.com (Mike Langlie) Date: Tue, 19 Feb 2008 16:45:52 -0500 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <20080219182314.GA32513@redhat.com> References: <47BAE296.6060302@redhat.com> <47BAE568.9050207@redhat.com> <20080219143533.GA32262@redhat.com> <20080219150946.GB18052@redhat.com> <47BAFA32.1000707@redhat.com> <20080219182314.GA32513@redhat.com> Message-ID: <47BB4E10.20902@redhat.com> Daniel Veillard wrote: > Quite better, but of course I have a few problems left (remember, > I'm french !): > - there are strange white artefacts on the side of the blue line > going into Admin Node > - the blue arrow into the admin node makes no sense, hypervisors > are downloaded from it, it's one way, not two ways > - I don't understand the two white lines cutting the bottom blue line > - the arrows and lines represneting the network are dark gey on a black > background and hence nearly invisible > > thanks ! > > Daniel > Hi Daniel, Here is an update. Part of the problem is due to the image being transparent. If not viewed on a white background it will look different. I used thick white lines under the solid lines to help separate them from the backgrounds. I removed the white lines in this version. Let me know if you don't like the gap in the blue line where it crosses the black line. I thought that would show that the black and blue lines are not connected. If you think the blue line looks broken I'll change it. I also took the incoming arrowhead off the blue line where it meets the Admin Node. Attached are two versions: one is transparent (to be viewed on a light background) and one has a flat white background. Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: diagram4-transparent.png Type: image/png Size: 31182 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: diagram4-flat.png Type: image/png Size: 30899 bytes Desc: not available URL: From berrange at redhat.com Tue Feb 19 21:52:45 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 19 Feb 2008 21:52:45 +0000 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <47BB4E10.20902@redhat.com> References: <47BAE296.6060302@redhat.com> <47BAE568.9050207@redhat.com> <20080219143533.GA32262@redhat.com> <20080219150946.GB18052@redhat.com> <47BAFA32.1000707@redhat.com> <20080219182314.GA32513@redhat.com> <47BB4E10.20902@redhat.com> Message-ID: <20080219215245.GT17472@redhat.com> On Tue, Feb 19, 2008 at 04:45:52PM -0500, Mike Langlie wrote: > Daniel Veillard wrote: > >Quite better, but of course I have a few problems left (remember, > >I'm french !): > > - there are strange white artefacts on the side of the blue line > > going into Admin Node > > - the blue arrow into the admin node makes no sense, hypervisors > > are downloaded from it, it's one way, not two ways > > - I don't understand the two white lines cutting the bottom blue line > > - the arrows and lines represneting the network are dark gey on a black > > background and hence nearly invisible > > > > thanks ! > > > >Daniel > > > > Hi Daniel, > > Here is an update. Part of the problem is due to the image being > transparent. If not viewed on a white background it will look different. > > I used thick white lines under the solid lines to help separate them > from the backgrounds. I removed the white lines in this version. Let me > know if you don't like the gap in the blue line where it crosses the > black line. I thought that would show that the black and blue lines are > not connected. If you think the blue line looks broken I'll change it. > > I also took the incoming arrowhead off the blue line where it meets the > Admin Node. > > Attached are two versions: one is transparent (to be viewed on a light > background) and one has a flat white background. Both look good to me - Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From berrange at redhat.com Tue Feb 19 22:41:59 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 19 Feb 2008 22:41:59 +0000 Subject: [Ovirt-devel] Appliance disk format In-Reply-To: <87tzk4k5q6.fsf@rho.meyering.net> References: <20080219203639.GQ17472@redhat.com> <87tzk4k5q6.fsf@rho.meyering.net> Message-ID: <20080219224159.GU17472@redhat.com> On Tue, Feb 19, 2008 at 10:15:45PM +0100, Jim Meyering wrote: > "Daniel P. Berrange" wrote: > ... > > To see if there's any further compression to be had for helping downloads > > I tried various compression programs with the following results: > > > > - gzip - 661M > > - bzip2 - 662M > > - p7zip - 617M > > - rzip - 586M > > > > All used their default compression levels. rzip is pretty impressive, and > > p7zip is not too shabby. It is clearly not worth using gzip/bzip though. > > Neat. If you want maximum compression, you probably don't want to use > the default level. It didn't make significant different with -9 - p7zip -9: 601M - rzip -9: 580M - lzma -9: 611M rzip is potentially worth using, saving 100 MBs download over the compressed qcow2. But if we slim down the master image itself that saving will be less sigificant. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From dlutter at redhat.com Wed Feb 20 05:54:54 2008 From: dlutter at redhat.com (David Lutterkort) Date: Tue, 19 Feb 2008 21:54:54 -0800 Subject: [Ovirt-devel] Appliance disk format In-Reply-To: <20080219203639.GQ17472@redhat.com> References: <20080219203639.GQ17472@redhat.com> Message-ID: <1203486894.3600.61.camel@localhost.localdomain> On Tue, 2008-02-19 at 20:36 +0000, Daniel P. Berrange wrote: > To see if there's any further compression to be had for helping downloads > I tried various compression programs with the following results: > > - gzip - 661M > - bzip2 - 662M > - p7zip - 617M > - rzip - 586M Did you run these on the raw or compressed disk images ? I did a similar comparison a while ago with the surprising result that sometimes compressing a raw image gives _much_ smaller images than compressing an already compressed image. That, and the fact that VMWare can run raw disk images w/o much ado made me use raw disk images for virt-pack[1] In more detail, I played with the Mantis appliance from JumpBox. Original is zip file of 138MB. Try with raw disk files and qcow compressed inside zip and tar: raw -> qcow 69s (root disk) + 16s (data disk) = 85s zip/raw - miserable, truncates files at 4GB zip/qcow 156MB 15s tar.gz/raw 140MB 99s tar.bz2/raw 123MB 203s tar.bz2/qcow 156MB 54s tar.gz/qcow 156MB 14s 7za/raw 78MB 17m 3s As you can see, you actually get better compression if you let gzip/bzip2/7zip loose on raw disk images. They can be quite a bit slower than qemu-img though, and, of course, you have to uncompress after download, not as convenient as qcow. I always imagined though that in a managed setting downloaded disk images would be copied into storage volumes when a VM is deployed so that uncompressing wouldn't really show up as a separate step. David [1] Patches I sent to et-mgmt-tools in Dec; I don't think I ever committed them. From veillard at redhat.com Wed Feb 20 07:59:59 2008 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 20 Feb 2008 02:59:59 -0500 Subject: [Ovirt-devel] Some architecture diagrams In-Reply-To: <47BB4E10.20902@redhat.com> References: <47BAE296.6060302@redhat.com> <47BAE568.9050207@redhat.com> <20080219143533.GA32262@redhat.com> <20080219150946.GB18052@redhat.com> <47BAFA32.1000707@redhat.com> <20080219182314.GA32513@redhat.com> <47BB4E10.20902@redhat.com> Message-ID: <20080220075959.GB19574@redhat.com> On Tue, Feb 19, 2008 at 04:45:52PM -0500, Mike Langlie wrote: > Daniel Veillard wrote: > >Quite better, but of course I have a few problems left (remember, > >I'm french !): > > - there are strange white artefacts on the side of the blue line > > going into Admin Node > > - the blue arrow into the admin node makes no sense, hypervisors > > are downloaded from it, it's one way, not two ways > > - I don't understand the two white lines cutting the bottom blue line > > - the arrows and lines represneting the network are dark gey on a black > > background and hence nearly invisible > > > > thanks ! > > > >Daniel > > > > Hi Daniel, > > Here is an update. Part of the problem is due to the image being > transparent. If not viewed on a white background it will look different. > > I used thick white lines under the solid lines to help separate them > from the backgrounds. I removed the white lines in this version. Let me > know if you don't like the gap in the blue line where it crosses the > black line. I thought that would show that the black and blue lines are > not connected. If you think the blue line looks broken I'll change it. > > I also took the incoming arrowhead off the blue line where it meets the > Admin Node. > > Attached are two versions: one is transparent (to be viewed on a light > background) and one has a flat white background. Okay, both looks great to me ! thanks a lot, and sorry for being a bit picky :-) Maybe I wanted to carry too much information in a single diagram, that makes them a bit harder to digest sometimes. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From berrange at redhat.com Wed Feb 20 12:57:27 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 20 Feb 2008 12:57:27 +0000 Subject: [Ovirt-devel] Appliance disk format In-Reply-To: <1203486894.3600.61.camel@localhost.localdomain> References: <20080219203639.GQ17472@redhat.com> <1203486894.3600.61.camel@localhost.localdomain> Message-ID: <20080220125727.GA31194@redhat.com> On Tue, Feb 19, 2008 at 09:54:54PM -0800, David Lutterkort wrote: > > On Tue, 2008-02-19 at 20:36 +0000, Daniel P. Berrange wrote: > > To see if there's any further compression to be had for helping downloads > > I tried various compression programs with the following results: > > > > - gzip - 661M > > - bzip2 - 662M > > - p7zip - 617M > > - rzip - 586M > > Did you run these on the raw or compressed disk images ? I did a similar > comparison a while ago with the surprising result that sometimes > compressing a raw image gives _much_ smaller images than compressing an > already compressed image. That, and the fact that VMWare can run raw > disk images w/o much ado made me use raw disk images for virt-pack[1] This was all done against qcow2 images, with compression turned on. I preferred this to raw, because it saves space at time of deployment as well as download. eg 680 MB vs 2 GB (uncompressed qcow) vs 4 GB (raw) > In more detail, I played with the Mantis appliance from JumpBox. > Original is zip file of 138MB. Try with raw disk files and qcow > compressed inside zip and tar: > > raw -> qcow 69s (root disk) + 16s (data disk) = 85s > > zip/raw - miserable, truncates files at 4GB > zip/qcow 156MB 15s > tar.gz/raw 140MB 99s > tar.bz2/raw 123MB 203s > tar.bz2/qcow 156MB 54s > tar.gz/qcow 156MB 14s > 7za/raw 78MB 17m 3s > > As you can see, you actually get better compression if you let > gzip/bzip2/7zip loose on raw disk images. They can be quite a bit slower > than qemu-img though, and, of course, you have to uncompress after > download, not as convenient as qcow. I always imagined though that in a > managed setting downloaded disk images would be copied into storage > volumes when a VM is deployed so that uncompressing wouldn't really show > up as a separate step. Yes, i guess the question is what do we want the deployable disk format to be. raw vs qcow2 ? That in turn impacts the decision on compression needs for re-distribution. > [1] Patches I sent to et-mgmt-tools in Dec; I don't think I ever > committed them. Hmm, I remember those, but never got time to review that at the time. We shoudl re-visit them. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From dlutter at redhat.com Wed Feb 20 18:48:16 2008 From: dlutter at redhat.com (David Lutterkort) Date: Wed, 20 Feb 2008 10:48:16 -0800 Subject: [Ovirt-devel] Appliance disk format In-Reply-To: <20080220125727.GA31194@redhat.com> References: <20080219203639.GQ17472@redhat.com> <1203486894.3600.61.camel@localhost.localdomain> <20080220125727.GA31194@redhat.com> Message-ID: <1203533296.30187.29.camel@localhost.localdomain> On Wed, 2008-02-20 at 12:57 +0000, Daniel P. Berrange wrote: > Yes, i guess the question is what do we want the deployable disk format to > be. raw vs qcow2 ? That in turn impacts the decision on compression needs > for re-distribution. That is indeed the 640GB question: when you deploy an image directly (i.e., w/o a virt mgmt system) what kind of tradeofs are acceptable ? The biggest issue here is the performance impact of writing to a compressed qcow disk ... does it matter ? Do we even care or just assume that 'serious' users will deploy VM images through a management system that will convert disks during deployment anyway. The other question: how do you make one VM image useful on as many virtualization platforms as possible. I really dislike the crazy download pages on rBuilder where you can download the same image in literally 20 different formats; that's insanely confusing to the user. At the same time, trying to build one image that runs on a reasonable swath of virt platforms forces a very low common denominator (i.e., raw disks) Luckily, OVF will fix all that > > [1] Patches I sent to et-mgmt-tools in Dec; I don't think I ever > > committed them. > > Hmm, I remember those, but never got time to review that at the time. We > shoudl re-visit them. The thread is https://www.redhat.com/archives/et-mgmt-tools/2007-December/msg00072.html. Haven't touched them since then. David From veillard at redhat.com Tue Feb 26 15:54:14 2008 From: veillard at redhat.com (Daniel Veillard) Date: Tue, 26 Feb 2008 10:54:14 -0500 Subject: [Ovirt-devel] Suggestion for the wui-appliance Message-ID: <20080226155414.GG26454@redhat.com> Well it would be nice to remove all the i386 packages on the x86_64 build that can add up to a lot of wasted space and sometimes make updates harder. Did someone tried after running yum remove *.i386 Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From berrange at redhat.com Tue Feb 26 16:10:05 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 26 Feb 2008 16:10:05 +0000 Subject: [Ovirt-devel] Suggestion for the wui-appliance In-Reply-To: <20080226155414.GG26454@redhat.com> References: <20080226155414.GG26454@redhat.com> Message-ID: <20080226161005.GF30568@redhat.com> On Tue, Feb 26, 2008 at 10:54:14AM -0500, Daniel Veillard wrote: > Well it would be nice to remove all the i386 packages on the x86_64 build > that can add up to a lot of wasted space and sometimes make updates harder. > Did someone tried after running > yum remove *.i386 Completely agree. i386 packages on x86_64 are only required for purposes of back-compatability with legacy (usually closed source) applications. Since we have no legacy apps in the admin or host images, there is no need to carry about i386 pacakges - they should all die. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From rjones at redhat.com Thu Feb 28 18:31:28 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 28 Feb 2008 18:31:28 +0000 Subject: [Ovirt-devel] ovirt dependencies Message-ID: <20080228183128.GA29120@amd.home.annexia.org> I'm trying to build a definitive list of 'external' dependencies for oVirt. By 'external' I mean dependencies on non-Fedora packages, network services, anything which needs a difficult or unusual configuration. The underlying question here is what would it take to be able to simply 'yum install ovirt-wui' to create a WUI? Please follow-up if I've missed any. (1a) FreeIPA server (1b) Kerberos support in the browser Does someone have Scott Seago's patches for "null" authentication? (2) DHCP, PXE, TFTP At the moment we provide some very complex instructions for setting up dhcpd & TFTP. DHCP is used for two things: (a) to pass the name of the PXE server to a booting node and (b) to pass a single configuration option to the managed node. As Dan suggested, (b) could be done with zeroconf. (a) seems like it will always require configuration. PXE, TFTP is used to boot the managed nodes. Can we run a self-contained dnsmasq (similar to the dnsmasq configuration used by libvirt) to do all of this work? Yes, in as much as dnsmasq works for me to PXEboot the managed host. Maybe we should mandate that in the "minimal" configuration people should always boot managed hosts using a USB key? (3) Apache The ovirt-wui RPM already drops the right files into /etc/httpd/conf.d to make an ovirt virtual host. (4) PostgreSQL Setting up databases is always hard: Should we create the database? What happens if the database already exists? (Upgrades are hard to do and error-prone). But leaving a SQL file around and asking the user to load it by hand seems reasonable enough. I notice that the current ovirt-wui RPM leaves a script around to create the database but my ruby isn't good enough to tell how the full database schema is created. (5) iSCSI server This is a bit of an unknown quantity. Can oVirt run without an iSCSI server? (6) collectd Should soon be added to Fedora, so not a problem. (7) Packages from Fedora: ruby, rails, kvm, libvirt, ntp, etc. These aren't really an issue because RPM can deal with installing them. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.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 Xen guests. http://et.redhat.com/~rjones/virt-p2v From clalance at redhat.com Thu Feb 28 18:56:50 2008 From: clalance at redhat.com (Chris Lalancette) Date: Thu, 28 Feb 2008 13:56:50 -0500 Subject: [Ovirt-devel] ovirt dependencies In-Reply-To: <20080228183128.GA29120@amd.home.annexia.org> References: <20080228183128.GA29120@amd.home.annexia.org> Message-ID: <47C703F2.5000205@redhat.com> Richard W.M. Jones wrote: > I'm trying to build a definitive list of 'external' dependencies for > oVirt. By 'external' I mean dependencies on non-Fedora packages, > network services, anything which needs a difficult or unusual > configuration. > > The underlying question here is what would it take to be able to > simply 'yum install ovirt-wui' to create a WUI? > > Please follow-up if I've missed any. > > (1a) FreeIPA server > (1b) Kerberos support in the browser > > Does someone have Scott Seago's patches for "null" authentication? I never saw them, so I can't help you there. > > (2) DHCP, PXE, TFTP > > At the moment we provide some very complex instructions for setting up > dhcpd & TFTP. > > DHCP is used for two things: (a) to pass the name of the PXE server to > a booting node and (b) to pass a single configuration option to the > managed node. As Dan suggested, (b) could be done with zeroconf. > (a) seems like it will always require configuration. Right. That being said, it is just the "next-server" directive, which I think is a required part of the DHCP spec (that is, it is not some exotic DHCP option record anymore). However, for people who don't have control of their DHCP server, it could be an issue. > > PXE, TFTP is used to boot the managed nodes. > > Can we run a self-contained dnsmasq (similar to the dnsmasq > configuration used by libvirt) to do all of this work? Yes, in as > much as dnsmasq works for me to PXEboot the managed host. > > Maybe we should mandate that in the "minimal" configuration people > should always boot managed hosts using a USB key? Eh. I'm guessing that for the initial target, if people are using real, physical machines as managed nodes, they'll either have a DHCP setup with PXE that works, have the ability to do so, or can use a USB key. I don't think we really need to mandate this. > > (3) Apache > > The ovirt-wui RPM already drops the right files into /etc/httpd/conf.d > to make an ovirt virtual host. > > (4) PostgreSQL > > Setting up databases is always hard: Should we create the database? > What happens if the database already exists? (Upgrades are hard to do > and error-prone). But leaving a SQL file around and asking the user > to load it by hand seems reasonable enough. > > I notice that the current ovirt-wui RPM leaves a script around to > create the database but my ruby isn't good enough to tell how the full > database schema is created. There are essentially 4 parts for setting up the database (all of which the appliance do at first-boot time): 1) service postgresql initdb 2) Run a series of postgresql commands to create the ovirt database user and create the ovirt database (this is in /usr/share/ovirt-wui/psql.cmds on the appliance) 3) cd /usr/share/ovirt-wui ; rake db:migrate (this actually creates the needed database tables) 4) /usr/share/ovirt-wui/scripts/grant_admin_privileges admin (this grants top-level admin privileges to the kerberos user "admin", so that he can then manage the other users/resources) > > (5) iSCSI server > > This is a bit of an unknown quantity. Can oVirt run without an iSCSI > server? Yes, the WUI can start without iSCSI. What iSCSI is really required for right now is for starting VMs on the managed nodes. Given the storage API's, it should be possible to use other things (like NFS, etc.); we just haven't coded it up yet. > > (6) collectd > > Should soon be added to Fedora, so not a problem. > > (7) Packages from Fedora: ruby, rails, kvm, libvirt, ntp, etc. > > These aren't really an issue because RPM can deal with installing > them. And don't forget the custom RPMs we currently have in the ovirt repository, notably updated libvirt with the storage patches + my custom iSCSI patch, updated KVM (from rawhide), updated kernel (from rawhide), updated livecd-tools (with rjones live-cd-to-pxe-script), custom ruby-libvirt bindings, and the custom ruby-kerberos bindings. Chris Lalancette From berrange at redhat.com Thu Feb 28 20:05:02 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 28 Feb 2008 20:05:02 +0000 Subject: [Ovirt-devel] ovirt dependencies In-Reply-To: <20080228183128.GA29120@amd.home.annexia.org> References: <20080228183128.GA29120@amd.home.annexia.org> Message-ID: <20080228200502.GG28935@redhat.com> On Thu, Feb 28, 2008 at 06:31:28PM +0000, Richard W.M. Jones wrote: > I'm trying to build a definitive list of 'external' dependencies for > oVirt. By 'external' I mean dependencies on non-Fedora packages, > network services, anything which needs a difficult or unusual > configuration. > > The underlying question here is what would it take to be able to > simply 'yum install ovirt-wui' to create a WUI? > > Please follow-up if I've missed any. > > (1a) FreeIPA server > (1b) Kerberos support in the browser > > Does someone have Scott Seago's patches for "null" authentication? I don't believe he finished it before he went away. > (2) DHCP, PXE, TFTP > > At the moment we provide some very complex instructions for setting up > dhcpd & TFTP. > > DHCP is used for two things: (a) to pass the name of the PXE server to > a booting node and (b) to pass a single configuration option to the > managed node. As Dan suggested, (b) could be done with zeroconf. > (a) seems like it will always require configuration. The configuration options we can definitely get rid of. The WUI could broadcast them with zeroconf, allthough that might increase the boot time of the managed nodes while they wait for a broadcast info. Would have to look at Avahi in detail to check if that's a problem or not. > PXE, TFTP is used to boot the managed nodes. > > Can we run a self-contained dnsmasq (similar to the dnsmasq > configuration used by libvirt) to do all of this work? Yes, in as > much as dnsmasq works for me to PXEboot the managed host. > > Maybe we should mandate that in the "minimal" configuration people > should always boot managed hosts using a USB key? That's is certainly doable. PXE is most appropriate is large networks where you don't have physical access. For small / developer networks using a LiveCD, or Live USB key is clearly a good option, particularly if we move config out of DHCP and into zeroconf. With this the only remaining requirement for DHCP would be the ability to set fixed DNS mappings, required to make Kerberos work nicely. > (3) Apache > > The ovirt-wui RPM already drops the right files into /etc/httpd/conf.d > to make an ovirt virtual host. Yep. Just need some config magic to FreeIPA to make it play nicely with other application > (4) PostgreSQL > > Setting up databases is always hard: Should we create the database? > What happens if the database already exists? (Upgrades are hard to do > and error-prone). But leaving a SQL file around and asking the user > to load it by hand seems reasonable enough. > > I notice that the current ovirt-wui RPM leaves a script around to > create the database but my ruby isn't good enough to tell how the full > database schema is created. Really a few steps: - InitDB - Fedora initscripts take care of this already - Create user - su - postgres and add the user account - Create DB - again a manual step - Config auth - twiddle pg_hba.conf - Import schema - Ruby provides a convenient command for this IIRC The first 4 are pretty much common to any DB app and really a documentation exercise. We can provide a script to help loading of the schema. > (5) iSCSI server > > This is a bit of an unknown quantity. Can oVirt run without an iSCSI > server? Not right now, but it will be able to. Once we use the storage APIs, then we have the generic API to manage any storage. THe next logical step for oVirt is to support LVM to carve up LUNs. Once do you are doing that, carving up local internal disks is much the same. And ading SAN / FibreChannel is not far behind. Its mostly a UI question, rather than a technology question at this point. If you don't care about migration, then simply use the local internal disk for dev purposes. If you do need migration, then we can support NFS with the storage APIs. So I think we have a good story for dealing with most of these issues. The only one which may remain 'hard' long term will be Kerberos. Hopefully the FreeIPA guys will make deployment easier. It is a shame we can't leverage libvirt's other auth schemes though, since that allows TLS/x509 certs, and even plain username+password auth. Supporting this though has implications for policy management / group management, since we had intended to push this all off to FreeIPA too. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From sseago at redhat.com Fri Feb 29 04:35:11 2008 From: sseago at redhat.com (Scott Seago) Date: Thu, 28 Feb 2008 23:35:11 -0500 Subject: [Ovirt-devel] ovirt dependencies In-Reply-To: <20080228200502.GG28935@redhat.com> References: <20080228183128.GA29120@amd.home.annexia.org> <20080228200502.GG28935@redhat.com> Message-ID: <47C78B7F.5040007@redhat.com> Daniel P. Berrange wrote: > On Thu, Feb 28, 2008 at 06:31:28PM +0000, Richard W.M. Jones wrote: > >> I'm trying to build a definitive list of 'external' dependencies for >> oVirt. By 'external' I mean dependencies on non-Fedora packages, >> network services, anything which needs a difficult or unusual >> configuration. >> >> The underlying question here is what would it take to be able to >> simply 'yum install ovirt-wui' to create a WUI? >> >> Please follow-up if I've missed any. >> >> (1a) FreeIPA server >> (1b) Kerberos support in the browser >> >> Does someone have Scott Seago's patches for "null" authentication? >> > > I don't believe he finished it before he went away. > > Actually, I haven't started it yet -- the priorities my last week before I took off were on the "demoable" bits that we needed to get in place first. On top of that, the null auth stuff won't work until Chris does the same thing on the back end (since we also use kerberos for libvirt) and at the time he had a backlog of higher priority tasks as well. As far as I know this is fairly high on the list of stuff for me to work on when I return though (although I've been out of the loop for a week, so some of this may have changed) >> (4) PostgreSQL >> >> Setting up databases is always hard: Should we create the database? >> What happens if the database already exists? (Upgrades are hard to do >> and error-prone). But leaving a SQL file around and asking the user >> to load it by hand seems reasonable enough. >> >> I notice that the current ovirt-wui RPM leaves a script around to >> create the database but my ruby isn't good enough to tell how the full >> database schema is created. >> > > Really a few steps: > > - InitDB - Fedora initscripts take care of this already > - Create user - su - postgres and add the user account > - Create DB - again a manual step > - Config auth - twiddle pg_hba.conf > - Import schema - Ruby provides a convenient command for this IIRC > > The first 4 are pretty much common to any DB app and really a documentation > exercise. We can provide a script to help loading of the schema. > > Yeah -- the actual schema loading is handled by ActiveRecord (the ORM used by rails). The code for the schema definition is contained in several Ruby files called "migrations" by ActiveRecord -- there is explicit support for db upgrades and downgrades, but the default "rake db:migrate" command upgrades the db schema to the latest version defined (or loads the whole schema for a newly-created db) > It is a shame we can't leverage libvirt's other auth schemes though, since > that allows TLS/x509 certs, and even plain username+password auth. Supporting > this though has implications for policy management / group management, since > we had intended to push this all off to FreeIPA too. > > Dan. > Any chance of FreeIPA supporting other auth schemes directly? Then we could just use those too. Is this on the roadmap, or is the plan to be "all kerberos, all the time" Scott From ssorce at redhat.com Fri Feb 29 18:13:25 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 29 Feb 2008 13:13:25 -0500 Subject: [Ovirt-devel] ovirt dependencies In-Reply-To: <47C78B7F.5040007@redhat.com> References: <20080228183128.GA29120@amd.home.annexia.org> <20080228200502.GG28935@redhat.com> <47C78B7F.5040007@redhat.com> Message-ID: <1204308805.26342.0.camel@localhost.localdomain> On Thu, 2008-02-28 at 23:35 -0500, Scott Seago wrote: > Any chance of FreeIPA supporting other auth schemes directly? Then we > could just use those too. Is this on the roadmap, or is the plan to > be > "all kerberos, all the time" In theory we support "plain text" authentication against the LDAP server (for users only). Simo. -- Simo Sorce * Red Hat, Inc * New York