[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Qemu-devel Digest, Vol 112, Issue 523
|
From: |
Paulo Arcinas |
|
Subject: |
Re: [Qemu-devel] Qemu-devel Digest, Vol 112, Issue 523 |
|
Date: |
Mon, 23 Jul 2012 18:59:25 +0800 |
On Jul 23, 2012 6:47 PM, <address@hidden> wrote:
>
> Send Qemu-devel mailing list submissions to
> address@hidden
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.nongnu.org/mailman/listinfo/qemu-devel
> or, via email, send a message with subject or body 'help' to
> address@hidden
>
> You can reach the person managing the list at
> address@hidden
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Qemu-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: [RFC PATCH 0/2] GlusterFS support in QEMU - v2 (Vijay Bellur)
> 2. Re: [PATCH 3/3] migration: block migration when streaming
> block jobs are running. (Stefan Hajnoczi)
> 3. Re: [PATCH 1/3] block: Add bdrv_have_block_jobs() so
> migration code abort if needed. (Paolo Bonzini)
> 4. Re: [PATCH] ide scsi: Mess with geometry only for hard disk
> devices (Paolo Bonzini)
> 5. Re: [PATCH 3/3] migration: block migration when streaming
> block jobs are running. (Beno?t Canet)
> 6. Re: [PATCH 1/3] block: Add bdrv_have_block_jobs() so
> migration code abort if needed. (Beno?t Canet)
> 7. Re: [PATCH 3/3] migration: block migration when streaming
> block jobs are running. (Stefan Hajnoczi)
> 8. [PATCH] pc: Fix max_cpus (address@hidden)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 23 Jul 2012 15:06:06 +0530
> From: Vijay Bellur <address@hidden>
> To: address@hidden
> Cc: Stefan Hajnoczi <address@hidden>, Anand Avati
> <address@hidden>, address@hidden, Amar Tumballi
> <address@hidden>
> Subject: Re: [Qemu-devel] [RFC PATCH 0/2] GlusterFS support in QEMU -
> v2
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 07/23/2012 02:20 PM, Bharata B Rao wrote:
>
> >
> >> 2. It is currently not possible to bypass RPC because the glusterd
> >> managed configuration file doesn't support that.
> >
> > It is possible. Gluster already supports custom extensions
> > to volume names and it is possible to use the required volfile by specifying
> > this custom volname extension.
> >
> > For eg, if I have a volume named test, by default the volfile used for
> > it will be test-fuse.vol. Currently I can put my own custom volfile into
> > the standard location and get glusterd pick that up. I can specify
> > test.rpcbypass as volname and glusterd will pick test.rpcbypass.vol.
> >
> > What is currently not supported is the ability to create test.rpcbypass.vol
> > from gluster CLI. I believe that gluster developers are ok with enhancing
> > gluster CLI to support generating/regenerating volfiles for a given volume
> > with custom translator set.
>
>
> Yes, this would be the preferred approach. We can tune the volume file
> generation to evolve the desired configuration file.
>
> >
> >>
> >> I'm not sure if these statements are true?
> >>
> >> Would you support local volfiles in the future again? Why force users
> >> to run glusterd?
> >
> > I will let gluster folks on CC to answer this and let us know the benefits
> > of always depending on glusterd.
> >
> > I guess running glusterd would be beneficial when supporting migration. QEMU
> > working from a local volume (with volname=test.rpcbypass) can be easily
> > restarted on a different node by just changing volname to test. glusterd will
> > take care of fetching the right volfile automatically for us.
>
> Yes, running glusterd would be beneficial in migration. Without deriving
> the file from glusterd features like volume tuning, client monitoring
> etc. would not be available to to clients that talk to a gluster volume.
> Additionally, driving configuration generation and management through
> glusterd helps in standardizing and stabilizing gluster configurations.
>
> >
>
> >>
> >> Has libgfapi been released yet?
> >
> > Its part of gluster mainline now.
> >
> >> Does it have versioning which will
> >> allow the QEMU GlusterFS block driver to build against different
> >> versions? I'm just wondering how the pieces will fit together once
> >> distros start shipping them.
> >
> > I request gluster folks on CC to comment about version and shipping
> > information.
> >
>
> There is no release that contains libgfapi as yet. Once that is done, we
> can probably have the dependency specified in QEMU as well.
>
> Regards,
> Vijay
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 23 Jul 2012 10:55:41 +0100
> From: Stefan Hajnoczi <address@hidden>
> To: address@hidden
> Cc: Kevin Wolf <address@hidden>, Beno?t Canet <address@hidden>,
> address@hidden, address@hidden
> Subject: Re: [Qemu-devel] [PATCH 3/3] migration: block migration when
> streaming block jobs are running.
> Message-ID:
> <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Fri, Jul 20, 2012 at 8:32 PM, <address@hidden> wrote:
> > From: Beno?t Canet <address@hidden>
> >
> > Signed-off-by: Benoit Canet <address@hidden>
> > ---
> > migration.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/migration.c b/migration.c
> > index 8db1b43..dfce680 100644
> > --- a/migration.c
> > +++ b/migration.c
> > @@ -425,6 +425,11 @@ void qmp_migrate(const char *uri, bool has_blk, bool blk,
> > return;
> > }
> >
> > + if (bdrv_have_block_jobs()) {
> > + error_set(errp, QERR_STREAMING_BLOCKS_MIGRATION);
> > + return;
> > + }
>
> I think bdrv_have_block_jobs() is too specific and would use
> bdrv_in_use(bs) here to give basically an EBUSY-type error.
>
> Stefan
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 23 Jul 2012 12:02:58 +0200
> From: Paolo Bonzini <address@hidden>
> To: address@hidden
> Cc: address@hidden, Beno?t Canet <address@hidden>,
> address@hidden, address@hidden
> Subject: Re: [Qemu-devel] [PATCH 1/3] block: Add
> bdrv_have_block_jobs() so migration code abort if needed.
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=UTF-8
>
> Il 20/07/2012 21:32, address@hidden ha scritto:
> > +bool bdrv_have_block_jobs(void)
> > +{
> > + BlockDriverState *bs;
> > +
> > + QTAILQ_FOREACH(bs, &bdrv_states, list) {
> > + if (bs->job || bdrv_in_use(bs)) {
> > + return true;
> > + }
> > + bdrv_close(bs);
>
> Why close the device here?
>
> Paolo
>
> > + }
> > +
> > + return false;
> > +}
> > +
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 23 Jul 2012 12:03:55 +0200
> From: Paolo Bonzini <address@hidden>
> To: Markus Armbruster <address@hidden>
> Cc: address@hidden, address@hidden
> Subject: Re: [Qemu-devel] [PATCH] ide scsi: Mess with geometry only
> for hard disk devices
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-15
>
> Il 23/07/2012 09:25, Markus Armbruster ha scritto:
> > Ping?
> >
> > Markus Armbruster <address@hidden> writes:
> >
> >> Legacy -drive cyls=... are now ignored completely when the drive
> >> doesn't back a hard disk device. Before, they were first checked
> >> against a hard disk's limits, then ignored.
> >>
> >> Signed-off-by: Markus Armbruster <address@hidden>
> >> ---
> >> hw/ide/qdev.c | 3 ++-
> >> hw/scsi-disk.c | 3 ++-
> >> 2 files changed, 4 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
> >> index 22e58df..5ea9b8f 100644
> >> --- a/hw/ide/qdev.c
> >> +++ b/hw/ide/qdev.c
> >> @@ -149,7 +149,8 @@ static int ide_dev_initfn(IDEDevice *dev, IDEDriveKind kind)
> >> }
> >>
> >> blkconf_serial(&dev->conf, &dev->serial);
> >> - if (blkconf_geometry(&dev->conf, &dev->chs_trans, 65536, 16, 255) < 0) {
> >> + if (kind != IDE_CD
> >> + && blkconf_geometry(&dev->conf, &dev->chs_trans, 65536, 16, 255) < 0) {
> >> return -1;
> >> }
> >>
> >> diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
> >> index 525816c..318318c 100644
> >> --- a/hw/scsi-disk.c
> >> +++ b/hw/scsi-disk.c
> >> @@ -1750,7 +1750,8 @@ static int scsi_initfn(SCSIDevice *dev)
> >> }
> >>
> >> blkconf_serial(&s->qdev.conf, &s->serial);
> >> - if (blkconf_geometry(&dev->conf, NULL, 65535, 255, 255) < 0) {
> >> + if (dev->type == TYPE_DISK
> >> + && blkconf_geometry(&dev->conf, NULL, 65535, 255, 255) < 0) {
> >> return -1;
> >> }
> >
> >
>
> Acked-by: Paolo Bonzini <address@hidden>
>
> Kevin, are you taking this patch?
>
> Paolo
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 23 Jul 2012 12:17:35 +0200
> From: Beno?t Canet <address@hidden>
> To: Stefan Hajnoczi <address@hidden>
> Cc: Kevin Wolf <address@hidden>, address@hidden,
> address@hidden, address@hidden
> Subject: Re: [Qemu-devel] [PATCH 3/3] migration: block migration when
> streaming block jobs are running.
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=iso-8859-1
>
> Would
>
> int bdrv_are_busy(void)
> {
> BlockDriverState *bs;
>
> QTAILQ_FOREACH(bs, &bdrv_states, list) {
> if (bs->job || bdrv_in_use(bs)) {
> return -EBUSY;
> }
> }
>
> return 0;
> }
>
> be more acceptable ?
>
> Beno?t
>
> Le Monday 23 Jul 2012 ? 10:55:41 (+0100), Stefan Hajnoczi a ?crit :
> > On Fri, Jul 20, 2012 at 8:32 PM, <address@hidden> wrote:
> > > From: Beno?t Canet <address@hidden>
> > >
> > > Signed-off-by: Benoit Canet <address@hidden>
> > > ---
> > > migration.c | 5 +++++
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/migration.c b/migration.c
> > > index 8db1b43..dfce680 100644
> > > --- a/migration.c
> > > +++ b/migration.c
> > > @@ -425,6 +425,11 @@ void qmp_migrate(const char *uri, bool has_blk, bool blk,
> > > return;
> > > }
> > >
> > > + if (bdrv_have_block_jobs()) {
> > > + error_set(errp, QERR_STREAMING_BLOCKS_MIGRATION);
> > > + return;
> > > + }
> >
> > I think bdrv_have_block_jobs() is too specific and would use
> > bdrv_in_use(bs) here to give basically an EBUSY-type error.
> >
> > Stefan
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 23 Jul 2012 12:25:38 +0200
> From: Beno?t Canet <address@hidden>
> To: Paolo Bonzini <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden,
> address@hidden
> Subject: Re: [Qemu-devel] [PATCH 1/3] block: Add
> bdrv_have_block_jobs() so migration code abort if needed.
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=iso-8859-1
>
> > Why close the device here?
>
> Thanks
>
> Beno?t
>
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 23 Jul 2012 11:43:54 +0100
> From: Stefan Hajnoczi <address@hidden>
> To: Beno?t Canet <address@hidden>
> Cc: Kevin Wolf <address@hidden>, address@hidden,
> address@hidden, address@hidden
> Subject: Re: [Qemu-devel] [PATCH 3/3] migration: block migration when
> streaming block jobs are running.
> Message-ID:
> <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Mon, Jul 23, 2012 at 11:17 AM, Beno?t Canet <address@hidden> wrote:
> > Would
> >
> > int bdrv_are_busy(void)
> > {
> > BlockDriverState *bs;
> >
> > QTAILQ_FOREACH(bs, &bdrv_states, list) {
> > if (bs->job || bdrv_in_use(bs)) {
> > return -EBUSY;
> > }
> > }
> >
> > return 0;
> > }
> >
> > be more acceptable ?
>
> Looks fine to me.
>
> Stefan
>
>
>
> ------------------------------
>
> Message: 8
> Date: Mon, 23 Jul 2012 18:47:35 +0800
> From: address@hidden
> To: qemu-devel <address@hidden>
> Cc: Anthony Liguori <address@hidden>, Stefan Hajnoczi
> <address@hidden>, Dunrong Huang <address@hidden>
> Subject: [Qemu-devel] [PATCH] pc: Fix max_cpus
> Message-ID: <address@hidden>
>
> From: Dunrong Huang <address@hidden>
>
> The VCPU count limit in kernel now is 254, defined by KVM_MAX_VCPUS
> in kernel's header files. But the count limit in QEMU is 255,
> so QEMU will failed to start if user passes "-enable-kvm" and "-smp 255"
> to it.
>
> This patch intruduces a Macro MAX_VCPUS whose value is KVM_MAX_VCPUS
> if CONFIG_KVM is defined. If user do not use kvm, set it's value to 255.
>
> Signed-off-by: Dunrong Huang <address@hidden>
> ---
> hw/pc_piix.c | 28 +++++++++++++++++++---------
> 1 files changed, 19 insertions(+), 9 deletions(-)
>
> diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> index 0c0096f..49cda51 100644
> --- a/hw/pc_piix.c
> +++ b/hw/pc_piix.c
> @@ -49,6 +49,16 @@
>
> #define MAX_IDE_BUS 2
>
> +#ifndef KVM_MAX_VCPUS
> +#define KVM_MAX_VCPUS 254
> +#endif
> +
> +#ifdef CONFIG_KVM
> +#define MAX_VCPUS KVM_MAX_VCPUS
> +#else
> +#define MAX_VCPUS 255
> +#endif
> +
> static const int ide_iobase[MAX_IDE_BUS] = { 0x1f0, 0x170 };
> static const int ide_iobase2[MAX_IDE_BUS] = { 0x3f6, 0x376 };
> static const int ide_irq[MAX_IDE_BUS] = { 14, 15 };
> @@ -354,7 +364,7 @@ static QEMUMachine pc_machine_v1_2 = {
> .alias = "pc",
> .desc = "Standard PC",
> .init = pc_init_pci,
> - .max_cpus = 255,
> + .max_cpus = MAX_VCPUS,
> .is_default = 1,
> };
>
> @@ -381,7 +391,7 @@ static QEMUMachine pc_machine_v1_1 = {
> .name = "pc-1.1",
> .desc = "Standard PC",
> .init = pc_init_pci,
> - .max_cpus = 255,
> + .max_cpus = MAX_VCPUS,
> .compat_props = (GlobalProperty[]) {
> PC_COMPAT_1_1,
> { /* end of list */ }
> @@ -416,7 +426,7 @@ static QEMUMachine pc_machine_v1_0 = {
> .name = "pc-1.0",
> .desc = "Standard PC",
> .init = pc_init_pci,
> - .max_cpus = 255,
> + .max_cpus = MAX_VCPUS,
> .compat_props = (GlobalProperty[]) {
> PC_COMPAT_1_0,
> { /* end of list */ }
> @@ -431,7 +441,7 @@ static QEMUMachine pc_machine_v0_15 = {
> .name = "pc-0.15",
> .desc = "Standard PC",
> .init = pc_init_pci,
> - .max_cpus = 255,
> + .max_cpus = MAX_VCPUS,
> .compat_props = (GlobalProperty[]) {
> PC_COMPAT_0_15,
> { /* end of list */ }
> @@ -463,7 +473,7 @@ static QEMUMachine pc_machine_v0_14 = {
> .name = "pc-0.14",
> .desc = "Standard PC",
> .init = pc_init_pci,
> - .max_cpus = 255,
> + .max_cpus = MAX_VCPUS,
> .compat_props = (GlobalProperty[]) {
> PC_COMPAT_0_14,
> {
> @@ -496,7 +506,7 @@ static QEMUMachine pc_machine_v0_13 = {
> .name = "pc-0.13",
> .desc = "Standard PC",
> .init = pc_init_pci_no_kvmclock,
> - .max_cpus = 255,
> + .max_cpus = MAX_VCPUS,
> .compat_props = (GlobalProperty[]) {
> PC_COMPAT_0_13,
> {
> @@ -533,7 +543,7 @@ static QEMUMachine pc_machine_v0_12 = {
> .name = "pc-0.12",
> .desc = "Standard PC",
> .init = pc_init_pci_no_kvmclock,
> - .max_cpus = 255,
> + .max_cpus = MAX_VCPUS,
> .compat_props = (GlobalProperty[]) {
> PC_COMPAT_0_12,
> {
> @@ -566,7 +576,7 @@ static QEMUMachine pc_machine_v0_11 = {
> .name = "pc-0.11",
> .desc = "Standard PC, qemu 0.11",
> .init = pc_init_pci_no_kvmclock,
> - .max_cpus = 255,
> + .max_cpus = MAX_VCPUS,
> .compat_props = (GlobalProperty[]) {
> PC_COMPAT_0_11,
> {
> @@ -587,7 +597,7 @@ static QEMUMachine pc_machine_v0_10 = {
> .name = "pc-0.10",
> .desc = "Standard PC, qemu 0.10",
> .init = pc_init_pci_no_kvmclock,
> - .max_cpus = 255,
> + .max_cpus = MAX_VCPUS,
> .compat_props = (GlobalProperty[]) {
> PC_COMPAT_0_11,
> {
> --
> 1.7.8.6
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Qemu-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>
> End of Qemu-devel Digest, Vol 112, Issue 523
> ********************************************
- Re: [Qemu-devel] Qemu-devel Digest, Vol 112, Issue 523,
Paulo Arcinas <=