On Wed, Mar 21, 2018 at 08:17:55PM +0300, Roman Kagan wrote: > On Wed, Mar 21, 2018 at 05:17:38PM +0100, Vitaly Kuznetsov wrote: > > (What I'm worried about with all our hv_* knobs is that more of them we > > have easier it is to assemble some frankenstien which won't look like > > any existing Hyper-V version; we're probably not doing a very good job > > tesing all possible hv_* combinations as people probably use 'all or > > nothing'. In case we end up finding a bug in Windows with some weird > > hv_* combination it's unlikely Microsoft will bother fixing at as it > > doesn't reproduce on any existent Hyper-V version. > > I agree that this is getting cumbersome, but, given that features get > added incrementally and we need to be able to maintain backwards > compatibility, I'm afraid this is unavoidable. > > > That said, it would be great to eventually have something like > > 'hv_ws2012r2' property making us look exactly the same real WS2012R2 > > looks like. Unfortunatelly, I'm unsure about a path to get there). > > I'm tempted to delegate this -- combining features into user-friendly > sets -- to the upper layers: libvirt or even something on top of it.
Sounds simpler to me, otherwise we would need a mechanism to tell the upper layers which of those named are usable on the current host. -- Eduardo
