From rjones at redhat.com Sat Mar 1 21:49:20 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Sat, 1 Mar 2008 21:49:20 +0000 Subject: [Ovirt-devel] Bricolage offer VMware image Message-ID: <20080301214920.GA13393@amd.home.annexia.org> http://www.bricolage.cc/downloads/ It's mildly interesting that Bricolage (a CMS) offer a VMware image for people who want to evaluate their CMS. Lessons: (1) Can we find out from them if this is popular, (2) encourage them to use a non-proprietary format(!) Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From berrange at redhat.com Tue Mar 4 14:43:18 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 4 Mar 2008 14:43:18 +0000 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: <20080304144317.GA6713@redhat.com> On Thu, Feb 28, 2008 at 11:35:11PM -0500, Scott Seago wrote: > Daniel P. Berrange wrote: > >On Thu, Feb 28, 2008 at 06:31:28PM +0000, Richard W.M. Jones wrote: > >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" There's stuff on the roadmap to provide x509 certificate management. When that gets there, we could use TLS/SSL in libvirt with x509 certs, and the LDAP plain text auth Simo mentions. 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 mwagner at redhat.com Wed Mar 5 03:40:57 2008 From: mwagner at redhat.com (mark wagner) Date: Tue, 04 Mar 2008 22:40:57 -0500 Subject: [Ovirt-devel] Can anyone help here Message-ID: <47CE1649.7000506@redhat.com> As I mentioned ina different mailing list earlier today, I am having lots of trouble trying to get an appliance up and running when following the directions on the ovirt installation webpage. This email expands on that bit and is intended to capture the issues and hopefully the answers :) The use of an F8 dvd and the kickstart file provided results in a failure every time on multiple pieces of hardware and when trying it in a guest. When trying on baremetal, it always gives a python error that scrolls off of the screen, in a guest it fails when trying to mount the cdrom that it already has mounted and is booting from. Yes I did try to fake it by manually unmounting, etc. I also have tried to use virsh to create a guest using the image provided but that fails with no error given (already explained as a bug in another mail list, but no help in getting to the root of the problem) I have created yum repos for ovirt and freeipa based on the kickstart file. The ovirt repo updates my Dom0 as follows: kernel.x86_64 2.6.25-0.50.rc2.fc9 ovirt kvm.x86_64 61-1.fc9 ovirt libvirt.x86_64 0.4.0-4.fc8ovirt2 ovirt livecd-tools.x86_64 014-2pxe.fc9 ovirt When I install all of them on the host and try to reboot with the new kernel, it can't find my logical volume that the file system is on and, well, let's just say things go downhill from there. Am I wrong to assume that the stuff on the ovirt site should work ? Are people building "new wui appliances" or just working off of the instances that they have ? Can someone give a definitive answer as to what versions of the kernel, kvm and libvirt are needed at this point in time ? the versions on the system I am focusing my devel effort on are: [root at wui ~]# virsh -c qemu:///system version Compiled against library: libvir 0.4.0 Using library: libvir 0.4.0 Using API: QEMU 0.4.0 Running hypervisor: QEMU 0.9.0 From mwagner at redhat.com Thu Mar 6 05:21:47 2008 From: mwagner at redhat.com (mark wagner) Date: Thu, 06 Mar 2008 00:21:47 -0500 Subject: [Ovirt-devel] Can anyone help here In-Reply-To: <47CE1649.7000506@redhat.com> References: <47CE1649.7000506@redhat.com> Message-ID: <47CF7F6B.80300@redhat.com> OK, so I reblew the system using a an F8 Live DVD. I yum'd in libvirt, kvm and some of there friends. I used the networking setup from the email that Chris sent out the other day. This time I was able to install the wui-application from the image. It is now configured and running. :) Tomorrow I'll try to actually bring up a guest... -mark mark wagner wrote: > As I mentioned ina different mailing list earlier today, I am having > lots of trouble trying to get an appliance up and running when following > the directions on the ovirt installation webpage. This email expands on > that bit and is intended to capture the issues and hopefully the answers :) > > The use of an F8 dvd and the kickstart file provided results in a > failure every time on multiple pieces of hardware and when trying it in > a guest. When trying on baremetal, it always gives a python error that > scrolls off of the screen, in a guest it fails when trying to mount the > cdrom that it already has mounted and is booting from. Yes I did try to > fake it by manually unmounting, etc. > > I also have tried to use virsh to create a guest using the image > provided but that fails with no error given (already explained as a bug > in another mail list, but no help in getting to the root of the problem) > > I have created yum repos for ovirt and freeipa based on the kickstart > file. The ovirt repo updates my Dom0 as follows: > kernel.x86_64 2.6.25-0.50.rc2.fc9 ovirt > kvm.x86_64 61-1.fc9 ovirt > libvirt.x86_64 0.4.0-4.fc8ovirt2 ovirt > livecd-tools.x86_64 014-2pxe.fc9 ovirt > > When I install all of them on the host and try to reboot with the new > kernel, it can't find my logical volume that the file system is on and, > well, let's just say things go downhill from there. > > Am I wrong to assume that the stuff on the ovirt site should work ? > > Are people building "new wui appliances" or just working off of the > instances that they have ? > > Can someone give a definitive answer as to what versions of the kernel, > kvm and libvirt are needed at this point in time ? > > the versions on the system I am focusing my devel effort on are: > > [root at wui ~]# virsh -c qemu:///system version > Compiled against library: libvir 0.4.0 > Using library: libvir 0.4.0 > Using API: QEMU 0.4.0 > Running hypervisor: QEMU 0.9.0 > > _______________________________________________ > Ovirt-devel mailing list > Ovirt-devel at redhat.com > https://www.redhat.com/mailman/listinfo/ovirt-devel From clalance at redhat.com Fri Mar 7 13:34:08 2008 From: clalance at redhat.com (Chris Lalancette) Date: Fri, 07 Mar 2008 08:34:08 -0500 Subject: [Ovirt-devel] Developer-only mode Message-ID: <47D14450.9080209@redhat.com> All, After thinking about it for a little while, I think I've come up with a way to make "developer mode" very simple, without really making any changes to our source code, and without removing kerberos. With this model, all developers would have to do to get up and running would be to download an appliance, start it up (this will be the management UI), and then just start up a second guest XML booting to the network (this will be the "managed node"). Beyond that, there shouldn't be any configuration necessary by the user. The details: 1. We provide a pre-built WUI appliance. Inside this appliance, we have already configured Ovirt, databases, etc, along with FreeIPA with some default realm (OVIRT.ORG). Simplification #1: users don't have to run ipa-server-install. 2. Inside the appliance, we pre-configure firefox to authenticate to this realm. Simplification #2: Users don't have to mess with firefox. 3. Inside the appliance, we create a default user (ovirtadmin) without a password, and export the keytab for that user into some location into the appliance (/usr/share/ovirt-wui/ovirt-admin.keytab). Set up a cron job to periodically kdestroy/kinit with this keytab. Simplification #3: users don't have to kinit anymore. 4. The whole appliance is run behind virbr0, so we can hard-code the MAC address that we use without worrying about colliding on the real network. Simplification #4: users won't have to muck (much) with the libvirt XML we provide them. 5. The "managed node" guest is also run behind virbr0, so we can hard-code a MAC here as well. There's no disk to download (since we'll be pulling the image over PXE), just a default libvirt XML that we provide. So, basically, I think we can do developer only mode with just configuration. I think this setup should be easy enough for most people to set up, assuming they can create KVM guests (of course, Xen guests would probably work too). I'm going to start working on this configuration; any thoughts on it in the meantime? Chris Lalancette From slinabery at gmail.com Fri Mar 7 17:54:11 2008 From: slinabery at gmail.com (steve linabery) Date: Fri, 7 Mar 2008 11:54:11 -0600 Subject: [Ovirt-devel] Developer-only mode In-Reply-To: <47D14450.9080209@redhat.com> References: <47D14450.9080209@redhat.com> Message-ID: <769584de0803070954m4ed1f9d3g7f76de868d36e06b@mail.gmail.com> On Fri, Mar 7, 2008 at 7:34 AM, Chris Lalancette wrote: > All, > After thinking about it for a little while, I think I've come up with > a way > to make "developer mode" very simple, without really making any changes to > our > source code, and without removing kerberos. With this model, all > developers > would have to do to get up and running would be to download an appliance, > start > it up (this will be the management UI), and then just start up a second > guest > XML booting to the network (this will be the "managed node"). Beyond > that, > there shouldn't be any configuration necessary by the user. The details: > > 1. We provide a pre-built WUI appliance. Inside this appliance, we have > already configured Ovirt, databases, etc, along with FreeIPA with some > default > realm (OVIRT.ORG). Simplification #1: users don't have to run > ipa-server-install. > > 2. Inside the appliance, we pre-configure firefox to authenticate to this > realm. Simplification #2: Users don't have to mess with firefox. > > 3. Inside the appliance, we create a default user (ovirtadmin) without a > password, and export the keytab for that user into some location into the > appliance (/usr/share/ovirt-wui/ovirt-admin.keytab). Set up a cron job to > periodically kdestroy/kinit with this keytab. Simplification #3: users > don't > have to kinit anymore. > > 4. The whole appliance is run behind virbr0, so we can hard-code the MAC > address that we use without worrying about colliding on the real network. > Simplification #4: users won't have to muck (much) with the libvirt XML we > provide them. > > 5. The "managed node" guest is also run behind virbr0, so we can > hard-code a > MAC here as well. There's no disk to download (since we'll be pulling the > image > over PXE), just a default libvirt XML that we provide. > > So, basically, I think we can do developer only mode with just > configuration. I > think this setup should be easy enough for most people to set up, assuming > they > can create KVM guests (of course, Xen guests would probably work too). > I'm > going to start working on this configuration; any thoughts on it in the > meantime? > > Chris Lalancette > > _______________________________________________ > Ovirt-devel mailing list > Ovirt-devel at redhat.com > https://www.redhat.com/mailman/listinfo/ovirt-devel > So everything would run on one physical host. Sounds great to me. The VMs-within-VMs would be slow, but that's ok for a development environment. I'll try to test this setup over the weekend. Steve Linabery -------------- next part -------------- An HTML attachment was scrubbed... URL: From clalance at redhat.com Fri Mar 7 18:26:32 2008 From: clalance at redhat.com (Chris Lalancette) Date: Fri, 07 Mar 2008 13:26:32 -0500 Subject: [Ovirt-devel] Developer-only mode In-Reply-To: <769584de0803070954m4ed1f9d3g7f76de868d36e06b@mail.gmail.com> References: <47D14450.9080209@redhat.com> <769584de0803070954m4ed1f9d3g7f76de868d36e06b@mail.gmail.com> Message-ID: <47D188D8.4010705@redhat.com> steve linabery wrote: > So everything would run on one physical host. Sounds great to me. The > VMs-within-VMs would be slow, but that's ok for a development environment. > > I'll try to test this setup over the weekend. Yeah, exactly, that's the goal. I'm going to do some work on making a setup for this today, but I don't know how far I'll get. Let me know where you get over the weekend, and we can compare notes. Thanks, Chris Lalancette From clalance at redhat.com Fri Mar 7 22:37:28 2008 From: clalance at redhat.com (Chris Lalancette) Date: Fri, 07 Mar 2008 17:37:28 -0500 Subject: [Ovirt-devel] Developer-only mode In-Reply-To: <47D188D8.4010705@redhat.com> References: <47D14450.9080209@redhat.com> <769584de0803070954m4ed1f9d3g7f76de868d36e06b@mail.gmail.com> <47D188D8.4010705@redhat.com> Message-ID: <47D1C3A8.8070209@redhat.com> Chris Lalancette wrote: > steve linabery wrote: >> So everything would run on one physical host. Sounds great to me. The >> VMs-within-VMs would be slow, but that's ok for a development environment. >> >> I'll try to test this setup over the weekend. > > Yeah, exactly, that's the goal. I'm going to do some work on making a setup for > this today, but I don't know how far I'll get. Let me know where you get over > the weekend, and we can compare notes. FYI; I've gotten the initial part of this working in a guest here locally. I still haven't tested PXE booting a "fake" managed node, but I'll get to that next week. After that, it should just be some documentation and packaging, and things should be much easier. Chris Lalancette From meyering at redhat.com Mon Mar 10 14:12:37 2008 From: meyering at redhat.com (Jim Meyering) Date: Mon, 10 Mar 2008 15:12:37 +0100 Subject: [Ovirt-devel] ovirt-host-creator/README+INSTALL from sources are *not* preferred Message-ID: <87tzjeacru.fsf@rho.meyering.net> I wasted some time following outdated instructions because until Friday, the web-based docs said to prefer README+INSTALL in the sources: However as of this writing (February 13, 2008) oVirt is a rapidly moving target. Therefore, please consult the README and INSTALL documents included with the source code when you install each piece; this document will inevitably lag them. In fact, it is the contrary: the web-based docs are newer. The web docs are now updated (thanks, Chris!), but for those who assume sources are more up-to-date, I've just changed README and INSTALL, both in ovirt.git's ovirt-host-creator/, to include this warning: [ CAUTION: The instructions in http://ovirt.org/install-instructions.html are usually more up-to-date than the instructions here. ] Eventually, I'm sure we'll generate common bits from a single source. From rjones at redhat.com Mon Mar 10 19:59:11 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 10 Mar 2008 19:59:11 +0000 Subject: [Ovirt-devel] Developer-only mode In-Reply-To: <47D14450.9080209@redhat.com> References: <47D14450.9080209@redhat.com> Message-ID: <20080310195911.GA5630@amd.home.annexia.org> On Fri, Mar 07, 2008 at 08:34:08AM -0500, Chris Lalancette wrote: > it up (this will be the management UI), and then just start up a > second guest XML booting to the network (this will be the "managed > node"). Beyond that, there shouldn't be any configuration necessary > by the user. The details: Did you mean to say "PXE booting from the network" there? Do we still need a PXE boot server on the virbr0 virtual network? 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 Mon Mar 10 21:11:42 2008 From: clalance at redhat.com (Chris Lalancette) Date: Mon, 10 Mar 2008 17:11:42 -0400 Subject: [Ovirt-devel] Developer-only mode In-Reply-To: <20080310195911.GA5630@amd.home.annexia.org> References: <47D14450.9080209@redhat.com> <20080310195911.GA5630@amd.home.annexia.org> Message-ID: <47D5A40E.9070302@redhat.com> Richard W.M. Jones wrote: > On Fri, Mar 07, 2008 at 08:34:08AM -0500, Chris Lalancette wrote: >> it up (this will be the management UI), and then just start up a >> second guest XML booting to the network (this will be the "managed >> node"). Beyond that, there shouldn't be any configuration necessary >> by the user. The details: > > Did you mean to say "PXE booting from the network" there? > > Do we still need a PXE boot server on the virbr0 virtual network? Yeah, we do, but it will all be pre-configured on the developer appliance. Note that I am not using dnsmasq here, so I can step around the problem that dnsmasq has with serving out TFTP without -m binary (of course, with the latest stuff, that whole issue goes away anyway). Chris Lalancette From mnielsen at redhat.com Tue Mar 11 13:30:36 2008 From: mnielsen at redhat.com (Mark Nielsen) Date: Tue, 11 Mar 2008 09:30:36 -0400 Subject: [Ovirt-devel] I need oVirt! Message-ID: <1205242236.12902.24.camel@localhost.localdomain> Greetings, I had a chat in #ovirt on freenode and was asked to provide some details on what I need oVirt to do, and I'm adding what I can offer in way of helping it get there. My environment consists of 3 8 nodes clusters. These 8 dom0s are Dell 2950's. They have 2x 2Gb Qlogic FC HBAs to both 3Par and EMC SANs which are multipathed using dm-multipath. Networking is done through 2 copper and 2 fiber NICs. The 2 copper are bonded (mode 0, "flat" non-routed private network for Cluster Suite comms) and the 2 fibers are bonded (mode 4, VLANs galore, multiple Xen bridges.. up to 10 at this point with more planned). These 8 nodes are clustered together using Cluster Suite which is primarily used to run the VMs as services for failover. GFS is used, but only for a common /etc/xen so the VMs can be started from any cluster node. The VM storage comes from logical volumes (clvmd running). We only have 40 running VMs at this time, but that number is expected to rise rapidly. I need an simple, accurate, and efficient way to monitor, deploy, and manage both physical and virtual resources. So far, oVirt is the only thing I've run across trying to accomplish this task. I would like to offer as much testing as needed (however, this is a network not accessible to the outside world) and bug filing as you want. I'm hoping in exchange some of the features I need could be implemented. I'd love to write patches myself to help, but sadly, I'm not a coder! 1) I need oVirt to support the fiber channel HBAs to the SAN so I can continue to use logical volumes for the domUs 2) I'm using RHEL 5.1 and need to make sure oVirt plays well with Xen. 3) My guests are currently services of Cluster Suite, I'm hoping that oVirt will play well with Cluster Suite as well as Conga... I think oVirt is what I'm looking for to manage my VMs and hosts, but please feel free to wave your hand in front of my face and tell me if this is not the tool I'm looking for. Mark From berrange at redhat.com Tue Mar 11 13:59:25 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 11 Mar 2008 13:59:25 +0000 Subject: [Ovirt-devel] I need oVirt! In-Reply-To: <1205242236.12902.24.camel@localhost.localdomain> References: <1205242236.12902.24.camel@localhost.localdomain> Message-ID: <20080311135925.GA15113@redhat.com> On Tue, Mar 11, 2008 at 09:30:36AM -0400, Mark Nielsen wrote: > Greetings, > > I had a chat in #ovirt on freenode and was asked to provide some details > on what I need oVirt to do, and I'm adding what I can offer in way of > helping it get there. > > My environment consists of 3 8 nodes clusters. These 8 dom0s are Dell > 2950's. They have 2x 2Gb Qlogic FC HBAs to both 3Par and EMC SANs which > are multipathed using dm-multipath. Networking is done through 2 copper > and 2 fiber NICs. The 2 copper are bonded (mode 0, "flat" non-routed > private network for Cluster Suite comms) and the 2 fibers are bonded > (mode 4, VLANs galore, multiple Xen bridges.. up to 10 at this point > with more planned). These 8 nodes are clustered together using Cluster > Suite which is primarily used to run the VMs as services for failover. > GFS is used, but only for a common /etc/xen so the VMs can be started > from any cluster node. The VM storage comes from logical volumes (clvmd > running). So would this be a fair summary of your networking setup: eth0 + eth1 -> bond0 (cluster suite / management) eth2 + eth3 -> bond1 (guest connectivity) bond1.1 + br01 => Bridged VLAN 1 (guest lan) bond1.2 + br02 => Bridged VLAN 2 (guest lan) bond1.3 + br03 => Bridged VLAN 3 (guest lan) bond1.4 + br04 => Bridged VLAN 4 (guest lan) bond1.5 + br05 => Bridged VLAN 5 (guest lan) > 1) I need oVirt to support the fiber channel HBAs to the SAN so I can > continue to use logical volumes for the domUs We are currently only supporting iSCSI, but direct attached storage is the next thing on the feature list for storage support. This is pending HBA support in libvirt - reasonably straightfowrad todo. Once this is done, then LVM is the logical next step. Can you describe in more detail the way you carve up your storage ? The relationship between LUNS, volume groups and guests ? 1 LUN + VG per guest, or many LUNs in 1 VG, split across many guests, or something else ? Also, do you use multipathing or RAID at all ? > 2) I'm using RHEL 5.1 and need to make sure oVirt plays well with Xen. For the guest that should not be a problem. oVirt is using KVM fullvirt which can run more or less any guest. There are now paravirt drivers available for KVM backported to 2.6.18. Or alternatively there is Xenner which lets us run Xen paravirt guests in KVM. For managed nodes (ie where the guests run) we provide a Fedora 8 based stateless image, but the core requirement is basically libvirtd daemon version 0.4.1 or later, so that can be built around other OS if needed. > 3) My guests are currently services of Cluster Suite, I'm hoping that > oVirt will play well with Cluster Suite as well as Conga... So, this is clustering at the physical host level ? ie if a physical host dies, cluster suite moves all your VMs to another host ? If so, that is definitely something on our roadmap. We won't neccessarily use Conga for this - we may integrate the low level clustering infrastructure directly into the oVirt images. For clustering inside the guest, we're intending to work with the cluster guys to provide some form of generic fence device to all guests. The goal is to allow the guest administrator to setup clustering of services inside their guests without needing co-ordination with the host admin. > I think oVirt is what I'm looking for to manage my VMs and hosts, but > please feel free to wave your hand in front of my face and tell me if > this is not the tool I'm looking for. oVirt is at a very early stage of development, so as you can see we can't currently meet all your feature requests yet. Everything you mention is definitely on our roadmap - you outline precisely the kind of deployment scenarios we want & need to be able to handle. Regards, Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From mnielsen at redhat.com Tue Mar 11 14:34:35 2008 From: mnielsen at redhat.com (Mark Nielsen) Date: Tue, 11 Mar 2008 10:34:35 -0400 Subject: [Ovirt-devel] I need oVirt! In-Reply-To: <20080311135925.GA15113@redhat.com> References: <1205242236.12902.24.camel@localhost.localdomain> <20080311135925.GA15113@redhat.com> Message-ID: <1205246075.12902.46.camel@localhost.localdomain> On Tue, 2008-03-11 at 13:59 +0000, Daniel P. Berrange wrote: > > So would this be a fair summary of your networking setup: > > eth0 + eth1 -> bond0 (cluster suite / management) > eth2 + eth3 -> bond1 (guest connectivity) > > bond1.1 + br01 => Bridged VLAN 1 (guest lan) > bond1.2 + br02 => Bridged VLAN 2 (guest lan) > bond1.3 + br03 => Bridged VLAN 3 (guest lan) > bond1.4 + br04 => Bridged VLAN 4 (guest lan) > bond1.5 + br05 => Bridged VLAN 5 (guest lan) > yes, nearly exactly (names have been changed to protect the innocent). One note of possible interest, only bond1.1 has an IP address. This is for access to dom0. No guests use this bridge. None of the additional bridges have an IP address on dom0. The guests use these various VLANs for all their networking (either "internal" for the VM cluster comms or external for direct network access to the guest). In most cases, dom0 won't be able to connect to the domU. > We are currently only supporting iSCSI, but direct attached storage is the > next thing on the feature list for storage support. This is pending HBA > support in libvirt - reasonably straightfowrad todo. Once this is done, then > LVM is the logical next step. > We have a "DR" cluster that won't go to the DR site for nearly a year. This is my 'playground' for now, I can test anything you want to try without worry about killing the whole cluster and having to re-install. > Can you describe in more detail the way you carve up your storage ? The > relationship between LUNS, volume groups and guests ? 1 LUN + VG per > guest, or many LUNs in 1 VG, split across many guests, or something else ? > Also, do you use multipathing or RAID at all ? VolGrp00 is all local for the host OS. VolGrp01 is 10+Tb for *guest* shared storage (virtual cluster GFS partitions for data) presented as the second disk to the VM where needed (w!). VolGrp02 is 1+TB for VM root partitions. We lvcreate separate 15G partitions for all guests, then present as disk = [ "phy:/dev/VolGrp02/LVTestVM,xvda,w" ] and kickstart a VM on to that using virt-install. Multipathing is done on dom0, RAID is done on the SAN. The LUNs presented from SAN are numerous and varying to some degree in size. They do try to present a consistent size, but that doesn't always happen. I pvcreate /dev/mapper/mpath0 them, then vgcreate multiple SAN LUNs (each PV) into one VG, then lvcreate slice them up as needed for guests. I do also use LVM inside the guests as well. I decided it was easier to use vg|lvextend inside the guest vs. on dom0 and I haven't seen any data indicating LVM over LVM has significant performance impacts. I do run in to issues because I use the same naming convention (VolGrp00), this prevents me from mounting a guest disk on dom0. That's fine, I don't want anyone on dom0 anyways, and don't want dom0 being used to mount up guest images when there are also security concerns about some of our data. I have a "rescue" VM that uses VG0/LV0 as its naming convention. If I have a problematic guest disk/image/LVM I present it as a second disk= to my rescue guest and fsck it there. > > > 2) I'm using RHEL 5.1 and need to make sure oVirt plays well with Xen. > > For the guest that should not be a problem. oVirt is using KVM fullvirt > which can run more or less any guest. There are now paravirt drivers > available for KVM backported to 2.6.18. Or alternatively there is Xenner > which lets us run Xen paravirt guests in KVM. > Another issue I have is the winding roadmap for virt! A FAQ would be nice to explain all the terms, the diffs between the various technologies, and where it is all going. I can't even tell my customer whether or not the virtualization solution we're using now will be valid in RHEL 6. > For managed nodes (ie where the guests run) we provide a Fedora 8 based > stateless image, but the core requirement is basically libvirtd daemon > version 0.4.1 or later, so that can be built around other OS if needed. > > > 3) My guests are currently services of Cluster Suite, I'm hoping that > > oVirt will play well with Cluster Suite as well as Conga... > > So, this is clustering at the physical host level ? ie if a physical > host dies, cluster suite moves all your VMs to another host ? If so, > that is definitely something on our roadmap. We won't neccessarily use > Conga for this - we may integrate the low level clustering infrastructure > directly into the oVirt images. > yes, exactly. Though I often use clusvcadm and other cluster commands when Conga fails me (which it doesn't seem to do as often as it used to) > For clustering inside the guest, we're intending to work with the cluster > guys to provide some form of generic fence device to all guests. The goal > is to allow the guest administrator to setup clustering of services inside > their guests without needing co-ordination with the host admin. > > > I think oVirt is what I'm looking for to manage my VMs and hosts, but > > please feel free to wave your hand in front of my face and tell me if > > this is not the tool I'm looking for. > > oVirt is at a very early stage of development, so as you can see we can't > currently meet all your feature requests yet. Everything you mention is > definitely on our roadmap - you outline precisely the kind of deployment > scenarios we want & need to be able to handle. > I'd love to be a use/test case. There really isn't anything I see that allows us to manage our VMs, and as our numbers climb in to the hundreds, we will need this functionality. Mark > Regards, > Dan. > -- > |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| > |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From pmyers at redhat.com Mon Mar 17 03:43:02 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Sun, 16 Mar 2008 23:43:02 -0400 Subject: [Ovirt-devel] Ovirt Host Tasks Message-ID: <47DDE8C6.3010304@redhat.com> Here's an initial cut at an Ovirt Host task list. After we refine this a little with some discussion, I'll prioritize these. One thing that complicates the design is supporting static addressing of Ovirt hosts. Making the assumption that DHCP can be used and configured for Ovirt makes things much simpler. I won't make the DHCP assumption below, but would appreciate people's thoughts on whether or not static addressing support is important. 1. Image Creation: Right now the Ovirt Host is created using scripts in the Ovirt host repository that utilize livecd creator to make ISO, USB and PXE formats. I think it makes sense to start with the tools that Chris L. has already been working with and migrate new functionality in, rather than starting with other tools. a. Integrate whitelist functionality into the image creation process to reduce image size. b. Determine the minimal set of files that the host image needs to construct a baseline whitelist. c. Determine minimal set of kernel modules to support wide platform base (i.e. keep disk, net modules. remove things like sound, isdn, etc...) d. Construct a repeatable build process so that images can be built daily for testing. e. Construct a utility that detects the minimal set of kernel modules for a given platform and generates a config file that can be fed to the build system for generating hardware platform specific images. f. Construct a method for taking the generic host image and removing all kernel modules not applicable for a specific platform. g. Construct a method for taking an image and adding site specific configuration information to it (IP addresses of Ovirt Mgmt Server and FreeIPA Server). This is only necessary to support hosts that require static IP configuration -and- do not have persistent storage to store configuration information. (If we decide to support static IP config we could make presence of persistent storage a requirement...) The goal is to get disk footprint down to something like 32, 64 or 128MB. The base images we build will not be hardware platform specific, so 32MB might be a long shot. But after step e) above, we should fit into 32MB. 2. Installation We have to account for two methods of distributing Ovirt: pre-installation by OEMs and install by IT admins. Pre-install by OEM implies that the platform has flash or a reserved partition on the primary hard disk. Install by IT can be done by setting up PXE boot, adding an external bootable USB disk, booting to CD or installing to onboard flash/disk. The livecd/liveusb disk should allow either booting and running directly or installation onto platform flash/disk. 3. Persistent Configuration Storage Since the host is non-persistent and may or may not have access to persistent storage, this could become tricky. It's further complicated by the need to support DHCP and static addressing of the host. The following things need to be stored for the host: a. Kerberos keytab or SSL Certificate b. IP configuration (if using static configuration) c. IP address of FreeIPA server and Ovirt Management Server (if using static configuration) Here's where things could be much simpler if DHCP were required. Without static addressing, b is not necessary and c can be transmitted as custom DHCP fields (iirc). Then the only thing that needs to be cached on the host on persistent storage is the auth credentials. (NOTE: Does Microsoft's DHCP server allow custom DHCP fields???) OEM Pre-Install (will always have flash/disk storage) DHCP Addressing Flash/Disk Storage/TPM Auth credentials can be stored in a file or in TPM Static Addressing Flash/Disk Storage/TPM Auth credentials/IP config/Server IPs can be stored in a file If TPM is present, can be used to store auth info IT Install (may not have flash or disk) DHCP Addressing Flash/Disk Storage/TPM Auth credentials can be stored in a file or in TPM No Persistent Storage (CD or PXE Boot) Auth can be stored in host image (separate image for each host) (NOTE: Not secure for PXE boot. Recommend that we only allow CD boot in this case) Static Addressing Flash/Disk Storage/TPM Auth credentials/IP config/Server IPs can be stored in a file If TPM is present, can be used to store auth info No Persistent Storage (CD or PXE Boot) Auth/IP config/Server IPs can be stored in host image (separate image for each host) (NOTE: Not secure for PXE boot as above) 4. Initial Configuration When the host comes up the first time it needs to know the IP address and password of the Ovirt Mgmt server so it can get its auth credentials set up. Here's how a typical setup might look: a. Cable up the new hardware and get MAC addrs for each iface. Need to record which MAC is for: * management network (NOTE: should be only iface that PXE boots if PXE is being used) * storage network * normal networks (these all don't have to be separate, there could be just a single interface on the box used for management, storage and normal traffic) b. Set up DNS/DHCP servers. If using static addressing, skip DHCP setup (This is a manual step that IT admin would do, i.e. we're not trying to automate this process) c. Boot Ovirt Host for first time. Kernel cmdline takes options like: * ovirt_net=static (to indicate that static ip config should be prompted for during boot) * ovirt_auth_pw= (password to use when connecting to the Ovirt Mgmt server to register the host and retrieve auth information) * ovirt_init (this is specified to let the host know that initial config needs to happen. Otherwise normal boot occurs) d. During boot if ovirt_net=static is specified, admin is prompted for IP config for each interface and which interface is the mgmt interface. This can be done with an anaconda style interface. e. Auth Setup: * If ovirt_auth_pw is not specified: Auth information is expected to be either on the host disk image or on a connected USB key. (could be that the Ovirt host image is on internal flash/disk and admin supplies auth info on a USB thumb drive) * If ovirt_auth_pw is specified: After network comes up, mgmt server is contacted and the host is registered using the supplied password. The auth information is sent back to the Ovirt Host. f. The host is checked for persistent storage and TPM devices. If TPM is found it is initialized so that auth info can be stored there. * If either USB or hard disk is found it is checked for a partition with a label called "OVIRT". If that exists it is used for persistent storage. If it does not, an "OVIRT" partition is created. on available unpartitioned space. (how big should it be?) * USB/disk is also checked for swap partition. If none is found, a swap partition is created using unpartitioned space. g. Host stores auth/ip information on persistent storage/TPM for future boots. 5. KVM Work * Need to work on support for Live Migration * Need to make sure that power management and suspend/resume of guests work as expected 6. Storage Support * libvirt storage API to support fibre channel * Work on using LVM on top of iSCSI so that we don't need to have a 1-1 mapping between LUNs and Guests * libvirt already supports NFS, just need to put plumbing in place so that Ovirt also supports NFS. (This is more of an issue for the management interface, not the Ovirt Host) 7. Performance Monitoring/Auditing/Health * collectd is used presently to send performance stats to management server. Is this the right solution? I don't have a better one, but suggestions are appreciated. * libvirt talks to auditd to send audit info to FreeIPA server * Need to create a health monitoring daemon that communicates to mgmt server: - Sends heartbeat at configurable interval - Sends status changes of host (including machine check exceptions, and other errors) - Sends VM state changes 8. Clustering I'm light on clustering knowledge, so fill me in if I'm talking crazy nonsense... Two types of clustering: physical machines and virtual machines Physical clustering is not particularly useful in and of itself, since the whole point of what we're trying to do is abstract the applications from hardware further. Clustering of guests should be done. The hardware fence would be replaced by a paravirt driver in the guest that communicates to the host. If two machines A and B are clustered and on different physical hardware, A is the primary and B is backup. B monitors the application on A. If A appears to go down, B uses the PV driver to tell the host that it needs to kill A. The host tells libvirt that A needs to be destroyed, and that command is sent over libvirt comms to the physical host that is hosting A. If the physical hardware hosting A is down, that libvirt command won't succeed. So in this case, a hardware fence would be required to make sure that the physical host is disconnected and does not power on again. This probably needs a lot of refinement. So someone who knows clustering better than I do, should feel free to help out here... 9. Image Updates Host images should be updated as binary blobs. (initially a complete overwrite, and eventually perhaps a binary diff) Updating can be done in a few ways: a. For machines that PXE, this is simply putting a new PXE image in place. b. For machines that boot from CD a new livecd needs to be created and physically put in machines c. For machines that boot from USB/hard disk an update daemon can run on the host that polls the mgmt server for new images. When a new image is found it is retrieved and stored on the persistent disk and grub is updated to boot to it. If boot fails of the new image, the next boot falls back to the old image. (This means that persistent storage should be 2 times the size of the compressed image size + some additional room for config) That's a mouthful. Thoughts and criticisms appreciated. Perry -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=| From pmyers at redhat.com Mon Mar 17 15:20:37 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Mon, 17 Mar 2008 11:20:37 -0400 Subject: [Ovirt-devel] Ovirt Host Tasks In-Reply-To: <47DDE8C6.3010304@redhat.com> References: <47DDE8C6.3010304@redhat.com> Message-ID: <47DE8C45.1090204@redhat.com> Some things I left off that are important... > 5. KVM Work > > * Need to work on support for Live Migration > * Need to make sure that power management and suspend/resume of guests > work as expected * Ballooning memory support * PV Drivers (disk and net) including drivers for Windows Perry From berrange at redhat.com Mon Mar 17 15:47:16 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 17 Mar 2008 15:47:16 +0000 Subject: [Ovirt-devel] Ovirt Host Tasks In-Reply-To: <47DDE8C6.3010304@redhat.com> References: <47DDE8C6.3010304@redhat.com> Message-ID: <20080317154716.GA3849@redhat.com> On Sun, Mar 16, 2008 at 11:43:02PM -0400, Perry N. Myers wrote: > 1. Image Creation: > > a. Integrate whitelist functionality into the image creation > process to reduce image size. > b. Determine the minimal set of files that the host image needs to > construct a baseline whitelist. IMHO, a pure whitelist approach is not very maintainable long term. As we track new Fedora RPM updates, new files often appear & we'll miss them with a pure whitelist. I'd go for a combined white/black list so we can be broadly inclusive and only do fine grained whitelist in specific areas > c. Determine minimal set of kernel modules to support wide platform base > (i.e. keep disk, net modules. remove things like sound, isdn, etc...) > d. Construct a repeatable build process so that images can be built > daily for testing. > e. Construct a utility that detects the minimal set of kernel modules > for a given platform and generates a config file that can be fed to > the build system for generating hardware platform specific images. > f. Construct a method for taking the generic host image and removing all > kernel modules not applicable for a specific platform. I'd put e) & f) fairly low on the list, unless someone has a compelling short term need to make a *tiny* embedded image for specific hardware. > g. Construct a method for taking an image and adding site specific > configuration information to it (IP addresses of Ovirt Mgmt Server and > FreeIPA Server). This is only necessary to support hosts that require > static IP configuration -and- do not have persistent storage to store > configuration information. (If we decide to support static IP config > we could make presence of persistent storage a requirement...) > > The goal is to get disk footprint down to something like 32, 64 or 128MB. > The base images we build will not be hardware platform specific, so 32MB > might be a long shot. But after step e) above, we should fit into 32MB. 64MB is probably a worthy immediate goal to aim for given that the current live image is about 85 MB & we know there's stuff that can be killed. Again, unless we have compelling hardware use case that requires 32 MB, I'd not bother aiming for the 32MB mark in the short-medium term. There's other more broadly useful stuff we can do.... > OEM Pre-Install (will always have flash/disk storage) > DHCP Addressing > Flash/Disk Storage/TPM > Auth credentials can be stored in a file or in TPM > Static Addressing > Flash/Disk Storage/TPM > Auth credentials/IP config/Server IPs can be stored in a file > If TPM is present, can be used to store auth info > IT Install (may not have flash or disk) > DHCP Addressing > Flash/Disk Storage/TPM > Auth credentials can be stored in a file or in TPM > No Persistent Storage (CD or PXE Boot) > Auth can be stored in host image (separate image for each host) > (NOTE: Not secure for PXE boot. Recommend that we only allow > CD boot in this case) > Static Addressing > Flash/Disk Storage/TPM > Auth credentials/IP config/Server IPs can be stored in a file > If TPM is present, can be used to store auth info > No Persistent Storage (CD or PXE Boot) > Auth/IP config/Server IPs can be stored in host image (separate > image for each host) > (NOTE: Not secure for PXE boot as above) The 2 PXE boot methods can be secure given a deployment scenario where the network admin has a dedicated PXE management LAN for their hosts. So PXE traffic would be separated from general guest / user traffic. Its probably not viable to mandate separate 'management network' but we should document it as a deployment scenario. > 5. KVM Work > > * Need to work on support for Live Migration > * Need to make sure that power management and suspend/resume of guests > work as expected * dmidecode support so we can expose UUID to guest OS * inter-VM socket family. Like AF_UNIX, but between guests (or perhaps just between guest & host). Call it AF_VIRT or some such. Want stream based protocol, but optionally datagram too. Some use cases for this: - Fast channel to feed performance stats from guest OS to host - Used to build the cluster fence agent - Other... ? > 7. Performance Monitoring/Auditing/Health > > * collectd is used presently to send performance stats to management > server. Is this the right solution? I don't have a better one, but > suggestions are appreciated. collectd is the best option I know of for flexible, lightweight monitoring > * libvirt talks to auditd to send audit info to FreeIPA server To clarify, there's no explicit depdancy chain here. Libvirt would simply send data to the audit daemon. The audit daemon can optionally be configured to ship data off to FreIPA. > * Need to create a health monitoring daemon that communicates to mgmt > server: > - Sends heartbeat at configurable interval > - Sends status changes of host (including machine check exceptions, > and other errors) > - Sends VM state changes This last point should arguably be supported by libvirt directly. > 8. Clustering > > Physical clustering is not particularly useful in and of itself, since the > whole point of what we're trying to do is abstract the applications from > hardware further. You fundamentally need at least the fencing part of clustering on the physical hosts. Without this you have no guarentee that the host & guests that were running on it are actually dead. You need this guarentee before starting the guests on a new host. > Clustering of guests should be done. The hardware fence would be replaced > by a paravirt driver in the guest that communicates to the host. If two > machines A and B are clustered and on different physical hardware, A is > the primary and B is backup. B monitors the application on A. If A > appears to go down, B uses the PV driver to tell the host that it needs to > kill A. The host tells libvirt that A needs to be destroyed, and that > command is sent over libvirt comms to the physical host that is hosting A. The basic goal here is that the oVirt host should provide a general purpose virtual fence device to all guests. The guest admin decides which of their guests are in the same cluster & does some config task with the driver to set this up. Since oVirt knows what VMs each user owns, it can validate the config to ensure the admin isn't trying to cluster someone else's VMs. THe driver will then provide the guest admin the ability to have one guest shoot another guest in the head securely. The key is there must be *zero* need for the guest admin to actually interact with the host admin. The host image should support this all automatically, so guest admin's can setup clustering in their guest at will. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From hbrock at redhat.com Mon Mar 17 16:35:53 2008 From: hbrock at redhat.com (Hugh O. Brock) Date: Mon, 17 Mar 2008 12:35:53 -0400 Subject: [Ovirt-devel] Ovirt Host Tasks In-Reply-To: <47DDE8C6.3010304@redhat.com> References: <47DDE8C6.3010304@redhat.com> Message-ID: <20080317163550.GA3009@redhat.com> On Sun, Mar 16, 2008 at 11:43:02PM -0400, Perry N. Myers wrote: Wow that's a big mail . I have a couple of general comments based on the way we *have been* thinking about this stuff (this of course doesn't mean we can't change). First off, we have been imagining the oVirt host image as stateless except for whatever we use to store its identity (if we even do that). This means we simply don't support static addressing of oVirt hosts, at all. The appealing thing about a stateless oVirt host image to me is that it means the host is immediately and easily upgradeable; there is 0 local state to worry about aside from the Kerberos keytab. It also means that a reboot will immediately restore a compromised machine FWIW. Having said all that, if there is a compelling reason to move away from the stateless idea I'm all ears. Further comments in-line below... > > 1. Image Creation: > > Right now the Ovirt Host is created using scripts in the Ovirt host > repository that utilize livecd creator to make ISO, USB and PXE formats. > > I think it makes sense to start with the tools that Chris L. has already > been working with and migrate new functionality in, rather than starting > with other tools. > > a. Integrate whitelist functionality into the image creation > process to reduce image size. > b. Determine the minimal set of files that the host image needs to > construct a baseline whitelist. > c. Determine minimal set of kernel modules to support wide platform base > (i.e. keep disk, net modules. remove things like sound, isdn, etc...) > d. Construct a repeatable build process so that images can be built > daily for testing. > e. Construct a utility that detects the minimal set of kernel modules > for a given platform and generates a config file that can be fed to > the build system for generating hardware platform specific images. > f. Construct a method for taking the generic host image and removing all > kernel modules not applicable for a specific platform. > g. Construct a method for taking an image and adding site specific > configuration information to it (IP addresses of Ovirt Mgmt Server and > FreeIPA Server). This is only necessary to support hosts that require > static IP configuration -and- do not have persistent storage to store > configuration information. (If we decide to support static IP config > we could make presence of persistent storage a requirement...) You could add "Kerberos keytab" to "site specific configuration information" and the host image would be completely self-contained. I can imagine a library of unique images under /tftpboot...? > > 2. Installation > > We have to account for two methods of distributing Ovirt: pre-installation > by OEMs and install by IT admins. Pre-install by OEM implies that the > platform has flash or a reserved partition on the primary hard disk. > Install by IT can be done by setting up PXE boot, adding an external > bootable USB disk, booting to CD or installing to onboard flash/disk. > > The livecd/liveusb disk should allow either booting and running directly or > installation onto platform flash/disk. That's a nice addition, yeah. Although again I'm in favor of the running image itself remaining stateless. > 3. Persistent Configuration Storage > > Since the host is non-persistent and may or may not have access to > persistent storage, this could become tricky. It's further complicated by > the need to support DHCP and static addressing of the host. > > The following things need to be stored for the host: > a. Kerberos keytab or SSL Certificate > b. IP configuration (if using static configuration) > c. IP address of FreeIPA server and Ovirt Management Server (if using > static configuration) > Here's where things could be much simpler if DHCP were required. Without > static addressing, b is not necessary and c can be transmitted as custom > DHCP fields (iirc). Then the only thing that needs to be cached on the > host on persistent storage is the auth credentials. (NOTE: Does > Microsoft's DHCP server allow custom DHCP fields???) Actually we've talked about moving away from overloading DHCP for this stuff and instead handling it with mdns (let zeroconf be zeroconf). There is another interesting possibility we might want to look at in the medium term. We are actively working on ways to use amqp as part of our infrastructure. If a machine has an identity via a keytab and an IP address via DHCP, I imagine it's possible to retrieve the remaining necessary config information by sending a message to a known alias? This relieves the oVirt host of having to know the precise address of the management server. Something to think about at least. > 4. Initial Configuration > > When the host comes up the first time it needs to know the IP address and > password of the Ovirt Mgmt server so it can get its auth credentials set > up. Here's how a typical setup might look: > > a. Cable up the new hardware and get MAC addrs for each iface. Need > to record which MAC is for: > * management network (NOTE: should be only iface that PXE boots > if PXE is being used) > * storage network > * normal networks > (these all don't have to be separate, there could be just a single > interface on the box used for management, storage and normal traffic) > b. Set up DNS/DHCP servers. If using static addressing, skip DHCP setup > (This is a manual step that IT admin would do, i.e. we're not trying > to automate this process) > c. Boot Ovirt Host for first time. Kernel cmdline takes options like: > * ovirt_net=static (to indicate that static ip config should be > prompted for during boot) > * ovirt_auth_pw= (password to use when connecting to the > Ovirt Mgmt server to register the host and retrieve auth information) > * ovirt_init (this is specified to let the host know that initial > config needs to happen. Otherwise normal boot occurs) Getting back to the stateless idea, I think the host image should always boot exactly the same way and be smart enough to know whether it needs config information or not and, if so, ask for it? Having said that the "password" idea is reasonable except that you would always need to be there to enter the password for a reboot... > f. The host is checked for persistent storage and TPM devices. If TPM > is found it is initialized so that auth info can be stored there. > * If either USB or hard disk is found it is checked for a partition > with a label called "OVIRT". If that exists it is used for > persistent storage. If it does not, an "OVIRT" partition is created. > on available unpartitioned space. (how big should it be?) > * USB/disk is also checked for swap partition. If none is found, a > swap partition is created using unpartitioned space. Hadn't thought about using TPM for the keytab, that's a neat idea. I'm a bit leery of using any local HDD on the machine for it though. > 7. Performance Monitoring/Auditing/Health > > * collectd is used presently to send performance stats to management > server. Is this the right solution? I don't have a better one, but > suggestions are appreciated. There is some really interesting stuff going on around monitoring with amqp. At a first step we need to try to get collectd hooked into that. > * Need to create a health monitoring daemon that communicates to mgmt > server: > - Sends heartbeat at configurable interval > - Sends status changes of host (including machine check exceptions, > and other errors) > - Sends VM state changes This is where the amqp stuff might be particularly useful, although we need something in place before July (which is the earliest we can really start looking at AMQP, it sounds like). > 8. Clustering > > This probably needs a lot of refinement. So someone who knows clustering > better than I do, should feel free to help out here... I'm afraid that someone would not be me ... Take care, --Hugh From pmyers at redhat.com Mon Mar 17 17:59:14 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Mon, 17 Mar 2008 13:59:14 -0400 Subject: [Ovirt-devel] Ovirt Host Tasks In-Reply-To: <20080317154716.GA3849@redhat.com> References: <47DDE8C6.3010304@redhat.com> <20080317154716.GA3849@redhat.com> Message-ID: <47DEB172.3090701@redhat.com> Daniel P. Berrange wrote: > On Sun, Mar 16, 2008 at 11:43:02PM -0400, Perry N. Myers wrote: >> 1. Image Creation: >> >> a. Integrate whitelist functionality into the image creation >> process to reduce image size. >> b. Determine the minimal set of files that the host image needs to >> construct a baseline whitelist. > > IMHO, a pure whitelist approach is not very maintainable long term. As > we track new Fedora RPM updates, new files often appear & we'll miss them > with a pure whitelist. I'd go for a combined white/black list so we can > be broadly inclusive and only do fine grained whitelist in specific areas Agreed. I just use whitelist instead of white/black list because it's shorter to type :) >> c. Determine minimal set of kernel modules to support wide platform base >> (i.e. keep disk, net modules. remove things like sound, isdn, etc...) >> d. Construct a repeatable build process so that images can be built >> daily for testing. >> e. Construct a utility that detects the minimal set of kernel modules >> for a given platform and generates a config file that can be fed to >> the build system for generating hardware platform specific images. >> f. Construct a method for taking the generic host image and removing all >> kernel modules not applicable for a specific platform. > > I'd put e) & f) fairly low on the list, unless someone has a compelling > short term need to make a *tiny* embedded image for specific hardware. They're certainly lower on the list (hence e and f) but this may eventually be a concern for embedding the HV on hardware platforms (integrated flash). Hardware manufacturers will want to keep costs low, which means minimal HV size so their flash is as small as possible. In these cases, I'm sure they'll want customized images that only contain the kmods for their hardware. >> g. Construct a method for taking an image and adding site specific >> configuration information to it (IP addresses of Ovirt Mgmt Server and >> FreeIPA Server). This is only necessary to support hosts that require >> static IP configuration -and- do not have persistent storage to store >> configuration information. (If we decide to support static IP config >> we could make presence of persistent storage a requirement...) >> >> The goal is to get disk footprint down to something like 32, 64 or 128MB. >> The base images we build will not be hardware platform specific, so 32MB >> might be a long shot. But after step e) above, we should fit into 32MB. > > 64MB is probably a worthy immediate goal to aim for given that the current > live image is about 85 MB & we know there's stuff that can be killed. Agreed. > Again, unless we have compelling hardware use case that requires 32 MB, > I'd not bother aiming for the 32MB mark in the short-medium term. There's > other more broadly useful stuff we can do.... Agreed. >> OEM Pre-Install (will always have flash/disk storage) >> DHCP Addressing >> Flash/Disk Storage/TPM >> Auth credentials can be stored in a file or in TPM >> Static Addressing >> Flash/Disk Storage/TPM >> Auth credentials/IP config/Server IPs can be stored in a file >> If TPM is present, can be used to store auth info >> IT Install (may not have flash or disk) >> DHCP Addressing >> Flash/Disk Storage/TPM >> Auth credentials can be stored in a file or in TPM >> No Persistent Storage (CD or PXE Boot) >> Auth can be stored in host image (separate image for each host) >> (NOTE: Not secure for PXE boot. Recommend that we only allow >> CD boot in this case) >> Static Addressing >> Flash/Disk Storage/TPM >> Auth credentials/IP config/Server IPs can be stored in a file >> If TPM is present, can be used to store auth info >> No Persistent Storage (CD or PXE Boot) >> Auth/IP config/Server IPs can be stored in host image (separate >> image for each host) >> (NOTE: Not secure for PXE boot as above) > > The 2 PXE boot methods can be secure given a deployment scenario where > the network admin has a dedicated PXE management LAN for their hosts. > So PXE traffic would be separated from general guest / user traffic. > Its probably not viable to mandate separate 'management network' but > we should document it as a deployment scenario. Good point. >> 5. KVM Work >> >> * Need to work on support for Live Migration >> * Need to make sure that power management and suspend/resume of guests >> work as expected > > * dmidecode support so we can expose UUID to guest OS > * inter-VM socket family. Like AF_UNIX, but between guests (or perhaps > just between guest & host). Call it AF_VIRT or some such. Want stream > based protocol, but optionally datagram too. > > Some use cases for this: > - Fast channel to feed performance stats from guest OS to host > - Used to build the cluster fence agent > - Other... ? I'll add these to my working list. >> 7. Performance Monitoring/Auditing/Health >> >> * collectd is used presently to send performance stats to management >> server. Is this the right solution? I don't have a better one, but >> suggestions are appreciated. > > collectd is the best option I know of for flexible, lightweight monitoring > >> * libvirt talks to auditd to send audit info to FreeIPA server > > To clarify, there's no explicit depdancy chain here. Libvirt would simply > send data to the audit daemon. The audit daemon can optionally be configured > to ship data off to FreIPA. Yeah, I just mention it to make sure that we actually do that configuration of the audit daemon :) >> * Need to create a health monitoring daemon that communicates to mgmt >> server: >> - Sends heartbeat at configurable interval >> - Sends status changes of host (including machine check exceptions, >> and other errors) >> - Sends VM state changes > > This last point should arguably be supported by libvirt directly. Ok. >> 8. Clustering >> >> Physical clustering is not particularly useful in and of itself, since the >> whole point of what we're trying to do is abstract the applications from >> hardware further. > > You fundamentally need at least the fencing part of clustering on the physical > hosts. Without this you have no guarentee that the host & guests that were > running on it are actually dead. You need this guarentee before starting the > guests on a new host. I agree. I didn't say that physical clustering is not useful at all, I just said it wasn't useful by itself. The clustering solution for Ovirt will require both hardware fences on the physical hosts as well as the virtual fences provided by libvirt. >> Clustering of guests should be done. The hardware fence would be replaced >> by a paravirt driver in the guest that communicates to the host. If two >> machines A and B are clustered and on different physical hardware, A is >> the primary and B is backup. B monitors the application on A. If A >> appears to go down, B uses the PV driver to tell the host that it needs to >> kill A. The host tells libvirt that A needs to be destroyed, and that >> command is sent over libvirt comms to the physical host that is hosting A. > > The basic goal here is that the oVirt host should provide a general purpose > virtual fence device to all guests. The guest admin decides which of their > guests are in the same cluster & does some config task with the driver to > set this up. Since oVirt knows what VMs each user owns, it can validate the > config to ensure the admin isn't trying to cluster someone else's VMs. THe > driver will then provide the guest admin the ability to have one guest shoot > another guest in the head securely. The key is there must be *zero* need > for the guest admin to actually interact with the host admin. The host image > should support this all automatically, so guest admin's can setup clustering > in their guest at will. Thanks for making that more clear :) Perry From imain at redhat.com Mon Mar 17 18:55:45 2008 From: imain at redhat.com (Ian Main) Date: Mon, 17 Mar 2008 11:55:45 -0700 Subject: [Ovirt-devel] Ovirt Host Tasks In-Reply-To: <47DEB172.3090701@redhat.com> References: <47DDE8C6.3010304@redhat.com> <20080317154716.GA3849@redhat.com> <47DEB172.3090701@redhat.com> Message-ID: <20080317115545.0ee77ac0@tp.mains.net> On Mon, 17 Mar 2008 13:59:14 -0400 "Perry N. Myers" wrote: > Daniel P. Berrange wrote: > > On Sun, Mar 16, 2008 at 11:43:02PM -0400, Perry N. Myers wrote: > >> 1. Image Creation: > >> > >> a. Integrate whitelist functionality into the image creation > >> process to reduce image size. > >> b. Determine the minimal set of files that the host image needs to > >> construct a baseline whitelist. > > > > IMHO, a pure whitelist approach is not very maintainable long term. As > > we track new Fedora RPM updates, new files often appear & we'll miss them > > with a pure whitelist. I'd go for a combined white/black list so we can > > be broadly inclusive and only do fine grained whitelist in specific areas > > Agreed. I just use whitelist instead of white/black list because it's > shorter to type :) I think some thought needs to be given to being able to add to, or change the base os to allow debugging and other tools to be present in the image as well. This can probably just be done with kickstart & white/black changes. [snip] > >> g. Construct a method for taking an image and adding site specific > >> configuration information to it (IP addresses of Ovirt Mgmt Server and > >> FreeIPA Server). This is only necessary to support hosts that require > >> static IP configuration -and- do not have persistent storage to store > >> configuration information. (If we decide to support static IP config > >> we could make presence of persistent storage a requirement...) > >> > >> The goal is to get disk footprint down to something like 32, 64 or 128MB. > >> The base images we build will not be hardware platform specific, so 32MB > >> might be a long shot. But after step e) above, we should fit into 32MB. > > > > 64MB is probably a worthy immediate goal to aim for given that the current > > live image is about 85 MB & we know there's stuff that can be killed. I wonder if we should create an API for persistent storage? Given that it sounds like we'll have to support multiple options. We'll have the ovirt DB storage, no storage, flash storage, maybe vsata etc. All with its own setup and the operational difference between the DB and some kind of disk. > Agreed. > > > Again, unless we have compelling hardware use case that requires 32 MB, > > I'd not bother aiming for the 32MB mark in the short-medium term. There's > > other more broadly useful stuff we can do.... > > Agreed. I agree as well. For intitial devel purposes I'd just as soon see us develop the debug/tools image first, and then widdle it down from there as a second step. This will give us the debug image right away which I think could be useful. > >> OEM Pre-Install (will always have flash/disk storage) > >> DHCP Addressing > >> Flash/Disk Storage/TPM > >> Auth credentials can be stored in a file or in TPM > >> Static Addressing > >> Flash/Disk Storage/TPM > >> Auth credentials/IP config/Server IPs can be stored in a file > >> If TPM is present, can be used to store auth info > >> IT Install (may not have flash or disk) > >> DHCP Addressing > >> Flash/Disk Storage/TPM > >> Auth credentials can be stored in a file or in TPM > >> No Persistent Storage (CD or PXE Boot) > >> Auth can be stored in host image (separate image for each host) > >> (NOTE: Not secure for PXE boot. Recommend that we only allow > >> CD boot in this case) > >> Static Addressing > >> Flash/Disk Storage/TPM > >> Auth credentials/IP config/Server IPs can be stored in a file > >> If TPM is present, can be used to store auth info > >> No Persistent Storage (CD or PXE Boot) > >> Auth/IP config/Server IPs can be stored in host image (separate > >> image for each host) > >> (NOTE: Not secure for PXE boot as above) > > > > The 2 PXE boot methods can be secure given a deployment scenario where > > the network admin has a dedicated PXE management LAN for their hosts. > > So PXE traffic would be separated from general guest / user traffic. > > Its probably not viable to mandate separate 'management network' but > > we should document it as a deployment scenario. My only thought here is.. how do we implement all these options with a single boot image? Somehow we'd have to identify up front if persistent storage is available and then allow other options to become available for configuration (static ip etc). I also think applications should be given access to persistent storage if available. One interesting thing would be to use a union filesystem with the os image mounted read only and a writeable fs underneath (maybe only where appropriate.. eg /etc) that would be stored on persistent storage. This lets you modify the image at runtime, have your changes saved while not changing the original image.. just a thought, not sure if it'd be useful. [snip] Ian From pmyers at redhat.com Mon Mar 17 19:02:20 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Mon, 17 Mar 2008 15:02:20 -0400 Subject: [Ovirt-devel] Ovirt Host Tasks In-Reply-To: <20080317163550.GA3009@redhat.com> References: <47DDE8C6.3010304@redhat.com> <20080317163550.GA3009@redhat.com> Message-ID: <47DEC03C.1090304@redhat.com> Hugh O. Brock wrote: > On Sun, Mar 16, 2008 at 11:43:02PM -0400, Perry N. Myers wrote: > > Wow that's a big mail . > > I have a couple of general comments based on the way we *have been* > thinking about this stuff (this of course doesn't mean we can't > change). > > First off, we have been imagining the oVirt host image as stateless > except for whatever we use to store its identity (if we even do > that). This means we simply don't support static addressing of oVirt > hosts, at all. The appealing thing about a stateless oVirt host image > to me is that it means the host is immediately and easily upgradeable; > there is 0 local state to worry about aside from the Kerberos > keytab. It also means that a reboot will immediately restore a > compromised machine FWIW. > > Having said all that, if there is a compelling reason to move away > from the stateless idea I'm all ears. I'm all for getting rid of static config support. The fundamental question is, how many people would require static IP config (as opposed to static DHCP reservations)? If that is a significant number of potential users, it makes sense to support it. We can always take the approach of: implement stateless/DHCP support only and then if we get feedback from enough folks that static addressing is important enough we can try to add it in later. Unless I hear major objections, this is how I'll proceed. > Further comments in-line below... >> 1. Image Creation: >> >> Right now the Ovirt Host is created using scripts in the Ovirt host >> repository that utilize livecd creator to make ISO, USB and PXE formats. >> >> I think it makes sense to start with the tools that Chris L. has already >> been working with and migrate new functionality in, rather than starting >> with other tools. >> >> a. Integrate whitelist functionality into the image creation >> process to reduce image size. >> b. Determine the minimal set of files that the host image needs to >> construct a baseline whitelist. >> c. Determine minimal set of kernel modules to support wide platform base >> (i.e. keep disk, net modules. remove things like sound, isdn, etc...) >> d. Construct a repeatable build process so that images can be built >> daily for testing. >> e. Construct a utility that detects the minimal set of kernel modules >> for a given platform and generates a config file that can be fed to >> the build system for generating hardware platform specific images. >> f. Construct a method for taking the generic host image and removing all >> kernel modules not applicable for a specific platform. >> g. Construct a method for taking an image and adding site specific >> configuration information to it (IP addresses of Ovirt Mgmt Server and >> FreeIPA Server). This is only necessary to support hosts that require >> static IP configuration -and- do not have persistent storage to store >> configuration information. (If we decide to support static IP config >> we could make presence of persistent storage a requirement...) > > You could add "Kerberos keytab" to "site specific configuration > information" and the host image would be completely > self-contained. I can imagine a library of unique images under > /tftpboot...? I don't like the idea of having a separate PXE image for each individual host unless -absolutely- necessary. So we shouldn't encourage this. So here are some assumptions we would should make: * DHCP only * keytab/SSL cert stored in TPM if available * If TPM not available, keytab/SSL cert stored on local storage (USB/disk) * If no persistent storage available, just attach the smallest thumb drive that you have to the box. (i.e. *make* persistent storage available) >> 2. Installation >> >> We have to account for two methods of distributing Ovirt: pre-installation >> by OEMs and install by IT admins. Pre-install by OEM implies that the >> platform has flash or a reserved partition on the primary hard disk. >> Install by IT can be done by setting up PXE boot, adding an external >> bootable USB disk, booting to CD or installing to onboard flash/disk. >> >> The livecd/liveusb disk should allow either booting and running directly or >> installation onto platform flash/disk. > > That's a nice addition, yeah. Although again I'm in favor of the > running image itself remaining stateless. The image is still stateless in this scenario. It's just transferring the boot image from removable media to onboard media. Once it is transferred, you remove the usb/cd media. >> 3. Persistent Configuration Storage >> >> Since the host is non-persistent and may or may not have access to >> persistent storage, this could become tricky. It's further complicated by >> the need to support DHCP and static addressing of the host. >> >> The following things need to be stored for the host: >> a. Kerberos keytab or SSL Certificate >> b. IP configuration (if using static configuration) >> c. IP address of FreeIPA server and Ovirt Management Server (if using >> static configuration) > >> Here's where things could be much simpler if DHCP were required. Without >> static addressing, b is not necessary and c can be transmitted as custom >> DHCP fields (iirc). Then the only thing that needs to be cached on the >> host on persistent storage is the auth credentials. (NOTE: Does >> Microsoft's DHCP server allow custom DHCP fields???) > > Actually we've talked about moving away from overloading DHCP for this > stuff and instead handling it with mdns (let zeroconf be > zeroconf). Echoing conversations on the IRC channel... zeroconf/avahi is not reliable, so even on a small scale it is probably not a good idea. dhcp fields work fine, but may not play well with MS DHCP servers. So in the short term, we support sending out critical config info (ip addresses of certain servers) via dhcp fields. For environments where we can't add custom dhcp fields, perhaps we should set up well known host aliases. i.e. if the dhcp fields are not present we assume that the freeipa server is located at freeipa.domain.com (where domain.com is the domain specified in dhcp) and the ovirt mgmt server is ovirt-mgmt.domain.com. This would mean that DNS records would need to be set up for these two servers, but we're already asking people to muck with DNS so.... > There is another interesting possibility we might want to look at in the > medium term. We are actively working on ways to use amqp as part of > our infrastructure. If a machine has an identity via a keytab and an > IP address via DHCP, I imagine it's possible to retrieve the remaining > necessary config information by sending a message to a known alias? > This relieves the oVirt host of having to know the precise address of > the management server. Something to think about at least. Interesting idea. >> 4. Initial Configuration >> >> When the host comes up the first time it needs to know the IP address and >> password of the Ovirt Mgmt server so it can get its auth credentials set >> up. Here's how a typical setup might look: >> >> a. Cable up the new hardware and get MAC addrs for each iface. Need >> to record which MAC is for: >> * management network (NOTE: should be only iface that PXE boots >> if PXE is being used) >> * storage network >> * normal networks >> (these all don't have to be separate, there could be just a single >> interface on the box used for management, storage and normal traffic) >> b. Set up DNS/DHCP servers. If using static addressing, skip DHCP setup >> (This is a manual step that IT admin would do, i.e. we're not trying >> to automate this process) >> c. Boot Ovirt Host for first time. Kernel cmdline takes options like: >> * ovirt_net=static (to indicate that static ip config should be >> prompted for during boot) >> * ovirt_auth_pw= (password to use when connecting to the >> Ovirt Mgmt server to register the host and retrieve auth information) >> * ovirt_init (this is specified to let the host know that initial >> config needs to happen. Otherwise normal boot occurs) > > Getting back to the stateless idea, I think the host image should > always boot exactly the same way and be smart enough to know whether > it needs config information or not and, if so, ask for it? Having said > that the "password" idea is reasonable except that you would always > need to be there to enter the password for a reboot... The password is only used to register the host on firstboot and to securely retrieve the keytab/SSL Cert from the management server. So, if as above we eliminate the need for static IP config, we can reduce the cmdline options to: * ovirt_auth= * ovirt_auth=floppy:/keytab * ovirt_auth=hd:sdb1:/keytab So either you specify a password to contact the ovirt host for registration and keytab retrieval or you specify the location of the keytab on a floppy/usb thumbdrive (syntax similar to kickstart cmdline syntax) >> f. The host is checked for persistent storage and TPM devices. If TPM >> is found it is initialized so that auth info can be stored there. >> * If either USB or hard disk is found it is checked for a partition >> with a label called "OVIRT". If that exists it is used for >> persistent storage. If it does not, an "OVIRT" partition is created. >> on available unpartitioned space. (how big should it be?) >> * USB/disk is also checked for swap partition. If none is found, a >> swap partition is created using unpartitioned space. > > Hadn't thought about using TPM for the keytab, that's a neat idea. I'm > a bit leery of using any local HDD on the machine for it though. Why? Are you ok with using USB storage but not ok with using HDD storage? Perry From pmyers at redhat.com Mon Mar 17 19:13:20 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Mon, 17 Mar 2008 15:13:20 -0400 Subject: [Ovirt-devel] Ovirt Host Tasks In-Reply-To: <20080317115545.0ee77ac0@tp.mains.net> References: <47DDE8C6.3010304@redhat.com> <20080317154716.GA3849@redhat.com> <47DEB172.3090701@redhat.com> <20080317115545.0ee77ac0@tp.mains.net> Message-ID: <47DEC2D0.1000108@redhat.com> Ian Main wrote: > I think some thought needs to be given to being able to add to, or > change the base os to allow debugging and other tools to be present in > the image as well. This can probably just be done with kickstart & > white/black changes. That's what I was envisioning as well. > [snip] > >>>> g. Construct a method for taking an image and adding site >>>> specific configuration information to it (IP addresses of Ovirt >>>> Mgmt Server and FreeIPA Server). This is only necessary to >>>> support hosts that require static IP configuration -and- do not >>>> have persistent storage to store configuration information. (If >>>> we decide to support static IP config we could make presence of >>>> persistent storage a requirement...) >>>> >>>> The goal is to get disk footprint down to something like 32, 64 >>>> or 128MB. The base images we build will not be hardware platform >>>> specific, so 32MB might be a long shot. But after step e) above, >>>> we should fit into 32MB. >>> 64MB is probably a worthy immediate goal to aim for given that the >>> current live image is about 85 MB & we know there's stuff that can >>> be killed. > > I wonder if we should create an API for persistent storage? Given that > it sounds like we'll have to support multiple options. We'll have the > ovirt DB storage, no storage, flash storage, maybe vsata etc. All with > its own setup and the operational difference between the DB and some > kind of disk. Since we're eliminating static IP addressing, and assuming dhcp fields or DNS aliases for critical hosts there no longer is a need for persistent storage except for storing the Kerberos keytab or SSL Cert. Basically when the host boots it needs to find its key. This could be: 1. Check for TPM and check for key in TPM NVRAM at predefined index 2. If no key in TPM, check local storage for a partition labeled OVIRT and get key from well known location there That should be it. So I don't think any need for an API to encapsulate that. >> Agreed. >> >>> Again, unless we have compelling hardware use case that requires 32 >>> MB, I'd not bother aiming for the 32MB mark in the short-medium >>> term. There's other more broadly useful stuff we can do.... >> Agreed. > > I agree as well. For intitial devel purposes I'd just as soon see us > develop the debug/tools image first, and then widdle it down from there > as a second step. This will give us the debug image right away which I > think could be useful. I think in parallel is better. We start with a reasonably trimmed down kickstart/filelist and then create a debug kickstart/filelist that inherits all of the base OS files but overrides to add add'l packages/files. >>>> OEM Pre-Install (will always have flash/disk storage) DHCP >>>> Addressing Flash/Disk Storage/TPM Auth credentials can be stored >>>> in a file or in TPM Static Addressing Flash/Disk Storage/TPM Auth >>>> credentials/IP config/Server IPs can be stored in a file If TPM >>>> is present, can be used to store auth info IT Install (may not >>>> have flash or disk) DHCP Addressing Flash/Disk Storage/TPM Auth >>>> credentials can be stored in a file or in TPM No Persistent >>>> Storage (CD or PXE Boot) Auth can be stored in host image >>>> (separate image for each host) (NOTE: Not secure for PXE boot. >>>> Recommend that we only allow CD boot in this case) Static >>>> Addressing Flash/Disk Storage/TPM Auth credentials/IP >>>> config/Server IPs can be stored in a file If TPM is present, can >>>> be used to store auth info No Persistent Storage (CD or PXE Boot) >>>> Auth/IP config/Server IPs can be stored in host image (separate >>>> image for each host) (NOTE: Not secure for PXE boot as above) >>> The 2 PXE boot methods can be secure given a deployment scenario >>> where the network admin has a dedicated PXE management LAN for >>> their hosts. So PXE traffic would be separated from general guest / >>> user traffic. Its probably not viable to mandate separate >>> 'management network' but we should document it as a deployment >>> scenario. > > My only thought here is.. how do we implement all these options with a > single boot image? Somehow we'd have to identify up front if > persistent storage is available and then allow other options to become > available for configuration (static ip etc). I also think applications > should be given access to persistent storage if available. applications? There are no applications :) This is just the embedded hypervisor. There will be services for Ovirt, but these will be written to not need persistent storage, and we can assume a connected environment (i.e. we're not trying to solve the problem of mobile disconnected datacenters) > One interesting thing would be to use a union filesystem with the os > image mounted read only and a writeable fs underneath (maybe only where > appropriate.. eg /etc) that would be stored on persistent storage. > This lets you modify the image at runtime, have your changes saved > while not changing the original image.. just a thought, not sure if > it'd be useful. I don't think this is necessary given that we're only using persistent storage to store a single item. Perry From berrange at redhat.com Mon Mar 17 19:22:31 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 17 Mar 2008 19:22:31 +0000 Subject: [Ovirt-devel] Ovirt Host Tasks In-Reply-To: <47DEC2D0.1000108@redhat.com> References: <47DDE8C6.3010304@redhat.com> <20080317154716.GA3849@redhat.com> <47DEB172.3090701@redhat.com> <20080317115545.0ee77ac0@tp.mains.net> <47DEC2D0.1000108@redhat.com> Message-ID: <20080317192231.GF3849@redhat.com> On Mon, Mar 17, 2008 at 03:13:20PM -0400, Perry N. Myers wrote: > >>>>OEM Pre-Install (will always have flash/disk storage) DHCP > >>>>Addressing Flash/Disk Storage/TPM Auth credentials can be stored > >>>>in a file or in TPM Static Addressing Flash/Disk Storage/TPM Auth > >>>>credentials/IP config/Server IPs can be stored in a file If TPM > >>>>is present, can be used to store auth info IT Install (may not > >>>>have flash or disk) DHCP Addressing Flash/Disk Storage/TPM Auth > >>>>credentials can be stored in a file or in TPM No Persistent > >>>>Storage (CD or PXE Boot) Auth can be stored in host image > >>>>(separate image for each host) (NOTE: Not secure for PXE boot. > >>>>Recommend that we only allow CD boot in this case) Static > >>>>Addressing Flash/Disk Storage/TPM Auth credentials/IP > >>>>config/Server IPs can be stored in a file If TPM is present, can > >>>>be used to store auth info No Persistent Storage (CD or PXE Boot) > >>>> Auth/IP config/Server IPs can be stored in host image (separate > >>>>image for each host) (NOTE: Not secure for PXE boot as above) > >>>The 2 PXE boot methods can be secure given a deployment scenario > >>>where the network admin has a dedicated PXE management LAN for > >>>their hosts. So PXE traffic would be separated from general guest / > >>>user traffic. Its probably not viable to mandate separate > >>>'management network' but we should document it as a deployment > >>>scenario. > > > >My only thought here is.. how do we implement all these options with a > >single boot image? Somehow we'd have to identify up front if > >persistent storage is available and then allow other options to become > >available for configuration (static ip etc). I also think applications > >should be given access to persistent storage if available. > > applications? There are no applications :) This is just the embedded > hypervisor. There will be services for Ovirt, but these will be written > to not need persistent storage, and we can assume a connected environment I agree - we're not supporting people installing 3rd party applications into the oVirt host image. It is a black box providing the minimal support layer to enable virtualizing guest OS for specific pre-defined use cases. Clustering is a good example - we're not supporting clustering as something you drop in as an add-on app to the base OS. Clustering is integrated into the core oVirt host image out of the box. You loose some flexibility you'd otherwise get if you deployed clustering as an addon, but that's fine becaue we targetting a specific use case only - fencing of physical hosts only to enable oVirt to safely do failover of VMs to an alternate host. In the unlikely case that someone does want extra functionaly, then that can be built into the master image by changing the kickstart & rebuilding it. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From ssorce at redhat.com Mon Mar 17 19:24:14 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 17 Mar 2008 15:24:14 -0400 Subject: [Ovirt-devel] Ovirt Host Tasks In-Reply-To: <20080317163550.GA3009@redhat.com> References: <47DDE8C6.3010304@redhat.com> <20080317163550.GA3009@redhat.com> Message-ID: <1205781854.29600.95.camel@localhost.localdomain> On Mon, 2008-03-17 at 12:35 -0400, Hugh O. Brock wrote: > There is another interesting possibility we might want to look at in > the > medium term. We are actively working on ways to use amqp as part of > our infrastructure. If a machine has an identity via a keytab and an > IP address via DHCP, I imagine it's possible to retrieve the remaining > necessary config information by sending a message to a known alias? > This relieves the oVirt host of having to know the precise address of > the management server. Something to think about at least. Both IPA and AMQP is in need of various auto-discovery features and they will involve using DNS SRV records. I think a service record that holds the address(es) of the manager should be used. The only gotcha about using DNS is that you must either know which domain you have to bind to, or have another way to provide that. Assuming that DHCP will ship the base default domain (where IPA stores the _kerberos SRV record and I assume O-Virt may store something similar) it may all just work. But this would be quite static (and all clients would point to one single Manager for the full IPA Realm), I assume big organizations may want to have multiple instances (reliability, fault-tolerance) in different locations on the network, so perhaps supporting the full auto-discovery we are going to implement in IPA/AMQP will probably make sense. Discussion on the details of auto-discovery is open if anyone wants to chime in, as we are still deciding how to exactly implement it in terms of protocols and conventions. Simo. -- Simo Sorce * Red Hat, Inc * New York From hbrock at redhat.com Mon Mar 17 19:29:43 2008 From: hbrock at redhat.com (Hugh O. Brock) Date: Mon, 17 Mar 2008 15:29:43 -0400 Subject: [Ovirt-devel] Ovirt Host Tasks In-Reply-To: <47DEC03C.1090304@redhat.com> References: <47DDE8C6.3010304@redhat.com> <20080317163550.GA3009@redhat.com> <47DEC03C.1090304@redhat.com> Message-ID: <20080317192942.GD3009@redhat.com> On Mon, Mar 17, 2008 at 03:02:20PM -0400, Perry N. Myers wrote: > > I'm all for getting rid of static config support. The fundamental question > is, how many people would require static IP config (as opposed to static > DHCP reservations)? If that is a significant number of potential users, it > makes sense to support it. > > We can always take the approach of: implement stateless/DHCP support only > and then if we get feedback from enough folks that static addressing is > important enough we can try to add it in later. > > Unless I hear major objections, this is how I'll proceed. Yeah, that works for me. > I don't like the idea of having a separate PXE image for each individual > host unless -absolutely- necessary. So we shouldn't encourage this. > > So here are some assumptions we would should make: > > * DHCP only > * keytab/SSL cert stored in TPM if available > * If TPM not available, keytab/SSL cert stored on local storage (USB/disk) > * If no persistent storage available, just attach the smallest thumb drive > that you have to the box. (i.e. *make* persistent storage available) Yeah that works for me too with the caveat that we should allow Avahi conf as well I think... >> Hadn't thought about using TPM for the keytab, that's a neat idea. I'm >> a bit leery of using any local HDD on the machine for it though. > > Why? Are you ok with using USB storage but not ok with using HDD storage? Good question. Seems to me that ideally you want your keytab stored on read-only storage (i.e. a cdrom or a usb key with a read-only switch or TPM)... which isn't really possible for local HDD storage. Maybe this is stupidly paranoid or just doesn't make any sense though. Let me know, --H From pmyers at redhat.com Mon Mar 17 19:34:21 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Mon, 17 Mar 2008 15:34:21 -0400 Subject: [Ovirt-devel] Ovirt Host Tasks In-Reply-To: <20080317192942.GD3009@redhat.com> References: <47DDE8C6.3010304@redhat.com> <20080317163550.GA3009@redhat.com> <47DEC03C.1090304@redhat.com> <20080317192942.GD3009@redhat.com> Message-ID: <47DEC7BD.6090000@redhat.com> Hugh O. Brock wrote: > Good question. Seems to me that ideally you want your keytab stored on > read-only storage (i.e. a cdrom or a usb key with a read-only > switch or TPM)... which isn't really possible for local HDD storage. Maybe > this is stupidly paranoid or just doesn't make any sense though. Hmm. That is a good point but... Not all USB thumbdrives have read/write toggles. We can of course mandate that only this type of thumbdrive should be used. (But that's just a suggestion, I don't think we should enforce it with code) And onboard flash... The platforms would need to have a way of toggling write access to platform flash. This is something that would have to be worked out with hardware vendors. But in general I agree with your thoughts on this. Perry From imain at redhat.com Mon Mar 17 20:29:48 2008 From: imain at redhat.com (Ian Main) Date: Mon, 17 Mar 2008 13:29:48 -0700 Subject: [Ovirt-devel] Ovirt Host Tasks In-Reply-To: <20080317192231.GF3849@redhat.com> References: <47DDE8C6.3010304@redhat.com> <20080317154716.GA3849@redhat.com> <47DEB172.3090701@redhat.com> <20080317115545.0ee77ac0@tp.mains.net> <47DEC2D0.1000108@redhat.com> <20080317192231.GF3849@redhat.com> Message-ID: <20080317132948.6de02223@tp.mains.net> Very good, thanks for the clarifications guys. Ian From rjones at redhat.com Mon Mar 17 21:04:17 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 17 Mar 2008 21:04:17 +0000 Subject: [Ovirt-devel] Book on RoR Message-ID: <20080317210340.GA29781@amd.home.annexia.org> Just reviewed on slashdot: http://books.slashdot.org/article.pl?sid=08/03/17/138205 Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From pmyers at redhat.com Thu Mar 20 04:06:48 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Thu, 20 Mar 2008 00:06:48 -0400 Subject: [Ovirt-devel] [PATCH] some cleanup of ovirt-host kickstart to make images smaller Message-ID: <47E1E2D8.2010001@redhat.com> This patch adds --excludedocs to the kickstart for the x86_64 and i386 ovirt host kickstarts. For the most part we're removing docs manually right now anyhow, but this may catch some other things. Also cleaned up the section that removes docs and localization. Recreate the cracklib dicts (frees up about 8MB) and remove unneeded kernel modules. Most of this stuff will just end up in the whitelist/blacklist module, but the cracklib stuff is a different issue. They can't be removed, they need to be recreated. This will probably need to continue to happen in %post. The end result of this cleanup is that the image boots and it is 58MB compressed/162MB uncompressed (filesystem is 450MB total) One of the things we need to fix is the filesystem total size. The filesystem doesn't need to be 450MB. It could be initially created as 450MB and then resized to 200MB or less. Signed-off-by: Perry Myers -------------- next part -------------- A non-text attachment was scrubbed... Name: image-minimization.patch Type: text/x-patch Size: 3865 bytes Desc: not available URL: From jim at meyering.net Thu Mar 20 08:13:44 2008 From: jim at meyering.net (Jim Meyering) Date: Thu, 20 Mar 2008 09:13:44 +0100 Subject: [Ovirt-devel] [PATCH] some cleanup of ovirt-host kickstart to make images smaller In-Reply-To: <47E1E2D8.2010001@redhat.com> (Perry N. Myers's message of "Thu, 20 Mar 2008 00:06:48 -0400") References: <47E1E2D8.2010001@redhat.com> Message-ID: <87hcf1hkxz.fsf@rho.meyering.net> "Perry N. Myers" wrote: > This patch adds --excludedocs to the kickstart for the x86_64 and i386 > ovirt host kickstarts. For the most part we're removing docs manually > right now anyhow, but this may catch some other things. ... > diff --git a/ovirt-host-creator/common-post.ks b/ovirt-host-creator/common-post.ks > index 8c9f090..308aaac 100644 > --- a/ovirt-host-creator/common-post.ks > +++ b/ovirt-host-creator/common-post.ks > @@ -162,6 +162,7 @@ fi > > g=$(printf '\33[1m\33[32m') # similar to g=$(tput bold; tput setaf 2) > n=$(printf '\33[m') # similar to n=$(tput sgr0) > +mkdir -p /t > cat < /t/i2 > > 888 888 ${g}d8b$n 888 Hi Perry, Thanks for noticing the debug-redirection I used when testing a recent change. I've just pushed the following, to remove it: Remove debugging-redirect to temp file added in 87dfab3abb32e498739d8d82036bd22f729d4d47. diff --git a/ovirt-host-creator/common-post.ks b/ovirt-host-creator/common-post.ks index 8c9f090..a34877a 100644 --- a/ovirt-host-creator/common-post.ks +++ b/ovirt-host-creator/common-post.ks @@ -162,7 +162,7 @@ fi g=$(printf '\33[1m\33[32m') # similar to g=$(tput bold; tput setaf 2) n=$(printf '\33[m') # similar to n=$(tput sgr0) -cat < /t/i2 +cat < (Perry N. Myers's message of "Thu, 20 Mar 2008 00:06:48 -0400") References: <47E1E2D8.2010001@redhat.com> Message-ID: <87bq59hjxe.fsf@rho.meyering.net> "Perry N. Myers" wrote: > This patch adds --excludedocs to the kickstart for the x86_64 and i386 > ovirt host kickstarts. For the most part we're removing docs manually > right now anyhow, but this may catch some other things. > > Also cleaned up the section that removes docs and localization. > Recreate the cracklib dicts (frees up about 8MB) and remove unneeded > kernel modules. Most of this stuff will just end up in the > whitelist/blacklist module, but the cracklib stuff is a different > issue. They can't be removed, they need to be recreated. This will > probably need to continue to happen in %post. > > The end result of this cleanup is that the image boots and it is 58MB > compressed/162MB uncompressed (filesystem is 450MB total) ... Nice decrease. > diff --git a/ovirt-host-creator/common-post.ks b/ovirt-host-creator/common-post.ks > index 8c9f090..308aaac 100644 > --- a/ovirt-host-creator/common-post.ks > +++ b/ovirt-host-creator/common-post.ks ... > -find /usr/share/i18n/locales -type f ! -iname en_US -exec rm -f {} \; ... > +find /usr/share/i18n/locales -type f ! -name en_us -exec $RM {} \; Won't the new find command remove the entire /usr/share/i18n/locales hierarchy? Maybe that's ok in practice, if we're sure to work in the C locale (in which case, don't bother with find, and just use rm -rf /usr/share/i18n/locales). Otherwise, on at least the rawhide, FC6 and RHEL4.6 systems I checked, the directory is named /usr/share/i18n/locales/en_US. BTW, since they're always "-type f", there's no need to change the rm -f to "rm -rf". From pmyers at redhat.com Thu Mar 20 13:26:00 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Thu, 20 Mar 2008 09:26:00 -0400 Subject: [Ovirt-devel] [PATCH] some cleanup of ovirt-host kickstart to make images smaller In-Reply-To: <87hcf1hkxz.fsf@rho.meyering.net> References: <47E1E2D8.2010001@redhat.com> <87hcf1hkxz.fsf@rho.meyering.net> Message-ID: <47E265E8.2000603@redhat.com> Jim Meyering wrote: > Hi Perry, > > Thanks for noticing the debug-redirection I used when testing a > recent change. I've just pushed the following, to remove it: Yeah, I was wondering why that was redirected as so. I just figured it had some purpose that I didn't yet understand :) Thanks, Perry From pmyers at redhat.com Thu Mar 20 13:38:20 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Thu, 20 Mar 2008 09:38:20 -0400 Subject: [Ovirt-devel] [PATCH] some cleanup of ovirt-host kickstart to make images smaller In-Reply-To: <87bq59hjxe.fsf@rho.meyering.net> References: <47E1E2D8.2010001@redhat.com> <87bq59hjxe.fsf@rho.meyering.net> Message-ID: <47E268CC.7020300@redhat.com> Jim Meyering wrote: > Maybe that's ok in practice, if we're sure to work > in the C locale (in which case, don't bother with find, and just > use rm -rf /usr/share/i18n/locales). Otherwise, on at least the > rawhide, FC6 and RHEL4.6 systems I checked, the directory is named > /usr/share/i18n/locales/en_US. I'm ok using C locale. I'll change it to a straight rm -Rf as you suggest. Perry -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=| From clalance at redhat.com Thu Mar 20 13:40:03 2008 From: clalance at redhat.com (Chris Lalancette) Date: Thu, 20 Mar 2008 09:40:03 -0400 Subject: [Ovirt-devel] [PATCH] some cleanup of ovirt-host kickstart to make images smaller In-Reply-To: <47E1E2D8.2010001@redhat.com> References: <47E1E2D8.2010001@redhat.com> Message-ID: <47E26933.2070704@redhat.com> Perry N. Myers wrote: > This patch adds --excludedocs to the kickstart for the x86_64 and i386 > ovirt host kickstarts. For the most part we're removing docs manually > right now anyhow, but this may catch some other things. > > Also cleaned up the section that removes docs and localization. Recreate > the cracklib dicts (frees up about 8MB) and remove unneeded kernel > modules. Most of this stuff will just end up in the whitelist/blacklist > module, but the cracklib stuff is a different issue. They can't be > removed, they need to be recreated. This will probably need to continue > to happen in %post. > > The end result of this cleanup is that the image boots and it is 58MB > compressed/162MB uncompressed (filesystem is 450MB total) > > One of the things we need to fix is the filesystem total size. The > filesystem doesn't need to be 450MB. It could be initially created as > 450MB and then resized to 200MB or less. It looks good to me....just remove the mkdir -p /t (since Jim pushed a fix for that), and remove all of the locales (going with C locale), and I think it is good. Chris Lalancette From pmyers at redhat.com Thu Mar 20 14:49:33 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Thu, 20 Mar 2008 10:49:33 -0400 Subject: [Ovirt-devel] [PATCH] repost: some cleanup of ovirt-host kickstart to make images smaller In-Reply-To: <47E1E2D8.2010001@redhat.com> References: <47E1E2D8.2010001@redhat.com> Message-ID: <47E2797D.7050205@redhat.com> Perry N. Myers wrote: > This patch adds --excludedocs to the kickstart for the x86_64 and i386 > ovirt host kickstarts. For the most part we're removing docs manually > right now anyhow, but this may catch some other things. > > Also cleaned up the section that removes docs and localization. > Recreate the cracklib dicts (frees up about 8MB) and remove unneeded > kernel modules. Most of this stuff will just end up in the > whitelist/blacklist module, but the cracklib stuff is a different > issue. They can't be removed, they need to be recreated. This will > probably need to continue to happen in %post. > > The end result of this cleanup is that the image boots and it is 58MB > compressed/162MB uncompressed (filesystem is 450MB total) > > One of the things we need to fix is the filesystem total size. The > filesystem doesn't need to be 450MB. It could be initially created as > 450MB and then resized to 200MB or less. > > Signed-off-by: Perry Myers Changed to remove /usr/share/i18n completely, added back sunrpc modules and merged with Jim's fix for removing debugging statements. Signed-off-by: Perry Myers -------------- next part -------------- A non-text attachment was scrubbed... Name: image-minimization.patch Type: text/x-patch Size: 3461 bytes Desc: not available URL: From mmorsi at redhat.com Thu Mar 20 15:34:49 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Thu, 20 Mar 2008 11:34:49 -0400 Subject: [Ovirt-devel] oVirt wui appliance sanity check script Message-ID: <47E28419.9080001@redhat.com> Attached is my first stab at the post-kickstart sanity check bash script. It is syntactically correct though I haven't been able to test it on a live-appliance to make sure all the tests succeed. There are a few hanging todo's in the script but I can finish those tommorow. If you have any comments or suggestions or patches, feel free to send em. -Mo -------------- next part -------------- A non-text attachment was scrubbed... Name: test-sanity.sh Type: application/x-shellscript Size: 6968 bytes Desc: not available URL: From mwagner at redhat.com Mon Mar 24 03:12:10 2008 From: mwagner at redhat.com (mark wagner) Date: Sun, 23 Mar 2008 23:12:10 -0400 Subject: [Ovirt-devel] [Patch] Make iscsi targets for the developer versions Message-ID: <47E71C0A.4070203@redhat.com> Please review the attached patch. It should make some small iscsi targets for the developer versions of the wui. It is not anticipated that these devices will actually be used to hold any data so they are really small, although they are set to "grow" if there is a need for space. I also append the commands to the rc.local file in order to properly configure and share them on startup. tgtadm does not use a config file so things are hardcoded for now. Note that these patches *should* be based on the release branch that Chris is working on. -mark -------------- next part -------------- A non-text attachment was scrubbed... Name: iscsi-devel.patch Type: text/x-patch Size: 3951 bytes Desc: not available URL: From clalance at redhat.com Mon Mar 24 13:27:01 2008 From: clalance at redhat.com (Chris Lalancette) Date: Mon, 24 Mar 2008 09:27:01 -0400 Subject: [Ovirt-devel] Release 0.3 of oVirt Message-ID: <47E7AC25.6000203@redhat.com> I'm pleased to announce release 0.3 of oVirt. Big changes in this release include: * Developer mode, for vastly simplified installation/usage * Integration with the libvirt storage API's for flexible storage configuration * i386 and x86_64 support * New, spiffy UI Installation instructions for quickstart are available at http://ovirt.org/devel-install.html To checkout this release from the source repository, you'll want to: $ git clone git://git.et.redhat.com/ovirt.git $ cd ovirt $ git checkout --track -b release-0.3 origin/release-0.3 Thanks to everyone who contributed ideas, patches, and documentation! From clalance at redhat.com Mon Mar 24 13:52:17 2008 From: clalance at redhat.com (Chris Lalancette) Date: Mon, 24 Mar 2008 09:52:17 -0400 Subject: [Ovirt-devel] [PATCH] repost: some cleanup of ovirt-host kickstart to make images smaller In-Reply-To: <47E2797D.7050205@redhat.com> References: <47E1E2D8.2010001@redhat.com> <47E2797D.7050205@redhat.com> Message-ID: <47E7B211.7020207@redhat.com> Not to nitpick, but a couple of things.... Perry N. Myers wrote: > > Changed to remove /usr/share/i18n completely, added back sunrpc modules > and merged with Jim's fix for removing debugging statements. > +fs_mods="9p affs autofs autofs4 befs bfs cifs coda configfs cramfs dlm \ ^^ I'm not entirely sure what exactly needs configfs in the kernel, but it seems to be one that we might want to keep around > + ecryptfs efs exportfs freevxfs fuse gfs2 hfs hfsplus jbd jbd2 \ > + jffs jfs minix ncpfs ocfs2 qnx4 reiserfs romfs sysv udf ufs xfs" > +for dir in $fs_mods ; do > + $RM $MODULES/fs/$dir > +done > + > +net_mods="802 8021q 9p appletalk atm ax25 bluetooth dccp decnet \ > + ieee80211 ipx irda mac80211 netrom rfkill rose sched \ > + sctp tipc wanrouter wireless" ^^ At one point the clustering stuff was using some SCTP code, so we might want to leave this around. > +for dir in $net_mods ; do > + $RM $MODULES/net/$dir > +done > + > +driver_mods="bluetooth firewire i2c isdn media edac" ^^ Probably something we eventually will want to report back to the management server (via collectd), so we should probably keep these modules too. > +for dir in $driver_mods ; do > + $RM $MODULES/drivers/$dir > +done Otherwise, the patch looks fine. If you do change the above, I don't really need to see an updated patch....just commit it. Thanks, Chris Lalancette From clalance at redhat.com Mon Mar 24 14:09:05 2008 From: clalance at redhat.com (Chris Lalancette) Date: Mon, 24 Mar 2008 10:09:05 -0400 Subject: [Ovirt-devel] [Patch] Make iscsi targets for the developer versions In-Reply-To: <47E71C0A.4070203@redhat.com> References: <47E71C0A.4070203@redhat.com> Message-ID: <47E7B601.3070008@redhat.com> A few things about this patch: mark wagner wrote: > Please review the attached patch. It should make some small iscsi targets for the developer versions > of the wui. > > It is not anticipated that these devices will actually be used to hold any data so they are really > small, although they are set to "grow" if there is a need for space. > > I also append the commands to the rc.local file in order to properly configure and share them on > startup. tgtadm does not use a config file so things are hardcoded for now. > > Note that these patches *should* be based on the release branch that Chris is working on. > %include common-lvm.ks > > +# Create some fake iSCSI partitions > +logvol /iscsi1 --name=iSCSI1 --vgname=VolGroup00 --size=64 --grow > +logvol /iscsi2 --name=iSCSI2 --vgname=VolGroup00 --size=64 --grow > +logvol /iscsi3 --name=iSCSI3 --vgname=VolGroup00 --size=64 --grow > + The above stuff should go into "common-lvm.ks"; that way, you don't have to repeat this information for i386 and x86_64 kickstarts. > %include common-lvm.ks > +# Create some fake iSCSI partitions > +logvol /iscsi1 --name=iSCSI1 --vgname=VolGroup00 --size=64 --grow > +logvol /iscsi2 --name=iSCSI2 --vgname=VolGroup00 --size=64 --grow > +logvol /iscsi3 --name=iSCSI3 --vgname=VolGroup00 --size=64 --grow This goes with the above comment of common-lvm.ks > +# Setup the iscsi stuff to be ready on each boot. Since tgtadm does not use a config file > +# append what we need to the rc.local file. Note that this for the developers version only. > + > +cat >> /etc/rc.d/rc.local << \EOF > +# > +# Set up the fake iscsi targets > +tgtadm --lld iscsi --op new --mode target --tid 1 -T node3:disk1 > +tgtadm --lld iscsi --op new --mode target --tid 1 -T node4:disk1 > +tgtadm --lld iscsi --op new --mode target --tid 1 -T node5:disk1 > +# > +# Now associate them to the LVs > +# > +tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /dev/VolGroup00/iSCSI1 > +tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 2 -b /dev/VolGroup00/iSCSI2 > +tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 3 -b /dev/VolGroup00/iSCSI3 > +# > +# Now make them available > +# My understanding of the iscsi target is admittedly weak, but I'm not sure this is what you want to do. As I understand it, this will actually only create one target (node5:disk1), with 3 LUN's, because you are overriding the tid in the top 3 lines. I think what you probably want is one target per host, and then one LUN per target, so your commands would look something like: tgtadm --lld iscsi --op new --mode target --tid 1 -T node3:disk1 tgtadm --lld iscsi --op new --mode target --tid 2 -T node4:disk1 tgtadm --lld iscsi --op new --mode target --tid 3 -T node5:disk1 tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /dev/VolGroup00/iSCSI1 tgtadm --lld iscsi --op new --mode logicalunit --tid 2 --lun 1 -b /dev/VolGroup00/iSCSI2 tgtadm --lld iscsi --op new --mode logicalunit --tid 3 --lun 1 -b /dev/VolGroup00/iSCSI3 That is, have a different tid per target, and then have each of the /dev/VolGroup00/iSCSI? be LUN 1 on each target. If you do it that way, then, you might want to change the name of the logical volumes to "iSCSI3", "iSCSI4", "iSCSI5", so that they match up with their target names. Chris Lalancette From berrange at redhat.com Mon Mar 24 14:33:34 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 24 Mar 2008 14:33:34 +0000 Subject: [Ovirt-devel] [Patch] Make iscsi targets for the developer versions In-Reply-To: <47E7B601.3070008@redhat.com> References: <47E71C0A.4070203@redhat.com> <47E7B601.3070008@redhat.com> Message-ID: <20080324143334.GB23440@redhat.com> On Mon, Mar 24, 2008 at 10:09:05AM -0400, Chris Lalancette wrote: > A few things about this patch: > > mark wagner wrote: > > Please review the attached patch. It should make some small iscsi targets for the developer versions > > of the wui. > > > > It is not anticipated that these devices will actually be used to hold any data so they are really > > small, although they are set to "grow" if there is a need for space. > > > > I also append the commands to the rc.local file in order to properly configure and share them on > > startup. tgtadm does not use a config file so things are hardcoded for now. > > > > Note that these patches *should* be based on the release branch that Chris is working on. > > > > > %include common-lvm.ks > > > > +# Create some fake iSCSI partitions > > +logvol /iscsi1 --name=iSCSI1 --vgname=VolGroup00 --size=64 --grow > > +logvol /iscsi2 --name=iSCSI2 --vgname=VolGroup00 --size=64 --grow > > +logvol /iscsi3 --name=iSCSI3 --vgname=VolGroup00 --size=64 --grow > > + > > The above stuff should go into "common-lvm.ks"; that way, you don't have to > repeat this information for i386 and x86_64 kickstarts. > > > > > %include common-lvm.ks > > +# Create some fake iSCSI partitions > > +logvol /iscsi1 --name=iSCSI1 --vgname=VolGroup00 --size=64 --grow > > +logvol /iscsi2 --name=iSCSI2 --vgname=VolGroup00 --size=64 --grow > > +logvol /iscsi3 --name=iSCSI3 --vgname=VolGroup00 --size=64 --grow > > This goes with the above comment of common-lvm.ks > > > > > +# Setup the iscsi stuff to be ready on each boot. Since tgtadm does not use a config file > > +# append what we need to the rc.local file. Note that this for the developers version only. > > + > > +cat >> /etc/rc.d/rc.local << \EOF > > +# > > +# Set up the fake iscsi targets > > +tgtadm --lld iscsi --op new --mode target --tid 1 -T node3:disk1 > > +tgtadm --lld iscsi --op new --mode target --tid 1 -T node4:disk1 > > +tgtadm --lld iscsi --op new --mode target --tid 1 -T node5:disk1 > > +# > > +# Now associate them to the LVs > > +# > > +tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /dev/VolGroup00/iSCSI1 > > +tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 2 -b /dev/VolGroup00/iSCSI2 > > +tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 3 -b /dev/VolGroup00/iSCSI3 > > +# > > +# Now make them available > > +# > > My understanding of the iscsi target is admittedly weak, but I'm not sure this > is what you want to do. As I understand it, this will actually only create one > target (node5:disk1), with 3 LUN's, because you are overriding the tid in the > top 3 lines. I think what you probably want is one target per host, and then > one LUN per target, so your commands would look something like: Nah, you want the same target on all hosts so you can do migration and still see the same storage. So one target, with 3 LUNS is a good setup IMHO. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From mwagner at redhat.com Mon Mar 24 14:44:28 2008 From: mwagner at redhat.com (mark wagner) Date: Mon, 24 Mar 2008 10:44:28 -0400 Subject: [Ovirt-devel] [Patch] Make iscsi targets for the developer versions In-Reply-To: <47E7B601.3070008@redhat.com> References: <47E71C0A.4070203@redhat.com> <47E7B601.3070008@redhat.com> Message-ID: <47E7BE4C.5030606@redhat.com> A few comments inline -mark Chris Lalancette wrote: > A few things about this patch: > > mark wagner wrote: > >> Please review the attached patch. It should make some small iscsi targets for the developer versions >> of the wui. >> >> It is not anticipated that these devices will actually be used to hold any data so they are really >> small, although they are set to "grow" if there is a need for space. >> >> I also append the commands to the rc.local file in order to properly configure and share them on >> startup. tgtadm does not use a config file so things are hardcoded for now. >> >> Note that these patches *should* be based on the release branch that Chris is working on. >> > > > > >> %include common-lvm.ks >> >> +# Create some fake iSCSI partitions >> +logvol /iscsi1 --name=iSCSI1 --vgname=VolGroup00 --size=64 --grow >> +logvol /iscsi2 --name=iSCSI2 --vgname=VolGroup00 --size=64 --grow >> +logvol /iscsi3 --name=iSCSI3 --vgname=VolGroup00 --size=64 --grow >> + >> > > The above stuff should go into "common-lvm.ks"; that way, you don't have to > repeat this information for i386 and x86_64 kickstarts. > I did not add them to the common-lvm.ks file because that would create the volumes on the non-developer version as well. Didn't think that we wanted them there. I can change the location if that is what we want. > > > >> %include common-lvm.ks >> +# Create some fake iSCSI partitions >> +logvol /iscsi1 --name=iSCSI1 --vgname=VolGroup00 --size=64 --grow >> +logvol /iscsi2 --name=iSCSI2 --vgname=VolGroup00 --size=64 --grow >> +logvol /iscsi3 --name=iSCSI3 --vgname=VolGroup00 --size=64 --grow >> > > This goes with the above comment of common-lvm.ks > > See above > > > >> +# Setup the iscsi stuff to be ready on each boot. Since tgtadm does not use a config file >> +# append what we need to the rc.local file. Note that this for the developers version only. >> + >> +cat >> /etc/rc.d/rc.local << \EOF >> +# >> +# Set up the fake iscsi targets >> +tgtadm --lld iscsi --op new --mode target --tid 1 -T node3:disk1 >> +tgtadm --lld iscsi --op new --mode target --tid 1 -T node4:disk1 >> +tgtadm --lld iscsi --op new --mode target --tid 1 -T node5:disk1 >> +# >> +# Now associate them to the LVs >> +# >> +tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /dev/VolGroup00/iSCSI1 >> +tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 2 -b /dev/VolGroup00/iSCSI2 >> +tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 3 -b /dev/VolGroup00/iSCSI3 >> +# >> +# Now make them available >> +# >> > > My understanding of the iscsi target is admittedly weak, but I'm not sure this > is what you want to do. As I understand it, this will actually only create one > target (node5:disk1), with 3 LUN's, because you are overriding the tid in the > top 3 lines. I think what you probably want is one target per host, and then > one LUN per target, so your commands would look something like: > > tgtadm --lld iscsi --op new --mode target --tid 1 -T node3:disk1 > tgtadm --lld iscsi --op new --mode target --tid 2 -T node4:disk1 > tgtadm --lld iscsi --op new --mode target --tid 3 -T node5:disk1 > > tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b > /dev/VolGroup00/iSCSI1 > tgtadm --lld iscsi --op new --mode logicalunit --tid 2 --lun 1 -b > /dev/VolGroup00/iSCSI2 > tgtadm --lld iscsi --op new --mode logicalunit --tid 3 --lun 1 -b > /dev/VolGroup00/iSCSI3 > > That is, have a different tid per target, and then have each of the > /dev/VolGroup00/iSCSI? be LUN 1 on each target. If you do it that way, then, > you might want to change the name of the logical volumes to "iSCSI3", "iSCSI4", > "iSCSI5", so that they match up with their target names. > > My understanding is also very weak as this is the first time I've used the tgtadm stuff. I found little online on using multiple targets and the docs don't help much either. I just saw Dan's email as well and can wait until for people to weigh in. I will admit I was a flip-flopper on the naming. I originally had the volumes and mount points named to match the nodes but then my OCD forced me to change them to look "cleaner" as starting at iscsi3 just felt dirty to me...:) But its no problem to change them to match the nodes. -mark > Chris Lalancette > From clalance at redhat.com Mon Mar 24 15:07:26 2008 From: clalance at redhat.com (Chris Lalancette) Date: Mon, 24 Mar 2008 11:07:26 -0400 Subject: [Ovirt-devel] [Patch] Make iscsi targets for the developer versions In-Reply-To: <20080324143334.GB23440@redhat.com> References: <47E71C0A.4070203@redhat.com> <47E7B601.3070008@redhat.com> <20080324143334.GB23440@redhat.com> Message-ID: <47E7C3AE.1020300@redhat.com> Daniel P. Berrange wrote: >> My understanding of the iscsi target is admittedly weak, but I'm not sure this >> is what you want to do. As I understand it, this will actually only create one >> target (node5:disk1), with 3 LUN's, because you are overriding the tid in the >> top 3 lines. I think what you probably want is one target per host, and then >> one LUN per target, so your commands would look something like: > > Nah, you want the same target on all hosts so you can do migration and still > see the same storage. So one target, with 3 LUNS is a good setup IMHO. Duh. Excellent point. Sounds like a good setup to me as well. Chris Lalancette From mwagner at redhat.com Tue Mar 25 02:29:50 2008 From: mwagner at redhat.com (mark wagner) Date: Mon, 24 Mar 2008 22:29:50 -0400 Subject: [Ovirt-devel] [Patch] Make iscsi targets for the developer versions In-Reply-To: <47E7C3AE.1020300@redhat.com> References: <47E71C0A.4070203@redhat.com> <47E7B601.3070008@redhat.com> <20080324143334.GB23440@redhat.com> <47E7C3AE.1020300@redhat.com> Message-ID: <47E8639E.4070700@redhat.com> So from poking around a bit, with a single "tid" everything really gets rolled into one target (where target is node3:disk1) Multiple tids allows for different targets. I've included tgtadm show data below for comparison. I can code it either way. Just let me know which way we want it. -mark With a single tid: [root at management ~]# tgtadm --lld iscsi --mode=target --op=show Target 1: node3:disk1 System information: Driver: iscsi Status: running I_T nexus information: LUN information: LUN: 0 Type: controller SCSI ID: deadbeaf1:0 SCSI SN: beaf10 Size: 0 Online: No Poweron/Reset: Yes Removable media: No Backing store: No backing store LUN: 1 Type: disk SCSI ID: deadbeaf1:1 SCSI SN: beaf11 Size: 256M Online: Yes Poweron/Reset: Yes Removable media: No Backing store: /dev/VolGroup00/iSCSI3 LUN: 2 Type: disk SCSI ID: deadbeaf1:2 SCSI SN: beaf12 Size: 256M Online: Yes Poweron/Reset: Yes Removable media: No Backing store: /dev/VolGroup00/iSCSI4 LUN: 3 Type: disk SCSI ID: deadbeaf1:3 SCSI SN: beaf13 Size: 288M Online: Yes Poweron/Reset: Yes Removable media: No Backing store: /dev/VolGroup00/iSCSI5 Account information: ACL information: ALL With multiple tids we get this: [root at management ~]# tgtadm --lld iscsi --mode=target --op=show Target 1: node3:disk1 System information: Driver: iscsi Status: running I_T nexus information: LUN information: LUN: 0 Type: controller SCSI ID: deadbeaf1:0 SCSI SN: beaf10 Size: 0 Online: No Poweron/Reset: Yes Removable media: No Backing store: No backing store LUN: 1 Type: disk SCSI ID: deadbeaf1:1 SCSI SN: beaf11 Size: 256M Online: Yes Poweron/Reset: Yes Removable media: No Backing store: /dev/VolGroup00/iSCSI3 Account information: ACL information: ALL Target 2: node4:disk1 System information: Driver: iscsi Status: running I_T nexus information: LUN information: LUN: 0 Type: controller SCSI ID: deadbeaf2:0 SCSI SN: beaf20 Size: 0 Online: No Poweron/Reset: Yes Removable media: No Backing store: No backing store LUN: 1 Type: disk SCSI ID: deadbeaf2:1 SCSI SN: beaf21 Size: 256M Online: Yes Poweron/Reset: Yes Removable media: No Backing store: /dev/VolGroup00/iSCSI4 Account information: ACL information: ALL Target 3: node5:disk1 System information: Driver: iscsi Status: running I_T nexus information: LUN information: LUN: 0 Type: controller SCSI ID: deadbeaf3:0 SCSI SN: beaf30 Size: 0 Online: No Poweron/Reset: Yes Removable media: No Backing store: No backing store LUN: 1 Type: disk SCSI ID: deadbeaf3:1 SCSI SN: beaf31 Size: 288M Online: Yes Poweron/Reset: Yes Removable media: No Backing store: /dev/VolGroup00/iSCSI5 Account information: ACL information: ALL [root at management ~]# Chris Lalancette wrote: > Daniel P. Berrange wrote: >>> My understanding of the iscsi target is admittedly weak, but I'm not sure this >>> is what you want to do. As I understand it, this will actually only create one >>> target (node5:disk1), with 3 LUN's, because you are overriding the tid in the >>> top 3 lines. I think what you probably want is one target per host, and then >>> one LUN per target, so your commands would look something like: >> Nah, you want the same target on all hosts so you can do migration and still >> see the same storage. So one target, with 3 LUNS is a good setup IMHO. > > Duh. Excellent point. Sounds like a good setup to me as well. > > Chris Lalancette From clalance at redhat.com Tue Mar 25 04:12:05 2008 From: clalance at redhat.com (Chris Lalancette) Date: Tue, 25 Mar 2008 00:12:05 -0400 Subject: [Ovirt-devel] [Patch] Make iscsi targets for the developer versions In-Reply-To: <47E8639E.4070700@redhat.com> References: <47E71C0A.4070203@redhat.com> <47E7B601.3070008@redhat.com> <20080324143334.GB23440@redhat.com> <47E7C3AE.1020300@redhat.com> <47E8639E.4070700@redhat.com> Message-ID: <47E87B95.4060808@redhat.com> mark wagner wrote: > So from poking around a bit, with a single "tid" everything really gets rolled into one target > (where target is node3:disk1) Multiple tids allows for different targets. I've included tgtadm show > data below for comparison. I can code it either way. Just let me know which way we want it. Right. I think what danpb proposed is best. Just pick a single target name (something like management-iscsi), and then export multiple LUNs from that single tid/target name. Chris Lalancette From mwagner at redhat.com Tue Mar 25 12:53:15 2008 From: mwagner at redhat.com (mark wagner) Date: Tue, 25 Mar 2008 08:53:15 -0400 Subject: [Ovirt-devel] [Patch] Make iscsi targets for the developer versions In-Reply-To: <47E87B95.4060808@redhat.com> References: <47E71C0A.4070203@redhat.com> <47E7B601.3070008@redhat.com> <20080324143334.GB23440@redhat.com> <47E7C3AE.1020300@redhat.com> <47E8639E.4070700@redhat.com> <47E87B95.4060808@redhat.com> Message-ID: <47E8F5BB.10601@redhat.com> Chris Lalancette wrote: > mark wagner wrote: >> So from poking around a bit, with a single "tid" everything really gets rolled into one target >> (where target is node3:disk1) Multiple tids allows for different targets. I've included tgtadm show >> data below for comparison. I can code it either way. Just let me know which way we want it. > > Right. I think what danpb proposed is best. Just pick a single target > name (something like management-iscsi), and then export multiple LUNs > from that single tid/target name. > > Chris Lalancette How does the wui treat the LUNs at this point ? They are no longer available as a selection when specifying the storage. When using a single tid everything is presented as the same host:target but with different LUN number. So combining the wui changes with how we want to present the storage seems incompatible. -mark From clalance at redhat.com Tue Mar 25 12:57:18 2008 From: clalance at redhat.com (Chris Lalancette) Date: Tue, 25 Mar 2008 08:57:18 -0400 Subject: [Ovirt-devel] [Patch] Make iscsi targets for the developer versions In-Reply-To: <47E8F5BB.10601@redhat.com> References: <47E71C0A.4070203@redhat.com> <47E7B601.3070008@redhat.com> <20080324143334.GB23440@redhat.com> <47E7C3AE.1020300@redhat.com> <47E8639E.4070700@redhat.com> <47E87B95.4060808@redhat.com> <47E8F5BB.10601@redhat.com> Message-ID: <47E8F6AE.9020709@redhat.com> mark wagner wrote: > > How does the wui treat the LUNs at this point ? > They are no longer available as a selection when specifying the storage. When using a single tid > everything is presented as the same host:target but with different LUN number. So combining the wui > changes with how we want to present the storage seems incompatible. Right. Instead of specifying the LUNs one by one in the WUI, we now just take an IP address and target, and then we scan it on the backend to find all of the LUNs attached to that target. This makes it less cumbersome for the administrator, since they don't have to type in the same information for 10 different LUNs connected to the same target. Admittedly, this could be described better on the "Add Storage" page; maybe we'll add some text explaining this. Chris Lalancette From sseago at redhat.com Tue Mar 25 13:47:32 2008 From: sseago at redhat.com (Scott Seago) Date: Tue, 25 Mar 2008 09:47:32 -0400 Subject: [Ovirt-devel] [patch] fix nil (unlimited) quota attribute behavior Message-ID: <47E90274.90606@redhat.com> This patch fixes quota-limiting behavior for omitted parameters. Proper quota enforcment only restricts resources on those parameters that are specified. If 'memory' ,for example, is left blank, then the quota shouldn't enforce memory limits. Empty strings were throwing off the unit conversion methods, resulting in empty values being reset to 0. Scott -------------- next part -------------- A non-text attachment was scrubbed... Name: nil-quota-values-fix.patch Type: text/x-patch Size: 946 bytes Desc: not available URL: From hbrock at redhat.com Tue Mar 25 13:58:29 2008 From: hbrock at redhat.com (Hugh O. Brock) Date: Tue, 25 Mar 2008 09:58:29 -0400 Subject: [Ovirt-devel] [patch] fix nil (unlimited) quota attribute behavior In-Reply-To: <47E90274.90606@redhat.com> References: <47E90274.90606@redhat.com> Message-ID: <20080325135827.GI3009@redhat.com> On Tue, Mar 25, 2008 at 09:47:32AM -0400, Scott Seago wrote: > This patch fixes quota-limiting behavior for omitted parameters. Proper > quota enforcment only restricts resources on those parameters that are > specified. If 'memory' ,for example, is left blank, then the quota > shouldn't enforce memory limits. Empty strings were throwing off the unit > conversion methods, resulting in empty values being reset to 0. > > Scott > diff --git a/wui/src/app/util/ovirt.rb b/wui/src/app/util/ovirt.rb > index 36fd613..9024333 100644 Looks good... ACK --H From mwagner at redhat.com Tue Mar 25 20:03:07 2008 From: mwagner at redhat.com (mark wagner) Date: Tue, 25 Mar 2008 16:03:07 -0400 Subject: [Ovirt-devel] [Patch] reworked patch for developer version iscsi setup Message-ID: <47E95A7B.9090307@redhat.com> Reworked per previous feedback: -mark -------------- next part -------------- A non-text attachment was scrubbed... Name: iscsiToo.patch Type: text/x-patch Size: 3951 bytes Desc: not available URL: From clalance at redhat.com Tue Mar 25 21:24:53 2008 From: clalance at redhat.com (Chris Lalancette) Date: Tue, 25 Mar 2008 17:24:53 -0400 Subject: [Ovirt-devel] [Patch] reworked patch for developer version iscsi setup In-Reply-To: <47E95A7B.9090307@redhat.com> References: <47E95A7B.9090307@redhat.com> Message-ID: <47E96DA5.3050100@redhat.com> mark wagner wrote: > Reworked per previous feedback: > diff --git a/wui-appliance/devel-post.ks b/wui-appliance/devel-post.ks > index 3ce6239..cc04c4b 100644 > --- a/wui-appliance/devel-post.ks > +++ b/wui-appliance/devel-post.ks > @@ -230,3 +230,25 @@ esac > EOF > chmod +x /etc/init.d/ovirt-app-first-run > /sbin/chkconfig ovirt-app-first-run on > + > +# Setup the iscsi stuff to be ready on each boot. Since tgtadm does not use a config file > +# append what we need to the rc.local file. Note that this for the developers version only. > + > +cat >> /etc/rc.d/rc.local << \EOF > +# > +# Set up the fake iscsi targets > +tgtadm --lld iscsi --op new --mode target --tid 1 -T node3:disk1 > +tgtadm --lld iscsi --op new --mode target --tid 1 -T node4:disk1 > +tgtadm --lld iscsi --op new --mode target --tid 1 -T node5:disk1 You don't need these last two lines, since I think they are overriding the target name. Plus we don't want to call it "node?:disk1" anymore; something like "ovirtpriv:storage" is a little better. > +# > +# Now associate them to the LVs > +# > +tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /dev/VolGroup00/iSCSI3 > +tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 2 -b /dev/VolGroup00/iSCSI4 > +tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 3 -b /dev/VolGroup00/iSCSI5 Now that we are using a single target with multiple LUNs, you can actually go back to calling them iSCSI1, iSCSI2, and iSCSI3 (since that now matches their LUN). Otherwise, looks good. Chris Lalancette From sburgess at redhat.com Wed Mar 26 06:01:58 2008 From: sburgess at redhat.com (Susan Burgess) Date: Wed, 26 Mar 2008 16:01:58 +1000 Subject: [Ovirt-devel] management login and password? In-Reply-To: <47E95A7B.9090307@redhat.com> References: <47E95A7B.9090307@redhat.com> Message-ID: <47E9E6D6.6060209@redhat.com> Hi Mark The installation appears to be complete - though there were some worrying messages, like dhcpd failed and failed to connect - however, I did see the "starting ovirt-app-first-run" message.. However, the guest is now asking from management login - and I havent been able to login as yet - none of my guesses have worked! What is the management login and password for the appliance? Thanks Susan -- Susan Burgess Content Author Red Hat APAC Level 2, 5 Gardner Close, Milton, QLD 4064 Australia Phone +61 7 3514 8179 Fax +61 7 3514 8199 Mail sburgess at redhat.com From jmh at redhat.com Wed Mar 26 06:08:35 2008 From: jmh at redhat.com (Jan Mark Holzer) Date: Wed, 26 Mar 2008 02:08:35 -0400 Subject: [Ovirt-devel] management login and password? In-Reply-To: <47E9E6D6.6060209@redhat.com> References: <47E95A7B.9090307@redhat.com> <47E9E6D6.6060209@redhat.com> Message-ID: <47E9E863.9080301@redhat.com> Susan Burgess wrote: > Hi Mark > The installation appears to be complete - though there were some > worrying messages, like dhcpd failed and failed to connect - however, > I did see the "starting ovirt-app-first-run" message.. > However, the guest is now asking from management login - and I havent > been able to login as yet - none of my guesses have worked! > What is the management login and password for the appliance? > Thanks > Susan > The default password for the root account on the management appliance should be 'ovirtwui' It might be worthwhile to send your message log in case you encounter problems so folks can make sure your system has actually come up correctly . - Jan From mwagner at redhat.com Wed Mar 26 10:43:23 2008 From: mwagner at redhat.com (mark wagner) Date: Wed, 26 Mar 2008 06:43:23 -0400 Subject: [Ovirt-devel] [Patch] Final change set for developer iscsi setup Message-ID: <47EA28CB.9050700@redhat.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: iscsi3.patch Type: text/x-patch Size: 1437 bytes Desc: not available URL: From mwagner at redhat.com Wed Mar 26 11:34:21 2008 From: mwagner at redhat.com (mark wagner) Date: Wed, 26 Mar 2008 07:34:21 -0400 Subject: [Ovirt-devel] Re: management login and password? In-Reply-To: <47E9E6D6.6060209@redhat.com> References: <47E95A7B.9090307@redhat.com> <47E9E6D6.6060209@redhat.com> Message-ID: <47EA34BD.7060608@redhat.com> root / ovirtwui -mark Susan Burgess wrote: > Hi Mark > The installation appears to be complete - though there were some > worrying messages, like dhcpd failed and failed to connect - however, I > did see the "starting ovirt-app-first-run" message.. > However, the guest is now asking from management login - and I havent > been able to login as yet - none of my guesses have worked! > What is the management login and password for the appliance? > Thanks > Susan > From clalance at redhat.com Wed Mar 26 13:48:44 2008 From: clalance at redhat.com (Chris Lalancette) Date: Wed, 26 Mar 2008 09:48:44 -0400 Subject: [Ovirt-devel] [Patch] Final change set for developer iscsi setup In-Reply-To: <47EA28CB.9050700@redhat.com> References: <47EA28CB.9050700@redhat.com> Message-ID: <47EA543C.50304@redhat.com> mark wagner wrote: > > ------------------------------------------------------------------------ > diff --git a/wui-appliance/common-pkgs.ks b/wui-appliance/common-pkgs.ks > index 15c47aa..af2766f 100644 > --- a/wui-appliance/common-pkgs.ks > +++ b/wui-appliance/common-pkgs.ks > @@ -21,6 +21,7 @@ ipa-admintools > xinetd > libvirt > cyrus-sasl-gssapi > +scsi-target-utils > iscsi-initiator-utils > collectd > ruby-libvirt > @@ -45,4 +46,4 @@ livecd-tools > -fetchmail > -slrn > -cadaver > --mutt > \ No newline at end of file > +-mutt > diff --git a/wui-appliance/devel-post.ks b/wui-appliance/devel-post.ks > index 3ce6239..c925204 100644 > --- a/wui-appliance/devel-post.ks > +++ b/wui-appliance/devel-post.ks > @@ -230,3 +230,23 @@ esac > EOF > chmod +x /etc/init.d/ovirt-app-first-run > /sbin/chkconfig ovirt-app-first-run on > + > +# Setup the iscsi stuff to be ready on each boot. Since tgtadm does not use a config file > +# append what we need to the rc.local file. Note that this for the developers version only. > + > +cat >> /etc/rc.d/rc.local << \EOF > +# > +# Set up the fake iscsi targets > +tgtadm --lld iscsi --op new --mode target --tid 1 -T ovirtpriv:storage > +# > +# Now associate them to the LVs > +# > +tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /dev/VolGroup00/iSCSI1 > +tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 2 -b /dev/VolGroup00/iSCSI2 > +tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 3 -b /dev/VolGroup00/iSCSI3 > +# > +# Now make them available > +# > +tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL > +EOF > + That's more like it. I think you missed the changes to wui-devel-i386.ks and wui-devel-x86_64.ks in this latest patch, but I took those from earlier patches. Committed to tip in git now (but note that I had to modify the patch somewhat, since things have moved around in tip now). We can cherry-pick it back onto the release branch if people want, too. Thanks! Chris Lalancette From djuran at redhat.com Wed Mar 26 14:42:31 2008 From: djuran at redhat.com (David Juran) Date: Wed, 26 Mar 2008 16:42:31 +0200 Subject: [Ovirt-devel] backtrace when trying to start a VM Message-ID: <1206542551.24980.89.camel@localhost.localdomain> Hello. I've been playing around with the ovirt devel setup as described on http://ovirt.org/devel-install.html I got the managed nodes started and proceeded by clicking around exploring the GUI. I create a VM but when I then tried to start it, I got the following backtrace: Processing LibraryController#vm_actions (for 192.168.50.2 at 2008-03-26 10:17:31) [POST] Session ID: BAh7BiIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNo%0ASGFzaHsABjoKQHVzZWR7AA%3D%3D--da9161e53812f6acb23beaa05888f9bc5f904ef2 Parameters: {"vm_actions"=>{"vm_library_id"=>"@vm_library.id", "other_actions"=>"Other Actions", "start_vm"=>"Start"}, "action"=>"vm_actions", "controller"=>"library"} ActiveRecord::RecordNotFound (Couldn't find VmLibrary without an ID): /usr/lib/ruby/gems/1.8/gems/activerecord-2.0.1/lib/active_record/base.rb:1175:in `find_from_ids' /usr/lib/ruby/gems/1.8/gems/activerecord-2.0.1/lib/active_record/base.rb:453:in `find' /app/controllers/library_controller.rb:86:in `vm_actions' /usr/lib/ruby/gems/1.8/gems/actionpack-2.0.1/lib/action_controller/base.rb:1168:in `send' /usr/lib/ruby/gems/1.8/gems/actionpack-2.0.1/lib/action_controller/base.rb:1168:in `perform_action_without_filters' /usr/lib/ruby/gems/1.8/gems/actionpack-2.0.1/lib/action_controller/filters.rb:697:in `call_filters' /usr/lib/ruby/gems/1.8/gems/actionpack-2.0.1/lib/action_controller/filters.rb:689:in `perform_action_without_benchmark' /usr/lib/ruby/gems/1.8/gems/actionpack-2.0.1/lib/action_controller/benchmarking.rb:68:in `perform_action_without_rescue' /usr/lib/ruby/1.8/benchmark.rb:293:in `measure' /usr/lib/ruby/gems/1.8/gems/actionpack-2.0.1/lib/action_controller/benchmarking.rb:68:in `perform_action_without_rescue' /usr/lib/ruby/gems/1.8/gems/actionpack-2.0.1/lib/action_controller/rescue.rb:199:in `perform_action_without_caching' /usr/lib/ruby/gems/1.8/gems/actionpack-2.0.1/lib/action_controller/caching.rb:678:in `perform_action' /usr/lib/ruby/gems/1.8/gems/activerecord-2.0.1/lib/active_record/connection_adapters/abstract/query_cache.rb:33:in `cache' /usr/lib/ruby/gems/1.8/gems/activerecord-2.0.1/lib/active_record/query_cache.rb:8:in `cache' /usr/lib/ruby/gems/1.8/gems/actionpack-2.0.1/lib/action_controller/caching.rb:677:in `perform_action' /usr/lib/ruby/gems/1.8/gems/actionpack-2.0.1/lib/action_controller/base.rb:524:in `send' /usr/lib/ruby/gems/1.8/gems/actionpack-2.0.1/lib/action_controller/base.rb:524:in `process_without_filters' /usr/lib/ruby/gems/1.8/gems/actionpack-2.0.1/lib/action_controller/filters.rb:685:in `process_without_session_management_support' /usr/lib/ruby/gems/1.8/gems/actionpack-2.0.1/lib/action_controller/session_management.rb:123:in `process' /usr/lib/ruby/gems/1.8/gems/actionpack-2.0.1/lib/action_controller/base.rb:388:in `process' /usr/lib/ruby/gems/1.8/gems/actionpack-2.0.1/lib/action_controller/dispatcher.rb:171:in `handle_request' /usr/lib/ruby/gems/1.8/gems/actionpack-2.0.1/lib/action_controller/dispatcher.rb:115:in `dispatch' /usr/lib/ruby/gems/1.8/gems/actionpack-2.0.1/lib/action_controller/dispatcher.rb:126:in `dispatch_cgi' /usr/lib/ruby/gems/1.8/gems/actionpack-2.0.1/lib/action_controller/dispatcher.rb:9:in `dispatch' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:78:in `process' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:76:in `synchronize' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:76:in `process' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:618:in `process_client' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:617:in `each' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:617:in `process_client' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:736:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:736:in `initialize' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:736:in `new' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:736:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:720:in `initialize' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:720:in `new' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:720:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:271:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:270:in `each' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:270:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:127:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/command.rb:211:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:243 /usr/bin/mongrel_rails:16:in `load' /usr/bin/mongrel_rails:16 Rendering /usr/share/ovirt-wui/public/404.html (404 Not Found) Does anyone have any clues? The full rails.log is available upon request (-: -- David Juran Sr. Consultant Red Hat +358-504-146348 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sseago at redhat.com Wed Mar 26 15:03:20 2008 From: sseago at redhat.com (Scott Seago) Date: Wed, 26 Mar 2008 11:03:20 -0400 Subject: [Ovirt-devel] backtrace when trying to start a VM In-Reply-To: <1206542551.24980.89.camel@localhost.localdomain> References: <1206542551.24980.89.camel@localhost.localdomain> Message-ID: <47EA65B8.5080002@redhat.com> David Juran wrote: > Hello. > > I've been playing around with the ovirt devel setup as described on > http://ovirt.org/devel-install.html I got the managed nodes started and > proceeded by clicking around exploring the GUI. I create a VM but when I > then tried to start it, I got the following backtrace: > > Processing LibraryController#vm_actions (for 192.168.50.2 at 2008-03-26 10:17:31) [POST] > Session ID: BAh7BiIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNo%0ASGFzaHsABjoKQHVzZWR7AA%3D%3D--da9161e53812f6acb23beaa05888f9bc5f904ef2 > Parameters: {"vm_actions"=>{"vm_library_id"=>"@vm_library.id", "other_actions"=>"Other Actions", "start_vm"=>"Start"}, "action"=>"vm_actions", "controller"=>"library"} > Ahh -- the action links/buttons on the vm Library page aren't active yet -- I was in the middle of implementing them when we started the last round of UI redesign, so it was put on hold. Originally, the actions would print some debugging information but no actual VM actions would occur. But it looks like now it's triggering a more fundamental error. I should probably stub this out until the current UI redesign round is done, since I'm not sure if the multi-VM actions will be changing in the process. If you click onto the VM page, the start/stop/etc. links should be working there (once taskomatic is fully-updated to work with the current WUI codebase) Scott From sseago at redhat.com Wed Mar 26 17:14:36 2008 From: sseago at redhat.com (Scott Seago) Date: Wed, 26 Mar 2008 13:14:36 -0400 Subject: [Ovirt-devel] [Patch] add support for NFS storage pools/volumes to WUI Message-ID: <47EA847C.7020804@redhat.com> This patch adds support for NFS storage pools and volumes to the Ovirt WUI. Taskomatic work is still needed to correspond to these changes -- mainly for handling NFS stuff, but also for previous iSCSI code to properly set the :type attribute for storage volumes now. -------------- next part -------------- A non-text attachment was scrubbed... Name: add_nfs_storage.patch Type: text/x-patch Size: 15463 bytes Desc: not available URL: From sburgess at redhat.com Wed Mar 26 23:44:16 2008 From: sburgess at redhat.com (Susan Burgess) Date: Thu, 27 Mar 2008 09:44:16 +1000 Subject: [Ovirt-devel] management login and password? In-Reply-To: <47E9E863.9080301@redhat.com> References: <47E95A7B.9090307@redhat.com> <47E9E6D6.6060209@redhat.com> <47E9E863.9080301@redhat.com> Message-ID: <47EADFD0.30503@redhat.com> Thanks Jan. Yes, I'm able to login now, but cannot get Firefox to display - the command from the instructions: |# ssh -Y root at 192.168.50.2 firefox http://management.priv.ovirt.org| || | doesnt result in the browser displaying.,consequently I can't do the next step of starting the fake managed nodes..| || |Any ideas?| || |Also, can you tell me where to look for the message logs?| || |Thanks| |Susan| |||| Jan Mark Holzer wrote: > Susan Burgess wrote: >> Hi Mark >> The installation appears to be complete - though there were some >> worrying messages, like dhcpd failed and failed to connect - however, >> I did see the "starting ovirt-app-first-run" message.. >> However, the guest is now asking from management login - and I havent >> been able to login as yet - none of my guesses have worked! >> What is the management login and password for the appliance? >> Thanks >> Susan >> > The default password for the root account on the management appliance > should be 'ovirtwui' > It might be worthwhile to send your message log in case you encounter > problems so folks can make sure > your system has actually come up correctly . > > - Jan > -- Susan Burgess Content Author Red Hat APAC Level 2, 5 Gardner Close, Milton, QLD 4064 Australia Phone +61 7 3514 8179 Fax +61 7 3514 8199 Mail sburgess at redhat.com From mmorsi at redhat.com Wed Mar 26 23:58:24 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Wed, 26 Mar 2008 19:58:24 -0400 Subject: [Ovirt-devel] [Patch] better exceptions for ruby-libvirt bindings Message-ID: <47EAE320.1000307@redhat.com> Defined custom libvirt ruby exceptions and altered the code so as to throw them instead of the generic 'rb_eSystemCallError'. If additional more-granular exceptions are needed, they can be easily added. (note this diff is against ruby-libvirt-0.0.2 due to issues with the upstream ruby-libvirt and libvirt-devel) -------------- next part -------------- A non-text attachment was scrubbed... Name: _libvirt.c.patch Type: text/x-patch Size: 22489 bytes Desc: not available URL: From pmyers at redhat.com Thu Mar 27 14:44:13 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Thu, 27 Mar 2008 10:44:13 -0400 Subject: [Ovirt-devel] [PATCH] fix modification of ovirt-wui.conf Message-ID: <47EBB2BD.6030000@redhat.com> ovirt-wui.conf modification in the create-default-principals script was not occurring because of an errant if statement. This has been removed. In addition, the file that comes in the RPM already has the virtual host and namevirtual host directives, so these do not need to be in the script. The modification of the Krb5KeyTab can also be removed since the default value in the rpm file is correct. Signed-off-by: Perry Myers diff --git a/wui-appliance/common-post.ks b/wui-appliance/common-post.ks index 3185cc6..de92f4b 100644 --- a/wui-appliance/common-post.ks +++ b/wui-appliance/common-post.ks @@ -83,20 +83,15 @@ if string.find(file(ipaconfname, 'rb').read(), '') < 0: print >>ipaconf2, "" ipaconf2.close() -if string.find(file(ovirtconfname, 'rb').read(), '') < 0: - ovirtconf = open(ovirtconfname, 'r') - ovirttext = ovirtconf.readlines() - ovirtconf.close() - - ovirtconf2 = open(ovirtconfname, 'w') - print >>ovirtconf2, "NameVirtualHost *:80" - print >>ovirtconf2, "" - for line in ovirttext: - newline = re.sub(r'(.*)KrbAuthRealms.*', r'\1KrbAuthRealms ' + default_realm, line) - newline = re.sub(r'(.*)Krb5KeyTab.*', r'\1Krb5KeyTab /etc/httpd/conf/ipa.keytab', newline) - ovirtconf2.write(newline) - print >>ovirtconf2, "" - ovirtconf2.close() +ovirtconf = open(ovirtconfname, 'r') +ovirttext = ovirtconf.readlines() +ovirtconf.close() + +ovirtconf2 = open(ovirtconfname, 'w') +for line in ovirttext: + newline = re.sub(r'(.*)KrbAuthRealms.*', r'\1KrbAuthRealms ' + default_realm, line) + ovirtconf2.write(newline) +ovirtconf2.close() EOF chmod +x /root/create_default_principals.py From apevec at redhat.com Thu Mar 27 14:58:27 2008 From: apevec at redhat.com (Alan Pevec) Date: Thu, 27 Mar 2008 15:58:27 +0100 Subject: [Ovirt-devel] [PATCH] replace ks_fold_include.py with ksflatten Message-ID: <47EBB613.5090804@redhat.com> commit 6a9675dff3f0b63d3e2a3a2f1acf24883560258f Author: Alan Pevec Date: Thu Mar 27 14:46:25 2008 +0100 replace ks_fold_include.py with ksflatten from pykickstart ksflatten parses and validates kickstart files NB: two %include in a row end up w/o line-feed between them, hence change in .ks files: %include ... + %include ... requires pykickstart >= 1.14 diff --git a/wui-appliance/Makefile b/wui-appliance/Makefile index ca9ef00..1999457 100644 --- a/wui-appliance/Makefile +++ b/wui-appliance/Makefile @@ -1,10 +1,10 @@ all: ks ks: - ./ks_fold_include.py wui-app-i386.ks > wui-rel-app-i386.ks - ./ks_fold_include.py wui-app-x86_64.ks > wui-rel-app-x86_64.ks - ./ks_fold_include.py wui-devel-i386.ks > wui-rel-devel-i386.ks - ./ks_fold_include.py wui-devel-x86_64.ks > wui-rel-devel-x86_64.ks + ksflatten wui-app-i386.ks > wui-rel-app-i386.ks + ksflatten wui-app-x86_64.ks > wui-rel-app-x86_64.ks + ksflatten wui-devel-i386.ks > wui-rel-devel-i386.ks + ksflatten wui-devel-x86_64.ks > wui-rel-devel-x86_64.ks clean: rm -f *-rel-* diff --git a/wui-appliance/ks_fold_include.py b/wui-appliance/ks_fold_include.py deleted file mode 100755 index ec4262d..0000000 --- a/wui-appliance/ks_fold_include.py +++ /dev/null @@ -1,41 +0,0 @@ -#!/usr/bin/python - -import sys -import re -import os - -include_regex = re.compile("^%include\s+(.*)") - -def usage(): - print "Usage: ks_fold_include.py " - sys.exit(1) - -def replace_lines(filename): - try: - file = open(filename) - for line in file.readlines(): - matched = include_regex.match(line) - if matched: - replace_lines(matched.group(1)) - sys.stdout.write("\n") - else: - sys.stdout.write(line) - - file.close() - except IOError, detail: - print detail - sys.exit(2) - -if len(sys.argv) != 2: - usage() - -dirname = os.path.dirname(sys.argv[1]) -basename = os.path.basename(sys.argv[1]) - -# if the user passes an argument like 'ks_fold_include.py foo.ks', then -# dirname returns a blank string; assume we are already in the right directory -# and do nothing -if dirname != '': - os.chdir(dirname) - -replace_lines(basename) diff --git a/wui-appliance/wui-app-i386.ks b/wui-appliance/wui-app-i386.ks index b05e229..4d53c0b 100644 --- a/wui-appliance/wui-app-i386.ks +++ b/wui-appliance/wui-app-i386.ks @@ -1,6 +1,7 @@ # Kickstart file automatically generated by anaconda. install + url --url http://download.fedora.redhat.com/pub/fedora/linux/releases/8/Fedora/i386/os/ %include common-install.ks @@ -16,6 +17,7 @@ repo --name=ovirt-management --baseurl=http://ovirt.et.redhat.com/repos/ovirt-ma %post %include common-post.ks + %include production-post.ks %end diff --git a/wui-appliance/wui-app-x86_64.ks b/wui-appliance/wui-app-x86_64.ks index 53fdd9f..6d192b3 100644 --- a/wui-appliance/wui-app-x86_64.ks +++ b/wui-appliance/wui-app-x86_64.ks @@ -16,6 +16,7 @@ repo --name=ovirt-management --baseurl=http://ovirt.et.redhat.com/repos/ovirt-ma %post %include common-post.ks + %include production-post.ks %end diff --git a/wui-appliance/wui-devel-i386.ks b/wui-appliance/wui-devel-i386.ks index 9701a89..fb72e7b 100644 --- a/wui-appliance/wui-devel-i386.ks +++ b/wui-appliance/wui-devel-i386.ks @@ -16,6 +16,7 @@ repo --name=ovirt-management --baseurl=http://ovirt.et.redhat.com/repos/ovirt-ma %post %include common-post.ks + %include devel-post.ks # get the PXE boot image; this can take a while diff --git a/wui-appliance/wui-devel-x86_64.ks b/wui-appliance/wui-devel-x86_64.ks index dae0f44..f2bd308 100644 --- a/wui-appliance/wui-devel-x86_64.ks +++ b/wui-appliance/wui-devel-x86_64.ks @@ -16,6 +16,7 @@ repo --name=ovirt-management --baseurl=http://ovirt.et.redhat.com/repos/ovirt-ma %post %include common-post.ks + %include devel-post.ks # get the PXE boot image; this can take a while From sseago at redhat.com Thu Mar 27 14:59:47 2008 From: sseago at redhat.com (Scott Seago) Date: Thu, 27 Mar 2008 10:59:47 -0400 Subject: [Ovirt-devel] [Patch] Add bridge to NIC model Message-ID: <47EBB663.507@redhat.com> This patch adds a 'bridge' attribute to the NIC model and UI. Scott -------------- next part -------------- A non-text attachment was scrubbed... Name: nic-add-bridge.patch Type: text/x-patch Size: 1447 bytes Desc: not available URL: From clalance at redhat.com Thu Mar 27 15:02:27 2008 From: clalance at redhat.com (Chris Lalancette) Date: Thu, 27 Mar 2008 11:02:27 -0400 Subject: [Ovirt-devel] [PATCH] replace ks_fold_include.py with ksflatten In-Reply-To: <47EBB613.5090804@redhat.com> References: <47EBB613.5090804@redhat.com> Message-ID: <47EBB703.9050005@redhat.com> Alan Pevec wrote: > commit 6a9675dff3f0b63d3e2a3a2f1acf24883560258f > Author: Alan Pevec > Date: Thu Mar 27 14:46:25 2008 +0100 > > replace ks_fold_include.py with ksflatten from pykickstart > ksflatten parses and validates kickstart files > NB: two %include in a row end up w/o line-feed between them, hence change in .ks files: > %include ... > + > %include ... > > requires pykickstart >= 1.14 Yep, looks good. I didn't know about ksflatten when I wrote ks_fold_include.py; thanks for pointing it out. ACK Chris Lalancette From clalance at redhat.com Thu Mar 27 15:03:58 2008 From: clalance at redhat.com (Chris Lalancette) Date: Thu, 27 Mar 2008 11:03:58 -0400 Subject: [Ovirt-devel] [PATCH] fix modification of ovirt-wui.conf In-Reply-To: <47EBB2BD.6030000@redhat.com> References: <47EBB2BD.6030000@redhat.com> Message-ID: <47EBB75E.6070809@redhat.com> Perry N. Myers wrote: > ovirt-wui.conf modification in the create-default-principals script was > not occurring because of an errant if statement. This has been removed. > In addition, the file that comes in the RPM already has the virtual host > and namevirtual host directives, so these do not need to be in the script. > The modification of the Krb5KeyTab can also be removed since the > default value in the rpm file is correct. > > Signed-off-by: Perry Myers Yes, this was the result of me doing two different things at two different times. This change should be fine. ACK Chris Lalancette From clalance at redhat.com Thu Mar 27 15:04:48 2008 From: clalance at redhat.com (Chris Lalancette) Date: Thu, 27 Mar 2008 11:04:48 -0400 Subject: [Ovirt-devel] [Patch] Add bridge to NIC model In-Reply-To: <47EBB663.507@redhat.com> References: <47EBB663.507@redhat.com> Message-ID: <47EBB790.8060305@redhat.com> Scott Seago wrote: > This patch adds a 'bridge' attribute to the NIC model and UI. > > Scott > Good, yes, we need this so we can enumerate bridges on hosts during "host-browser" time and make decisions in taskomatic. ACK Chris Lalancette From pmyers at redhat.com Thu Mar 27 15:16:13 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Thu, 27 Mar 2008 11:16:13 -0400 Subject: [Ovirt-devel] ports and hostnames for the ovirt server Message-ID: <47EBBA3D.6040300@redhat.com> In looking at the apache configuration for the ipa server and the ovirt-wui, I had a few questions... Right now the assumption being made is that the FreeIPA instance always gets installed on the same host as the ovirt-wui. And because of this, we have to run the FreeIPA server on a non-standard port (8089) because it currently does not coexist well with other apps on the same port. Another configuration exists where the FreeIPA server is already installed elsewhere in the network (maybe someone is already using it for other purposes) and in this case it'll likely be running on port 80 on that server. Since by default FreeIPA runs on port 80, it makes more sense to always keep it on port 80 so that the configuration is the same whether it is hosted with the oVirt WUI or standalone. If we agree on that (I'm open to objections here) then the next question is how to run FreeIPA and oVirt on the same box without conflicts. A few options exist: 1. Run oVirt on a different port instead of FreeIPA 2. Use name virtual hosting so that IPA runs on the base hostname and oVirt runs on something like ovirt.domain.com. For the developer install, this can be accomplished by mucking with /etc/hosts and for prod installs it'll involve DNS, but we already require that for other things. This is tricky because once we start using https and FreeIPA does as well, NameVirtualHosting sort of breaks down... 3. Relocate the ipa server so that it's not at the root URL 4. Relocate the ovirt server so that it's not at the root URL I don't like option 3, since that also changes the default configuration for FreeIPA. Option 2 will work for now, but we know it'll break later when we start using https. Option 1 is the easiest way to get things working, as long as people don't object to running the mgmt ui on something other than port 80. Option 4 might solve the problem, but I'm not sure if it'll work since FreeIPA does URL rewriting (we can comment this out, but I'd like to not muck with their stuff and leave things default if possible) Thoughts? Perry -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=| From berrange at redhat.com Thu Mar 27 15:27:58 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 27 Mar 2008 15:27:58 +0000 Subject: [Ovirt-devel] ports and hostnames for the ovirt server In-Reply-To: <47EBBA3D.6040300@redhat.com> References: <47EBBA3D.6040300@redhat.com> Message-ID: <20080327152758.GD22443@redhat.com> On Thu, Mar 27, 2008 at 11:16:13AM -0400, Perry N. Myers wrote: > In looking at the apache configuration for the ipa server and the > ovirt-wui, I had a few questions... > > Right now the assumption being made is that the FreeIPA instance always > gets installed on the same host as the ovirt-wui. And because of this, we > have to run the FreeIPA server on a non-standard port (8089) because it > currently does not coexist well with other apps on the same port. > > Another configuration exists where the FreeIPA server is already installed > elsewhere in the network (maybe someone is already using it for other > purposes) and in this case it'll likely be running on port 80 on that server. > > Since by default FreeIPA runs on port 80, it makes more sense to always > keep it on port 80 so that the configuration is the same whether it is > hosted with the oVirt WUI or standalone. > > If we agree on that (I'm open to objections here) then the next question > is how to run FreeIPA and oVirt on the same box without conflicts. A few > options exist: > 1. Run oVirt on a different port instead of FreeIPA > 2. Use name virtual hosting so that IPA runs on the base hostname and > oVirt runs on something like ovirt.domain.com. For the developer > install, this can be accomplished by mucking with /etc/hosts and > for prod installs it'll involve DNS, but we already require that for > other things. This is tricky because once we start using https and > FreeIPA does as well, NameVirtualHosting sort of breaks down... Name based virtual hosting breaks with Kerberos too, because the oVirt server's CANME will resolve to an IP, and then reverse resolve to a different name. All services using Kerberos need real A records AFAICT > 3. Relocate the ipa server so that it's not at the root URL > 4. Relocate the ovirt server so that it's not at the root URL IMHO, both IPA & oVirt should *not* take over the root URL. All apps should default to a private prefix, /ipa/ and /ovirt/. When deploying in production a simple mod-rewrite rule can make either app take over use of /, simply redirecting to the either /ipa or /ovirt depending on which the server admin decides should be the default. > I don't like option 3, since that also changes the default configuration > for FreeIPA. Option 2 will work for now, but we know it'll break later > when we start using https. > > Option 1 is the easiest way to get things working, as long as people don't > object to running the mgmt ui on something other than port 80. > > Option 4 might solve the problem, but I'm not sure if it'll work since > FreeIPA does URL rewriting (we can comment this out, but I'd like to not > muck with their stuff and leave things default if possible) The FreeIPA config file is fundamentally broken since it assumes it is the only app living in the apache server. This needs to be fixed so that they play nicely with other apps. This means living under /ipa/ and having an optional redirect from / at the site administrators discretion. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From clalance at redhat.com Thu Mar 27 15:27:48 2008 From: clalance at redhat.com (Chris Lalancette) Date: Thu, 27 Mar 2008 11:27:48 -0400 Subject: [Ovirt-devel] ports and hostnames for the ovirt server In-Reply-To: <20080327152758.GD22443@redhat.com> References: <47EBBA3D.6040300@redhat.com> <20080327152758.GD22443@redhat.com> Message-ID: <47EBBCF4.9050303@redhat.com> Daniel P. Berrange wrote: >> 3. Relocate the ipa server so that it's not at the root URL >> 4. Relocate the ovirt server so that it's not at the root URL > > IMHO, both IPA & oVirt should *not* take over the root URL. All apps > should default to a private prefix, /ipa/ and /ovirt/. When deploying > in production a simple mod-rewrite rule can make either app take over > use of /, simply redirecting to the either /ipa or /ovirt depending > on which the server admin decides should be the default. Yep, I completely agree with danpb here. The freeipa guys are also open to moving to /ipa; they just weren't sure how to configure apache to do so. Once we figure it out, we should probably make ovirt do something similar. In summary, do both 3 and 4. Chris Lalancette From sseago at redhat.com Thu Mar 27 15:34:06 2008 From: sseago at redhat.com (Scott Seago) Date: Thu, 27 Mar 2008 11:34:06 -0400 Subject: [Ovirt-devel] ports and hostnames for the ovirt server In-Reply-To: <20080327152758.GD22443@redhat.com> References: <47EBBA3D.6040300@redhat.com> <20080327152758.GD22443@redhat.com> Message-ID: <47EBBE6E.9010705@redhat.com> Daniel P. Berrange wrote: > >> 3. Relocate the ipa server so that it's not at the root URL >> 4. Relocate the ovirt server so that it's not at the root URL >> > > IMHO, both IPA & oVirt should *not* take over the root URL. All apps > should default to a private prefix, /ipa/ and /ovirt/. When deploying > in production a simple mod-rewrite rule can make either app take over > use of /, simply redirecting to the either /ipa or /ovirt depending > on which the server admin decides should be the default. > > In addition to apache rewriting, the webapp may need to know this prefix when generating URLs as well. With virt-factory, we did mount the whole app at "/vf" and I had to feed this prefix to rails to prepend this to generated URLs. Perhaps mod-rewrite can do this as well, but I wasn't able to figure that out (although perhaps I was just being dense). Doing this in the app did work, but it was a pain, as we had to prepend the prefix all over the place. > The FreeIPA config file is fundamentally broken since it assumes it is > the only app living in the apache server. This needs to be fixed so that > they play nicely with other apps. This means living under /ipa/ and having > an optional redirect from / at the site administrators discretion. > > Dan. > The ovirt config suffers from this same problem currently. Scott From ssorce at redhat.com Thu Mar 27 15:34:48 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 27 Mar 2008 11:34:48 -0400 Subject: [Ovirt-devel] ports and hostnames for the ovirt server In-Reply-To: <47EBBA3D.6040300@redhat.com> References: <47EBBA3D.6040300@redhat.com> Message-ID: <1206632088.3533.22.camel@localhost.localdomain> CCing freeipa-devel to make sure I am saying the right thing as Rob is the one sending patches for it. On Thu, 2008-03-27 at 11:16 -0400, Perry N. Myers wrote: > In looking at the apache configuration for the ipa server and the > ovirt-wui, I had a few questions... > > Right now the assumption being made is that the FreeIPA instance always > gets installed on the same host as the ovirt-wui. And because of this, we > have to run the FreeIPA server on a non-standard port (8089) because it > currently does not coexist well with other apps on the same port. FYI: We are working on fixing this. > Another configuration exists where the FreeIPA server is already installed > elsewhere in the network (maybe someone is already using it for other > purposes) and in this case it'll likely be running on port 80 on that server. > > Since by default FreeIPA runs on port 80, it makes more sense to always > keep it on port 80 so that the configuration is the same whether it is > hosted with the oVirt WUI or standalone. It would make sense yes. > If we agree on that (I'm open to objections here) then the next question > is how to run FreeIPA and oVirt on the same box without conflicts. A few > options exist: > 1. Run oVirt on a different port instead of FreeIPA > 2. Use name virtual hosting so that IPA runs on the base hostname and > oVirt runs on something like ovirt.domain.com. For the developer > install, this can be accomplished by mucking with /etc/hosts and > for prod installs it'll involve DNS, but we already require that for > other things. This is tricky because once we start using https and > FreeIPA does as well, NameVirtualHosting sort of breaks down... > 3. Relocate the ipa server so that it's not at the root URL We are pursuing this solution in freeIPA itself. Hopefully, with some help, we will have this soon. > 4. Relocate the ovirt server so that it's not at the root URL In general it would be wise to be able to use something like http://server/service so that multiple services can be used on the same server without clashes. THe patches I've seen from Rob move all to http(s)://server.name/ipa(xml), I guess ovirt could do something similar and move to http(s)://server.name/ovirt ? > I don't like option 3, since that also changes the default configuration > for FreeIPA. Option 2 will work for now, but we know it'll break later > when we start using https. > > Option 1 is the easiest way to get things working, as long as people don't > object to running the mgmt ui on something other than port 80. > > Option 4 might solve the problem, but I'm not sure if it'll work since > FreeIPA does URL rewriting (we can comment this out, but I'd like to not > muck with their stuff and leave things default if possible) > > Thoughts? I think opt 3 is the solution and should be adopted by both freeipa and ovirt so that we can all be good citizens. Simo. -- Simo Sorce * Red Hat, Inc * New York From pmyers at redhat.com Thu Mar 27 15:40:24 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Thu, 27 Mar 2008 11:40:24 -0400 Subject: [Ovirt-devel] ports and hostnames for the ovirt server In-Reply-To: <1206632088.3533.22.camel@localhost.localdomain> References: <47EBBA3D.6040300@redhat.com> <1206632088.3533.22.camel@localhost.localdomain> Message-ID: <47EBBFE8.4080205@redhat.com> Simo Sorce wrote: > I think opt 3 is the solution and should be adopted by both freeipa and > ovirt so that we can all be good citizens. > > Simo. Ok. I think we're all in agreement then. :) We'll change ovirt to be in /ovirt, and we'll wait to hear when new rpms are in rawhide to fix this in ipa. Thanks everyone. Perry -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=| From berrange at redhat.com Thu Mar 27 15:42:41 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 27 Mar 2008 15:42:41 +0000 Subject: [Ovirt-devel] ports and hostnames for the ovirt server In-Reply-To: <47EBBFE8.4080205@redhat.com> References: <47EBBA3D.6040300@redhat.com> <1206632088.3533.22.camel@localhost.localdomain> <47EBBFE8.4080205@redhat.com> Message-ID: <20080327154241.GE22443@redhat.com> On Thu, Mar 27, 2008 at 11:40:24AM -0400, Perry N. Myers wrote: > Simo Sorce wrote: > > I think opt 3 is the solution and should be adopted by both freeipa and > > ovirt so that we can all be good citizens. > > > > Simo. > > Ok. I think we're all in agreement then. :) > > We'll change ovirt to be in /ovirt, and we'll wait to hear when new rpms > are in rawhide to fix this in ipa. We should sync up with Rob to test his config changes for IPA to verify that they work for us before they get pushed to rawhide. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From bkearney at redhat.com Thu Mar 27 15:43:12 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 27 Mar 2008 11:43:12 -0400 Subject: [Ovirt-devel] ports and hostnames for the ovirt server In-Reply-To: <47EBBE6E.9010705@redhat.com> References: <47EBBA3D.6040300@redhat.com> <20080327152758.GD22443@redhat.com> <47EBBE6E.9010705@redhat.com> Message-ID: <47EBC090.4000607@redhat.com> If you use the url-for tags, they the rails app should be oblivious to the context. This should work for emails too. Note.. this is a rails 2.0 comment.. I dont know about 1.X -- bk Scott Seago wrote: > Daniel P. Berrange wrote: >> >>> 3. Relocate the ipa server so that it's not at the root URL >>> 4. Relocate the ovirt server so that it's not at the root URL >>> >> >> IMHO, both IPA & oVirt should *not* take over the root URL. All apps >> should default to a private prefix, /ipa/ and /ovirt/. When deploying >> in production a simple mod-rewrite rule can make either app take over >> use of /, simply redirecting to the either /ipa or /ovirt depending >> on which the server admin decides should be the default. >> >> > In addition to apache rewriting, the webapp may need to know this prefix > when generating URLs as well. With virt-factory, we did mount the whole > app at "/vf" and I had to feed this prefix to rails to prepend this to > generated URLs. Perhaps mod-rewrite can do this as well, but I wasn't > able to figure that out (although perhaps I was just being dense). Doing > this in the app did work, but it was a pain, as we had to prepend the > prefix all over the place. >> The FreeIPA config file is fundamentally broken since it assumes it is >> the only app living in the apache server. This needs to be fixed so that >> they play nicely with other apps. This means living under /ipa/ and >> having >> an optional redirect from / at the site administrators discretion. >> >> Dan. >> > The ovirt config suffers from this same problem currently. > > Scott > > _______________________________________________ > Ovirt-devel mailing list > Ovirt-devel at redhat.com > https://www.redhat.com/mailman/listinfo/ovirt-devel From dlutter at redhat.com Thu Mar 27 16:14:46 2008 From: dlutter at redhat.com (David Lutterkort) Date: Thu, 27 Mar 2008 09:14:46 -0700 Subject: [Ovirt-devel] [Patch] better exceptions for ruby-libvirt bindings In-Reply-To: <47EAE320.1000307@redhat.com> References: <47EAE320.1000307@redhat.com> Message-ID: <1206634486.22539.4.camel@localhost.localdomain> On Wed, 2008-03-26 at 19:58 -0400, Mohammed Morsi wrote: > Defined custom libvirt ruby exceptions and altered the code so as to > throw them instead of the generic 'rb_eSystemCallError'. If additional > more-granular exceptions are needed, they can be easily added. The patch looks good, except for some small formatting issues (try to keep the lines to < 80 columns, I usually stop at 78) > (note > this diff is against ruby-libvirt-0.0.2 due to issues with the upstream > ruby-libvirt and libvirt-devel) The issue, I assume is that the ruby-libvirt bindings will only build against a libvirt with storage API. That really needs to be ifdef'd out; one option is to do that function by function: that's so tedious that we'll probably need to switch to generating _libvirt.c. The other option is to just check for certain types (like virStoragePoolPtr) and then ifdefing the whole storage API out. I'll have a stab at that and hope that it won't make forward porting your patch impossible. David From dlutter at redhat.com Thu Mar 27 20:31:48 2008 From: dlutter at redhat.com (David Lutterkort) Date: Thu, 27 Mar 2008 13:31:48 -0700 Subject: [Ovirt-devel] ports and hostnames for the ovirt server In-Reply-To: <20080327152758.GD22443@redhat.com> References: <47EBBA3D.6040300@redhat.com> <20080327152758.GD22443@redhat.com> Message-ID: <1206649908.22539.13.camel@localhost.localdomain> On Thu, 2008-03-27 at 15:27 +0000, Daniel P. Berrange wrote: > Name based virtual hosting breaks with Kerberos too, because the oVirt > server's CANME will resolve to an IP, and then reverse resolve to a > different name. All services using Kerberos need real A records AFAICT That is an extremely serious shortcoming in practice, since generally you should make the hostnames for any services CNAME's so that you can move them around easily and transparently. David From rcritten at redhat.com Thu Mar 27 19:43:07 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Mar 2008 15:43:07 -0400 Subject: [Freeipa-devel] Re: [Ovirt-devel] ports and hostnames for the ovirt server In-Reply-To: <20080327154241.GE22443@redhat.com> References: <47EBBA3D.6040300@redhat.com> <1206632088.3533.22.camel@localhost.localdomain> <47EBBFE8.4080205@redhat.com> <20080327154241.GE22443@redhat.com> Message-ID: <47EBF8CB.4010606@redhat.com> Daniel P. Berrange wrote: > On Thu, Mar 27, 2008 at 11:40:24AM -0400, Perry N. Myers wrote: >> Simo Sorce wrote: >>> I think opt 3 is the solution and should be adopted by both freeipa and >>> ovirt so that we can all be good citizens. >>> >>> Simo. >> Ok. I think we're all in agreement then. :) >> >> We'll change ovirt to be in /ovirt, and we'll wait to hear when new rpms >> are in rawhide to fix this in ipa. > > We should sync up with Rob to test his config changes for IPA to verify > that they work for us before they get pushed to rawhide. > > Dan. The patch is in: https://www.redhat.com/archives/freeipa-devel/2008-March/msg00063.html You can probably apply this by-hand to an existing IPA install, just some of the paths will change. We discussed in IRC to change this even further and put everything that IPA uses into the /ipa namespace. Simo suggested: /ipa/ui /ipa/xml /ipa/errors /ipa/static /ipa/config I'll look into that next. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Thu Mar 27 21:00:27 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 27 Mar 2008 17:00:27 -0400 Subject: [Ovirt-devel] ports and hostnames for the ovirt server In-Reply-To: <1206649908.22539.13.camel@localhost.localdomain> References: <47EBBA3D.6040300@redhat.com> <20080327152758.GD22443@redhat.com> <1206649908.22539.13.camel@localhost.localdomain> Message-ID: <1206651627.3533.49.camel@localhost.localdomain> On Thu, 2008-03-27 at 13:31 -0700, David Lutterkort wrote: > On Thu, 2008-03-27 at 15:27 +0000, Daniel P. Berrange wrote: > > Name based virtual hosting breaks with Kerberos too, because the oVirt > > server's CANME will resolve to an IP, and then reverse resolve to a > > different name. All services using Kerberos need real A records AFAICT > > That is an extremely serious shortcoming in practice, since generally > you should make the hostnames for any services CNAME's so that you can > move them around easily and transparently. You can use CNAMEs all you want as long as they point to an A name and that A name is what you use to cretae the http/fqdn at REALM service principal. When you move a service to another machine you generally do not move the kerberos credentials, but you use the new credentials of the new target machine. If something does not work in this context then it might be a client bug. Simo. -- Simo Sorce * Red Hat, Inc * New York From mmorsi at redhat.com Fri Mar 28 01:07:47 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Thu, 27 Mar 2008 21:07:47 -0400 Subject: [Ovirt-devel] [Patch] better exceptions for ruby-libvirt bindings In-Reply-To: <1206634486.22539.4.camel@localhost.localdomain> References: <47EAE320.1000307@redhat.com> <1206634486.22539.4.camel@localhost.localdomain> Message-ID: <47EC44E3.7040509@redhat.com> David Lutterkort wrote: > On Wed, 2008-03-26 at 19:58 -0400, Mohammed Morsi wrote: > >> Defined custom libvirt ruby exceptions and altered the code so as to >> throw them instead of the generic 'rb_eSystemCallError'. If additional >> more-granular exceptions are needed, they can be easily added. >> > > The patch looks good, except for some small formatting issues (try to > keep the lines to < 80 columns, I usually stop at 78) > Gotchya, will do. > >> (note >> this diff is against ruby-libvirt-0.0.2 due to issues with the upstream >> ruby-libvirt and libvirt-devel) >> > > The issue, I assume is that the ruby-libvirt bindings will only build > against a libvirt with storage API. That really needs to be ifdef'd out; > one option is to do that function by function: that's so tedious that > we'll probably need to switch to generating _libvirt.c. > > The other option is to just check for certain types (like > virStoragePoolPtr) and then ifdefing the whole storage API out. I'll > have a stab at that and hope that it won't make forward porting your > patch impossible. > > David > > The storage APIs are most likely the problem, I remember seeing related errors when I tried compiling the upstream version. If you change it so that it works, don't worry about breaking my patch, it shouldn't take too long to readd it (plus its really simple, just the error definitions, instantiations, and usage). One question I had was as to the need to pass the virConnectPtr into the _E / vir_error methods. It is not used, yet everything passes it in. If there is no need for it, can it be removed? -Mo From mmorsi at redhat.com Fri Mar 28 01:24:40 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Thu, 27 Mar 2008 21:24:40 -0400 Subject: [Ovirt-devel] oVirt Model UML Class Diagram Message-ID: <47EC48D8.6090806@redhat.com> Hey I am a big fan of design and documentation, and as I've been setting up and playing around with the oVirt code, I created this uml diagram of the model classes / tables we have. Attached is also the original DIA file used to generate the image incase anyone wants to add something or make corrections. If you know anything is off or awry feel free to shout out. -------------- next part -------------- A non-text attachment was scrubbed... Name: ovirt-model.png Type: image/png Size: 104611 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: model.dia Type: application/x-dia-diagram Size: 6098 bytes Desc: not available URL: From pmyers at redhat.com Fri Mar 28 04:40:59 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Fri, 28 Mar 2008 00:40:59 -0400 Subject: [Ovirt-devel] host-keyadd daemon Message-ID: <47EC76DB.2060903@redhat.com> Right now the host-keyadd daemon and some of the python utility scripts use kadmin.local to do things like create host principals for the ovirt managed hosts. This makes it so the ipa and ovirt servers need to be on the same box. I was thinking that it would make more sense to generate a keytab for the ovirt mgmt host and grant that principal privileges to kadmin running on the ipa server. Then the ovirt daemons can use kadmin instead of kadmin.local. The developer install would just need to have a few more things scripted to create the principal and keytab. And we'd have to provide instructions for doing this for the production install. Is this the right path to go down, or should we be doing something else? If people think this is reasonable, I'll make the changes. Perry -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=| From bkearney at redhat.com Fri Mar 28 12:27:49 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 28 Mar 2008 08:27:49 -0400 Subject: [Ovirt-devel] oVirt Model UML Class Diagram In-Reply-To: <47EC48D8.6090806@redhat.com> References: <47EC48D8.6090806@redhat.com> Message-ID: <47ECE445.1020703@redhat.com> Perhaps a resend... did you try railroad (http://railroad.rubyforge.org/). It can generate some diagrams for you right from the rails media. -- bk Mohammed Morsi wrote: > Hey I am a big fan of design and documentation, and as I've been setting > up and playing around with the oVirt code, I created this uml diagram of > the model classes / tables we have. Attached is also the original DIA > file used to generate the image incase anyone wants to add something or > make corrections. If you know anything is off or awry feel free to shout > out. > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ovirt-devel mailing list > Ovirt-devel at redhat.com > https://www.redhat.com/mailman/listinfo/ovirt-devel From jguiditt at redhat.com Fri Mar 28 14:47:22 2008 From: jguiditt at redhat.com (jay) Date: Fri, 28 Mar 2008 10:47:22 -0400 Subject: [Ovirt-devel] oVirt Model UML Class Diagram In-Reply-To: <47ECE445.1020703@redhat.com> References: <47EC48D8.6090806@redhat.com> <47ECE445.1020703@redhat.com> Message-ID: <47ED04FA.6020808@redhat.com> Mail client went squirrelly this morning, sorry if this goes through twice. Excellent Mo, I was wanting to do that as well. Just for fun, I gave railroad a quick try -thanks Bryan, hadnt heard of this tool. Pretty nice, easy to use, and the diagrams dont have to be maintained manually (maybe yours dont either, not sure how they were generated). I attached the output for controllers and models in both graphiz dot format and as pngs. Btw, railroad is available as a gem. -j Bryan Kearney wrote: > Perhaps a resend... did you try railroad > (http://railroad.rubyforge.org/). It can generate some diagrams for > you right from the rails media. > > -- bk > > > Mohammed Morsi wrote: >> Hey I am a big fan of design and documentation, and as I've been >> setting up and playing around with the oVirt code, I created this uml >> diagram of the model classes / tables we have. Attached is also the >> original DIA file used to generate the image incase anyone wants to >> add something or make corrections. If you know anything is off or >> awry feel free to shout out. >> >> ------------------------------------------------------------------------ >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Ovirt-devel mailing list >> Ovirt-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/ovirt-devel > > _______________________________________________ > Ovirt-devel mailing list > Ovirt-devel at redhat.com > https://www.redhat.com/mailman/listinfo/ovirt-devel -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: controllers.dot URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: controllers.png Type: image/png Size: 159220 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: models.dot URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: models.png Type: image/png Size: 306522 bytes Desc: not available URL: From clalance at redhat.com Fri Mar 28 14:35:02 2008 From: clalance at redhat.com (Chris Lalancette) Date: Fri, 28 Mar 2008 10:35:02 -0400 Subject: [Ovirt-devel] [PATCH] replace ks_fold_include.py with ksflatten In-Reply-To: <47EBB613.5090804@redhat.com> References: <47EBB613.5090804@redhat.com> Message-ID: <47ED0216.8080701@redhat.com> Alan Pevec wrote: > commit 6a9675dff3f0b63d3e2a3a2f1acf24883560258f > Author: Alan Pevec > Date: Thu Mar 27 14:46:25 2008 +0100 > > replace ks_fold_include.py with ksflatten from pykickstart > ksflatten parses and validates kickstart files > NB: two %include in a row end up w/o line-feed between them, hence change in .ks files: > %include ... > + > %include ... > > requires pykickstart >= 1.14 Applied. Thanks! Chris Lalancette From rcritten at redhat.com Fri Mar 28 15:18:56 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 28 Mar 2008 11:18:56 -0400 Subject: [Freeipa-devel] Re: [Ovirt-devel] ports and hostnames for the ovirt server In-Reply-To: <47ED0B50.7020704@redhat.com> References: <47EBBA3D.6040300@redhat.com> <1206632088.3533.22.camel@localhost.localdomain> <47EBBFE8.4080205@redhat.com> <20080327154241.GE22443@redhat.com> <47EBF8CB.4010606@redhat.com> <47ED0B50.7020704@redhat.com> Message-ID: <47ED0C60.7080006@redhat.com> David O'Brien wrote: > Rob Crittenden wrote: >> Daniel P. Berrange wrote: >>> On Thu, Mar 27, 2008 at 11:40:24AM -0400, Perry N. Myers wrote: >>>> Simo Sorce wrote: >>>>> I think opt 3 is the solution and should be adopted by both freeipa >>>>> and >>>>> ovirt so that we can all be good citizens. >>>>> >>>>> Simo. >>>> Ok. I think we're all in agreement then. :) >>>> >>>> We'll change ovirt to be in /ovirt, and we'll wait to hear when new >>>> rpms >>>> are in rawhide to fix this in ipa. >>> >>> We should sync up with Rob to test his config changes for IPA to verify >>> that they work for us before they get pushed to rawhide. >>> >>> Dan. >> >> The patch is in: >> >> https://www.redhat.com/archives/freeipa-devel/2008-March/msg00063.html >> >> You can probably apply this by-hand to an existing IPA install, just >> some of the paths will change. >> >> We discussed in IRC to change this even further and put everything >> that IPA uses into the /ipa namespace. >> >> Simo suggested: /ipa/ui /ipa/xml /ipa/errors /ipa/static /ipa/config >> >> I'll look into that next. >> >> rob > Will you also use this for the replica info files that we were thinking > of putting in /var/lib/ipa ? > These aren't directories, the are the proposed URI's for the web server. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From daobrien at redhat.com Fri Mar 28 15:14:24 2008 From: daobrien at redhat.com (David O'Brien) Date: Sat, 29 Mar 2008 01:14:24 +1000 Subject: [Freeipa-devel] Re: [Ovirt-devel] ports and hostnames for the ovirt server In-Reply-To: <47EBF8CB.4010606@redhat.com> References: <47EBBA3D.6040300@redhat.com> <1206632088.3533.22.camel@localhost.localdomain> <47EBBFE8.4080205@redhat.com> <20080327154241.GE22443@redhat.com> <47EBF8CB.4010606@redhat.com> Message-ID: <47ED0B50.7020704@redhat.com> Rob Crittenden wrote: > Daniel P. Berrange wrote: >> On Thu, Mar 27, 2008 at 11:40:24AM -0400, Perry N. Myers wrote: >>> Simo Sorce wrote: >>>> I think opt 3 is the solution and should be adopted by both freeipa >>>> and >>>> ovirt so that we can all be good citizens. >>>> >>>> Simo. >>> Ok. I think we're all in agreement then. :) >>> >>> We'll change ovirt to be in /ovirt, and we'll wait to hear when new >>> rpms >>> are in rawhide to fix this in ipa. >> >> We should sync up with Rob to test his config changes for IPA to verify >> that they work for us before they get pushed to rawhide. >> >> Dan. > > The patch is in: > > https://www.redhat.com/archives/freeipa-devel/2008-March/msg00063.html > > You can probably apply this by-hand to an existing IPA install, just > some of the paths will change. > > We discussed in IRC to change this even further and put everything > that IPA uses into the /ipa namespace. > > Simo suggested: /ipa/ui /ipa/xml /ipa/errors /ipa/static /ipa/config > > I'll look into that next. > > rob Will you also use this for the replica info files that we were thinking of putting in /var/lib/ipa ? /dob -- David O'Brien IPA Content Author Red Hat Asia Pacific "We couldn't care less about comfort. We make you feel good." Federico Minoli CEO Ducati Motor S.p.A. From mmorsi at redhat.com Fri Mar 28 15:51:11 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Fri, 28 Mar 2008 11:51:11 -0400 Subject: [Ovirt-devel] oVirt Model UML Class Diagram In-Reply-To: <47ED04FA.6020808@redhat.com> References: <47EC48D8.6090806@redhat.com> <47ECE445.1020703@redhat.com> <47ED04FA.6020808@redhat.com> Message-ID: <47ED13EF.8090308@redhat.com> Resending, not sure what happened to the original message (the diagram is showing up in my sent folder fine). I'll also check out that railroad utility. Thanks! -Mo jay wrote: > Mail client went squirrelly this morning, sorry if this goes through > twice. > Excellent Mo, I was wanting to do that as well. Just for fun, I gave > railroad a quick try -thanks Bryan, hadnt heard of this tool. Pretty > nice, easy to use, and the diagrams dont have to be maintained manually > (maybe yours dont either, not sure how they were generated). I > attached the output for controllers and models in both graphiz dot > format and as pngs. Btw, railroad is available as a gem. > > -j > > Bryan Kearney wrote: >> Perhaps a resend... did you try railroad >> (http://railroad.rubyforge.org/). It can generate some diagrams for >> you right from the rails media. >> >> -- bk >> >> >> Mohammed Morsi wrote: >>> Hey I am a big fan of design and documentation, and as I've been >>> setting up and playing around with the oVirt code, I created this >>> uml diagram of the model classes / tables we have. Attached is also >>> the original DIA file used to generate the image incase anyone wants >>> to add something or make corrections. If you know anything is off or >>> awry feel free to shout out. >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> Ovirt-devel mailing list >>> Ovirt-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/ovirt-devel >> >> _______________________________________________ >> Ovirt-devel mailing list >> Ovirt-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/ovirt-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: model.dia Type: application/x-dia-diagram Size: 6098 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ovirt-model.png Type: image/png Size: 104611 bytes Desc: not available URL: From hbrock at redhat.com Fri Mar 28 16:04:34 2008 From: hbrock at redhat.com (Hugh O. Brock) Date: Fri, 28 Mar 2008 12:04:34 -0400 Subject: [Ovirt-devel] host-keyadd daemon In-Reply-To: <47EC76DB.2060903@redhat.com> References: <47EC76DB.2060903@redhat.com> Message-ID: <20080328160434.GU3009@redhat.com> On Fri, Mar 28, 2008 at 12:40:59AM -0400, Perry N. Myers wrote: > Right now the host-keyadd daemon and some of the python utility scripts > use kadmin.local to do things like create host principals for the ovirt > managed hosts. This makes it so the ipa and ovirt servers need to be on > the same box. > > I was thinking that it would make more sense to generate a keytab for the > ovirt mgmt host and grant that principal privileges to kadmin running on > the ipa server. Then the ovirt daemons can use kadmin instead of > kadmin.local. > > The developer install would just need to have a few more things scripted > to create the principal and keytab. And we'd have to provide instructions > for doing this for the production install. > > Is this the right path to go down, or should we be doing something else? > If people think this is reasonable, I'll make the changes. > FWIW the IPA guys say using kadmin kills kittens and we should be using their ipa-* scripts instead... that doesn't necessarily change the general outline of what you're doing, but the implementation is going to be a little different... --H From pmyers at redhat.com Fri Mar 28 16:11:08 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Fri, 28 Mar 2008 12:11:08 -0400 Subject: [Ovirt-devel] host-keyadd daemon In-Reply-To: <20080328160434.GU3009@redhat.com> References: <47EC76DB.2060903@redhat.com> <20080328160434.GU3009@redhat.com> Message-ID: <47ED189C.5060202@redhat.com> Hugh O. Brock wrote: > FWIW the IPA guys say using kadmin kills kittens and we should be > using their ipa-* scripts instead... that doesn't necessarily change > the general outline of what you're doing, but the implementation is > going to be a little different... > I sort of figured that was the case. I'll look at what the equivalent functionality exposed by the ipa scripts are and use those if possible. Perry From sseago at redhat.com Fri Mar 28 17:47:01 2008 From: sseago at redhat.com (Scott Seago) Date: Fri, 28 Mar 2008 13:47:01 -0400 Subject: [Ovirt-devel] [Patch] move app root to /ovirt for ovirt-wui Message-ID: <47ED2F15.7000806@redhat.com> This patch moves the app root to /ovirt for the ovirt wui, paving the way for ovirt and freeipa to live on the same box without having to use alternate ports. This is mostly a config change -- fixing the httpd proxy stuff to redirect to /ovirt, and telling mongrel to serve the app at /ovirt. There were a couple view changes to remove hard-coded URLs, and we have to hard-code the image/stylesheet paths in the error html pages. We are not, at this point, redirecting "/" to "/ovirt", but we may want to do that in some of the appliance install/setup scripts. Scott -------------- next part -------------- A non-text attachment was scrubbed... Name: move-app-root.patch Type: text/x-patch Size: 5421 bytes Desc: not available URL: From berrange at redhat.com Fri Mar 28 18:00:32 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 28 Mar 2008 18:00:32 +0000 Subject: [Ovirt-devel] [Patch] move app root to /ovirt for ovirt-wui In-Reply-To: <47ED2F15.7000806@redhat.com> References: <47ED2F15.7000806@redhat.com> Message-ID: <20080328180031.GB15337@redhat.com> On Fri, Mar 28, 2008 at 01:47:01PM -0400, Scott Seago wrote: > This patch moves the app root to /ovirt for the ovirt wui, paving the > way for ovirt and freeipa to live on the same box without having to use > alternate ports. > > This is mostly a config change -- fixing the httpd proxy stuff to > redirect to /ovirt, and telling mongrel to serve the app at /ovirt. > There were a couple view changes to remove hard-coded URLs, and we have > to hard-code the image/stylesheet paths in the error html pages. > > We are not, at this point, redirecting "/" to "/ovirt", but we may want > to do that in some of the appliance install/setup scripts. I'd just add a commented out rule to httpd.conf to illustrate it, eg # To make oVirt the default app on the website uncomment this line: #RewriteRule ^/$ /ovirt/ And enable this by default in our pre-built WUI appliance image. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From dlutter at redhat.com Fri Mar 28 18:07:30 2008 From: dlutter at redhat.com (David Lutterkort) Date: Fri, 28 Mar 2008 11:07:30 -0700 Subject: [Ovirt-devel] [Patch] better exceptions for ruby-libvirt bindings In-Reply-To: <47EC44E3.7040509@redhat.com> References: <47EAE320.1000307@redhat.com> <1206634486.22539.4.camel@localhost.localdomain> <47EC44E3.7040509@redhat.com> Message-ID: <1206727650.22539.30.camel@localhost.localdomain> On Thu, 2008-03-27 at 21:07 -0400, Mohammed Morsi wrote: > The storage APIs are most likely the problem, I remember seeing related > errors when I tried compiling the upstream version. I committed a change yesterday that makes the bindings build against libvirt 0.4.0 (i.e., without storage API) > One question I > had was as to the need to pass the virConnectPtr into the _E / vir_error > methods. It is not used, yet everything passes it in. If there is no > need for it, can it be removed? I think the initial intent was to use the connection to get more details about the error through virConnCopyLastError and include that in the exception being thrown. Do you want to look into that and expand vir_error accordingly ? That might also be a good way to get to finer-grained exceptions. Otherwise, yes we should get rid of that extra connection argument. David From hbrock at redhat.com Fri Mar 28 18:17:48 2008 From: hbrock at redhat.com (Hugh O. Brock) Date: Fri, 28 Mar 2008 14:17:48 -0400 Subject: [Ovirt-devel] [Patch] move app root to /ovirt for ovirt-wui In-Reply-To: <47ED2F15.7000806@redhat.com> References: <47ED2F15.7000806@redhat.com> Message-ID: <20080328181748.GV3009@redhat.com> On Fri, Mar 28, 2008 at 01:47:01PM -0400, Scott Seago wrote: > diff --git a/wui/conf/ovirt-wui b/wui/conf/ovirt-wui > index 2ad7bf1..07d7acc 100644 > --- a/wui/conf/ovirt-wui > +++ b/wui/conf/ovirt-wui > @@ -14,6 +14,7 @@ ADDR=127.0.0.1 > RAILS_ENVIRONMENT=production > USER=ovirt > GROUP=ovirt > +PREFIX=/ovirt > export RAILS_GEM_VERSION=2.0.1 > > RETVAL=0 > @@ -23,7 +24,7 @@ RETVAL=0 > start() { > echo -n "Starting ovirt-wui: " > > - mongrel_rails start -c $OVIRT_DIR -l $MONGREL_LOG -P $MONGREL_PID -a $ADDR -e $RAILS_ENVIRONMENT --user $USER --group $GROUP -d > + mongrel_rails start -c $OVIRT_DIR -l $MONGREL_LOG -P $MONGREL_PID -a $ADDR -e $RAILS_ENVIRONMENT --user $USER --group $GROUP -d --prefix=$PREFIX > RETVAL=$? > if [ $RETVAL -eq 0 ] && touch /var/lock/subsys/ovirt-wui ; then > echo_success > diff --git a/wui/conf/ovirt-wui.conf b/wui/conf/ovirt-wui.conf > index 99aa74f..df09c33 100644 > --- a/wui/conf/ovirt-wui.conf > +++ b/wui/conf/ovirt-wui.conf > @@ -12,9 +12,9 @@ ProxyRequests Off > Krb5KeyTab /etc/httpd/conf/ipa.keytab > KrbSaveCredentials on > Require valid-user > - ErrorDocument 401 /errors/401.html > - ErrorDocument 404 /errors/404.html > - ErrorDocument 500 /errors/500.html > + ErrorDocument 401 /ovirt/errors/401.html > + ErrorDocument 404 /ovirt/errors/404.html > + ErrorDocument 500 /ovirt/errors/500.html > RewriteEngine on > Order deny,allow > Allow from all > @@ -29,17 +29,17 @@ ProxyRequests Off > # RequestHeader unset Authorization > > > -Alias /stylesheets "/usr/share/ovirt-wui/public/stylesheets" > -Alias /images "/usr/share/ovirt-wui/public/images" > -Alias /errors "/usr/share/ovirt-wui/public/" > +Alias /ovirt/stylesheets "/usr/share/ovirt-wui/public/stylesheets" > +Alias /ovirt/images "/usr/share/ovirt-wui/public/images" > +Alias /ovirt/errors "/usr/share/ovirt-wui/public/" > > -ProxyPass /images ! > -ProxyPass /stylesheets ! > -ProxyPass /errors ! > -ProxyPass / http://localhost:3000/ > -ProxyPassReverse / http://localhost:3000/ > -ProxyPassReverse /images ! > -ProxyPassReverse /stylesheets ! > -ProxyPassReverse /errors ! > +ProxyPass /ovirt/images ! > +ProxyPass /ovirt/stylesheets ! > +ProxyPass /ovirt/errors ! > +ProxyPass /ovirt http://localhost:3000/ovirt > +ProxyPassReverse /ovirt http://localhost:3000/ovirt > +ProxyPassReverse /ovirt/images ! > +ProxyPassReverse /ovirt/stylesheets ! > +ProxyPassReverse /ovirt/errors ! > > > diff --git a/wui/src/app/views/library/list.rhtml b/wui/src/app/views/library/list.rhtml > index 867682f..ada16dd 100644 > --- a/wui/src/app/views/library/list.rhtml > +++ b/wui/src/app/views/library/list.rhtml > @@ -19,7 +19,7 @@ function confirm_and_submit(item){ >
> >
> -
> +<% form_tag( {:controller => 'library', :action => 'vm_actions'}, {:name => "vm_actions", :method => "post"}) do -%> > <%= tag :input, { "type" => "submit", "name" => "vm_actions[#{VmTask::ACTION_START_VM}]", "value" => "Start"} %> > <%= tag :input, { "type" => "submit", "name" => "vm_actions[#{VmTask::ACTION_SHUTDOWN_VM}]", "value" => "Stop"} %> >