On Mon, Aug 11, 2014 at 8:38 AM, Levente Kurusa <lkur...@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 > > -- > libvir-list mailing list > libvir-list@redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list > >
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list