Re: [Qemu-devel] IRQ number, interrupt number, interrupt line GPIO[in/out]
IRQ number is actually a word coming from ancient time. When 8259 was popular at that time, we only have 0 ~ 15 interrupts when two 8259 are cascaded. The IRQ number mattered in that time, because 8259 put their vector number in the bus for CPU after the interrupt was delivered. The number did have special meaning to the CPU used as a vector to interrupt table. However, in modern time, especially after we have APIC and MSI, the number don't have much meaning to CPU because the interrupt is targeting some special PCI address to notify the CPU. So APIC don't need put a vector number in the bus. In modern os, it is usually called auto vector for OS to walk the interrupt routine table. Interrupt line is similar to IRQ numbers, interrupt numbers. On 2012-3-2 20:38, Zhi Yong Wu wrote: HI, Can anyone explain their relationship and difference among them? It is very appreciated if you can make some comments. thanks. -- Shu Mingshum...@linux.vnet.ibm.com IBM China Systems and Technology Laboratory
Re: [Qemu-devel] Fail to share Samba directory with guest
On 2012-2-27 17:21, Jun Koi wrote: hi, on qemu 1.0.1, i am trying to share a host directory with the Windows guest like below: qemu-system-i386 -enable-kvm -m 1000 -net nic,model=rtl8139 -net user,smb=/tmp img.winxp but in the guest, \\10.0.2.4 doesnt show me any shared directory. i already run Samba on the host (default configuration). did i miss something, or is it a bug?? So 10.0.2.4 is your host IP with samba server? And what's the network the guest belongs to? thanks, Jun -- Shu Mingshum...@linux.vnet.ibm.com IBM China Systems and Technology Laboratory
Re: [Qemu-devel] [vdsm] oVirt Live Snapshots
Can someone explain what is DB in this wiki page? See, Live snapshots operation extend regular snapshots as follow: * Create a locked snapshot in DB On 2012-1-30 19:00, Federico Simoncelli wrote: Hi, oVirt, and more specifically VDSM, is currently implementing the live snapshot feature using the API/commands provided by libvirt and qemu. It would be great if you could review the design and the current open issues at: http://ovirt.org/wiki/Live_Snapshots Thank you, -- Shu Mingshum...@linux.vnet.ibm.com IBM China Systems and Technology Laboratory
Re: [Qemu-devel] The reversion of hot adding a storage disk to Linux guest.
No other comments? Anyway, I think we need a way to hot unplug a storage disk from the guest totally exactly liking to remove a disk physically. After that unplugging, linux guest can not bring back the disk by any command. On 2012-1-12 16:57, Shu Ming wrote: Hi, I am testing the hot plug of scsi disk to the KVM Linux guest with the following command. [root@kvm-rhel-01 bin]# ./virsh qemu-monitor-command RHEL6.1-C pci_add auto storage file=/nfs/images/storage1-qcow2.img,if=scsi OK domian 0, bus 0, slot 7, function 0 [root@kvm-rhel-01 bin]# lspci ... 00:05.0 SCSI storage controller: Red Hat, Inc Virtio block device 00:06.0 RAM memory: Red Hat, Inc Virtio memory balloon 00:07.0 SCSI storage controller: LSI Logic / Symbios Logic 53c895a ---new deviced added in the KVM guest: [root@RHEL6 ~]#cat /proc/scsi/scsi Attached devices: Host: scsi1 Channel: 00 Id: 00 Lun: 00 Vendor: QEMUModel: QEMU DVD-ROMRev: 1.0. Type:CD-ROM Host: scsi2 Channel: 00 Id: 00 Lun: 00 Vendor: QEMUModel: QEMU HARDDISKRev: 1.0. Type: Direct-AccessANSISCSI revision: 05 --new scsi disk attached The command successfully created a HBA device in the guest and also a scsi disk was enumerated under the HBA device. My next request is to hot detach the scsi disk from the HBA device, not necessarily detach the HBA device. That is to emulate the swapping out of the scsi disk from a physical machine and to release the image file in the backend. Because the scsi disk is not PCI device, pci_del command can not be used in this case. Can we have a way to send some commands to notice the HBA device to offline the scsi disk? By that way, HBA device can do some cleanup in their driver to fully offline the scsi disk. BTW: In the linux guest, we can do echo scsi remove-single-device 2 0 0 0 /proc/scsi/scsi to disable the disk. But I don't think it is fully removed, because you can bring it back again by echo scsi add-single-device 2 0 0 0 /proc/scsi/scsi -- Shu Mingshum...@linux.vnet.ibm.com IBM China Systems and Technology Laboratory
[Qemu-devel] The reversion of hot adding a storage disk to Linux guest.
Hi, I am testing the hot plug of scsi disk to the KVM Linux guest with the following command. [root@kvm-rhel-01 bin]# ./virsh qemu-monitor-command RHEL6.1-C pci_add auto storage file=/nfs/images/storage1-qcow2.img,if=scsi OK domian 0, bus 0, slot 7, function 0 [root@kvm-rhel-01 bin]# lspci ... 00:05.0 SCSI storage controller: Red Hat, Inc Virtio block device 00:06.0 RAM memory: Red Hat, Inc Virtio memory balloon 00:07.0 SCSI storage controller: LSI Logic / Symbios Logic 53c895a ---new deviced added in the KVM guest: [root@RHEL6 ~]#cat /proc/scsi/scsi Attached devices: Host: scsi1 Channel: 00 Id: 00 Lun: 00 Vendor: QEMUModel: QEMU DVD-ROMRev: 1.0. Type:CD-ROM Host: scsi2 Channel: 00 Id: 00 Lun: 00 Vendor: QEMUModel: QEMU HARDDISKRev: 1.0. Type: Direct-AccessANSISCSI revision: 05 --new scsi disk attached The command successfully created a HBA device in the guest and also a scsi disk was enumerated under the HBA device. My next request is to hot detach the scsi disk from the HBA device, not necessarily detach the HBA device. That is to emulate the swapping out of the scsi disk from a physical machine and to release the image file in the backend. Because the scsi disk is not PCI device, pci_del command can not be used in this case. Can we have a way to send some commands to notice the HBA device to offline the scsi disk? By that way, HBA device can do some cleanup in their driver to fully offline the scsi disk. BTW: In the linux guest, we can do echo scsi remove-single-device 2 0 0 0 /proc/scsi/scsi to disable the disk. But I don't think it is fully removed, because you can bring it back again by echo scsi add-single-device 2 0 0 0 /proc/scsi/scsi -- Shu Mingshum...@linux.vnet.ibm.com IBM China Systems and Technology Laboratory
Re: [Qemu-devel] Stalls on Live Migration of VMs with a lot of memory
On 2012-1-4 2:04, Peter Lieven wrote: Hi all, is there any known issue when migrating VMs with a lot of (e.g. 32GB) of memory. It seems that there is some portion in the migration code which takes too much time when the number of memory pages is large. Symptoms are: Irresponsive VNC connection, VM stalls and also irresponsive QEMU Monitor (via TCP). The problem seems to be worse on 10G connections between 2 Nodes (i already tried limiting the bandwidth with the migrate_set_speed command) than on 1G connections. Is the migration accomplished finally? How long will that be? I did a test on VM with 4G and it took me about two seconds. The problem also seems to be worse in qemu-kvm-1.0 than in qemu-kvm-0.12.5. Any hints? Thanks, Peter -- Shu Mingshum...@linux.vnet.ibm.com IBM China Systems and Technology Laboratory
Re: [Qemu-devel] [help] QEMUFile's format
Do you mean the file format? qcow2, qed, raw? Or the content layout in the file image? On 2011-12-23 13:17, ¤終於aware wrote: Hi, Is anyone clear about the format of qemu file for savevm or loadvm? bruce -- Shu Mingshum...@linux.vnet.ibm.com IBM China Systems and Technology Laboratory
Re: [Qemu-devel] [RFC] Consistent Snapshots Idea
On 2011-11-21 20:31, Avi Kivity wrote: On 11/21/2011 02:01 PM, Richard Laager wrote: I'm not an expert on the architecture of KVM, so perhaps this is a QEMU question. If so, please let me know and I'll ask on a different list. It is a qemu question, yes (though fork()ing a guest also relates to kvm). Background: Assuming the block layer can make instantaneous snapshots of a guest's disk (e.g. lvcreate -s), one can get crash consistent (i.e. as if the guest crashed) snapshots. To get a fully consistent snapshot, you need to shutdown the guest. For production VMs, this is obviously not ideal. Idea: What if KVM/QEMU was to fork() the guest and shutdown one copy? KVM/QEMU would momentarily halt the execution of the guest and take a writable, instantaneous snapshot of each block device. Then it would fork(). The parent would resume execution as normal. The child would redirect disk writes to the snapshot(s). The RAM should have copy-on-write behavior as with any other fork()ed process. Other resources like the network, display, sound, serial, etc. would simply be disconnected/bit-bucketed. Finally, the child would resume guest execution and send the guest an ACPI power button press event. This would cause the guest OS to perform an orderly shutdown. I believe this would provide consistent snapshots in the vast majority of real-world scenarios in a guest OS and application-independent way. Interesting idea. Will the guest actually shut down nicely without a network? Things like NFS mounts will break. Does the child and parent process run in parallel? What will happen if the parent process try to access the block device? It looks like that the child process will write to a snapshot file, but where will the parent process write to? Implementation Nits: * A timeout on the child process would likely be a good idea. * It'd probably be best to disconnect the network (i.e. tell the guest the cable is unplugged) to avoid long timeouts. Likewise for the hardware flow-control lines on the serial port. This is actually critical, otherwise the guest will shutdown(2) all sockets and confuse the clients. * For correctness, fdatasync()ing or similar might be necessary after halting execution and before creating the snapshots. Microsoft guests have an API to quiesce storage prior to a snapshot, and I think there is work to bring this to Linux guests. So it should be possible to get consistent snapshots even without this, but it takes more integration.
Re: [Qemu-devel] Catching system calls and PIDs in Qemu
I don't know how to convert the guest virtual address to a guest physical address. But I believe that the guest virtual address to guest physical address mapping table should belong to the guest OS and stay at guest context. So you should know where is the mapping table in the guest OS by guest physical address before you have a way to do the conversion. After the guest physical address of the table is known, cpu_physical_memory_rw() can be used to walking the table and get the guest physical address of the guest virtual address you want to convert. The time spending on the walk should be non-trival. On 2011-11-3 2:25, Ricardo Alves wrote: Need Help! I am editing the Qemu source code to be able to catch every system call made by the guest OS and which processes do those system calls. I catch the system calls in the void do_interrupt(CPUState *env1) (op_helper.c) function by accessing the exception index on the cpu environment (env-exception_index == 0x80) and inspecting the system call ID in the eax register. The difficulty resides in finding the process that made the system call. Linux uses the thread_info struct to store process information. The method to find this struct location is to apply a mask to the esp register and I would get the struct pointer. In qemu I would just do this -- target_ulong pos = env-regs[R_ESP] 0xE000. The problem is that I don't know how to access the guest main memory. The qemu function I found to access memory was this one -- void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,int len, int is_write) (exec.c). But as far as I know (I could be wrong) this function receives a guest physical adress and the one I have is a guest virtual adress. Can anybody help me convert this guest virtual adress to a guest physical adress? Thank you.
Re: [Qemu-devel] http://git.qemu.org/git/qemu.git/ is inaccessible
You may try: http://repo.or.cz/w/qemu.git On 2011-11-2 9:01, Roy Tam wrote: Hi all, http://git.qemu.org/git/qemu.git/ is listed in http://git.qemu.org/ but it is inaccessible (HTTP 403). Where is mirror of it? As I can't access git:// protocol here and I need accessing http:// repo instead. Best regards, Roy
[Qemu-devel] Abnormal function exit message in Qemu block drivers code
Hi,
After reading the block driver code in, it was found that the error
exit code behaved in different ways. Here are some examples. It seems
that way 3 is a better way to log the error message. In fact, It is
pretty important for a administrator to know what is going on and be
informed the error when that happens. I believe we should convert all
the error exit code to way 3 gradually and make all the new code to
follow an unique standard.
Further more, really, some errors can be ignored while others can
not. So we can have a more flexible function to classify the level of
the error message like
error_report(log_level, string format, string);
1)The error code exited silently.
case QCOW2_EXT_MAGIC_BACKING_FORMAT:
if (ext.len = sizeof(bs-backing_format)) {
fprintf(stderr, ERROR: ext_backing_format: len=%u too
large
(=%zu)\n,
ext.len, sizeof(bs-backing_format));
return 2;
}
2) fprintf() to emit the error message
case QCOW2_EXT_MAGIC_BACKING_FORMAT:
if (ext.len = sizeof(bs-backing_format)) {
fprintf(stderr, ERROR: ext_backing_format: len=%u too
large
(=%zu)\n,
ext.len, sizeof(bs-backing_format));
return 2;
3) A error_report() function to emit the error message.
/* Find driver and parse its options */
drv = bdrv_find_format(fmt);
if (!drv) {
error_report(Unknown file format '%s', fmt);
ret = -EINVAL;
goto out;
}
Re: [Qemu-devel] [PATCH v3] add add-cow file format
Looks good to me. A nit, it seems that bdrv_flush is not supported
anymore in upstream.
bdrv_co_flush should be used instead if you update your workspace to
latest one.
On 2011-10-26 18:08, Robert Wang wrote:
Please find version 4 in the attachment.
2011/10/23 shu mingshum...@linux.vnet.ibm.com:
On 2011-10-13 0:23, Dong Xu Wang wrote:
Add add-cow file format
Signed-off-by: Dong Xu Wangwdon...@linux.vnet.ibm.com
---
Makefile.objs |1 +
block.c|2 +-
block.h|1 +
block/add-cow.c| 412
block_int.h|1 +
docs/specs/add-cow.txt | 45 ++
6 files changed, 461 insertions(+), 1 deletions(-)
create mode 100644 block/add-cow.c
create mode 100644 docs/specs/add-cow.txt
diff --git a/Makefile.objs b/Makefile.objs
index c849e51..624c04c 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -31,6 +31,7 @@ block-obj-$(CONFIG_LINUX_AIO) += linux-aio.o
block-nested-y += raw.o cow.o qcow.o vdi.o vmdk.o cloop.o dmg.o bochs.o
vpc.o vvfat.o
block-nested-y += qcow2.o qcow2-refcount.o qcow2-cluster.o
qcow2-snapshot.o qcow2-cache.o
+block-nested-y += add-cow.o
block-nested-y += qed.o qed-gencb.o qed-l2-cache.o qed-table.o
qed-cluster.o
block-nested-y += qed-check.o
block-nested-y += parallels.o nbd.o blkdebug.o sheepdog.o blkverify.o
diff --git a/block.c b/block.c
index e865fab..c25241d 100644
--- a/block.c
+++ b/block.c
@@ -106,7 +106,7 @@ int is_windows_drive(const char *filename)
#endif
/* check if the path starts with protocol: */
-static int path_has_protocol(const char *path)
+int path_has_protocol(const char *path)
{
#ifdef _WIN32
if (is_windows_drive(path) ||
diff --git a/block.h b/block.h
index 16bfa0a..8b09f12 100644
--- a/block.h
+++ b/block.h
@@ -256,6 +256,7 @@ char *bdrv_snapshot_dump(char *buf, int buf_size,
QEMUSnapshotInfo *sn);
char *get_human_readable_size(char *buf, int buf_size, int64_t size);
int path_is_absolute(const char *path);
+int path_has_protocol(const char *path);
void path_combine(char *dest, int dest_size,
const char *base_path,
const char *filename);
diff --git a/block/add-cow.c b/block/add-cow.c
new file mode 100644
index 000..d2538a2
--- /dev/null
+++ b/block/add-cow.c
@@ -0,0 +1,412 @@
+#include qemu-common.h
+#include block_int.h
+#include module.h
+
+#define ADD_COW_MAGIC (((uint64_t)'A'56) | ((uint64_t)'D'48) | \
+((uint64_t)'D'40) | ((uint64_t)'_'32) | \
+((uint64_t)'C'24) | ((uint64_t)'O'16) | \
+((uint64_t)'W'8) | 0xFF)
+#define ADD_COW_VERSION 1
+
+typedef struct AddCowHeader {
+uint64_t magic;
+uint32_t version;
+char backing_file[1024];
+char image_file[1024];
1024 is a magic number for me. Can we have a meaningful macro?
+uint64_t size;
+} QEMU_PACKED AddCowHeader;
+
+typedef struct BDRVAddCowState {
+char image_file[1024];
+BlockDriverState *image_hd;
+uint8_t *bitmap;
+uint64_t bitmap_size;
+} BDRVAddCowState;
+
+static int add_cow_probe(const uint8_t *buf, int buf_size, const char
*filename)
+{
+const AddCowHeader *header = (const void *)buf;
+
+if (be64_to_cpu(header-magic) == ADD_COW_MAGIC
+be32_to_cpu(header-version) == ADD_COW_VERSION) {
+return 100;
+} else {
+return 0;
+}
+}
+
+static int add_cow_open(BlockDriverState *bs, int flags)
+{
+AddCowHeader header;
+int64_t size;
+char image_filename[1024];
+int image_flags;
+BlockDriver *image_drv = NULL;
+int ret;
+BDRVAddCowState *state = (BDRVAddCowState *)(bs-opaque);
+
+ret = bdrv_pread(bs-file, 0,header, sizeof(header));
+if (ret != sizeof(header)) {
+goto fail;
+}
+
+if (be64_to_cpu(header.magic) != ADD_COW_MAGIC ||
+be32_to_cpu(header.version) != ADD_COW_VERSION) {
+ret = -1;
+goto fail;
+}
+
+size = be64_to_cpu(header.size);
+bs-total_sectors = size / BDRV_SECTOR_SIZE;
+
+QEMU_BUILD_BUG_ON(sizeof(state-image_file) !=
sizeof(header.image_file));
+pstrcpy(bs-backing_file, sizeof(bs-backing_file),
+header.backing_file);
+pstrcpy(state-image_file, sizeof(state-image_file),
+header.image_file);
+
+state-bitmap_size = ((bs-total_sectors + 7)3);
+state-bitmap = g_malloc0(state-bitmap_size);
+
+ret = bdrv_pread(bs-file, sizeof(header), state-bitmap,
+state-bitmap_size);
+if (ret != state-bitmap_size) {
+goto fail;
+}
+ /* If there is a image_file, must be together with backing_file */
+if (state-image_file[0] != '\0') {
+state-image_hd = bdrv_new();
+/* Relative to image or working dir, need discussion */
+if (path_has_protocol(state-image_file)) {
+pstrcpy(image_filename, sizeof(image_filename),
+
Re: [Qemu-devel] [PATCH v3] add add-cow file format
On 2011-10-13 0:23, Dong Xu Wang wrote:
Add add-cow file format
Signed-off-by: Dong Xu Wangwdon...@linux.vnet.ibm.com
---
Makefile.objs |1 +
block.c|2 +-
block.h|1 +
block/add-cow.c| 412
block_int.h|1 +
docs/specs/add-cow.txt | 45 ++
6 files changed, 461 insertions(+), 1 deletions(-)
create mode 100644 block/add-cow.c
create mode 100644 docs/specs/add-cow.txt
diff --git a/Makefile.objs b/Makefile.objs
index c849e51..624c04c 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -31,6 +31,7 @@ block-obj-$(CONFIG_LINUX_AIO) += linux-aio.o
block-nested-y += raw.o cow.o qcow.o vdi.o vmdk.o cloop.o dmg.o bochs.o vpc.o
vvfat.o
block-nested-y += qcow2.o qcow2-refcount.o qcow2-cluster.o qcow2-snapshot.o
qcow2-cache.o
+block-nested-y += add-cow.o
block-nested-y += qed.o qed-gencb.o qed-l2-cache.o qed-table.o qed-cluster.o
block-nested-y += qed-check.o
block-nested-y += parallels.o nbd.o blkdebug.o sheepdog.o blkverify.o
diff --git a/block.c b/block.c
index e865fab..c25241d 100644
--- a/block.c
+++ b/block.c
@@ -106,7 +106,7 @@ int is_windows_drive(const char *filename)
#endif
/* check if the path starts with protocol: */
-static int path_has_protocol(const char *path)
+int path_has_protocol(const char *path)
{
#ifdef _WIN32
if (is_windows_drive(path) ||
diff --git a/block.h b/block.h
index 16bfa0a..8b09f12 100644
--- a/block.h
+++ b/block.h
@@ -256,6 +256,7 @@ char *bdrv_snapshot_dump(char *buf, int buf_size,
QEMUSnapshotInfo *sn);
char *get_human_readable_size(char *buf, int buf_size, int64_t size);
int path_is_absolute(const char *path);
+int path_has_protocol(const char *path);
void path_combine(char *dest, int dest_size,
const char *base_path,
const char *filename);
diff --git a/block/add-cow.c b/block/add-cow.c
new file mode 100644
index 000..d2538a2
--- /dev/null
+++ b/block/add-cow.c
@@ -0,0 +1,412 @@
+#include qemu-common.h
+#include block_int.h
+#include module.h
+
+#define ADD_COW_MAGIC (((uint64_t)'A' 56) | ((uint64_t)'D' 48) | \
+((uint64_t)'D' 40) | ((uint64_t)'_' 32) | \
+((uint64_t)'C' 24) | ((uint64_t)'O' 16) | \
+((uint64_t)'W' 8) | 0xFF)
+#define ADD_COW_VERSION 1
+
+typedef struct AddCowHeader {
+uint64_t magic;
+uint32_t version;
+char backing_file[1024];
+char image_file[1024];
1024 is a magic number for me. Can we have a meaningful macro?
+uint64_t size;
+} QEMU_PACKED AddCowHeader;
+
+typedef struct BDRVAddCowState {
+char image_file[1024];
+BlockDriverState *image_hd;
+uint8_t *bitmap;
+uint64_t bitmap_size;
+} BDRVAddCowState;
+
+static int add_cow_probe(const uint8_t *buf, int buf_size, const char
*filename)
+{
+const AddCowHeader *header = (const void *)buf;
+
+if (be64_to_cpu(header-magic) == ADD_COW_MAGIC
+be32_to_cpu(header-version) == ADD_COW_VERSION) {
+return 100;
+} else {
+return 0;
+}
+}
+
+static int add_cow_open(BlockDriverState *bs, int flags)
+{
+AddCowHeader header;
+int64_t size;
+char image_filename[1024];
+int image_flags;
+BlockDriver *image_drv = NULL;
+int ret;
+BDRVAddCowState *state = (BDRVAddCowState *)(bs-opaque);
+
+ret = bdrv_pread(bs-file, 0,header, sizeof(header));
+if (ret != sizeof(header)) {
+goto fail;
+}
+
+if (be64_to_cpu(header.magic) != ADD_COW_MAGIC ||
+be32_to_cpu(header.version) != ADD_COW_VERSION) {
+ret = -1;
+goto fail;
+}
+
+size = be64_to_cpu(header.size);
+bs-total_sectors = size / BDRV_SECTOR_SIZE;
+
+QEMU_BUILD_BUG_ON(sizeof(state-image_file) != sizeof(header.image_file));
+pstrcpy(bs-backing_file, sizeof(bs-backing_file),
+header.backing_file);
+pstrcpy(state-image_file, sizeof(state-image_file),
+header.image_file);
+
+state-bitmap_size = ((bs-total_sectors + 7) 3);
+state-bitmap = g_malloc0(state-bitmap_size);
+
+ret = bdrv_pread(bs-file, sizeof(header), state-bitmap,
+state-bitmap_size);
+if (ret != state-bitmap_size) {
+goto fail;
+}
+ /* If there is a image_file, must be together with backing_file */
+if (state-image_file[0] != '\0') {
+state-image_hd = bdrv_new();
+/* Relative to image or working dir, need discussion */
+if (path_has_protocol(state-image_file)) {
+pstrcpy(image_filename, sizeof(image_filename),
+state-image_file);
+} else {
+path_combine(image_filename, sizeof(image_filename),
+ bs-filename, state-image_file);
+}
+
+image_drv = bdrv_find_format(raw);
+image_flags =
+ (flags (~(BDRV_O_SNAPSHOT | BDRV_O_NO_BACKING))) | BDRV_O_RDWR;
+
Re: [Qemu-devel] passing secrets to block devices
On 2011-10-21 5:48, Josh Durgin wrote:
On 10/20/2011 12:24 PM, Daniel P. Berrange wrote:
On Thu, Oct 20, 2011 at 11:30:42AM -0700, Josh Durgin wrote:
We're working on libvirt support for block device authentication
[1]. To
authenticate, rbd needs a username and a secret. Normally, to
avoid putting the secret on the command line, you can store the secret
in a file and pass the file to qemu, but when this is automated,
there's no good way to know when the file can be removed. There are
a few ways to pass the secret to qemu that avoid this problem:
This is the same problem the iSCSI block driver currently faces,
and also if the Curl/HTTP block driver wanted todo authentication
we'd hit this. So it isn't unique to Ceph/RBD.
1) pass an fd to an unlinked file containing the secret
This is the simplest method, but it sounds like qemu developers don't
like fd passing from libvirt. [2]
That would be workable, but it means people trying to run the libvirt
QEMU command line themselves, would have to remove some args.
Isn't this already the case for chardevs? I can understand not wanting
more things like that though.
2) start guests paused, without disks requiring authentication, then
use the drive_add monitor command to attach them
This would make disks with authentication somewhat of a special case
in libvirt, but would be simple to implement, and require no qemu
changes.
This makes it very hard for people to take the libvirt QEMU command line
and run themselves, since now an entire chunk of it is just missing.
So I really don't want to go down this route.
3) start guests paused, then send the secret via a new QMP/HMP
command (block_set_confkey value?)
This is a larger change, but it would be more generally useful for
changing configuration at runtime.
I don't think you need to try to solve the problem of a general
purpose 'set configuration' command here, not least because that
will likely get you drawn into a huge discussion about qemu device
configuration in general which will likely never end.
We already have a 'block_passwd' command for setting qcow2 decryption
keys. These aren't decryption passwords, rather they are authentication
passwords, so they're a little different, but I think this command could
still likely be leveraged for Ceph/iSCSI/etc auth passwords.
Ideally, we want to cope with having both a decryption auth password
for the same block device. eg, an encrypted qcow2 image accessed, over
HTTP would require both. In these case there are 2 block drivers
involved,
the 'qcow2' driver and the 'http' driver. So perhaps an extra parameter
for the 'block_password' command to identify which driver the password
is intended for is the right approach. If omitted,we'd default to
'qcow2'
for back compat.
So eg, for a encrypted qcow2 disk accessed over http
-drive file=http://fred@host/my.iso,format=qcow2,id=mydrive
the app would invoke
{ execute: block_password, argument: { device: mydrive,
driver, qcow2,
password, 12345 } }
{ execute: block_password, argument: { device: mydrive,
driver, curl,
password, 7890 } }
For Ceph/RBD with a plain file, you'd just do
{ execute: block_password, argument: { device: mydrive,
driver, rbd,
password, 7890 } }
This sounds good to me, although the same driver might use
authentication and encryption. Adding another argument to specify
'auth' or 'encryption' would fix this, i.e.:
{ execute: block_password, argument: { device: mydrive,
driver: qcow2,
use: encryption
password: 12345 } }
I'll prepare a patch if there are no objections to this approach.
Does the authentication be calculated by QEMU finally? If it is, how
the secrets will be transported from libvirt to QEMU if they are in
different hosts?
IMO, It should be encrpted to prevent the peek from others on the network.
[Qemu-devel] [Bug 861141] Re: Installing libvirt-bin qemu slows host network
Do you mean the send-receive result is different than receive-send? What about the result of bi-direction test? It looks like that the total bytes transferred are also different. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/861141 Title: Installing libvirt-bin qemu slows host network Status in QEMU: New Bug description: Installing the packages needed for qemu-kvm slows don network connectivity between two non-virtual machines. Uninstalling the packages does not restore the previous network speeds. Hardware: I have two identical machines (DELL poweredge R815), each with Broadcom NetXtreme II BCM57711 10-Gigabit PCIe connected via a 10G switch. Each machine runs 4 socket 12 core AMD Opteron(tm) Processor 6174 and 128GB of ram Software: Both machines ar running ubuntu server 10.04 lts Kernels are: Linux whitlam 2.6.32-28-server #55-Ubuntu SMP Mon Jan 10 23:57:16 UTC 2011 x86_64 GNU/Linux Linux fraser 2.6.32-28-server #55-Ubuntu SMP Mon Jan 10 23:57:16 UTC 2011 x86_64 GNU/Linux I have installed iperf on both machines and I am trying to install kvm on fraser. The tests here involve running whitlam as the iperf server and fraser as the client. On whitlam I run: bioadmin@whitlam:~# iperf -sm On fraser I run: bioadmin@fraser:~# iperf -c whitlam -d before installation I get: bioadmin@whitlam:~# iperf -sm Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) [ 5] local 10.168.48.14 port 5001 connected with 10.168.48.13 port 37960 Client connecting to 10.168.48.13, TCP port 5001 TCP window size: 110 KByte (default) [ 6] local 10.168.48.14 port 49627 connected with 10.168.48.13 port 5001 Waiting for server threads to complete. Interrupt again to force quit. [ 5] 0.0-10.0 sec 10.8 GBytes 9.23 Gbits/sec [ 5] MSS size 1448 bytes (MTU 1500 bytes, ethernet) [ 6] 0.0-10.0 sec 10.6 GBytes 9.11 Gbits/sec [ 6] MSS size 1448 bytes (MTU 1500 bytes, ethernet) Which is nice. Next I run: aptitude -y install qemu-kvm libvirt-bin ubuntu-vm-builder bridge- utils kvm Which results in: bioadmin@whitlam:~# iperf -sm Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) [ 4] local 10.168.48.14 port 5001 connected with 10.168.48.13 port 56405 Client connecting to 10.168.48.13, TCP port 5001 TCP window size: 1.25 MByte (default) [ 6] local 10.168.48.14 port 57001 connected with 10.168.48.13 port 5001 Waiting for server threads to complete. Interrupt again to force quit. [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.0 sec 10.5 GBytes 9.00 Gbits/sec [ 4] MSS size 1448 bytes (MTU 1500 bytes, ethernet) [ 6] 0.0-10.0 sec 2.51 GBytes 2.15 Gbits/sec [ 6] MSS size 1448 bytes (MTU 1500 bytes, ethernet) Note that the connection from the machine with KVM installed (fraser) to the other machine (whitlam) is not affected. Only the connection from whitlam to fraser. Both machines are fresh installs with nfs-common, and iperf installed. I had problems with qemu version 0.12 and virtio_net so I was using Daniel Baumans ppa for virtualisation. But this problem occurs regardless of whether I do this or not. I am happy to give versions of software but I have no idea which part could be causing this problem and installing kvm etc installs quite a few dependencies. Please let me know if you need more information To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/861141/+subscriptions
Re: [Qemu-devel] [libvirt] The design choice for how to enable block I/O throttling function in libvirt
See commens below. Zhi Yong Wu: HI, folks, I am trying to enable block I/O throttling function in libvirt. But currently i met some design questions, and don't make sure if we should extend blkiotune to support block I/O throttling or introduce one new libvirt command blkiothrottle to cover it or not. If you have some better idea, pls don't hesitate to drop your comments. If one new libvirt command blkiothrottle is introduced, I plan to design its usage syntax as below: virsh # help blkiothrottle NAME blkiothrottle - Set or display a block disk I/O throttle setting. SYNOPSIS blkiothrottledomain device [--bpsnumber] [--bps_rd number] [--bps_wrnumber] [--iopsnumber] [--iops_rdnumber] [--iops_wrnumber] DESCRIPTION Set or display a block disk I/O throttle setting. OPTIONS [--domain]string domain name, id or uuid [--device]string block device --bpsnumbertotal throughput limits in bytes/s --bps_rdnumber read throughput limits in bytes/s --bps_wrnumber write throughput limits in bytes/s --iopsnumber total operation limits in numbers/s --iops_rdnumber read operation limits in numbers/s --iops_wrnumber write operation limits in numbers/s How to display the current I/O throttle setting of a specific block device here? I prfer to have less command to be as simple as possible for users. But it seems that we need another command here instead of having a block IO specific command like iothrottle. Supposely, the next step of I/O throttling will be network device limit. Shoud we have another new command like niciothrottle?
Re: [Qemu-devel] [libvirt] The design choice for how to enable block I/O throttling function in libvirt
Zhi Yong Wu: On Tue, Aug 30, 2011 at 3:18 PM, shu mingshum...@linux.vnet.ibm.com wrote: See commens below. Zhi Yong Wu: HI, folks, I am trying to enable block I/O throttling function in libvirt. But currently i met some design questions, and don't make sure if we should extend blkiotune to support block I/O throttling or introduce one new libvirt command blkiothrottle to cover it or not. If you have some better idea, pls don't hesitate to drop your comments. If one new libvirt command blkiothrottle is introduced, I plan to design its usage syntax as below: virsh # help blkiothrottle NAME blkiothrottle - Set or display a block disk I/O throttle setting. SYNOPSIS blkiothrottledomaindevice[--bpsnumber] [--bps_rd number] [--bps_wrnumber] [--iopsnumber] [--iops_rdnumber] [--iops_wrnumber] DESCRIPTION Set or display a block disk I/O throttle setting. OPTIONS [--domain]string domain name, id or uuid [--device]string block device --bpsnumber total throughput limits in bytes/s --bps_rdnumber read throughput limits in bytes/s --bps_wrnumber write throughput limits in bytes/s --iopsnumber total operation limits in numbers/s --iops_rdnumber read operation limits in numbers/s --iops_wrnumber write operation limits in numbers/s How to display the current I/O throttle setting of a specific block device here? It will show as below: virtio0: bps=xxx, bps_rd=xxx, bps_wr=xxx, iops=xxx, iops_rd=xxx, iops_wr=xxx. With which options to the command? I guess blkiothrottle domain device will display the current setting.
