OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [virtio-comment] [PATCH V2 2/2] virtio: introduce STOP status bit

å 2021/8/4 äå4:36, Stefan Hajnoczi åé:
On Tue, Aug 03, 2021 at 07:42:31PM +0800, Jason Wang wrote:
å 2021/8/3 äå6:37, Stefan Hajnoczi åé:
On Tue, Aug 03, 2021 at 02:33:20PM +0800, Jason Wang wrote:
å 2021/7/26 äå11:07, Stefan Hajnoczi åé:
I guess this is just a summary of what we've already discussed and not
new information. I think an implementation today would use DBus VMState
to transfer implementation-specific device state (an opaque blob).
Instead of trying to migrate those opaque stuffs which is kind of tricky, I
wonder if we can avoid them by recording the mapping in the shared
filesystem itself.
The problem is that virtiofsd has no way of reopening the exact same
files without Linux file handles.

I believe if we want to support live migration of the passthrough
filesystem. The filesystem itself must be shared? (like NFS)
The virtiofs device is not tied to any particular file system backend.
The file system could be shared (available from both the source and
destination) or local. It might be a passthrough file system or
something else (an in-memory file system similar to Linux tmpfs, a
non-POSIX network storage like a REST object storage API, etc).

Yes, I meant for the case of passthrough file system, it must be shared in order to be migrated.

Or can we live migrate the whole passthrough file system to the destination as block device?



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]