Re: [Qemu-devel] Does kvm friendly support GPT?
On Mon, Dec 22, 2014 at 02:39:27PM +0800, Zhang Haoyu wrote: Hi, When I perform P2V from native servers with win2008 to kvm vm, some cases failed due to the physical disk was using GPT for partition, and QEMU doesn't support GPT by default. And, I see in below site that OVMF can be used to enable UEFI to support GPT, http://www.linux-kvm.org/page/OVMF But, it seems that OVMF is not stable enough for kvm. I guess you mean EFI rather than just GPT? FWIW virt-p2v has some support for EFI, but it's very hairy and not that well tested. It tries to modify the guest to use BIOS for booting. I'm waiting for good, free EFI support in qemu and then I can remove such hacks. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] implement lvm-aware P2V to reduce time cost significantly for linux server
On Fri, Jan 02, 2015 at 10:19:29AM +, Stefan Hajnoczi wrote: On Sat, Dec 27, 2014 at 09:28:53AM +0800, Haoyu Zhang wrote: I want to P2V a redhat server to kvm vm, and lvm was used to manage disks in the redhat server. I want to only migrate the really used storage to vm image, which can reduce the time cost significantly sometimes, so I need the information of logical volume to physical disks bitmap, to know which physical sectors were really used, any ideas? Is there a tool off-the-shelf have implemented the target? Have you looked at virt-p2v(1)? http://libguestfs.org/virt-p2v.1.html I'm not sure if it sparsifies the disk image during conversion or whether you would have to run virt-sparsify(1) afterwards (http://libguestfs.org/virt-sparsify.1.html). virt-sparsify(1) can definitely unmap LVM's unused space. It sparsifies automatically during conversion. No need to run virt-sparsify afterwards :-) 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/ -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] implement lvm-aware P2V to reduce time cost significantly for linux server
On Sat, Jan 03, 2015 at 12:47:10AM +, Richard W.M. Jones wrote: On Fri, Jan 02, 2015 at 10:19:29AM +, Stefan Hajnoczi wrote: On Sat, Dec 27, 2014 at 09:28:53AM +0800, Haoyu Zhang wrote: I want to P2V a redhat server to kvm vm, and lvm was used to manage disks in the redhat server. I want to only migrate the really used storage to vm image, which can reduce the time cost significantly sometimes, so I need the information of logical volume to physical disks bitmap, to know which physical sectors were really used, any ideas? Is there a tool off-the-shelf have implemented the target? Have you looked at virt-p2v(1)? http://libguestfs.org/virt-p2v.1.html I'm not sure if it sparsifies the disk image during conversion or whether you would have to run virt-sparsify(1) afterwards (http://libguestfs.org/virt-sparsify.1.html). virt-sparsify(1) can definitely unmap LVM's unused space. It sparsifies automatically during conversion. No need to run virt-sparsify afterwards :-) I should note this statement only applies to the new version of virt-p2v/virt-v2v, = 1.28. The old version, 0.9.x, did not do this. The old version is not supported or maintained. 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/ -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] How does qemu know the virtual memory of the guest os?
On Fri, Nov 28, 2014 at 04:17:10PM -0800, Jidong Xiao wrote: Hi, I notice that Qemu supports dump virtual memory of Guest OS. As this page suggests: http://doc.opensuse.org/products/draft/SLES/SLES-kvm_sd_draft/cha.qemu.monitor.html To save the content of the virtual machine memory to a disk or console output, use the following commands: memsave addr size filename Saves virtual memory dump starting at addr of size size to file filename pmemsave addr size filename Saves physical memory dump starting at addr of size size to file filename = I understand that hypervisors certainly know the physical memory of virtual machine, but how does it know the virtual memory of the Guest OS? I think the hypervisor has no semantic knowledge of the Guest OS, and such knowledge should be different for different OS (e.g., Windows vs Linux), so I am really surprised that Qemu can dump the virtual memory of the Guest OS. Can someone kindly give me some explanation? Thank you very much!! It's different for each *architecture*, but not for each OS. For example on x86 it starts by reading the CR* control registers, and then the page tables (see target-i386/helper.c: x86_cpu_get_phys_page_debug). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hang after seabios
On Wed, Jul 30, 2014 at 03:58:43PM -0700, Zetan Drableg wrote: [00183ms] /usr/libexec/qemu-kvm \ -global virtio-blk-pci.scsi=off \ -nodefconfig \ -nodefaults \ -nographic \ -machine accel=kvm:tcg \ -cpu host,+kvmclock \ -m 500 \ -no-reboot \ -kernel /var/tmp/.guestfs-0/kernel.47903 \ -initrd /var/tmp/.guestfs-0/initrd.47903 \ -device virtio-scsi-pci,id=scsi \ -drive file=/tmp/libguestfs-test-tool-sda-Iakpwe,cache=none,format =raw,id=hd0,if=none \ -device scsi-hd,drive=hd0 \ -drive file=/var/tmp/.guestfs-0/root.47903,snapshot=on,id=appliance, if=none,cache=unsafe \ -device scsi-hd,drive=appliance \ -device virtio-serial \ -serial stdio \ -device sga \ -chardev socket,path=/tmp/libguestfspx9994/guestfsd.sock,id=channel0 \ -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \ -append 'panic=1 console=ttyS0 udevtimeout=600 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm edd=off' \x1b[1;256r\x1b[256;256H\x1b[6n Google, Inc. Serial Graphics Adapter 10/14/11 SGABIOS $Id: sgabios.S 8 2010-04-22 00:03:40Z nlaredo $ (mockbuild@ ca-build44.us.oracle.com) Fri Oct 14 20:04:36 UTC 2011 Term: 80x24 4 0 SeaBIOS (version seabios-0.6.1.2-28.el6) \x1b[2J At this point it hangs forever. These hangs can be tricky to diagnose. There are a couple of things you can do however: (1) strace qemu to find out what it is doing, or: (2) [harder, but much more informative] gdb into the guest to find out where the guest hangs, or: (3) Take the command line above, and cut it down to try to isolate the problematic options. I would concentrate on the following options as being most likely to cause trouble: -cpu -machine -kernel -device sga (remove it) For (1) and (2) you can use a qemu wrapper to modify the qemu command that the test tool runs. See also: http://libguestfs.org/guestfs.3.html#qemu-wrappers http://rwmj.wordpress.com/2011/10/12/tip-debugging-the-early-boot-process-with-qemu-and-gdb/#content Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hang after seabios
On Thu, Jul 31, 2014 at 12:12:26PM -0700, Zetan Drableg wrote:
Hi Richard thanks for the info.
I took the strace approach and ran into this looping over and over again.
Is it failing to get time?
timer_gettime(0x8, {it_interval={0, 0}, it_value={0, 0}}) = 0
timer_settime(0x8, 0, {it_interval={0, 0}, it_value={0, 25}}, NULL) = 0
timer_gettime(0x8, {it_interval={0, 0}, it_value={0, 204443}}) = 0
select(16, [0 6 9 13 15], [], [], {1, 0}) = 2 (in [6 13], left {0, 98})
read(13, \1\0\0\0\0\0\0\0, 4096) = 8
read(13, 0x7fffa2ed3f70, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
read(6, \0, 512) = 1
read(6, 0x7fffa2ed4d70, 512)= -1 EAGAIN (Resource
temporarily unavailable)
select(16, [0 6 9 13 15], [], [], {1, 0}) = 1 (in [15], left {0, 98})
read(15,
\16\0\0\0\0\0\0\0\376\377\377\377\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0...,
128) = 128
rt_sigaction(SIGALRM, NULL, {0x7f6d8b8d17d0, ~[KILL STOP RTMIN RT_1],
SA_RESTORER, 0x7f6d8b211710}, 8) = 0
write(7, \0, 1) = 1
write(14, \1\0\0\0\0\0\0\0, 8)= 8
read(15, 0x7fffa2ed4ee0, 128) = -1 EAGAIN (Resource
temporarily unavailable)
timer_gettime(0x8, {it_interval={0, 0}, it_value={0, 0}}) = 0
timer_settime(0x8, 0, {it_interval={0, 0}, it_value={0, 988758000}}, NULL) = 0
select(16, [0 6 9 13 15], [], [], {1, 0}) = 2 (in [6 13], left {0, 98})
read(13, \1\0\0\0\0\0\0\0, 4096) = 8
read(13, 0x7fffa2ed3f70, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
read(6, \0, 512) = 1
read(6, 0x7fffa2ed4d70, 512)= -1 EAGAIN (Resource
temporarily unavailable)
It looks a lot like the bug you filed here.
https://bugzilla.redhat.com/show_bug.cgi?id=553689
I'm fairly sure this is just qemu running as normal. It's not a
duplicate of that ancient bug, because you can see from the messages
that SeaBIOS is running.
You need to `gdb' into the guest to see where the emulation got to.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [fedora-virt] 3.13 - Nested KVM (vmx) totally broken?
On Fri, Mar 14, 2014 at 03:52:03PM +0400, Vasiliy Tolstov wrote: If i use 3.13.6 kernel that have alredy this patch, but sometimes i get kernel panic, what can i do? P.S. I'm using nested virt, fault from L2 It could be there is another, less frequent, bug in nested KVM. I'm assuming this is on Intel hardware? From the libguestfs point of view what you can do is to force TCG: export LIBGUESTFS_BACKEND_SETTINGS=force_tcg Unfortunately this only has an effect in libguestfs = 1.25.24. We're going to have the new version in Fedora 20 real soon -- probably before the end of this month. Or you can compile the Rawhide version on F20. 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://people.redhat.com/~rjones/virt-df/ -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [fedora-virt] 3.13 - Nested KVM (vmx) totally broken?
On Fri, Mar 14, 2014 at 04:11:13PM +0400, Vasiliy Tolstov wrote: 2014-03-14 15:58 GMT+04:00 Richard W.M. Jones rjo...@redhat.com: It could be there is another, less frequent, bug in nested KVM. I'm assuming this is on Intel hardware? From the libguestfs point of view what you can do is to force TCG: export LIBGUESTFS_BACKEND_SETTINGS=force_tcg Unfortunately this only has an effect in libguestfs = 1.25.24. We're going to have the new version in Fedora 20 real soon -- probably before the end of this month. Or you can compile the Rawhide version on F20. Thanks for answer. I'm not using libguestfs. I'm try tun vm inside vm via libvirt. You can set the VM domain type=qemu. Of course it'll run quite slowly. is that possible to debug this issue ? How can i help? Complete logs from the guest. Any messages from qemu or the host. put all of that into a full bug report. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [fedora-virt] 3.13 - Nested KVM (vmx) totally broken?
On Fri, Mar 14, 2014 at 04:39:48PM +0400, Vasiliy Tolstov wrote: 2014-03-14 16:16 GMT+04:00 Richard W.M. Jones rjo...@redhat.com: You can set the VM domain type=qemu. Of course it'll run quite slowly. is that possible to debug this issue ? How can i help? Complete logs from the guest. Any messages from qemu or the host. put all of that into a full bug report. Where i can find submission form for bug report? (I'm using exherbo linux, but it does not have like debian or sles personal patches and using only upstream) I suspect this is going to be a kernel bug, in which case: https://bugzilla.kernel.org/ For libvirt bugs it would be: https://bugzilla.redhat.com/enter_bug.cgi?component=libvirtproduct=Virtualization+Tools Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [fedora-virt] 3.13 - Nested KVM (vmx) totally broken?
On Tue, Mar 04, 2014 at 09:13:40AM +0100, Paolo Bonzini wrote: Il 04/03/2014 03:40, Ian Pilcher ha scritto: Is this a known problem? I just tried using nested vmx for the first time since upgrading my system from F19 (3.12.?? at the time) to F20, and I cannot start any L2 guests. The L2 guest appears to hang almost immediately after starting, consuming 100% of one of the L1 guest's VCPUs. If I reboot with kernel-3.12.10-300.fc20.x86_64, the problem does not occur. Any known workaround? (Other than using 3.12.10?) There is a fix on the way to the 3.13 kernel. You can open a Fedora bug and ask them to include http://article.gmane.org/gmane.linux.kernel.stable/82043/raw in the kernel. Thanks for fixing this. It affects a lot of libguestfs users too. I opened this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1073663 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [virt-tools-list] cache write back barriers
On Fri, Jun 14, 2013 at 12:53:04PM +0200, Stefan Hajnoczi wrote: On Thu, Jun 13, 2013 at 10:47:32AM +0200, folkert wrote: Hi, In virt-manager I saw that there's the option for cache writeback for storage devices. I'm wondering: does this also make kvm to ignore write barriers invoked by the virtual machine? Looking at current git, the cache types supported by virt-manager are: - none - writethrough - writeback - default [virt-manager only, not in virt-install] These translate directly into the libvirt driver ... cache=... field which you can find documented here: http://libvirt.org/formatdomain.html#elementsDisks As far as I can tell (from looking at libvirt sources) as long as you have a modern qemu these will translate to the same names on the qemu command line. No, that would be unsafe. When the guest issues a flush then QEMU will ensure that data reaches the disk with -drive cache=writeback. Aha so the writeback behaves like the consume harddisks with write-cache on them. In answer to the original question by 'folkert': In that case maybe an extra note could be added to the virt-manager (excellent software by the way!) that if the client vm supports barriers, that write-back in that case then is safe. Agree? I suspect the problem with doing this is it depends on the hypervisor. Likely for qemu and Xen (since it uses a qemu device model) this would be true. Possibly not for other hypervisors that virt-manager can control. Generally speaking, it would be nice to document these properly and also how they are implemented in different hypervisors, because I know I for one don't find these settings very obvious. So, patches welcome! Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH uq/master] fix double free the memslot in kvm_set_phys_mem
On Fri, May 31, 2013 at 04:52:18PM +0800, Xiao Guangrong wrote:
Luiz Capitulino reported that guest refused to boot and qemu
complained with:
kvm_set_phys_mem: error unregistering overlapping slot: Invalid argument
It is caused by commit 235e8982ad that did double free for the memslot
so that the second one raises the -EINVAL error
Fix it by reset memory size only if it is needed
Reported-by: Luiz Capitulino lcapitul...@redhat.com
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
kvm-all.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 8e7bbf8..405480e 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -206,7 +206,8 @@ static int kvm_set_user_memory_region(KVMState *s,
KVMSlot *slot)
if (s-migration_log) {
mem.flags |= KVM_MEM_LOG_DIRTY_PAGES;
}
-if (mem.flags KVM_MEM_READONLY) {
+
+if (slot-memory_size mem.flags KVM_MEM_READONLY) {
/* Set the slot size to 0 before setting the slot to the desired
* value. This is needed based on KVM commit 75d61fbc. */
mem.memory_size = 0;
Tested and fixes it for me too.
Tested-by: Richard W.M. Jones rjo...@redhat.com
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for September 25th
On Mon, Sep 24, 2012 at 01:48:26PM +0200, Paolo Bonzini wrote: Il 24/09/2012 13:28, Juan Quintela ha scritto: Hi Please send in any agenda items you are interested in covering. URI parsing library for glusterfs: libxml2 vs. in-tree fork of the same code. I can't make this call, but I'm not fussed about the decision here, go with whatever Paolo thinks. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for September 25th
On Tue, Sep 25, 2012 at 07:57:53AM -0500, Anthony Liguori wrote: Paolo Bonzini pbonz...@redhat.com writes: Il 24/09/2012 13:28, Juan Quintela ha scritto: Hi Please send in any agenda items you are interested in covering. URI parsing library for glusterfs: libxml2 vs. in-tree fork of the same code. The call is a bit late for Bharata but I think copying is the way to go. Something I've been thinking about since this discussion started though. Maybe we could standardize on using URIs as short-hand syntax for backends. For example: qemu -hda file:///foo.img Or: qemu -device virtio-net-pci,netdev=tap:///vnet0?script=/etc/qemu-ifup This is roughly what the original URI code from libvirt is used for: http://libvirt.org/remote.html#Remote_URI_reference It works well because URIs are standardized, well understood, support escaping, and are widely supported by client libraries/languages. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 0/4] improve speed of rep ins emulation
On Mon, Jul 30, 2012 at 05:38:17PM +0300, Gleb Natapov wrote: And now for something completely different. So this series (or rather the last patch of it) takes different approach to rep ins optimization. Instead of writing separate fast path for it do the fast path inside emulator itself. This way nobody can say the code is not reused! Patch 1,2 are now, strictly speaking, not needed, but I think this is still nice cleanup and, in case of patch 1, eliminates some ifs at each KVM_RUN ioctl. Gleb Natapov (4): Provide userspace IO exit completion callback. KVM: emulator: make x86 emulation modes enum instead of defines KVM: emulator: string_addr_inc() cleanup KVM: emulator: optimize rep ins handling. arch/x86/include/asm/kvm_emulate.h | 26 +- arch/x86/include/asm/kvm_host.h|1 + arch/x86/kvm/emulate.c | 48 ++- arch/x86/kvm/x86.c | 92 +--- 4 files changed, 104 insertions(+), 63 deletions(-) I tested this patch series and it really helped to improve the performance of loading the libguestfs -kernel and -initrd: https://bugzilla.redhat.com/show_bug.cgi?id=847546 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] 9p broken?
On Mon, Jul 30, 2012 at 03:35:39PM +0300, Avi Kivity wrote:
Having an annoying bug on i386 kvm I decided to debug it buy running an
i386 guest on my x86_64 host, use 9p to access a guest image, and run it
using nested kvm.
However, 9p appears to be broken: first, the configure test fails (patch
sent). Second, while mount works, ls on the mount point causes qemu to
crash with
(gdb) bt
#0 error_set (errp=0x7fffe95fb128, fmt=0x558d4568 { 'class':
'VirtFSFeatureBlocksMigration', 'data': { 'path': %s, 'tag': %s } }) at
/home/tlv/akivity/qemu/error.c:32
#1 0x5567cb06 in v9fs_attach (opaque=0x7fffe95e3020) at
/home/tlv/akivity/qemu/hw/9pfs/virtio-9p.c:988
#2 0x5561d19f in coroutine_trampoline (i0=1449767888, i1=21845)
at /home/tlv/akivity/qemu/coroutine-ucontext.c:138
#3 0x75a93ef0 in ?? () from /lib64/libc.so.6
#4 0x7fffce00 in ?? ()
#5 0x in ?? (
**errp already points to a VirtFSFeatureBlocksMigration error;
v9fs_attach() has been called a second time (the first time,
understandably, on mount; the second on ls).
Yes, I can reproduce this too.
LIBGUESTFS_QEMU=~/d/qemu/qemu.wrapper \
guestfish -v -- \
sparse /tmp/unused 100M : \
config -device 'virtio-9p-pci,fsdev=root,mount_tag=root' : \
config -fsdev 'local,id=root,path=/tmp,security_model=passthrough' : \
run : \
mount-9p root / : \
ls /
Stack trace:
#0 0x7fb1d4d19ba5 in __GI_raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:63
#1 0x7fb1d4d1b358 in __GI_abort () at abort.c:90
#2 0x7fb1d4d12972 in __assert_fail_base (fmt=
0x7fb1d4e5c8e8 %s%s%s:%u: %s%sAssertion `%s' failed.\n%n,
assertion=assertion@entry=0x7fb1d8e2e87e *errp == ((void *)0),
file=file@entry=0x7fb1d8e56217 error.c, line=line@entry=35,
function=function@entry=
0x7fb1d8e2e8ca __PRETTY_FUNCTION__.13983 error_set) at assert.c:92
#3 0x7fb1d4d12a22 in __GI___assert_fail (assertion=assertion@entry=
0x7fb1d8e2e87e *errp == ((void *)0), file=file@entry=
0x7fb1d8e56217 error.c, line=line@entry=35, function=function@entry=
0x7fb1d8e2e8ca __PRETTY_FUNCTION__.13983 error_set) at assert.c:101
#4 0x7fb1d8c1147f in error_set (errp=errp@entry=0x7fb1ce36a128,
fmt=fmt@entry=
0x7fb1d8e39a78 { 'class': 'VirtFSFeatureBlocksMigration', 'data': {
'path': %s, 'tag': %s } }) at error.c:35
#5 0x7fb1d8c57f9b in v9fs_attach (opaque=0x7fb1ce352020)
at /home/rjones/d/qemu/hw/9pfs/virtio-9p.c:988
#6 0x7fb1d8c0fcfa in coroutine_trampoline (i0=optimized out,
i1=optimized out) at coroutine-ucontext.c:138
#7 0x7fb1d4d2a2f0 in ?? () from /lib64/libc.so.6
#8 0x7fff51061aa0 in ?? ()
#9 0xb5b5b5b5b5b5b5b5 in ?? ()
#10 0x in ?? ()
I'll add a regression test for 9p to libguestfs so at least we will
catch this in future during Fedora builds.
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/
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Memory Tracking API
On Thu, May 17, 2012 at 11:36:24PM +0530, Jaspal wrote: Hi , Is it possible to keep a count of reads / writes taking place in a vm using qemu ( using kvm as hypervisor ) ? Is there a api ( or any patch ) for it ? Memory reads and writes is surely going to generate a huge amount of output! There are various DEBUG_* symbols at the top of exec.c and ioport.c. I've only used a few of these: DEBUG_UNASSIGNED - prints a message when an unmapped page is referenced (TCG only, presumably?) DEBUG_IOPORT - prints a message when any I/O port is referenced DEBUG_UNUSED_IOPORT - prints a message when a non-emulated I/O port is referenced There are several more if you look at the code. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Idea: fuse-kvm filesystem
On Thu, May 10, 2012 at 03:29:54PM +0300, Avi Kivity wrote: Currently when you mount a filesystem, you face two issues: - you have to be root - if the media is untrusted, it can exploit your kernel With kvm and fuse, we can have a virtualized kernel mount the filesystem, and re-export to the host, which mounts it using a fuse interface. This solves both problems, at the expense of speed and simplicity. In theory this can be used for mounting untrusted USB sticks (perhaps only for the less well tested filesystems). I guess you CC'd me so I could point out guestmount :-? http://libguestfs.org/guestmount.1.html guestmount does the above already, and you can point it directly at USB sticks, hard drives and the like, although most people use it for mounting VM filesystems on the host. On my local machine I'm a member of the disk group so I can do all this as non-root: $ guestmount --ro -a /dev/vg_pin/F16x64 -i /tmp/mnt $ cat /tmp/mnt/etc/redhat-release Fedora release 16 (Verne) $ ls /tmp/mnt bin dev home lib64 media opt root sbin srv tmp var boot etc lib lost+found mntproc run selinux sys usr One problem you'll find is that FUSE is pretty slow. I recommend if you're looking for performance that you use the libguestfs API calls directly instead of POSIX-over-FUSE. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [libvirt] Qemu/KVM is 3x slower under libvirt (due to vhost=on)
On Wed, Sep 28, 2011 at 12:19:09PM +0200, Reeted wrote: On 09/28/11 11:53, Daniel P. Berrange wrote: On Wed, Sep 28, 2011 at 11:49:01AM +0200, Reeted wrote: YES! It's the vhost. With vhost=on it takes about 12 seconds more time to boot. ...meaning? :-) I've no idea. I was always under the impression that 'vhost=on' was the 'make it go much faster' switch. So something is going wrong here that I cna't explain. Perhaps one of the network people on this list can explain... To turn vhost off in the libvirt XML, you should be able to use driver name='qemu'/ for the interface in question,eg interface type='user' mac address='52:54:00:e5:48:58'/ model type='virtio'/ driver name='qemu'/ /interface Ok that seems to work: it removes the vhost part in the virsh launch hence cutting down 12secs of boot time. If nobody comes out with an explanation of why, I will open another thread on the kvm list for this. I would probably need to test disk performance on vhost=on to see if it degrades or it's for another reason that boot time is increased. Is it using CPU during this time, or is the qemu-kvm process idle? It wouldn't be the first time that a network option ROM sat around waiting for an imaginary console user to press a key. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Guest kernel device compatability auto-detection
On Fri, Aug 26, 2011 at 09:22:45AM +0300, Sasha Levin wrote: On Thu, 2011-08-25 at 16:25 +, Decker, Schorschi wrote: 2) implement the feature as an agent in the guest OS where the hypervisor can only query the guest OS agent, using a standard TCP/IP methodology. I was planning to implementing it by probing the image before actually booting it. This process is completely offline and doesn't require interaction with the guest. The guest isn't even running at that point. There are still plenty of security issues to be concerned about with handling an offline guest. It is quite possible for such a guest to be booby-trapped in a way that allows an exploit. I summarised some of the issues I thought about here, but there are likely to be others: http://libguestfs.org/guestfs.3.html#security Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Guest kernel device compatability auto-detection
On Fri, Aug 26, 2011 at 09:08:02AM +0300, Sasha Levin wrote: You're thinking about trying to expose all interfaces during boot and seeing which ones the kernel bites? No, that's a bad idea. A current guest would register that as two disks. It might even try to write to them independently. You need an IDE device which can be promoted to virtio at the request of the guest (so you know the guest understands this type of device). Another thing that comes to mind is that we could start this project with a script that given a kernel, it would find the optimal hardware configuration for it (and the matching QEMU command line). It would be better if the guest could communicate what it needs. But no current guest works that way. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Guest kernel device compatability auto-detection
On Fri, Aug 26, 2011 at 01:18:49PM +0300, Sasha Levin wrote: On Fri, 2011-08-26 at 09:04 +0100, Richard W.M. Jones wrote: On Fri, Aug 26, 2011 at 09:22:45AM +0300, Sasha Levin wrote: On Thu, 2011-08-25 at 16:25 +, Decker, Schorschi wrote: 2) implement the feature as an agent in the guest OS where the hypervisor can only query the guest OS agent, using a standard TCP/IP methodology. I was planning to implementing it by probing the image before actually booting it. This process is completely offline and doesn't require interaction with the guest. The guest isn't even running at that point. There are still plenty of security issues to be concerned about with handling an offline guest. It is quite possible for such a guest to be booby-trapped in a way that allows an exploit. I summarised some of the issues I thought about here, but there are likely to be others: http://libguestfs.org/guestfs.3.html#security That was an interesting read. Are the concerns still valid if we were going to boot the image anyway later on? Yes. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Guest kernel device compatability auto-detection
On Thu, Aug 25, 2011 at 08:33:04AM +0300, Avi Kivity wrote: On 08/25/2011 08:21 AM, Sasha Levin wrote: Hi, Currently when we run the guest we treat it as a black box, we're not quite sure what it's going to start and whether it supports the same features we expect it to support when running it from the host. This forces us to start the guest with the safest defaults possible, for example: '-drive file=my_image.qcow2' will be started with slow IDE emulation even though the guest is capable of virtio. I'm currently working on a method to try and detect whether the guest kernel has specific configurations enabled and either warn the user if we know the kernel is not going to properly work or use better defaults if we know some advanced features are going to work. How am I planning to do it? First, we'll try finding which kernel the guest is going to boot (easy when user does '-kernel', less easy when the user boots an image). For simplicity sake I'll stick with the '-kernel' option for now. Once we have the kernel we can do two things: 1. See if the kernel was built with CONFIG_IKCONFIG. 2. Try finding the System.map which belongs to the kernel, it's provided with all distro kernels so we can expect it to be around. If we did find it we repeat the same process as in #1. If we found one of the above, we start matching config sets (we need a,b,c,d for virtio, let's see if it's all there). Once we find a good config set, we use it for defaults. If we didn't find a good config set we warn the user and don't even bother starting the guest. If we couldn't find either, we can just default to whatever we have as defaults now. To sum it up, I was wondering if this approach has been considered before and whether it sounds interesting enough to try. This is a similar problem to p2v or v2v - taking a guest that used to run on physical or virtual hardware, and modifying it to run on (different) virtual hardware. The first step is what you're looking for - detecting what the guest currently supports. You can look at http://libguestfs.org/virt-v2v/ for an example. I'm also copying Richard Jones, who maintains libguestfs, which does the actual poking around in the guest. Yes, as Avi says, we do all of the above already. Including for Windows guests. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Guest kernel device compatability auto-detection
On Thu, Aug 25, 2011 at 10:40:34AM +0300, Sasha Levin wrote: From what I gathered libguestfs only provides access to the guests' image. Correct. Which part is doing the IKCONFIG or System.map probing? Or is it done in a different way? You'll have to see what Matt's doing in the virt-v2v code for the details, but in general we have full access to: - grub.conf (to determine which kernel will boot) - the kernel image - the corresponding System.map and config - the modules directory - the Xorg config - boot.ini or BCD (to determine which NT kernel will boot) - the Windows Registry - the list of packages installed (to see if VMware-tools or some other guest agent is installed) So working out what drivers are available is just a tedious matter of iterating across each of these places in the filesystem. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Guest kernel device compatability auto-detection
On Thu, Aug 25, 2011 at 08:48:25AM +0100, Richard W.M. Jones wrote: On Thu, Aug 25, 2011 at 10:40:34AM +0300, Sasha Levin wrote: From what I gathered libguestfs only provides access to the guests' image. Correct. Which part is doing the IKCONFIG or System.map probing? Or is it done in a different way? You'll have to see what Matt's doing in the virt-v2v code for the details, but in general we have full access to: - grub.conf (to determine which kernel will boot) - the kernel image - the corresponding System.map and config - the modules directory - the Xorg config - boot.ini or BCD (to determine which NT kernel will boot) - the Windows Registry - the list of packages installed (to see if VMware-tools or some other guest agent is installed) So working out what drivers are available is just a tedious matter of iterating across each of these places in the filesystem. We had some interesting discussion on IRC about this. Detecting if a guest supports virtio is a tricky problem, and it goes beyond what the guest kernel can do. For Linux guests you also need to check what userspace can do. This means unpacking the initrd and checking for virtio drivers [in the general case this is intractable, but you can do it for specific distros]. You also need to check that udev has the correct rules and that LVM is configured to see VGs on /dev/vd* devices. Console and Xorg configuration may also need to be checked (for virtio-console and Cirrus/QXL support resp.) virt-v2v does quite a lot of work to *enable* virtio drivers including: - possibly installing a new kernel and updating grub - rebuilding the initrd to include virtio drivers - adjusting many different config files - removing other guest tools and Xen drivers - reconfiguring SELinux - adding viostor driver to Windows and adjusting the Windows Registry Critical Device Database Of course virt-v2v confines itself to specific known guests, and we test it like crazy. Here is the code: http://git.fedorahosted.org/git/?p=virt-v2v.git;a=blob;f=lib/Sys/VirtConvert/Converter/RedHat.pm;hb=HEAD http://git.fedorahosted.org/git/?p=virt-v2v.git;a=blob;f=lib/Sys/VirtConvert/Converter/Windows.pm;hb=HEAD 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/ -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()
On Mon, Jul 25, 2011 at 11:51:12AM +0300, Avi Kivity wrote: qemu_malloc() is type-unsafe as it returns a void pointer. Introduce QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. Signed-off-by: Avi Kivity a...@redhat.com --- This is part of my memory API patchset, but doesn't really belong there. qemu-common.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/qemu-common.h b/qemu-common.h index ba55719..66effa3 100644 --- a/qemu-common.h +++ b/qemu-common.h @@ -186,6 +186,9 @@ void qemu_free(void *ptr); char *qemu_strdup(const char *str); char *qemu_strndup(const char *str, size_t size); +#define QEMU_NEW(type) ((type *)(qemu_malloc(sizeof(type +#define QEMU_NEWZ(type) ((type *)(qemu_mallocz(sizeof(type + void qemu_mutex_lock_iothread(void); void qemu_mutex_unlock_iothread(void); FYI libvirt have been doing something similar, perhaps even more far-reaching: http://libvirt.org/hacking.html#memalloc http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/util/memory.h;hb=HEAD The libvirt versions are designed to catch errors in situations such as: - trying to allocate zero-sized objects when the underlying malloc returns NULL for zero-sized objects - trying to allocate N * M-sized objects when N * M overflows - realloc fails, don't forget the original pointer 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/ -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Enhancing qemu-img convert format compatibility
On Mon, Apr 18, 2011 at 11:18:42AM +0100, Stefan Hajnoczi wrote: qemu-img is a pretty good Rosetta stone for image formats but it is missing support some format versions. In order to bring qemu-img up-to-date with the latest disk image formats we will need to find specific image files and/or software versions that produce image files that qemu-img cannot understand today. If you have image files that qemu-img is unable to manipulate, please respond with details of the software and version used to produce the image. If possible please include a link to a small example image file. Stefan, We found that using the vSphere 4.x Export to OVF option would produce a VMDK file that qemu-img could not convert to raw. For older qemu-img the file would be converted to something that was not all zeroes, but nevertheless was certainly not a raw disk image. For current qemu-img, we get an Operation not permitted error which is at least better than silent corruption. Full details are in this bug report: https://bugzilla.redhat.com/show_bug.cgi?id=548723 Note the links at the top of that bug are broken. The disk image which failed is: http://oirase.annexia.org/tmp/TestLinux-disk1.vmdk SHA1: 2c81bae89210b075acc51da9d025935470149d55 http://oirase.annexia.org/tmp/TestLinux.ovf SHA1: 30831689b8c6f1b1a1fcbb728769b5f71056a580 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/ -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] qemu-kvm: Switch to upstream -enable-kvm semantics
On Mon, Jan 03, 2011 at 10:28:12AM +0200, Avi Kivity wrote: On 01/02/2011 09:52 PM, Richard W.M. Jones wrote: On Sun, Jan 02, 2011 at 11:15:33AM +0100, Jan Kiszka wrote: Does any qemu-kvm user rely on the automatic fallback to TCG if KVM initialization fails? Yes, libguestfs does ... ... or at least we would like to be able to reliably request this from the command line. You can specify as many toppings as you like for your pizza with -accel. Does that option now exist? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] qemu-kvm: Switch to upstream -enable-kvm semantics
On Sun, Jan 02, 2011 at 11:15:33AM +0100, Jan Kiszka wrote: Does any qemu-kvm user rely on the automatic fallback to TCG if KVM initialization fails? Yes, libguestfs does ... ... or at least we would like to be able to reliably request this from the command line. 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/ -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] qemu-kvm: Switch to upstream -enable-kvm semantics
On Tue, Dec 21, 2010 at 04:41:03PM +0100, Markus Armbruster wrote: Like this? upstream qemu | default |-enable-kvm +---+--- KVM available | disabled | enabled KVM unavailable | disabled |fail qemu-kvm| default |-enable-kvm| -no-kvm +---+---+--- KVM available | enabled* | enabled | disabled KVM unavailable | disabled |fail | disabled * differs from upstream libguestfs wants best effort behaviour, and libvirt wants KVM or die behaviour. Avi, can you comment on whether just opening /dev/kvm O_RDWR is a reasonable way to detect if KVM is available? Markus, any idea when we might get the -accel option appearing in released versions of qemu/KVM? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] qemu-kvm: Switch to upstream -enable-kvm semantics
On Tue, Dec 21, 2010 at 04:00:32PM +, Richard W.M. Jones wrote: Markus, any idea when we might get the -accel option appearing in released versions of qemu/KVM? Sorry, I thought this email wasn't going out to a public list. I should be more careful next time. I'll say instead: We really need both the -accel option and a working system of qemu capabilities. Both would be hugely helpful making it easier to work with qemu. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Hitting 29 NIC limit
On Thu, Oct 14, 2010 at 01:10:47PM +0100, Daniel P. Berrange wrote: Or a PCI bridge to wire up more PCI buses, so we raise the max limit for any type of device we emulate. Break the 29/30/31 virtio-blk limit ... please! 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/ -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Hitting 29 NIC limit
On Thu, Oct 14, 2010 at 04:57:36PM -0500, Anthony Liguori wrote: On 10/14/2010 04:42 PM, Richard W.M. Jones wrote: On Thu, Oct 14, 2010 at 01:10:47PM +0100, Daniel P. Berrange wrote: Or a PCI bridge to wire up more PCI buses, so we raise the max limit for any type of device we emulate. Break the 29/30/31 virtio-blk limit ... please! It was broken ages ago: [...] Excellent news indeeed. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35?
On Wed, Aug 04, 2010 at 08:54:35AM +0300, Avi Kivity wrote: On 08/04/2010 01:06 AM, Richard W.M. Jones wrote: On Tue, Aug 03, 2010 at 10:24:41PM +0300, Avi Kivity wrote: Why do we need to transfer roms? These are devices on the memory bus or pci bus, it just needs to be there at the right address. Boot splash should just be another rom as it would be on a real system. Just like the initrd? There isn't enough address space for a 100MB initrd in ROM. Because of limits of the original PC, sure, where you had to fit everything in 0xa-0xf or whatever it was. But this isn't a real PC. You can map the read-only memory anywhere you want. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35?
On Wed, Aug 04, 2010 at 12:52:23PM +0300, Avi Kivity wrote: On 08/04/2010 12:24 PM, Richard W.M. Jones wrote: Just like the initrd? There isn't enough address space for a 100MB initrd in ROM. Because of limits of the original PC, sure, where you had to fit everything in 0xa-0xf or whatever it was. But this isn't a real PC. You can map the read-only memory anywhere you want. I wasn't talking about the 1MB limit, rather the 4GB limit. Of that, 3-3.5GB are reserved for RAM, 0.5-1GB for PCI. Putting large amounts of ROM in that space will cost us PCI space. I'm only allocating 500MB of RAM, so there's easily enough space to put a large ROM, with tons of room for growth (of both RAM and ROM). Yes, even real hardware has done this. The Weitek math copro mapped itself in at physical memory addresses c000 (a 32 MB window IIRC). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35?
On Wed, Aug 04, 2010 at 04:07:09PM +0300, Gleb Natapov wrote: On Wed, Aug 04, 2010 at 08:04:09AM -0500, Anthony Liguori wrote: On 08/04/2010 03:17 AM, Avi Kivity wrote: For playing games, there are three options: - existing fwcfg - fwcfg+dma - put roms in 4GB-2MB (or whatever we decide the flash size is) and have the BIOS copy them Existing fwcfg is the least amount of work and probably satisfactory for isapc. fwcfg+dma is IMO going off a tangent. High memory flash is the most hardware-like solution, pretty easy from a qemu point of view but requires more work. The only trouble I see is that high memory isn't always available. If it's a 32-bit PC and you've exhausted RAM space, then you're only left with the PCI hole and it's not clear to me if you can really pull out 100mb of space there as an option ROM without breaking something. We can map it on demand. Guest tells qemu to map rom A to address X by writing into some io port. Guest copies rom. Guest tells qemu to unmap it. Better then DMA interface IMHO. I think this is a fine idea. Do you want me to try to implement something like this? (I'm on holiday this week and next week at the KVM Forum, so it won't be for a while ...) 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/ -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35?
On Wed, Aug 04, 2010 at 08:15:04AM -0500, Anthony Liguori wrote: On 08/04/2010 08:07 AM, Gleb Natapov wrote: On Wed, Aug 04, 2010 at 08:04:09AM -0500, Anthony Liguori wrote: On 08/04/2010 03:17 AM, Avi Kivity wrote: For playing games, there are three options: - existing fwcfg - fwcfg+dma - put roms in 4GB-2MB (or whatever we decide the flash size is) and have the BIOS copy them Existing fwcfg is the least amount of work and probably satisfactory for isapc. fwcfg+dma is IMO going off a tangent. High memory flash is the most hardware-like solution, pretty easy from a qemu point of view but requires more work. The only trouble I see is that high memory isn't always available. If it's a 32-bit PC and you've exhausted RAM space, then you're only left with the PCI hole and it's not clear to me if you can really pull out 100mb of space there as an option ROM without breaking something. We can map it on demand. Guest tells qemu to map rom A to address X by writing into some io port. Guest copies rom. Guest tells qemu to unmap it. Better then DMA interface IMHO. That's what I thought too, but in a 32-bit guest using ~3.5GB of RAM, where can you safely get 100MB of memory to full map the ROM? If you're going to map chunks at a time, you are basically doing DMA. It's boot time, so you can just map it over some existing RAM surely? Linuxboot.bin can work out where to map it so it won't be in any memory either being used or the target for the copy. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35?
On Wed, Aug 04, 2010 at 07:36:04PM +0300, Avi Kivity wrote: This is basically my suggestion to libguestfs: instead of generating an initrd, generate a bootable cdrom, and boot from that. The result is faster and has a smaller memory footprint. Everyone wins. We had some discussion of this upstream decided to do this. It should save the time it takes for the guest kernel to unpack the initrd, so maybe another second off boot time, which could bring us ever closer to the golden 5 second boot target. It's not trivial mind you, and won't happen straightaway. Part of it is that it requires reworking the appliance builder (a matter of just coding really). The less trivial part is that we have to 'hide' the CD device throughout the publically available interfaces. Then of course, a lot of testing. I will note that virt-install uses the -initrd interface for installing guests (large initrds too). And I've talked with a sysadmin who was using -kernel and -initrd for deploying VM hosting. In his case he did it so he could centralize kernel distribution / updates, and have the guests use /dev/vda == filesystem which made provisioning easy [for him -- I would have used libguestfs ...]. 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/ -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35?
On Wed, Aug 04, 2010 at 02:06:58PM -0600, David S. Ahern wrote: On 08/04/10 11:34, Avi Kivity wrote: And it's awesome for fast prototyping. Of course, once that fast becomes dog slow, it's not useful anymore. For the Nth time, it's only slow with 100MB initrds. 100MB is really not that large for an initrd. note I'd just like to note that the libguestfs initrd is uncompressed. The reason for this is I found that the decompression code in Linux is really slow. I have to admit I didn't look into why this is. By not compressing it on the host and decompressing it on the guest, we saved a bunch of boot time (3-5 seconds IIRC). Anyway, comparing 115MB libguestfs initrd and other initrd sizes may not be a fair comparison, since almost every other initrd you will see will be compressed. /note Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35?
On Tue, Aug 03, 2010 at 02:33:02PM +0300, Gleb Natapov wrote: On Tue, Aug 03, 2010 at 12:13:06PM +0100, Richard W.M. Jones wrote: qemu compiled from today's git. Using the following command line: $qemudir/x86_64-softmmu/qemu-system-x86_64 -L $qemudir/pc-bios \ -drive file=/dev/null,if=virtio \ -enable-kvm \ -nodefaults \ -nographic \ -serial stdio \ -m 500 \ -no-reboot \ -no-hpet \ -net user,vlan=0,net=169.254.0.0/16 \ -net nic,model=ne2k_pci,vlan=0 \ -kernel /tmp/libguestfsEyAMut/kernel \ -initrd /tmp/libguestfsEyAMut/initrd \ -append 'panic=1 console=ttyS0 udevtimeout=300 noapic acpi=off printk.time=1 cgroup_disable=memory selinux=0 guestfs_vmchannel=tcp:169.254.2.2:35007 guestfs_verbose=1 TERM=xterm-color ' With kernel 2.6.35 [*], this takes about 1 min 20 s before the guest starts. If I revert back to kernel 2.6.34, it's pretty quick as usual. strace is not very informative. It's in a loop doing select and reading/writing from some file descriptors, including the signalfd and two pipe fds. Anyone seen anything like this? I assume your initrd is huge. It's ~110MB, yes. In newer kernels ins/outs are much slower that they were. They are much more correct too. It shouldn't be 1 min 20 sec for 100M initrd though, but it can take 20-30 sec. This belongs to kvm list BTW. I can't see anything about this in the kernel changelog. Can you point me to the commit or the key phrase to look for? Also, what's the point of making in/out more correct when they we know we're talking to qemu (eg. from the CPUID) and we know it already worked fine before with qemu? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35?
On Tue, Aug 03, 2010 at 03:37:14PM +0300, Gleb Natapov wrote: On Tue, Aug 03, 2010 at 01:10:00PM +0100, Richard W.M. Jones wrote: I can't see anything about this in the kernel changelog. Can you point me to the commit or the key phrase to look for? 7972995b0c346de76 Thanks - I see. Also, what's the point of making in/out more correct when they we know we're talking to qemu (eg. from the CPUID) and we know it already worked fine before with qemu? Qemu has nothing to do with that. ins/outs didn't worked correctly for some situation. They didn't work at all if destination/source memory was MMIO (didn't work as in hang vcpu IIRC and this is security risk). Direction flag wasn't handled at all (if it was set instruction injected #GP into a gust). It didn't check that memory it writes to is shadowed in which case special action should be taken. It didn't delivered events during long string operations. May be more. Unfortunately adding all that makes emulation much slower. I already implemented some speedups, and more is possible, but we will not be able to get to previous string io speed which was our upper limit. Thanks for the explanation. I'll repost my DMA-like fw-cfg patch once I've rebased it and done some more testing. This huge regression for a common operation (implementing -initrd) needs to be solved without using inb/rep ins. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35?
On Tue, Aug 03, 2010 at 04:19:39PM +0300, Avi Kivity wrote: On 08/03/2010 03:48 PM, Richard W.M. Jones wrote: Thanks for the explanation. I'll repost my DMA-like fw-cfg patch once I've rebased it and done some more testing. This huge regression for a common operation (implementing -initrd) needs to be solved without using inb/rep ins. Adding more interfaces is easy but a problem in the long term. We'll optimize it as much as we can. Meanwhile, why are you loading huge initrds? Use a cdrom instead (it will also be faster since the guest doesn't need to unpack it). Because it involves rewriting the entire appliance building process, and we don't necessarily know if it'll be faster after we've done that. Look: currently we create the initrd on the fly in 700ms. We've no reason to believe that creating a CD-ROM on the fly wouldn't take around the same time. After all, both processes involve reading all the host files from disk and writing a temporary file. You have to create these things on the fly, because we don't actually ship an appliance to end users, just a tiny ( 1 MB) skeleton. You can't ship a massive statically linked appliance to end users because it's just unmanageable (think: security; updates; bandwidth). Loading the initrd currently takes 115ms (or could do, if a sensible 50 line patch was permitted). So the only possible saving would be the 115ms load time of the initrd. In theory the CD-ROM device could be detected in 0 time. Total saving: 115ms. But will it be any faster, since after spending 115ms, everything runs from memory, versus being loaded from the CD? Let's face the fact that qemu has suffered from an enormous regression. From some hundreds of milliseconds up to over a minute, in the space of 6 months of development. For a very simple operation: loading a file into memory. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35?
On Tue, Aug 03, 2010 at 05:38:25PM +0300, Avi Kivity wrote: The time will only continue to grow as you add features and as the distro bloats naturally. Much better to create it once and only update it if some dependent file changes (basically the current on-the-fly code + save a list of file timestamps). This applies to both cases, the initrd could also be saved, so: Total saving: 115ms. 815 ms by my arithmetic. no, not true, 115ms. You also save 3*N-2*P memory where N is the size of your initrd and P is the actual amount used by the guest. Can you explain this? Loading a file into memory is plenty fast if you use the standard interfaces. -kernel -initrd is a specialized interface. Why bother with any command line options at all? After all, they keep changing and causing problems for qemu's users ... Apparently we're all doing stuff wrong, in ways that are never explained by the developers. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35?
On Tue, Aug 03, 2010 at 07:10:18PM +0300, Avi Kivity wrote: -kernel and -initrd is a developer's interface intended to make life easier for users that use qemu to develop kernels. It was not intended as a high performance DMA engine. Neither was the firmware _configuration_ interface. That is what virtio and to a lesser extent IDE was written to perform. You'll get much better results from them. Firmware configuration replaced something which was already working really fast -- preloading the images into memory -- with something which worked slower, and has just recently got _way_ more slow. This is a regression. Plain and simple. I have posted a small patch which makes this 650x faster without appreciable complication. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35?
On Tue, Aug 03, 2010 at 07:44:49PM +0300, Avi Kivity wrote: On 08/03/2010 07:28 PM, Richard W.M. Jones wrote: I have posted a small patch which makes this 650x faster without appreciable complication. It doesn't appear to support live migration, or hiding the feature for -M older. AFAICT live migration should still work (even assuming someone live migrates a domain during early boot, which seems pretty unlikely ...) Maybe you mean live migration of the dma_* global variables? I can fix that. It's not a good path to follow. Tomorrow we'll need to load 300MB initrds and we'll have to rework this yet again. Not a very good straw man ... The patch would take ~300ms instead of ~115ms, versus something like 2 mins 40 seconds with the current method. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35?
On Tue, Aug 03, 2010 at 08:58:10PM +0300, Avi Kivity wrote: Richard, can you test kvm.git master? it already contains one fix and we plan to add more. Yup, I will ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35?
On Tue, Aug 03, 2010 at 09:43:39PM +0300, Avi Kivity wrote: libguestfs does not depend on an x86 architectural feature. qemu-system-x86_64 emulates a PC, and PCs don't have -kernel. We should discourage people from depending on this interface for production use. I really don't get this whole thing where we must slavishly emulate an exact PC ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35?
On Tue, Aug 03, 2010 at 10:22:22PM +0300, Avi Kivity wrote: On 08/03/2010 10:13 PM, Richard W.M. Jones wrote: On Tue, Aug 03, 2010 at 09:43:39PM +0300, Avi Kivity wrote: libguestfs does not depend on an x86 architectural feature. qemu-system-x86_64 emulates a PC, and PCs don't have -kernel. We should discourage people from depending on this interface for production use. I really don't get this whole thing where we must slavishly emulate an exact PC ... This has two motivations: - documented interfaces: we suck at documentation. We seldom document. Even when we do document something, the documentation is often inaccurate, misleading, and incomplete. While an exact PC unfortunately doesn't exist, it's a lot closer to reality than, say, an exact Linux syscall interface. If we adopt an existing interface, we already have the documentation, and if there's a conflict between the documentation and our implementation, it's clear who wins (well, not always). - preexisting guests: if we design a new interface, we get to update all guests; and there are many of them. Whereas an exact PC will be seen by the guest vendors as well who will then add whatever support is necessary. On the other hand we end up with stuff like only being able to add 29 virtio-blk devices to a single guest. As best as I can tell, this comes from PCI, and this limit required a bunch of hacks when implementing virt-df. These are reasonable motivations, but I think they are partially about us: We could document things better and make things future-proof. I'm surprised by how lacking the doc requirements are for qemu (compared to, hmm, libguestfs for example). We could demand that OSes write device drivers for more qemu devices -- already OS vendors write thousands of device drivers for all sorts of obscure devices, so this isn't really much of a demand for them. In fact, they're already doing it. 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/ -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35?
On Tue, Aug 03, 2010 at 10:24:41PM +0300, Avi Kivity wrote: Why do we need to transfer roms? These are devices on the memory bus or pci bus, it just needs to be there at the right address. Boot splash should just be another rom as it would be on a real system. Just like the initrd? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] virt-what.in: Added VMware virt detection using cpuid in wrapper script
On Tue, Jun 29, 2010 at 07:29:01PM -0400, Chetan Loke wrote: Brief discussion thread - http://lkml.org/lkml/2010/6/29/355 Added VMware detection via cpuid.Mimic'd VMware's balloon driver's init-time check(cpuid followed by dmi-checks). Moved the existing logic into a simple function to achieve that. Tested virt-what.in(ran as a script) and virt-what-cpuid-helper within a Linux guest on ESX. Thanks. Chetan, do you think you could send me this one again as an attachment. Some MUA/MTA along the way has sufficiently mangled the patch such that it can no longer be applied. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Unify KVM kernel-space and user-space code into a single project
On Mon, Mar 22, 2010 at 01:05:13PM +, Daniel P. Berrange wrote: This is close to the way libguestfs already works. It boots QEMU/KVM pointing to a minimal stripped down appliance linux OS image, containing a small agent it talks to over some form of vmchannel/serial/virtio-serial device. Thus the kernel in the appliance it runs is the only thing that needs to know about the filesystem/lvm/dm on-disk formats - libguestfs definitely does not want to be duplicating this detailed knowledge of on disk format itself. It is doing full read-write access to the guest filesystem in offline mode - one of the major use cases is disaster recovery from a unbootable guest OS image. As Dan said, the 'daemon' part is separate and could be run as a standard part of a guest install, talking over vmchannel to the host. The only real issue I can see is adding access control to the daemon (currently it doesn't need it and doesn't do any). Doing it this way you'd be leveraging the ~250,000 lines of existing libguestfs code, bindings in multiple languages, tools etc. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Unify KVM kernel-space and user-space code into a single project
On Mon, Mar 22, 2010 at 02:56:47PM +0100, Ingo Molnar wrote: Just curious: any plans to extend this to include live read/write access as well? I.e. to have the 'agent' (guestfsd) running universally, so that tools such as perf and by users could rely on the VFS integration as well, not just disaster recovery tools? Totally. That's not to say there is a definite plan, but we're very open to doing this. We already wrote the daemon in such a way that it doesn't require the appliance part, but could run inside any existing guest (we've even ported bits of it to Windoze ...). The only remaining issue is how access control would be handled. You obviously wouldn't want anything in the host that can get access to the vmchannel socket to start sending destructive write commands into guests. 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/ -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Workaround segfault when qemu-kvm runs inside a VM
This was discussed here before so I'll just link to that earlier
discussion:
http://www.mail-archive.com/kvm@vger.kernel.org/msg19890.html
The attached patch is a bit of a hack, but at least it stops qemu-kvm
from segfaulting when hardware virtualization isn't available.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.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/
From add286b6e753f14e4ae0ab6b831441aea0d35497 Mon Sep 17 00:00:00 2001
From: Richard Jones rjo...@f12rawhidex64.home.annexia.org
Date: Thu, 20 Aug 2009 13:52:20 +0100
Subject: [PATCH] Workaround segfault when qemu-kvm runs inside a VM
(RHBZ#516543).
Regression was introduced by this commit:
http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=commitdiff;h=b8083e930efc1ee85a7ad7e700dbd0f52ebb32dd
Upstream discussion:
http://www.mail-archive.com/kvm@vger.kernel.org/msg19890.html
Note: NOT UPSTREAM and this is something of a hack. Upstream are
still debating how they really want to fix this.
---
exec.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/exec.c b/exec.c
index 705bcf2..2091516 100644
--- a/exec.c
+++ b/exec.c
@@ -422,9 +422,6 @@ static uint8_t
static_code_gen_buffer[DEFAULT_CODE_GEN_BUFFER_SIZE];
static void code_gen_alloc(unsigned long tb_size)
{
-if (kvm_enabled())
-return;
-
#ifdef USE_STATIC_CODE_GEN_BUFFER
code_gen_buffer = static_code_gen_buffer;
code_gen_buffer_size = DEFAULT_CODE_GEN_BUFFER_SIZE;
--
1.6.4
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On Mon, Aug 03, 2009 at 02:57:01PM -0500, Anthony Liguori wrote: Richard W.M. Jones wrote: On Mon, Jul 27, 2009 at 06:44:28PM -0500, Anthony Liguori wrote: It really suggests that you need _one_ vmchannel that's exposed to userspace with a single userspace daemon that consumes it. ... or a more flexible API. I don't like having fixed /dev/vmch* devices either. Have you considered using a usb serial device? Something attractive about it is that a productid/vendorid can be specified which means that you can use that as a method of enumerating devices. Hot add/remove is supported automagically. [ Meant to reply to this two days ago :-( ] We're using -net channel ^W guestfwd in libguestfs now. Apart from the problem with using the new syntax, which I hope to get around to resolving some day, it performs quite well. The userspace API is somewhat annoying. Hot add/remove isn't a concern for us right now, nor is migration. Since we can throw up new qemu-based appliances in a few seconds. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On Mon, Jul 27, 2009 at 06:44:28PM -0500, Anthony Liguori wrote: It really suggests that you need _one_ vmchannel that's exposed to userspace with a single userspace daemon that consumes it. ... or a more flexible API. I don't like having fixed /dev/vmch* devices either. A long time ago (on a mailing list not so far away) there was a much better userspace API proposed, which had a separate AF_VMCHANNEL address family. That API works much more like TCP sockets, except without requiring network devices: https://lists.linux-foundation.org/pipermail/virtualization/2008-December/012383.html Note: even better if it allows multiple channels with the same name to be created on demand from the guest, which the API would allow, although not the implementation above. That would allow the fast-user-switching / multi-X-server case to work well, and be useful if we parallelize libguestfs. 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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On Tue, Jul 28, 2009 at 09:48:00AM -0500, Anthony Liguori wrote: Richard W.M. Jones wrote: On Mon, Jul 27, 2009 at 06:44:28PM -0500, Anthony Liguori wrote: It really suggests that you need _one_ vmchannel that's exposed to userspace with a single userspace daemon that consumes it. ... or a more flexible API. I don't like having fixed /dev/vmch* devices either. Indeed. A long time ago (on a mailing list not so far away) there was a much better userspace API proposed, which had a separate AF_VMCHANNEL address family. That API works much more like TCP sockets, except without requiring network devices: Dave Miller nacked that approach with a sledgehammer instead preferring that we just use standard TCP/IP which is what led to the current implementation using slirp. I'm aware of that - I just don't think it was a good choice. [BTW the qemu-devel mailing list seems to be bouncing messages] Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [et-mgmt-tools] Re: [libvirt] RE: [Qemu-devel] [ANNOUNCE] virt-mem tools version 0.2.8 released
On Mon, Aug 11, 2008 at 07:39:34PM +1200, james wrote: This is what libvirt gives you (and lots more, eg. secure remote access to hypervisors, bindings to Perl many other languages, etc.). Can you be more specfic about what you couldn't do with libvirt? I can give you such an example although I confess it could be due to my lack of understanding of the libvirt config. I have tried and tried to use libvirt to configure VMs within KVM using scsi disk images. Usually when tinkering/experimenting with RAID setups. It just will not take it. Starting a KVM based VM from the command line with the appropriate settings and I have no problems. This inability to use scsi within libvirt has been extremely frustrating until I took the plunge and went to to kvm command line. However if you can point out an example xml config for a VM using scsi disk images that works then that would be very cool Dan's probably the best one to help here, but our example configs are here: http://libvirt.org/formatstorage.html 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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [et-mgmt-tools] Re: [libvirt] RE: [Qemu-devel] [ANNOUNCE] virt-mem tools version 0.2.8 released
On Sun, Aug 10, 2008 at 11:07:32AM +0100, Richard W.M. Jones wrote: Libvirt deliberately doesn't expose the full feature set of any one hypervisor which it supports, but instead exposes common features. 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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [libvirt] RE: [Qemu-devel] [ANNOUNCE] virt-mem tools version 0.2.8 released
On Thu, Aug 07, 2008 at 03:55:49PM +0300, Alexey Eremenko wrote: The only problem: virt-mem doesn't compiles. 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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [et-mgmt-tools] Re: [libvirt] RE: [Qemu-devel] [ANNOUNCE] virt-mem tools version 0.2.8 released
On Thu, Aug 07, 2008 at 11:47:39AM +0100, Daniel P. Berrange wrote: On Thu, Aug 07, 2008 at 07:40:58PM +0900, Jun Koi wrote: One of the problem is that these tools work via libvirt, so on a VM is not managed by libvirt, these tools no longer work. 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 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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] virt-mem tools version 0.2.8 released
I'm pleased to announce the latest release of the virt-mem tools, version 0.2.8. These are tools for system administrators which let you find things like kernel messages, process lists and network information of your guests. For example: virt-uname 'uname' command, shows OS version, architecture, etc. virt-dmesg 'dmesg' command, shows kernel messages virt-ps 'ps' command, shows process list Nothing needs to be installed in the guest for this to work, and the tools are specifically designed to allow easy scripting and integration with databases and monitoring systems. Source is available from the web page here: http://et.redhat.com/~rjones/virt-mem/ The latest version (0.2.8) reworks the internals substantially so that we have direct access to basically any kernel structure, and this will allow us to quickly add the remaining features that people have asked for (memory usage information, lists of network interfaces and so on). As usual, patches, feedback, suggestions etc. are very welcome! Binaries will be available in Fedora 10 (Rawhide) at some point soon. 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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Has anyone tried to run Linux 2.2 under KVM?
On Sat, Jul 05, 2008 at 02:16:34PM +0300, Avi Kivity wrote: Richard W.M. Jones wrote: I've been trying out RHL6.2 [sic] on KVM 70. This has an ancient 2.2.14 kernel and generally dates from 1999/2000. However it does run nicely in 16 MB of RAM which makes it useful for me because I want to see what happens when we run 100s of KVM instances :-) Can you post a pointer to an iso image somewhere? I got it from this site, although it's often a little overloaded so best to use 'wget' to grab the ISO. http://archive.download.redhat.com/pub/redhat/linux/6.2/en/iso/i386/ 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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Has anyone tried to run Linux 2.2 under KVM?
I've been trying out RHL6.2 [sic] on KVM 70. This has an ancient 2.2.14 kernel and generally dates from 1999/2000. However it does run nicely in 16 MB of RAM which makes it useful for me because I want to see what happens when we run 100s of KVM instances :-) A few observations: (1) IDE DMA seems to cause problems. I get lost interrupts and general disk problems unless I boot the kernel with ide=nodma. (2) The kernel sees the default rtl8139 NIC but cannot seem to get any packets out of it. I had to switch to using ne2k_pci instead. (3) Heavy console activity hangs the virtual machine. This is a really weird and very annoying bug. (a) Serial console (-serial stdio) _also_ hangs under heavy activity. (b) At the point when the kernel hangs, the EIP is always at the same place, seemingly in the __best_copy_from_user function in the guest kernel. (c) The KVM monitor is still responsive. (d) (Now the strange bit ..) If I switch to the KVM monitor first and run my load tests - it doesn't hang! (e) However, qemu-kvm -nographic hangs under my load tests. (f) Plain qemu 0.9.1 doesn't hang. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 59 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
