virt June 2014

virt@lists.centos.org

38 participants
28 discussions

sorting virtual network interface names with xen
by lee 06 Jun '14

06 Jun '14

Hi, how would I make it so that a particular virtual network interface of dom0 is attached to a particular bridge created for a particular VM? When I start the VM with 'virsh start <domU>', I get interfaces vif1.0, vif1.1 and vif1.2. After shutting down domU with 'virsh shutdown <domU>' and starting it again as before, the virtual network interfaces are vif2.0, vif2.1 and vif2.2. I want them to keep their names so that they would be vif1.[0-2] again. In the end, I want to give them different names, like vif_domU.loc, vif_domU.dmz and vif_domU.mta, which they are supposed to keep consistently. Is it possible to hardcode the interface names in the domain description? Currently, the default script /etc/xen/scripts/vif-bridge is used to create them. And once hardcoded, how do I make it so that the corresponding interfaces in domU have appropriate names like eth_loc, eth_dmz and eth_mta? Generic interface names for all the bridges and interfaces would lead to total confusion in this case because I`d never be able to tell which bridge or interface in dom0 corresponds to what in any of the domUs. -- Knowledge is volatile and fluid. Software is power.

1 0

Open graphics connection with virt-manager problem
by jaumotte, styve 05 Jun '14

05 Jun '14

Hi, Actually, we study virtualization on CentOS with Xen, our goal is to test if the migration of Xen with SLES 11 to CentsOS. Our first tests are ok except for one problem and I don't find any solutions on the net. I hope, you can help me. The problem is that I can't connect to my vm desktop with Virt-Viewer. I follow the installation guide available for centos : http://wiki.centos.org/HowTos/Xen/Xen4QuickStart and http://wiki.centos.org/HowTos/Xen/Xen4QuickStart/Xen4Libvirt My CentOS is a fresh new install 6.5 with xen 4.2 and X11. >From Dom0, when I launch virt-manager, everything is ok. I can create a new vm and the first time I connect to the virtual graphics without any problems. But, if I close the desktop VM, I can't access anymore to the virtual desktop of the VM, it is as if the graphics is freazing.The VM is still alive. What is very strange is that I can connect directly with vnc client on 127.0.0.1 :5900 port. I try to launch virt-manager with " --debug " option, but don't find any interesting errors. I've got the same problem if I remotely launch a virt-manager and connect with xen+ssh from another centos 6.5. But, I can still connect from a virt-manger launched from a Rh7RC or even from a SLES 11.3. I think it becomes from virt-manager or libvirt which come with centos 6.5. I made update and I don't know what's wrong with my CentOS 6.5. Don't find any problems like this with Google ! Thank's for you help. Styve

2 1

qemu-kvm rebuild in Centos for oVirt in SIG Virt
by Douglas Schilling Landgraf 05 Jun '14

05 Jun '14

Hi guys, As we discussed in the last CentOS SIG Virt meeting below the steps that we do to rebuild the qemu-kvm from http://vault.centos.org to enable the rhev-features like live snapshot for CentOS. 1. Download the last qemu-kvm from http://vault.centos.org/${version}/updates/Source/SPackages/ 2. mock -D "${build_version}" -r epel-6-x86_64 --with=rhev-features --rebuild "${WORKSPACE}"/rpms/${qemu_kvm} --resultdir="${WORKSPACE}"/rpms --cleanup-after As you can see we don't bump the release at moment, please let me know your thoughts. If there is any volunteer to take owner of this package in the SIG group please let me know, otherwise I can take it. Here the jenkins URL: http://jenkins.ovirt.org/job/qemu-kvm-rhev_create-rpms_el6/ Thanks! -- Cheers Douglas

3 4

Log from today's IRC meeting (June 3rd, 2014)
by Lars Kurth 04 Jun '14

04 Jun '14

With slight re-ordering to keep related things together <kbsingh> lars_kurth: Hi [13:52] <kbsingh> Are we doing this meeting on irc ? <lars_kurth> kbsingh: yes, we are [13:59] <lars_kurth> gwd: Hi. [14:02] <lars_kurth> Alright. I didn't put an agenda together <gwd> I've got a couple of things I wanted to bring up. [14:04] <gwd> Who else is here for the meeting? <lars_kurth> Please do. I think KB has some too <jonludlam> Hello <lars_kurth> gwd: seems we have jonludlam, kbsingh gwd and me so far [14:05] <lars_kurth> Hi. Before we properly start. Any changes on actions on http://wiki.centos.org/SpecialInterestGroup/Virtualization/Status ? <lars_kurth> So: no changes then? [14:06] <gwd> We chatted at the hackathon (with Daniel Barrange there) about libvirt versions <jonludlam> That was a good session [14:07] <lars_kurth> gwd: what was the outcome/recommendation? <gwd> What we said there was that libvirt/libxl driver isn't yet stable, so there's no point doing a "choose a version and stick with it" thing until it is. <lars_kurth> gwd: that is what I was afraid of [14:08] <jonludlam> so libvirt becomes a 'tech preview' until it stabilises? <gwd> Er, I don't think "tech preview" <jonludlam> 'unstable'? <gwd> More like, "Not enterprise". :-) <jonludlam> ok <pasik> hello [14:09] <jonludlam> hi pasik <gwd> pasik: Hello <gwd> You know, like the kernel we want to be "enterprise" and only update every 2+ years. <lars_kurth> But that is only an issue for libxl, mot xm. Correct? If we are still talking Xen 4.4 that should not be an issue <gwd> I don't think we want to encourage anyone to use xend if we can possibly help it. <gwd> We need to transition people away from it. [14:10] <jonludlam> libvirt is a reasonable transition strategy though <gwd> Is there a need for "enterprise libvirt"? Is anyone using that? <pasik> Hopefully we can get thinks into better shape with xen 4.4 + later libvirt <lars_kurth> Agreed. How about the needs of KVM, oVirt, ... for libvirt <pasik> with the current xen 4.2 packages basicly only xend is usable (with libvirt) <gwd> pasik / euanh: We were just talking about how often to update the libvirt packages. <jonludlam> ovirt will take a good deal of porting to work with xen <lars_kurth> jonludlam: correct. But this SIG is not about Xen only [14:11] <jonludlam> true, but <gwd> jonludlam: given how much hypervisor detail is exposed by libvirt, how reliable would a libvirt/xend -> libvirt/libxl transition go? <jonludlam> What was said was that ovirt effectively doesn't need anything provided by what we're looking at in sig virt today [14:12] <jonludlam> gwd, I don't think it would be too bad - it already autodetects whether to use xl or xm based on what's installed, if you connect to xen:// <gwd> lars_kurth: I think if someone wants to use oVirt+KVM, they can use the core libvirt. <gwd> jonludlam: Sure, but as we found out, libvirt doesn't try very hard to hide the hypervisor details. [14:13] <jonludlam> qemu was mentioned in the meeting at the hackathon, but it's totally orthogonal to everything else in the SIG so far <jonludlam> gwd, but the difference between libxl and xend is much smaller than between qemu and xen <gwd> Sure; but it may still be a fairly major headache to get stuff to work. <lars_kurth> kbsingh: any views? I thought you were worried about scope creep in the SIG. <lars_kurth> Sorry: SIG [14:14] <gwd> And what actually works well with libvirt+xen at the moment anyway? xm/xl are better than virsh, IMHO <lars_kurth> gwd: That is probably correct. On the other hand, we don't have an interface into Cloud SIGs until we have libvirt and/or xapi <jonludlam> the xapi question was a bit clearer after the meetings. Anil and KB talked about an OCaml SIG that the virt SIG could <gwd> lars_kurth: Yes, but those are not going to be enterprisey either. :-) <lars_kurth> gwd: so what is the proposal <gwd> The proprosals are: depend on <gwd> 1) Choose a version of libvirt (1.2.3 maybe) and stick with it, backporting functionality we're missing. [14:16] <gwd> 2) Update the libvirt package when there's a new libvirt release until libxl support is mature enough <pasik> gwd: I use virt-install often to install new VMs <pasik> gwd: imho it's the easiest way to launch $distro installers in a PV domU [14:17] <gwd> #2 is easier for us, and will get us all the available libvirt/xen functionality; it's what we favored at the metting at the hackathon. <pasik> gwd: and virt-install works with xen4.2+xend+libvirt in el6 <gwd> The only downside is that enterprise customers don't like such frequent updates. <jonludlam> Daniel B said that #1 would be tricky, as they were refactoring the other bits of libvirt to make the xl plugin easier [14:18] <DV> We really try to not break libvirt upstream, ideally having the git version run for regtests on libxl would be a good idea <gwd> DV: Upstream Xen Project already does that. <DV> * DV agrees with danpb , even in RHEL we rebase to try to avoid backporting <gwd> Having a new libvirt shouldn't *interfere* with oVirt, virt-install, &c&c. [14:19] <DV> gwd: ah, good, are the result available publicly, if yes then maybe breakages should be reported on libvirt-list! <DV> err libvir-list@ <gwd> DV: Can you mail me about that separately? It's a bit off-topic for the current meeting. :-) [14:20] <DV> gwd: hum, the problem is that there is usually a few RHEL specific patches which used to be carried on libvirt builds <lars_kurth> Related to the libvirt version discussion is http://lists.centos.org/pipermail/centos-virt/2014-May/003832.html <pasik> gwd: and also virt-manager works OK with el6 xen4.2+xend+libvirt <pasik> gwd: for basic VM management operations, and new VM installs <DV> but I think we tried to reduce them as much as possible <pasik> gwd: so maybe that answers your "And what actually works well with libvirt+xen at the moment anyway?" <DV> pasik: ah, good to know ! [14:21] <gwd> Just to be clear: the question is NOT "do we need libvirt". Yes, we absolutely do. <gwd> The question is, "Do we need a super-stable libvirt, or can we just update on new releases for the time being." [14:22] <lars_kurth> Related to that is then: how long would we be on cutting edge libvirt version (by gut feel) <jonludlam> gwd, and, if we are updating to new releases often, is that with a view to converging? <pasik> gwd: well, centos6 is an enterprise stable distro, se people expect things to be (at least semi) stable. <pasik> gwd: we can of course make it clear libvirt will change more often.. [14:23] <gwd> Well let's discuss this on the list. <DV> * DV think within the SIG the rule 'things should be absolutely rock solid' could be relaxed, but only a bit [14:24] <gwd> kbsingh: Actually, that's another question: centos-devel isn't really that high traffic. Would it make sense to have the development discussions held on there? <gwd> OK, so that's going to be taken back to the list. [14:25] <lars_kurth> OK: adding an action <lars_kurth> gwd: are you OK to make a proposal? [14:26] <gwd> That's all the updates I have from the status: we're still waiting for the core CentOS team to get something set up to make contribution easier; there was some discussion of using koji, like Fedora. <gwd> lars_kurth: Yes, I'll do that. <lars_kurth> What next on the agenda? [14:29] <gwd> Did everyone see the Xen Hackathon meeting minutes? Anyone have any questions about that? <lars_kurth> See http://lists.centos.org/pipermail/centos-virt/2014-June/003865.html for meeting minutes <gwd> jonludlam: "...with a view to converging" -- you mean, to stop updating once libvirt+libxl is mature? Yes, that was my idea. [14:30] <jonludlam> yes <gwd> Cool. <jonludlam> although exactly how to define maturity is left unspecified :-) [14:31] <gwd> So I had one quick question for kbsingh -- should I merge my "git am" change into the main CentOS repo on github? Is there anything else that need to get that actually built? <lars_kurth> kbsingh: AYT? [14:32] <gwd> (Or maybe hughesjr ^) <gwd> OK, I think most of what I had really needs kb's input. :-) [14:34] <lars_kurth> gwd: maybe ping kbsingh and/or hughesjr an e-mail (or on-list) <gwd> Related to the "build images" thing -- is there a better way to make images that doesn't require libvirt? [14:35] <lars_kurth> Any other items from http://lists.centos.org/pipermail/centos-virt/2014-June/003865.html that we need to discuss? <gwd> The only tool like that I've ever used is xen-tools, which might be possible, but it would be nicer if there were something that could make images either for Xen or KVM. [14:36] <lars_kurth> It seems it may make sense to track jonludlam about Ocaml SIG and XAPI in the actions <jonludlam> lars_kurth, sure <lars_kurth> jonludlam: can you summarize that discussion briefly? <jonludlam> I'll poke anil :-) <jonludlam> Right: anil & KB discussed creating an OCaml SIG which would take the most recent version of the ocaml compiler: 4.01 [14:37] <jonludlam> RHEL 7 will have 4.00.1 (not recent enough) <jonludlam> SIG virt could then depend upon the OCaml SIG, but crucially, only the OCaml bindings from the sig virt would then depend upon the ocaml sig [14:38] <jonludlam> oxenstore doesn't need any runtime dependence on any ocaml libs <lars_kurth> OK. Makes sense. So the ball is in Anil's court <jonludlam> correct <lars_kurth> gwd, pasik: re xen-tools ... anyone knows whether there is such a thing for Xen and KVM [14:39] <gwd> lars_kurth: I don't understand the question. [14:41] <lars_kurth> gwd: was referring back to xen-tools ... what I meant is whether virt-manager provides the same functionality + more than xen-tools <gwd> lars_kurth: virt-install I think will do that, but it depends on libvirt; which seems to confuse some people. [14:44] <lars_kurth> gwd: re virt-install confusion. If we introduced something else, it is likely it will also confuse people. In any case may be better to rely on documentation [14:45] <gwd> virt-install> But I guess when we add an updated libvirt, then things should work more easily. <jonludlam> lars_kurth, btw, I had another action to send a PR with updated RPM packaging layout as an RFC <gwd> jonludlam: You should be able to d/l the tarballs manually though. <gwd> jonludlam: And I had an action to send you a how-to build the sig-virt-xen repos <jonludlam> yup! [14:42] <lars_kurth> jonludlam: OK, a new one? What is the context? <gwd> jonludlam: But it turns out the binary-download thing isn't ready yet -- KB doesn't want the world spamming his (previously) private ftp server. They're trying to come up with a new system similar to Fedora, but it's not ready yet. [14:43] <jonludlam> gwd, ok - are there many that aren't in the current Xen4CentOS SRPM repo? <gwd> (There was just someone on centos-virt complaining about how hard it was to build an image for Xen4CentOS and the poor documentation.) <jonludlam> lars_kurth, the idea was to try to get the work done by Andy Cooper & co to reorganise the layout of the binary RPMs taken up <lars_kurth> gwd: thank you. Got it [14:46] <lars_kurth> jonludlum: Added the action <lars_kurth> Looks we are running out of steam. Anything else? <gwd> No -- I think following up on the "where do oVirt and xapi go" discussion is the only other thing I had, but we need KB for that. <lars_kurth> OK. Maybe it is better to do this on the next call. It's easier then [14:49] <gwd> OK -- any other business? <lars_kurth> Alright: we are closed then [14:52] <gwd> OK, looks like we're done.

2 2

Why are bridges required?
by lee 04 Jun '14

04 Jun '14

Hi, all the descriptions of networking setups with VMs I`m seeing involve bridges. The only use I see for bridges is when I actually want to be able to send network traffic to multiple arbitrary interfaces connected to the bridge. I do neither need, nor want bridges when I want to keep the VMs separated, like when separating a VM in a DMZ from a VM in the LAN. The bridge acts like a hub. Looking at [1] makes it seem that this is undesirable --- otherwise there wouldn`t be need for a software switch to prevent network traffic on a bridge from going to all of the connected interfaces. When there`s a bridge with multiple VMs connected to it, is a software switch desirable to prevent network traffic on the bridge from going to interfaces it doesn`t need to go to? If so, isn`t it better not to use a bridge to begin with? Can`t we simply have virtual interfaces on the physical host which are the "other end" of the interfaces showing up in the VMs, without bridges? [2] seems to suggest to leave all bridges "dangling", i. e. it says you`re not supposed to connect an interface to the bridge. What`s the point of a bridge when only a single interface is connected to it? [1]: http://openvswitch.org/support/config-cookbooks/vlan-configuration-cookbook/ [2]: http://wiki.libvirt.org/page/Networking -- Knowledge is volatile and fluid. Software is power.

3 3

Re: [CentOS-virt] [Hackathon] CentOS Virt SIG summary
by Lars Kurth 03 Jun '14

03 Jun '14

Adding virt list, which we had missed off by mistake Lars On 03/06/2014 11:13, George Dunlap wrote: > Sorry this is a bit sparse; I was both running the meeting and jotting > down notes. Let me know if you have any questions. > > -George > > Present (from memory): > - George Dunlap > - Anil Madhavapeddy > - Jonathan Ludlam > - David Berrange > - Dan Keningsberg > - Dario Faggioli > - [others I've forgotten] > > > * Agenda > - Package layout > - ocaml > - oVirt? > - libvirt? > - Sorting out check-in stuff > > * ocaml and xapi > - Progess made yesterday in discussion with KB > - RHEL 7 4.0.0.1 > - xapi wants 4.0.1 > - Depend on ocaml for *building* but not for *installing* > > * Packaging > - xenstore client tools useful in domUs mixed in with libraries only > useful in dom0 > - How this would affect people upgrading? > - obsoletes? > - GWD to Mail JonL re virt sig repos > > * Build servers for SIGs? > - koji up and running? > - mock build environment > - send it to Fedora first? > - copr -- lightweight version of koji > > * oVirt > - Must be in a separate repo for dependencies' sake > - building more complicated (java, maven, &c &c) > - Start with just copying RHEV > > * libvirt > - No sense in making it a "stable" at this point > - Use the lastest release until libxl support is fully featured / stabilized

1 0

Xen DomU supoprt in RHEL 7 and the CentOS Plan
by Karanbir Singh 03 Jun '14

03 Jun '14

Hi Guys, so far, in rhel7rc its pretty clear that Xen instances ( domUs ) are not going to boot with the RHEL7rc kernel. Also, i think at this point its a safe bet that these things wont change to GA - no way to accertain that, but its a safe bet ). Wondering if someone has looked into what the challenges might be to enable this support, and then what the options are to deliver this support ? If we can get the stuff staged up, we can work it during the Distro QA stages and target ( potentially ) a in-sync release for Xen support when CentOS7 goes GA - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

13 19

Re: [CentOS-virt] xen setup documentation for centos?
by Scot P. Floess 03 Jun '14

03 Jun '14

Lee, I managed to get this working, but I'm not in front of my computer at the moment. I used KOAN and Cobbler with a few caveats...I'll try to follow up to tomorrow. Sent from my Verizon Wireless 4G LTE Smartphone -------- Original message -------- From: lee <lee(a)yun.yagibdah.de> Date:06/01/2014 8:45 PM (GMT-05:00) To: centos-virt(a)centos.org Subject: [CentOS-virt] xen setup documentation for centos? Hi, what is the proposed way to create domU guests on centos 6.5? At first I tried to follow the documentation on the xen project website which recommends using xl. I created a config file and ended up with getting a message that the kernel is not bootable when trying to create a guest. I also had to stop some daemon (xend?) because it said that xl isn`t compatible with it and the daemon must be stopped first. Then I followed redhat documentation which suggests to use virt-manager --- which doesn`t work because servers don`t have GUIs. So I finally managed to create a guest with virt-install. I can start and stop the guest (which is also running centos), though I don`t think this is the right way to create one. So how exactly are you supposed to create guests? Now I can`t get the networking to work. I`ve been reading lots of documentation and still don`t understand how that is supposed to work. As far as I understand, you get three different network interfaces: dom0: a bridge (virbr0) dom0: a virtual network interface (vifN.X) domU: a virtual network interface which doesn`t appear to be virtual to domU And dom0 keeps it`s own network interface(s), like eth0, which is a physical one. Is vifN.X the same as eth0 in domU? Or what is it for? If it`s the same, is it supposed to have the same IP on both sides? How do I make it so that domU has network access (beyond dom0)? How does this network stuff work? Do the virtual devices have to be in different subnets? When they are not, the network becomes reachable via multiple interfaces, and I`m guessing that either packet loops may be created or some paths might be disabled by STP. Do I have to set up shorewall (or the like) on dom0 to be able to handle network access for guests? Would I need to create a bridge for every guest to be able to handle them separately for firewalling purposes because otherwise packets circumvent firewall rules by directly going over the bridge? If so, why are bridges needed? I would understand doing things like adding those guests that are visible to the LAN only to the same bridge to have them all reachable likewise. When doing that, it would seem to make sense to use a different subnet for guests in the DMZ. All the documentation tells you many different things, none of them work and it`s totally confusing. Is there any /good/ documentation somewhere? -- Knowledge is volatile and fluid. Software is power. _______________________________________________ CentOS-virt mailing list CentOS-virt(a)centos.org http://lists.centos.org/mailman/listinfo/centos-virt

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

virt June 2014