All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: fengyd <fengyd81@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Fwd: How live migration work for vhost-user
Date: Mon, 29 Apr 2019 17:15:02 +0100	[thread overview]
Message-ID: <20190429161502.GI2748@work-vm> (raw)
In-Reply-To: <CACnvu8Y7OQSYgGUXm5+bdB0owwmm+gSDpuaGQn=5QNhB5wcjvQ@mail.gmail.com>

* fengyd (fengyd81@gmail.com) wrote:
> Hi,
> 
> I want to add some log to qemu-kvm-ev.
> Do you know how to compile qemu-kvm-ev from source code?

That's our downstream package build; it should build fine with rpmbuild,
or you can configure and build it like any other qemu.

Dave

> Thanks
> 
> Yafeng
> 
> On Tue, 16 Apr 2019 at 16:47, Dr. David Alan Gilbert <dgilbert@redhat.com>
> wrote:
> 
> > * fengyd (fengyd81@gmail.com) wrote:
> > > ---------- Forwarded message ---------
> > > From: fengyd <fengyd81@gmail.com>
> > > Date: Tue, 16 Apr 2019 at 09:17
> > > Subject: Re: [Qemu-devel] How live migration work for vhost-user
> > > To: Dr. David Alan Gilbert <dgilbert@redhat.com>
> > >
> > >
> > > Hi,
> > >
> > > Any special feature needs to be supported on guest driver?
> > > Because it's OK for standard Linux VM, but not OK for our VM where virtio
> > > is  implemented by ourself.
> >
> > I'm not sure; you do have to support that 'log' mechanism but I don't
> > know what else is needed.
> >
> > > And with qemu-kvm-ev-2.6, live migration can work with our VM where
> > virtio
> > > is  implemented by ourself.
> >
> > 2.6 is pretty old, so there's a lot of changes - not sure what's
> > relevant.
> >
> > Dave
> >
> > > Thanks
> > > Yafeng
> > >
> > > On Mon, 15 Apr 2019 at 22:54, Dr. David Alan Gilbert <
> > dgilbert@redhat.com>
> > > wrote:
> > >
> > > > * fengyd (fengyd81@gmail.com) wrote:
> > > > > Hi,
> > > > >
> > > > > During live migration,  the folloing log can see in nova-compute.log
> > in
> > > > my
> > > > > environment:
> > > > >  ERROR nova.virt.libvirt.driver
> > [req-039a85e1-e7a1-4a63-bc6d-c4b9a044aab6
> > > > > 0cdab20dc79f4bc6ae5790e7b4a898ac 3363c319773549178acc67f32c78310e -
> > > > default
> > > > > default] [instance: 5ec719f4-1865-4afe-a207-3d9fae22c410] Live
> > Migration
> > > > > failure: internal error: qemu unexpectedly closed the monitor:
> > > > > 2019-04-15T02:58:22.213897Z qemu-kvm: VQ 0
> > > > > size 0x100 < last_avail_idx 0x1e - used_idx 0x23
> > > > >
> > > > > It's OK for standard Linux VM, but not OK for our VM where virtio is
> > > > > implemented by ourself.
> > > > > KVM version as follow:
> > > > > qemu-kvm-common-ev-2.12.0-18.el7_6.3.1.x86_64
> > > > > qemu-kvm-ev-2.12.0-18.el7_6.3.1.x86_64
> > > > > libvirt-daemon-kvm-3.9.0-14.2.el7.centos.ncir.8.x86_64
> > > > >
> > > > > Do you know what's the difference between virtio and vhost-user
> > during
> > > > > migration?
> > > > > The function virtio_load in Qemu is called for virtio and vhost-user
> > > > during
> > > > > migration.
> > > > > For virtio,  last_avail_idx  and used_idx are stored in Qemu, Qemu is
> > > > > responsible for updating their values accordingly
> > > > > For vhost-user, last_avail_idx  and used_idx are stored in vhost-user
> > > > app,
> > > > > eg. DPDK, not in Qemu?
> > > > > How does migration work for vhost-user?
> > > >
> > > > I don't know the details, but my understanding is that vhost-user
> > > > tells the vhost-user client about an area of 'log' memory, where the
> > > > vhost-user client must mark pages as dirty.
> > > >
> > > > In the qemu source, see docs/interop/vhost-user.txt and see
> > > > the VHOST_SET_LOG_BASE and VHOST_USER_SET_LOG_FD calls.
> > > >
> > > > If the client correctly marks the areas as dirty, then qemu
> > > > should resend those pages across.
> > > >
> > > >
> > > > Dave
> > > >
> > > > > Thanks in advance
> > > > > Yafeng
> > > > --
> > > > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> > > >
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> >
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

      parent reply	other threads:[~2019-04-29 16:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-15  8:50 [Qemu-devel] How live migration work for vhost-user fengyd
2019-04-15 14:53 ` Dr. David Alan Gilbert
     [not found]   ` <CACnvu8a5DjAUhfAGmi6GtpD1V2hfoNLTkKEgbsFuL_6GrRc+pg@mail.gmail.com>
2019-04-16  7:59     ` [Qemu-devel] Fwd: " fengyd
2019-04-16  8:47       ` Dr. David Alan Gilbert
2019-04-23  6:20         ` fengyd
2019-04-24  3:14           ` fengyd
2019-04-29 16:22             ` Dr. David Alan Gilbert
     [not found]               ` <CACnvu8bBykwoSHOAwTa0L_FD3kF=i+KW+H1MZk-x3xu1tV9gkw@mail.gmail.com>
2019-05-08  4:50                 ` [Qemu-devel] Fwd: " fengyd
2019-04-29 16:15           ` Dr. David Alan Gilbert [this message]

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=20190429161502.GI2748@work-vm \
    --to=dgilbert@redhat.com \
    --cc=fengyd81@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.