[libvirt] question about rdma migration

Roy Shterman roy.shterman at gmail.com
Tue Oct 25 19:18:35 UTC 2016


Hi Jiri,

Sorry about the late response, only now I managed to push iSER into QEMU.
Because ISER is registered as a different protocol than iSCSI with the
prefix of iser:// I want to add support for it in libvirt.

Libvirt code is pretty new for me, wondered if adding
VIR_STORAGE_NET_PROTOCOL_ISER as another virStorageNetProtocol should be
enough?
Of course I added ISER in all necessary switch-case in code also.

Thanks,
Roy


On Tue, Mar 22, 2016 at 2:56 PM, Jiri Denemark <jdenemar at redhat.com> wrote:

> On Tue, Mar 22, 2016 at 14:21:52 +0200, Roy Shterman wrote:
> > Correct me if I'm wrong but locked option is pinning all VM memory in
> host
> > RAM,
> >
> > for example if I have a VM with 4G memory, and I want to run some QEMU
> code
> > which needs to pin 500M,
> >
> > I will need to lock all 4G in host memory instead of locking only 500M.
>
> So the question is which code wants to lock part of the memory, why, and
> if it's something that can be influenced by user.
>
> For example, we know that if you ask for all memory to by locked, we
> need to set the limit. The same applies when RDMA migration is started.
> On PPC we know some amount of memory will always need to be locked, we
> compute the amount and set the limit accordingly. We can't really expect
> user to have deep knowledge of QEMU and know what limit needs to be set
> when they use a specific device, QMP command, or whatever. So if the
> limit is something predictable and deterministic, we can automatically
> compute the amount of memory and use it when starting QEMU. Forcing
> users to set the limit when all memory needs to be locked is already bad
> enough that I don't think we should add a new option to explicitly set
> arbitrary lock limit.
>
> Jirka
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20161025/88e04140/attachment-0001.htm>


More information about the libvir-list mailing list