4:52 a.m.
I've compiled guestfsd and run it on CentOS 6.3. It worked well, but when I
quit guestfish, the guestfsd process in guest is always dead itself
automatically. Is this a bug? or did I miss something?
thanks.
4:57 a.m.
On 09/13/2012 05:52 PM, Richard Huang wrote:
I've compiled guestfsd and run it on CentOS 6.3. It worked well,
but when I quit guestfish, the guestfsd process in guest is always dead itself
automatically. Is this a bug? or did I miss something?
Yeah, the guestfsd should be dead when you finish your operations to the guest,
and will be started when you use guestfish next time. It's the design of guestfs,
not a bug.
Thanks,
Wanlong Gao
thanks.
_______________________________________________
Libguestfs mailing list
Libguestfs(a)redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs
5:01 a.m.
Since the guestfsd is already dead, that means there is no guestfsd process
in the guest, then guestfish cannot execute "run" with --live option any
more.
In Fedora 17, there is guestfsd.service which uses systemd restart function
to bring the guestfsd up I guess..
On Thu, Sep 13, 2012 at 5:57 PM, Wanlong Gao <gaowanlong(a)cn.fujitsu.com>wrote:
On 09/13/2012 05:52 PM, Richard Huang wrote:
> I've compiled guestfsd and run it on CentOS 6.3. It worked well, but
when I quit guestfish, the guestfsd process in guest is always dead itself
automatically. Is this a bug? or did I miss something?
>
Yeah, the guestfsd should be dead when you finish your operations to the
guest,
and will be started when you use guestfish next time. It's the design of
guestfs,
not a bug.
Thanks,
Wanlong Gao
> thanks.
>
>
> _______________________________________________
> Libguestfs mailing list
> Libguestfs(a)redhat.com
> https://www.redhat.com/mailman/listinfo/libguestfs
>
5:03 a.m.
The messages on guest's screen:
# ./guestfsd -vr
verbose daemon enabled
linux commmand line: BOOT_IMAGE=/boot/vmlinuz-3.5.3-1.fc17.i686.PAE
root=UUID=88c7691f-a407-45ad-a2b2-c00f0d7c24cc ro rd.md=0 rd.lvm=0 rd.dm=0
SYSFONT=True KEYTABLE=us rd.luks=0 LANG=en_US.UTF-8 rhgb quiet
guestfsd: main_loop: new request, len 0x28
fsync /dev/vda
fsync /dev/vdb
guestfsd: main_loop: proc 282 (internal_autosync) took 0.23 seconds
read: unexpected end of file on fd 3
You can see the last line.
thanks.
On Thu, Sep 13, 2012 at 6:01 PM, Richard Huang <huangyunsong(a)gmail.com>wrote:
Since the guestfsd is already dead, that means there is no guestfsd
process in the guest, then guestfish cannot execute "run" with --live
option any more.
In Fedora 17, there is guestfsd.service which uses systemd restart
function to bring the guestfsd up I guess..
On Thu, Sep 13, 2012 at 5:57 PM, Wanlong Gao <gaowanlong(a)cn.fujitsu.com>wrote:
> On 09/13/2012 05:52 PM, Richard Huang wrote:
> > I've compiled guestfsd and run it on CentOS 6.3. It worked well, but
> when I quit guestfish, the guestfsd process in guest is always dead itself
> automatically. Is this a bug? or did I miss something?
> >
>
> Yeah, the guestfsd should be dead when you finish your operations to the
> guest,
> and will be started when you use guestfish next time. It's the design of
> guestfs,
> not a bug.
>
> Thanks,
> Wanlong Gao
>
> > thanks.
> >
> >
> > _______________________________________________
> > Libguestfs mailing list
> > Libguestfs(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/libguestfs
> >
>
>
5:03 a.m.
On Thu, Sep 13, 2012 at 05:52:35PM +0800, Richard Huang wrote:
I've compiled guestfsd and run it on CentOS 6.3. It worked well,
but when I
quit guestfish, the guestfsd process in guest is always dead itself
automatically. Is this a bug? or did I miss something?
This is intentional, and also a bug.
libguestfs-live currently has a limit of one user at a time. We
normally run it from systemd which restarts guestfsd after each
user. See:
http://pkgs.fedoraproject.org/cgit/libguestfs.git/tree/guestfsd.service
The limit of one user at a time makes sense for regular libguestfs,
but not so much for libguestfs-live, where we could easily support
multiple parallel users.
However the reason we don't support that is because we have only one
virtio-serial channel with a fixed name
(/dev/virtio-ports/org.libguestfs.channel.0). virtio-serial channels
are not multiplexed, and they have to be created in advance [AFAIK --
is this still true?] so you would always have a very awkward situation
where max N users are supported concurrently (at the moment, N=1).
Assuming we stick with virtio-serial for the libguestfs-live case and
don't use something more normal like TCP/IP. So that's why this is
also a bug.
Fixing it isn't too hard TBH, but no one cares enough about this
use-case to have sent any patches so far.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
5:10 a.m.
On Thu, Sep 13, 2012 at 11:03:26AM +0100, Richard W.M. Jones wrote:
BTW on CentOS you'll need to write a tiny script that does the
equivalent of 'while true; do guestfsd [...]; done'
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
7:18 a.m.
On Thu, Sep 13, Richard W.M. Jones wrote:
Assuming we stick with virtio-serial for the libguestfs-live case
and
don't use something more normal like TCP/IP. So that's why this is
also a bug.
Using TCP/IP would simplify porting to Xen, because there is currently
no virtio-serial replacement for a PV guest.
Olaf
4452
days inactive
4452
days old
6 comments
4 participants
participants (4)
-
Olaf Hering -
Richard Huang -
Richard W.M. Jones -
Wanlong Gao