[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] More structured migration URIs?
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [Qemu-devel] More structured migration URIs? |
Date: |
Mon, 5 Jan 2015 12:37:23 +0000 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
* Daniel P. Berrange (address@hidden) wrote:
> On Mon, Jan 05, 2015 at 12:14:25PM +0000, Dr. David Alan Gilbert wrote:
> > Hi,
> > I keep thinking of things where it might make sense to add
> > options onto the migration URIs and wondered if it makes
> > sense to restructure the migration URIs; my proposal would be:
> >
> > a) Restructure tcp:hhhh:pppp into protocol=tcp,host=hhhh,port=pppp
> > b) Have a requirement that protocol= is the first entry in the list
> > c) If it doesn't start protocol= then it's the old format.
> > d) This would also change in the 'migrate' command to keep it symmetric
> >
> > Eric/Daniel does this make sense for libvirt?
> >
> > My current set of things I might want to add are:
> > 1) A flag saying if a return channel is needed
> > For sockets qemu can open this afterwards when needed, but Dave
> > Gibson's
> > review of my postcopy world pointed out that it might not be that
> > easy for all protocols to open the reverse later.
> > 2) Flags for opening multiple sockets/FDs - e.g. to pass the pages down
> > a separate fd.
> >
> > Thoughts?
>
> The QEMU migration URI is exposed via the libvirt API to applications, so
> they can control the host/port of the target explicitly (to override
> libvirt's default guess of a suitable host/port).
Ah OK, that's a shame.
> These extra things that you suggest adding are not things we neccessarily
> want to expose to applications. So if QEMU changed the format, libvirt
> would probably not accept this new format from applications - we would
> force applications to always use the URI syntax and only allow host+port
> to be specified. Internally libvirt would translate that to the new
> key/value pair format, and add the extra flags / options as needed. We
> would possibly add some options to our public API to configure extra
> features as desired, separately from the URI.
It all gets a bit more complicated when an application could specify
an arbitrary exec: uri through that API, rather than you knowing what it's
doing.
> More generally though, what is the advantage of encoding new things in
> the migration URI, as opposed to adding new parameters to the QMP
> migration command. The use of URIs in this scenario is really a hang
> over from days of HMP. If we were designing the migration command today
> I don't think we'd use URIs at all - we'd just have a QMP command with
> explicit parameters for the hostname, the port number and anything else
> we might want to set. So if there are new features I'd be inclined to
> just add more optional parameters to the QMP migration command and not
> touch the URI format at all.
I was only interested in adding options to the -incoming side rather than the
'migrate' side, but thought if I was changing the URI syntax I may as well
make it consistent. If you wanted to add options to the -incoming side
what would be easiest for you?
Dave
>
> Regards,
> Daniel
> --
> |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org -o- http://virt-manager.org :|
> |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK