On Sun, Jan 11, 2009 at 02:09:26PM +0100, Guido G?nther wrote:
> On Mon, Dec 15, 2008 at 11:27:27AM +0000, Daniel P. Berrange wrote:
> [..snip..]
> > > + vm->stdin_fd = qemudGetProcFD(vm->pid, 0);
> > > + vm->stdout_fd = qemudGetProcFD(vm->pid, 1);
> > > + vm->stderr_fd = qemudGetProcFD(vm->pid, 2);
> >
> > NACK, to these 3 lines - since we go to trouble of creating the statefile,
> > we should store the FD numbers in the statefile too, instead of relying
> > in the linux specific /proc code.
> This is (as far as I know) the last blocker for merging the forking of
> qemus/kvms and reattaching them after libvirtd restart (so the vms
> survive a libvirtd crash/restart)[1]. While I can safe the path to
> std{in,out,err} in the domain status file easily this would still be
> /proc/<pid>/fd/{1,2,3} which is not portable.
>
> After reading the monitor path on vm startup we only need the above fds
> to decect vm shutdown in qemudDispatchVMEvent(). This could be replaced
> by simply dup'ing the fds and using inotify on the pid file in
> /var/run/libvirt/qemu/ to detect vm shutdown instead - but this isn't
> portable outside of Linux either.
>
> Any other options I'm overlooking? Note that the current code doesn't
> break any non Linux port, it's just that the VMs won't get reattached
> after daemon restart.
There's different needs for each file descriptor
- stdin_fd - this is only ever used for incoming migration data
all other times it is hooked up to /dev/null. So we don't need
to keep this FD around at all
- stdout_fd - AFAIK, the only time we get any data on stdout is
when we run qemu -help to check support args. Current code will
read & log all data on stdout, but I believe this is effectively
nothing and so we could just hook it to /dev/null & ignore it
- stderr_fd - libvirtd reads this FD & logs the data to the domain
logfile in /var/log/libvirt/qemu/$NAME.log. Instead of having
the daemon process this logging, we can just dup() the file straight
onto the logfile FD, so data will be logged even when libvirtd is
not running. The only minor complication is that we need to parse
the logfile to get the monitor TTY path.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list