[libvirt] Introducing Fabian Freyer (GSoC 2016 student)

[Roman Bogorodskiy]

  Michal Privoznik wrote:

> On 04.05.2016 13:50, 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".
> 
> Hey, that's awesome! I wasn't aware that somebody outside libvirt GSoC
> org is actually intending to work on libvirt.
> 
> > 
> > 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.
> 
> My knowledge of the bhyve is very limited, but isn't --force-reset just
> enough? Or it is merely just sending the request to the hypervisor and
> then we have to lurk for actual request execution?

--force-reset is not enough because it just forces the bhyve process to
terminate with the appropriate exit code that tells if that VM was shut
down or reset (in that case we need to manually restart it).

> >   - virDomainReboot
> 
> Michal

Roman Bogorodskiy