From: "Ján Tomko" <jtomko@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: ted.h.kim@oracle.com, sgarzare@redhat.com, netdev@vger.kernel.org
Subject: Re: vsock CID questions
Date: Thu, 20 Feb 2020 17:09:12 +0100 [thread overview]
Message-ID: <20200220160912.GL3065@lpt> (raw)
In-Reply-To: <20200219154317.GB1085125@stefanha-x1.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2351 bytes --]
On Wed, Feb 19, 2020 at 03:43:17PM +0000, Stefan Hajnoczi wrote:
>On Tue, Feb 18, 2020 at 02:45:38PM -0800, ted.h.kim@oracle.com wrote:
>> 1. Is there an API to lookup CIDs of guests from the host side (in libvirt)?
>
>I wonder if it can be queried from libvirt (at a minimum the domain XML
>might have the CID)? I have CCed Ján Tomko who worked on the libvirt
>support:
>
>https://libvirt.org/formatdomain.html#vsock
>
Yes, libvirt has to know the CIDs of the guest and presents them in the
domain XML:
<domain type='kvm'>
<name>test</name>
...
<devices>
...
<vsock model='virtio'>
<cid auto='no' address='4'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</vsock>
</devices>
</domain>
>> 2. In the vsock(7) man page, it says the CID might change upon migration, if
>> it is not available.
>> Is there some notification when CID reassignment happens?
>
>All established connections are reset across live migration -
>applications will notice :).
>
>Listen sockets stay open but automatically listen on the new CID.
>
>> 3. if CID reassignment happens, is this persistent? (i.e. will I see updated
>> vsock definition in XML for the guest)
>
>Another question for Ján.
Depends on the setting.
For <cid auto='yes'/>, libvirt will try to acquire the first available CID
for the guest and pass it to QEMU.
For <cid auto='no'/>, no reassignment should happend and the CID
requested in the domain XML on the source will be used (or fail to be
used) on the destination.
Jano
>
>> 4. I would like to minimize the chance of CID collision. If I understand
>> correctly, the CID is a 32-bit unsigned. So for my application, it might
>> work to put an IPv4 address. But if I adopt this convention, then I need to
>> look forward to possibly using IPv6. Anyway, would it be hard to potentially
>> expand the size of the CID to 64 bits or even 128?
>
>A little hard, since the struct sockaddr_vm that userspace applications
>use has a 32-bit CID field. This is because the existing VMware VMCI
>vsock implementation has 32-bit CIDs.
>
>virtio-vsock is ready for 64-bit CIDs (the packet header fields are
>already 64-bit) but changes to net/vmw_vsock/ core code and to the
>userspace ABI would be necessary.
>
>Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-02-20 16:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-18 22:45 vsock CID questions ted.h.kim
2020-02-19 10:44 ` Stefano Garzarella
2020-02-19 15:43 ` Stefan Hajnoczi
2020-02-20 16:09 ` Ján Tomko [this message]
2020-02-21 19:49 ` ted.h.kim
2020-02-25 11:30 ` Ján Tomko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200220160912.GL3065@lpt \
--to=jtomko@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=sgarzare@redhat.com \
--cc=stefanha@redhat.com \
--cc=ted.h.kim@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).