On Mon, Sep 29, 2014 at 1:14 AM, Richard W.M. Jones <rjones(a)redhat.com> wrote:
On Mon, Sep 29, 2014 at 12:55:04AM +0800, Zhi Yong Wu wrote:
> On Mon, Sep 29, 2014 at 12:36 AM, Richard W.M. Jones <rjones(a)redhat.com>
wrote:
> > On Sun, Sep 28, 2014 at 11:43:17PM +0800, Zhi Yong Wu wrote:
> >> Yeah, but why did it happen when i directly issue guest VM via above
command?
> >
> > OK I see. When libguestfs runs qemu-kvm, it sets up a TCP socket
> > first [on RHEL 5 -- it works differently upstream]. Without the
> > socket existing (and sending commands etc), the qemu-kvm command on
> > its own won't work.
> I got it, thanks.
>
> By the way, i found that virt-xxx usually has very poor performance on
> my box. e.g. virt-filesystems will return the result in 30s,
> virt-resize will need 30 minutes to complete resizing one disk. Every
> virt-xxx need to start one QEMU guest at first every time it is
> issued, so this takes too long time to run. I am trying to find out
> some ways to improve its perf.
A good place to start is:
http://libguestfs.org/guestfs-performance.1.html
Are you running this inside a VM?
Yes, I am trying to run it in Xen Domain0. I
thought that we can use
Domain0 as a public libguestfs VM, This will avoid starting a new
guest for virt-xxx every time, But Domain0 has no corresponding qemu
task. So this way isn't available.
Now, i am considering if we can run private VM for libguestfs which
will keep running forever and if it will bring more trouble.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
--
Regards,
Zhi Yong Wu