- Users - libvirt List Archives

[libvirt-users] Running all my virtual machines with a low priority
by R. Diez 02 May '19

02 May '19

Hi all: I have an Ubuntu 18.04 system. What is the easiest way to run all of my virtual machines with a low priority? Say a "nice" level of 15. I just do not want my virtual machines to have too much of an impact in any other processes on the system. Thanks in advance, rdiez

3 8

[libvirt-users] NUMA revisited
by Patrick Meyer 02 May '19

02 May '19

Moin libvirters, I'm looking into the current numa settings for a large-ish libvirt/qemu based setup and I ended up having a couple of questions: 1) Has kernel.numa_balancing completely replaced numad or is there still a time and place for numad when we have a modern kernel? 2) Should I pin vCPUs to numa nodes and/or use numatune at all, when using kernel.numa_balancing? 3) The libvirt domain xml elements for vcpu and numatune.memory have placement options. According to the docs setting them to auto will query numad for a good placements. Should I keep numad running just for this? 4) Should I still expose the numa topology via cpu.numa.cell if I use the auto placement for vcpu and numatune? 5) Does the cpus attribute in the cpu.numa.cell elements reference vCPU cores or the real physical CPU cores? Most examples reference them as ranges, which confuses me as on my numa hosts node0 has cores 0,2,4.. and node1 the others. I'd like to benchmark a couple of different options using our production workloads once I actually have grasp what combinations could make any sense. Maybe somebody would like to share the cpu/memory/numa settings they ended up with and why? Thanks a lot, Patrick Meyer

1 0

[libvirt-users] Unable to have TSO GSO feature in VM
by Harsh Gondaliya 02 May '19

02 May '19

I am trying to turn ON TSO in my Ubuntu Virtual machine but it gives me the following error: [image: image.png] Also on doing *ethtool -k ens3* all the features are marked as [fixed]. How to use libvirt to configure VM to have TSO?

1 0

[libvirt-users] Cloning a volume via storage XML
by Weller, Lennart 01 May '19

01 May '19

Hello everyone, After the Bug with libvirt was found and fixed by Michal I am now looking for a way to actually do the task I intended to do. I cannot find any information if it is possible to clone a base-volume a la vol- clone for ceph rbd. As I posted in my addendum to the first post here I thought something like this volume xml would do the job: <volume> <name>coreos00.disk</name> <capacity unit="bytes">9116319744</capacity> <target> <format type="raw"></format> <permissions> <mode>644</mode> </permissions> </target> <backingStore> <path>vmdisks/coreos_2023</path> <format type="raw"></format> </backingStore> </volume> But even with the fix applied this simply creates an empty volume of the given size. Granted this has no information about the snapshot so I was sceptical that this would be enough in the first place. If the vol-clone is not an option right now via volume xml it's not that wild as I could just patch the terraform-libvirt-provider to do the task beforehand but I wanted to know if it there exists an option for libvirt to do it automatically when provided with an xml. I can't find any options in the storage xml documentation so my guess would be no. Kind regards, Lennart Weller

1 1

[libvirt-users] libvirtd via unix socket using system uri
by lameventanas＠gmail.com 01 May '19

01 May '19

I want to run libvirtd as a special user, and allowing users that belong to a special group to connect via qemu+unix:///system (eg: unix socket). I did everything necessary to do so: created a libvirt user and group, added the libvirt user to the kvm group, added my normal user to the libvirt group, and made sure the socket is owned by libvirt:libvirt with permissions set to 770. libvirtd starts successfully, but when I try to connect as the normal user I get this error: bash$ virsh --connect qemu+unix://system error: failed to connect to the hypervisor error: invalid argument: using unix socket and remote server 'system' is not supported. A trace shows virsh is not even trying to open the socket. I want to use the socket because I just need local connectivity and don't want to run sasl and set up certificates for this, but at the same time want to run libvirtd as a dedicated user. Is there any reason to prevent libvirt from being used like this?

4 10

[libvirt-users] Error connecting to hypervisor
by Sukrit Bhatnagar 29 Apr '19

29 Apr '19

Hi, I have compiled and installed libvirt from git checkout and started libvirtd service. The version is 5.3.0 and I have done system-wide installation. When I do a `virsh list`, I get the following error: error: failed to connect to the hypervisor error: Unable to encode message header Similarly, the libvirtd instance shows the following error: 2019-04-23 21:36:57.777+0000: 1807: info : libvirt version: 5.3.0 2019-04-23 21:36:57.777+0000: 1807: info : hostname: dell 2019-04-23 21:36:57.777+0000: 1807: error : virNetSocketReadWire:1803 : End of file while reading data: Input/output error Furthermore, virnetmessagetest show the following error: $ VIR_TEST_DEBUG=1 ./virnetmessagetest TEST: virnetmessagetest 1) Message Header Encode ... libvirt: XML-RPC error : Unable to encode message header FAILED 2) Message Header Decode ... libvirt: XML-RPC error : Unable to decode message length FAILED 3) Message Payload Encode ... libvirt: XML-RPC error : Unable to encode message header FAILED 4) Message Payload Decode ... libvirt: XML-RPC error : Unable to decode message length FAILED 5) Message Payload Stream Encode ... libvirt: XML-RPC error : Unable to encode message header FAILED I am also compiling qemu from source and the virsh commands ran fine when I was using libvirt 4.7.0 from Fedora repository. Any ideas how I can solve this issue? Thanks, Sukrit

3 3

[libvirt-users] Libvirt pool cannot see or create rbd clones
by Weller, Lennart 29 Apr '19

29 Apr '19

Hello everyone, To increase my odds of finding an answer I also wanted to ask here. This is my post from serverfault[1] in verbatim: While trying to get a cloned disk running from my OS snapshot I run into the problem that Libvirt cannot see existing images cloned from a snapshot. Created via: # rbd -p vmdisks clone vmdisks/coreos_2023@base vmdisks/coreos00.disk The base image has the one snapshot 'base' and is protected. The cloned disk is created just fine: # rbd -p vmdisks info coreos00.disk rbd image 'coreos00.disk': size 8.49GiB in 2174 objects order 22 (4MiB objects) block_name_prefix: rbd_data.48a99c6b8b4567 format: 2 features: layering flags: create_timestamp: Thu Apr 25 14:46:52 2019 parent: vmdisks/coreos_2023@base overlap: 8.49GiB I temporarily have Libvirt configured with a rbd pool that uses the ceph admin user. But I cannot see the cloned disk. Just the parent: virsh # vol-list --pool rbd_image_root Name Path --------------------------------------------------------------------- --------- coreos_2023 vmdisks/coreos_2023 If I try to create the cloned image from within virsh I run into the following issue: virsh # vol-clone --pool rbd_image_root coreos_2023 coreos00.disk error: Failed to clone vol from coreos_2023 error: failed to iterate RBD snapshot coreos_2023@base: Operation not permitted Note that this pool uses the Ceph admin user which makes the Operation not permitted a tad odd. Am I missing a configuration option here that would allow for the pool to use clones? I can't find any information on this in the documentation so far. And the source code of libvirt looks like it should support both features. Versions: Libvirt Machine: Ubuntu 18.04 Compiled against library: libvirt 4.0.0 Using library: libvirt 4.0.0 Using API: QEMU 4.0.0 Running hypervisor: QEMU 2.11.1 Ceph Machine: openSUSE Leap 42.3 Ceph 12.2.5 [1] https://serverfault.com/questions/964586/libvirt-pool-cannot-see-or-create-…

2 2

[libvirt-users] 5.2.0 xen and maxGrantFrames
by Christoph 27 Apr '19

27 Apr '19

Hi libvirt 5.2.0 should support maxGrantFrames setting for xen (changelog). I get ever an error if I use it in the config: <domain type='xen'> <name>satan.chao5.int</name> <uuid>f1f96b1c-fb75-4707-afb7-604d696d29cc</uuid> <memory unit='KiB'>3145728</memory> <currentMemory unit='KiB'>3145728</currentMemory> <vcpu placement='static'>4</vcpu> <bootloader>pygrub</bootloader> <os> <type arch='x86_64' machine='xenpvh'>xenpvh</type> </os> <clock offset='utc' adjustment='reset'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <disk type='block' device='disk'> <driver name='phy' type='raw'/> <source dev='/dev/vg_lilith/lv_satan_root'/> <target dev='xvda' bus='xen'/> </disk> <disk type='block' device='disk'> <driver name='phy' type='raw'/> <source dev='/dev/vg_lilith/lv_satan_home'/> <target dev='xvdb' bus='xen'/> </disk> <disk type='block' device='disk'> <driver name='phy' type='raw'/> <source dev='/dev/vg_lilith/lv_satan_swap'/> <target dev='xvdc' bus='xen'/> </disk> <disk type='block' device='disk'> <driver name='phy' type='raw'/> <source dev='/dev/md10'/> <target dev='xvdd' bus='xen'/> </disk> <disk type='block' device='disk'> <driver name='phy' type='raw'/> <source dev='/dev/disk/by-uuid/6beff9f2-a88c-4d21-86c6-ff90439b4ca3'/> <target dev='xvde' bus='xen'/> </disk> <disk type='block' device='disk'> <driver name='phy' type='raw'/> <source dev='/dev/disk/by-uuid/e19e6e23-b35c-4fae-b34a-0e2835bde74d'/> <target dev='xvdf' bus='xen'/> </disk> <disk type='block' device='disk'> <driver name='phy' type='raw'/> <source dev='/dev/disk/by-uuid/3d50dfab-5ffe-4558-9ab3-36fd504607be'/> <target dev='xvdg' bus='xen'/> </disk> <disk type='block' device='disk'> <driver name='phy' type='raw'/> <source dev='/dev/disk/by-uuid/c4593072-0161-4bdc-b8b6-317fdd23f8ed'/> <target dev='xvdh' bus='xen'/> </disk> <disk type='block' device='disk'> <driver name='phy' type='raw'/> <source dev='/dev/disk/by-uuid/372167e4-c1ea-4ce6-813b-9c57dd4e67a6'/> <target dev='xvdi' bus='xen'/> </disk> <disk type='block' device='disk'> <driver name='phy' type='raw'/> <source dev='/dev/mapper/keys'/> <target dev='xvdz' bus='xen'/> <readonly/> </disk> <controller type='xenbus' index='0' maxGrantFrames='128'/> <interface type='bridge'> <mac address='00:16:3e:05:31:50'/> <source bridge='xenbr5'/> <script path='vif-bridge'/> </interface> <interface type='bridge'> <mac address='00:16:3e:15:31:50'/> <source bridge='xenbr15'/> <script path='vif-bridge'/> </interface> <console type='pty'> <target type='xen' port='0'/> </console> <input type='mouse' bus='xen'/> <input type='keyboard' bus='xen'/> <memballoon model='xen'/> </devices> </domain> What Im doing wrong? -- ------ Greetz

3 3

[libvirt-users] PCI passthrough and abstraction
by Mauricio Tavares 26 Apr '19

26 Apr '19

When you pass a device in the pci chain (after virsh nodedev-dettach'ing it from host) to the guest, how much is passed without being emulated/abstracted?

2 2

[libvirt-users] Live Disk Backup with Active Blockcommit
by Wolf 26 Apr '19

26 Apr '19

Hi! I was reading the Wiki about 'Live Disk Backup with Active Blockcommit, https://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit and see that example shown seems to be using two different names for the same file. First showing the current block device in use: $ virsh domblklist vm1 Target Source ------------------------------------------------ vda /export/images/base.qcow2 Then copying the same file for backup: $ cp /export/images/base.img /export/images/copy.img => Is there are reason why the block device first is called 'base.qcow2' and then 'base.img'? I also saw another name that seems to be wrong based on the context. It doesn't have the same implication as my earlier example, as the name of the overlay file is not written in the command itself, but still: ------ $ virsh snapshot-create-as --domain vm1 guest-state1 \ --diskspec vda,file=/export/images/overlay1.qcow2 \ --disk-only --atomic Then: $ virsh domblklist vm1 Target Source ------------------------------------------------ vda /export/images/overlay.qcow2 Now that the backup is finished, perform active blockcommit by live mergning contents of 'overlay1' into base . . . ." ------ => Here it seems like the overlay file first is called ''overlay1.qcow2" and the ' virsh domblklist vm1' command shows that it is actually called: 'overlay.qcow2' And then back to ''overlay1 in the following text: 'mergning contents of 'overlay1' into base' (Where 'mergning' is spelled wrong, but that doesn't affect the logic). => Do I understand all this correctly? I came to this article based on this answer on Serverfault: https://serverfault.com/a/921966 Since I didn't understand the logic of the file changing names, I visited the file linked to in the answer on wiki.libvirt.org and saw that the same was written there. So maybe change these errors in the Wiki if I understand all this correctly? Thanks for input! Best regards, Wolf

2 1