virt

virt@lists.centos.org

1610 discussions

Can I bridge a bonded and vlan tagged interface directly to a guest?
by David Knierim 03 Aug '09

03 Aug '09

I am running CentOS 5.3 x86_64 as my dom0 and CentOS 5.3 on my domU's. On the dom0, I have two interfaces that are bonded and have tagged VLANs. I can get the networks to the domU's by creating a bridge for each of the VLANS (bond0.3, bond0.4, etc). On the domU, the interfaces show up as eth0, eth1, etc. Is there a way to set up the network on the dom0 so my domU's see a single interface with tagged VLAN support?? Thanks! David

3 4

Gilberto Nunes deixou uma mensagem para você no Badoo!
by Badoo 03 Aug '09

03 Aug '09

Você tem uma nova mensagem no Badoo! Gilberto Nunes deixou uma mensagem pra você. Clique no link para abrir: http://us1.badoo.com/01097897898/in/BDGmMoCC9H8/?lang_id=61 E, outras pessoas estiveram procurando por você: Manoel Felipe (Joinville, Brasil)Mara Leal mendes (Joinville, Brasil)Tiago Gabriel (Joinville, Brasil) Se os links desta mensagem não funcionarem, copie e cole os links na barra de navegação do seu browser. Esta é uma mensagem automática. Respostas à esta mensagem não serão lidas ou respondidas. Se não deseja receber outras mensagens, clique aqui: http://us1.badoo.com/impersonation.phtml?lang_id=61&mail_code=21&email=cent…

1 0

Loading default keymap error after a yum update...
by Davide Perini 29 Jul '09

29 Jul '09

Hi, I'm running CentOS 5.3 on a XEN VPS. After I yum update, I've got this error on boot. Press 'I' to enter interactive startup. Cannot access the Hardware Clock via any known method. Use the --debug option to see the details of our search for an access method. Setting clock (utc): Thu Jul 16 18:54:50 CEST 2009 [ OK ] Starting udev: [ OK ] Loading default keymap (us): /etc/rc.d/rc.sysinit: line 396: /dev/tty0: No such file or directory [FAILED] Setting hostname localhost.localdomain: [ OK ] is there a solution to that problem? please help. thanks. Davide.

1 0

ntp on kvm
by Johnny Tan 28 Jul '09

28 Jul '09

We've noticed our fully-virtualized KVM guests' time keeps getting faster, despite running ntpd. A quick google reveals this to be a known problem with virtual guests. It seems there are a variety of solutions, some apparently vendor-specific. What is the best practice as of now for KVM guests? * Setting independent_wallclock=1 (or is that a xen-only thing)? * Passing kernel parameters? If so, which? The vmware KB mentions "notsc divider=10" -- is that vmware-specific? * Just don't run ntpd on virtual guests? And let it get its time from the host. The last seems like the easiest/cleanest, if it really does always get its time from the host. Thanks for any info. johnny

3 3

Installing/running Fedora 10 or Fedora 11 32b Xen domU on CentOS 5.3 x86_64 host/dom0 broken
by Pasi Kärkkäinen 28 Jul '09

28 Jul '09

Hello. Yesterday I tried installing Fedora 10 and Fedora 11 i386 Xen domUs/guests using virt-install and/or virt-manager on CentOS 5.3 Xen x86_64 dom0/host. It doesn't work. The guest kernel crashes early and the graphical VNC console newer shows up. Installing x86_64 domU on x86_64 dom0 work well. 32-on-32 works aswell. So it's a 32-on-64 bug. CentOS 5.3 32b guest on x86_64 host works though, most probably because it uses the "original" Xenlinux patchset. I found the upstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=467698 This problem will be fixed in upcoming RHEL 5.4, and it's also fixed in the latest el5 test kernel-xen (-159). I think this is not really F10 or F11 guest specific, but more likely will happen with any/many upstream (kernel.org) pv_ops Xen domU kernels. -- Pasi

1 0

I/O load distribution
by Dennis J. 27 Jul '09

27 Jul '09

Hi, What is the best way to deal with I/O load when running several VMs on a physical machine with local or remote storage? What I'm primarily worried about is the case when several VMs cause disk I/O at the same time. One example would be the "updatedb" cronjob of the mlocate package. If you have say 5 VMs running on a physical System with a local software raid-1 as storage and the all run updatedb at the same time that causes all of them to run really slowly because the starve each other fighting over the disk. What is the best way to soften the impact of such a situation? Does it make sense to use a hardware raid instead? How would the raid type affect the performance in this case? Would the fact that the I/O load gets distributed across multiple spindles in, say, a 4 disk hardware raid-5 have a big impact on this? I'm currently facing the problem where I fear that random disk I/O by too many VMs on a physical system could cripple their performance even though I have plenty of CPU cores/RAM left to run them. Has anyone experience with this problem and maybe some data to shed some light on this potential bottleneck for virtualization? Regards, Dennis

4 6

Re: [CentOS-virt] I/O load distribution
by Christopher G. Stach II 27 Jul '09

27 Jul '09

----- "Dennis J." <dennisml(a)conversis.de> wrote: > Hi, > What is the best way to deal with I/O load when running several VMs on > a > physical machine with local or remote storage? Fill up on controller cache, add more spindles until you saturate the bus, then start adding more controllers. > What I'm primarily worried about is the case when several VMs cause > disk > I/O at the same time. One example would be the "updatedb" cronjob of > the > mlocate package. If you have say 5 VMs running on a physical System > with a > local software raid-1 as storage and the all run updatedb at the same > time > that causes all of them to run really slowly because the starve each > other > fighting over the disk. Is this updatedb issue your only concern? Does it affect anything important? If it's just annoying, try to ignore it. Like any time sharing system, virtualization is a bet that things like this typically don't happen. > What is the best way to soften the impact of such a situation? Does it > make > sense to use a hardware raid instead? It won't matter that much to change from software to hardware. Arguably, the benefits of software RAID outweigh the negatives. It won't help you one bit in this case. A controller with a battery-backed cache will, though. > How would the raid type affect > the > performance in this case? Would the fact that the I/O load gets > distributed > across multiple spindles in, say, a 4 disk hardware raid-5 have a big > impact on this? It can affect it an awful lot. RAID 5 sucks. Avoid it. A little research will give you all of the reasons why. If you have a random access pattern like you'd typically see in a busy virtualized setup, RAID 10 is your best bet. If you're not heavy on writes, RAID 6 will save you some disk space... but disk is cheap enough to err on the side of unused performance if you don't want to spend the time to benchmark. Proper partitioning can give you back some performance in many cases, too. > I'm currently facing the problem where I fear that random disk I/O by > too > many VMs on a physical system could cripple their performance even > though I > have plenty of CPU cores/RAM left to run them. In most virtualized situations, I've seen it go down like this. In approximately this order, you will run out of... 1. RAM 2. disk I/O 3. CPU 4. network 3 and 4 will be swapped in a lot of cases. Regardless, this is the general order of priorities you should address while spec'ing your hardware or expect while setting your expectations with reappropriated hardware. If you have a two disk RAID 1 and 128GB of RAM and you run write-heavy databases (block device backing stores for anyone aiming to nitpick about OS filesystem cache) in all of the VMs, performance will not be that great. -- Christopher G. Stach II

1 0

The best network to use.
by Rich 27 Jul '09

27 Jul '09

When using a para-virtualized guest, which network type should be used?

3 4

Bridge or para network.
by Rich 25 Jul '09

25 Jul '09

What is the most boust network to use?

2 1

Re: [CentOS-virt] How to pass messages from dom0 to domU??
by Christopher G. Stach II 23 Jul '09

23 Jul '09

----- "R P Herrold" <herrold(a)centos.org> wrote: > The addition of a new private network segment seems like > overkill and needless additional fragility and complexity -- > if one to one, use a remote syslog setup (viz., over UDP); if > one to many (domU), use a multicast sender and listeners. > > Run either on the existing network seqment shared by the domUs > and dom0 already. It's just RAM until you add a physical interface to the bridge, and then it's just Ethernet. It would be difficult to argue that using either is fragile or complex. Even compared against your suggestion, the only difference is isolation, the general rule for administrative networks. If the skill level involved is negative, perhaps if the person is coming from the Device Manager space, maybe the steps of adding a bridge, a vif entry for each VM, and configuring the interface within each VM is way too much to handle. However, IIRC, virtual network bridges are one of the documented Xen use cases and are entry level stuff. The cost and added risk thereof are next to zero. Being that worried about fragility in your basic set of capabilities is silly, unless you have evidence to the contrary. If the messages are used to trigger things like shutdowns, scale back services, or be published in any way that could be dangerous (inadvertently notifying customers/competitors/attackers that your hardware sucks or what your system architecture looks like), you'll need to involve crypto unless you don't care if anyone inside shuts down your VMs. syslogd would not help in this case, but at least SNMP could. -- Christopher G. Stach II

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

virt