- Users - libvirt List Archives

[libvirt-users] Ceph RBD locking for libvirt-managed LXC (someday) live migrations
by Joshua Dotson 16 Jan '14

16 Jan '14

Hi, I'm trying to build an active/active virtualization cluster using a Ceph RBD as backing for each libvirt-managed LXC. I know live migration for LXC isn't yet possible, but I'd like to build my infrastructure as if it were. That is, I would like to be sure proper locking is in place for live migrations to someday take place. In other words, I'm building things as if I were using KVM and live migration via libvirt. I've been looking at corosync, pacemaker, virtlock, sanlock, gfs2, ocfs2, glusterfs, cephfs, ceph RBD and other solutions. I admit that I'm quite confused. If oVirt, with its embedded GlusterFS and its planned self-hosted engine option, supported LXC, I'd use that. However the stars have not yet aligned for that. It seems that the most elegant and scalable approach may be to utilize Ceph's RBD with its native locking mechanism plus corosync and pacemaker for fencing, for a number of reasons out of scope for this email. *My question now is in regards to proper locking. Please see the following links. The libvirt hook looks good, but is there any expectation that this arrangement will become a patch to libvirt itself, as is suggested by the second link?* http://www.wogri.at/en/linux/ceph-libvirt-locking/ http://lists.ceph.com/pipermail/ceph-users-ceph.com/2013-August/003887.html Can anyone guide me on how to theoretically build a very "lock" safe 5-node active-active KVM cluster atop Ceph RBD? Must I use sanlock with its NFS or GFS2 with its performance bottlenecks? Does your answer work for LXC (sans the current state of live migration)? Thanks, Joshua -- Joshua Dotson Founder, Wrale Ltd

2 2

[libvirt-users] Live migration finish threshold
by Joaquim Barrera 16 Jan '14

16 Jan '14

Hello everyone, Can somebody point where I can find the code where libvirt makes the decision to complete a live migration? I mean, at some point syncronising the VM state, it has to decide that the delta left to be migrate is low enough to achieve downtime 0, so libvirt finishes the migration. This "low enough" must be defined somewhere in the code, but I am unable to find it. Thank you very much.

2 1

[libvirt-users] vnc port/listen address ignored when setting machine?
by hubert depesz lubaczewski 16 Jan '14

16 Jan '14

Hi, First of all, I hope it's not a big problem - I'm running on Debian, not Redhat. To my problem: I'm starting to learn virtualization, libvirt, and decided to create some test machine. I did it with: virt-install --name debian-test \ --os-type=linux \ --os-variant=debianwheezy \ --cdrom /media/media/software/iso/debian-testing-amd64-netinst-2014-01-16.iso \ --graphics vnc,listen=0.0.0.0,port=20001 \ --disk pool=default,format=raw,size=20 \ --ram 2048 \ --vcpus=2 \ --network bridge=virbr0 \ --hvm \ --virt-type=kvm Machine starts, but domdisplay shows: =# virsh domdisplay debian-test vnc://localhost:14101 When I tried setting it with --grpahics=vnc,...port=40001, I got it to listen on port 34101 (which is weird anyway, but at least I can change it). But whatever I do - I can't make it to listen on 0.0.0.0. I know I can use ssh port forwarding to get to this VNC, but I would very much prefer to be able to set VNC listen to 0.0.0.0 for at least some of my test domains. What am I doing wrong? Best regards, depesz -- The best thing about modern society is how easy it is to avoid contact with it. http://depesz.com/

2 3

[libvirt-users] Does libvirt lxc driver support "cpuset" attribute?
by WANG Cheng D 16 Jan '14

16 Jan '14

Dear all I allocate only one vcpu for the container by the following statement, that is, I want to pin the vcpu to physical core "2". <vcpu placement='static' cpuset="2" >1</vcpu> My host has 4 physical cores. Before test, all the 4 cores are idle. After I run 4 processes in the container, I found all the 4 cores in the host are 100% used. That is, the container is pinned to all the available physical CPUs. This is not what I want. My libvirt version is 1.0.3. Although "vcpupin" element also can be used to pin vcpu, according to http://libvirt.org/formatdomain.html , "vcpupin" element is not supported by lxc driver. I wonder if it is the older version of libvirt that causes the problem? Thank you in advance. Cheng Wang

2 2

[libvirt-users] Fake Network Interface
by Andrew Martin 15 Jan '14

15 Jan '14

Hello, Is there a supported method for creating a fake network interface in a VM's configuration file? I was using the below construct, however it is no longer working for me in recent versions of libvirt (libvirt 1.0.2 with qemu-kvm 1.4.0). Is there a different, preferred method for creating a fake virtual interface on the guest which does not exist on the host? <interface type='network'> <mac address='aa:aa:aa:aa:aa:aa'/> <source network='fake'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> Thanks, Andrew

2 3

[libvirt-users] virDBusCallMethod:1173 : Launch helper exited with unknown return code
by Karoline Haus 15 Jan '14

15 Jan '14

Good morning, I'm using libvirtd on Gentoo. This is libvirt version: 1.1.3.1 I have trouble starting a VM using virsh start $vm. I do this as root, because as non-root user it did not work at all (especially it failed attaching to the networks). So, when I run the command (with sudo), I get the following error in libvirtd.log: 2014-01-15 07:51:00.423+0000: 16158: warning : qemuDomainObjTaint:1573 : Domain id=5 name='vader' uuid=f5b8c05b-9c7a-3211-49b9-2bd635f7e2aa is tainted: high-privileges 2014-01-15 07:51:00.428+0000: 16158: error : virDBusCallMethod:1173 : Launch helper exited with unknown return code 1 At the same time I get an error in /var/log/messages which seems related: Jan 15 07:51:00 dbus[15845]: [system] Activating service name='org.freedesktop.machine1' (using servicehelper) Jan 15 07:51:00 dbus[15845]: [system] Activated service 'org.freedesktop.machine1' failed: Launch helper exited with unknown return code 1 Anyone ever seen this issue? I have no idea where to look for errors because the message don't really tell me much. I have tried to execute the qemu-kvm command on the command line directly and that worked immediately. So the problem must be in libvirt. Thanks for any pointers.

3 3

[libvirt-users] Best practice for custom iptables rules
by ZeroUno 15 Jan '14

15 Jan '14

Hi, I'm using libvirt to manage some VMs on a CentOS host, and I need some custom iptables rules to always be in place for some communications to happen, e.g. between the VMs and the outside world in both directions. Some of these rules need to be at the top of the iptables chain, otherwise the default rules added by libvirt would block the communications I need. So I cannot just add the rules in /etc/sysconfig/iptables, because libvirt adds its own rules _before_ the rules contained in this config file. I was looking at filters, but maybe not every rule can be made into a filter? Specifically, I need a rule for the POSTROUTING chain in the "nat" table. Can it be added through filters? Also, regarding the "iptables restart problem" described in the last paragraph at <http://libvirt.org/firewall.html>, is there really no acceptable way to make libvirt add its rules back automatically upon iptables/network restart? Thanks for any info. Marco -- 01

4 12

[libvirt-users] how to detect if qemu supports live disk snapshot
by Francesco Romani 15 Jan '14

15 Jan '14

Hi everyone, Using the QEMU hypervisor, when a live disk snapshot is requested through libvirt, the request can fail if the underyling qemu binary lacks the snapshotting support. In python, we have something like libvirtError: Operation not supported: live disk snapshot not supported with this QEMU binary I'd like to detect ahead of time if the underlying QEMU can or cannot do snapshotting, and disable right from the start the snapshotting support in my application, avoiding to throw errors to the user. After reading from the docs, it seems that libvirt doesn't reports yet this information about the hypervisor in the capabilities XML: http://libvirt.org/formatcaps.html a quick test against libvirt 1.1.3 (qemu 1.6.1) on Fedora 20 seems to confirm (see XML dump below[1]). So, if I'm not mistaken, looks like the only way to test for the support in QEMU is to actually request a snapshot and see what happens. Is this right? If this is correct, I would like to craft and propose a patch to libvirt to export this information, maybe into a form of some kind of warning list/blacklist: disk snapshotting it is supposed to be available, but this particular QEMU doesn't support it. What would be the best form to export such information? the options I see are * enhance the capabilities XML * add a new API: something like (very rough first draft) int virDomainIsSnapshotSupported(virConnectPtr conn, unsigned int flags); Thoughts? Any suggestion is welcome. Best regards, +++ [1] # virsh -c qemu:///system Welcome to virsh, the virtualization interactive terminal. Type: 'help' for help with commands 'quit' to quit virsh # capabilities <capabilities> <host> <uuid>01c4dc83-b652-cb11-9e6d-f3bf03b35d26</uuid> <cpu> <arch>x86_64</arch> <model>SandyBridge</model> <vendor>Intel</vendor> <topology sockets='1' cores='2' threads='2'/> <feature name='erms'/> <feature name='smep'/> <feature name='fsgsbase'/> <feature name='rdrand'/> <feature name='f16c'/> <feature name='osxsave'/> <feature name='pcid'/> <feature name='pdcm'/> <feature name='xtpr'/> <feature name='tm2'/> <feature name='est'/> <feature name='smx'/> <feature name='vmx'/> <feature name='ds_cpl'/> <feature name='monitor'/> <feature name='dtes64'/> <feature name='pbe'/> <feature name='tm'/> <feature name='ht'/> <feature name='ss'/> <feature name='acpi'/> <feature name='ds'/> <feature name='vme'/> </cpu> <power_management> <suspend_mem/> <suspend_disk/> <suspend_hybrid/> </power_management> <migration_features> <live/> <uri_transports> <uri_transport>tcp</uri_transport> </uri_transports> </migration_features> <topology> <cells num='1'> <cell id='0'> <memory unit='KiB'>7871524</memory> <cpus num='4'> <cpu id='0' socket_id='0' core_id='0' siblings='0-1'/> <cpu id='1' socket_id='0' core_id='0' siblings='0-1'/> <cpu id='2' socket_id='0' core_id='1' siblings='2-3'/> <cpu id='3' socket_id='0' core_id='1' siblings='2-3'/> </cpus> </cell> </cells> </topology> <secmodel> <model>selinux</model> <doi>0</doi> </secmodel> <secmodel> <model>dac</model> <doi>0</doi> </secmodel> </host> <guest> <os_type>hvm</os_type> <arch name='i686'> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-i386</emulator> <machine canonical='pc-i440fx-1.6' maxCpus='255'>pc</machine> <machine maxCpus='255'>pc-q35-1.4</machine> <machine maxCpus='255'>pc-q35-1.5</machine> <machine canonical='pc-q35-1.6' maxCpus='255'>q35</machine> <machine maxCpus='1'>isapc</machine> <machine maxCpus='255'>pc-0.10</machine> <machine maxCpus='255'>pc-0.11</machine> <machine maxCpus='255'>pc-0.12</machine> <machine maxCpus='255'>pc-0.13</machine> <machine maxCpus='255'>pc-0.14</machine> <machine maxCpus='255'>pc-0.15</machine> <machine maxCpus='255'>pc-1.0</machine> <machine maxCpus='255'>pc-1.1</machine> <machine maxCpus='255'>pc-1.2</machine> <machine maxCpus='255'>pc-1.3</machine> <machine maxCpus='255'>pc-i440fx-1.4</machine> <machine maxCpus='255'>pc-i440fx-1.5</machine> <machine maxCpus='1'>none</machine> <domain type='qemu'> </domain> <domain type='kvm'> <emulator>/usr/bin/qemu-kvm</emulator> <machine canonical='pc-i440fx-1.6' maxCpus='255'>pc</machine> <machine maxCpus='255'>pc-q35-1.4</machine> <machine maxCpus='255'>pc-q35-1.5</machine> <machine canonical='pc-q35-1.6' maxCpus='255'>q35</machine> <machine maxCpus='1'>isapc</machine> <machine maxCpus='255'>pc-0.10</machine> <machine maxCpus='255'>pc-0.11</machine> <machine maxCpus='255'>pc-0.12</machine> <machine maxCpus='255'>pc-0.13</machine> <machine maxCpus='255'>pc-0.14</machine> <machine maxCpus='255'>pc-0.15</machine> <machine maxCpus='255'>pc-1.0</machine> <machine maxCpus='255'>pc-1.1</machine> <machine maxCpus='255'>pc-1.2</machine> <machine maxCpus='255'>pc-1.3</machine> <machine maxCpus='255'>pc-i440fx-1.4</machine> <machine maxCpus='255'>pc-i440fx-1.5</machine> <machine maxCpus='1'>none</machine> </domain> </arch> <features> <cpuselection/> <deviceboot/> <acpi default='on' toggle='yes'/> <apic default='on' toggle='no'/> <pae/> <nonpae/> </features> </guest> <guest> <os_type>hvm</os_type> <arch name='x86_64'> <wordsize>64</wordsize> <emulator>/usr/bin/qemu-system-x86_64</emulator> <machine canonical='pc-i440fx-1.6' maxCpus='255'>pc</machine> <machine maxCpus='255'>pc-q35-1.4</machine> <machine maxCpus='255'>pc-q35-1.5</machine> <machine canonical='pc-q35-1.6' maxCpus='255'>q35</machine> <machine maxCpus='1'>isapc</machine> <machine maxCpus='255'>pc-0.10</machine> <machine maxCpus='255'>pc-0.11</machine> <machine maxCpus='255'>pc-0.12</machine> <machine maxCpus='255'>pc-0.13</machine> <machine maxCpus='255'>pc-0.14</machine> <machine maxCpus='255'>pc-0.15</machine> <machine maxCpus='255'>pc-1.0</machine> <machine maxCpus='255'>pc-1.1</machine> <machine maxCpus='255'>pc-1.2</machine> <machine maxCpus='255'>pc-1.3</machine> <machine maxCpus='255'>pc-i440fx-1.4</machine> <machine maxCpus='255'>pc-i440fx-1.5</machine> <machine maxCpus='1'>none</machine> <domain type='qemu'> </domain> <domain type='kvm'> <emulator>/usr/bin/qemu-kvm</emulator> <machine canonical='pc-i440fx-1.6' maxCpus='255'>pc</machine> <machine maxCpus='255'>pc-q35-1.4</machine> <machine maxCpus='255'>pc-q35-1.5</machine> <machine canonical='pc-q35-1.6' maxCpus='255'>q35</machine> <machine maxCpus='1'>isapc</machine> <machine maxCpus='255'>pc-0.10</machine> <machine maxCpus='255'>pc-0.11</machine> <machine maxCpus='255'>pc-0.12</machine> <machine maxCpus='255'>pc-0.13</machine> <machine maxCpus='255'>pc-0.14</machine> <machine maxCpus='255'>pc-0.15</machine> <machine maxCpus='255'>pc-1.0</machine> <machine maxCpus='255'>pc-1.1</machine> <machine maxCpus='255'>pc-1.2</machine> <machine maxCpus='255'>pc-1.3</machine> <machine maxCpus='255'>pc-i440fx-1.4</machine> <machine maxCpus='255'>pc-i440fx-1.5</machine> <machine maxCpus='1'>none</machine> </domain> </arch> <features> <cpuselection/> <deviceboot/> <acpi default='on' toggle='yes'/> <apic default='on' toggle='no'/> </features> </guest> </capabilities> -- Francesco Romani

3 4

[libvirt-users] --persistent/--config confusion
by Dennis Jacobfeuerborn 15 Jan '14

15 Jan '14

Hi, I'm wondering how to attach a network device properly to a domain. According to the man page without "--config" a device created with "attach-device" will be added to the domain yet with "--config" it will only be added to the config and only be available after a restart of the guest. Is there no way to attach the device immediately *and* also make that change persistent? Regards, Dennis

2 2

[libvirt-users] Dedicated GDM session for a virt-manager virtual machine?
by Alex GS 15 Jan '14

15 Jan '14

Dear list, Something has been perplexing me lately. I have a bunch of Windows 7 virtual machines running on top of Fedora 20 in KVM using virt-manager. One of the big problems is that users who need the Windows VM's don't know how to user virt-manager and when they accidentally reboot a machine I have to manually setup the virt-manager session for them and make it full-screen. That means if I'm not physically there the users are unable to use the Windows sessions and cannot do their work. Is there a way to create a GDM desktop session that just launches a virtual machine via virsh and then logs directly into a full-screen virt-viewer instance of that virtual machine? Best, AGS

1 0