[PATCH] feature: Ceph rbd create with data pool attributes set support.
In some cases, we may use another pool to store the data and one pool to
store the meta data of the rbd vol, so it is to use another interface to
create the rbd vol, rbd_create4, required.
This patch add the feature with xml configure is like as below:
rbd_pool
Here we add one item rbdimageoption to set the attributions used when
create rbd vol.
If the option is not set, then the origin interface rbd_create is
called as before.
Signed-off-by: Guozhonghua
---
src/conf/storage_conf.c | 205 ++
src/conf/storage_conf.h | 33 +
src/storage/storage_backend_rbd.c | 123 +-
3 files changed, 358 insertions(+), 3 deletions(-)
diff --git a/src/conf/storage_conf.c b/src/conf/storage_conf.c
index f5a9636ce2..ac6c700ac1 100644
--- a/src/conf/storage_conf.c
+++ b/src/conf/storage_conf.c
@@ -461,6 +461,14 @@ virStoragePoolSourceDeviceClear(virStoragePoolSourceDevice
*dev)
}
+void
+virRbdImageOptionClear(virRbdImageOptionsPtr rbd_image_option)
+{
+ VIR_FREE(rbd_image_option->journal_pool);
+ VIR_FREE(rbd_image_option->data_pool);
+}
+
+
void
virStoragePoolSourceClear(virStoragePoolSource *source)
{
@@ -484,6 +492,7 @@ virStoragePoolSourceClear(virStoragePoolSource *source)
VIR_FREE(source->vendor);
VIR_FREE(source->product);
VIR_FREE(source->protocolVer);
+ virRbdImageOptionClear(&source->rbdImageOptions);
}
@@ -514,6 +523,131 @@ virStoragePoolDefFree(virStoragePoolDef *def)
}
+int
+virRbdImageOptionParseXML(virRbdImageOptionsPtr rbd_image_option,
+ xmlNodePtr node,
+ xmlXPathContextPtr ctxt)
+{
+ VIR_XPATH_NODE_AUTORESTORE(ctxt)
+ char *val = NULL;
+
+ ctxt->node = node;
+
+ rbd_image_option->format = -1;
+ if ((val = virXMLPropString(node, "format"))) {
+ if (virStrToLong_l(val, NULL, 10, &rbd_image_option->format) < 0)
+ goto cleanup;
+ VIR_FREE(val);
+ }
+
+ rbd_image_option->feature = -1;
+ if ((val = virXMLPropString(node, "feature"))) {
+ if (virStrToLong_l(val, NULL, 10, &rbd_image_option->feature) < 0)
+ goto cleanup;
+ VIR_FREE(val);
+ }
+
+ rbd_image_option->order = -1;
+ if ((val = virXMLPropString(node, "order"))) {
+ if (virStrToLong_l(val, NULL, 10, &rbd_image_option->order) < 0)
+ goto cleanup;
+ VIR_FREE(val);
+ }
+
+ rbd_image_option->stripe_unit = -1;
+ if ((val = virXMLPropString(node, "stripeunit"))) {
+ if (virStrToLong_l(val, NULL, 10, &rbd_image_option->stripe_unit) < 0)
+ goto cleanup;
+ VIR_FREE(val);
+ }
+
+ rbd_image_option->stripe_count = -1;
+ if ((val = virXMLPropString(node, "stripecount"))) {
+ if (virStrToLong_l(val, NULL, 10, &rbd_image_option->stripe_count) < 0)
+ goto cleanup;
+ VIR_FREE(val);
+ }
+
+ rbd_image_option->journal_order = -1;
+ if ((val = virXMLPropString(node, "journalorder"))) {
+ if (virStrToLong_l(val, NULL, 10, &rbd_image_option->journal_order) <
0)
+ goto cleanup;
+ VIR_FREE(val);
+ }
+
+ rbd_image_option->journal_splay_width = -1;
+ if ((val = virXMLPropString(node, "journalsplaywidth"))) {
+ if (virStrToLong_l(val, NULL, 10,
&rbd_image_option->journal_splay_width) < 0)
+ goto cleanup;
+ VIR_FREE(val);
+ }
+
+ rbd_image_option->journal_pool = virXMLPropString(node, "journalpool");
+
+ rbd_image_option->feature_set = -1;
+ if ((val = virXMLPropString(node, "featureset"))) {
+ if (virStrToLong_l(val, NULL, 10, &rbd_image_option->feature_set) < 0)
+ goto cleanup;
+ VIR_FREE(val);
+ }
+
+ rbd_image_option->feature_clear = -1;
+ if ((val = virXMLPropString(node, "featureclear"))) {
+ if (virStrToLong_l(val, NULL, 10, &rbd_image_option->feature_clear) <
0)
+ goto cleanup;
+ VIR_FREE(val);
+ }
+
+ rbd_image_option->data_pool = virXMLPropString(node, "datapool");
+
+ rbd_image_option->flatten = -1;
+ if ((val = virXMLPropString(node, "flatten"))) {
+ if (virStrToLong_l(val, NULL, 10, &rbd_image_option->flatten) < 0)
+ goto cleanup;
+ VIR_FREE(val);
+ }
+
+ rbd_image_option->clone_format = -1;
+ if ((val = virXMLPropString(node, "cloneformat"))) {
+ if (virStrToLong_l(val, NULL, 10, &rbd_image_option->clone_format) < 0)
+ goto cleanup;
+ VIR_FREE(val);
+ }
+
+ rbd_image_option->mirror_image_mode = -1;
+ if ((val = virXMLPropString(node, "mirrorimagemode"))) {
+
[libvirt] 答复: [libvirt-users] libivrt issue report , 1.1.0 version, while migrate VMs between two hosts, is it solved or other way to avoid it, thanks
Thank you. I will try it - 本邮件及其附件含有杭州华三通信技术有限公司的保密信息，仅限于发送给上面地址中列出 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 邮件！ This e-mail and its attachments contain confidential information from H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] libivrt issue report , 1.1.0 version, while migrate VMs between two hosts, is it solved or other way to avoid it, thanks
Libivrt 1.1.0
Migrate VM between two hosts using shell scripts.
The issues is occurred about every 5 minutes, using gdb and the back trace is
below:
(gdb) c
Continuing.
[New Thread 0x7f78e7c11700 (LWP 48116)]
[New Thread 0x7f78cf7fe700 (LWP 48129)]
[New Thread 0x7f78ceffd700 (LWP 48306)]
[New Thread 0x7f78ce7fc700 (LWP 62351)]
[New Thread 0x7f78cdffb700 (LWP 62694)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f78ed24a700 (LWP 46120)]
0x7f78ef553579 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0 0x7f78ef553579 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x7f78ef555a45 in malloc () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x7f78ef545ae3 in vasprintf () from /lib/x86_64-linux-gnu/libc.so.6
#3 0x7f78f07a3e54 in virVasprintf (strp=0x7f78ed249b38,
fmt=0x7f78f0959c48 "server=%p client=%p message=%p prog=%p",
list=0x7f78ed249c00) at util/virstring.c:334
#4 0x7f78f077d998 in virLogVMessage (source=VIR_LOG_FROM_FILE,
priority=VIR_LOG_DEBUG, filename=0x7f78f0959bed "rpc/virnetserver.c",
linenr=182, funcname=0x7f78f095a500 "virNetServerHandleJob", metadata=0x0,
fmt=0x7f78f0959c48 "server=%p client=%p message=%p prog=%p",
vargs=0x7f78ed249c00) at util/virlog.c:836
#5 0x7f78f077d85d in virLogMessage (source=VIR_LOG_FROM_FILE,
priority=VIR_LOG_DEBUG, filename=0x7f78f0959bed "rpc/virnetserver.c",
linenr=182, funcname=0x7f78f095a500 "virNetServerHandleJob", metadata=0x0,
fmt=0x7f78f0959c48 "server=%p client=%p message=%p prog=%p")
at util/virlog.c:773
#6 0x7f78f08acd86 in virNetServerHandleJob (jobOpaque=0x7f78f305f6a0,
opaque=0x7f78f304a360) at rpc/virnetserver.c:181
#7 0x7f78f07a8a5e in virThreadPoolWorker (opaque=0x7f78f304a0a0)
at util/virthreadpool.c:144
#8 0x7f78f07a842a in virThreadHelper (data=0x7f78f3049ec0)
at util/virthreadpthread.c:205
#9 0x7f78ef897e9a in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#10 0x7f78ef5c54bd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#11 0x in ?? ()
(gdb) frame 6
#6 0x7f78f08acd86 in virNetServerHandleJob (jobOpaque=0x7f78f305f6a0,
opaque=0x7f78f304a360) at rpc/virnetserver.c:181
181 rpc/virnetserver.c: No such file or directory.
(gdb) p job
$1 = (virNetServerJobPtr) 0x7f78f305f6a0
(gdb) p srv
$2 = (virNetServerPtr) 0x7f78f304a360
(gdb) p job->client
$3 = (virNetServerClientPtr) 0x7f78f3054a60
(gdb) p job->msg
$4 = (virNetMessagePtr) 0x7f78f3051480
(gdb) p job->prog
$5 = (virNetServerProgramPtr) 0x7f78f3054c60
(gdb)
$6 = (virNetServerProgramPtr) 0x7f78f3054c60
(gdb) frame 5
#5 0x7f78f077d85d in virLogMessage (source=VIR_LOG_FROM_FILE,
priority=VIR_LOG_DEBUG, filename=0x7f78f0959bed "rpc/virnetserver.c",
linenr=182, funcname=0x7f78f095a500 "virNetServerHandleJob", metadata=0x0,
fmt=0x7f78f0959c48 "server=%p client=%p message=%p prog=%p")
at util/virlog.c:773
773 util/virlog.c: No such file or directory.
(gdb) frame 3
#3 0x7f78f07a3e54 in virVasprintf (strp=0x7f78ed249b38,
fmt=0x7f78f0959c48 "server=%p client=%p message=%p prog=%p",
list=0x7f78ed249c00) at util/virstring.c:334
334 util/virstring.c: No such file or directory.
(gdb) p strp
$7 = (char **) 0x7f78ed249b38
(gdb) p *strp
$8 = 0x0
(gdb) p list
$9 = (struct __va_list_tag *) 0x7f78ed249c00
(gdb) p *list
$10 = {gp_offset = 48, fp_offset = 48, overflow_arg_area = 0x7f78ed249ce8,
reg_save_area = 0x7f78ed249c20}
-
???
This e-mail and its attachments contain confidential information from H3C,
which is
intended only for the person or entity whose address is listed above. Any use
of the
information contained herein in any way (including, but not limited to, total
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify
the sender
by phone or email immediately and delete it!
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] 答复: [libvirt-users] Is virsh blockcommit supported? Thanks a lot
Thanks a lot. :) That will be good to support the features in future. Guozhonghua -邮件原件- 发件人: Eric Blake [mailto:ebl...@redhat.com] 发送时间: 2013年9月4日 9:34 收件人: guozhonghua 02084 抄送: libvirt-us...@redhat.com; libvir-list@redhat.com; changlimin 00148 主题: Re: [libvirt-users] Is virsh blockcommit supported? Thanks a lot On 09/03/2013 06:56 PM, Guozhonghua wrote: > Hi, > > I have another question, when I do the blockcommit command and get the result > " Top image as the active layer is currently unsupported ", is it being > developed? > root@cvk-31:/vms/images# virsh blockcommit Vmtest /vms/images/Vmtest1;echo $? > error: internal error unable to execute QEMU command 'block-commit': > Top image as the active layer is currently unsupported Yes, patches have been proposed to upstream qemu for that feature, but they missed 1.6, so you will have to wait for qemu 1.7. There may also be some integration efforts that require tweaks to libvirt to take advantage of the qemu feature (the libvirt API was designed to work as soon as qemu added support, but we haven't yet proven whether our plans work out as nicely as we hope). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org - 本邮件及其附件含有杭州华三通信技术有限公司的保密信息，仅限于发送给上面地址中列出 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 邮件！ This e-mail and its attachments contain confidential information from H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [libvirt-users] Is virsh blockcommit supported? Thanks a lot
Hi, I have another question, when I do the blockcommit command and get the result " Top image as the active layer is currently unsupported ", is it being developed? root@cvk-31:/vms/images# virsh blockcommit Vmtest /vms/images/Vmtest1;echo $? error: internal error unable to execute QEMU command 'block-commit': Top image as the active layer is currently unsupported 1 But as I specified the commit file which is not the current image file, it will be work, such as below: root@cvk-31:/vms/images# qemu-img info --backing-chain /vms/images/Vmtest1 image: /vms/images/Vmtest1 file format: qcow2 virtual size: 9.8G (1048576 bytes) disk size: 18M cluster_size: 65536 backing file: /vms/images/Vmtest1_base_1 backing file format: qcow2 image: /vms/images/Vmtest1_base_1 file format: qcow2 virtual size: 9.8G (1048576 bytes) disk size: 196K cluster_size: 65536 backing file: /vms/images/Vmtest1_base backing file format: qcow2 image: /vms/images/Vmtest1_base file format: qcow2 virtual size: 9.8G (1048576 bytes) disk size: 3.4G cluster_size: 2097152 root@cvk-31:/vms/images# virsh blockcommit Vmtest /vms/images/Vmtest1 --base /vms/images/Vmtest1_base --top /vms/images/Vmtest1_base_1 --wait --verbose;echo $? Block Commit: [100 %] Commit complete 0 - 本邮件及其附件含有杭州华三通信技术有限公司的保密信息，仅限于发送给上面地址中列出 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 邮件！ This e-mail and its attachments contain confidential information from H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Is virsh blockcommit supported? Thanks a lot
I had test the command virsh blockcommit, but it failed, with the libvirt version 1.1.0, and qemu version 1.6.0. Is this feature being developing? Thanks root@cvk-31:/vms/images# virsh -v 1.1.0 root@cvk-31:/vms/images# qemu-img -V qemu-img version 1.6.0, Copyright (c) 2004-2008 Fabrice Bellard usage: qemu-img command [command options] root@cvk-31:/vms/images# virsh blockcommit Vmtest /vms/images/Vmtest1 --base /vms/image s/Vmtest1_base --top /vms/images/Vmtest1_base_1 --wait --verbose ;echo $? error: invalid argument: top '/vms/images/Vmtest1_base_1' in chain for '/vms/images/Vmtest1' has no backing file 1 root@cvk-31:/vms/images# qemu-img info /vms/images/Vmtest1_base_1 image: /vms/images/Vmtest1_base_1 file format: qcow2 virtual size: 9.8G (1048576 bytes) disk size: 6.0M cluster_size: 2097152 backing file: /vms/images/Vmtest1_base root@cvk-31:/vms/images# qemu-img info --backing-chain /vms/images/Vmtest1 image: /vms/images/Vmtest1 file format: qcow2 virtual size: 9.8G (1048576 bytes) disk size: 140M cluster_size: 2097152 backing file: /vms/images/Vmtest1_base_1 image: /vms/images/Vmtest1_base_1 file format: qcow2 virtual size: 9.8G (1048576 bytes) disk size: 6.0M cluster_size: 2097152 backing file: /vms/images/Vmtest1_base image: /vms/images/Vmtest1_base file format: qcow2 virtual size: 9.8G (1048576 bytes) disk size: 3.4G cluster_size: 2097152 root@cvk-31:/vms/images# virsh blockcommit Vmtest /vms/images/Vmtest1 --base /vms/image s/Vmtest1_base --wait --verbose ;echo $? error: invalid argument: could not find base '/vms/images/Vmtest1_base' below '/vms/images/Vmtest1' in chain for '/vms/images/Vmtest1' 1 root@cvk-31:/vms/images# ls -al /vms/images/Vmtest1_base -rw--- 1 root root 3705667584 Aug 23 10:19 /vms/images/Vmtest1_base root@cvk-31:/vms/images# qemu-img info /vms/images/Vmtest1_base image: /vms/images/Vmtest1_base file format: qcow2 virtual size: 9.8G (1048576 bytes) disk size: 3.4G cluster_size: 2097152 - ??? This e-mail and its attachments contain confidential information from H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
