[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v0 0/2] virtio-blk and vhost-user-blk cross-device migration
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [PATCH v0 0/2] virtio-blk and vhost-user-blk cross-device migration |
Date: |
Tue, 5 Oct 2021 15:01:05 +0100 |
User-agent: |
Mutt/2.0.7 (2021-05-04) |
* Michael S. Tsirkin (mst@redhat.com) wrote:
> On Tue, Oct 05, 2021 at 02:18:40AM +0300, Roman Kagan wrote:
> > On Mon, Oct 04, 2021 at 11:11:00AM -0400, Michael S. Tsirkin wrote:
> > > On Mon, Oct 04, 2021 at 06:07:29PM +0300, Denis Plotnikov wrote:
> > > > It might be useful for the cases when a slow block layer should be
> > > > replaced
> > > > with a more performant one on running VM without stopping, i.e. with
> > > > very low
> > > > downtime comparable with the one on migration.
> > > >
> > > > It's possible to achive that for two reasons:
> > > >
> > > > 1.The VMStates of "virtio-blk" and "vhost-user-blk" are almost the same.
> > > > They consist of the identical VMSTATE_VIRTIO_DEVICE and differs from
> > > > each other in the values of migration service fields only.
> > > > 2.The device driver used in the guest is the same: virtio-blk
> > > >
> > > > In the series cross-migration is achieved by adding a new type.
> > > > The new type uses virtio-blk VMState instead of vhost-user-blk specific
> > > > VMstate, also it implements migration save/load callbacks to be
> > > > compatible
> > > > with migration stream produced by "virtio-blk" device.
> > > >
> > > > Adding the new type instead of modifying the existing one is convenent.
> > > > It ease to differ the new virtio-blk-compatible vhost-user-blk
> > > > device from the existing non-compatible one using qemu machinery
> > > > without any
> > > > other modifiactions. That gives all the variety of qemu device related
> > > > constraints out of box.
> > >
> > > Hmm I'm not sure I understand. What is the advantage for the user?
> > > What if vhost-user-blk became an alias for vhost-user-virtio-blk?
> > > We could add some hacks to make it compatible for old machine types.
> >
> > The point is that virtio-blk and vhost-user-blk are not
> > migration-compatible ATM. OTOH they are the same device from the guest
> > POV so there's nothing fundamentally preventing the migration between
> > the two. In particular, we see it as a means to switch between the
> > storage backend transports via live migration without disrupting the
> > guest.
> >
> > Migration-wise virtio-blk and vhost-user-blk have in common
> >
> > - the content of the VMState -- VMSTATE_VIRTIO_DEVICE
> >
> > The two differ in
> >
> > - the name and the version of the VMStateDescription
> >
> > - virtio-blk has an extra migration section (via .save/.load callbacks
> > on VirtioDeviceClass) containing requests in flight
> >
> > It looks like to become migration-compatible with virtio-blk,
> > vhost-user-blk has to start using VMStateDescription of virtio-blk and
> > provide compatible .save/.load callbacks. It isn't entirely obvious how
> > to make this machine-type-dependent, so we came up with a simpler idea
> > of defining a new device that shares most of the implementation with the
> > original vhost-user-blk except for the migration stuff. We're certainly
> > open to suggestions on how to reconcile this under a single
> > vhost-user-blk device, as this would be more user-friendly indeed.
> >
> > We considered using a class property for this and defining the
> > respective compat clause, but IIUC the class constructors (where .vmsd
> > and .save/.load are defined) are not supposed to depend on class
> > properties.
> >
> > Thanks,
> > Roman.
>
> So the question is how to make vmsd depend on machine type.
> CC Eduardo who poked at this kind of compat stuff recently,
> paolo who looked at qom things most recently and dgilbert
> for advice on migration.
I don't think I've seen anyone change vmsd name dependent on machine
type; making fields appear/disappear is easy - that just ends up as a
property on the device that's checked; I guess if that property is
global (rather than per instance) then you can check it in
vhost_user_blk_class_init and swing the dc->vmsd pointer?
Dave
> --
> MST
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
- [PATCH v0 0/2] virtio-blk and vhost-user-blk cross-device migration, Denis Plotnikov, 2021/10/04
- [PATCH v0 1/2] vhost-user-blk: add a new vhost-user-virtio-blk type, Denis Plotnikov, 2021/10/04
- [PATCH v0 2/2] vhost-user-blk-pci: add new pci device type to support vhost-user-virtio-blk, Denis Plotnikov, 2021/10/04
- Re: [PATCH v0 0/2] virtio-blk and vhost-user-blk cross-device migration, Michael S. Tsirkin, 2021/10/04
- Re: [PATCH v0 0/2] virtio-blk and vhost-user-blk cross-device migration, Roman Kagan, 2021/10/04
- Re: [PATCH v0 0/2] virtio-blk and vhost-user-blk cross-device migration, Michael S. Tsirkin, 2021/10/05
- Re: [PATCH v0 0/2] virtio-blk and vhost-user-blk cross-device migration,
Dr. David Alan Gilbert <=
- Re: [PATCH v0 0/2] virtio-blk and vhost-user-blk cross-device migration, Eduardo Habkost, 2021/10/05
- Re: [PATCH v0 0/2] virtio-blk and vhost-user-blk cross-device migration, Michael S. Tsirkin, 2021/10/05
- Re: [PATCH v0 0/2] virtio-blk and vhost-user-blk cross-device migration, Dr. David Alan Gilbert, 2021/10/06
- Re: [PATCH v0 0/2] virtio-blk and vhost-user-blk cross-device migration, Michael S. Tsirkin, 2021/10/06
- Re: [PATCH v0 0/2] virtio-blk and vhost-user-blk cross-device migration, Dr. David Alan Gilbert, 2021/10/06
- Re: [PATCH v0 0/2] virtio-blk and vhost-user-blk cross-device migration, Michael S. Tsirkin, 2021/10/06
- Re: [PATCH v0 0/2] virtio-blk and vhost-user-blk cross-device migration, Dr. David Alan Gilbert, 2021/10/06
- Re: [PATCH v0 0/2] virtio-blk and vhost-user-blk cross-device migration, Michael S. Tsirkin, 2021/10/06
- Re: [PATCH v0 0/2] virtio-blk and vhost-user-blk cross-device migration, Dr. David Alan Gilbert, 2021/10/06
- Re: [PATCH v0 0/2] virtio-blk and vhost-user-blk cross-device migration, Michael S. Tsirkin, 2021/10/06