Re: [Qemu-devel] [PATCH v6 11/19] migration: Start of multiple fd work

[Daniel P. Berrange]

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 :|