Welcome Fabian! - Cole On 05/04/2016 07:50 AM, Roman Bogorodskiy wrote: > Hi, > > I'd like to introduce Fabian Freyer (CCed), he's taking part in Google > Support of Code this year within FreeBSD organization and his project is > called "Improving libvirt support for bhyve". > > Below I'm sharing a tentative plan we currently have. Or, to be more > specific, it's a list of ideas for the bhyve driver with things were > implementation is clear going first, followed by items were some > additional research and working on approach needed. There's no goal to > implement everything from this list though. > > This list was assembled by Fabian with some minor edits from me. > > Suggestions and ideas are very welcome. > > --- > > The primary aim of this project is to implement missing calls and > functionality in the libvirt bhyve driver. According to the libvirt API > Support Matrix [1], there are a large number of calls not yet implemented. While > some missing API calls are not applicable to bhyve, a number of them are, > among them the following calls: > > General calls: > > - virConnectDomainXMLFromNative > This would mostly be an argument parser for a bhyve(8) and bhyvectl(8) > command line. > - virConnectGetCPUModelNames > This needs a research: bhyve is not very flexible in configuration of > what CPU model is exposed to the guest, need to figure out if that’s > worth implementing now. > > Connection calls: > > Most of these include some form of authentication handling and are > therefore not applicable. However, the following do apply to bhyve and are > easy to implement: > > - virConnectGetType > Trivially return “BHYVE” > - virConnectIsAlive > Trivially return 1, since “A connection will be classed as > alive if it is [...] local” and /dev/vmm is local. > - virConnectIsEncrypted > Trivially return 0, since bhyve does not support encrypted interfaces. > > General Domain calls: > > - virDomainGetMaxMemory > Since bhyve does not support memory ballooning, just > return the amount of memory allocated here > - virDomainGetMaxVcpus, virDomainGetVcpus > Would use the approach described in this mailing list > thread: “Until the vCPU state is exposed by bhyvectl, or we provide a > sysctl, you can use heuristics: the number of vCPU threads for the bhyve > process, or scan all vCPUs and only count those that have a non-zero RIP.” [2] > - virDomainGetCPUStats > - virDomainGetTime > - virDomainInjectNMI > Call bhyvectl --inject-nmi > - virDomainReset > Reset a bhyve VM with ‘bhyvectl --force-reset’ and then clean things up > using bhyvectl --destroy; update bhyve monitor code to handle exit > code 0 from bhyve(8) that’s corresponding to reset (0 - reset > / reboot, 1 - shutdown, 2 - halt) to trigger re-starting of the VM. > - virDomainReboot > > Block-Device level calls: > > These would implement access to the vdev block storage layer. The > plan is implement support for both file-backed and zvol-backed virtual > machines for the following API calls: > > - virDomainGetBlockInfo > - virDomainBlockPeek > - virDomainBlockCopy > - virDomainBlockStats > - virDomainBlockStatsFlags > > Going further, since zvols support snapshotting, I > plan to implement the following for zvol-backed storage: > > - virDomainBlockCommit > - virDomainBlockPull > > VirtFS layer > I would like to create patches to support > specifying filesystems when creating the domain as well as the following > calls to be merged at a later time when VirtFS-9p support for bhyve becomes > ready: > - virDomainFSFreeze > - virDomainFSThaw > > Memory inspection > - virDomainMemoryPeek > A guest’s memory space is exposed in /dev/vmm, so this > call would have to read from that. > - virDomainMemoryStats > > Virt-host-validate(1) bhyve support > > Add bhyve support to virt-host-validate: > - Check support of CPU supports features required for bhyve > - Check if the vmm module is available > - Check if essential networking things are available > (if_bridge(4), if_tap(4)) + nmdm(4) for console > > Networking support > > Currently the bhyve’s libvirt driver (as well as libxl/FreeBSD driver) > only supports L2 interface bridging. There’s no support for upper level schemas > like NAT for example. This is a huge task that involves research of what > firefall is more applicable (ipfw or pf), designing of the firewall rules and > the actual implemtation. > > PCI passthrough support > I.e. the the "bhyve ... -s 7:0,passthru,4/0/0" thing. Probably that will > involve the HAL nodedev driver modifications. > > --- > > PS For historic purposes, I've stashed the original proposal: > > https://people.freebsd.org/~novel/misc/FabianFreyer_GoogleSummerofCode2016proposalImprovingbhyvesupportforlibvirt.pdf > > 1: https://libvirt.org/hvsupport.html > 2: > https://lists.freebsd.org/pipermail/freebsd-virtualization/2014-April/002467.html > > Roman Bogorodskiy > > -- > libvir-list mailing list > libvir-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list