[libvirt] [PATCH] Do not require virtio-pci devices when using virtio-mmio
by Ján Tomko
On arm, we probe for virtio-*-pci devices, but use their
virtio-*-device variants.
Set the capabilities based on the -device variants as well,
to make them work with qemus with the PCI devices compiled out.
---
src/qemu/qemu_capabilities.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index ce6767c..3b49271 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -1499,6 +1499,7 @@ struct virQEMUCapsStringFlags virQEMUCapsObjectTypes[] = {
{ "virtio-scsi-pci", QEMU_CAPS_VIRTIO_SCSI },
{ "virtio-scsi-s390", QEMU_CAPS_VIRTIO_SCSI },
{ "virtio-scsi-ccw", QEMU_CAPS_VIRTIO_SCSI },
+ { "virtio-scsi-device", QEMU_CAPS_VIRTIO_SCSI },
{ "megasas", QEMU_CAPS_SCSI_MEGASAS },
{ "spicevmc", QEMU_CAPS_DEVICE_SPICEVMC },
{ "qxl-vga", QEMU_CAPS_DEVICE_QXL_VGA },
@@ -1515,6 +1516,7 @@ struct virQEMUCapsStringFlags virQEMUCapsObjectTypes[] = {
{ "virtio-rng-pci", QEMU_CAPS_DEVICE_VIRTIO_RNG },
{ "virtio-rng-s390", QEMU_CAPS_DEVICE_VIRTIO_RNG },
{ "virtio-rng-ccw", QEMU_CAPS_DEVICE_VIRTIO_RNG },
+ { "virtio-rng-device", QEMU_CAPS_DEVICE_VIRTIO_RNG },
{ "rng-random", QEMU_CAPS_OBJECT_RNG_RANDOM },
{ "rng-egd", QEMU_CAPS_OBJECT_RNG_EGD },
{ "spapr-nvram", QEMU_CAPS_DEVICE_NVRAM },
--
2.0.5
9 years, 8 months
[libvirt] [libvirt-glib] Support setting of compat XML node
by Richa Sehgal
This change adds support for setting of compat XML node in libvirt
gconfig storage volumes target
---
libvirt-gconfig/libvirt-gconfig-storage-vol-target.c | 13 +++++++++++++
libvirt-gconfig/libvirt-gconfig-storage-vol-target.h | 2 ++
libvirt-gconfig/libvirt-gconfig.sym | 5 +++++
libvirt-gconfig/tests/test-domain-create.c | 1 +
4 files changed, 21 insertions(+)
diff --git a/libvirt-gconfig/libvirt-gconfig-storage-vol-target.c b/libvirt-gconfig/libvirt-gconfig-storage-vol-target.c
index d3151d1..b72b304 100644
--- a/libvirt-gconfig/libvirt-gconfig-storage-vol-target.c
+++ b/libvirt-gconfig/libvirt-gconfig-storage-vol-target.c
@@ -99,3 +99,16 @@ void gvir_config_storage_vol_target_set_permissions(GVirConfigStorageVolTarget *
"permissions",
GVIR_CONFIG_OBJECT(perms));
}
+
+/**
+ * gvir_config_storage_vol_target_set_compat:
+ * @compat: (allow-none):
+ */
+void gvir_config_storage_vol_target_set_compat(GVirConfigStorageVolTarget *target,
+ const char *compat)
+{
+ g_return_if_fail(GVIR_CONFIG_IS_STORAGE_VOL_TARGET(target));
+
+ gvir_config_object_set_node_content(GVIR_CONFIG_OBJECT(target),
+ "compat", compat);
+}
diff --git a/libvirt-gconfig/libvirt-gconfig-storage-vol-target.h b/libvirt-gconfig/libvirt-gconfig-storage-vol-target.h
index b572381..c165e2b 100644
--- a/libvirt-gconfig/libvirt-gconfig-storage-vol-target.h
+++ b/libvirt-gconfig/libvirt-gconfig-storage-vol-target.h
@@ -67,6 +67,8 @@ void gvir_config_storage_vol_target_set_format(GVirConfigStorageVolTarget *targe
const char *format);
void gvir_config_storage_vol_target_set_permissions(GVirConfigStorageVolTarget *target,
GVirConfigStoragePermissions *perms);
+void gvir_config_storage_vol_target_set_compat(GVirConfigStorageVolTarget *target,
+ const char *compat);
G_END_DECLS
diff --git a/libvirt-gconfig/libvirt-gconfig.sym b/libvirt-gconfig/libvirt-gconfig.sym
index 8614126..407a52f 100644
--- a/libvirt-gconfig/libvirt-gconfig.sym
+++ b/libvirt-gconfig/libvirt-gconfig.sym
@@ -714,4 +714,9 @@ global:
gvir_config_domain_cpu_set_model;
} LIBVIRT_GCONFIG_0.1.8;
+LIBVIRT_GCONFIG_0.2.0 {
+global:
+ gvir_config_storage_vol_target_set_compat;
+} LIBVIRT_GCONFIG_0.1.9;
+
# .... define new API here using predicted next version number ....
diff --git a/libvirt-gconfig/tests/test-domain-create.c b/libvirt-gconfig/tests/test-domain-create.c
index eb4b945..66f618b 100644
--- a/libvirt-gconfig/tests/test-domain-create.c
+++ b/libvirt-gconfig/tests/test-domain-create.c
@@ -482,6 +482,7 @@ int main(int argc, char **argv)
vol_target = gvir_config_storage_vol_target_new();
gvir_config_storage_vol_target_set_format(vol_target, "qcow2");
gvir_config_storage_vol_target_set_permissions(vol_target, perms);
+ gvir_config_storage_vol_target_set_compat(vol_target, "1.1");
g_object_unref(G_OBJECT(perms));
gvir_config_storage_vol_set_target(vol, vol_target);
g_object_unref(G_OBJECT(vol_target));
--
1.9.1
9 years, 8 months
[libvirt] [libvirt-glib] Support setting of compat XML node
by Richa Sehgal
This change adds support for setting of compat XML node in libvirt
gconfig storage volumes target
---
libvirt-gconfig/libvirt-gconfig-storage-vol-target.c | 13 +++++++++++++
libvirt-gconfig/libvirt-gconfig-storage-vol-target.h | 2 ++
libvirt-gconfig/libvirt-gconfig.sym | 5 +++++
libvirt-gconfig/tests/test-domain-create.c | 1 +
4 files changed, 21 insertions(+)
diff --git a/libvirt-gconfig/libvirt-gconfig-storage-vol-target.c b/libvirt-gconfig/libvirt-gconfig-storage-vol-target.c
index d3151d1..b72b304 100644
--- a/libvirt-gconfig/libvirt-gconfig-storage-vol-target.c
+++ b/libvirt-gconfig/libvirt-gconfig-storage-vol-target.c
@@ -99,3 +99,16 @@ void gvir_config_storage_vol_target_set_permissions(GVirConfigStorageVolTarget *
"permissions",
GVIR_CONFIG_OBJECT(perms));
}
+
+/**
+ * gvir_config_storage_vol_target_set_compat:
+ * @compat: (allow-none):
+ */
+void gvir_config_storage_vol_target_set_compat(GVirConfigStorageVolTarget *target,
+ const char *compat)
+{
+ g_return_if_fail(GVIR_CONFIG_IS_STORAGE_VOL_TARGET(target));
+
+ gvir_config_object_set_node_content(GVIR_CONFIG_OBJECT(target),
+ "compat", compat);
+}
diff --git a/libvirt-gconfig/libvirt-gconfig-storage-vol-target.h b/libvirt-gconfig/libvirt-gconfig-storage-vol-target.h
index b572381..c165e2b 100644
--- a/libvirt-gconfig/libvirt-gconfig-storage-vol-target.h
+++ b/libvirt-gconfig/libvirt-gconfig-storage-vol-target.h
@@ -67,6 +67,8 @@ void gvir_config_storage_vol_target_set_format(GVirConfigStorageVolTarget *targe
const char *format);
void gvir_config_storage_vol_target_set_permissions(GVirConfigStorageVolTarget *target,
GVirConfigStoragePermissions *perms);
+void gvir_config_storage_vol_target_set_compat(GVirConfigStorageVolTarget *target,
+ const char *compat);
G_END_DECLS
diff --git a/libvirt-gconfig/libvirt-gconfig.sym b/libvirt-gconfig/libvirt-gconfig.sym
index 8614126..407a52f 100644
--- a/libvirt-gconfig/libvirt-gconfig.sym
+++ b/libvirt-gconfig/libvirt-gconfig.sym
@@ -714,4 +714,9 @@ global:
gvir_config_domain_cpu_set_model;
} LIBVIRT_GCONFIG_0.1.8;
+LIBVIRT_GCONFIG_0.2.0 {
+global:
+ gvir_config_storage_vol_target_set_compat;
+} LIBVIRT_GCONFIG_0.1.9;
+
# .... define new API here using predicted next version number ....
diff --git a/libvirt-gconfig/tests/test-domain-create.c b/libvirt-gconfig/tests/test-domain-create.c
index eb4b945..66f618b 100644
--- a/libvirt-gconfig/tests/test-domain-create.c
+++ b/libvirt-gconfig/tests/test-domain-create.c
@@ -482,6 +482,7 @@ int main(int argc, char **argv)
vol_target = gvir_config_storage_vol_target_new();
gvir_config_storage_vol_target_set_format(vol_target, "qcow2");
gvir_config_storage_vol_target_set_permissions(vol_target, perms);
+ gvir_config_storage_vol_target_set_compat(vol_target, "1.1");
g_object_unref(G_OBJECT(perms));
gvir_config_storage_vol_set_target(vol, vol_target);
g_object_unref(G_OBJECT(vol_target));
--
1.9.1
9 years, 8 months
[libvirt] [PATCH] AUTHORS: Add my email address to AUTHORS.in
by Dmitry Guryanov
---
AUTHORS.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/AUTHORS.in b/AUTHORS.in
index 6673b3f..7e4359f 100644
--- a/AUTHORS.in
+++ b/AUTHORS.in
@@ -14,6 +14,7 @@ Claudio Bley <claudio.bley(a)gmail.com>
Cole Robinson <crobinso(a)redhat.com>
Daniel Berrange <berrange(a)redhat.com>
Daniel Veillard <veillard(a)redhat.com>
+Dmitry Guryanov <dguryanov(a)parallels.com>
Doug Goldstein <cardoe(a)gentoo.org>
Eric Blake <eblake(a)redhat.com>
Erik Skultety <eskultet(a)redhat.com>
--
2.1.0
9 years, 8 months
[libvirt] [PATCH v2 0/5] Refactor cgroup and qemuDomainHotplugVcpus
by John Ferlan
v1 here:
http://www.redhat.com/archives/libvir-list/2015-April/msg00126.html
John Ferlan (5):
cgroup: Introduce virCgroupNewThread
cgroup: Use virCgroupNewThread
qemu: qemuDomainHotplugVcpus - separate out the add cgroup
qemu: qemuDomainHotplugVcpus - separate out the del cgroup and pin
qemu: qemuDomainHotplugVcpus - separate out pin adjustment code
src/libvirt_private.syms | 4 +-
src/qemu/qemu_cgroup.c | 22 +++--
src/qemu/qemu_driver.c | 233 ++++++++++++++++++++++++++++++-----------------
src/util/vircgroup.c | 144 +++++++----------------------
src/util/vircgroup.h | 30 +++---
5 files changed, 208 insertions(+), 225 deletions(-)
--
2.1.0
9 years, 8 months
Re: [libvirt] [openstack-dev] [nova] The risk of hanging when shutdown instance.
by zhang bo
On 2015/3/28 18:06, Rui Chen wrote:
> Thank you for reply, Chris.
>
>
> 2015-03-27 23:15 GMT+08:00 Chris Friesen <chris.friesen(a)windriver.com <mailto:chris.friesen@windriver.com>>:
>
> On 03/26/2015 07:44 PM, Rui Chen wrote:
>
> Yes, you are right, but we found our instance hang at first dom.shutdown() call,
> if the dom.shutdown() don't return, there is no chance to execute dom.destroy(),
> right?
>
>
> Correct. The code is written assuming dom.shutdown() cannot block indefinitely.
>
> The libvirt docs at "https://libvirt.org/html/__libvirt-libvirt-domain.html#__virDomainShutdown <https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainShutdown>" say "...this command returns as soon as the shutdown request is issued rather than blocking until the guest is no longer running."
>
> If dom.shutdown() blocks indefinitely, then that's a libvirt bug.
>
>
> Chris
The API virDomainShutdown's description is out of date, it's not correct.
In fact, virDomainShutdown would block or not, depending on its mode. If it's in mode *agent*, then it would be blocked until qemu founds that the guest actually got down.
Otherwise, if it's in mode *acpi*, then it would return immediately.
Thus, maybe further more work need to be done in Openstack.
What's your opinions, Michal and Daniel (from libvirt.org), and Chris (from openstack.org) :)
9 years, 8 months
[libvirt] [PATCH] conf: fix crash when parse a invalid vcpus in virDomainThreadSchedParse()
by Luyao Huang
When we set a invalid vcpus in /domain/cputune/vcpusched, like this:
<vcpusched vcpus='0,^0' scheduler='fifo' priority='1'/>
libvirtd will get segfault, because we will free bitmap (here is sp->ids) we
passed in virBitmapParse() then return -1, then call virBitmapIsAllClear() with
a null pointer bitmap will crash libvirtd.
Split this check in two part to report parse error when cannot parse vcpus,
and report invalid argument error when the cpu number is not correct.
virBitmapIsAllClear (bitmap=0x0) at util/virbitmap.c:649
649 for (i = 0; i < bitmap->map_len; i++)
(gdb) bt
#0 virBitmapIsAllClear (bitmap=0x0) at util/virbitmap.c:649
#1 0x00007f28322f1245 in virDomainThreadSchedParse at conf/domain_conf.c:13464
#2 0x00007f283238aec8 in virDomainDefParseXML at conf/domain_conf.c:14059
#3 0x00007f2832390ddb in virDomainDefParseNode at conf/domain_conf.c:15588
#4 0x00007f2832390f02 in virDomainDefParse at conf/domain_conf.c:15530
#5 0x00007f2832390f53 in virDomainDefParseString at conf/domain_conf.c:15546
#6 0x00007f2819d8e8de in qemuDomainDefineXMLFlags at qemu/qemu_driver.c:7385
Signed-off-by: Luyao Huang <lhuang(a)redhat.com>
---
src/conf/domain_conf.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 1763305..46dfea1 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -13473,12 +13473,11 @@ virDomainThreadSchedParse(xmlNodePtr node,
goto error;
}
- if (!virBitmapParse(tmp, 0, &sp->ids,
- VIR_DOMAIN_CPUMASK_LEN) ||
- virBitmapIsAllClear(sp->ids) ||
- virBitmapNextSetBit(sp->ids, -1) < minid ||
- virBitmapLastSetBit(sp->ids) > maxid) {
+ if (virBitmapParse(tmp, 0, &sp->ids, VIR_DOMAIN_CPUMASK_LEN) < 0)
+ goto error;
+ if (virBitmapNextSetBit(sp->ids, -1) < minid ||
+ virBitmapLastSetBit(sp->ids) > maxid) {
virReportError(VIR_ERR_XML_ERROR,
_("Invalid value of '%s': %s"),
name, tmp);
--
1.8.3.1
9 years, 8 months
[libvirt] [PATCH v3 00/14] parallels: implement managed save
by Dmitry Guryanov
This patch series is intended to implement all needed code, so
that suspend/resume in openstack nova will work.
It implements .domainHasManagedSaveImage, .domainManagedSave
and .domainManagedSaveRemove functions.
It's not possible to change VM configuration, if it
is in suspended state in PCS. It's possible for containers,
but it has different meaning from the same action in libvirt:
libvirt stores domain config in a save file and restores
it if a user decided to start domain. But if the user discarded
state file - domain will have new configuration.
PCS doesn't store domain config for containers, so it will
have new configuration either if the user will start it from,
save file or discard state file and start after that.
So the idea is to forbid changing domain configuration, if
a domain is in managed saved state. We can't forbid calling
this function in this state, because openstack/nova calls
virDomainDefineXML in suspended state. So I compare
current virDomainDef with the new one. And if there are
no changes - function does nothing and returns success.
Dmitry Guryanov (14):
parallels: fix headers in parallels_sdk.h
parallels: split prlsdkDomainChangeState function
parallels: implement virDomainManagedSave
parallels: report, that cdroms are readonly
parallels: add controllers in prlsdkLoadDomain
parallels: fill adapter model in virDomainNetDef
parallels: don't fill net adapter model for containers
conf: add VIR_DOMAIN_VIDEO_TYPE_PARALLELS video type
conf: return proper default video type for parallels
conf: add input device type for parallels containers
parallels: add implicit input devices
conf: fix virDomainDefParseXML for parallels
conf: fix virDomainDefFormatInternal for parallels
parallels: fix virDomainDefineXML for domain in saved state
src/conf/domain_conf.c | 70 +++++++++++++++++++---
src/conf/domain_conf.h | 2 +
src/parallels/parallels_driver.c | 104 ++++++++++++++++++++++++++++++--
src/parallels/parallels_sdk.c | 124 ++++++++++++++++++++++++++++++++++-----
src/parallels/parallels_sdk.h | 17 ++++--
src/qemu/qemu_command.c | 6 +-
6 files changed, 285 insertions(+), 38 deletions(-)
--
2.1.0
9 years, 8 months
Re: [libvirt] [Qemu-devel] can't bot from scsi http cdrom
by Stefan Hajnoczi
On Mon, Apr 06, 2015 at 01:15:24PM +0300, Vasiliy Tolstov wrote:
> Hi. I'm try to boot from http cdrom and can't do that in case of scsi:
> <disk type='network' device='cdrom'>
> <driver name='qemu' type='raw' cache='unsafe'/>
> <source protocol='http' name='/vps/rescue-4.5.2'>
> <host name='xx.xx' port='80'/>
> </source>
> <backingStore/>
> <target dev='sdb' bus='scsi'/>
> <readonly/>
> <alias name='scsi0-0-0-1'/>
> <address type='drive' controller='0' bus='0' target='0' unit='1'/>
> </disk>
>
> but in case of ide:
> <disk type='network' device='cdrom'>
> <driver name='qemu' type='raw' cache='unsafe'/>
> <source protocol='http' name='/vps/rescue-4.5.2'>
> <host name='xx.xx' port='80'/>
> </source>
> <backingStore/>
> <target dev='hda' bus='ide'/>
> <readonly/>
> <alias name='ide0-0-0'/>
> <address type='drive' controller='0' bus='0' target='0' unit='0'/>
> </disk>
>
> all works fine.
>
> libvirt - 1.2.10
> qemu - 2.0.0
> seabios - 1.7.5
This is a libvirt question. I have CCed the libvirt mailing list.
Stefan
9 years, 8 months
[libvirt] possible bug regarding cpu flag 'pclmulqdq' in cpu_map.xml
by Sven Kieske
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
laine on IRC was so kind to redirect me to this list, so
I didn't file a BZ at:
https://bugzilla.redhat.com/enter_bug.cgi?product=Virtualization%20Tools
&component=libvirt
yet.
Please keep me CC'ed as I'm not subscribed to the list.
So here is my bug report:
Description of problem:
I believe the flag "pclmulqdq" is wrongly spelled in cpu_map.xml
leading to wrong cpu
being detected:
Version-Release number of selected component (if applicable):
current master:
https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/cpu/cpu_map.xml;h=21
10c0b9b2a2a70f0334b2ff63416bd1b704b669;hb=HEAD
How reproducible:
always
Steps to Reproduce:
1.install e.g. ovirt, or some other libvirt consumer on a system with
a cpu like intel xeon E3-1230
2. it will get reported as nehalem
3.
Actual results:
cpu gets reported as "nehalem"
Expected results:
cpu gets reported as "sandy bridge"
Additional info:
I found no real info on this flag:
grep --color pclmuldq /usr/share/libvirt/cpu_map.xml
<feature name='pclmuldq'>
<feature name='pclmuldq'/>
<feature name='pclmuldq'/>
wikipedia (not always right, I know) and Intel
just seem to know the flag
'pclmulqdq'
See:
https://en.wikipedia.org/wiki/CLMUL_instruction_set
https://en.wikipedia.org/wiki/CPUID#EAX.3D1:_Processor_Info_and_Feature_
Bits
https://software.intel.com/file/36945
But the Intel documentation is vast and I might have
missed information on their website.
So please check if this is the correct cpu flag indeed.
Thanks!
PS: If this is a real bug, it goes way back
into el6 released versions of libvirt, and
I would like to see a backport, if possible!
Here is the BZ which introduced the flag:
https://bugzilla.redhat.com/show_bug.cgi?id=761005
I guess this got wrongly typed, when you look
at this comment, which has the correct notation:
https://bugzilla.redhat.com/show_bug.cgi?id=761005#c16
- --
Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhaus
en
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad
Oeynhausen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJVJpqoAAoJEMby9TMDAbQRFlcP/1xajVdbv3fNfQPzJ3wIRa6M
szkdbqMkI7HZTBjGvgSFXcf/ufb2RNfCU7AXpMi+FsE+oMB6qafke/J5VM6H/GUW
TWuOy1wXz6QLxkP/p0VeU6ZX28XmwPOUMPcCQVhexIAbrmpgYCY42iaiEZUStcNp
QQIqapOR6kL57WazTjY0U5GlGkV479oYlStF3E4maaJz+viNUqD6pE3WhXTbpcsu
1U1hPYANkfaMiXglm4MqpLklHw2PqgSfRvPzH58JStByuizPiWXZ9h42xE5ykVkW
B7sw4XBSVk0mH99LNwnXC/VIw4pPz7uecTSbxdubZ/p4vvlG8JdszOekMfZVhy1+
ic93VPB+jSbiRGjWx8jkyYAsVOREaPBbmFF3ioLkAo9eVl8v8MXcBNppQQASVv7R
vidSBu4qAVeu3ghmY5L+zEqTT3cG8pDcqzrFcELOtY1b6qsOOksgUxiylFv25g6F
QPoDZpkpTvJ8YjOZx4H3ZjlfPQBhvBqd3QESNR8fKBUcxgxfGRwBVVU+14otvElE
buEhBux0DvEfYrLbbiJtlGFtBmuz28RToPM1bmj52ujnGS1+0xYYYrHL35GhwnPc
pvJ8mxAIRMYTdhn5eMsIh50N3uxz9Zky0CU8DJZ5St2Fsds3n7fR7Oao+PXOsOX1
mtJPsI1bYnxJ4RYVaIzk
=ergB
-----END PGP SIGNATURE-----
9 years, 8 months
