On 01/03/2023 17:33, Michael S. Tsirkin wrote:
On Tue, Feb 28, 2023 at 07:59:54PM +0200, Anton Kuchin wrote:
We can't rely here entirely on
destination to block this because if VM is migrated to file and then
can't be loaded by destination there is no way to fallback and resume
the source so we
On 06/03/2023 23:53, Michael S. Tsirkin wrote:
On Mon, Mar 06, 2023 at 10:55:29PM +0200, Anton Kuchin wrote:
On 01/03/2023 22:22, Michael S. Tsirkin wrote:
On Wed, Mar 01, 2023 at 09:35:56PM +0200, Anton Kuchin wrote:
I do trust them :)
I have to, otherwise we would need to pack all the
On Mon, Mar 06, 2023 at 10:55:29PM +0200, Anton Kuchin wrote:
> On 01/03/2023 22:22, Michael S. Tsirkin wrote:
> > On Wed, Mar 01, 2023 at 09:35:56PM +0200, Anton Kuchin wrote:
> > > I do trust them :)
> > > I have to, otherwise we would need to pack all the properties and
> > > flags of qemu to
On 01/03/2023 22:22, Michael S. Tsirkin wrote:
On Wed, Mar 01, 2023 at 09:35:56PM +0200, Anton Kuchin wrote:
I do trust them :)
I have to, otherwise we would need to pack all the properties and
flags of qemu to the migration stream and validate them at
destination or entire migration ends up
On Wed, Mar 01, 2023 at 09:35:56PM +0200, Anton Kuchin wrote:
> I do trust them :)
> I have to, otherwise we would need to pack all the properties and
> flags of qemu to the migration stream and validate them at
> destination or entire migration ends up broken beyond repair if
> orchestrators tend
On 01/03/2023 17:52, Michael S. Tsirkin wrote:
On Wed, Mar 01, 2023 at 05:40:09PM +0200, Anton Kuchin wrote:
So catching errors in not the only purpose of this property, but it
definitely
allows us to catch some obvious ones.
OK let's say this. If migration=external then migration just works.
On 01/03/2023 19:17, Michael S. Tsirkin wrote:
On Wed, Mar 01, 2023 at 06:04:31PM +0200, Anton Kuchin wrote:
On 01/03/2023 17:24, Michael S. Tsirkin wrote:
On Wed, Mar 01, 2023 at 05:07:28PM +0200, Anton Kuchin wrote:
On 28/02/2023 23:24, Michael S. Tsirkin wrote:
On Tue, Feb 28, 2023 at
On Wed, Mar 01, 2023 at 06:29:50PM +0200, Anton Kuchin wrote:
> On 01/03/2023 17:52, Michael S. Tsirkin wrote:
> > On Wed, Mar 01, 2023 at 05:40:09PM +0200, Anton Kuchin wrote:
> > > So catching errors in not the only purpose of this property, but it
> > > definitely
> > > allows us to catch some
On Wed, Mar 01, 2023 at 06:04:31PM +0200, Anton Kuchin wrote:
> On 01/03/2023 17:24, Michael S. Tsirkin wrote:
> > On Wed, Mar 01, 2023 at 05:07:28PM +0200, Anton Kuchin wrote:
> > > On 28/02/2023 23:24, Michael S. Tsirkin wrote:
> > > > On Tue, Feb 28, 2023 at 07:59:54PM +0200, Anton Kuchin
On 01/03/2023 17:52, Michael S. Tsirkin wrote:
On Wed, Mar 01, 2023 at 05:40:09PM +0200, Anton Kuchin wrote:
So catching errors in not the only purpose of this property, but it
definitely
allows us to catch some obvious ones.
OK let's say this. If migration=external then migration just works.
On 01/03/2023 17:24, Michael S. Tsirkin wrote:
On Wed, Mar 01, 2023 at 05:07:28PM +0200, Anton Kuchin wrote:
On 28/02/2023 23:24, Michael S. Tsirkin wrote:
On Tue, Feb 28, 2023 at 07:59:54PM +0200, Anton Kuchin wrote:
On 28/02/2023 16:57, Michael S. Tsirkin wrote:
On Tue, Feb 28, 2023 at
On Wed, Mar 01, 2023 at 05:40:09PM +0200, Anton Kuchin wrote:
> So catching errors in not the only purpose of this property, but it
> definitely
> allows us to catch some obvious ones.
OK let's say this. If migration=external then migration just works.
If migration=internal it fails for now. We
On 01/03/2023 16:46, Michael S. Tsirkin wrote:
On Wed, Mar 01, 2023 at 05:03:03PM +0300, Vladimir Sementsov-Ogievskiy wrote:
On 01.03.23 00:24, Michael S. Tsirkin wrote:
Said that checking on destination would need another flag and the safe
way of using this feature would require managing
On Wed, Feb 22, 2023 at 10:50:02PM +0200, Anton Kuchin wrote:
> > Property on source does not satisfy both at the same time.
> > Property on destination does.
>
> If destination QEMUs on local and remote hosts have same properties
I'd say just make an exception from this rule.
> how can
> we
On Tue, Feb 28, 2023 at 07:59:54PM +0200, Anton Kuchin wrote:
> We can't rely here entirely on
> destination to block this because if VM is migrated to file and then
> can't be loaded by destination there is no way to fallback and resume
> the source so we need to have some kind of blocker on
On Wed, Mar 01, 2023 at 05:07:28PM +0200, Anton Kuchin wrote:
> On 28/02/2023 23:24, Michael S. Tsirkin wrote:
> > On Tue, Feb 28, 2023 at 07:59:54PM +0200, Anton Kuchin wrote:
> > > On 28/02/2023 16:57, Michael S. Tsirkin wrote:
> > > > On Tue, Feb 28, 2023 at 04:30:36PM +0200, Anton Kuchin
On 28/02/2023 23:24, Michael S. Tsirkin wrote:
On Tue, Feb 28, 2023 at 07:59:54PM +0200, Anton Kuchin wrote:
On 28/02/2023 16:57, Michael S. Tsirkin wrote:
On Tue, Feb 28, 2023 at 04:30:36PM +0200, Anton Kuchin wrote:
I really don't understand why and what do you want to check on
destination.
On Wed, Mar 01, 2023 at 05:03:03PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> On 01.03.23 00:24, Michael S. Tsirkin wrote:
> > > Said that checking on destination would need another flag and the safe
> > > way of using this feature would require managing two flags instead of one
> > > making it
On 01.03.23 00:24, Michael S. Tsirkin wrote:
Said that checking on destination would need another flag and the safe
way of using this feature would require managing two flags instead of one
making it even more fragile. So I'd prefer not to make it more complex.
In my opinion the best way to use
On Tue, Feb 28, 2023 at 04:29:22PM -0500, Michael S. Tsirkin wrote:
> On Tue, Feb 28, 2023 at 02:18:25PM -0500, Stefan Hajnoczi wrote:
> > On Tue, 28 Feb 2023 at 09:58, Michael S. Tsirkin wrote:
> > >
> > > On Tue, Feb 28, 2023 at 04:30:36PM +0200, Anton Kuchin wrote:
> > > > I really don't
On Tue, Feb 28, 2023 at 02:18:25PM -0500, Stefan Hajnoczi wrote:
> On Tue, 28 Feb 2023 at 09:58, Michael S. Tsirkin wrote:
> >
> > On Tue, Feb 28, 2023 at 04:30:36PM +0200, Anton Kuchin wrote:
> > > I really don't understand why and what do you want to check on
> > > destination.
> >
> > Yes I
On Tue, Feb 28, 2023 at 07:59:54PM +0200, Anton Kuchin wrote:
> On 28/02/2023 16:57, Michael S. Tsirkin wrote:
> > On Tue, Feb 28, 2023 at 04:30:36PM +0200, Anton Kuchin wrote:
> > > I really don't understand why and what do you want to check on
> > > destination.
> > Yes I understand your patch
On Tue, 28 Feb 2023 at 09:58, Michael S. Tsirkin wrote:
>
> On Tue, Feb 28, 2023 at 04:30:36PM +0200, Anton Kuchin wrote:
> > I really don't understand why and what do you want to check on
> > destination.
>
> Yes I understand your patch controls source. Let me try to rephrase
> why I think it's
On 28/02/2023 16:57, Michael S. Tsirkin wrote:
On Tue, Feb 28, 2023 at 04:30:36PM +0200, Anton Kuchin wrote:
I really don't understand why and what do you want to check on
destination.
Yes I understand your patch controls source. Let me try to rephrase
why I think it's better on destination.
On Tue, Feb 28, 2023 at 04:30:36PM +0200, Anton Kuchin wrote:
> I really don't understand why and what do you want to check on
> destination.
Yes I understand your patch controls source. Let me try to rephrase
why I think it's better on destination.
Here's my understanding
- With vhost-user-fs
On 24/02/2023 10:47, Michael S. Tsirkin wrote:
On Thu, Feb 23, 2023 at 04:24:43PM -0500, Stefan Hajnoczi wrote:
On Thu, Feb 23, 2023 at 02:36:33AM -0500, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at 03:21:42PM -0500, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at 08:25:19PM +0200,
On 24/02/2023 06:14, Anton Kuchin wrote:
On 23/02/2023 23:24, Stefan Hajnoczi wrote:
On Thu, Feb 23, 2023 at 02:36:33AM -0500, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at 03:21:42PM -0500, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at 08:25:19PM +0200, Anton Kuchin wrote:
On
On Thu, Feb 23, 2023 at 04:24:43PM -0500, Stefan Hajnoczi wrote:
> On Thu, Feb 23, 2023 at 02:36:33AM -0500, Michael S. Tsirkin wrote:
> > On Wed, Feb 22, 2023 at 03:21:42PM -0500, Michael S. Tsirkin wrote:
> > > On Wed, Feb 22, 2023 at 08:25:19PM +0200, Anton Kuchin wrote:
> > > > On 22/02/2023
On 23/02/2023 23:24, Stefan Hajnoczi wrote:
On Thu, Feb 23, 2023 at 02:36:33AM -0500, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at 03:21:42PM -0500, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at 08:25:19PM +0200, Anton Kuchin wrote:
On 22/02/2023 19:12, Michael S. Tsirkin wrote:
On
On Thu, Feb 23, 2023 at 02:36:33AM -0500, Michael S. Tsirkin wrote:
> On Wed, Feb 22, 2023 at 03:21:42PM -0500, Michael S. Tsirkin wrote:
> > On Wed, Feb 22, 2023 at 08:25:19PM +0200, Anton Kuchin wrote:
> > > On 22/02/2023 19:12, Michael S. Tsirkin wrote:
> > > > On Wed, Feb 22, 2023 at
On Wed, Feb 22, 2023 at 03:21:42PM -0500, Michael S. Tsirkin wrote:
> On Wed, Feb 22, 2023 at 08:25:19PM +0200, Anton Kuchin wrote:
> > On 22/02/2023 19:12, Michael S. Tsirkin wrote:
> > > On Wed, Feb 22, 2023 at 07:05:47PM +0200, Anton Kuchin wrote:
> > > > On 22/02/2023 18:51, Michael S. Tsirkin
On 22/02/2023 22:21, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at 08:25:19PM +0200, Anton Kuchin wrote:
On 22/02/2023 19:12, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at 07:05:47PM +0200, Anton Kuchin wrote:
On 22/02/2023 18:51, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at
On Wed, Feb 22, 2023 at 08:25:19PM +0200, Anton Kuchin wrote:
> On 22/02/2023 19:12, Michael S. Tsirkin wrote:
> > On Wed, Feb 22, 2023 at 07:05:47PM +0200, Anton Kuchin wrote:
> > > On 22/02/2023 18:51, Michael S. Tsirkin wrote:
> > > > On Wed, Feb 22, 2023 at 06:49:10PM +0200, Anton Kuchin
On 22/02/2023 19:12, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at 07:05:47PM +0200, Anton Kuchin wrote:
On 22/02/2023 18:51, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at 06:49:10PM +0200, Anton Kuchin wrote:
On 22/02/2023 17:14, Vladimir Sementsov-Ogievskiy wrote:
On 22.02.23
On Wed, Feb 22, 2023 at 07:15:40PM +0200, Anton Kuchin wrote:
> On 22/02/2023 18:43, Michael S. Tsirkin wrote:
> > On Wed, Feb 22, 2023 at 06:14:31PM +0300, Vladimir Sementsov-Ogievskiy
> > wrote:
> > > On 22.02.23 17:25, Anton Kuchin wrote:
> > > > > > > +static int vhost_user_fs_pre_save(void
On 22/02/2023 18:43, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at 06:14:31PM +0300, Vladimir Sementsov-Ogievskiy wrote:
On 22.02.23 17:25, Anton Kuchin wrote:
+static int vhost_user_fs_pre_save(void *opaque)
+{
+ VHostUserFS *fs = opaque;
+ g_autofree char *path =
On Wed, Feb 22, 2023 at 07:05:47PM +0200, Anton Kuchin wrote:
> On 22/02/2023 18:51, Michael S. Tsirkin wrote:
> > On Wed, Feb 22, 2023 at 06:49:10PM +0200, Anton Kuchin wrote:
> > > On 22/02/2023 17:14, Vladimir Sementsov-Ogievskiy wrote:
> > > > On 22.02.23 17:25, Anton Kuchin wrote:
> > > > > >
On 22/02/2023 18:51, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at 06:49:10PM +0200, Anton Kuchin wrote:
On 22/02/2023 17:14, Vladimir Sementsov-Ogievskiy wrote:
On 22.02.23 17:25, Anton Kuchin wrote:
+static int vhost_user_fs_pre_save(void *opaque)
+{
+ VHostUserFS *fs = opaque;
+
On Wed, Feb 22, 2023 at 06:49:10PM +0200, Anton Kuchin wrote:
> On 22/02/2023 17:14, Vladimir Sementsov-Ogievskiy wrote:
> > On 22.02.23 17:25, Anton Kuchin wrote:
> > > > > > +static int vhost_user_fs_pre_save(void *opaque)
> > > > > > +{
> > > > > > + VHostUserFS *fs = opaque;
> > > > > > +
On 22/02/2023 17:14, Vladimir Sementsov-Ogievskiy wrote:
On 22.02.23 17:25, Anton Kuchin wrote:
+static int vhost_user_fs_pre_save(void *opaque)
+{
+ VHostUserFS *fs = opaque;
+ g_autofree char *path = object_get_canonical_path(OBJECT(fs));
+
+ switch (fs->migration_type) {
+ case
On Wed, Feb 22, 2023 at 06:14:31PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> On 22.02.23 17:25, Anton Kuchin wrote:
> > > > > +static int vhost_user_fs_pre_save(void *opaque)
> > > > > +{
> > > > > + VHostUserFS *fs = opaque;
> > > > > + g_autofree char *path =
On 17.02.23 20:00, Anton Kuchin wrote:
Migration of vhost-user-fs device requires transfer of FUSE internal state
from backend. There is no standard way to do it now so by default migration
must be blocked. But if this state can be externally transferred by
orchestrator give it an option to
On 22.02.23 17:21, Anton Kuchin wrote:
1. I see, other similar qdev_prop_* use DEFINE_PROP_SIGNED
I don't think this should be signed. Enum values are non-negative so compilers
(at least gcc and clang that I checked) evaluate underlying enum type to be
unsigned int.
I don't know why other
On 22.02.23 17:25, Anton Kuchin wrote:
+static int vhost_user_fs_pre_save(void *opaque)
+{
+ VHostUserFS *fs = opaque;
+ g_autofree char *path = object_get_canonical_path(OBJECT(fs));
+
+ switch (fs->migration_type) {
+ case VHOST_USER_MIGRATION_TYPE_NONE:
+
On 22/02/2023 14:43, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at 03:20:00PM +0300, Vladimir Sementsov-Ogievskiy wrote:
On 17.02.23 20:00, Anton Kuchin wrote:
Migration of vhost-user-fs device requires transfer of FUSE internal state
from backend. There is no standard way to do it now so
On 22/02/2023 14:20, Vladimir Sementsov-Ogievskiy wrote:
On 17.02.23 20:00, Anton Kuchin wrote:
Migration of vhost-user-fs device requires transfer of FUSE internal
state
from backend. There is no standard way to do it now so by default
migration
must be blocked. But if this state can be
On Wed, Feb 22, 2023 at 03:20:00PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> On 17.02.23 20:00, Anton Kuchin wrote:
> > Migration of vhost-user-fs device requires transfer of FUSE internal state
> > from backend. There is no standard way to do it now so by default migration
> > must be blocked.
On 17.02.23 20:00, Anton Kuchin wrote:
Migration of vhost-user-fs device requires transfer of FUSE internal state
from backend. There is no standard way to do it now so by default migration
must be blocked. But if this state can be externally transferred by
orchestrator give it an option to
On Fri, Feb 17, 2023 at 07:00:38PM +0200, Anton Kuchin wrote:
> Migration of vhost-user-fs device requires transfer of FUSE internal state
> from backend. There is no standard way to do it now so by default migration
> must be blocked. But if this state can be externally transferred by
>
Migration of vhost-user-fs device requires transfer of FUSE internal state
from backend. There is no standard way to do it now so by default migration
must be blocked. But if this state can be externally transferred by
orchestrator give it an option to explicitly allow migration.
Signed-off-by:
50 matches
Mail list logo
