How well does KVM connect a physical drive to the VM?
I have a program which I need to run against a pile of drives. The program needs to boot to a dedicated machine and will only do one drive at a time, and I only have one machine I can tie up to use dedicated, making it a very slow process and requiring a manual drive change when the program is done poking in the SMART firmware. I also have a 4 bay eSATA box and an evil thought, I could do this in a VM, many VMs perhaps, if KVM really lets the VM see the drive. I propose to do something like this: qemu-kvm -m 600 -hda /dev/sdi -cdron diskfiddle.iso -boot d Before I try this I'd like an opinion, because while I can hot swap drives in the external enclosure, the enclosure warns against connecting to a powered computer, so I have to take a downtime. Thanks for any educated opinions. -- Bill Davidsen david...@tmr.com We are not out of the woods yet, but we know the direction and have taken the first step. The steps are many, but finite in number, and if we persevere we will reach our destination. -me, 2010 -- 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] KVM: remove redundant NULL tests
Roel Kluin wrote:
kvm_get_exit_data() cannot return a NULL pointer.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
arch/ia64/kvm/kvm_fw.c | 28 +---
1 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/arch/ia64/kvm/kvm_fw.c b/arch/ia64/kvm/kvm_fw.c
index e4b8231..cb548ee 100644
--- a/arch/ia64/kvm/kvm_fw.c
+++ b/arch/ia64/kvm/kvm_fw.c
@@ -75,7 +75,7 @@ static void set_pal_result(struct kvm_vcpu *vcpu,
struct exit_ctl_data *p;
p = kvm_get_exit_data(vcpu);
- if (p p-exit_reason == EXIT_REASON_PAL_CALL) {
+ if (p-exit_reason == EXIT_REASON_PAL_CALL) {
p-u.pal_data.ret = result;
return ;
}
[___etc___]
Clearly the original author thought that there was a path where kvm_exit_data
could return a NULL pointer, was that ever possible?
--
Bill Davidsen david...@tmr.com
We have more to fear from the bungling of the incompetent than from
the machinations of the wicked. - from Slashdot
--
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 + virt-manager: which is the perfect host Linux distro?
Evert wrote: Hi all, I am about to install a new host system, which will be hosting various guest systems by means of KVM virt-manager for GUI. What would be the best choice for host OS distro? Red Hat, or will any mature Linux distro do? Personally I am more of a Gentoo guy, but if there is 1 distro which is clearly better as host OS when it comes to KVM+virt-manager, I am willing to use something else... ;-) Fedora supports KVM and virt-manager nicely. I can't say it's the best, only that it works solidly. -- Bill Davidsen david...@tmr.com We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- 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 binary names
Daniel P. Berrange wrote: On Fri, Mar 20, 2009 at 10:57:50AM -0700, jd wrote: Hi What is the motivation for having different kvm binary names on various linux distributions.. ? -- kvm -- qemu-system-x86_84 -- qemu-kvm I can tell you the history from the Fedora POV at least... We already had 'qemu', 'qemu-system-x86_64', etc from the existing plain qemu emulator RPMs we distributed. The KVM makefile creates a binary call qemu-system-x86_64 but this clashes with the existing QEMU RPM, so we had to rename it somehow to allow parallel installation of KVM and QEMU RPMs. KVM already ships with a python script called 'kvm' and we didn't want to clash with that either, so we eventually settled on calling it 'qemu-kvm'. Other distros didn't worry about clash with the python script so called their binary just 'kvm' Don't stop there, why does Fedora have both qemu-ppc and qemu-system-ppc and so forth? There are many of these, arm and m68k for instance. On x86 I assume that they are both emulated, and they are not two names for the same executable or such, so what are they and how to choose which to use? -- Bill Davidsen david...@tmr.com We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- 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: More vcd info wanted
Ryan Harper wrote:
* Bill Davidsen david...@tmr.com [2009-03-30 15:51]:
I am looking for detailed information or a single reproducible example of
starting a VM using the qemu-kvm command from a script under Linux (and a
display script on a control host, obviously). What software needs to be
installed and running on the host, and what needs to be on the remote
accessing display.
Please: this is not a question about doing something else using some other
method, I need to be able to drop a disk image and a few parameters into a
KVM host and start it in such a way that there is not human intervention
nor previous preparation such as virt-manager or similar.
I run desktops and servers under KVM using both command line start and
managers, I just keep running into documentation which tells me to use a
vnc specifier without explanation of what that might look like or a
single reproducible example of same.
-vnc localhost:1 -- will display the guest VGA display on the localhost.
A remote system can do:
vncviewer ${kvmhost}:1
to view the guest VGA.
Thanks, will try later tonight. Have to have a bit of care getting the number
right (unique) since there might be more than one of these, but this may be all
I need.
The host will be given a disk image and some parameters such as MAC address
and memory size, and the machine which will have the display. That's my
starting point, KVM host info will be used to start the viewer on another
machine.
--
Bill Davidsen david...@tmr.com
We have more to fear from the bungling of the incompetent than from
the machinations of the wicked. - from Slashdot
--
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: Setting disk parameters in a VM
Avi Kivity wrote: Bill Davidsen wrote: Based on a discussion in another list on ioschedulers, I added a few lines to my rc.local to set the scheduler to noop for disks with model QEMU*, to the scheduling in the VM will not be computing with the scheduling in the host. I wonder if the same thinking applies to the rotational feature added to /sys/block in 2.6.29, intended for SSD but probably appropriate for virtual and nbd devices as well. A virtual disk backed by a rotational physical disk probably should be marked rotational, at least with cache=off. The question was more regarding virtual drives backed by files, but even so I would think the bad case would be to let the host decide what methods should be used, rather than the VM, which is more likely to do things wrong based on incomplete information. Feel free to clarify if you think there's a case where the VM and the host should both be doing caching and scheduling. The only one I can imagine is if a USB port is passed to the VM and it has a storage device attached. That's not really a common configuration, I would guess. -- Bill Davidsen david...@tmr.com Woe unto the statesman who makes war without a reason that will still be valid when the war is over... Otto von Bismark -- 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-10 install hang
Farkas Levente wrote: hi, with kvm-83 on a - host: - Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz - Intel S3000AHV - 8GB RAM - CentOS-5.2 - kernel-2.6.18-92.1.22.el5 x86_64 64bit fedora-10 i386 install hang at : - detecting hardware... waiting for haedware to initialize... - Two things to try, run kvm qith the -std-vga option, and/or start the install with vga set to a reasonable resolution like 0x318. -- Bill Davidsen david...@tmr.com We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- 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 can't install Windows
I need a Win98SE VM to do some software testing and support. Unfortunately KVM seems to not be able to run 98SE, although it runs a bunch of more recent Windows versions I can't use for this. I really don't want to support multiple VM servers, and there is pressure to go to VISTA and VMware. Base is a small server with Intel quad core 2.66GHz CPU, 8GB memory, and 2TB SATA. FC9, fully patched, 32 bit PATA kernel. Running some FC4, CentOS, and DragonFly machines for various services. Someone have a pointer to some docs or something? -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- 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: [PATH] kvm-72 - fix compilation on 2.6.26 (anon_inode_getfd flag)
Nikola Ciprich wrote:
Hi,
anon_inode_getfd flag parameter was added after 2.6.26
following patch fixes compilation
please apply
thanks
nik
diff -Naur kvm-72/kernel/anon_inodes.c
kvm-72-fix-2.6.26-anon-inode/kernel/anon_inodes.c
--- kvm-72/kernel/anon_inodes.c 2008-07-27 12:08:56.0 +0200
+++ kvm-72-fix-2.6.26-anon-inode/kernel/anon_inodes.c 2008-07-29
10:36:51.0 +0200
@@ -245,6 +245,15 @@
return fd;
}
+#elif LINUX_VERSION_CODE == KERNEL_VERSION(2,6,26)
Should that be = for future use?
+
+int kvm_anon_inode_getfd(const char *name,
+const struct file_operations *fops,
+void *priv, int flags)
+{
+ return anon_inode_getfd(name, fops, priv);
+}
+
#else
int kvm_anon_inode_getfd(const char *name,
--
Bill Davidsen [EMAIL PROTECTED]
We have more to fear from the bungling of the incompetent than from
the machinations of the wicked. - from Slashdot
--
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: [PATCH 0/9][RFC] KVM virtio_net performance
Avi Kivity wrote:
Bill Davidsen wrote:
Anthony Liguori wrote:
Hi Mark,
[...snip...]
I'm still seeing the same problem I saw with my patch series.
Namely, dhclient fails to get a DHCP address. Rusty noticed that RX
has a lot more packets received then it should so we're suspicious
that we're getting packet corruption.
I have been discussing this (on this list) in another thread. Putting
tcpdump on the eth0 device in the VM, the br0 device in the host, and
the eth0 (physical NIC) in the host, you can see that when the VM
generates a DHCP request it shows up on the br0 in the host, but
never gets sent on the wire by eth0.
That's the point of failure, at least using RHEL5/FC6/kvm-66 as the
environment.
Does playing with the bridge forward delay ('brctl setfd') help?
Not obviously, default value is 15, stepping from 10..30 made no
difference. It appears the bridge just doesn't forward DHCP packets. I'm
not an expert on bridge setup, and I don't see an obvious control, so I
will look at the code this afternoon and see if something jumps out at me.
--
Bill Davidsen [EMAIL PROTECTED]
Woe unto the statesman who makes war without a reason that will still
be valid when the war is over... Otto von Bismark
--
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: [PATCH 0/9][RFC] KVM virtio_net performance
Avi Kivity wrote:
Bill Davidsen wrote:
I have been discussing this (on this list) in another thread. Putting
tcpdump on the eth0 device in the VM, the br0 device in the host, and
the eth0 (physical NIC) in the host, you can see that when the VM
generates a DHCP request it shows up on the br0 in the host, but
never gets sent on the wire by eth0.
That's the point of failure, at least using RHEL5/FC6/kvm-66 as the
environment.
Does playing with the bridge forward delay ('brctl setfd') help?
Update: Redhat has a user chain in iptables shared between INPUT and
FORWARD (bad idea) which doesn't pass bootp packets by default. Adding
the following rules to that table solved the DHCP for me.
ACCEPT udp -- anywhere anywhereudp
spt:bootps dpt:bootpc
ACCEPT udp -- anywhere anywhereudp
spt:bootpc dpt:bootps
This seems to solve my problem, I just have to make it part of my start
kvm procedure.
--
Bill Davidsen [EMAIL PROTECTED]
Woe unto the statesman who makes war without a reason that will still
be valid when the war is over... Otto von Bismark
--
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: [PATCH 0/9][RFC] KVM virtio_net performance
Anthony Liguori wrote: Hi Mark, Mark McLoughlin wrote: Hey, Here's a bunch of patches attempting to improve the performance of virtio_net. This is more an RFC rather than a patch submission since, as can be seen below, not all patches actually improve the perfomance measurably. I'm still seeing the same problem I saw with my patch series. Namely, dhclient fails to get a DHCP address. Rusty noticed that RX has a lot more packets received then it should so we're suspicious that we're getting packet corruption. I have been discussing this (on this list) in another thread. Putting tcpdump on the eth0 device in the VM, the br0 device in the host, and the eth0 (physical NIC) in the host, you can see that when the VM generates a DHCP request it shows up on the br0 in the host, but never gets sent on the wire by eth0. That's the point of failure, at least using RHEL5/FC6/kvm-66 as the environment. Configuring the tap device with a static address, here's what I get with iperf: w/o patches: guest-host: 625 Mbits/sec host-guest: 825 Mbits/sec w/patches guest-host: 2.02 Gbits/sec host-guest: 1.89 Gbits/sec guest lo: 4.35 Gbits/sec host lo: 4.36 Gbits/sec This is with KVM GUEST configured FWIW. Regards, Anthony Liguori -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- 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: Simple way of putting a VM on a LAN
Javier Guerra wrote: On Wed, Jul 9, 2008 at 11:28 AM, Bill Davidsen [EMAIL PROTECTED] wrote: A bit of the original problem seems to have been clipped before you read it, or I stated it poorly. i think you're very confused. maybe you got it working the hard way, but it's really simple to do the easy way. Your easy way seems to mean using Debian, other distributions don't have some of the scripts, or they are in different places or do different things. Other thoughts below. first, you have to do some small preparations on the host machine, but nothing difficult. this is what i do on my workstation (kubuntu) so that i can fire up a test VM at any moment's whim: - setup a bridge, and use it as main interface - add a /etc/qemu-ifup script - kvm kernel module - make sure /dev/kvm and /dev/net/tun have the correct privilege access. for the first one, in debian-like systems just use the following in /dev/network/interfaces: That's Debian thing. # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto br0 iface br0 inet static address 172.18.13.66 netmask 255.255.0.0 network 172.18.0.0 broadcast 172.18.255.255 gateway 172.18.0.1 bridge_ports eth0 that makes br0 my main interface, and adds eth0 to it. when i'm not running any VM, it doesn't interfere in any way, except for any utilities that default to eth0... if that were a problem, i could simply rename eth0=peth0 and br0=eth0 (i think the Xen scripts do similar tricks) That's an interesting trick. I don't know of any problems I'm having which require it, but a useful thing to consider. when that's set, /etc/qemu-ifup just have to setup the tun/tap interface and add to the bridge: #!/bin/sh ifconfig $1 0.0.0.0 promisc up brctl addif br0 $1 and that's it! no need to meddle with iptables. note that i don't even set the IP, the VM is connected to the LAN, and it setups it's own IP from inside Not being a trusting person I find that a bridge is an ineffective firewall, but with a bit of trickery that could live on the VM, to the extent it's needed. Now the sets up its own IP is a mystery, since there's no place I have told it what the IP of the machine it replaces might be. I did take the obvious step of setting the macadrs of the tap to that of the NIC in the original machine, but here I find a problem, at boot DHCP is not being used, or perhaps the issue is that some internal kvm DHCP service is being used instead of sending the requests out and letting my server provide the IP (and gateway, and nameservice, and etc). Setting up the IP and routing by hand does result in a working configuration, however, so other than the lack of control from using iptables to forward packets, it works well. If the DHCP worked as expected it would really be easy. hope that helps I thank you for sharing your info, it was a good starting point even though some of the steps were not portable. Well, it provides an easier way to get things working, there's one case where the iptables is still desirable, but that is a corner case for sure. Modulo the DHCP issue it works well, so I can say it did help, although not in the way you expected, I suspect. I'm going to write it up while I can remember what I did and understand my notes. I have a bunch of tcpdump files from the physical NIC (eth0) and the bridge (br0), and wireshark, so I may get some idea of why DHCP isn't working, that would finish the job in most cases. Even if I have to do a bit of manual setup, it's faster than setting up iptables, and acceptably secure as long as the kvm host is at least as secure as the original. -- Bill Davidsen [EMAIL PROTECTED] Woe unto the statesman who makes war without a reason that will still be valid when the war is over... Otto von Bismark -- 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: Simple way of putting a VM on a LAN
Chris Lalancette wrote:
Mike Snitzer wrote:
I've taken to using a bridge (or in virt-manager speak shared
physical device). The 'network-bridge' script (and supporting
xen-network-common.sh and xen-script-common.sh) that are provided with
xen rpms (e.g. xen-3.1.0-13.fc8.x86_64.rpm) make this relatively
painless.
The overall solution is not what I'd call simple but once I've
started the bridge I just defer to libvirtd to abstract away the
complexity associated with exposing each kvm guest to the physical
network.
Yep, exactly. Actually, generally your distribution of choice provides nice
startup scripts to such things; in Fedora, you create an
/etc/sysconfig/network-scripts/ifcfg-eth0 that has a BRIDGE=br0, and an
/etc/sysconfig/network-scripts/ifcfg-br0 that defines the actual bridge with
TYPE=Bridge, and the system will bring up the bridge at bootup and plug your
eth0 into it. I'm sure the other distributions have similar mechanisms.
A bit of the original problem seems to have been clipped before you read
it, or I stated it poorly.
- the problems are immediate, not permanent hosting. So startup
anythings are out, I'd have to put in scripts for every machine I might
ever want to host on every machine capable of hosting.
- I need to bind an IP, unless you can point me to a different bridge
package. If eth0 is x.y.z.10 and I put x.y.z.20 on eth0:1
ifconfig eth0:1 x.y.z.20 up
adding eth0:1 moves the whole NIC to the bridge, and the normal
functions of the machine come to a halt. I'm probably doing something
wrong, currently I'm getting this done by ugly iptables abuse.
I am missing some piece on doing this quickly and selectively, for the
case of dns02 just dropped a cooling fan, we need another server, run
it on your {whatever} machine for a few minutes. These are immediate
and short term, but often done on machines in burn-in state, someone's
desktop, etc. Little load, but the service must be running.
Does that clarify?
--
Bill Davidsen [EMAIL PROTECTED]
We have more to fear from the bungling of the incompetent than from
the machinations of the wicked. - from Slashdot
--
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: KVM: pvmmu breakage with gcc 4.3.0
Anthony Liguori wrote: Avi Kivity wrote: Marcelo Tosatti wrote: Some pvmmu functions store their commands on stack, and newer GCC versions conclude that these commands are unused. So stick an inline asm statement to convince the compiler otherwise. Signed-off-by: Marcelo Tosatti [EMAIL PROTECTED] diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c index 8b7a3cf..c892752 100644 --- a/arch/x86/kernel/kvm.c +++ b/arch/x86/kernel/kvm.c @@ -55,6 +55,12 @@ static void kvm_mmu_op(void *buffer, unsigned len) int r; unsigned long a1, a2; +/* +* GCC 4.3.0 concludes that on-stack kvm_mmu_op* is unused and +* optimizes its initialization away. + */ +asm ( : : p (buffer)); + I don't think p should force the contents into memory? Perhaps m(*(char *)buffer)? Anthony, I don't see why a memory clobber would tell gcc that the variables is actually used. It doesn't, but it seems to me that it should force GCC to assume everything is live. It's a big stick to hit the problem with but it seems like the right thing semantically. In general the right stick to hit a compiler with is 'volatile,' which should tell the compiler that outside forces are in play. Without really digging into the code I don't want to suggest just where this should be used, but clearly Christian had the same thought. The problem is with the void * - unsigned long cast (__pa), once that happens gcc loses track. It's probably needed anyway since hypercalls _do_ clobber memory. Right, it's not telling GCC that we touch a particular variable, but rather that we may have touched any variable. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- 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
