[libvirt] [PATCH 3/8] conf, qemu: Add support for shmem model

[Martin Kletzander]

On Fri, Oct 07, 2016 at 03:55:44PM +0100, Daniel P. Berrange wrote:
>On Fri, Oct 07, 2016 at 10:53:48AM -0400, John Ferlan wrote:
>>
>>
>> On 09/27/2016 08:24 AM, Martin Kletzander wrote:
>> > Just the default one now, new ones will be added in following commits.
>> >
>> > Signed-off-by: Martin Kletzander <mkletzan at redhat.com>
>> > ---
>> >  docs/schemas/domaincommon.rng                     |  9 +++++
>> >  src/conf/domain_conf.c                            | 44 +++++++++++++++++------
>> >  src/conf/domain_conf.h                            |  8 +++++
>> >  src/libvirt_private.syms                          |  2 ++
>> >  src/qemu/qemu_command.c                           | 11 +++++-
>> >  tests/qemuxml2argvdata/qemuxml2argv-shmem.xml     |  2 ++
>> >  tests/qemuxml2xmloutdata/qemuxml2xmlout-shmem.xml |  8 +++++
>> >  7 files changed, 72 insertions(+), 12 deletions(-)
>> >
>>
>> docs/formatdomain.html.in ??
>>
>> Just so I'm sure I understand ;-)... This is the existing 'model type'
>> for 'shmem' being implemented as the "default" (e.g. 0 entry) because we
>> know at some short time in the future we're going to be adding a new
>> type (or two).
>>

This is the 'ivshmem' being implemented as default if you don't pick any
due to the fact that there are some older domains that already have
<shmem/> without <model/> and we're sure they are using 'ivshmem'.  So
we don't want to change that.  We could add a MODEL_DEFAULT and
MODEL_IVSHMEM, but we would have to set it to _IVSHMEM in the PostParse
anyway because _DEFAULT doesn't make sense here (in contrast to other
places/options).  That is because libvirt *has* to choose the model,
there is no way to let the hypervisor (QEMU) choose.

>> Since the <model type='ivshmem'> is now going to be the default on
>> output, we should explain in some way... and encourage choosing
>> something else because "at some point in the future" ;-) we'll deprecate
>> this one (whenever that dire time exists who knows).
>>
>> Making sure #2 - we don't have to care about save files, true?  Since
>> the default will be to now to ShmemDefFormat the <model> - a save file
>> read on an older libvirt will have a failure, but that'd be true for any
>> XML change I suppose.

It won't, it would just *not* be parsed.  We're not iterating over all
children elements, we're just picking the ones we want.  Have you ever
edited the XML and lost the stuff you added because of a typo?  Well
that's exactly why.  And also why we added RNG schema validation, I
believe.

>
>IIRC ivshmem is non-migratable, so its impossible to have any existing
>save files.
>

It's not that black-n-white, there are some grey areas.  But we disabled
the migration in previous commit due to the fact that it was never safe
or that it would work for sure.  Plus it doesn't make much sense, so
IMNSHO we don't have to have a problem wrt migration.

>
>Regards,
>Daniel
>--
>|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
>|: http://libvirt.org              -o-             http://virt-manager.org :|
>|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20161011/1f57662a/attachment-0001.sig>