[CentOS-virt] Open graphics connection with virt-manager problem
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 ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] qemu-kvm rebuild in Centos for oVirt in SIG Virt
On 04/06/2014 20:17, Douglas Schilling Landgraf wrote: Hello, I would like to continue this process in the SIG Virt. Any advice/steps which I should follow? Thanks! Douglas, we are not ignoring you. As it turns out there are quite a few unknown pieces related to the libvirt version for this SIG and there was also a discussion with Dan Kenigsberg at last week's Hackathon. I don't have the technical depth to go through your proposal. Added George. Lars ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] KVM integrated network (user mode) dying after inactivity
On Wed, Jun 4, 2014 at 7:40 PM, Timo Schöler t...@riscworks.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi list, I searched the web for bug reports regarding this phenomenon I see on *multiple* machines of a customer, however, I didn't find an exact fit. So, I'd like to ask here whether anyone else has run into this. I have multiple CentOS 6 machines running using KVM to virtualize a bunch of machines on them (LVM-based). Software releases as following: [root@fe00 ~]# rpm -qa|egrep '(virt|kvm)' virt-viewer-0.5.6-8.el6_5.3.x86_64 libvirt-python-0.10.2-29.el6_5.7.x86_64 libvirt-client-0.10.2-29.el6_5.7.x86_64 qemu-kvm-0.12.1.2-2.415.el6_5.8.x86_64 libvirt-0.10.2-29.el6_5.7.x86_64 python-virtinst-0.600.0-18.el6.noarch [root@fe00 ~]# uname -r 2.6.32-431.17.1.el6.x86_64 The VMs (here: two) have the default connection provided by KVM (heading to the internet) as well as a bridged interface to connect to a high performance backbone, where sensitive data is kept and bandwidth is an issue (or better, not :), on a second interface within the VMs: [root@fe00 ~]# brctl show bridge name bridge id STP enabled interfaces br1 8000.001b21xx yes eth1 vnet1 vnet3 virbr0 8000.525400xx yes virbr0-nic vnet0 vnet2 br1 is the interface connected to the backbone, virbr0 KVM's user mode network. After some time of inactivity on the virbr0 interface, from *within* the VMs connection is *lost*. The interface(s) lose their IP; running dhclient(8) is not of any use. To get the machine back onto track, ``service libvirtd restart'' has to be issued: Vanished iptables rules show up again. (This, in contrast to an Ubuntu document [0], fixes it without shutting the VM(s) down.) Starting dhclient(8) within the VMs gets connectivity back. Have you verified that the iptables rules disappear? That is: * Initially, the NAT rule is present * After inactivity, the NAT rule disappears * After restarting libvirtd, the NAT rule re-appears? -George ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] xen setup documentation for centos?
On Wed, Jun 4, 2014 at 3:12 AM, lee l...@yun.yagibdah.de wrote: George Dunlap dunl...@umich.edu writes: On Mon, Jun 2, 2014 at 1:45 AM, lee l...@yun.yagibdah.de wrote: 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. I understand how frustrating it can be to be dealing with old / inaccurate documentation. But I'm not sure how we're supposed to help you if you don't give any details about what you did and exactly how it failed. I was merely trying to create a VM on a centos host, using xen. Hence my question what the centos way of doing this (without a GUI) is. By trial and error, I found that creating them with virsh-install works. Yet it seems to me as if virsh is an additional layer which makes dealing with VMs a lot easier at the cost of increased resource usage. My intention was to avoid this and to create VMs the xen way --- which apparently doesn`t work with centos. The Xen project itself doesn't have anything to build disk images; just as KVM itself doesn't have anything to build disk images. It leaves that to higher-level tools. I know some people use virsh to install the guest, and then use the xl command-line to manage it after that; but I haven't tested that. It would be good to have recommendations on the wiki for a simple, standardized way to create guests in CentOS. If you describe which bit of documentation on the Xen website you tried to follow, what you were trying to do, and what happened, then we can figure out which of those it is and address the issue. Well, I didn`t really care about the documentation that didn`t work. Like I said, using xl didn`t work because it only says the kernel can`t be booted; xm seems to be deprecated (yet still used with centos), and virsh-install works. *I* care about the documentation that didn't work, so that other people don't trip over the same thing. :-) If you've walked this path and become frustrated, there are probably a dozen other people who have also walked it and just not said anything. Thanks, -George ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] Open graphics connection with virt-manager problem
On Thu, Jun 5, 2014 at 10:18 AM, jaumotte, styve s.jaumo...@cg49.fr wrote: 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 ! Hmm, I wonder if it's related to this one: http://marc.info/?l=xen-develm=140050749529103 Although since this hasn't even been accepted into upstream libvirt, AFAICT, it's strange that it works with RH7RC and SLES. Can you tell what port virt-manager is trying to connect to? -George ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] KVM integrated network (user mode) dying after inactivity
On 06/05/2014 12:37 PM, thus George Dunlap spake: On Wed, Jun 4, 2014 at 7:40 PM, Timo Schöler t...@riscworks.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi list, I searched the web for bug reports regarding this phenomenon I see on *multiple* machines of a customer, however, I didn't find an exact fit. So, I'd like to ask here whether anyone else has run into this. I have multiple CentOS 6 machines running using KVM to virtualize a bunch of machines on them (LVM-based). Software releases as following: [root@fe00 ~]# rpm -qa|egrep '(virt|kvm)' virt-viewer-0.5.6-8.el6_5.3.x86_64 libvirt-python-0.10.2-29.el6_5.7.x86_64 libvirt-client-0.10.2-29.el6_5.7.x86_64 qemu-kvm-0.12.1.2-2.415.el6_5.8.x86_64 libvirt-0.10.2-29.el6_5.7.x86_64 python-virtinst-0.600.0-18.el6.noarch [root@fe00 ~]# uname -r 2.6.32-431.17.1.el6.x86_64 The VMs (here: two) have the default connection provided by KVM (heading to the internet) as well as a bridged interface to connect to a high performance backbone, where sensitive data is kept and bandwidth is an issue (or better, not :), on a second interface within the VMs: [root@fe00 ~]# brctl show bridge name bridge id STP enabled interfaces br1 8000.001b21xx yes eth1 vnet1 vnet3 virbr0 8000.525400xx yes virbr0-nic vnet0 vnet2 br1 is the interface connected to the backbone, virbr0 KVM's user mode network. After some time of inactivity on the virbr0 interface, from *within* the VMs connection is *lost*. The interface(s) lose their IP; running dhclient(8) is not of any use. To get the machine back onto track, ``service libvirtd restart'' has to be issued: Vanished iptables rules show up again. (This, in contrast to an Ubuntu document [0], fixes it without shutting the VM(s) down.) Starting dhclient(8) within the VMs gets connectivity back. Have you verified that the iptables rules disappear? That is: * Initially, the NAT rule is present * After inactivity, the NAT rule disappears * After restarting libvirtd, the NAT rule re-appears? -George Hi, yes, it's exactly that way it happens. Timo ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] xen setup documentation for centos?
George Dunlap dunl...@umich.edu writes: On Wed, Jun 4, 2014 at 3:12 AM, lee l...@yun.yagibdah.de wrote: George Dunlap dunl...@umich.edu writes: I was merely trying to create a VM on a centos host, using xen. Hence my question what the centos way of doing this (without a GUI) is. By trial and error, I found that creating them with virsh-install works. Yet it seems to me as if virsh is an additional layer which makes dealing with VMs a lot easier at the cost of increased resource usage. My intention was to avoid this and to create VMs the xen way --- which apparently doesn`t work with centos. The Xen project itself doesn't have anything to build disk images; just as KVM itself doesn't have anything to build disk images. It leaves that to higher-level tools. Creating a VM and getting the network to work are the biggest problems I`m having with this. Even with virt-install, you cannot use a centos minimal CD ISO because it`ll say that something is missing. With the full installer DVD ISO you get to the point where the installer asks you where the installation media is --- and then you`re screwed because you *must* have network access from within the VM at that point. The installer lets you set up network access, but only once. If you don`t get it right the first time, you have to start over. Nobody tells you how to get the network access to work. Suppose the dom0 has an IP of 192.168.10.10 and you tell the installer to use 192.168.10.20. That seems to make sense, but there`s no way to get network access from within the VM with that. I still don`t understand why and why this is so awfully difficult. You have to use something like 192.168.20.20 for the VM and make sure routing on dom0 is set up accordingly. You have to use an http server or nfs on dom0 to make the installation media available available to the VM. If the http/nfs server is not on dmo0, you have to set up forwarding to make it reachable for the VM. You have to make sure to disable the rudimentary firewall dom0 has to be able to access it from within the VM. You have to figure out that the installer doesn`t want the installation media, which is the ISO file. No, you have to mount the ISO, copy everything in it to a directory and then export that directory via nfs so that finally, if you got network access to work, the installer can proceed. Then you need to figure out how to get the bridge set up when starting the system. I created an ifcfg file for it and am told that bringing up that interface is delayed because it doesn`t seem to exist. There doesn`t seem to be any documentation about the file apparently used by xend to configure the VM. Documentation tells you to use virsh edit domU name, and with that, I`m seeing my changes *not* being applied even after restarting the VM. I`d edit the file directly (somewhere under /etc/xend/domains or so), but without documentation about what`s in it, I rather avoid that. How do you set a memory range (min--max) for the VM with virsh? There doesn`t seem to be a way to do that, and even if there was, how do I make it so that changes through virsh edit are applied? I know some people use virsh to install the guest, and then use the xl command-line to manage it after that; but I haven't tested that. It seemed to me that xend and xl are incompatible. It would be good to have recommendations on the wiki for a simple, standardized way to create guests in CentOS. Yes, that`s exactly what I`m asking about all the time: The centos way of creating guests. As it is, you have to piece together hundreds of bits of documentation and by trial and error somehow figure out some way that gets you what you want. If you describe which bit of documentation on the Xen website you tried to follow, what you were trying to do, and what happened, then we can figure out which of those it is and address the issue. Well, I didn`t really care about the documentation that didn`t work. Like I said, using xl didn`t work because it only says the kernel can`t be booted; xm seems to be deprecated (yet still used with centos), and virsh-install works. *I* care about the documentation that didn't work, so that other people don't trip over the same thing. :-) If you've walked this path and become frustrated, there are probably a dozen other people who have also walked it and just not said anything. I`d gladly tell you which documentation it was if I could remember. Some of the documentation on the xen wiki seems to be outdated or a mess because it evolved over time and how things are supposed to be done has changed. Almost all documentation recommends you to create a file to keep the VM in. I was planning to do that until I found some other documentation telling me that it`s a bad idea because file access like that is relatively slow and you`re much better off using LVM volumes instead. Besides being faster, they have other advantages as well, so I`m doing it that way. Once I
[CentOS-virt] sorting virtual network interface names with xen
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. ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] xen setup documentation for centos?
George Dunlap dunl...@umich.edu writes: *I* care about the documentation that didn't work, so that other people don't trip over the same thing. :-) If you've walked this path and become frustrated, there are probably a dozen other people who have also walked it and just not said anything. To give an example: https://www.centos.org/docs/5/html/5.1/Deployment_Guide/s1-networkscripts-static-routes.html [root@charon ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 BOOTPROTO=none DNS1=192.168.178.20 IPADDR=192.168.1.1 NETMASK=255.255.255.255 NM_CONTROLLED=no ONBOOT=yes TYPE=Ethernet UUID=1b645d25-9f66-4335-ba0b-939cdd9f553f [root@charon ~]# cat /etc/sysconfig/network-scripts/route-eth0 192.168.178.0/24 via 192.168.1.1 eth0 default 192.168.178.200 dev eth0 [root@charon ~]# service network restart Shutting down interface eth0: [ OK ] Shutting down loopback interface: [ OK ] Bringing up loopback interface: [ OK ] Bringing up interface eth0: Determining if ip address 192.168.1.1 is already in use for device eth0... Error: either to is duplicate, or eth0 is a garbage. Error: either to is duplicate, or 192.168.178.200 is a garbage. [ OK ] [root@charon ~]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface [root@charon ~]# https://docs.fedoraproject.org/en-US/Fedora/13/html/Deployment_Guide/s1-networkscripts-static-routes.html If the default gateway is already assigned from DHCP, the IP command arguments format can cause one of two errors during start-up, or when bringing up an interface from the down state using the ifup command: RTNETLINK answers: File exists or 'Error: either to is a duplicate, or X.X.X.X is a garbage.', where X.X.X.X is the gateway, or a different IP address. These errors can also occur if you have another route to another network using the default gateway. Both of these errors are safe to ignore. This error is not save to ignore because it makes the network unreachable. Without the duplication and only the default route specified, I`m getting the same error, though only once, and still no routing. Then from https://docs.fedoraproject.org/en-US/Fedora/13/html/Deployment_Guide/s1-networkscripts-static-routes.html: You can also use the network/netmask directives format for route-interface files. The following is a template for the network/netmask format, with instructions following afterwards: [...] Let`s see ... [root@charon ~]# cat /etc/sysconfig/network-scripts/route-eth0 ADDRESS0=192.168.178.0 NETMASK0=255.255.255.0 GATEWAY0=192.168.1.1 [root@charon ~]# service network restart Shutting down interface eth0: [ OK ] Shutting down loopback interface: [ OK ] Bringing up loopback interface: [ OK ] Bringing up interface eth0: Determining if ip address 192.168.1.1 is already in use for device eth0... [ OK ] [root@charon ~]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 192.168.178.0 192.168.1.1 255.255.255.0 UG0 00 eth0 [root@charon ~]# So why does the second approach work and the first one doesn`t? It looks still strange since eth0 is configured with 192.168.1.1 anyway --- but perhaps it`s ok since there are two more interfaces. Figuring this out was even fast; it took less than an hour. Other things take hours over hours, and it goes on and on like this. For some things, there isn`t even any documentation I could find, like how to make sure that virtual interfaces in dom0 have consistent names and that such interfaces are consistently connected to particular interfaces in particular domUs: For firewalling and routing, I require a domU with three virtual interfaces and access to a physical one. Obviously, the names of the interfaces must remain consistent rather than change all the time. Otherwise it will be impossible to get the networking for all the guests sorted out. Like in the above example: How do I make sure that eth0 of the guest will always be connected to a particular bridge and show up as a particular interface in dom0? It`s going to be the interface to the DMZ --- you can imagine what would happen if that interface suddenly shows up as the bridge guests in the LAN will be connected to ... -- Knowledge is volatile and fluid. Software is power. ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
