Gilad Ben-Yossef wrote:
Anthony Liguori wrote:
The machine running qemu has a web based interface to start VMs.
A user asks for a new VM to start by browsing to a URL. The CGI
implmenting that URL will start a new qemu instance, send to the user
web browser an HTML page with a JAVA VNC viewer embedded and terminate.
Passing an fd is still the wrong solution due to the problems with
save/restore/migrate.
There is no problem with save/restore or migration.
For save/restore, the fd is not saved in the saved state. You need to
specify a (new?) fd when you restore, if that is what you want to do,
that is.
It just like I can run a VM with SDL, save the state and restore it
with VNC - the question if the restored session should use the same fd
(for whatever definition of "the same" you want) or not is left for
the user. We should be providing mechanism, not policy.
The same applies for migration - when you migrate your VM, its your
call and responsibility to do the right thing. Just spawn a wrapper on
the target machine that opens a new fd and exec into qemu and use
*that* as your migrate command line argument instead of plain qemu, as
an obvious example.
As someone wrote in their blog (this is why I write my blog in a
language that's been dead for aprox. 2000 years... :-):
"Instead of just saying 'migrate hostname' you now have to construct a
rather long command like 'migrate "ssh hostname qemu -loadvm -"'. A
nice side effect though is that you can completely change the command
line arguments in case you have NFS mounts at different locations."
I couldn't agree more. :-)
Except that the syntax has changed since then. It is now 'migrate
ssh://hostname' in which case, the command line qemu was launched with
is used to relaunch on the new machine. This is where passing an fd
fails. The syntax I proposed addresses this issue.
It may be interesting to have something like -vnc
tcp://0.0.0.0:5900-6000 to let QEMU try to find an unused port in the
given range. Combined with -daemonize and having the monitor on a
Unix socket, you could:
1) create a vm with qemu -vnc tcp://0.0.0.0:5900-6000 -monitor
unix:/path/to/socket -daemonize
2) *wait* for qemu to finish running and daemonize properly
3) connect to /path/to/socket and issue a 'info vnc' command to
discover which port it's actually using
4) render that port with your HTML.
What you're saying is the same as claiming that "ls" needs to
implement sorting, compression (in both gz and bzip algorithms),
regexp searching and transferring it's output over an SSL connection
to another machine.
We don't do that. We have pipes . VNC socket fd passing is just the
old pipe concept (adapted to the situation) - nothing more.
Or in other words: you can easily implement the VNC over unix domain
socket feature (if it was not in qemu already) using the fd passing
method, but you can't do it the other way around (without an extra
long running process, that is)
There is such a thing as too many options. Adding new options requires
weighing the utility that that option brings verses the added
complexity. In this case, the option would not be useful to the vast
majority of users, only those writing front-ends. I proposed an option
that would still be useful to those writing front-ends but would also be
useful to general users.
Regards,
Anthony Liguori
The nice thing about this is that it not only continues to work with
save/restore/migrate, it's smart enough to allocate a new port to
ensure that you always tend to succeed. Choosing :3 might be okay on
machine A, but there's no guarantee that it's okay on machine B so
you have to allow QEMU to try and find a new port after restore/migrate.
You're assuming we know what the correct behavior is. We really don't
know. Maybe we want to use the same fd number on the new machine,
maybe we don't. The user somehow provided a good fd on the original
machine, trust him to provide a good one on the new one (via a qemu
wrapper for migrate as explained above, for example).
Again it's that mechanism vs. policy thing again.,
Gilad
PS. This is not some ego trip about whether you'll take the patch or
not, so just tell me if this back and forth gets annoying and I'll
shut up :-)