http://wiki.libvirt.org/page/Virtio#Requirements
It doesn't look like KVM is required for virtio (require for hotplugging/systemvm functions), although I wonder what is meant by "recent qemu" there, if there's no other blocker then it may be possible to skip the check for kvm modules in some specific scenario, maybe a global config that propagates to the agent.properties when a host joins or something. Then as Wido says, the host should just fall back to qemu. It should be possible. I wouldn't want any chance of a user accidentally running in that mode though. On Fri, Feb 8, 2013 at 9:05 AM, Chip Childers <chip.child...@sungard.com> wrote: > On Fri, Feb 08, 2013 at 10:47:29AM +0000, Paul Angus wrote: >> Hi Dave, >> >> Your suggestion ties in nicely which a proposal that I have been mulling >> over; and that is further abstraction of the hypervisor, by CloudStack >> becoming more ‘toolset agonistic’ to use Xen parlance, rather than >> hypervisor agnostic? >> >> It seems quite an elegant solution to expanding hypervisor support (which >> easy for me to say as I don't know how to do it)… >> >> The current toolsets / interfaces become something like: >> >> OVM Manager (OVM) >> vCenter (ESXi) >> XAPI (XenServer, XCP, Xen+XAPI) >> Libvirt (KVM, Xen+Libvirt, QEMU) >> WMI/PowerShell (Hyper-V) >> >> + a bit of logic when copying scripts across to put them in the correct >> location for any given hypervisor/distribution. > > Paul, > > I'm not sure I quite understand what you are suggesting. Can you > elaborate? > > -chip
