[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [RFC PATCH 0/5] ivshmem support






On Mon, Aug 11, 2014 at 8:38 AM, Levente Kurusa <lkurusa redhat com> wrote:
On Aug 06 2014, Wang Rui wrote:
>On 2014/8/6 0:48, Maxime Leroy wrote:
>> The following patches are an implementation proposal
>> for the ivshmem device support in libvirt.
>>
>> Any feedback is welcome.
>>
>> Note:
>>    SELinux is not supported (need to be done for the next
>>    patchset version)
>>
>
>Just some questiones:
>Is there only one master at most on a host?

Right now, qemu does not have any restriction on the number of masters
on a host.

>What will happen if two masters(in one VM or two VMS) on a host?

By default, all ivshmem devices are 'master' unless specified to be
'peer' on the command line. The only difference between 'master' and
'peer' is that 'peer' blocks migration.

My guess is that this mode-thing was a planned feature to solve
migration problems. According to my understanding the following was
meant to be:

The guests using the same SHM are virtually grouped together, having
one (and only one!) master guest, the rest being peer guests. On
migration the guest-group can only be migrated to the same host and all
together.

The master guest will copy over the SHM. Before this happens the ivshmem
devices are detached from the peer guests using PCI/ACPI hotplug. Once
the master finishes the copy, the guests are migrated and the peers are
reattached with a new fd pointing to the new shm object on the new host.

So, to answer your question: My guess is that you can have as much
master guests on the host, given that each master has a unique SHM.

Hello,

One master per SHM is the original intent.  The goal was to make migration behaviour explicit for each guest.

Cam
  
 
Thanks!
Levente Kurusa


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]