VM hang: how to get latest sources
My VM keeps hanging (high host CPU use, no response except from the monitor) and I assume the first advice I will get is to use the current version of qemu/kvm. Where and what is that? It seems there is a development and production release, and things have mostly been folded into qemu. I'm not sure what flavor is appropriate. Some earlier messages on the list referred to a git repo. I'm running Debian wheezy amd64 with linux kernel 3.2.0-4-amd64 and qemu-kvm 1.1.2+dfsg-6. It looks as if the most current version in sid is qemu-system-x86 (1.6.0+dfsg-1). If the side version is recent enough it would probably be a bit easier for me to get going. I would like to avoid upgrading the kernel if possible. I am invoking with -cpu pentium3 -smp 2. The host processor is Intel(R) Xeon(R) CPU E3-1245 V2 @ 3.40GHz (4 cores, 8 hyperthreads). If anyone can help me on my problems with the current version, I would welcome it. Here are some more questions. Do I get hardware virtualization if I specify -cpu pentium3? Side note: I'm not sure I need the -cpu at all; I am trying to recover a 32 bit OS (Debian Lenny) that ran on a Pentium 4 before it died. I may try running without the -cpu argument to see if that helps. Details of the crashes are at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724798. Any ideas about what's going on? How can I capture more useful diagnostic information? Thanks. Ross Boylan -- 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
How to share filesystem
I would like to have access to the same file system from the host and the guest. Can anyone recommend the best way to do this, considering ease of use, safety (concurrent access from guest and host does not corrupt) and performance? For example, I would like to restore files from backup using the host, but write to filesystems used by the guest. I have previously used kvm mostly with disks that are based on LVM logical volumes, e.g. -hda /dev/turtle/Squeeze00. Since the LVs are virtual disks, I can't just mount them in the host AFAIK. Among the alternatives I can think of are using NFS and using NBD. Maybe there's some kind of loopback device I could use on the disk image to access it from the host. Host: Debian GNU/Linux wheezy, amd64 architecture, qemu-kvm 1.1.2 Guest: Debian GNU/Linux lenny i386. Host processor is a recent i5 with good virtualization (flaga: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms) Thanks. Ross Boylan -- 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: How to share filesystem
On Tue, 2013-09-24 at 12:24 +0200, Thomas Huth wrote: Am Tue, 24 Sep 2013 01:38:39 -0700 schrieb Ross Boylan r...@biostat.ucsf.edu: I would like to have access to the same file system from the host and the guest. Can anyone recommend the best way to do this, considering ease of use, safety (concurrent access from guest and host does not corrupt) and performance? [...] Among the alternatives I can think of are using NFS and using NBD. Maybe there's some kind of loopback device I could use on the disk image to access it from the host. I've never tried it on my own, but there is also virtio-9p: http://wiki.qemu.org/Documentation/9psetup Maybe that's what you need? Thomas At first I saw Plan 9 and figured it was irrelevant to linux, but the example seems to be Linux. So I'm puzzled. Ross -- 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: How to share filesystem
On Wed, 2013-09-25 at 03:06 +0800, shendl1...@gmail.com wrote: 9p is a protocol that is created by plan 9 operation system. linux can use virtio-9p. 发自我的 iPhone Is this the preferred way to go? At any rate, I don't think I can use it easily because the wiki says it needs linux 2.6.36.rc4 or newer, and Lenny uses 2.6.26 and backports only has 2.6.32. Ross 在 2013年9月25日，3:03，shendl1...@gmail.com 写道： You。can use. Virtio-9p. In. Linux. 发自我的 iPhone 在 2013年9月25日，0:37，Ross Boylan r...@biostat.ucsf.edu 写道： On Tue, 2013-09-24 at 12:24 +0200, Thomas Huth wrote: Am Tue, 24 Sep 2013 01:38:39 -0700 schrieb Ross Boylan r...@biostat.ucsf.edu: I would like to have access to the same file system from the host and the guest. Can anyone recommend the best way to do this, considering ease of use, safety (concurrent access from guest and host does not corrupt) and performance? [...] Among the alternatives I can think of are using NFS and using NBD. Maybe there's some kind of loopback device I could use on the disk image to access it from the host. I've never tried it on my own, but there is also virtio-9p: http://wiki.qemu.org/Documentation/9psetup Maybe that's what you need? Thomas At first I saw Plan 9 and figured it was irrelevant to linux, but the example seems to be Linux. So I'm puzzled. Ross -- 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 -- 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: expanding virtual disk based on lvm
On Tue, 2012-09-04 at 15:53 +0300, Avi Kivity wrote: On 08/28/2012 11:26 PM, Ross Boylan wrote: My vm launches with -hda /dev/turtle/VD0 -hdb /dev/turtle/VD1, where VD0 and VD1 are lvm logical volumes. I used lvextend to expand them, but the VM, started after the expansion, does not seem to see the extra space. What do I need to so that the space will be recognized? IDE (-hda) does not support rechecking the size. Try booting with virtio-blk. Additionally, you may need to request the guest to rescan the drive (no idea how to do that). Nor am I sure whether qemu will emulate the request correctly. Thank you for the suggestion. I think the physical recognition of the new virtual disk size was accomplished when I restarted the VM, without any other steps. I've had plenty of other problems, but I think at the VM level things are good. I needed to manually resize the last partition with fdisk. None of the other tools (cfdisk, parted, gparted) would manipulate the partition table, for reasons that became apparent. The resized partitions were in an mdadm RAID1 array. When I expanded them it meant the raid superblock was no longer found (theory), and the RAID could not be reassembled (fact). I've attempted to fix that by recreating the array, but mdadm is refusing to use the UUID I specify, instead modifying it with the localhost name. The virtual disks are for a Debian lenny VM, but the only other spare VM around was squeeze, and mdadm in squeeze does the localhost rewriting. By the way, it's really great to have a VM's as a testing area in which I can discover these problems without trashing my real system. Thanks to everyone who made it possible. Ross Boylan -- 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
expanding virtual disk based on lvm
My vm launches with -hda /dev/turtle/VD0 -hdb /dev/turtle/VD1, where VD0 and VD1 are lvm logical volumes. I used lvextend to expand them, but the VM, started after the expansion, does not seem to see the extra space. What do I need to so that the space will be recognized? The net has references to qemu-resize and virt-resize, but I don't seem to have them. The host system is on QEMU emulator version 0.13.0 (qemu-kvm-0.13.0), Copyright (c) 2003-2008 Fabrice Bellard from the Debian I'm on lenny (it's the upgrade I'm testing). The other problem is that everything on the net refers to files that are disk images; I'm not sure if the same procedures apply when a logical volume is the underlying device. The virtual disks each have 3 partitions. Inside the VM software raid produces dm0 from the 2 first partitions and dm1 from the 2 third partitions. Thanks for any help. Ross Boylan -- 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: expanding virtual disk based on lvm
On Tue, 2012-08-28 at 14:15 -0700, Freddie Cash wrote: On Tue, Aug 28, 2012 at 1:26 PM, Ross Boylan r...@biostat.ucsf.edu wrote: My vm launches with -hda /dev/turtle/VD0 -hdb /dev/turtle/VD1, where VD0 and VD1 are lvm logical volumes. I used lvextend to expand them, but the VM, started after the expansion, does not seem to see the extra space. You've increased the size of the hard drive, but you haven't changed the filesystem on top of the hard drive to use that extra space. How you do that depends on whether the virtual disks are partitioned with filesystems in the partitions; or formatted with a filesystem directly. The virtual disks are partitioned. If they are partitioned, then you need to boot off a LiveCD, extend the partition, then extend the filesystem in the partition. So I edit the parition table directly? I thought there might be some meta-information that kvm used to establish the size of the physical disk. I'm not sure what the final sector number should be; I could get it approximately from the size, but I'm not sure my calculation would be just right. If they are formatted directly, then (depending on the filesystem) you can grow the filesystem. Some filesystems can't be extended live, so you have to boot to a LiveCD. No fancy VM-related tools required. Just think in terms of real, physical hardware, and it all becomes clear. :) My real physical disks have never grown spontaneously. :) I also wasn't sure how the kernel would react, and so I shut it down during the growth. Ross -- 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
unhandled wrmsr
I built from qemu-kvm-0.13.0.tar.gz on a Debian system with kernel linux-image-2.6.32-5-amd642.6.32-26 (but otherwise basically the stable/lenny version) and now see Oct 26 16:57:38 markov kernel: [ 5757.672426] kvm: 23063: cpu0 unhandled wrmsr: 0x198 data 0 Oct 26 16:57:38 markov kernel: [ 5757.672454] kvm: 23063: cpu1 unhandled wrmsr: 0x198 data 0 Oct 26 16:57:38 markov kernel: [ 5757.672476] kvm: 23063: cpu2 unhandled wrmsr: 0x198 data 0 Oct 26 16:57:38 markov kernel: [ 5757.672497] kvm: 23063: cpu3 unhandled wrmsr: 0x198 data 0 on startup. I have 4 CPUs with 8 cores: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz stepping 06. Note this means the kernel side is from the Debian package, and so might be older. google shows this message has popped up several times in the past and been fixed several times. Most of the messages indicate it is harmless, but https://bugs.launchpad.net/ubuntu/+source/linux/+bug/325851 on 2009-07-01 says it's not benign. There also seems to be a current bug open about it, http://sourceforge.net/tracker/index.php?func=detailaid=3056363group_id=180599atid=893831, which is also marked as fixed. Can anyone tell me anything more about these messages? Do they indicate a problem I need to fix? If so, any advice on how to fix it? Thanks. Ross P.S. Please cc me on reply. -- 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 usability
On Wed, 2010-03-03 at 08:55 +, Daniel P. Berrange wrote: On Tue, Mar 02, 2010 at 06:57:54PM -0800, Ross Boylan wrote: On Mon, 2010-03-01 at 15:59 -0600, Anthony Liguori wrote: * desktop is 1024 x 720 1024x768 and this is what the default is today anyway. That was not my experience, as reported in my post a few days ago (800x600 max resolution), nor is it the experience reported in the message that kicked off this thread. I have been able to get a higher resolution, but it was far from automatic. It depends on the guest OS version. QEMU exposes a cirrus logic card by defualt, QEMU docs recommend -std vga for higher resolutions; I used that. and given the lack of vsync/hsync info, the Xorg driver will pick 800x600 as the default resolution in absence of any Xorg.conf About 6 months or so back, we got Xorg guys to add a code to the Xorg cirrus driver that looked for the QEMU PCI subsystem ID and if found, defaults to 1024x768 instead. So presumably that logic wouldn't have kicked in. I had xorg 7.5 on Debian squeeze as the guest. Of course this is itself still far from optimal as a user experiance. We really want it to be fully configured to any resolution as easily as the user would do with a real graphics card monitor. Is there some obstacle to getting the virtual monitor to provide configuration info when it's queried? That seems like the most direct solution. Ross -- 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 usability
On Mon, 2010-03-01 at 15:59 -0600, Anthony Liguori wrote: * desktop is 1024 x 720 1024x768 and this is what the default is today anyway. That was not my experience, as reported in my post a few days ago (800x600 max resolution), nor is it the experience reported in the message that kicked off this thread. I have been able to get a higher resolution, but it was far from automatic. I believe the root cause is the failure of the virtual monitor to respond to or provide EDID (?) to tell the kernel available screen resolutions, sync values, and similar information. I recall seeing an open bug on this, not sure if it was kvm or qemu. I also recall it had been open for a fairly long time. Ross -- 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
800x600 max resolution
I'm running qemu-kvm-0.12.2, compiled from source on Debian lenny (stable), amd64 architecture (Xeon). The VM is running Debian squeeze (testing). When it starts up, the boot screen appears to be 640x480. If I launch an X session, I get 800x600. I would like higher resolutions in both terminal and X mode. Unlike earlier X's, I don't need to do anything special to get the tablet device recognized, which is nice. But something is going wrong with the video. Other bugs on the net suggest that the virtual display adapter is not advertising its modes properly, but the log file seems to show they are all there (though there is a message VESA VBE DDC not supported). The attached log file is for a start without any xorg.conf. I have tried various xorg.conf's, but have gotten nowhere--apparently if I define one section I need to define all the others. The problem in the log seems to be that X runs through a series of modes and says no mode of this name. Should it be using something like 104 or 104 (1024x768) instead? Then it tries a less strict probe, and rejects all but a couple of low-resolution modes with hsync out of range. I launch with sudo vdeq bin/qemu-system-x86_64 -net nic,vlan=1,macaddr=52:54:a0:16:01:01 \ -net vde,vlan=1,sock=/var/run/vde2/tap0.ctl \ -boot c \ -vga std -vnc localhost:7 -usbdevice tablet \ -name Squeeze00 \ -hda /dev/turtle/Squeeze00 \ -soundhw es1370 -m 1G -smp 4 I'd really appreciate some help, particularly because the VM's virtual network card stops working after it's been up awhile--a separate problem. Thanks. Ross Boylan Xorg.0.log.bz2 Description: application/bzip
Re: vnc mouse trouble; -usbdevice tablet no help [SOLVED]
On Mon, 2010-02-08 at 07:17 -0500, Javier Guerra wrote: On Mon, Feb 8, 2010 at 1:19 AM, Ross Boylan r...@biostat.ucsf.edu wrote: Previous advice (to me and others) was to use -usbdevice tablet. I've tried that, and a variety of kvm/qemu versions, but no luck. check your guest's X11 config. if you didn't have -usbdevice tablet when installing, the installer would set only the PS/2 mouse, which isn't disabled when adding the tablet. Thank you for the tip. It worked. Documentation on how to do this was skimpy, but the following seems to work. The two mice still get separated during motion, but when I pause they catch up with each other. This is with xorg 1:7.3+20 on Debian Lenny. xorg.conf Section Module Load evdev Disable mouse EndSection Section InputDevice Identifier Generic Keyboard Driver kbd Option XkbRules xorg Option XkbModel pc104 Option XkbLayout us EndSection Section InputDevice Identifier Configured Mouse Driver evdev Option CorePointer Option Device /dev/input/by-path/pci-:00:01.2-usb-0:1:1.0-event-joystick Option Path /dev/input/by-path/pci-:00:01.2-usb-0:1:1.0-event-joystick EndSection Section Device Identifier Configured Video Device EndSection Section Monitor Identifier Configured Monitor EndSection Section Screen Identifier Default Screen Monitor Configured Monitor EndSection /xorg.conf The man page with the distribution says the mouse module supports the USB protocol, but when I put that in I got an error that it was an unknown protocol. Device and Path are supposed to be redundant for evdev; I put in the device when I got no device specified errors (approximate wording). I think the real cause was that the default mouse driver was still being preferred. I added the CorePointer option and the Module section to defeat that. It's probably possible to cook up some udev rule to get a more useful and stable name for the input device. There may be one now, but I wasn't sure which it was. The current xorg is advertised as auto-detecting the configuration; clearly that's not quite true in this case. The xorg.conf above probably includes unnecessary directives. The current virtual screen is too big. Can anyone tell me the best way to fix that? -- 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
vnc mouse trouble; -usbdevice tablet no help
I have been unable to get the real mouse and the virtualized mouse to stay together when using kvm with linux host, guest and client. Previous advice (to me and others) was to use -usbdevice tablet. I've tried that, and a variety of kvm/qemu versions, but no luck. Can anyone suggest what to do, or how to diagnose it? vnc and the mouse work OK for Windows XP guests. Host system: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz, 8 cores qemu-kvm 0.12.2, built from source linux 2.6.32-trunk-amd64 (stock Debian kernel) guest linux 2.6.26-2-amd64 Invoked with sudo vdeq bin/qemu-system-x86_64 -net nic,vlan=1,macaddr=52:54:a0:14:01:01 \ -name Lenny BCU Server \ -vga std -vnc localhost:5 -usb -usbdevice tablet \ -net vde,vlan=1,sock=/var/run/vde2/tap0.ctl \ -boot c \ -hda /dev/turtle/Lenny06BCU \ -soundhw es1370 -m 1G -smp 2 I've tried without the -usb; I added it hoping it would help. It didn't. My client has been either the host system or 32 bit linux system. Mostly I've used krdc. All systems basically Debian Lenny, with bits from later releases (e.g., the kernel on the host). -- 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: XP blue screen with qemu-kvm-0.11.0
On Sat, 2009-10-31 at 15:21 +0300, Michael Tokarev wrote: Ross Boylan wrote: My XP VM was working OK, and then started crashing shortly after it logged me in. There were no obvious changes at the time. I built the latest qemu-kvm, but the problem persists. I am running 32 bit XP on Intel(R) Xeon(R) CPU E5420 @ 2.50GHz (8 cores total), Debian GNU/Linux mostly Lenny (amd64), but with some more recent stuff. In particular, the kernel is 2.6.30-8 and I pulled in the kernel-headers package to match before building kvm. However, libc6 and libc6-dev are at Lenny's 2.7-18 version. Libc is basically irrelevant here. What matters are the host kernel and kvm version. $ ./XP.sh ++ sudo vdeq bin/qemu-system-x86_64 -net nic,vlan=1,macaddr=52:54:a0:12:01:00 -net vde,vlan=1,sock=/var/run/vde2/tap0.ctl -boot c -vga std -hda /dev/turtle/XP01 -soundhw es1370 -localtime -m 1G -smp 2 arg ,vlan=1,sock=/var/run/vde2/tap0.ctl TUNGETIFF ioctl() failed: Invalid argument TUNSETOFFLOAD ioctl() failed: Bad address oss: Could not initialize DAC oss: Failed to open `/dev/dsp' oss: Reason: Device or resource busy oss: Could not initialize DAC oss: Failed to open `/dev/dsp' oss: Reason: Device or resource busy audio: Failed to create voice `es1370.dac2' # and more sound-related complaints Switch to alsa to get your audio working. I don't see an alsa option for kvm/qemu. I'm already running alsa, but under KDE which tends to grab the device. The VM starts; I see the initial XP screen with the 4 colors; I see the background I get when I log in (it logs me in directly without prompt); and then (pretty fast) I get a blue screen. The stop code is 0x8E, and the text says to check disk space and BIOS options. What's the bios files your kvm uses? Are they by a change from some old qemu install? They appear to be from the latest install, since strace shows various bios files loading from /usr/local/kvm/share. The invoking environment was a little different from the real run, since strace vdeq apparently traced vdeq but not kvm calls. So I just ran the kvm bare. Does kvm deb from http://www.corpit.ru/debian/tls/kvm/ expose the same issue? Yes. However, as it fails it left a reverberating sound (fragment of the Windows login tone). I tried starting in safe mode. XP said there was new hardware: the video (-vga std). It could not find a driver on the internet(!? the device was identified as a VGA controller). Then it told me the driver had been installed (after I hit finish). I rebooted in regular mode. This time there was no sound, but the machine failed again with STOP 0x8E (as before). The video appeared to be working throughout this, showing a window that exceeded vanilla VGA resolution. Ross -- 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: XP blue screen with qemu-kvm-0.11.0
On Sat, 2009-10-31 at 15:21 +0300, Michael Tokarev wrote: Ross Boylan wrote: My XP VM was working OK, and then started crashing shortly after it logged me in. There were no obvious changes at the time. I built the latest qemu-kvm, but the problem persists. I am running 32 bit XP on Intel(R) Xeon(R) CPU E5420 @ 2.50GHz (8 cores total), Debian GNU/Linux mostly Lenny (amd64), but with some more recent stuff. In particular, the kernel is 2.6.30-8 and I pulled in the kernel-headers package to match before building kvm. However, libc6 and libc6-dev are at Lenny's 2.7-18 version. Libc is basically irrelevant here. What matters are the host kernel and kvm version. BTW, I do not have libvirt installed. $ ./XP.sh ++ sudo vdeq bin/qemu-system-x86_64 -net nic,vlan=1,macaddr=52:54:a0:12:01:00 -net vde,vlan=1,sock=/var/run/vde2/tap0.ctl -boot c -vga std -hda /dev/turtle/XP01 -soundhw es1370 -localtime -m 1G -smp 2 arg ,vlan=1,sock=/var/run/vde2/tap0.ctl TUNGETIFF ioctl() failed: Invalid argument TUNSETOFFLOAD ioctl() failed: Bad address Are the previous 2 messages significant? Just noise from vdeq? ... The VM starts; I see the initial XP screen with the 4 colors; I see the background I get when I log in (it logs me in directly without prompt); and then (pretty fast) I get a blue screen. The stop code is 0x8E, and the text says to check disk space and BIOS options. What's the bios files your kvm uses? How do I find out? Are they by a change from some old qemu install? Does kvm deb from http://www.corpit.ru/debian/tls/kvm/ expose the same issue? I'll try the next time I'm at the machine (I've also had problems with remote use). -no-kvm-irqchip and -no-kvm-pit make no difference. With -no-kvm I get stop code 0x24 and a suggestion to disable anti-virus, defragmentation, and backup software. This is the one obvious change between the Lenny kvm and the one I just built; with lenny kvm (kvm 72+dfsg-5~lenny3) running with -no-kvm simply seemed to hang forever (I think I waited at least 15 minutes). This disk turtle/XP01 is a read-write snapshot on turtle/XP00. The snapshot looks healthy, with about 50% allocated to the snapshot. The snapshot volume is 10G and the original is 50G. The VM starts fine if I point it to XP00 instead of XP01. Well, that's telling, isn't it? If you change disk image and it works, the problem should be in the disk image... Maybe. As I said, it was working, and I get different errors with --no-kvm. Is there a way I can mount the individual partitions on XP01 to get a look at them? It took a lot of time to create this, so I'm really hoping I can salvage it. P.S. What are the different files in my kvm/bin directory? There's no kvm/bin directory in the source tarball of qemu-kvm-0.11.0. I'm referring to the installation directories: /usr/local/kvm/bin$ ls qemu-img qemu-io qemu-nbd qemu-system-x86_64 Ross -- 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
XP blue screen with qemu-kvm-0.11.0
My XP VM was working OK, and then started crashing shortly after it logged me in. There were no obvious changes at the time. I built the latest qemu-kvm, but the problem persists. I am running 32 bit XP on Intel(R) Xeon(R) CPU E5420 @ 2.50GHz (8 cores total), Debian GNU/Linux mostly Lenny (amd64), but with some more recent stuff. In particular, the kernel is 2.6.30-8 and I pulled in the kernel-headers package to match before building kvm. However, libc6 and libc6-dev are at Lenny's 2.7-18 version. $ ./XP.sh ++ sudo vdeq bin/qemu-system-x86_64 -net nic,vlan=1,macaddr=52:54:a0:12:01:00 -net vde,vlan=1,sock=/var/run/vde2/tap0.ctl -boot c -vga std -hda /dev/turtle/XP01 -soundhw es1370 -localtime -m 1G -smp 2 arg ,vlan=1,sock=/var/run/vde2/tap0.ctl TUNGETIFF ioctl() failed: Invalid argument TUNSETOFFLOAD ioctl() failed: Bad address oss: Could not initialize DAC oss: Failed to open `/dev/dsp' oss: Reason: Device or resource busy oss: Could not initialize DAC oss: Failed to open `/dev/dsp' oss: Reason: Device or resource busy audio: Failed to create voice `es1370.dac2' # and more sound-related complaints The VM starts; I see the initial XP screen with the 4 colors; I see the background I get when I log in (it logs me in directly without prompt); and then (pretty fast) I get a blue screen. The stop code is 0x8E, and the text says to check disk space and BIOS options. -no-kvm-irqchip and -no-kvm-pit make no difference. With -no-kvm I get stop code 0x24 and a suggestion to disable anti-virus, defragmentation, and backup software. This is the one obvious change between the Lenny kvm and the one I just built; with lenny kvm (kvm 72+dfsg-5~lenny3) running with -no-kvm simply seemed to hang forever (I think I waited at least 15 minutes). This disk turtle/XP01 is a read-write snapshot on turtle/XP00. The snapshot looks healthy, with about 50% allocated to the snapshot. The snapshot volume is 10G and the original is 50G. The VM starts fine if I point it to XP00 instead of XP01. Any ideas or suggestions? Ross Boylan P.S. What are the different files in my kvm/bin directory? -- 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 or qemu-kvm?
On Wed, 2009-09-30 at 20:51 -0500, Charles Duffy wrote: Ross Boylan wrote: http://www.linux-kvm.org/page/HOWTO1 says to build kvm I should get the latest kvm-release.tar.gz. http://www.linux-kvm.org/page/Downloads says If you want to use the latest version of KVM kernel modules and supporting userspace, you can download the latest version from http://sourceforge.net/project/showfiles.php?group_id=180599.; That page shows the latest version is qemu-kvm-0.11.0.tar.gz. The most recent kvm-release.tar.gz appears to be for kvm-88. So which file should I start from? If you don't know what you want, you want qemu-kvm, which is based off a stable release of qemu. I'm trying to follow the advice on the bug reporting page to Please use the latest release version of kvm at the time you submit the bug. Ross -- 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 or qemu-kvm?
On Thu, 2009-10-01 at 18:42 +0200, Avi Kivity wrote: On 09/30/2009 04:21 AM, Ross Boylan wrote: http://www.linux-kvm.org/page/HOWTO1 says to build kvm I should get the latest kvm-release.tar.gz. http://www.linux-kvm.org/page/Downloads says If you want to use the latest version of KVM kernel modules and supporting userspace, you can download the latest version from http://sourceforge.net/project/showfiles.php?group_id=180599.; That page shows the latest version is qemu-kvm-0.11.0.tar.gz. The most recent kvm-release.tar.gz appears to be for kvm-88. So which file should I start from? qemu-kvm is the userspace component, kvm-kmod is the kernel component as an external module. 'kvm' is a package containing both. That helps a lot; maybe that info could go up on the bugs or faq page. I couldn't find it (that is, there is info that there are kernel and user space components, but not how these relate to the tar files). In general the best place to start is with the distro provided packages. My distro (Debian) is only at 85, even in unstable. Since it wasn't current, and also the dependencies will have wide effects on my system (which I'm trying to keep at the stable release Lenny), I figured getting the current source and building it myself would be the best move. For other reasons I'm already running a 2.6.30 kernel from Debian, which includes kernel side kvm. So I figure I only need to mess with user space. Ross -- 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
kvm or qemu-kvm?
http://www.linux-kvm.org/page/HOWTO1 says to build kvm I should get the latest kvm-release.tar.gz. http://www.linux-kvm.org/page/Downloads says If you want to use the latest version of KVM kernel modules and supporting userspace, you can download the latest version from http://sourceforge.net/project/showfiles.php?group_id=180599.; That page shows the latest version is qemu-kvm-0.11.0.tar.gz. The most recent kvm-release.tar.gz appears to be for kvm-88. So which file should I start from? Thanks. Ross Boylan -- 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: losing mouse location with vnc
On Sat, 2009-09-12 at 11:48 +0200, Kenni Lund wrote: 2009/9/12 Ross Boylan r...@biostat.ucsf.edu: When I try to use a (Linux) VM via vnc there appear to be two mouse locations at once. One is the pointer displayed on the screen; the other is the shown as a little box by krdc when I select always show local cursor in the krdc menu. It also appears when I use xtightvncviewer. Try using -usbdevice tablet as an argument to the QEMU/KVM executable, it will most likely fix your problem. Thank you for the suggestion. Unfortunately, it doesn't seem to make a difference. Here's how I invoked it: sudo vdeq kvm -net nic,vlan=1,macaddr=52:54:a0:14:01:01 \ -name Lenny BCU Server \ -serial file:kvm.log \ -net vde,vlan=1,sock=/var/run/vde2/tap0.ctl \ -boot c \ -vnc :6 -usbdevice tablet \ -hda /dev/turtle/Lenny06BCU \ -soundhw es1370 -m 1G -smp 2 kvm 72+dfsg-5~lenny2 on a 2.6.26 kernel. Ross -- 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
out of memory error leads to unbootable VM
I had a VM running Linux. While running that SAS installer the kernel ran out of memory and killed the installer. After that, any attempt to run a binary inside the VM produced cannot execute binary file. The log (inside the VM) also showed messages like Buffer I/O error on device hda1, logical block 12243549368. hda1 is 86\% full. I killed the VM and attempted to restart. However, the virtual BIOS says the disk is unrecognizeable. lvscan shows, among other things, inactive Original '/dev/turtle/Lenny00' [5.00 GB] inherit ACTIVE'/dev/turtle/SAS92' [33.00 GB] inherit inactive Snapshot '/dev/turtle/Lenny01SAS' [3.00 GB] inherit The active volume has the installation disk; Lenny01SAS was the disk the VM was using; it is a snapshot of Lenny00. I have not deliberately deactivated either. lvdisplay does not give any indication of COW overflow, though that may be because the volumes are inactive. Only about 11G of SAS92 are in use. The SAS installation docs seem to indicate 1 to 1.5G for a full installation. Although it looks as if I had enough room, I suppose a snapshot overflow could account for the inactive snapshot (and inactive original?). It probably did run out of virtual RAM, since kvm started (inadvertently) with the default RAM. Any ideas what's going on? Thanks. Ross Boylan -- 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: out of memory error leads to unbootable VM
On Tue, 2009-06-02 at 19:27 +0300, Avi Kivity wrote: Ross Boylan wrote: I had a VM running Linux. While running that SAS installer the kernel ran out of memory and killed the installer. After that, any attempt to run a binary inside the VM produced cannot execute binary file. The log (inside the VM) also showed messages like Buffer I/O error on device hda1, logical block 12243549368. hda1 is 86\% full. I killed the VM and attempted to restart. However, the virtual BIOS says the disk is unrecognizeable. lvscan shows, among other things, inactive Original '/dev/turtle/Lenny00' [5.00 GB] inherit ACTIVE'/dev/turtle/SAS92' [33.00 GB] inherit inactive Snapshot '/dev/turtle/Lenny01SAS' [3.00 GB] inherit The active volume has the installation disk; Lenny01SAS was the disk the VM was using; it is a snapshot of Lenny00. I have not deliberately deactivated either. lvdisplay does not give any indication of COW overflow, though that may be because the volumes are inactive. Only about 11G of SAS92 are in use. The SAS installation docs seem to indicate 1 to 1.5G for a full installation. Although it looks as if I had enough room, I suppose a snapshot overflow could account for the inactive snapshot (and inactive original?). It probably did run out of virtual RAM, since kvm started (inadvertently) with the default RAM. Any ideas what's going on? Sounds like a guest bug that caused guest disk corruption. Try with more memory (on new volumes to be sure). Isn't Linux (the guest, running Debian Lenny amd64 dual processor) more robust than that? At any rate, I'll try again. I'm hoping the original (Lenny00) is OK, so there's less I need to rebuild. Ross P.S. Running kvm 72+dfsg-5~lenny1 with a host 2.6.29 kernel. They guest was probably 2.6.26, though it might have been 2.6.29. -- 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: XP smp using a lot of CPU
On Fri, 2009-05-15 at 11:56 -0300, Marcelo Tosatti wrote: Ross, Can you confirm the qemu process CPU consumption is down to acceptable levels if you dont specify -no-acpi? Thanks Simply starting without -no-acpi did not help. I tried to do a Windows XP repair, but seemed to end up nasically doing a reinstall. The system now seems to be hung up. I'm probably going to end up trying a fresh install; I'll report more results when I have them. On Thu, May 14, 2009 at 01:01:11PM -0700, Ross Boylan wrote: On Wed, 2009-05-13 at 09:56 +0300, Avi Kivity wrote: Ross Boylan wrote: I just installed XP into a new VM, specifying -smp 2 for the machine. According to top, it's using nearly 200% of a cpu even when I'm not doing anything. Is this real CPU useage, or just a reporting problem (just as my disk image is big according to ls, but isn't really)? If it's real, is there anything I can do about it? kvm 0.7.2 on Debian Lenny (but 2.6.29 kernel), amd64. Xeon chips; 32 bit version of XP pro installed, now fully patched (including the Windows Genuine Advantage stuff, though I cancelled it when it wanted to run). Task manager in XP shows virtually no CPU useage. Please cc me on responses. I'm guessing Windows uses a pio port to sleep, which kvm doesn't support. Can you provide kvm_stat output? markov:~# kvm_stat -1 efer_reload0 0 exits9921384 566 fpu_reload267970 0 halt_exits 1 0 halt_wakeup3 0 host_state_reload402605017 hypercalls 0 0 insn_emulation 1329455 0 insn_emulation_fail 154 0 invlpg176773 0 io_exits 3818270 0 irq_exits1434046 566 irq_injections326730 0 irq_window164827 0 largepages 0 0 mmio_exits 35892 0 mmu_cache_miss 29760 0 mmu_flooded19908 0 mmu_pde_zapped 15557 0 mmu_pte_updated82088 0 mmu_pte_write 97990 0 mmu_recycled 0 0 mmu_shadow_zapped 43276 0 mmu_unsync 891 0 mmu_unsync_global 0 0 nmi_injections 0 0 nmi_window 0 0 pf_fixed 1231164 0 pf_guest 276083 0 remote_tlb_flush 115606 0 request_irq0 0 request_nmi0 0 signal_exits 5 0 tlb_flush 960198 0 This is with the VM displaying the XP It is now safe to turn off your computer. CPU remains about 200% from kvm. Invoked with sudo vdeq kvm -net nic,vlan=1,macaddr=52:54:a0:12:01:00 \ -net vde,vlan=1,sock=/var/run/vde2/tap0.ctl \ -std-vga -hda XP.raw \ -boot c \ -soundhw es1370 -localtime -no-acpi -m 1G -smp 2 Next I'll trying fiddling with acpi. -- Ross Boylan wk: (415) 514-8146 185 Berry St #5700 r...@biostat.ucsf.edu Dept of Epidemiology and Biostatistics fax: (415) 514-8150 University of California, San Francisco San Francisco, CA 94107-1739 hm: (415) 550-1062 -- 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 -- 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: XP smp using a lot of CPU [SOLVED]
Using ACPI fixes the problem; CPU useage is now quite low. Start line was sudo vdeq kvm -net nic,vlan=1,macaddr=52:54:a0:12:01:00 \ -net vde,vlan=1,sock=/var/run/vde2/tap0.ctl \ -boot d -cdrom /usr/local/backup/XPProSP3.iso \ -std-vga -hda /dev/turtle/XP00 \ -soundhw es1370 -localtime -m 1G -smp 2 I switched to -boot c later. I ended up doing a fresh install; my repair got mucked up and I got the message The requested lookup key was not found in any active activation context when I entered a location into MSIE, including when I tried to run Windows Update. Googling showed this might indicate some permission or file corruption issues. They may have happened during my earlier (virtual) system hang. My experience suggests a theory: if you use SMP with XP (i.e., more than 1 virtual processor) you should enable acpi, i.e., not say -no-acpi. It this is true, the advice to run windows with -no-acpi should probably be updated. It's possible single CPU systems are affected as well. Ross -- 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: XP smp using a lot of CPU
On Thu, 2009-05-14 at 12:19 +0200, Johannes Schlatow wrote: I had a similar problem some weeks ago. Finally I found out that my VM running WinXP was working on a non-acpi system (maybe I started kvm with -no-acpi option during the installation). In the Device Manager there has to be the entry Computer-ACPI Multiprocessor PC. Otherwise the VM produced 100% real cpu load on my machines (the fans were running on highest speed level). I just started the WinXP installation in repair mode and this did fix the problem. I hope this helps! regards Johannes That may be it: I was running with -no-acpi. Various docs recommended this for Windows performance, but your comment reminded me that acpi is (I think) required for multiprocessors. I'll be in where I can check on this later today. Thanks. Ross On Wed, May 13, 2009 at 2:41 AM, Ross Boylan r...@biostat.ucsf.edu wrote: I just installed XP into a new VM, specifying -smp 2 for the machine. According to top, it's using nearly 200% of a cpu even when I'm not doing anything. Is this real CPU useage, or just a reporting problem (just as my disk image is big according to ls, but isn't really)? If it's real, is there anything I can do about it? kvm 0.7.2 on Debian Lenny (but 2.6.29 kernel), amd64. Xeon chips; 32 bit version of XP pro installed, now fully patched (including the Windows Genuine Advantage stuff, though I cancelled it when it wanted to run). Task manager in XP shows virtually no CPU useage. Please cc me on responses. Thanks for any assistance. -- Ross Boylan wk: (415) 514-8146 185 Berry St #5700 r...@biostat.ucsf.edu Dept of Epidemiology and Biostatistics fax: (415) 514-8150 University of California, San Francisco San Francisco, CA 94107-1739 hm: (415) 550-1062 -- 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 -- 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: XP smp using a lot of CPU
On Wed, 2009-05-13 at 09:56 +0300, Avi Kivity wrote: Ross Boylan wrote: I just installed XP into a new VM, specifying -smp 2 for the machine. According to top, it's using nearly 200% of a cpu even when I'm not doing anything. Is this real CPU useage, or just a reporting problem (just as my disk image is big according to ls, but isn't really)? If it's real, is there anything I can do about it? kvm 0.7.2 on Debian Lenny (but 2.6.29 kernel), amd64. Xeon chips; 32 bit version of XP pro installed, now fully patched (including the Windows Genuine Advantage stuff, though I cancelled it when it wanted to run). Task manager in XP shows virtually no CPU useage. Please cc me on responses. I'm guessing Windows uses a pio port to sleep, which kvm doesn't support. Can you provide kvm_stat output? markov:~# kvm_stat -1 efer_reload0 0 exits9921384 566 fpu_reload267970 0 halt_exits 1 0 halt_wakeup3 0 host_state_reload402605017 hypercalls 0 0 insn_emulation 1329455 0 insn_emulation_fail 154 0 invlpg176773 0 io_exits 3818270 0 irq_exits1434046 566 irq_injections326730 0 irq_window164827 0 largepages 0 0 mmio_exits 35892 0 mmu_cache_miss 29760 0 mmu_flooded19908 0 mmu_pde_zapped 15557 0 mmu_pte_updated82088 0 mmu_pte_write 97990 0 mmu_recycled 0 0 mmu_shadow_zapped 43276 0 mmu_unsync 891 0 mmu_unsync_global 0 0 nmi_injections 0 0 nmi_window 0 0 pf_fixed 1231164 0 pf_guest 276083 0 remote_tlb_flush 115606 0 request_irq0 0 request_nmi0 0 signal_exits 5 0 tlb_flush 960198 0 This is with the VM displaying the XP It is now safe to turn off your computer. CPU remains about 200% from kvm. Invoked with sudo vdeq kvm -net nic,vlan=1,macaddr=52:54:a0:12:01:00 \ -net vde,vlan=1,sock=/var/run/vde2/tap0.ctl \ -std-vga -hda XP.raw \ -boot c \ -soundhw es1370 -localtime -no-acpi -m 1G -smp 2 Next I'll trying fiddling with acpi. -- Ross Boylan wk: (415) 514-8146 185 Berry St #5700 r...@biostat.ucsf.edu Dept of Epidemiology and Biostatistics fax: (415) 514-8150 University of California, San Francisco San Francisco, CA 94107-1739 hm: (415) 550-1062 -- 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: Best choice for copy/clone/snapshot
Thanks for all the info. I have one follow up. On Wed, 2009-05-13 at 10:07 +0300, Avi Kivity wrote: As I install software onto a system I want to preserve its state--just the disk state---at various points so I can go back. What is the best way to do this? LVM snapshots. Read up on the 'lvcreate -s' command and option. I may have been unclear. I meant as I install software on the VM. Since some of them are running Windows, they can't do LVM. I am running LVM on my host Linux system. Or are you suggesting that I put the image files on a snapshottable partition? Over time the snapshot seems likely to accumulate a lot of original sectors that don't involve the disk image I care about. Or do you mean I should back each virtual disk with an LVM volume? That does seem cleaner; I've just been following the docs and they use regular files. They say I can't just use a raw partition, but maybe kvm-img -f qcow2 /dev/MyVolumeGroup/Volume10 ? Does that give better performance? The one drawback I see is that I'd have to really take the space I wanted, rather than having it only notionally reserved for a file. I'm not sure how growing the logical volume would interact with qcow... Ross -- 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
XP smp using a lot of CPU
I just installed XP into a new VM, specifying -smp 2 for the machine. According to top, it's using nearly 200% of a cpu even when I'm not doing anything. Is this real CPU useage, or just a reporting problem (just as my disk image is big according to ls, but isn't really)? If it's real, is there anything I can do about it? kvm 0.7.2 on Debian Lenny (but 2.6.29 kernel), amd64. Xeon chips; 32 bit version of XP pro installed, now fully patched (including the Windows Genuine Advantage stuff, though I cancelled it when it wanted to run). Task manager in XP shows virtually no CPU useage. Please cc me on responses. Thanks for any assistance. -- Ross Boylan wk: (415) 514-8146 185 Berry St #5700 r...@biostat.ucsf.edu Dept of Epidemiology and Biostatistics fax: (415) 514-8150 University of California, San Francisco San Francisco, CA 94107-1739 hm: (415) 550-1062 -- 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
Best choice for copy/clone/snapshot
First, I have a feeling this might be a question I could ask on a qemu list. Is there a way for me to tell which questions should go where? Is it OK to ask here? As I install software onto a system I want to preserve its state--just the disk state---at various points so I can go back. What is the best way to do this? First, I think I could just make a copy of the virtual disk, although I haven't seen this suggested anywhere. I assume this will work if the VM is off; are there other circumstances in which it is safe? Since my original virtual disk file isn't really occupying its nominal space, I assume this will be true of the copy too. Second, kvm-img could create a copy on write image. There are several things I don't understand about this. Suppose I go kvm-img -b A.img B.img If I then go on and use A.img as I did before, changing what is on disk, have I screwed up B.img? Do A.img or B.img have to be qcow2 format? I created a raw image for portability. Suppose I work for awhile installing new stuff on B.img, and then want to preserve the state. Is kvm-img -b B.img C.img sensible, or is this kind of recursive operation (B.img is already the copy on write version of A.img) not OK? Does ‘commit [-f fmt] filename’, documented as Commit the changes recorded in filename in its base image. mean commit the recorded changes TO its base image? Here are some other things I think I don't want to do. Please let me know if I'm mistaken. -snapshot on the kvm command line: nothing persistent comes of this (maybe if you commit you update the original image, but you don't get 2). snapshot in the monitor: this snapshots the non-disk state of the VM; further, that state is not guaranteed to work if you later change what is on the disk. I think kvm-img snapshot also accesses these facilities. Yours in confusion :) Ross P.S. Please cc me. -- Ross Boylan wk: (415) 514-8146 185 Berry St #5700 r...@biostat.ucsf.edu Dept of Epidemiology and Biostatistics fax: (415) 514-8150 University of California, San Francisco San Francisco, CA 94107-1739 hm: (415) 550-1062 -- 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
bridges
I'm trying to understand bridging with KVM, but am still puzzled. I think that the recommended bridging with TAP means that packets from the VM will end up going out the host card attached to the default gateway. But it looks to me as if their IP address is unchanged, which means replies will never reach me. Is that correct? Do I need to NAT the packets, or is something already doing that? Some documents indicate that I need to bring the interfaces (e.g., eth0) down before I bring the bridge up, and that afterwards only the bridge will have an IP address. Is that right? Some documents, e.g., http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html, indicate iptables should just work with bridging. However, I've seen someone with a 2.6.15 kernel ask about firewalling and be told they needed to patch the kernel to get it work (don't have the reference handy). Should it just work? I'm running a 2.6.29 kernel on Debian Lenny with kvm 72+dfsg-5~lenny1. Version 84+dfsg-2 is available in experimental. Is there much to be gained by going with the more recent version? Please cc me; I'm not on the list. Thanks. Ross Boylan -- 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: bridges
On Thu, 2009-05-07 at 11:13 -0600, Cam Macdonell wrote: Ross Boylan wrote: I'm trying to understand bridging with KVM, but am still puzzled. I think that the recommended bridging with TAP means that packets from the VM will end up going out the host card attached to the default gateway. But it looks to me as if their IP address is unchanged, which means replies will never reach me. Is that correct? Do I need to NAT the packets, or is something already doing that? Hi Ross, This is the place to start http://www.linux-kvm.org/page/Networking. I saw that; it gives some recipes but I wasn't sure what their effect was. You want a public bridge. I'm not sure what their and me mean in your email. In short, with bridging each VM has its own IP and that VM can be accessed directly from the network. their = the VM. me = my host machine. So if the VM's are running on their own subnet, e.g., 10.0.2.* (I've been assuming the subnet with TAP is like the one with the User Mode Network stack in 3.7.3 of http://www.nongnu.org/qemu/qemu-doc.html) and my host machine is on another net, e.g., 10.0.8.* then I think the packet will go out with an IP of 10.0.2.2 (say). When some other machine tries to reply to 10.0.2.2, the packet gets lost because the outside network thinks 10.0.2.* is not for it. At least that's my concern. If the return IP address on the packet were 10.0.8.44 (supposing that's the IP of my host machine) then the packets could find their way back. My host machine is on an internal network with a 10.* IP. The example might be clearer if one supposed that the VM's were on a 192.168.* network. I am perhaps being influenced by the fact that I don't want to ask for more IP's, so I don't want to configure the VM's to use an IP on our 10.0.8 network. Does the TAP networking setup a whole subnet like the user mode network stack (e.g., running a DHCP server), or is the idea that I would just give the VM an IP on my subnet (10.0.8.*) in this example? If the latter is the case (I'm now suspecting it is) then I think the solution is clear. I just stick the VM's on a private (to my machine) subnet, like 192.168.*, and I do NAT on the packets as they go out. -- 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
