[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v6 11/19] migration: Start of multiple fd work
From: |
Daniel P. Berrange |
Subject: |
Re: [Qemu-devel] [PATCH v6 11/19] migration: Start of multiple fd work |
Date: |
Mon, 14 Aug 2017 14:50:10 +0100 |
User-agent: |
Mutt/1.8.3 (2017-05-23) |
On Mon, Aug 14, 2017 at 03:43:58PM +0200, Juan Quintela wrote:
> "Daniel P. Berrange" <address@hidden> wrote:
> > On Tue, Aug 08, 2017 at 06:26:21PM +0200, Juan Quintela wrote:
> >> We create new channels for each new thread created. We send through
> >> them a string containing <uuid> multifd <channel number> so we are
> >> sure that we connect the right channels in both sides.
> >>
> >> Signed-off-by: Juan Quintela <address@hidden>
> >>
>
> >> +/* Default uuid for multifd when qemu is not started with uuid */
> >> +static char multifd_uuid[] = "5c49fd7e-af88-4a07-b6e8-091fd696ad40";
> >
> > Why is this better than just using the qemu_uuid unconditionally.
> > UUIC, it'll just be 00000000-0000-0000-0000-000000000000.
> >
> > Either way you've got a non-unique UUID if multiple QEMUs are
> > started, so I dont see a benefit in inventing a new uuid here.
>
> I hate a message full of zeros, it is the default value. If you have
> more than one qemu and you don't set uuid, you are asking for trouble.
>
> But if people preffer the 00000 uuid, it is also ok with me.
I don't see a fixed UUID of all-zeros being any different from
a fixed UUID hardcoded in the source code here. Both are simply
conceptually broken in the same way if you care about distinguishing
VMs.
> > I also think it is not nice to be formatting a string with printf
> > here, sending it and then using scanf to extract the data. If we
> > need to send structured data, then we should define a proper binary
> > format for it eg
> >
> > struct MigrateUUIDMsg {
> > uint32_t chnanelid;
> > QemuUUID uuid;
> > } __attribute__((__packed__));
> >
> > and then just send the raw struct across.
>
> Not that I believe that it still works (or that it worked ever), but
> qemu migration "on stream" was supposed to be Endian safe .....
The uuid field is just a byte array, so not endian sensitive. For
the channelid, just do a hton / ntoh call before/after writing/reading
the struct.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
- Re: [Qemu-devel] [PATCH v6 07/19] migration: Create x-multifd-threads parameter, (continued)
[Qemu-devel] [PATCH v6 12/19] migration: Create ram_multifd_page, Juan Quintela, 2017/08/08
[Qemu-devel] [PATCH v6 14/19] migration: Send the fd number which we are going to use for this page, Juan Quintela, 2017/08/08
[Qemu-devel] [PATCH v6 13/19] migration: Really use multiple pages at a time, Juan Quintela, 2017/08/08
[Qemu-devel] [PATCH v6 15/19] migration: Create thread infrastructure for multifd recv side, Juan Quintela, 2017/08/08
[Qemu-devel] [PATCH v6 16/19] migration: Test new fd infrastructure, Juan Quintela, 2017/08/08