[libvirt] increase number of libvirt threads by starting tansient guest doamin - is it a bug?
by ustermann78＠web.de
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
10 years, 6 months
[libvirt] [libvirt-python PATCH] implement new tunable event
by Pavel Hrdina
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
10 years, 6 months
[libvirt] [PATCH] Allow setting migration max downtime any time
by chris.a.st.pierre＠gmail.com
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
10 years, 6 months
[libvirt] [PATCH] qemu: monitor: Avoid shadowing variable "devname" on FreeBSD
by Peter Krempa
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
10 years, 6 months
[libvirt] [libvirt-glib] gconfig: Add GVIR_CONFIG_DOMAIN_INPUT_DEVICE_KEYBOARD
by Zeeshan Ali (Khattak)
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
10 years, 6 months
[libvirt] [PATCH 0/2] Fix migration with host-passthrough
by Ján Tomko
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
10 years, 6 months
[libvirt] CreateMachine: Input/output error
by Richard Weinberger
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
10 years, 6 months
[libvirt] W/ commit 9e159b5: error from service: CreateMachine: Machine 'qemu-foo' already exists
by Kashyap Chamarthy
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
10 years, 6 months
[libvirt] Is seems necessary to pass "migratable=no/yes" to qemu.
by zhang bo
The patch
http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=de0aeafe9ce3eb414c8b...
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=120eee7d1fdb2eba15766cfff7b9bc...
----------
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=fba6bc47cbcabbe08d422796...,
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.
10 years, 6 months
