- Users - libvirt List Archives

[libvirt-users] Resource control is not supported on this host
by Allence 14 Mar '18

14 Mar '18

Libvirt release version V4.1.0 It add a element is cachetune After we add this, We can use host-cpu-cache But when i add it, my host get a error message: "Resource control is not supported on this host" Why? Following is my environment: kernel : 4.1.5, libvirt : 4.1.0 qemu : 2.9 host : lfs-7.0 my add cachetune in xml: <cachetune vcpus='0-3'> <cache id='1' level='3' type='data' size='3' unit='MiB'/> </cachetune>

4 4

[libvirt-users] Xen PVH Support in libvirt
by Tizian Lamatsch 14 Mar '18

14 Mar '18

Hello @ all, i wonder if there is any support for Xen PVH (https://wiki.xen.org/wiki/Xen_Project_Software_Overview) within libvirt. If i parse a xen native domU config file with 'virsh domxml-from-native' in which i set type='pvh' it changes it in the libvirt xml output to normal pv. Also the docs of libvirt do not state something like pvh. I am currently running Xen 4.10.0 with LibVirt 4.0.0. If it is not possible at the moment, can you please tell if this is a planned feature of libvirt? Thanks in advance for your help! Best Regards, Tizian

2 1

[libvirt-users] auto propagate interface status change
by John Lemon 13 Mar '18

13 Mar '18

1 0

[libvirt-users] libvirt connect vmware workstation fail
by 吴金灿 13 Mar '18

13 Mar '18

bash: vmwarews+ssh://jc@127.0.0.1/session: No such file or directory [jc@te ~]$ virsh -c vmwarews+ssh://jc@127.0.0.1/session 错误：连接到管理程序失败错误：不支持的操作：ssh 连接驱动程序不支持在没有套接字路径的情况下连接到会话实例 [jc@te ~]$ virsh -c vmwarews+ssh://root@127.0.0.1/session 错误：连接到管理程序失败错误：不支持的操作：ssh 连接驱动程序不支持在没有套接字路径的情况下连接到会话实例 [jc@te ~]$ virsh -c vmwarews:///session Segmentation fault (核心已转储)

2 1

[libvirt-users] KVM or Qemu
by Jamie Fargen 12 Mar '18

12 Mar '18

List- I know this may be slightly off topic and if so tell me to hit up the emu-discuss mailing list, but does anyone know how to detect the difference between a guest that is being fully emulates using qemu and a guest that is running para-virtualized using KVM? I have and when I inspect the CPUs I see the following.... # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : QEMU Virtual CPU version 1.5.3 stepping : 3 microcode : 0x1 cpu MHz : 1995.312 cache size : 4096 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 4 wp : yes flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl pni cx16 hypervisor lahf_lm abm bogomips : 3990.62 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management: # dmidecode # dmidecode 2.12-dmifs SMBIOS 2.4 present. 10 structures occupying 326 bytes. Table at 0x000F7190. Handle 0x0000, DMI type 0, 24 bytes BIOS Information Vendor: Seabios Version: 0.5.1 Release Date: 01/01/2011 Address: 0xE8000 Runtime Size: 96 kB ROM Size: 64 kB Characteristics: BIOS characteristics not supported Targeted content distribution is supported BIOS Revision: 1.0 Handle 0x0100, DMI type 1, 27 bytes System Information Manufacturer: Red Hat Product Name: KVM Version: RHEL 7.0.0 PC (i440FX + PIIX, 1996) Serial Number: Not Specified UUID: 1851A1FE-5ABB-42BD-B651-1A5931ADEE40 Wake-up Type: Power Switch SKU Number: Not Specified Family: Red Hat Enterprise Linux Handle 0x0300, DMI type 3, 20 bytes Chassis Information Manufacturer: Bochs Type: Other Lock: Not Present Version: Not Specified Serial Number: Not Specified Asset Tag: Not Specified Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: Unknown OEM Information: 0x00000000 Height: Unspecified Number Of Power Cords: Unspecified Handle 0x0401, DMI type 4, 32 bytes Processor Information Socket Designation: CPU 1 Type: Central Processor Family: Other Manufacturer: Bochs ID: D3 06 00 00 FD FB 8B 07 Version: Not Specified Voltage: Unknown External Clock: Unknown Max Speed: 2000 MHz Current Speed: 2000 MHz Status: Populated, Enabled Upgrade: Other L1 Cache Handle: Not Provided L2 Cache Handle: Not Provided L3 Cache Handle: Not Provided Since it is report a Qemu cpu and Manufacturer Bochs I am suspecting that it is qemu fully emulated vs KVM para-virtualized.

2 1

[libvirt-users] snapshot with libvirt tools or with lvm tools ?
by Lentes, Bernd 09 Mar '18

09 Mar '18

Hi, i asked already a time ago about snapshots. I have some guests, each resides in a raw file, placed on an ext3 fs which is on top of a logical volume, for each guest a dedicated lv. The raw is not a "must have", if there are obvious reasons i can convert them to a qcow2. What i want is a consistent backup of each guest taken overnight. If possible i won't have downtime. I can use the libvirt tools, but the lvm way seems to be more elegant. Before copying the file the guests resides in i take a snapshot from the respective lv. Then i mount the snapshot and transfer it via rsync on a CIFS share. Rsync seems to be the appropriate tool because i just transfer the changes in the file compared to the file from a day before. So i don't have to transfer complete and big raw files but just the difference. The guest still can be running, and after the transfer of the snapshot file i just delete it, and the next night the same procedure. What do you think ? Bernd -- Bernd Lentes Systemadministration Institut für Entwicklungsgenetik Gebäude 35.34 - Raum 208 HelmholtzZentrum münchen [ mailto:bernd.lentes@helmholtz-muenchen.de | bernd.lentes(a)helmholtz-muenchen.de ] phone: +49 89 3187 1241 fax: +49 89 3187 2294 [ http://www.helmholtz-muenchen.de/idg | http://www.helmholtz-muenchen.de/idg ] no backup - no mercy Helmholtz Zentrum Muenchen Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) Ingolstaedter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen Registergericht: Amtsgericht Muenchen HRB 6466 USt-IdNr: DE 129521671

1 2

[libvirt-users] About .img file while creating vm
by amey pandit 09 Mar '18

09 Mar '18

Hi, I am trying to create vm using virsh create x.xml. But I am confused as what is the .img file that is required. Here is the Disk tag from my xml. <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> * <source file='/xxx/xx_vm.img'/> * <target dev='hda'/> </disk> Is it .ova file that is converted to .img ? If anybody have links or some guide related to the topic that would be really helpful. Thank you, Amey

2 1

[libvirt-users] Statistics domain memory block when domain shutdown
by llilulu 09 Mar '18

09 Mar '18

Hi My libvirt version is 3.4.0,host system is centos 7.4 ,kernel is 3.10.0-693.el7.x86_64 , when I shutdown domain in virtual system, My program call virDomainMemoryStats, My program blocked in this api. the call stack is #0 0x00007ff242d78a3d in poll () from /lib64/libc.so.6 #1 0x00007ff243755ce8 in virNetClientIOEventLoop () from /lib64/libvirt.so.0 #2 0x00007ff24375654b in virNetClientSendInternal () from /lib64/libvirt.so.0#3 0x00007ff2437579b3 in virNetClientSendWithReply () from /lib64/libvirt.so.0 #4 0x00007ff2437581c2 in virNetClientProgramCall () from /lib64/libvirt.so.0#5 0x00007ff24372d392 in callFull.isra.3 () from /lib64/libvirt.so.0 #6 0x00007ff24373b8a1 in remoteDomainMemoryStats () from /lib64/libvirt.so.0 #7 0x00007ff2436f14e2 in virDomainMemoryStats () from /lib64/libvirt.so.0 #8 0x00007ff22ee975c2 in VM::getMemoryStats (this=0x7ff1d4064ae0, Begin I think is my program problem, But when I use virsh domstats cmd , The cmd block too. In my program, I set timeout event for virConnectPtr. But my program blocked all the time. I find my system log, I find some libvirtd error: libvirtd: 2018-03-08 04:25:13.144+0000: 1289: error : virKeepAliveTimerInternal:143 : internal error: connection closed due to keepalive timeout Mar 7 23:33:05 localhost libvirtd: 2018-03-08 04:33:05.738+0000: 1289: error : virNetSocketReadWire:1808 : End of file while reading data: Input/output error Mar 7 23:33:14 localhost libvirtd: 2018-03-08 04:33:14.253+0000: 1289: error : virNetSocketReadWire:1808 : End of file while reading data: Input/output error Mar 7 23:33:16 localhost libvirtd: 2018-03-08 04:33:16.962+0000: 1289: error : virNetSocketReadWire:1808 : End of file while reading data: Input/output error Mar 7 23:33:25 localhost libvirtd: 2018-03-08 04:33:25.879+0000: 1300: warning : qemuDomainObjBeginJobInternal:3847 : Cannot start job (query, none) for domain d7bb3005-4fa4-4c3a-8802-ab55464d074b; current job is (query, none) owned by (1299 remoteDispatchDomainMemoryStats, 0 <null>) for (3680s, 0s) Mar 7 23:33:25 localhost libvirtd: 2018-03-08 04:33:25.879+0000: 1300: error : qemuDomainObjBeginJobInternal:3859 : Timed out during operation: cannot acquire state change lock (held by remoteDispatchDomainMemoryStats) Mar 7 23:33:25 localhost libvirtd: 2018-03-08 04:33:25.879+0000: 1300: warning : qemuGetProcessInfo:1428 : cannot parse process status data Mar 7 23:33:25 localhost libvirtd: 2018-03-08 04:33:25.880+0000: 1300: error : virNetDevTapInterfaceStats:751 : internal error: /proc/net/dev: Interface not found Mar 7 23:33:41 localhost libvirtd: 2018-03-08 04:33:41.826+0000: 1298: warning : qemuDomainObjBeginJobInternal:3847 : Cannot start job (query, none) for domain d7bb3005-4fa4-4c3a-8802-ab55464d074b; current job is (query, none) owned by (1299 remoteDispatchDomainMemoryStats, 0 <null>) for (3696s, 0s)Mar 7 23:33:41 localhost libvirtd: 2018-03-08 04:33:41.826+0000: 1298: error : qemuDomainObjBeginJobInternal:3859 : Timed out during operation: cannot acquire state change lock (held by remoteDispatchDomainMemoryStats) Is this problem a bug or I can't statistics some specifi status domain? Thanks

2 1

[libvirt-users] Lib virt v4.x packages for Xenial
by Stephen Bates 06 Mar '18

06 Mar '18

Hi Libvirt Users! Apologies in advance as I am sure this has been asked before (but I could not find it in the archives). Has anyone had any success creating .deb packages for Xenial for libvirt and libvirt-bin for v4.0 or v4.1? A quick scan of the PPA respository does not show anything this recent. Is there a fundamental issue that prevents these package files being created? If so has anyone got a primer for how best to install a recent version of libvirt and associated tools on Xenial? We have a bare-metal server we have to keep on LTS but I need to be able to run recent versions of QEMU to get access to certain NVMe model features that were only recently added... Cheers Stephen

1 0

[libvirt-users] Fail in virDomainUpdateDeviceFlags (libvirt-4.0.0 + Qemu-kvm 2.9.0 + Ceph 10.2.10)
by Star Guo 05 Mar '18

05 Mar '18

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: "2018-02-26 13:09:13.638+0000: 50524: debug : virDomainLookupByName:412 : conn=0x7f7278000aa0, name=6ec499397d594ef2a64fcfc938f38225 2018-02-26 13:09:13.638+0000: 50515: debug : virDomainGetInfo:2431 : dom=0x7f726c000c30, (VM: name=6ec499397d594ef2a64fcfc938f38225, uuid=6ec49939-7d59-4ef2-a64f-cfc938f38225), info=0x7f72b9059b20 2018-02-26 13:09:13.638+0000: 50515: debug : qemuGetProcessInfo:1479 : Got status for 71205/0 user=14674 sys=3627 cpu=5 rss=105105 2018-02-26 13:09:13.644+0000: 50519: debug : virDomainGetXMLDesc:2572 : dom=0x7f7280002f20, (VM: name=6ec499397d594ef2a64fcfc938f38225, uuid=6ec49939-7d59-4ef2-a64f-cfc938f38225), flags=0x0 2018-02-26 13:09:13.653+0000: 50516: debug : virDomainUpdateDeviceFlags:8326 : dom=0x7f7274000b90, (VM: name=6ec499397d594ef2a64fcfc938f38225, uuid=6ec49939-7d59-4ef2-a64f-cfc938f38225), xml=<disk device="cdrom" type="network"><source name="zstack/08085a31f8c43f278ed2f649ee166b1f@08085a31f8c43f278ed2f649ee166b 1f" 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-26 13:09:13.653+0000: 50516: debug : qemuDomainObjBeginJobInternal:4778 : Starting job: modify (vm=0x7f7294100af0 name=6ec499397d594ef2a64fcfc938f38225, current job=none async=none) 2018-02-26 13:09:13.653+0000: 50516: debug : qemuDomainObjBeginJobInternal:4819 : Started job: modify (async=none vm=0x7f7294100af0 name=6ec499397d594ef2a64fcfc938f38225) 2018-02-26 13:09:13.660+0000: 50516: debug : virQEMUCapsCacheLookup:5443 : Returning caps 0x7f7294126ac0 for /usr/libexec/qemu-kvm 2018-02-26 13:09:13.664+0000: 50516: debug : virQEMUCapsCacheLookup:5443 : Returning caps 0x7f7294126ac0 for /usr/libexec/qemu-kvm 2018-02-26 13:09:13.667+0000: 50516: debug : qemuSetupImageCgroupInternal:91 : Not updating cgroups for disk path '08085a31f8c43f278ed2f649ee166b1f@08085a31f8c43f278ed2f649ee166b1f', type: network 2018-02-26 13:09:13.667+0000: 50516: debug : qemuDomainObjEnterMonitorInternal:5048 : Entering monitor (mon=0x7f728c07f260 vm=0x7f7294100af0 name=6ec499397d594ef2a64fcfc938f38225) 2018-02-26 13:09:13.667+0000: 50516: debug : qemuMonitorEjectMedia:2487 : dev_name=drive-ide0-1-0 force=0 2018-02-26 13:09:13.667+0000: 50516: debug : qemuMonitorEjectMedia:2489 : mon:0x7f728c07f260 vm:0x7f7294100af0 json:1 fd:24 2018-02-26 13:09:13.667+0000: 50516: debug : qemuMonitorJSONCommandWithFd:301 : Send command '{"execute":"eject","arguments":{"device":"drive-ide0-1-0","force":false},"i d":"libvirt-78"}' for write with FD -1 2018-02-26 13:09:13.667+0000: 50516: info : qemuMonitorSend:1079 : QEMU_MONITOR_SEND_MSG: mon=0x7f728c07f260 msg={"execute":"eject","arguments":{"device":"drive-ide0-1-0","force":false} ,"id":"libvirt-78"} fd=-1 2018-02-26 13:09:13.667+0000: 50514: info : qemuMonitorIOWrite:553 : QEMU_MONITOR_IO_WRITE: mon=0x7f728c07f260 buf={"execute":"eject","arguments":{"device":"drive-ide0-1-0","force":false} ,"id":"libvirt-78"} len=93 ret=93 errno=0 2018-02-26 13:09:13.669+0000: 50514: debug : qemuMonitorJSONIOProcessLine:193 : Line [{"return": {}, "id": "libvirt-78"}] 2018-02-26 13:09:13.669+0000: 50514: info : qemuMonitorJSONIOProcessLine:213 : QEMU_MONITOR_RECV_REPLY: mon=0x7f728c07f260 reply={"return": {}, "id": "libvirt-78"} 2018-02-26 13:09:13.669+0000: 50516: debug : qemuMonitorJSONCommandWithFd:306 : Receive command reply ret=0 rxObject=0x5561b7c6abc0 2018-02-26 13:09:13.669+0000: 50516: debug : qemuDomainObjExitMonitorInternal:5071 : Exited monitor (mon=0x7f728c07f260 vm=0x7f7294100af0 name=6ec499397d594ef2a64fcfc938f38225) 2018-02-26 13:09:13.669+0000: 50516: debug : qemuDomainObjEnterMonitorInternal:5048 : Entering monitor (mon=0x7f728c07f260 vm=0x7f7294100af0 name=6ec499397d594ef2a64fcfc938f38225) 2018-02-26 13:09:13.669+0000: 50516: debug : qemuMonitorEjectMedia:2487 : dev_name=drive-ide0-1-0 force=0 2018-02-26 13:09:13.669+0000: 50516: debug : qemuMonitorEjectMedia:2489 : mon:0x7f728c07f260 vm:0x7f7294100af0 json:1 fd:24 2018-02-26 13:09:13.669+0000: 50516: debug : qemuMonitorJSONCommandWithFd:301 : Send command '{"execute":"eject","arguments":{"device":"drive-ide0-1-0","force":false},"i d":"libvirt-79"}' for write with FD -1 2018-02-26 13:09:13.669+0000: 50516: info : qemuMonitorSend:1079 : QEMU_MONITOR_SEND_MSG: mon=0x7f728c07f260 msg={"execute":"eject","arguments":{"device":"drive-ide0-1-0","force":false} ,"id":"libvirt-79"} fd=-1 2018-02-26 13:09:13.669+0000: 50514: info : qemuMonitorIOWrite:553 : QEMU_MONITOR_IO_WRITE: mon=0x7f728c07f260 buf={"execute":"eject","arguments":{"device":"drive-ide0-1-0","force":false} ,"id":"libvirt-79"} len=93 ret=93 errno=0 2018-02-26 13:09:13.670+0000: 50514: debug : qemuMonitorJSONIOProcessLine:193 : Line [{"return": {}, "id": "libvirt-79"}] 2018-02-26 13:09:13.670+0000: 50514: info : qemuMonitorJSONIOProcessLine:213 : QEMU_MONITOR_RECV_REPLY: mon=0x7f728c07f260 reply={"return": {}, "id": "libvirt-79"} 2018-02-26 13:09:13.670+0000: 50516: debug : qemuMonitorJSONCommandWithFd:306 : Receive command reply ret=0 rxObject=0x5561b7c6a080 2018-02-26 13:09:13.670+0000: 50516: debug : qemuDomainObjExitMonitorInternal:5071 : Exited monitor (mon=0x7f728c07f260 vm=0x7f7294100af0 name=6ec499397d594ef2a64fcfc938f38225) 2018-02-26 13:09:13.670+0000: 50516: debug : qemuDomainObjEnterMonitorInternal:5048 : Entering monitor (mon=0x7f728c07f260 vm=0x7f7294100af0 name=6ec499397d594ef2a64fcfc938f38225) 2018-02-26 13:09:13.670+0000: 50516: debug : qemuMonitorChangeMedia:2504 : dev_name=drive-ide0-1-0 newmedia=rbd:zstack/08085a31f8c43f278ed2f649ee166b1f@08085a31f8c43f278ed2f64 9ee166b1f:auth_supported=none:mon_host=10.0.229.181\:6789 format=raw 2018-02-26 13:09:13.670+0000: 50516: debug : qemuMonitorChangeMedia:2506 : mon:0x7f728c07f260 vm:0x7f7294100af0 json:1 fd:24 2018-02-26 13:09:13.670+0000: 50516: debug : qemuMonitorJSONCommandWithFd:301 : Send command '{"execute":"change","arguments":{"device":"drive-ide0-1-0","target":"rbd:zs tack/08085a31f8c43f278ed2f649ee166b1f@08085a31f8c43f278ed2f649ee166b1f:auth_ supported=none:mon_host=10.0.229.181\\:6789","arg":"raw"},"id":"libvirt-80"} ' for write with FD -1 2018-02-26 13:09:13.670+0000: 50516: info : qemuMonitorSend:1079 : QEMU_MONITOR_SEND_MSG: mon=0x7f728c07f260 msg={"execute":"change","arguments":{"device":"drive-ide0-1-0","target":"rbd :zstack/08085a31f8c43f278ed2f649ee166b1f@08085a31f8c43f278ed2f649ee166b1f:au th_supported=none:mon_host=10.0.229.181\\:6789","arg":"raw"},"id":"libvirt-8 0"} fd=-1 2018-02-26 13:09:13.670+0000: 50514: info : qemuMonitorIOWrite:553 : QEMU_MONITOR_IO_WRITE: mon=0x7f728c07f260 buf={"execute":"change","arguments":{"device":"drive-ide0-1-0","target":"rbd :zstack/08085a31f8c43f278ed2f649ee166b1f@08085a31f8c43f278ed2f649ee166b1f:au th_supported=none:mon_host=10.0.229.181\\:6789","arg":"raw"},"id":"libvirt-8 0"} len=229 ret=229 errno=0 2018-02-26 13:09:13.678+0000: 50514: debug : qemuMonitorJSONIOProcessLine:193 : Line [{"id": "libvirt-80", "error": {"class": "GenericError", "desc": "error connecting: Operation not supported"}}] 2018-02-26 13:09:13.678+0000: 50514: info : qemuMonitorJSONIOProcessLine:213 : QEMU_MONITOR_RECV_REPLY: mon=0x7f728c07f260 reply={"id": "libvirt-80", "error": {"class": "GenericError", "desc": "error connecting: Operation not supported"}} 2018-02-26 13:09:13.678+0000: 50516: debug : qemuMonitorJSONCommandWithFd:306 : Receive command reply ret=0 rxObject=0x5561b7c88f40 2018-02-26 13:09:13.678+0000: 50516: debug : qemuMonitorJSONCheckError:381 : unable to execute QEMU command {"execute":"change","arguments":{"device":"drive-ide0-1-0","target":"rbd:zst ack/08085a31f8c43f278ed2f649ee166b1f@08085a31f8c43f278ed2f649ee166b1f:auth_s upported=none:mon_host=10.0.229.181\\:6789","arg":"raw"},"id":"libvirt-80"}: {"id":"libvirt-80","error":{"class":"GenericError","desc":"error connecting: Operation not supported"}} 2018-02-26 13:09:13.678+0000: 50516: error : qemuMonitorJSONCheckError:392 : internal error: unable to execute QEMU command 'change': error connecting: Operation not supported 2018-02-26 13:09:13.678+0000: 50516: debug : qemuDomainObjExitMonitorInternal:5071 : Exited monitor (mon=0x7f728c07f260 vm=0x7f7294100af0 name=6ec499397d594ef2a64fcfc938f38225) 2018-02-26 13:09:13.678+0000: 50516: debug : qemuTeardownImageCgroup:123 : Not updating cgroups for disk path '08085a31f8c43f278ed2f649ee166b1f@08085a31f8c43f278ed2f649ee166b1f', type: network 2018-02-26 13:09:13.682+0000: 50516: debug : qemuDomainObjEndJob:4979 : Stopping job: modify (async=none vm=0x7f7294100af0 name=6ec499397d594ef2a64fcfc938f38225) 2018-02-26 13:09:13.983+0000: 50520: debug : virDomainLookupByName:412 : conn=0x7f7278000aa0, name=6ec499397d594ef2a64fcfc938f38225 2018-02-26 13:09:13.990+0000: 50518: debug : virDomainGetInfo:2431 : dom=0x7f72700009b0, (VM: name=6ec499397d594ef2a64fcfc938f38225, uuid=6ec49939-7d59-4ef2-a64f-cfc938f38225), info=0x7f72b7856b20 2018-02-26 13:09:13.990+0000: 50518: debug : qemuGetProcessInfo:1479 : Got status for 71205/0 user=14675 sys=3628 cpu=0 rss=105119 2018-02-26 13:09:13.991+0000: 50515: debug : virDomainGetXMLDesc:2572 : dom=0x7f726c000c30, (VM: name=6ec499397d594ef2a64fcfc938f38225, uuid=6ec49939-7d59-4ef2-a64f-cfc938f38225), flags=0x0" I see the flow is virDomainUpdateDeviceFlags -> qemuMonitorChangeMedia, but the cephx auth is drop, so make update error. Anybody meet this error? Best Regards, Star Guo

4 6