Re: [ovirt-users] oVirt 4.0 wishlist: oVirt Node
On Fri, Nov 20, 2015 at 1:54 PM, Giuseppe Ragusa wrote: > Hi all, > I'm trying to organize my wishes/hopes for oVirt 4.0 > > These items derive from both solitary mumblings and community talks at the > the first Italian oVirt Meetup. > > I offer to help in coding (work/family schedules permitting) but keep in mind > that I'm a sysadmin with mainly C and bash-scripting skills (but hoping to > improve my less-than-newbie Python too...) > > Since I have related interests/wishes also for Engine and VDSM, I'll send a > separate message for each one. Giuseppe, this is a nice compilation of wishes! > Let's start from the oVirt Node: > > *) oVirt Node complete convergence with Atomic Host: start from Project > Atomic tools and define an ISO-installable Atomic Host variant [1] to include > gluster, qemu, libvirt, vdsm and all the packages/configurations that an > oVirt Node would need (remove unneeded parts) That's a nice idea and we actually actively investigated to use Atomic Host. Atomic is pretty strong on quickly building and deploying trees. It also provides the nice features to rollback in case of accidents, and also has a vibrant community. But we encountered a few issues i.e. Atomic has tough requirements on how the root filesystem must look, and how packages can touch/change the root file-system. Besides that we were seeing issues when it comes to support a wider range of (multipathed) storage hardware. To just name two issues. So for now we don't aim to build Node an the foundations of Atomic. But we are working on an approach which is similar to Atomic and allows us to address some long standing issues and make Node much easier to use, maintain, and customize. Stay tuned for news on the Node development road-map. > *) add oVirt Node ability to host containers (independent of the above > mentioned convergence with Atomic); note that Atomic Host has > Docker/Kubernetes, but libvirt already has a LXC driver [2] and the Engine > could benefit from some added smartness in managing groups of guests etc. in > the vm case too; there are related wishlist items on configuring/managing > containers on the Engine and on VDSM Actually a good point which I also had on my mind. The main focus of Node will be to host VMs, but having basic container support to host containers for supporting a feature is surely something interesting. > *) add Open vSwitch direct support (not Neutron-mediated); there are related > wishlist items on configuring/managing Open vSwitch on the Engine and on VDSM This will need work on the vdsm side before it makes sense to pull this into Node. > *) add oVirt Node ability to fully perform as a stand-alone hypervisor: I > hear that Cockpit is coming, so why not Kimchi too? ;) Yep, Cockpit will be part of the game on Node. Kimchi might be problematic - not because of Node - but because of the way how libvirtd is tuned towards vdsm. The last time I looked the issue was that libvirtd is not consumable by kimchi anymore, once vdsm has configured it. And to me it looks like this does not really fit anyway right now, because the current assumption is that Engine has the full control over VMs - and this would be not true anymore if you could use kimchi to administer your VMs. - fabian ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] oVirt 4.0 wishlist: oVirt Node
On Fri, Nov 20, 2015 at 1:54 PM, Giuseppe Ragusa < giuseppe.rag...@hotmail.com> wrote: > Hi all, > I'm trying to organize my wishes/hopes for oVirt 4.0 > > These items derive from both solitary mumblings and community talks at the > the first Italian oVirt Meetup. > Thanks Giuseppe! > > I offer to help in coding (work/family schedules permitting) but keep in > mind that I'm a sysadmin with mainly C and bash-scripting skills (but > hoping to improve my less-than-newbie Python too...) > > Since I have related interests/wishes also for Engine and VDSM, I'll send > a separate message for each one. > > Let's start from the oVirt Node: > > *) oVirt Node complete convergence with Atomic Host: start from Project > Atomic tools and define an ISO-installable Atomic Host variant [1] to > include gluster, qemu, libvirt, vdsm and all the packages/configurations > that an oVirt Node would need (remove unneeded parts) > > *) add Samba, CTDB and Ganesha to oVirt Node to allow it to be used as a > full storage appliance (specifically, I'm thinking of the GlusterFS > integration); there are related wishlist items on configuring/managing > Samba/CTDB/Ganesha on the Engine and on VDSM > > *) add oVirt Node ability to host containers (independent of the above > mentioned convergence with Atomic); note that Atomic Host has > Docker/Kubernetes, but libvirt already has a LXC driver [2] and the Engine > could benefit from some added smartness in managing groups of guests etc. > in the vm case too; there are related wishlist items on > configuring/managing containers on the Engine and on VDSM > > *) add Open vSwitch direct support (not Neutron-mediated); there are > related wishlist items on configuring/managing Open vSwitch on the Engine > and on VDSM > > *) add DRBD9 as a supported Storage Domain type, maybe for HC and HE too; > there are related wishlist items on configuring/managing DRBD9 on the > Engine and on VDSM > > *) add oVirt Node ability to fully perform as a stand-alone hypervisor: I > hear that Cockpit is coming, so why not Kimchi too? ;) > > Regards, > Giuseppe > > [1] product.json, I suppose, but I'm starting to learn Atomic now... > > [2] barring a pending deprecation in RHEL7, but I suppose that a > community/Centos-Virt-SIG libvirt build could restore it and maybe RedHat > too could support it on a special libvirt build for RHEV (just to remove > those support costs from the base RHEL OS offering) > ___ > Users mailing list > Users@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] oVirt 4.0 wishlist: oVirt Node
Hi all, I'm trying to organize my wishes/hopes for oVirt 4.0 These items derive from both solitary mumblings and community talks at the the first Italian oVirt Meetup. I offer to help in coding (work/family schedules permitting) but keep in mind that I'm a sysadmin with mainly C and bash-scripting skills (but hoping to improve my less-than-newbie Python too...) Since I have related interests/wishes also for Engine and VDSM, I'll send a separate message for each one. Let's start from the oVirt Node: *) oVirt Node complete convergence with Atomic Host: start from Project Atomic tools and define an ISO-installable Atomic Host variant [1] to include gluster, qemu, libvirt, vdsm and all the packages/configurations that an oVirt Node would need (remove unneeded parts) *) add Samba, CTDB and Ganesha to oVirt Node to allow it to be used as a full storage appliance (specifically, I'm thinking of the GlusterFS integration); there are related wishlist items on configuring/managing Samba/CTDB/Ganesha on the Engine and on VDSM *) add oVirt Node ability to host containers (independent of the above mentioned convergence with Atomic); note that Atomic Host has Docker/Kubernetes, but libvirt already has a LXC driver [2] and the Engine could benefit from some added smartness in managing groups of guests etc. in the vm case too; there are related wishlist items on configuring/managing containers on the Engine and on VDSM *) add Open vSwitch direct support (not Neutron-mediated); there are related wishlist items on configuring/managing Open vSwitch on the Engine and on VDSM *) add DRBD9 as a supported Storage Domain type, maybe for HC and HE too; there are related wishlist items on configuring/managing DRBD9 on the Engine and on VDSM *) add oVirt Node ability to fully perform as a stand-alone hypervisor: I hear that Cockpit is coming, so why not Kimchi too? ;) Regards, Giuseppe [1] product.json, I suppose, but I'm starting to learn Atomic now... [2] barring a pending deprecation in RHEL7, but I suppose that a community/Centos-Virt-SIG libvirt build could restore it and maybe RedHat too could support it on a special libvirt build for RHEV (just to remove those support costs from the base RHEL OS offering) ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
