September 2014 - Devel - libvirt List Archives

[libvirt] increase number of libvirt threads by starting tansient guest doamin - is it a bug?
by ustermann78＠web.de 01 Oct '14

01 Oct '14

hello, if i start a transient guest doamin via "virsh create abcd.xml" i see an additional libvirt thread and also some open files: pstree -h `pgrep libvirtd` libvirtd───11*[{libvirtd}] libvirtd 3016 root 21w REG 253,0 6044 1052094 /var/log/libvirt/libxl/abcd.log libvirtd 3016 root 22r FIFO 0,8 0t0 126124 pipe libvirtd 3016 root 23w FIFO 0,8 0t0 126124 pipe libvirtd 3016 root 24u REG 0,37 0 4 /proc/xen/privcmd libvirtd 3016 root 25u unix 0xffff8807d2c3ad80 0t0 126125 socket libvirtd 3016 root 26r FIFO 0,8 0t0 126127 pipe libvirtd 3016 root 27w FIFO 0,8 0t0 126127 pipe libvirtd 3016 root 28r FIFO 0,8 0t0 124783 pipe libvirtd 3016 root 29w FIFO 0,8 0t0 124783 pipe libvirtd 3016 root 30r FIFO 0,8 0t0 127140 pipe libvirtd 3016 root 31w FIFO 0,8 0t0 127140 pipe if i destroy these vm via "virsh destroy abcd", i see that the additional thread still exists and also the list of openfiles is the same. if i start the transient guest domain again, i observe an increase in the number of libvirt threads ans also in the list of openfiles: [root@localhost libxl]# pstree -h `pgrep libvirtd` libvirtd───12*[{libvirtd}] libvirtd 3016 root 21w REG 253,0 13783 1052094 /var/log/libvirt/libxl/abcd.log libvirtd 3016 root 22r FIFO 0,8 0t0 126124 pipe libvirtd 3016 root 23w FIFO 0,8 0t0 126124 pipe libvirtd 3016 root 24u REG 0,37 0 4 /proc/xen/privcmd libvirtd 3016 root 25u unix 0xffff8807d2c3ad80 0t0 126125 socket libvirtd 3016 root 26r FIFO 0,8 0t0 126127 pipe libvirtd 3016 root 27w FIFO 0,8 0t0 126127 pipe libvirtd 3016 root 28r FIFO 0,8 0t0 124783 pipe libvirtd 3016 root 29w FIFO 0,8 0t0 124783 pipe libvirtd 3016 root 30r FIFO 0,8 0t0 127140 pipe libvirtd 3016 root 31w FIFO 0,8 0t0 127140 pipe libvirtd 3016 root 32w REG 253,0 13783 1052094 /var/log/libvirt/libxl/abcd.log libvirtd 3016 root 33r FIFO 0,8 0t0 129039 pipe libvirtd 3016 root 34w FIFO 0,8 0t0 129039 pipe libvirtd 3016 root 35u REG 0,37 0 4 /proc/xen/privcmd libvirtd 3016 root 36u unix 0xffff8807d398bb80 0t0 129040 socket libvirtd 3016 root 37r FIFO 0,8 0t0 129042 pipe libvirtd 3016 root 38w FIFO 0,8 0t0 129042 pipe libvirtd 3016 root 39r FIFO 0,8 0t0 129043 pipe libvirtd 3016 root 40w FIFO 0,8 0t0 129043 pipe libvirtd 3016 root 41r FIFO 0,8 0t0 129044 pipe libvirtd 3016 root 42w FIFO 0,8 0t0 129044 pipe if i destroy the doamin again and define them via "virsh define abcd.xml" and start them then via "virsh start abcd", the number of libvirtd threads don´t increase again and also the number of open files is the same. My question: is it normal that for transient guest domains the created libvirtd thread sill exists and also the open files after i destroy the doamin? or is it bug? thanks max

4 4

[libvirt] Entering freeze for libvirt-1.2.9
by Daniel Veillard 01 Oct '14

01 Oct '14

I have tagged the release candidate 1 for libvirt-1.2.9 in git, and pushed signed tarballs and rpms to the usual place: ftp://libvirt.org/libvirt/ This seems to work fine with my limited testing, but more people need to give it a try ! I expect to provide a release candidate 2 possibly on Monday, and shooting for a release on the 1st October if everything goes well. Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/

4 8

[libvirt] [libvirt-python PATCH] implement new tunable event
by Pavel Hrdina 30 Sep '14

30 Sep '14

Resovles: https://bugzilla.redhat.com/show_bug.cgi?id=1147639 Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- examples/event-test.py | 3 ++ libvirt-override-virConnect.py | 9 ++++++ libvirt-override.c | 64 ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 76 insertions(+) diff --git a/examples/event-test.py b/examples/event-test.py index cd85de3..be7a7d4 100644 --- a/examples/event-test.py +++ b/examples/event-test.py @@ -515,6 +515,8 @@ def myDomainEventDeviceRemovedCallback(conn, dom, dev, opaque): dom.name(), dom.ID(), dev)) def myDomainEventBlockJob2Callback(conn, dom, disk, type, status, opaque): print("myDomainEventBlockJob2Callback: Domain %s(%s) %s on disk %s %s" % (dom.name(), dom.ID(), blockJobTypeToString(type), disk, blockJobStatusToString(status))) +def myDomainEventTunableCallback(conn, dom, params, opaque): + print("myDomainEventTunableCallback: Domain %s(%s) %s" % (dom.name(), dom.ID(), params)) ########################################################################## # Network events @@ -624,6 +626,7 @@ def main(): vc.domainEventRegisterAny(None, libvirt.VIR_DOMAIN_EVENT_ID_PMSUSPEND_DISK, myDomainEventPMSuspendDiskCallback, None) vc.domainEventRegisterAny(None, libvirt.VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED, myDomainEventDeviceRemovedCallback, None) vc.domainEventRegisterAny(None, libvirt.VIR_DOMAIN_EVENT_ID_BLOCK_JOB_2, myDomainEventBlockJob2Callback, None) + vc.domainEventRegisterAny(None, libvirt.VIR_DOMAIN_EVENT_ID_TUNABLE, myDomainEventTunableCallback, None) vc.networkEventRegisterAny(None, libvirt.VIR_NETWORK_EVENT_ID_LIFECYCLE, myNetworkEventLifecycleCallback, None) diff --git a/libvirt-override-virConnect.py b/libvirt-override-virConnect.py index 218f266..7ad2469 100644 --- a/libvirt-override-virConnect.py +++ b/libvirt-override-virConnect.py @@ -188,6 +188,15 @@ cb(self, virDomain(self, _obj=dom), devAlias, opaque) return 0 + def _dispatchDomainEventTunableCallback(self, dom, params, cbData): + """Dispatches evetn to python user domain tunable event callbacks + """ + cb = cbData["cb"] + opaque = cbData["opaque"] + + cb(self, virDomain(self, _obj=dom), params, opaque) + return 0 + def domainEventDeregisterAny(self, callbackID): """Removes a Domain Event Callback. De-registering for a domain callback will disable delivery of this event type """ diff --git a/libvirt-override.c b/libvirt-override.c index c5017a5..8b3c503 100644 --- a/libvirt-override.c +++ b/libvirt-override.c @@ -6506,6 +6506,65 @@ libvirt_virConnectDomainEventDeviceRemovedCallback(virConnectPtr conn ATTRIBUTE_ } #endif /* LIBVIR_CHECK_VERSION(1, 1, 1) */ +#if LIBVIR_CHECK_VERSION(1, 2, 9) +static int +libvirt_virConnectDomainEventTunableCallback(virConnectPtr conn ATTRIBUTE_UNUSED, + virDomainPtr dom, + virTypedParameterPtr params, + int nparams, + void *opaque) +{ + PyObject *pyobj_cbData = (PyObject*)opaque; + PyObject *pyobj_dom; + PyObject *pyobj_ret = NULL; + PyObject *pyobj_conn; + PyObject *dictKey; + PyObject *pyobj_dict = NULL; + int ret = -1; + + LIBVIRT_ENSURE_THREAD_STATE; + + pyobj_dict = getPyVirTypedParameter(params, nparams); + if (!pyobj_dict) + goto cleanup; + + if (!(dictKey = libvirt_constcharPtrWrap("conn"))) + goto cleanup; + pyobj_conn = PyDict_GetItem(pyobj_cbData, dictKey); + Py_DECREF(dictKey); + + /* Create a python instance of this virDomainPtr */ + virDomainRef(dom); + if (!(pyobj_dom = libvirt_virDomainPtrWrap(dom))) { + virDomainFree(dom); + goto cleanup; + } + Py_INCREF(pyobj_cbData); + + /* Call the Callback Dispatcher */ + pyobj_ret = PyObject_CallMethod(pyobj_conn, + (char*)"_dispatchDomainEventTunableCallback", + (char*)"OOO", + pyobj_dom, pyobj_dict, pyobj_cbData); + + Py_DECREF(pyobj_cbData); + Py_DECREF(pyobj_dom); + + cleanup: + if (!pyobj_ret) { + DEBUG("%s - ret:%p\n", __FUNCTION__, pyobj_ret); + PyErr_Print(); + Py_XDECREF(pyobj_dict); + } else { + Py_DECREF(pyobj_ret); + ret = 0; + } + + LIBVIRT_RELEASE_THREAD_STATE; + return ret; + +} +#endif /* LIBVIR_CHECK_VERSION(1, 2, 9) */ static PyObject * libvirt_virConnectDomainEventRegisterAny(ATTRIBUTE_UNUSED PyObject *self, @@ -6594,6 +6653,11 @@ libvirt_virConnectDomainEventRegisterAny(ATTRIBUTE_UNUSED PyObject *self, cb = VIR_DOMAIN_EVENT_CALLBACK(libvirt_virConnectDomainEventDeviceRemovedCallback); break; #endif /* LIBVIR_CHECK_VERSION(1, 1, 1) */ +#if LIBVIR_CHECK_VERSION(1, 2, 9) + case VIR_DOMAIN_EVENT_ID_TUNABLE: + cb = VIR_DOMAIN_EVENT_CALLBACK(libvirt_virConnectDomainEventTunableCallback); + break; +#endif /* LIBVIR_CHECK_VERSION(1, 2, 9) */ case VIR_DOMAIN_EVENT_ID_LAST: break; } -- 2.0.4

2 2

[libvirt] [PATCH] Allow setting migration max downtime any time
by chris.a.st.pierre＠gmail.com 30 Sep '14

30 Sep '14

From: "Chris St. Pierre" <chris.a.st.pierre(a)gmail.com> This removes the artificial and unnecessary restriction that virDomainSetMaxDowntime() only be called while a migration is in progress. --- src/qemu/qemu_driver.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 6606154..7e53752 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -12023,12 +12023,6 @@ qemuDomainMigrateSetMaxDowntime(virDomainPtr dom, priv = vm->privateData; - if (priv->job.asyncJob != QEMU_ASYNC_JOB_MIGRATION_OUT) { - virReportError(VIR_ERR_OPERATION_INVALID, - "%s", _("domain is not being migrated")); - goto endjob; - } - VIR_DEBUG("Setting migration downtime to %llums", downtime); qemuDomainObjEnterMonitor(driver, vm); ret = qemuMonitorSetMigrationDowntime(priv->mon, downtime); -- 1.9.3

2 1

[libvirt] [PATCH] qemu: monitor: Avoid shadowing variable "devname" on FreeBSD
by Peter Krempa 30 Sep '14

30 Sep '14

FreeBSD's compiler complains that we shadow the symbol. Sigh. s/devname/dev_name/ --- Pushed as trivial && build-breaker. src/qemu/qemu_monitor_json.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index 150ff76..b3b6451 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -1816,7 +1816,7 @@ int qemuMonitorJSONGetAllBlockStatsInfo(qemuMonitorPtr mon, for (i = 0; i < virJSONValueArraySize(devices); i++) { virJSONValuePtr dev = virJSONValueArrayGet(devices, i); virJSONValuePtr stats; - const char *devname; + const char *dev_name; if (VIR_ALLOC(bstats) < 0) goto cleanup; @@ -1828,15 +1828,15 @@ int qemuMonitorJSONGetAllBlockStatsInfo(qemuMonitorPtr mon, goto cleanup; } - if (!(devname = virJSONValueObjectGetString(dev, "device"))) { + if (!(dev_name = virJSONValueObjectGetString(dev, "device"))) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("blockstats device entry was not " "in expected format")); goto cleanup; } - if (STRPREFIX(devname, QEMU_DRIVE_HOST_PREFIX)) - devname += strlen(QEMU_DRIVE_HOST_PREFIX); + if (STRPREFIX(dev_name, QEMU_DRIVE_HOST_PREFIX)) + dev_name += strlen(QEMU_DRIVE_HOST_PREFIX); if ((stats = virJSONValueObjectGet(dev, "stats")) == NULL || stats->type != VIR_JSON_TYPE_OBJECT) { @@ -1907,7 +1907,7 @@ int qemuMonitorJSONGetAllBlockStatsInfo(qemuMonitorPtr mon, goto cleanup; } - if (virHashAddEntry(hash, devname, bstats) < 0) + if (virHashAddEntry(hash, dev_name, bstats) < 0) goto cleanup; bstats = NULL; } -- 2.1.0

1 0

[libvirt] [libvirt-glib] gconfig: Add GVIR_CONFIG_DOMAIN_INPUT_DEVICE_KEYBOARD
by Zeeshan Ali (Khattak) 30 Sep '14

30 Sep '14

Add missing enum type for keyboard input device. --- libvirt-gconfig/libvirt-gconfig-domain-input.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libvirt-gconfig/libvirt-gconfig-domain-input.h b/libvirt-gconfig/libvirt-gconfig-domain-input.h index 252b6ca..83a0ec9 100644 --- a/libvirt-gconfig/libvirt-gconfig-domain-input.h +++ b/libvirt-gconfig/libvirt-gconfig-domain-input.h @@ -58,7 +58,8 @@ struct _GVirConfigDomainInputClass typedef enum { GVIR_CONFIG_DOMAIN_INPUT_DEVICE_MOUSE, - GVIR_CONFIG_DOMAIN_INPUT_DEVICE_TABLET + GVIR_CONFIG_DOMAIN_INPUT_DEVICE_TABLET, + GVIR_CONFIG_DOMAIN_INPUT_DEVICE_KEYBOARD } GVirConfigDomainInputDeviceType; typedef enum { -- 2.1.0

2 1

[libvirt] [PATCH 0/2] Fix migration with host-passthrough
by Ján Tomko 30 Sep '14

30 Sep '14

Ján Tomko (2): Don't verify CPU features with host-passthrough Also filter out non-migratable features out of host-passthrough src/cpu/cpu_x86.c | 14 ++++++-------- src/qemu/qemu_migration.c | 22 ++++++++++++---------- src/qemu/qemu_process.c | 5 +++++ 3 files changed, 23 insertions(+), 18 deletions(-) -- 1.8.5.5

2 6

[libvirt] CreateMachine: Input/output error
by Richard Weinberger 29 Sep '14

29 Sep '14

Hi! Sometimes libvirt (1.2.7) becomes unable to start any container. Logs show only: error : virDBusCall:1429 : error from service: CreateMachine: Input/output error It looks like dbus_connection_send_with_reply_and_block() returns EIO. Has anyone else seen this kind of issue? I'm currently a bit puzzled where to look for the root cause. Maybe it is related to dbus. -- Thanks, //richard

5 11

[libvirt] W/ commit 9e159b5: error from service: CreateMachine: Machine 'qemu-foo' already exists
by Kashyap Chamarthy 29 Sep '14

29 Sep '14

On Fedora 20 with: libvirt RPMs built from git commit: 9e159b521dbf18c6da6976e54e29c8553f831eb6 qemu-2.1.1-1.fc22.x86_64 Just start a guest: ----- $ virsh start ostack-controller error: Failed to start domain ostack-controller error: error from service: CreateMachine: Machine 'qemu-ostack-controller' already exists ----- QEMU CLI: ----- $ tail /var/log/libvirt/qemu/ostack-controller.log 2014-09-27 14:01:40.544+0000: starting up LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -name ostack-controller -S -machine pc-i440fx-1.6,accel=kvm,usb=off -cpu host -m 2048 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 24099854-24b2-4664-b425-a288114a43df -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/ostack-controller.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/ostack-controller.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x3,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:7b:f3:a2,bus=pci.0,addr=0x2 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on Domain id=8 is tainted: host-cpu 2014-09-27 14:01:40.550+0000: shutting down root@~$ ----- libvirtd is running: ----- $ systemctl status libvirtd libvirtd.service - Virtualization daemon Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled) Active: active (running) since Sat 2014-09-27 19:32:24 IST; 47min ago Docs: man:libvirtd(8) http://libvirt.org Main PID: 4569 (libvirtd) CGroup: /system.slice/libvirtd.service ├─1715 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --dhcp-script=/usr/libexec/libvirt_leaseshelper ├─1716 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --dhcp-script=/usr/libexec/libvirt_leaseshelper ├─1762 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/openstackvms.conf --dhcp-script=/usr/libexec/libvirt_leaseshelper ├─1763 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/openstackvms.conf --dhcp-script=/usr/libexec/libvirt_leaseshelper └─4569 /usr/sbin/libvirtd Sep 27 19:32:40 tesla libvirtd[4569]: 2014-09-27 14:02:40.887+0000: 4682: debug : virFileClose:99 : Closed fd 15 Sep 27 19:32:40 tesla libvirtd[4569]: 2014-09-27 14:02:40.887+0000: 4682: debug : virFileClose:99 : Closed fd 16 Sep 27 19:32:40 tesla libvirtd[4569]: 2014-09-27 14:02:40.887+0000: 4682: debug : virFileClose:99 : Closed fd 17 Sep 27 19:32:40 tesla libvirtd[4569]: 2014-09-27 14:02:40.887+0000: 4682: debug : virFileClose:99 : Closed fd 18 Sep 27 19:32:40 tesla libvirtd[4569]: 2014-09-27 14:02:40.887+0000: 4682: debug : virFileClose:99 : Closed fd 19 Sep 27 19:32:40 tesla libvirtd[4569]: 2014-09-27 14:02:40.887+0000: 4682: debug : virFileClose:99 : Closed fd 20 Sep 27 19:32:40 tesla libvirtd[4569]: 2014-09-27 14:02:40.887+0000: 4682: debug : virFileClose:99 : Closed fd 21 Sep 27 19:32:40 tesla libvirtd[4569]: 2014-09-27 14:02:40.887+0000: 4682: debug : virFileClose:99 : Closed fd 22 Sep 27 19:32:40 tesla libvirtd[4569]: 2014-09-27 14:02:40.887+0000: 4682: debug : virFileClose:99 : Closed fd 26 Sep 27 19:32:40 tesla libvirtd[4569]: 2014-09-27 14:02:40.887+0000: 4682: debug : virFileClose:99 : Closed fd 29 ----- >From the debug log, that's the only failure I see: [. . .] 2014-09-27 14:02:40.897+0000: 4569: debug : virEventPollDispatchHandles:494 : i=4 w=5 2014-09-27 14:02:40.897+0000: 4569: debug : virEventPollDispatchHandles:494 : i=5 w=6 2014-09-27 14:02:40.897+0000: 4569: debug : virEventPollDispatchHandles:508 : EVENT_POLL_DISPATCH_HANDLE: watch=6 events=1 2014-09-27 14:02:40.897+0000: 4569: debug : virNetlinkEventCallback:350 : dispatching to max 0 clients, called from event watch 6 2014-09-27 14:02:40.897+0000: 4569: debug : virNetlinkEventCallback:363 : event not handled. 2014-09-27 14:02:40.897+0000: 4569: debug : virEventPollDispatchHandles:494 : i=7 w=8 2014-09-27 14:02:40.897+0000: 4569: debug : virEventPollDispatchHandles:494 : i=8 w=9 2014-09-27 14:02:40.897+0000: 4569: debug : virEventPollDispatchHandles:508 : EVENT_POLL_DISPATCH_HANDLE: watch=9 events=1 2014-09-27 14:02:40.897+0000: 4569: debug : udevEventHandleCallback:1596 : udev action: 'remove' 2014-09-27 14:02:40.897+0000: 4569: debug : udevRemoveOneDevice:1359 : Failed to find device to remove that has udev name '/sys/devices/virtual/net/vn et0/queues/rx-0' [. . .] Searching the inter-webs, I see a few related old bugs, which indicate it's a QEMU bug of some sorts. Any hints? (Sorry, didn't dig deeper yet, /me is traveling). -- /kashyap

2 7

[libvirt] Is seems necessary to pass "migratable=no/yes" to qemu.
by zhang bo 29 Sep '14

29 Sep '14

The patch http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=de0aeafe9ce3eb414c8b5d… removes invtsc flag in the host-model CPU. I'm wondering, will it be better to pass args "migratable=no/yes" to qemu, and let qemu complete the remaining work? As that qemu has checked whether it's necessary to use invtsc or not. ---------- "invtsc is available only if using: -cpu host,migratable=no,+invtsc." http://git.qemu.org/?p=qemu.git;a=commit;h=120eee7d1fdb2eba15766cfff7b9bcdc… ---------- There's another problem, if we do not pass "migratable=no" to qemu. Consider if we set host mode to pass-through --------- <cpu mode='host-passthrough'> </cpu> --------- then the vm->def->cpu->features contains invtsc. however, qemu will automatically remove this cpu flag as that "migration=no" is not passed to it. thus, the guest will not start up. This problem is in fact caused by the patch: http://libvirt.org/git/?p=libvirt.git;a=commit;h=fba6bc47cbcabbe08d42279691…, it forbids guest domain to start up if the host has INVTSC while the guest(qemu) does not. ------------- for (i = 0; def->cpu && i < def->cpu->nfeatures; i++) { virCPUFeatureDefPtr feature = &def->cpu->features[i]; if (feature->policy != VIR_CPU_FEATURE_REQUIRE) continue; if (STREQ(feature->name, "invtsc") && !cpuHasFeature(guestcpu, feature->name)) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("host doesn't support invariant TSC")); goto cleanup; } } break; -------------- In conclusion: 1 Will it better to pass args "migratable=yes/no" to qemu rather than doing the mask-invtsc job in libvirt? 2 If the guest has "pass-through" cpu mode, then it's unable to start up, because qemu removes invtsc, and vm->def->cpu->features has it. It seems a BUG.

2 4