On 07/24/2013 11:22 AM, Anthony Liguori wrote: The ovirt-node team is very excited by this project. We can't wait to get it incorporated into an ovirt-node build. Mike

On 07/24/2013 11:22 PM, Anthony Liguori wrote: Perfect, I would use it myself. I think it is really missing in the current oVirt palette. +1

----- Original Message ----- | From: "Itamar Heim" <iheim(a)redhat.com&gt; | To: "Anthony Liguori" <aliguori(a)us.ibm.com&gt; | Cc: "board" <board(a)ovirt.org&gt; | Sent: Friday, July 26, 2013 6:59:29 AM | Subject: Re: Submitting Kimchi project as an oVirt incubator project | | On 07/24/2013 06:22 PM, Anthony Liguori wrote: | > | > Hi, | > | > Kimchi is a web-based management tool meant as an entry level tool for | > interacting with KVM. It compliments oVirt well allowing the project to | > provide both a starting point for virtualization that can expand to a | > large enterprise environment. | > | > We believe that Kimchi will benefit by being part of the oVirt umbrella | > as we can work together to make the interfaces consistent with the oVirt | > UI and integrate with ovirt-node to provide a complete stand alone | > virtualization experience for an end-user. | Indeed much needed for various use cases from my talks in various events. People would often ask me about managing a 1-2 hosts setup and Kimchi fits right in and I'll be happy to demo it once I have the opportunity. | hi Anthony, | | I think it will be great to compliment the ovirt solution. | Is the idea to try and match the user portal/power user portal look and | feel / style? | I think its important to try and make it feel its coming from the same | family. | we'll VMs and templates be portable from one to the other (via ovf? | something else?) | show list of VMs from a remote ovirt-engine as well? | | do i understand correctly its a simplified web based "virt-manager", or | 'server oriented' boxes, or am i missing something? | (say, what's the envisioned roadmap of development for features?) | | Thanks, | Itamar | I agree keeping user experience and interoperability are important to make it a valuable member of the oVirt ecosystem. This should allow Kimchi users to grow their setups on the one hand, while test a specific VM locally using Kimchy on the other hand. So +1 from me, as long as we make sure users can benefit both projects together without needing to re-create their guests. | > | > More information about Kimchi is available at: | > | > http://github.com/kimchi-project/kimchi | > | > Let me know if there is additional information I can provide about the | > project. | > | > Regards, | > | > Anthony Liguori | > | > _______________________________________________ | > Board mailing list | > Board(a)ovirt.org | > http://lists.ovirt.org/mailman/listinfo/board | > | | _______________________________________________ | Board mailing list | Board(a)ovirt.org | http://lists.ovirt.org/mailman/listinfo/board |

Itamar Heim <iheim(a)redhat.com&gt; writes: That would be ideal although not a short term goal. What we really want is for there to be a seamless transition between Kimchi and oVirt-engine. We envision a user install Kimchi (via a Fedora based oVirt node ISO), playing around with KVM, creating some guests, and then deciding they need more. The user would then initial bringing the node into a datacenter and ideally, would be able to import those VMs into ovirt-engine in a seamless fashion. This is the bigger focus for us vs. just making the look and feel the same. Yes, this is an explicit goal. The scope right now is narrowly focused on single node. I personally think it's important to avoid creeping the scope beyond that. It really is about getting someone to do useful things with KVM with the absolute smallest number of steps. Web-based virt-manager is a good starting point. The biggest difference though is that while virt-manager is a UI designed around exposing the features of libvirt, Kimchi's UI design is much more oriented to a particular type of user and simplifying the workflows that they'd have. The user we focus on is the "tire-kicker". They are primarily Windows users who may already have experience with VMware but no direct experience with oVirt or KVM. https://github.com/kimchi-project/kimchi/wiki/TODO Regards, Anthony Liguori

Livnat Peer <lpeer(a)redhat.com&gt; writes: Exactly :-/ OVF is probably a handy way of communicating the metadata. An open question is storage/network configuration. We have the concept of storage/network pools that are implemented strictly in terms of libvirt. It would be really handy to be able to have ovirt automatically create a storage pool from one defined in Kimchi for the entire datacenter so that you can do mobility. If we do it right, the concept could also extend beyond Kimchi for a number of libvirt-based tools. Regards, Anthony Liguori