qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: "Ge, Xiongzi" <Xiongzi.Ge@netapp.com>
Cc: "virtio-fs@redhat.com" <virtio-fs@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Virtio-fs] Live migration support for virtio-fs
Date: Mon, 3 May 2021 09:07:16 -0400	[thread overview]
Message-ID: <20210503130716.GB81443@redhat.com> (raw)
In-Reply-To: <423DD084-E08F-4402-AD5A-3583117A6B4E@netapp.com>

Hi Xiongzi,

Try qemu monitor to hot device add/remove that works. I think libvirt
support is yet to be added.

One issue I faced was that I had to add a pcie root to move virtiofs
device off pcie.0 and then hot add remove functionality works.

So I had to add pcie root port by adding following to qemu command
line.

-device pcie-root-port,id=root1,slot=0

And now you can hot add a device using device_add.

 (qemu) device_add vhost-user-fs-pci,bus=root1,id=myvirtiofs,chardev=char0,tag=myfs,queue-size=1024

- To hot remove device, issue from qemu monitor.

  (qemu) device_del <device_id>
  ex. device_del myvirtiofs

Thanks
Vivek

On Mon, May 03, 2021 at 12:50:56PM +0000, Ge, Xiongzi wrote:
> Thanks, Stefan!
> It seems that libvirt does not support device-attach for filesystem type device, like virtiofs. Are there any other ways to do this hot-unplugging? 
> 
> Xiongzi
> 
> On 4/8/21, 12:21 PM, "Stefan Hajnoczi" <stefanha@redhat.com> wrote:
> 
>     On Wed, Apr 07, 2021 at 06:05:29PM +0000, Ge, Xiongzi wrote:
>     > Thanks Dr Gilbert, Vivek, Stefan, Greg!
>     > I put together the discussion into this thread and CC qemu-devel@nongnu.org. 
>     > 
>     > Problem:
>     > Current Virtio-FS does not support live migration.  Even when the virtiofs directory is not mounted on the guest, VM cannot do live migration. Any suggestions/interest If we want to make this work so we can still have the live migration feature for other purpose on that VM? 
>     > 
>     > If we already have a shared file system like Ceph, does this make it different? 
> 
>     (Marc-André: I CCed you regarding D-Bus VMState, see below.)
> 
>     During the last virtio-fs call on Wednesday we discussed how to allow
>     live migration when the file system is not mounted. This means live
>     migration of a mounted file system still wouldn't be supported, but at
>     least it would be possible to migrate when the file system is not
>     mounted.
> 
>     The easiest way to do that is to hot unplug the vhost-user-fs-pci device
>     so that QEMU can live migrate the VM and then hot plug the
>     vhost-user-fs-pci device again after migration has completed. This
>     requires either manually performing the hot plug operations or some
>     automation to do this around live migration.
> 
>     A smoother approach would be for QEMU to allow live migration when the
>     file system is not mounted. Unfortunately it turns out this is actually
>     rather involved because virtiofsd runs as a separate process from QEMU
>     and the live migration interface for vhost-user devices is currently
>     pretty basic
>     (https://qemu.readthedocs.io/en/latest/interop/dbus-vmstate.html). There
>     is currently no way for virtiofsd to communicate with QEMU to allow/deny
>     live migration depending on whether virtiofsd currently has an active
>     FUSE session (mount). It might be possible to extend the D-Bus VMState
>     interface and implement support for "migration blockers" as they are
>     known in QEMU, but I wonder whether it's not better to just work on
>     full virtio-fs live migration instead. Either task is complex and I
>     wouldn't recommend it as a first contribution to virtiofsd or QEMU.
> 
>     Can you make use of the hotplug approach to live migration?
> 
>     Stefan
> 



      reply	other threads:[~2021-05-03 13:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <714BD741-AE3F-4BC5-8DFB-F5C74A8623B1@netapp.com>
     [not found] ` <YFnC9QXo6uP+2zC1@work-vm>
     [not found]   ` <20210323145312.GB483930@redhat.com>
     [not found]     ` <YFoCpIh5PCSP6gXB@work-vm>
2021-04-07 18:05       ` Live migration support for virtio-fs Ge, Xiongzi
2021-04-08 16:20         ` [Virtio-fs] " Stefan Hajnoczi
2021-05-03 12:50           ` Ge, Xiongzi
2021-05-03 13:07             ` Vivek Goyal [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=20210503130716.GB81443@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=Xiongzi.Ge@netapp.com \
    --cc=dgilbert@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=virtio-fs@redhat.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).