[libvirt] Introducing Fabian Freyer (GSoC 2016 student)
Michal Privoznik
mprivozn at redhat.com
Thu May 5 15:54:21 UTC 2016
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?
> - virDomainReboot
Michal
More information about the libvir-list
mailing list