Re: I/O scheduling on block devices
On Tue, Dec 18, 2012 at 4:41 PM, Andrew Holway wrote: > How should I set up io scheduling with this configuration. Performance is not > so great and I have a feeling that all of the io schedulers in my VMs and the > ones on my host are not having a nice party together. most external storage units do their own io scheduling with sizeable amounts of buffers and cache, so any optimization done by the hosts would be nullified before reaching the media. also, a scheduler in each host ignores what's happening on the other hosts, so their worldview is incomplete at best. therefore, the best you could aim is to minimize latency; that is, send each command out to the storage ASAP and let it sort it out. for that, usually the best is to use the 'noop' scheduler. -- Javier -- 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: [User Question] How to create a backup of an LVM based maschine without wasting space
On Sat, Oct 13, 2012 at 5:25 PM, Lukas Laukamp wrote: > I have backed up the data within the machine with partimage and fsarchiver. > But it would be greate to have a better way than doing this over a live > system. make no mistake, the absolutely best way is from within the VM. It's the most consistent, safe and efficient method. Doing it "from the outside" is attractive, but it's a hack, and in some cases you have to jump through several hoops to make it safe. -- Javier -- 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: [User Question] How to create a backup of an LVM based maschine without wasting space
On Fri, Oct 12, 2012 at 3:56 PM, Lukas Laukamp wrote: > I think that it must be possible to create an image with a size like the > used space + a few hundret MB with metadata or something like that. the 'best' way to do it is 'from within' the VM the typical workaround is to mount/fsck a LVM snapshot (don't skip the fsck, or at least a journal replay) beyond that, there are a few utilities for specific filesystems: PartImage [1], dump/restore [2], and i'm sure some others. I don't know how would these behave with unclean images, which is what you get if you pull the image under the VM's feet. [1] http://www.partimage.org/Main_Page [2] http://dump.sourceforge.net/ -- Javier -- 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: [User Question] How to create a backup of an LVM based maschine without wasting space
On Fri, Oct 12, 2012 at 9:25 AM, Stefan Hajnoczi wrote: > I would leave them raw as long as they are sparse (zero regions do not > take up space). If you need to copy them you can either convert to > qcow2 or use tools that preserve sparseness (BTW compression tools are > good at this). note that free blocks previously used by deleted files won't be sparse, won't be zero and won't be much reduced by compression. i'd say the usual advice stays: A: if you run any non-trivial application on that VM, then use a real network backup tool 'from the inside' of the VM B: if real point-in-time application-cache-storage consistency is not important, then you can: - make a read-write LVM snapshot - mount that and fsck. (it will appear as not-cleanly unmounted) - backup the files. (i like rsync, especially if you have an uncompressed previous backup) - umount and destroy the snapshot - optionally compress the backup but seriously consider option A before. especially important if you run any DB on that VM -- Javier -- 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: [Question] Live migration -> normal process migration
On Tue, Oct 9, 2012 at 9:36 AM, Grzegorz Dwornicki wrote: > I have a question to you guys. Is it possible to use code from live > migration of KVM VMs to migrate other process? As far as I can tell, no. most of the virtualization facililites of KVM are implemented in the kernel, but they're managed by a 'normal' process (sometimes called qemu-kvm, sometimes just kvm). Is this userspace process that implements it's own migration feature. to do that, one running qemu-kvm (proc A) instance connects with a just-started instance (proc B). proc A first sends all the configuration information, so B sets itself identically. then all RAM data is transferred (iteratively, to 'catch up' with the still-running VM). finally, proc A suspends the running VM, finishes the last modified RAM data and all the CPU state. now proc B is identical to A, and both are suspended, and then, proc B is unsuspended and notifies proc A, which just exits. if you want to do that for arbitrary 'normal' processes, you'd have to implement that in the kernel; but KVM doesn't do that. As Paolo mentions, there are other projects that do similar things. OpenVZ is one; LXC does it too. I'd start with LXC, since it's a standard part of the kernel (just like KVM), and supported by many common utilities. -- Javier -- 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- 1CPU for guest while more cores used on host?
On Wed, Jul 4, 2012 at 2:44 PM, wrote: > Thank you very much for your explanation, it makes sense :-) > >>2: why do you think "course amd-v+KVM is impossible to be used" ?? it does >>work very well > Not for me, it is some old RedHat version that fails on boot under KVM, but > works well (but slow) under Qemu. It is even unable to use more cores, so the > limit in this case is one-core per guest for me. 1: kvm does work, and very well on AMD chips. "of course amd-v+KVM is impossible to be used" is plain wrong 2: if an old OS doesn't work under kvm, but does under qemu, then you can fiddle with kvm's cpu emulation flags. try "kvm -cpu ?" to see what's available. -- Javier -- 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- 1CPU for guest while more cores used on host?
1: no. what you're asking can't be done. if it was possible, every chipmaker would implement it in silicon to create über-fast single-processors on top of multicore chips. 2: why do you think "course amd-v+KVM is impossible to be used" ?? it does work very well -- Javier -- 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: Credit-based scheduling in KVM?
On Fri, Jun 15, 2012 at 6:39 AM, sguazt wrote: > With "native" I meant that I'd like to have a credit-based scheduling > mechanism specifically targeted to VMs, without affecting the other > processes of the host machine. just put the VMs on their own cgroup -- Javier -- 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: Credit-based scheduling in KVM?
On Fri, Jun 15, 2012 at 4:08 AM, sguazt wrote: > I've found some suggestions here: > > http://forums.meulie.net/viewtopic.php?f=43&t=6436 > http://serverfault.com/questions/324265/equivalent-of-xen-capping-in-kvm > > but none of those are native to KVM. what do you mean 'native to KVM'? kvm is part of the Linux kernel, VMs are normal processes, the Linux scheduler is the 'native kvm' scheduler. -- Javier -- 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: Starting / stopping VMs
On Wed, Jun 6, 2012 at 9:57 AM, Michael Johns wrote: > a small > database from which small amounts of information about running > machines which indicated the presence or not of virtual machine > instances. pgrep works beautifully, especially when using the -name option -- Javier -- 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: linux guests and ksm performance
On Thu, Feb 23, 2012 at 11:42 AM, Stefan Hajnoczi wrote: > The other approach is a memory page "discard" mechanism - which > obviously requires more code changes than zeroing freed pages. > > The advantage is that we don't take the brute-force and CPU intensive > approach of zeroing pages. It would be like a fine-grained ballooning > feature. (disclaimer: i don't know the code, i'm just guessing) does KVM emulate the MMU? if so, is there any 'unmap page' primitive? -- Javier -- 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: Infiniband / RDMA
On Fri, Aug 5, 2011 at 2:14 PM, Lance Couture wrote: > We are looking at implementing KVM-based virtual machines in our HPC cluster. > > Our storage runs over Infiniband using RDMA, but we have been unable to find > any real documentation regarding Infiniband, let alone using RDMA. usually it's best to manage storage in the host system, not in the VMs. In that case, it's just a usual Linux setup. Once you get the storage running in your host, KVM will take it, no matter what technology is used underneath. If, on the other hand, you do use Infiniband for some applications _inside_ the VMs, then you would need to pass the PCI devices to the VMs, a totally different issue; and one I don't know about. -- Javier -- 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, iSCSI and High Availability
On Mon, Mar 28, 2011 at 3:31 PM, Marcin M. Jessa wrote: > How is OCFS2 compared to CLVM? different layers, can't compare. CLVM (aka cLVM) is the cluster version of LVM, the volume manager. the addition of a userspace lock manager lets you do all volume management (create/delete volumes, resize them, add/remove physical devices, etc.) online on any machine and all others will see the change. since locks are only needed while modifying the volume layout, there's no overhead during normal operation. OCFS2 is a filesystem. specifically, a Cluster filesystem. that means that the same storage can be mounted by several machines and all of them will see the same data consistently. distributed locks are needed for any modification, and cache strategies have to be complex and tied to such locks. scalability is good, since there's no central node; but ultimately limited to the lock performance. Usually you store cluster filesystems on cluster volumes on cluster storage. -- Javier -- 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: recommended timer frequency for host and guest
On Tue, Mar 1, 2011 at 4:44 PM, Nikola Ciprich wrote: > I guess that on host, the higher frequency can be better, but for guest, > 100HZ should be better because it causes lower overhead for host, right? or NO_HZ? -- Javier -- 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: Disk activity issue...
On Tue, Jan 4, 2011 at 11:19 AM, Erich Weiler wrote: > Thanks for replying! I was able to figure it out - it was not the fault of > KVM. One of the guests was running ganglia gmetad which was updating 30,000+ > rrd files every 15 seconds (thus generating load via disk I/O), I didn't spot > that until shutting down the VMs one by one until I found the offending one. > It was just a needle in a haystack. ;) i use iotop to check which VM is hitting the disk -- Javier -- 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: limit conectivity of a VM
On Sat, Nov 20, 2010 at 3:40 AM, Thomas Mueller wrote: > maybe one of the virtual network cards is 10mbit? start kvm with "-net > nic,model=?" to get a list. wouldn't matter. different models emulate the hardware registers used to transmit, not the performance. if you had infinitely fast processors, every virtual network would be infinitely fast. -- Javier -- 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: limit conectivity of a VM
On Fri, Nov 19, 2010 at 2:47 PM, hadi golestani wrote: > Hello, > I need to limit the port speed of a VM to 10 mbps ( or 5 mbps if it's > possible). > What's the way of doing so? tc check http://lartc.org/howto/lartc.qdisc.html -- Javier -- 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: ESXi, KVM or Xen?
On Fri, Jul 2, 2010 at 10:55 PM, Emmanuel Noobadmin wrote: > This is a concern since I plan to put storage on the network and the > most heavy load the client has is basically the email server due to > the volume plus inline antivirus and anti-spam scanning to be done on > those emails. Admittedly, they won't be seeing as much emails as say a > webhost but most of their emails come with relatively large > attachments. if by 'put storage on the network' you mean using a block-level protocol (iSCSI, FCoE, AoE, NBD, DRBD...), then you should by all means initiate on the host OS (Dom0 in Xen) and present to the VM as if it were local storage. it's far faster and more stable that way. in that case, storage wouldn't add to the VM's network load, which might or might not make those (old) scenarios irrelevant > 2. Security > Some sites point out that KVM VM runs in userspace as threads. So a > compromised guest OS would then give intruder access to the system as > well as other VMs. in any case, if your base OS (host on KVM, Dom0 on Xen) is compromised, it's game over. also, KVM is not 'userspace threads', they're processes as far as the scheduler is concerned, and their ram mapping is managed as a separate process space. no more no less separation than usual among processes on a server. of course, the guest processes are isolated inside that VM and there's no way out of there (unless there's a security bug, which are few and far between given the hardware-assisted virtualization) in any case, yes; Xen does have more maturity on big hosting deployments. but most third parties are betting on KVM for the future. the biggest examples are Redhat, Canonical, libvirt (which is sponsored by redhat), and Eucalyptus (which reimplements amazon's EC2 with either Xen or KVM, focusing on the last) so the gap is closing. regarding performance, KVM is still somewhat behind; but the design is cleaner and more scalable (don't believe too much on 'type 1 vs type 2' hype, most people invoking that don' really understand the issues). the evolving virtio backends have a lot of promise, and periodically there are proof of concept tests that blow out of the water everything else. and finally, even if right now the 'best' deployment on Xen definitely outperforms KVM by a measurable margin; when things are not optimal Xen degrades a lot quicker than KVM. in part because the Xen core scheduler is far from the maturity of Linux kernel's scheduler. -- Javier -- 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: Graphical virtualisation management system
On Thu, Jun 24, 2010 at 1:32 PM, Freddie Cash wrote: > * virt-manager which requires X and seems to be more desktop-oriented; don't know about the others, but virt-manager runs only on the admin station. on the VM hosts you run only libvirtd, which doesn't need X in fact, that's what you get when you install Ubuntu server and choose 'VM host'. about the storage servers, i don't know if they manage them, as i simply add PVs to the VG, and libvirt handles from there. it doesn't care about the type of block devices. -- Javier -- 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: Networking - Static NATs
On Mon, Apr 26, 2010 at 7:10 AM, Anthony Davis wrote: > the problem I have is that kvm currently has dhcp running and setting up > NATs etc... > > I need to stop this, but still allow my current virtual machines access out, > how would be the best way to do this? use bridged networking -- Javier -- 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] [GSoC 2010] Pass-through filesystem support.
On Sat, Apr 10, 2010 at 7:42 AM, Mohammed Gamal wrote: > On Sat, Apr 10, 2010 at 2:12 PM, Jamie Lokier wrote: >> To throw a spanner in, the most widely supported filesystem across >> operating systems is probably NFS, version 2 :-) > > Remember that Windows usage on a VM is not some rare use case, and > it'd be a little bit of a pain from a user's perspective to have to > install a third party NFS client for every VM they use. Having > something supported on the VM out of the box is a better option IMO. i don't think virtio-CIFS has any more support out of the box (on any system) than virtio-9P. -- Javier -- 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] [GSoC 2010] Pass-through filesystem support.
On Fri, Apr 9, 2010 at 5:17 PM, Mohammed Gamal wrote: > That's all good and well. The question now is which direction would > the community prefer to go. Would everyone be just happy with > virtio-9p passthrough? Would it support multiple OSs (Windows comes to > mind here)? Or would we eventually need to patch Samba for passthrough > filesystems? found this: http://code.google.com/p/ninefs/ it's a BSD-licensed 9p client for windows i have no idea of how stable / complete / trustable it is; but might be some start -- Javier -- 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 Tue, Mar 23, 2010 at 2:21 PM, Joerg Roedel wrote: > On Tue, Mar 23, 2010 at 06:39:58PM +0200, Avi Kivity wrote: >> So, two users can't have a guest named MyGuest each? What about >> namespace support? There's a lot of work in virtualizing all kernel >> namespaces, you're adding to that. > > This enumeration is a very small and non-intrusive feature. Making it > aware of namespaces is easy too. an outsider's comment: this path leads to a filesystem... which could be a very nice idea. it could have a directory for each VM, with pseudo-files with all the guest's status, and even the memory it's using. perf could simply watch those files. in fact, such a filesystem could be the main userleve/kernel interface. but i'm sure such a layour was considered (and rejected) very early in the KVM design. i don't think there's anything new to make it more desirable than it was back then. -- Javier -- 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 tweak kernel to get the best out of kvm?
On Wed, Mar 10, 2010 at 8:15 AM, Avi Kivity wrote: > 15 guests should fit comfortably, more with ksm running if the workloads are > similar, or if you use ballooning. is there any simple way to get some stats to see how is ksm doing? -- Javier -- 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: which -cpu to use
Piavlo wrote: > Alexander Graf wrote: > > virtio drivers have nothing to do with CPU. > > Yes I mistakenly used the term "viritio drivers" instead of > "paravirtual guest support". So what I wanted to ask is if I build a > guest kernel with paravitual support > will it make the native hardware cpu features available inside the guest > like in Xen kernel? Or paravirtual support is for device drivers only > and has no impact on CPU handling like in Xen? > I thought that KVM (as Xen) is a bare metal hypervisor with regards to > giving access native access to the CPU which have svm or vmx support, > and not just CPU emulation. > I'm confused here - can someone shed some light on my ignorance on the > matter? you're mixing several buzzwords: - paravirtual/fully virtualized guest: this refers as to how the guest runs in terms of the lowest level of hardware, mainly about accessing CPU's ring0, the most privileged mode of execution. paravirtualized guests can't access ring0, so can't do some very low level CPU operations. for this, the guest is modified to use some hypervisor calls instead of CPU operations. since the guest OS has to be modified, usually the VM system doesn't bother fully emulating IO hardware either. Xen works in either mode, KVM only works in 'fully virtualized' mode, using HVM capabilities. - paravirtualized drivers: usually paravirtualized guests (which KVM doesn't do) also have some special IO channels, which are faster than emulating every detail of an existing piece of hardware. but even if you're fully emulating a CPU, there's nothing preventing you from creating special device drivers that know how to access the Hypervisor communication channels to do any IO needed. the advantage is that these drivers are easy to integrate into an oterwise- unmodified OS. that makes it possible to use PV drivers on windows guests, gaining most (if not all) performance advantages of PV guests without access to the guest OS's source code. - virtio: is the IO interface presented to the guest for communicating with the emulator. at least KVM uses it, but i think Xen's interface is similar. there are several virtio clients in current Linux kernels, so if you select virtio network, and block device when launching KVM, a Linux guest gets a big speedup. also available if you install the PV drivers on windows guests (for network, block drivers aren't available yet). - CPU type: this is only how the CPU identifies itself to the guest, and what capabilities it advertises. AFAIK, it doesn't mean any software emulation (á la qemu), or maybe only a few non-performance-sensitive. it's useful mainly to facilitate guest migration between different hosts. if the guest OS sees the same CPU as the host, it might see it changing, and since all modern OSs check the CPU type at bootup to activate different optimised code, changing it while running would make it crash. advertising only the features common to all hosts lets it stay constant no matter how you move the guest around. originally Xen supported migration only between identical hosts, but there's some special features to allow this on some cases. i don't know how complete they're currently. hope that clears the waters a bit. -- Javier -- 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 0/6 v3] PCI: Linux kernel SR-IOV support
On Saturday 27 September 2008, Zhao, Yu wrote: > Greetings, > > Following patches are intended to support SR-IOV capability in the Linux > kernel. With these patches, people can turn a PCI device with the > capability into multiple ones from software perspective, which can benefit > KVM and achieve other purposes such as QoS, security, etc. sounds great, i think some Infiniband HBAs have this capability; they even suggested using on Xen for faster (no hypervisor intervention) communication between DomU's on the same box. (and transparently to out of the box, of course) does it need an IOMMU (VT-d), or the whole magic is done by the PCI device? -- Javier signature.asc Description: This is a digitally signed message part.
Re: How to run KVM on non-X environment
On Tuesday 29 July 2008, Stephen Liu wrote: > # kvm -hda ubuntu6.06.img -cdrom /dev/scd0 -m 512 -boot d -vnc :1 > > It was hanging there. it's not a hang. it's running, but all feedback goes to the VNC port. maybe you'd like it to run in the background, so you get the prompt back. just add a '&' at the end: kvm -hda ubuntu6.06.img -cdrom /dev/scd0 -m 512 -boot d -vnc :1 & > On local desktop Xterm after ssh-connect the server; > > # netstat -antp > Active Internet connections (servers and established) > Proto Recv-Q Send-Q Local Address Foreign Address > State PID/Program name > tcp0 0 0.0.0.0:59010.0.0.0:* > LISTEN 5682/kvm > tcp0 0 192.168.122.1:530.0.0.0:* > LISTEN 5100/dnsmasq > tcp6 0 0 :::22 :::* > LISTEN 5561/sshd > tcp6 0 0 192.168.0.110:22192.168.0.36:45338 > ESTABLISHED 5566/0 > > > Is the VM running? yes, and port 5901 is VNC's port 1 (since you used -vnc :1) you do need a VNC client. it would be the 'screen and keyboard' of the virtual machine. you need at least that to install an OS. after that, you could setup any kind of network access you like directly to the VM (ssh, X, RDP, etc) -- Javier signature.asc Description: This is a digitally signed message part.
Re: qemu-send.c (was Re: Since we're sharing, here's my kvmctl script)
On Wednesday 11 June 2008, Chris Webb wrote: > Hi. I have a small 'qemu-send' utility for talking to a running qemu/kvm > process whose monitor console listens on a filesystem socket, which I think > might be a useful building block when extending these kinds of script to do > things like migratation, pausing, and so on. The source is attached. there's a utility called socat that let's you send text to/from TCP sockets and unix-domain sockets. it can even (temporarily) attach the terminal, or use GNU's readline to regain interactive control of KVM/Qemu -- Javier signature.asc Description: This is a digitally signed message part.
Re: Since we're sharing, here's my kvmctl script
On Wednesday 11 June 2008, Freddie Cash wrote: > The script can be run as a normal user, as it will use sudo where > needed. However, this causes all the VMs to be run as root (this is > developed on Debian where they've added that annoying "feature" of not > being able to create/use tun/tap devices as non-root users). If > anyone knows how to unbreak Debian to allow non-root users to create > tun/tap devices, I'm all ears. change the group, owner, and/or privileges of /dev/net/tun, usually maneged by udev -- Javier signature.asc Description: This is a digitally signed message part.
