- Users - libvirt List Archives

[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

[libvirt-users] Can't shutdown/reboot Windows 10 guest if on lock screen
by Sebastian Arcus 05 Mar '18

05 Mar '18

I am running Windows 10 vms on a Linux host with libvirt 4.0.0 and qemu 2.10.2 I can shutdown and reboot the Windows 10 guests if the no user is logged in the vm, or if the user is logged in and active/seeing the desktop. But after a while, when the lock screen kicks in (but the user is still logged in technically), the shutdown and reboot commands don't have any effect any more. Is there any way around this (except for disabling automatic screen locking on Windows)? Thank you for any hints.

1 0

[libvirt-users] How can we achieve vga emulation over a serial port in libvirt
by Meina Li 05 Mar '18

05 Mar '18

Hi For the latest seabios version, it said: Support for vga emulation over a serial port in SeaBIOS (sercon). So I want to know how can I find the application of this feature in libvirt? And whether my understanding is correct? There are no related instruction on the website: https://libvirt.org/ My understanding: (1) The feature means: we can set this the IO address of a serial port to "video" element to enable SeaBIOS' VGA adapter emulation on the given serial port. (2) Libvirt XML examples and with this xml the guest can start successfully: <controller type='virtio-serial' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </controller> <video> <model type='vga' vram='16384' heads='1' primary='yes'/> <address type='virtio-serial' controller='0' bus='0' port='3'/> </video> Thank in advance. Best Regards Meina Li

2 2