This seems to be great ! I think it is similar to OpenVZ concept of controlling VMs from Host, right ? How it works, if it is not installed in guest ? Using PV, in connects into guests virtio-tty device ? In may become more universal, if more command are added, such as: (like OpenVZ does) vm 101 enter (this will enter into guest VM TTY, right from host terminal). -or- vm 101 exec [guest-command] (this will execute command on guest, using bash, right from host terminal). For more commands from OpenVZ, that can be applied to Qemu/KVM, see: (7.8.2008) http://www.howtoforge.com/installing-and-using-openvz-on-fedora9-p2 -Alexey

On Thu, Aug 07, 2008 at 07:40:58PM +0900, Jun Koi wrote: Yes they peek at the live guest kernel memory image to extract the data. That's not a problem - that's a reason to use libvirt :-) It allows the same tools to work whether using Xen, QEMU, KVM or any other full machine virtualization suported by libvirt, rather than being tied to one particular hypervisor. Not to mention ability to run them remotely, with authentication and encryption, etc 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 :|

On Thu, Aug 07, 2008 at 03:55:49PM +0300, Alexey Eremenko wrote: It has a huge chain of dependencies actually. Maybe better off starting with our RPMs, either source or binary, from here: https://bugzilla.redhat.com/show_bug.cgi?id=450713 Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top

On Thu, Aug 07, 2008 at 11:47:39AM +0100, Daniel P. Berrange wrote: We also support running the tools from memory images which you can capture using the QEMU "memsave" command (see the '-t' option). No libvirt required for that, _but_ to see any interesting stuff you'd need to capture the entire guest memory which could obviously be quite large. You could do 'virt-mem capture' which captures just the bits of memory that contain interesting data, and that reduces the amount of data you need to capture substantially. Unfortunately I broke 'virt-mem capture' in the latest release by accident, and in any case it requires libvirt to do the capturing. I think the message here is, install libvirt & be happy :-) Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top

Javier Guerra wrote: Regrettably I agree for the moment. I ended up writing a Perl management script for my KVM VMs because libvirt was just too muddled and limited for my needs, and because the config file format confused me, didn't handle everything I needed, and I didn't find clear documentation on it. Also, I wanted to import existing guests from another VM, and libvirt's tools seemed strongly geared around creating new VMs to use with libvirt. So I had to write config files for it - see above. I like the idea of libvirt a lot and wish it well. My own Perl script was a nightmare to write even though it's not so long (synchronisation & monitor issues especially), so I respect what's done. It's a good goal. But I just found it too confusing to use in the ways I needed to use KVM, that I gave up on libvirt for now rather than spend the considerable time to get to grips with what it's doing, and it's config format. What would be nicer is a VM management protocol build in to QEMU, KVM and XEN, which is a bit like the monitor, but supports multiple client connections and overlapping operations (where reasonable), and is a bit more structured, so e.g. you can get the state of anything whose state you can set, you can wait for events, etc. The somewhat object-based config file work that's been discussed not long ago would be a good thing to structure it around. -- Jamie

On Sun, Aug 10, 2008 at 11:07:32AM +0100, Richard W.M. Jones wrote: Judging by one private reply I got, I don't want this to be misinterpreted. Libvirt DOESN'T expose the minimum subset of all hypervisors (because that would be very small and useless). It exposes general virtualization features, even if those features only apply to one or two hypervisors. For example: migration - only works with Xen & KVM, but could be applicable to other hypervisors in the future when we support them and they support migration scheduler tuning - only for Xen, but generally applicable adding/dropping interfaces from live guests - a general feature supported by many but not all of the backends Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 60 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora