[libvirt] Device backend in another domain (xen)
by Marek Marczykowski
Hi all,
Xen have (AFAIK unique) feature of having backend device in other domU
(sometimes called driver domain) instead of dom0. Currently libxl support it
for disk and network devices, but in general it is valid for any device
(perhaps excluding PCI). Current implementation requires ID of backend domain
to be specified during device attach/domain startup. There are some upcoming
patches to allow also use domain name.
I'd like to add support for it into libvirt. The question is how specify
domain reference. The simplest approach is to use direct domain ID, logically
it fits in <source/> tag, so something like:
<disk type='file'>
<source file='/path/to/file/inside/domain/7' domid='7'/>
<target dev='xvdb'/>
</disk>
<interface type='bridge'>
<source bridge='name-of-bridge-in-domiain-7' domid='7'/>
</interface>
This have obvious limitation that domain ID changes with each domain restart.
But perhaps more correct approach is to use name or UUID?
Extending <source/> tag is right thing to do? Or should I add a new tag
(<backenddomain uuid='...'/> ? )?
Regarding implementation I need some hints how to do the value verification
(check if domain exists at least). If it has to be done in domain_conf.c
(during XML parsing) it will require predetermined domain load order, which
IMHO isn't acceptable. So perhaps the check should be done at domain
startup/device attach (by driver)?
In any case: is it possible at all to check if domain with given name/UUID
exists in scope of domain_conf.c? It looks like it requires connection
reference, which isn't passed to virDomain*DefParseXML.
--
Best Regards,
Marek Marczykowski
Invisible Things Lab
11 years, 7 months
[libvirt] [PATCH 1/3] Remove support for old kernels lacking private devpts
by Daniel P. Berrange
From: "Daniel P. Berrange" <berrange(a)redhat.com>
Early on kernel support for private devpts was not widespread,
so we had compatibiltiy codepaths. Such old kernels are not
seriously used for LXC these days, so the compat code can go
away
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
src/lxc/lxc_controller.c | 28 +++++++++-------------------
1 file changed, 9 insertions(+), 19 deletions(-)
diff --git a/src/lxc/lxc_controller.c b/src/lxc/lxc_controller.c
index 1d1443c..cede445 100644
--- a/src/lxc/lxc_controller.c
+++ b/src/lxc/lxc_controller.c
@@ -1252,8 +1252,9 @@ virLXCControllerSetupDevPTS(virLXCControllerPtr ctrl)
}
if (access(ctrl->devptmx, R_OK) < 0) {
- VIR_WARN("Kernel does not support private devpts, using shared devpts");
- VIR_FREE(ctrl->devptmx);
+ virReportSystemError(ENOSYS, "%s",
+ _("Kernel does not support private devpts"));
+ goto cleanup;
}
ret = 0;
@@ -1278,24 +1279,13 @@ virLXCControllerSetupConsoles(virLXCControllerPtr ctrl,
size_t i;
for (i = 0 ; i < ctrl->nconsoles ; i++) {
- if (ctrl->devptmx) {
- VIR_DEBUG("Opening tty on private %s", ctrl->devptmx);
- if (lxcCreateTty(ctrl->devptmx,
- &ctrl->consoles[i].contFd,
- &containerTTYPaths[i]) < 0) {
- virReportSystemError(errno, "%s",
- _("Failed to allocate tty"));
- return -1;
- }
- } else {
- VIR_DEBUG("Opening tty on shared /dev/ptmx");
- if (virFileOpenTty(&ctrl->consoles[i].contFd,
- &containerTTYPaths[i],
- 0) < 0) {
- virReportSystemError(errno, "%s",
+ VIR_DEBUG("Opening tty on private %s", ctrl->devptmx);
+ if (lxcCreateTty(ctrl->devptmx,
+ &ctrl->consoles[i].contFd,
+ &containerTTYPaths[i]) < 0) {
+ virReportSystemError(errno, "%s",
_("Failed to allocate tty"));
- return -1;
- }
+ return -1;
}
}
return 0;
--
1.7.11.7
11 years, 7 months
[libvirt] [RFC] Per machine type qemu capability detection
by Peter Krempa
Hi,
qemu recently added a qmp/hmp command ("get-cpu-max") to determine
maximum number of supported CPUs for a VM. The output of this command
depends on the machine type that is used when it is called. The problem
here is that libvirt uses "-M none" while detecting capabilities and
with that machine type the get-cpu-max command returns always 1.
My question is: Is it worthwhile to do per machine type capability
detection? It definitely isn't worth doing just for the get-cpu-max
support, but it might be needed for Q35 or other stuff that may depend
on the actual machine type used.
Pros of this approach:
----------------------
- (possibly) more accurate capabilities
Cons:
-----
- ~10x more qemus started on libvirtd startup (one per machine type)
Thanks for your opinions.
Peter
11 years, 7 months
[libvirt] [RFC 0/5] X86CPU "feature-words" & "filtered-features" properties (v2)
by Eduardo Habkost
Changes v2:
* Added "filtered-features" properties
* Removed the non-qapi version and kept only the qapi version of the code
* Moved the new types to qapi-schema.json instead of creating
cpu-qapi-schema.json
* Rebased on top of "feature words array" series
Git tree:
https://github.com/ehabkost/qemu-hacks/tree/work/cpu-raw-feature-props-v2
git://github.com/ehabkost/qemu-hacks.git work/cpu-raw-feature-props-v2
Description:
As the work to get X86CPU subclasses static properties defined is taking very
long to get reviewed and we risk not getting it finished in 1.5, I am sending
an alternative mechanism to allow libvirt to probe for CPU model information.
It's interesting to note that this alternative solution is actually _easier_ to
use for libvirt, because libvirt logic is already based on CPUID bit values, not
"feature names", so it should be very easy to convert the current libvirt code
that (incorrectly) query the host CPU directly for available features to instead
start QEMU with "-cpu host" and use the "feature-words" array information to
find out which CPU features are supported by the host.
The "feature-words" property will have two main use cases:
* Checking host capabilities, by checking the features of the "host"
CPU model;
* Checking which features are enabled on each CPU model.
The "filtered-features" property will have two main use cases:
* Allowing libvirt to emulate the "check" & "enforce" flags while collecting
more detailted data about the missing features;
* Allowing libvirt to probe for CPU model information even if host features
are missing (it can simply combine the "feature-words" and
"filtered-features" values to get the full CPU model definition)
Example output:
$ ./QMP/qmp --path=/tmp/m qom-get --path=/machine/unattached/device[1] --property=feature-words
item[0].cpuid-register: EDX
item[0].cpuid-input-eax: 1
item[0].features: 126614521
item[1].cpuid-register: ECX
item[1].cpuid-input-eax: 1
item[1].features: 2155880449
item[2].cpuid-register: EBX
item[2].cpuid-input-eax: 7
item[2].features: 0
item[2].cpuid-input-ecx: 0
item[3].cpuid-register: EDX
item[3].cpuid-input-eax: 2147483649
item[3].features: 563346425
item[4].cpuid-register: ECX
item[4].cpuid-input-eax: 2147483649
item[4].features: 101
item[5].cpuid-register: EDX
item[5].cpuid-input-eax: 3221225473
item[5].features: 0
item[6].cpuid-register: EAX
item[6].cpuid-input-eax: 1073741825
item[6].features: 0
item[7].cpuid-register: EDX
item[7].cpuid-input-eax: 2147483658
item[7].features: 0
Eduardo Habkost (5):
target-i386: Add ECX information to FeatureWordInfo
target-i386: Add "feature-words" property
target-i386: Use FeatureWord loop on filter_features_for_kvm()
target-i386: Introduce X86CPU.filtered_features field
target-i386: Add "filtered-features" property to X86CPU
.gitignore | 2 +
Makefile.objs | 7 +++-
qapi-schema.json | 32 +++++++++++++++
target-i386/cpu-qom.h | 3 ++
target-i386/cpu.c | 110 +++++++++++++++++++++++++++++++++++---------------
5 files changed, 121 insertions(+), 33 deletions(-)
--
1.8.1.4
11 years, 7 months
[libvirt] language bindings
by Vasiliy Tolstov
Hello. I'm newbie in libvirt world and not able to find answer for my
question in google.
If i want to create binding for some language (for example go) is that
possible do not use libvirt C library and talk to libvirtd via some
rpc protocol? For example json or internal binary..
is that possible to talk to libvirtd not using C library?
--
Vasiliy Tolstov,
e-mail: v.tolstov(a)selfip.ru
jabber: vase(a)selfip.ru
11 years, 7 months
Re: [libvirt] [Qemu-devel] attaching disk to paused guest
by Stefan Hajnoczi
On Wed, Apr 3, 2013 at 1:05 PM, Liron Aravot <laravot(a)redhat.com> wrote:
> does qemu support attaching disk to a paused guest? Does it makes sense to allow this operation?
Yes, it works. I tested it via libvirt:
$ virsh start vm
$ cat >/tmp/disk.xml
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='path/to/new_disk.img'/>
<target dev='vdb' bus='virtio'/>
<alias name='virtio-disk1'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x08'
function='0x0'/>
</disk>
^D
$ virsh suspend vm
$ virsh list
Id Name State
----------------------------------------------------
1 vm paused
$ virsh attach-device vm /tmp/disk.xml
Device attached successfully
$ virsh resume vm
The issue with hotplug is that it may involve guest cooperation. This
is not possible when the guest is paused, but attaching a new
virtio-blk adapter is okay because we'll just have pending PCI hotplug
notifications when the guest is resumed.
Hot unplug is the nasty case because the guest OS isn't running and
cannot terminate its guest driver for the device. Because of this,
both network adapters and disks in QEMU try to clean up after
themselves and libvirt does not need to wait for the guest to
acknowledge hot unplug.
I think both hotplug and hot unplug should work fine while the guest is paused.
Stefan
11 years, 7 months
[libvirt] [PATCH v3 00/11] Add support for guests with TPM passthrough device
by Stefan Berger
Hello!
The following set of patches adds support to libvirt for
adding a TPM passthrough device to a QEMU guest. Support for
this was recently accepted into QEMU.
This set of patches borrows a lot from the recently added support
for rng's.
Regards,
Stefan
---
v2->v3:
- followed tree to 03122d7b
- some bits fixed
v1->v2:
- Followed Daniel Berrange's comments
(except for the one on de-consolidating the JSON monitor code)
11 years, 7 months
[libvirt] [PATCH] storage: Fix volume cloning for logical volume.
by Atsushi Kumagai
When creating a logical volume with virStorageVolCreateXMLFrom,
"qemu-img convert" is called internally if clonevol is a file volume.
Then, vol->target.format is used as output_fmt parameter but the
target.format of logical volumes is always 0 because logical volumes
haven't the volume format type element.
Fortunately, 0 was treated as RAW file format before commit f772b3d9,
so there was no problem. But now, 0 is treated as the type of none,
qemu-img fails with "Unknown file format 'none'".
This patch fixes this issue by treating output block devices as RAW
file format like for input block devices.
Signed-off-by: Atsushi Kumagai <kumagai-atsushi(a)mxc.nes.nec.co.jp>
diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c
index bb58d4a..2551f1f 100644
--- a/src/storage/storage_backend.c
+++ b/src/storage/storage_backend.c
@@ -652,7 +652,12 @@ virStorageBackendCreateQemuImgCmd(virConnectPtr conn,
unsigned long long int size_arg;
bool preallocate = false;
- const char *type = virStorageFileFormatTypeToString(vol->target.format);
+ /* Treat output block devices as 'raw' format */
+ const char *type =
+ virStorageFileFormatTypeToString(vol->type == VIR_STORAGE_VOL_BLOCK ?
+ VIR_STORAGE_FILE_RAW :
+ vol->target.format);
+
const char *backingType = vol->backingStore.path ?
virStorageFileFormatTypeToString(vol->backingStore.format) : NULL;
--
1.7.1
11 years, 7 months
[libvirt] [PATCH] Add support for SD cards in nodedev driver
by Daniel P. Berrange
From: "Daniel P. Berrange" <berrange(a)redhat.com>
The nodedev driver currently only detects harddisk, cdrom
and floppy devices. This adds support for SD cards, which
are common storage for ARM devices, eg the Google ChromeBook
<device>
<name>block_mmcblk0_0xb1c7c08b</name>
<parent>computer</parent>
<capability type='storage'>
<block>/dev/mmcblk0</block>
<drive_type>sd</drive_type>
<serial>0xb1c7c08b</serial>
<size>15758000128</size>
<logical_block_size>512</logical_block_size>
<num_blocks>30777344</num_blocks>
</capability>
</device>
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
src/node_device/node_device_udev.c | 41 ++++++++++++++++++++++++++++++++++++++
1 file changed, 41 insertions(+)
diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c
index cb11e5f..362a47f 100644
--- a/src/node_device/node_device_udev.c
+++ b/src/node_device/node_device_udev.c
@@ -952,6 +952,35 @@ static int udevProcessFloppy(struct udev_device *device,
return udevProcessRemoveableMedia(device, def, has_media);
}
+
+static int udevProcessSD(struct udev_device *device,
+ virNodeDeviceDefPtr def)
+{
+ union _virNodeDevCapData *data = &def->caps->data;
+ int ret = 0;
+
+ if (udevGetUint64SysfsAttr(device,
+ "size",
+ &data->storage.num_blocks) == PROPERTY_ERROR) {
+ goto out;
+ }
+
+ if (udevGetUint64SysfsAttr(device,
+ "queue/logical_block_size",
+ &data->storage.logical_block_size)
+ == PROPERTY_ERROR) {
+ goto out;
+ }
+
+ data->storage.size = data->storage.num_blocks *
+ data->storage.logical_block_size;
+
+out:
+ return ret;
+}
+
+
+
/* This function exists to deal with the case in which a driver does
* not provide a device type in the usual place, but udev told us it's
* a storage device, and we can make a good guess at what kind of
@@ -1056,6 +1085,13 @@ static int udevProcessStorage(struct udev_device *device,
data->storage.drive_type = strdup("floppy");
if (!data->storage.drive_type)
goto out;
+ } else if ((udevGetIntProperty(device, "ID_DRIVE_FLASH_SD",
+ &tmp_int, 0) == PROPERTY_FOUND) &&
+ (tmp_int == 1)) {
+
+ data->storage.drive_type = strdup("sd");
+ if (!data->storage.drive_type)
+ goto out;
} else {
/* If udev doesn't have it, perhaps we can guess it. */
@@ -1071,6 +1107,8 @@ static int udevProcessStorage(struct udev_device *device,
ret = udevProcessDisk(device, def);
} else if (STREQ(def->caps->data.storage.drive_type, "floppy")) {
ret = udevProcessFloppy(device, def);
+ } else if (STREQ(def->caps->data.storage.drive_type, "sd")) {
+ ret = udevProcessSD(device, def);
} else {
VIR_DEBUG("Unsupported storage type '%s'",
def->caps->data.storage.drive_type);
@@ -1082,6 +1120,7 @@ static int udevProcessStorage(struct udev_device *device,
}
out:
+ VIR_DEBUG("Storage ret=%d", ret);
return ret;
}
@@ -1338,6 +1377,8 @@ static int udevAddOneDevice(struct udev_device *device)
out:
if (ret != 0) {
+ VIR_DEBUG("Discarding device %d %p %s", ret, def,
+ def ? def->sysfs_path : "");
virNodeDeviceDefFree(def);
}
--
1.8.1.4
11 years, 7 months
