February 2018 - Users - libvirt List Archives

[libvirt-users] Reply: Fail in virDomainUpdateDeviceFlags (libvirt-4.0.0 + Qemu-kvm 2.9.0 + Ceph 10.2.10)
by Star Guo 28 Feb '18

28 Feb '18

Dear Michal After I fix the local libvirt master branch follow your patch, and build rpm for CentOS 7.4. virDomainUpdateDeviceFlags as bellow: ================================================ 2018-02-27 09:27:43.782+0000: 16656: debug : virDomainUpdateDeviceFlags:8326 : dom=0x7f2084000c50, (VM: name=6ec499397d594e f2a64fcfc938f38225, uuid=6ec49939-7d59-4ef2-a64f-cfc938f38225), xml=<disk device="cdrom" type="network"><source name="zstac k/08085a31f8c43f278ed2f649ee166b1f@08085a31f8c43f278ed2f649ee166b1f" protocol="rbd"><host name="10.0.229.181" port="6789" / ></source><auth username="zstack"><secret type="ceph" uuid="9b06bb70-dc13-4338-88fd-b0c72d5ab9e9" /></auth><target bus="ide " dev="hdc" /><readonly /></disk>, flags=0x1 ... 2018-02-27 09:27:43.788+0000: 16656: info : virObjectNew:254 : OBJECT_NEW: obj=0x7f2084003cc0 classname=qemuDomainStorageSourcePrivate 2018-02-27 09:27:43.788+0000: 16656: debug : virConnectOpen:1169 : name=secret:///system 2018-02-27 09:27:43.788+0000: 16656: info : virObjectNew:254 : OBJECT_NEW: obj=0x7f20840008c0 classname=virConnect 2018-02-27 09:27:43.788+0000: 16656: debug : virConfLoadConfig:1576 : Loading config file '/etc/libvirt/libvirt.conf' 2018-02-27 09:27:43.788+0000: 16656: debug : virConfReadFile:752 : filename=/etc/libvirt/libvirt.conf 2018-02-27 09:27:43.788+0000: 16656: debug : virFileClose:110 : Closed fd 28 2018-02-27 09:27:43.788+0000: 16656: debug : virConfGetValueStringList:946 : Get value string list (nil) 0 2018-02-27 09:27:43.788+0000: 16656: debug : virConnectOpenInternal:1033 : Split "secret:///system" to URI components: scheme secret server <null> user <null> port 0 path /system .. 2018-02-27 09:27:43.788+0000: 16656: info : virObjectRef:388 : OBJECT_REF: obj=0x563fa24f2360 2018-02-27 09:27:43.788+0000: 16656: info : virObjectUnref:350 : OBJECT_UNREF: obj=0x563fa24f2360 2018-02-27 09:27:43.788+0000: 16656: debug : virConnectOpenInternal:1098 : driver 7 secret returned SUCCESS 2018-02-27 09:27:43.788+0000: 16656: error : qemuDomainGetSecretAESAlias:729 : invalid argument: encrypted secret alias requires valid source alias 2018-02-27 09:27:43.788+0000: 16656: info : virObjectUnref:350 : OBJECT_UNREF: obj=0x7f20840008c0 2018-02-27 09:27:43.788+0000: 16656: info : virObjectUnref:352 : OBJECT_DISPOSE: obj=0x7f20840008c0 2018-02-27 09:27:43.788+0000: 16656: info : virObjectUnref:350 : OBJECT_UNREF: obj=0x7f2030101cb0 2018-02-27 09:27:43.788+0000: 16656: debug : qemuDomainObjEndJob:5594 : Stopping job: modify (async=none vm=0x7f20300fa6e0 name=6ec499397d594ef2a64fcfc938f38225) ====================================================== But it fails. Best Regards, Star Guo -----邮件原件----- 发件人: Michal Privoznik [mailto:mprivozn@redhat.com] 发送时间: 2018年2月27日 16:53 收件人: Star Guo <starg(a)ceph.me>; libvirt-users(a)redhat.com 抄送: John Ferlan <jferlan(a)redhat.com> 主题: Re: [libvirt-users] Fail in virDomainUpdateDeviceFlags (libvirt-4.0.0 + Qemu-kvm 2.9.0 + Ceph 10.2.10) On 02/27/2018 03:06 AM, Star Guo wrote: > Hello Everyone, > > > > My pc run in CentOS 7.4 and install libvirt-4.0.0 + Qemu-kvm 2.9.0 + > Ceph > 10.2.10 ALL-in-One. > > > > I use python-sdk with libvirt and run > [self.domain.updateDeviceFlags(xml, > libvirt.VIR_DOMAIN_AFFECT_LIVE)] on CDROM (I want to change media path). > However, I enable libvirt debug log , the log as below: > > <snip/> > > I see the flow is virDomainUpdateDeviceFlags -> > qemuMonitorChangeMedia, but the cephx auth is drop, so make update error. Anybody meet this error? Yes, this is a libvirt bug. I think this fixes the issue: diff --git i/src/qemu/qemu_driver.c w/src/qemu/qemu_driver.c index 96454c17c..0e5ad9971 100644 --- i/src/qemu/qemu_driver.c +++ w/src/qemu/qemu_driver.c @@ -7842,6 +7842,8 @@ qemuDomainChangeDiskLive(virDomainObjPtr vm, virQEMUDriverPtr driver, bool force) { + virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver); + qemuDomainObjPrivatePtr priv = vm->privateData; virDomainDiskDefPtr disk = dev->data.disk; virDomainDiskDefPtr orig_disk = NULL; virDomainDeviceDef oldDev = { .type = dev->type }; @@ -7850,6 +7852,9 @@ qemuDomainChangeDiskLive(virDomainObjPtr vm, if (virDomainDiskTranslateSourcePool(disk) < 0) goto cleanup; + if (qemuDomainPrepareDiskSource(disk, priv, cfg) < 0) + goto cleanup; + if (qemuDomainDetermineDiskChain(driver, vm, disk, false, true) < 0) goto cleanup; @@ -7898,6 +7903,7 @@ qemuDomainChangeDiskLive(virDomainObjPtr vm, ret = 0; cleanup: + virObjectUnref(cfg); return ret; } Can you check and confirm? Michal

2 1

[libvirt-users] QEMU guest-agent safety in hostile VM?
by procmem 28 Feb '18

28 Feb '18

Hi. Is it still considered risky to use the QEMU guest agent in an untrusted guest? A warning on these lines was written in the manual a few years back when the feature made its debut. I wanted to know if it was hardened since.

2 1

[libvirt-users] Install of Libvirt-snmp
by Michael Cooper 26 Feb '18

26 Feb '18

Hello Everyone, This is my first time here and I have a question. Where is it installed? I am assuming on the KVM Host itself? I am sorry if this is a stupid question thanks. -- Michael A Cooper Linux Certified Zerto Certified http://www.coopfire.com

2 1

[libvirt-users] "scripts are not supported on interfaces of type vhostuser" error
by Riccardo Ravaioli 23 Feb '18

23 Feb '18

Hi, I'm having trouble starting a VM with vhostuser interfaces. I have a simple configuration where a VM running Debian has 1 vhostuser interface plugged into an OVS switch where a DPDK interface is already plugged in. $ ovs-vsctl show: Bridge "switch1" Port "switch1" Interface "switch1" type: internal Port "1.switch1" Interface "1.switch1" type: dpdk options: {dpdk-devargs="0000:0b:00.0"} Port "0.switch1" Interface "0.vm" type: dpdkvhostuserclient options: {vhost-server-path="/opt/oa/vhost/0.vm.sock"} The relevant excerpt from the XML of my VM is: <?xml version="1.0" ?> <domain type="kvm" xmlns:ns0="http://libvirt.org/schemas/domain/qemu/1.0">  <devices> <emulator>/opt/oa/bin/qemu-system-x86_64</emulator>  <interface type="vhostuser"> <script path="/opt/oa/etc/qemu-ifup"/> <source mode="server" path="/opt/oa/vhost/0.vm.sock" type="unix"/> <mac address="52:54:00:41:37:08"/> <model type="virtio"/> <driver queues="1"> <host csum="off"/> </driver> </interface>  </devices> <ns0:commandline> <ns0:arg value="-object"/> <ns0:arg value="memory-backend-file,id=mem,size=2G,mem-path=/dev/hugepages,share=on"/> <ns0:arg value="-numa"/> <ns0:arg value="node,memdev=mem"/> <ns0:arg value="-mem-prealloc"/> </ns0:commandline> </domain> Now, if I try to start my VM, I get the following error and the VM is not started at all: $ virsh create vm.xml error: Failed to create domain from vm.xml error: unsupported configuration: scripts are not supported on interfaces of type vhostuser The logs from libvirtd.log say: 2018-02-22 09:18:24.982+0000: 2033: warning : qemuProcessStartWarnShmem:4539 : Detected vhost-user interface without any shared memory, the interface might not be operational 2018-02-22 09:18:24.982+0000: 2033: error : qemuBuildHostNetStr:3894 : unsupported configuration: scripts are not supported on interfaces of type vhostuser The logs from qemu simply say: 2018-02-22 09:26:15.857+0000: shutting down, reason=failed And finally, ovs-vswitchd.log: 2018-02-22T09:18:24.715Z|00328|dpdk|INFO|VHOST_CONFIG: vhost-user client: socket created, fd: 51 2018-02-22T09:18:24.716Z|00329|netdev_dpdk|INFO|vHost User device '0.vm' created in 'client' mode, using client socket '/opt/oa/vhost/0.vm.sock' 2018-02-22T09:18:24.718Z|00330|dpdk|WARN|VHOST_CONFIG: failed to connect to /opt/oa/vhost/0.vm.sock: No such file or directory 2018-02-22T09:18:24.718Z|00331|dpdk|INFO|VHOST_CONFIG: /opt/oa/vhost/0.vm.sock: reconnecting... 2018-02-22T09:18:24.718Z|00332|bridge|INFO|bridge switch1: added interface 0.vm on port 5 Am I missing something on the openvswitch or on the libvirt side? It looks like openvswitch can't find /opt/oa/vhost/0.vm.sock, but isn't either openvswitch or libvirt in charge of creating it? Then, I'm not too sure about the error messages in libvirtd.log... My software versions are: libvirt 3.10.0, qemu 2.10.2, openvswitch 2.8.1 and DPDK 17.11. Thanks a lot! Riccardo

3 4

[libvirt-users] How to use rtc_timeoffset (XL toolkit option) in Libvirt and Xen/libxl hypervisor?
by Volo M. 21 Feb '18

21 Feb '18

Hello techs, We used XL toolkit for Xen hypervisor for starting Windows hvm VMs and the option rtc_timeoffset worked perfectly with XL. It helped us to set correct Timezone time/offset for Windows HVM VMs from inside virtual_machine xen config. For example: Below option WORKS perfectly with XL toolkit. [root@hw12xen ~]# cat goillltawdlssq.xl.cfg | grep offset rtc_timeoffset = "7200" # +2 hours to UTC time (or +/-3600=+/-1 hour to UTC time) [root@hw12xen ~]# Now we try to migrate all the Windows hvm VMs to using Libvirt and Xen 4.6.6 (or 4.4). But as we see it's impossible to make VMs using correct time/offset set in XML config like below: below Libvirt option DOESN'T WORK as we expect... [root@hw12xen ~]# cat goillltawdlssq.var.xml | grep offset <clock offset='variable' adjustment='7200' /> [root@hw12xen ~]# Can you please explain if there's something we're doing wrong way or it's just a bug like described here: https://bugzilla.redhat.com/show_bug.cgi?id=1212191 ? Thanks in advance.

2 3

[libvirt-users] ANNOUNCE: ruby-libvirt 0.7.1
by Chris Lalancette 18 Feb '18

18 Feb '18

I'm pleased to release ruby-libvirt 0.7.1. ruby-libvirt is a ruby wrapper around the libvirt API. The changelog between 0.7.0 and 0.7.1 is: * Fix a bad bug in block_resize (Marius Rieder) * Fix up some problems pointed out by clang * Fix up the tests for small semantic differences in how libvirt works Version 0.7.1 is available from http://libvirt.org/ruby: Tarball: http://libvirt.org/ruby/download/ruby-libvirt-0.7.1.tgz Gem: http://libvirt.org/ruby/download/ruby-libvirt-0.7.1.gem It is also available from rubygems.org; to get the latest version, run: $ gem install ruby-libvirt Packages for it are also built for Fedora, and will be released shortly. As usual, if you run into questions, problems, or bugs, please feel free to mail me (clalancette at gmail.com) and the libvirt mailing list. Thanks to those who contributed to this release.

1 0

[libvirt-users] what is the practical limit on snapshot generations?
by W Kern 16 Feb '18

16 Feb '18

I've googled around on this and haven't found much so I'll ask here. I have a client who routinely does live snapshots on snapshot on snapshot ( just keep going recursively) I've told him to roll them up once in a while, but he feels its unnecessary and only plans a rollup during a major maintenance period, where he can take the whole site down and then watch it grind during the commit. Note these are Qcow2 (1.1) images and they are external snaps. Most of the write activity is logging and medium database writes for an ecommerce store. It is certainly NOT heavy write i/o. Isn't there a cost (speed, resources) etc to all those generations. Any safety issues? Is there an optimium # of generations where if you exceed that you get diminishing returns. At one point are you shooting yourself in the foot, or is this really no big deal aside from two hours of downtime while the 'actual' commit occurs. -wk

1 0

[libvirt-users] Ask question
by 李杰 15 Feb '18

15 Feb '18

Dear Recently,I am interested in libvirt,but I found the libvirt does't support revert and delete the external snapshot which the raw disk based guest.My libvirt and qemu release are both 3.2.0.So I have a question,the community how to solve it,if have any plans about it.Can you tell me more about it?Thank you very much. Best Regards Rambo

3 4

[libvirt-users] kvm/libvirt on CentOS7 w/Windows 10 Pro guest
by Benjammin2068 14 Feb '18

14 Feb '18

Hey all, New to list, so I apologize if this has been asked a bunch already... Is there something I'm missing with Windows 10 as a guest that keeps Windows Updates from nuking the boot process? I just did an orderly shutdown and windows updated itself <I forgot to disable in time> only to reboot to the diagnostics screen which couldn't repair. going to command prompt and doing the usual "bootrec /fixmbr, /fixboot and /RebuildBcd" didn't help. This has happened a few times. I can't believe how fragile Win10pro is while running in a VM. (and it's happened on a couple machines I've been experimenting with -- both running same OS, but different hardware.) I just saw the FAQ about the libvirt repo for the virtio drivers for windows.... I need to go read more on it... but in the meantime, is there any other smoking gun I'm not aware of? (after lots of google searching) Thanks, -Ben

4 10

[libvirt-users] Nested KVM: L0 guest produces kernel BUG on wakeup from managed save (while a nested VM is running)
by Florian Haas 12 Feb '18

12 Feb '18

Hi everyone, I hope this is the correct list to discuss this issue; please feel free to redirect me otherwise. I have a nested virtualization setup that looks as follows: - Host: Ubuntu 16.04, kernel 4.4.0 (an OpenStack Nova compute node) - L0 guest: openSUSE Leap 42.3, kernel 4.4.104-39-default - Nested guest: SLES 12, kernel 3.12.28-4-default The nested guest is configured with "<type arch='x86_64' machine='pc-i440fx-1.4'>hvm</type>". This is working just beautifully, except when the L0 guest wakes up from managed save (openstack server resume in OpenStack parlance). Then, in the L0 guest we immediately see this: [Tue Feb 6 07:00:37 2018] ------------[ cut here ]------------ [Tue Feb 6 07:00:37 2018] kernel BUG at ../arch/x86/kvm/x86.c:328! [Tue Feb 6 07:00:37 2018] invalid opcode: 0000 [#1] SMP [Tue Feb 6 07:00:37 2018] Modules linked in: fuse vhost_net vhost macvtap macvlan xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp tun br_netfilter bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables vboxpci(O) vboxnetadp(O) vboxnetflt(O) af_packet iscsi_ibft iscsi_boot_sysfs vboxdrv(O) kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel hid_generic usbhid jitterentropy_rng drbg ansi_cprng ppdev parport_pc floppy parport joydev aesni_intel processor button aes_x86_64 virtio_balloon virtio_net lrw gf128mul glue_helper pcspkr serio_raw ablk_helper cryptd i2c_piix4 ext4 crc16 jbd2 mbcache ata_generic [Tue Feb 6 07:00:37 2018] virtio_blk ata_piix ahci libahci cirrus(O) drm_kms_helper(O) syscopyarea sysfillrect sysimgblt fb_sys_fops ttm(O) drm(O) virtio_pci virtio_ring virtio uhci_hcd ehci_hcd usbcore usb_common libata sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua scsi_mod autofs4 [Tue Feb 6 07:00:37 2018] CPU: 2 PID: 2041 Comm: CPU 0/KVM Tainted: G W O 4.4.104-39-default #1 [Tue Feb 6 07:00:37 2018] Hardware name: OpenStack Foundation OpenStack Nova, BIOS 1.10.1-1ubuntu1~cloud0 04/01/2014 [Tue Feb 6 07:00:37 2018] task: ffff880037108d80 ti: ffff88042e964000 task.ti: ffff88042e964000 [Tue Feb 6 07:00:37 2018] RIP: 0010:[<ffffffffa04f20e5>] [<ffffffffa04f20e5>] kvm_spurious_fault+0x5/0x10 [kvm] [Tue Feb 6 07:00:37 2018] RSP: 0018:ffff88042e967d70 EFLAGS: 00010246 [Tue Feb 6 07:00:37 2018] RAX: 0000000000000000 RBX: ffff88042c4f0040 RCX: 0000000000000000 [Tue Feb 6 07:00:37 2018] RDX: 0000000000006820 RSI: 0000000000000282 RDI: ffff88042c4f0040 [Tue Feb 6 07:00:37 2018] RBP: ffff88042c4f00d8 R08: ffff88042e964000 R09: 0000000000000002 [Tue Feb 6 07:00:37 2018] R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000001 [Tue Feb 6 07:00:37 2018] R13: 0000021d34fbb21d R14: 0000000000000001 R15: 000055d2157cf840 [Tue Feb 6 07:00:37 2018] FS: 00007f7c52b96700(0000) GS:ffff88043fd00000(0000) knlGS:0000000000000000 [Tue Feb 6 07:00:37 2018] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [Tue Feb 6 07:00:37 2018] CR2: 00007f823b15f000 CR3: 0000000429334000 CR4: 0000000000362670 [Tue Feb 6 07:00:37 2018] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [Tue Feb 6 07:00:37 2018] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [Tue Feb 6 07:00:37 2018] Stack: [Tue Feb 6 07:00:37 2018] ffffffffa07939b1 ffffffffa0787875 ffffffffa0503a60 ffff88042c4f0040 [Tue Feb 6 07:00:37 2018] ffffffffa04e5ede ffff88042c4f0040 ffffffffa04e6f0f ffff880037108d80 [Tue Feb 6 07:00:37 2018] ffff88042c4f00e0 ffff88042c4f00e0 ffff88042c4f0040 ffff88042e968000 [Tue Feb 6 07:00:37 2018] Call Trace: [Tue Feb 6 07:00:37 2018] [<ffffffffa07939b1>] intel_pmu_set_msr+0xfc1/0x2341 [kvm_intel] [Tue Feb 6 07:00:37 2018] DWARF2 unwinder stuck at intel_pmu_set_msr+0xfc1/0x2341 [kvm_intel] [Tue Feb 6 07:00:37 2018] Leftover inexact backtrace: [Tue Feb 6 07:00:37 2018] [<ffffffffa0787875>] ? vmx_interrupt_allowed+0x15/0x30 [kvm_intel] [Tue Feb 6 07:00:37 2018] [<ffffffffa0503a60>] ? kvm_arch_vcpu_runnable+0xa0/0xd0 [kvm] [Tue Feb 6 07:00:37 2018] [<ffffffffa04e5ede>] ? kvm_vcpu_check_block+0xe/0x60 [kvm] [Tue Feb 6 07:00:37 2018] [<ffffffffa04e6f0f>] ? kvm_vcpu_block+0x8f/0x310 [kvm] [Tue Feb 6 07:00:37 2018] [<ffffffffa0503c17>] ? kvm_arch_vcpu_ioctl_run+0x187/0x400 [kvm] [Tue Feb 6 07:00:37 2018] [<ffffffffa04ea6d9>] ? kvm_vcpu_ioctl+0x359/0x680 [kvm] [Tue Feb 6 07:00:37 2018] [<ffffffff81016689>] ? __switch_to+0x1c9/0x460 [Tue Feb 6 07:00:37 2018] [<ffffffff81224f02>] ? do_vfs_ioctl+0x322/0x5d0 [Tue Feb 6 07:00:37 2018] [<ffffffff811362ef>] ? __audit_syscall_entry+0xaf/0x100 [Tue Feb 6 07:00:37 2018] [<ffffffff8100383b>] ? syscall_trace_enter_phase1+0x15b/0x170 [Tue Feb 6 07:00:37 2018] [<ffffffff81225224>] ? SyS_ioctl+0x74/0x80 [Tue Feb 6 07:00:37 2018] [<ffffffff81634a02>] ? entry_SYSCALL_64_fastpath+0x16/0xae [Tue Feb 6 07:00:37 2018] Code: d7 fe ff ff 8b 2d 04 6e 06 00 e9 c2 fe ff ff 48 89 f2 e9 65 ff ff ff 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 <0f> 0b 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 89 ff 48 89 [Tue Feb 6 07:00:37 2018] RIP [<ffffffffa04f20e5>] kvm_spurious_fault+0x5/0x10 [kvm] [Tue Feb 6 07:00:37 2018] RSP <ffff88042e967d70> [Tue Feb 6 07:00:37 2018] ---[ end trace e15c567f77920049 ]--- We only hit this kernel bug if we have a nested VM running. The exact same setup, sent into managed save after shutting down the nested VM, wakes up just fine. Now I am aware of https://bugzilla.redhat.com/show_bug.cgi?id=1076294, which talks about live migration — but I think the same considerations apply. I am also aware of https://fedoraproject.org/wiki/How_to_enable_nested_virtualization_in_KVM, which strongly suggests to use host-passthrough or host-model. I have tried both, to no avail. The stack trace persists. I have also tried running a 4.15 kernel in the L0 guest, from https://kernel.opensuse.org/packages/stable, but again, the stack trace persists. What does fix things, of course, is to switch from the nested guest from KVM to Qemu — but that also makes things significantly slower. So I'm wondering: is there someone reading this who does run nested KVM and has managed to successfully live-migrate or managed-save? If so, would you be able to share a working host kernel / L0 guest kernel / nested guest kernel combination, or any other hints for tuning the L0 guest to support managed save and live migration? I'd be extraordinarily grateful for any suggestions. Thanks! Cheers, Florian

4 21