device, and what was your device backed by?
>
> Very simple:
> ./qemu-system-x86_64 -enable-kvm -smp 4 -m 4096 -net none rhel6u5.img
> -monitor stdio
>
> And it's a local migration. I will do the test between two physical machines
> later.
OK, but for shared storage you would have to add cache=none (or something like
that),
so that would change the behaviour anyway.
Dave
>
>
> Liang
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
lication.txt | 147 +++
> include/block/block.h | 5 +
> include/block/block_int.h | 13 ++
> include/qemu/hbitmap.h | 8 +
> qapi/block.json| 16 ++
> tests/qemu-iotests/051 | 13 ++
> tests/qemu-iotests/051.out | 13 ++
> util/hbitmap.c
> > the console or ping the system, but no longer login.
> >
> > Thank you,
> > Peter
>
> Interesting observation: Migrating the vServer again seems to fix to problem
> (at least in one case I could test just now).
>
> 2.6.8-24-smp is also affected.
How often does it fail - you say 'sometimes' - is it a 1/10 or a 1/1000 ?
I'm not sure at what kernel version the switch is, but newer kernels use some
code shared with the newer SATA world (libata?) where as older kernels had
separate IDE code, so the behaviour of the two can be quite different.
Dave
Dave
> Thanks,
> Peter
>
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Peter Lieven (p...@kamp.de) wrote:
> Hi David,
>
> Am 07.04.2015 um 10:43 schrieb Dr. David Alan Gilbert:
> >>>> Any particular workload or reproducer?
> >>> Workload is almost zero. I try to figure out if there is a way to trigger
> >>> it.
>
* Peter Lieven (p...@kamp.de) wrote:
> Am 07.04.2015 um 17:29 schrieb Dr. David Alan Gilbert:
> > * Peter Lieven (p...@kamp.de) wrote:
> >> Hi David,
> >>
> >> Am 07.04.2015 um 10:43 schrieb Dr. David Alan Gilbert:
> >>>>>> Any particular w
* Peter Lieven (p...@kamp.de) wrote:
> Am 07.04.2015 um 21:01 schrieb Dr. David Alan Gilbert:
> >* Peter Lieven (p...@kamp.de) wrote:
> >>Am 07.04.2015 um 17:29 schrieb Dr. David Alan Gilbert:
> >>>* Peter Lieven (p...@kamp.de) wrote:
> >>>>Hi David,
&
n-disk.driver=qcow2,\
> + backing_reference.hidden-disk.allow-write-backing-file=on
> + Then run qmp command:
> +nbd_server_start host:port
> + Note:
> + 1. The export name for the same disk must be the same in primary
> + and secondary QEMU command line
> + 2. The qmp command nbd-server-start must be run before running the
> + qmp command migrate on primary QEMU
> + 3. Don't use nbd-server-start's other options
> + 4. Active disk, hidden disk and nbd target's length should be the
> + same.
> + 5. It is better to put active disk and hidden disk in ramdisk.
> + 6. It is all a single argument to -drive, and you should ignore
> + the leading whitespace.
> --
> 2.1.0
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
a primary failure, the secondary now needs to morph into something
like a primary, and somehow you need to bring up a new secondary
and get that new secondary an image of the primaries current disk.
Dave
> Paolo
>
> > Anyway, even if we move it to a second step, it looks li
* Paolo Bonzini (pbonz...@redhat.com) wrote:
>
>
> On 23/04/2015 14:05, Dr. David Alan Gilbert wrote:
> > As presented at the moment, I don't see there's any dynamic reconfiguration
> > on the primary side at the moment
>
> So that means the bdrv_start_
is ready. In this case, I think
> there is no need to touch nbd client.
Yes, I think maybe the harder part is getting a copy of the current disk
contents to the new secondary while the new primary is still running.
Dave
>
> Thanks
> Wen Congyang
>
> >
> > Kevin/Stefan, is there a design document somewhere that covers at least
> > static filters?
> >
> > Paolo
> > .
> >
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
gt; failover.
>
> I think anyone serious about fault tolerance would deploy a Backup
> Secondary, otherwise the system cannot survive two failures unless a
> human administrator is lucky/fast enough to set up a new Secondary.
I'd assumed that a higher level management layer would do
* Stefan Hajnoczi (stefa...@redhat.com) wrote:
> On Tue, May 05, 2015 at 04:23:56PM +0100, Dr. David Alan Gilbert wrote:
> > * Stefan Hajnoczi (stefa...@redhat.com) wrote:
> > > On Fri, Apr 24, 2015 at 11:36:35AM +0200, Paolo Bonzini wrote:
> > > >
> > &
* Kevin Wolf (kw...@redhat.com) wrote:
> Am 08.05.2015 um 10:42 hat Stefan Hajnoczi geschrieben:
> > On Tue, May 05, 2015 at 04:23:56PM +0100, Dr. David Alan Gilbert wrote:
> > > * Stefan Hajnoczi (stefa...@redhat.com) wrote:
> > > > On Fri, Apr 24, 2015 at 11:36:3
e.driver=qcow2,\
> + file.backing_reference.drive_id=nbd_target1,\
> + file.backing_reference.hidden-disk.file.filename=hidden_disk.qcow2,\
> + file.backing_reference.hidden-disk.driver=qcow2,\
> + file.backing_reference.hidden-disk.allow-write-backing-file=o
* Wen Congyang (ghost...@gmail.com) wrote:
> At 2015/5/14 19:19, Dr. David Alan Gilbert Wrote:
> >One thing I wanted to check I understand; how much RAM do the active and
> >hidden
> >disks use; lets say during the 1st checkpoint 10MB of disk is written,
> >and
| 16 ++
> qemu-options.hx| 4 +
> tests/qemu-iotests/051 | 13 ++
> tests/qemu-iotests/051.out | 13 ++
> 16 files changed, 1260 insertions(+), 30 deletions(-)
> create mode 100644 block/replication.c
> create mode 100644 docs/block-replication.txt
>
> --
> 2.1.0
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
oesn't address John's (valid) concerns - would be the most reasonable:
>
> 3. Don't add any VMState fields now and just do the post_load handler.
>If we ever extend fdc in a way that makes it impossible to
>reconstruct the phase from other migrated state, we add a subsection
>that is only sent in cases where it differs from the reconstructed
>value.
Dave
>
> Kevin
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
y narrow use case compared to old->new.
I have to care about it downstream so I'd prefer if it wasn't
broken upstream except where really hard.
Dave
> -- PMM
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
WRITE;
> > fdctrl->data_pos = 0;
> > fdctrl->msr &= ~(FD_MSR_CMDBUSY | FD_MSR_DIO);
> > @@ -1146,6 +1230,7 @@ static void fdctrl_to_command_phase(FDCtrl *fdctrl)
> > * @fifo_len is the number of result bytes to be read out. */
> > static void fdctrl_to_result_phase(FDCtrl *fdctrl, int fifo_len)
> > {
> > +fdctrl->phase = FD_PHASE_RESULT;
> > fdctrl->data_dir = FD_DIR_READ;
> > fdctrl->data_len = fifo_len;
> > fdctrl->data_pos = 0;
> > @@ -1912,6 +1997,9 @@ static void fdctrl_handle_relative_seek_out(FDCtrl
> > *fdctrl, int direction)
> > fdctrl_raise_irq(fdctrl);
> > }
> >
> > +/*
> > + * Handlers for the execution phase of each command
> > + */
> > static const struct {
> > uint8_t value;
> > uint8_t mask;
> > @@ -2015,6 +2103,7 @@ static void fdctrl_write_data(FDCtrl *fdctrl,
> > uint32_t value)
> > /* We now have all parameters
> > * and will be able to treat the command
> > */
> > +fdctrl->phase = FD_PHASE_EXECUTION;
> > if (fdctrl->data_state & FD_STATE_FORMAT) {
> > fdctrl_format_sector(fdctrl);
> > return;
> >
>
> Acked-by: John Snow
>
> Looks ok to me, CC David Gilbert for a migration look-see.
>
> --js
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Markus Armbruster (arm...@redhat.com) wrote:
> "Dr. David Alan Gilbert" writes:
>
> > * John Snow (js...@redhat.com) wrote:
> >>
> >>
> >> On 05/21/2015 09:19 AM, Kevin Wolf wrote:
> >> > The floppy controller spec describes thre
* Kevin Wolf (kw...@redhat.com) wrote:
> Am 29.05.2015 um 10:33 hat Dr. David Alan Gilbert geschrieben:
> > * Markus Armbruster (arm...@redhat.com) wrote:
> > > "Dr. David Alan Gilbert" writes:
> > >
> > > > * John Snow (js...@redhat.com) wrote:
* Kevin Wolf (kw...@redhat.com) wrote:
> Am 29.05.2015 um 11:38 hat Dr. David Alan Gilbert geschrieben:
> > * Kevin Wolf (kw...@redhat.com) wrote:
> > > Am 29.05.2015 um 10:33 hat Dr. David Alan Gilbert geschrieben:
> > > > * Markus Armbruster (arm...@redhat.com) wr
* Peter Maydell (peter.mayd...@linaro.org) wrote:
> On 29 May 2015 at 11:34, Dr. David Alan Gilbert wrote:
> > It's the destination I'm worried about here, not the source; lets say
> > you have two devices, a & b. 'a' gets serialised, but then '
nd again after
> migration. If the disk is not synced before migration, we will use disk
> mirgation or mirror
> job to sync it.
Can you document the way that you use disk migration or mirror, together
with your COLO setup? I think it would make it easier to understand this
restriction.
At the moment I don't understand how you can switch from doing a disk migration
into COLO mode - there seems to be a gap between the end of disk migration and
the start
of COLO.
> So we cannot start block replication when migration is running. We need
> that nbd
> client is not ready when migration is running, and it is ready between
> migration ends
> and checkpoint begins. Using a monotir command add the nbd client will cause
> larger
> downtime. So if the nbd client has been added(only not connect to the nbd
> server),
> we can connect to nbd server automatically.
Without the disk migration or mirror, I can't see the need for the delayed
bdrv_connect.
I can see that you want to do a disconnect at failover, however you need
to take care because if the network is broken at the point of failover
you need to make sure nothing blocks.
Dave
>
> Thanks
> Wen Congyang
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Wen Congyang (we...@cn.fujitsu.com) wrote:
> On 06/24/2015 10:07 PM, Dr. David Alan Gilbert wrote:
> > * Wen Congyang (ghost...@gmail.com) wrote:
> >> At 2015/6/19 18:49, Stefan Hajnoczi Wrote:
> >>> On Fri, Jun 19, 2015 at 08:54:56AM +0800, Wen Congyang wrote:
* Wen Congyang (we...@cn.fujitsu.com) wrote:
> On 06/27/2015 03:03 AM, Dr. David Alan Gilbert wrote:
> > Ah, I hadn't realised you could do that; so do you just do:
> >
> > migrate_set_parameter colo on
> > migrate -d -b tcp:otherhhost:port
> >
> &
* Wen Congyang (we...@cn.fujitsu.com) wrote:
> On 07/01/2015 03:01 AM, Dr. David Alan Gilbert wrote:
> > * Wen Congyang (we...@cn.fujitsu.com) wrote:
> >> On 06/27/2015 03:03 AM, Dr. David Alan Gilbert wrote:
> >
> >
> >
> >>> Ah, I hadn
* Wen Congyang (we...@cn.fujitsu.com) wrote:
> On 07/01/2015 04:11 PM, Dr. David Alan Gilbert wrote:
> > * Wen Congyang (we...@cn.fujitsu.com) wrote:
> >> On 07/01/2015 03:01 AM, Dr. David Alan Gilbert wrote:
> >>> * Wen Congyang (we...@cn.fujitsu.com) wrote:
>
* Wen Congyang (we...@cn.fujitsu.com) wrote:
> On 07/02/2015 02:42 AM, Dr. David Alan Gilbert wrote:
> > * Wen Congyang (we...@cn.fujitsu.com) wrote:
> >> On 07/01/2015 04:11 PM, Dr. David Alan Gilbert wrote:
> >>> * Wen Congyang (we...@cn.fujitsu.com) wrote:
>
lude/qemu/option.h | 2 +
> include/sysemu/block-backend.h | 3 +
> include/sysemu/blockdev.h | 2 +
> qapi/block.json| 16 ++
> util/qemu-option.c | 44
> 18 files changed, 1303 insertions(+), 47 deletions(-)
> create mode 100644 block/replication.c
> create mode 100644 docs/block-replication.txt
>
> --
> 2.4.3
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Wen Congyang (ghost...@gmail.com) wrote:
> At 2015/7/3 23:30, Dr. David Alan Gilbert Wrote:
> >* Wen Congyang (we...@cn.fujitsu.com) wrote:
> >>Block replication is a very important feature which is used for
> >>continuous checkpoints(for example: COLO).
> >>
* Wen Congyang (we...@cn.fujitsu.com) wrote:
> On 07/07/2015 08:25 AM, Michael R. Hines wrote:
> > On 07/04/2015 07:46 AM, Wen Congyang wrote:
> >> At 2015/7/3 23:30, Dr. David Alan Gilbert Wrote:
> >>> * Wen Congyang (we...@cn.fujitsu.com) wrote:
> >>&
t; /**
> @@ -348,4 +351,13 @@ void block_job_defer_to_main_loop(BlockJob *job,
>BlockJobDeferToMainLoopFn *fn,
> void *opaque);
>
> +/**
> + * block_job_do_checkpoint:
> + * @job: The job.
> + * @errp: Error object.
> + *
> + * Do block checkpoint on the specified job.
> + */
> +void block_job_do_checkpoint(BlockJob *job, Error **errp);
> +
> #endif
> --
> 2.4.3
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Wen Congyang (we...@cn.fujitsu.com) wrote:
> On 07/08/2015 11:49 PM, Michael R. Hines wrote:
> > On 07/07/2015 08:38 PM, Wen Congyang wrote:
> >> On 07/08/2015 12:56 AM, Michael R. Hines wrote:
> >>> On 07/07/2015 04:23 AM, Paolo Bonzini wrote:
> >>>>
hat isn't working in
this setup is migrate -b, I get:
(qemu) Receiving block device images
Error unknown block device disk1
qemu-system-x86_64: error while loading state section id 1(block)
qemu-system-x86_64: load of migration failed: Invalid argument
Can you explain the id=disk1 on the master s
* Wen Congyang (we...@cn.fujitsu.com) wrote:
> On 07/09/2015 05:16 PM, Dr. David Alan Gilbert wrote:
> > * Wen Congyang (we...@cn.fujitsu.com) wrote:
> >
> >>>> I have sent the v8. But the usage is not changed. You can setup the
> >>>> environment a
* Wen Congyang (we...@cn.fujitsu.com) wrote:
> On 07/09/2015 06:37 PM, Dr. David Alan Gilbert wrote:
> > * Wen Congyang (we...@cn.fujitsu.com) wrote:
> >> On 07/09/2015 05:16 PM, Dr. David Alan Gilbert wrote:
> >>> * Wen Congyang (we...@cn.fujitsu.com) wrote:
> >
more important problem.
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
;C", "D", "E" ], 'vote-threshold':3,
> 'child-errors-okay': [ "E" ] }
>
> The code to ignore the errors is then done in the quorum itself (the BDS
> for E does not have to care about a special ignore-errors property, but
> just alwa
4 ++
> qmp-commands.hx | 61 +++
> 10 files changed, 329 insertions(+), 5 deletions(-)
>
> --
> 2.4.3
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Wen Congyang (we...@cn.fujitsu.com) wrote:
> On 09/22/2015 07:15 PM, Dr. David Alan Gilbert wrote:
> > * Wen Congyang (we...@cn.fujitsu.com) wrote:
> >> If quorum's child is broken, we can use mirror job to replace it.
> >> But sometimes, the user only need
res_postcopy_only);
> }
> }
>
> diff --git a/migration/trace-events b/migration/trace-events
> index 6f29fcc686..a04fffb877 100644
> --- a/migration/trace-events
> +++ b/migration/trace-events
> @@ -86,7 +86,7 @@ migrate_fd_cleanup(void) ""
> migrate_fd_error(const char *error_desc) "error=%s"
> migrate_fd_cancel(void) ""
> migrate_handle_rp_req_pages(const char *rbname, size_t start, size_t len)
> "in %s at 0x%zx len 0x%zx"
> -migrate_pending(uint64_t size, uint64_t max, uint64_t post, uint64_t
> nonpost) "pending size %" PRIu64 " max %" PRIu64 " (post=%" PRIu64 "
> nonpost=%" PRIu64 ")"
> +migrate_pending(uint64_t size, uint64_t max, uint64_t pre, uint64_t compat,
> uint64_t post) "pending size %" PRIu64 " max %" PRIu64 " (pre = %" PRIu64 "
> compat=%" PRIu64 " post=%" PRIu64 ")"
> migrate_send_rp_message(int msg_type, uint16_t len) "%d: len %d"
> migration_completion_file_err(void) ""
> migration_completion_postcopy_end(void) ""
> --
> 2.11.1
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
current.rp_mutex);
> qemu_event_init(&mis_current.main_thread_load_event, false);
> +
> +init_dirty_bitmap_incoming_migration();
> +
You might want to consider if that's better in vl.c near where
ram_mig_init() is, OR whether there should be a call in
migratation_incoming_state_destroy to clean it up.
(Although I doubt the cases where the destroy happens are interesting
for postcopy bitmaps).
> once = true;
> }
> return &mis_current;
> @@ -297,6 +300,8 @@ static void process_incoming_migration_bh(void *opaque)
> state, we need to obey autostart. Any other state is set with
> runstate_set. */
>
> +dirty_bitmap_mig_before_vm_start();
> +
> if (!global_state_received() ||
> global_state_get_runstate() == RUN_STATE_RUNNING) {
> if (autostart) {
> diff --git a/migration/savevm.c b/migration/savevm.c
> index e5d557458e..93b339646b 100644
> --- a/migration/savevm.c
> +++ b/migration/savevm.c
> @@ -1673,6 +1673,8 @@ static void loadvm_postcopy_handle_run_bh(void *opaque)
>
> trace_loadvm_postcopy_handle_run_vmstart();
>
> +dirty_bitmap_mig_before_vm_start();
> +
> if (autostart) {
> /* Hold onto your hats, starting the CPU */
> vm_start();
> diff --git a/vl.c b/vl.c
> index e517a8d995..0ef3f2b5a2 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -4514,6 +4514,7 @@ int main(int argc, char **argv, char **envp)
>
> blk_mig_init();
> ram_mig_init();
> +dirty_bitmap_mig_init();
>
> /* If the currently selected machine wishes to override the units-per-bus
> * property of its default HBA interface type, do so now. */
> diff --git a/migration/Makefile.objs b/migration/Makefile.objs
> index 99e038024d..c83ec47ba8 100644
> --- a/migration/Makefile.objs
> +++ b/migration/Makefile.objs
> @@ -6,6 +6,7 @@ common-obj-y += qemu-file.o global_state.o
> common-obj-y += qemu-file-channel.o
> common-obj-y += xbzrle.o postcopy-ram.o
> common-obj-y += qjson.o
> +common-obj-y += block-dirty-bitmap.o
>
> common-obj-$(CONFIG_RDMA) += rdma.o
>
> diff --git a/migration/trace-events b/migration/trace-events
> index a04fffb877..e9eb8078d4 100644
> --- a/migration/trace-events
> +++ b/migration/trace-events
> @@ -227,3 +227,17 @@ colo_vm_state_change(const char *old, const char *new)
> "Change '%s' => '%s'"
> colo_send_message(const char *msg) "Send '%s' message"
> colo_receive_message(const char *msg) "Receive '%s' message"
> colo_failover_set_state(const char *new_state) "new state %s"
> +
> +# migration/block-dirty-bitmap.c
> +send_bitmap_header_enter(void) ""
> +send_bitmap_bits(uint32_t flags, uint64_t start_sector, uint32_t nr_sectors,
> uint64_t data_size) "\n flags:0x%x\n start_sector: %" PRIu64 "\n
> nr_sectors: %" PRIu32 "\n data_size:%" PRIu64 "\n"
Tracing doesn't have \n's in
> +dirty_bitmap_save_iterate(int in_postcopy) "in postcopy: %d"
> +dirty_bitmap_save_complete_enter(void) ""
> +dirty_bitmap_save_complete_finish(void) ""
> +dirty_bitmap_save_pending(uint64_t pending, uint64_t max_size) "pending %"
> PRIu64 " max: %" PRIu64
> +dirty_bitmap_load_complete(void) ""
> +dirty_bitmap_load_bits_enter(uint64_t first_sector, uint32_t nr_sectors)
> "chunk: %" PRIu64 " %" PRIu32
> +dirty_bitmap_load_bits_zeroes(void) ""
> +dirty_bitmap_load_header(uint32_t flags) "flags 0x%x"
> +dirty_bitmap_load_enter(void) ""
> +dirty_bitmap_load_success(void) ""
So other than minor bits, this one looks OK from a migration side; I
can't say I've followed the block side of the patch though.
Dave
> --
> 2.11.1
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
ap_'
> +name += '_online' if cmb[2] else '_offline'
> +
> +# TODO fix shared-storage bitmap migration and enable cases for it
> +args = list(cmb) + [False]
> +
> +inject_test_case(TestDirtyBitmapMigration, name, 'do_test_migration',
> + *args)
> +
> +
> +if __name__ == '__main__':
> +iotests.main(supported_fmts=['qcow2'])
> diff --git a/tests/qemu-iotests/169.out b/tests/qemu-iotests/169.out
> new file mode 100644
> index 00..594c16f49f
> --- /dev/null
> +++ b/tests/qemu-iotests/169.out
> @@ -0,0 +1,5 @@
> +
> +--
> +Ran 8 tests
> +
> +OK
> diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
> index a2dfe79d86..498c52c4c1 100644
> --- a/tests/qemu-iotests/group
> +++ b/tests/qemu-iotests/group
> @@ -169,6 +169,7 @@
> 162 auto quick
> 163 rw auto quick
> 165 rw auto quick
> +169 rw auto quick
> 170 rw auto quick
> 171 rw auto quick
> 172 auto
> --
> 2.11.1
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
iotests.py b/tests/qemu-iotests/iotests.py
> index 5a10b2d534..a9bded77e4 100644
> --- a/tests/qemu-iotests/iotests.py
> +++ b/tests/qemu-iotests/iotests.py
> @@ -473,6 +473,10 @@ def verify_platform(supported_oses=['linux']):
> if True not in [sys.platform.startswith(x) for
* Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) wrote:
> 12.03.2018 18:30, Dr. David Alan Gilbert wrote:
> > * Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) wrote:
> > > There would be savevm states (dirty-bitmap) which can migrate only in
> &g
* John Snow (js...@redhat.com) wrote:
>
>
> On 03/12/2018 11:30 AM, Dr. David Alan Gilbert wrote:
> > * Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) wrote:
> >> There would be savevm states (dirty-bitmap) which can migrate only in
> >> postcopy st
* Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) wrote:
> 13.03.2018 13:30, Dr. David Alan Gilbert wrote:
> > * Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) wrote:
> > > 12.03.2018 18:30, Dr. David Alan Gilbert wrote:
> > > > * Vladimi
* Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) wrote:
> Allow migrate-start-postcopy for any postcopy type
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Dr. David Alan Gilbert
> ---
> migration/migration.c | 2 +-
> 1 file changed, 1 insert
* Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) wrote:
> 12.03.2018 19:09, Dr. David Alan Gilbert wrote:
> > * Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) wrote:
> > > Postcopy migration of dirty bitmaps. Only named dirty bitmaps a
* Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) wrote:
> There would be savevm states (dirty-bitmap) which can migrate only in
> postcopy stage. The corresponding pending is introduced here.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Dr. David
&finish_lock);
> +
> +for (item = enabled_bitmaps; item; item = g_slist_next(item)) {
> +DirtyBitmapLoadBitmapState *b = item->data;
> +
> +if (b->bitmap == s->bitmap) {
> +b->migrated = true;
> +break;
> +}
rrors, 0 warnings, 816 lines checked
>
> Your patch has style problems, please review. If any of these errors
> are false positives report them to the maintainer, see
> CHECKPATCH in MAINTAINERS.
>
> Checking PATCH 12/13: iotests: add dirty bitmap migration test...
> Checking PATCH 13/13: iotests: add dirty bitmap postcopy test...
> === OUTPUT END ===
>
> Test command exited with code: 1
>
>
> ---
> Email generated automatically by Patchew [http://patchew.org/].
> Please send your feedback to patchew-de...@freelists.org
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
> > -Original Messages-
> > From: "Dr. David Alan Gilbert"
> > Sent Time: 2018-03-14 04:10:24 (Wednesday)
> > To: "Vladimir Sementsov-Ogievskiy" ,
> > suhan...@mails.ucas.ac.cn, ebl...@redhat.com
> > Cc: "peter.mayd...@linaro.or
t OOB */
> continue;
> }
> - qlist_append(cap_list, qstring_from_str(QMPCapability_str(cap)));
> +qlist_append_str(cap_list, QMPCapability_str(cap));
> }
>
> return qobject_from_jsonf("{'QMP': {'version': %p, 'capabilities': %p}}",
For monitor:
Acked-by: Dr. David Alan Gilbert
> --
> 2.14.3
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
ate.read_done) <
> MAX_IO_BUFFERS) {
> blk_mig_unlock();
> --
> 2.7.4
>
>
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
s from about September); but it got
bogged down in trying to fix output visitors; it's possible the visitor
code has been fixed since then though.
The 'Show values and description when using "qom-list"' patch
that Ricardo Perez Blanco posted would do something similar.
break;
> +}
> +}
> +
> +if (window) {
> +munmap(window, length);
> +}
> +}
> +
> static void coroutine_fn raw_co_invalidate_cache(BlockDriverState *bs,
> Error **errp)
> {
> @@ -
aw_co_invalidate_cache,
> .bdrv_co_pwrite_zeroes = hdev_co_pwrite_zeroes,
>
> .bdrv_co_preadv = raw_co_preadv,
> @@ -2927,6 +2965,7 @@ static BlockDriver bdrv_host_cdrom = {
> .bdrv_reopen_abort = raw_reopen_abort,
> .bdrv_co_create_opts = hdev_co_create_opts,
> .create_opts = &raw_create_opts,
> +.bdrv_co_invalidate_cache = raw_co_invalidate_cache,
>
>
> .bdrv_co_preadv = raw_co_preadv,
> --
> 2.14.3
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
e
destination was run with -S and for some external failure reason, the
management layer decides to kill the destination and restart the source.
And you're right, that at that point there's no one holding the lock,
so the source can't be sure that no one snuck in and fiddled with the
disk before restarting.
Dave
> --
> Best regards,
> Vladimir
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
| 2 +-
> tests/qemu-iotests/149 | 3 +-
> tests/qemu-iotests/165 | 3 +-
> tests/qemu-iotests/iotests.py | 5 +-
> tests/qemu-iotests/nbd-fault-injector.py | 7 +--
> tests/qemu-iotests/qcow2.py | 39 +++---
> tests/qemu-iotests/qed.py| 17 +++---
> tests/vm/basevm.py | 3 +-
> 41 files changed, 337 insertions(+), 301 deletions(-)
>
> --
> 2.14.3
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
we had a
> write() done in the same fd. Any suggestions?
>
>
>
> ps: it is worth mentioning that I was able to reproduce this same bug in a
> POWER8 system running Ubuntu 18.04. Given that the code we're dealing with
> doesn't have any arch-specific behavior I wouldn't be surprised if this bug
> is also reproducible in other archs like x86.
>
>
> Thanks,
>
> Daniel
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1561017
> [2] https://github.com/open-power/HTX
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
'monitor: add asynchronous command type' tries to do?
(See 20180326150916.9602-1-marcandre.lur...@redhat.com 26th March)
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
oses. They use a completely different format (VMX)
> which is a lot like YAML.
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> http://fedoraproject.org/wiki/MinGW
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
snapshot.
It's also easy for the person packaging them.
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Eduardo Habkost (ehabk...@redhat.com) wrote:
> On Tue, May 29, 2018 at 03:03:16PM +0100, Dr. David Alan Gilbert wrote:
> > * Richard W.M. Jones (rjo...@redhat.com) wrote:
> > > On Fri, May 18, 2018 at 06:09:56PM +0100, Daniel P. Berrangé wrote:
> > > > The closest
* Marc-André Lureau (marcandre.lur...@redhat.com) wrote:
> Hi
>
> On Tue, May 22, 2018 at 1:01 PM, Kevin Wolf wrote:
> > Am 18.05.2018 um 20:41 hat Dr. David Alan Gilbert geschrieben:
> >> * Kevin Wolf (kw...@redhat.com) wrote:
> >> > Before we can make x-
ys are sorted, but
that's a pain to do in some json creators)
c) Forcing the registry of keys might avoid silly duplication.
We can but hope.
d) I've not said it's a libvirt XML file since that seems
a bit prescriptive.
Some initial suggested keys:
"qemu.machine-types": [ "q35", "i440fx" ]
"qemu.min-ram-MB": 1024
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
the encoding in the value?
>
> string value:
> [A-Za-z][^=\0]=S[^\0]*
>
> base64 value:
> [A-Za-z][^=\0]=B[A-Za-z0-9+/]*
>
> or the key:
> S[A-Za-z][^=\0]=[^\0]*
>
> base64 value:
> B[A-Za-z][^=\0]=[A-Za-z0-9+/]*
Why reinvent the wheel yet again?
The
* Eduardo Habkost (ehabk...@redhat.com) wrote:
> On Tue, Jun 05, 2018 at 10:21:59AM +0100, Dr. David Alan Gilbert wrote:
> >
> >
> > This seems to have fizzled out because of a lack of a concrete proposal;
> > so here is one based on a reply to Max's post:
> &g
* Max Reitz (mre...@redhat.com) wrote:
> On 2018-06-05 11:21, Dr. David Alan Gilbert wrote:
> >
> >
> > This seems to have fizzled out because of a lack of a concrete proposal;
> > so here is one based on a reply to Max's post:
> >
>
ave in qcow2 that is opaque is the VM state
> that can be stored in snapshots (and don't hold me responsible for that).
>
> >> Secondly, that completely depends on how you use it. You can freely
> >> expand the last file in the archive, for instance. Also I've seen
> >> people store files in chunks so they can indeed resize it.
> >>
> >> (I'm wondering if we could write a block driver that could provide
> >> such a chunk allocation transparently to qcow2... Note that a qcow2
> >> file does not need to be continuous, so you could in theory indeed
> >> store the qcow2 file and its data in completely separate places in a
> >> tar file.)
> >
> > Which basically invents another new filesystem on top of tar for no
> > good reason. Especially when we have already support for storage format
> > that is capable enough.
>
> No different from inventing a filesystem on top of qcow2.
>
> I don't think qcow2 is any more capable than tar.
>
> >> What I'm trying to get at is that qcow2 was not designed to be a
> >> container format for arbitrary files. If you want to make it such,
> >> I'm sure there are existing formats that work better.
> >
> > Such as?
>
> ext2?
>
> It seems to me that you want to make qcow2 a filesystem. Sure, the FS
> we'd end up with would probably be simpler than ext2, but I assume
> thanks to feature creep we'd eventually end up with a qcow2 format that
> is a worse FS than real FS (especially performance-wise), but that is
> similarly complex.
>
> >>>> Unless I have got something terribly wrong (which is indeed a
> >>>> possibility!), to me this proposal means basically to turn qcow2
> >>>> into (1) a VM description format for qemu, and (2) to turn it into
> >>>> an archive format on the way.
> >>>
> >>> And if you go all the way you can store multiple disks along with
> >>> the VM definition so you can have the whole appliance in one file.
> >>> It conveniently solves the problem of synchronizing snapshots across
> >>> multiple disk images and the question where to store the machine
> >>> state if you want to suspend it.
> >>
> >> Yeah, but why make qcow2 that format? That's what I completely fail
> >> to understand.
> >>
> >> If you want to have a single VM description file that contains the VM
> >> configuration and some qcow2/raw/whatever files along with it for the
> >> guest disk data, sure, go ahead. But why does the format of the whole
> >> thing need to be qcow2?
> >
> > Because then qemu can access the disk data from the image directly
> > without any need for extraction, copying to different file, etc.
>
> This does not explain why it needs to be qcow2. There is absolutely no
> reason why you couldn't use qcow2 files in-place inside of another file.
Because then we'd have to change the whole stack to take advantage of
that. Adding a feature into qcow2 means nothing else changes.
Dave
> Max
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Max Reitz (mre...@redhat.com) wrote:
> On 2018-06-06 13:14, Dr. David Alan Gilbert wrote:
> > * Max Reitz (mre...@redhat.com) wrote:
> >> On 2018-06-05 11:21, Dr. David Alan Gilbert wrote:
> >>>
> >>>
> >>> This seems to have fizzled out b
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Wed, Jun 06, 2018 at 12:42:28PM +0100, Richard W.M. Jones wrote:
> > On Wed, Jun 06, 2018 at 12:14:07PM +0100, Dr. David Alan Gilbert wrote:
> > > The problem with having a separate file is that you either have to copy
> &
* Max Reitz (mre...@redhat.com) wrote:
> On 2018-06-06 13:37, Dr. David Alan Gilbert wrote:
> > * Max Reitz (mre...@redhat.com) wrote:
> >> On 2018-06-06 13:19, Michal Suchánek wrote:
> >>> On Wed, 6 Jun 2018 13:02:53 +0200
> >>> Max Reitz wrote:
> &g
* Max Reitz (mre...@redhat.com) wrote:
> On 2018-06-06 14:16, Dr. David Alan Gilbert wrote:
> > * Max Reitz (mre...@redhat.com) wrote:
> >> On 2018-06-06 13:37, Dr. David Alan Gilbert wrote:
> >>> * Max Reitz (mre...@redhat.com) wrote:
> >>>> On 2018-0
* Max Reitz (mre...@redhat.com) wrote:
> On 2018-06-06 14:00, Dr. David Alan Gilbert wrote:
> > * Max Reitz (mre...@redhat.com) wrote:
> >> On 2018-06-06 13:14, Dr. David Alan Gilbert wrote:
> >>> * Max Reitz (mre...@redhat.com) wrote:
> >>>> On 2
* Max Reitz (mre...@redhat.com) wrote:
> On 2018-06-06 16:02, Dr. David Alan Gilbert wrote:
> > * Max Reitz (mre...@redhat.com) wrote:
> >> On 2018-06-06 14:16, Dr. David Alan Gilbert wrote:
> >>> * Max Reitz (mre...@redhat.com) wrote:
> >>>> On 2
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Wed, Jun 06, 2018 at 03:31:35PM +0100, Dr. David Alan Gilbert wrote:
> > > Not in this case because it'd still be a flat qcow2 file in a simple tar
> > > archive.
> > >
> > > But you're r
* Max Reitz (mre...@redhat.com) wrote:
> On 2018-06-06 16:31, Dr. David Alan Gilbert wrote:
> > * Max Reitz (mre...@redhat.com) wrote:
> >> On 2018-06-06 14:00, Dr. David Alan Gilbert wrote:
> >>> * Max Reitz (mre...@redhat.com) wrote:
> >>>> On 2
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Wed, Jun 06, 2018 at 10:36:20AM -0500, Eric Blake wrote:
> > On 06/06/2018 10:05 AM, Dr. David Alan Gilbert wrote:
> >
> > > > If that's the issue, add a UUID to qcow2 files and reference it from the
> &
h bit of the bootloader does this,
> whether it's UEFI itself, or the grub-efi in the guest.
>
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-p2v converts physical machines to virtual machines. Boot with a
> live CD or over the network (PXE) and turn machines into KVM guests.
> http://libguestfs.org/virt-v2v
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
ed on and ... that could be trouble.
Also, if we're going to start including the EFI rom then that would have
to be migrated with the VM so that after a restart on a different host
it's still using the right ROM that's compatible with it's varfile.
Dave
> Regards,
>
* Andrea Bolognani (abolo...@redhat.com) wrote:
> On Thu, 2018-06-07 at 14:49 +0100, Dr. David Alan Gilbert wrote:
> > Including the nvram and efi makes me nervous; but I can see why together
> > they might work. However, there's no guarantee that EFI has been tested
> &g
* Andrea Bolognani (abolo...@redhat.com) wrote:
> On Thu, 2018-06-07 at 15:45 +0100, Dr. David Alan Gilbert wrote:
> > * Andrea Bolognani (abolo...@redhat.com) wrote:
> > > On Thu, 2018-06-07 at 14:49 +0100, Dr. David Alan Gilbert wrote:
> > > > Including the nvram a
sed by a new QEMU (due to a valid QEMU change), even
> when using old machine types. The upstream solution was to fix edk2 and
> stick with QEMU as-was (although the agreement around that hadn't been
> universal). Conversely, one downstream solution was to restrict the
> otherwise v
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Fri, Jun 08, 2018 at 09:21:30AM +0100, Dr. David Alan Gilbert wrote:
> > * Laszlo Ersek (ler...@redhat.com) wrote:
> > > On 06/07/18 12:54, Andrea Bolognani wrote:
> > > > On Thu, 2018-06-07 at 11:36 +
active_iterate = dirty_bitmap_is_active_iterate,
> +.load_state = dirty_bitmap_load,
> + .cleanup = dirty_bitmap_migration_cleanup,
> +.is_active = dirty_bitmap_is_active,
> +};
> +
> +void dirty_bitmap_mig_init(void)
> +{
> +QSIMPLEQ_INIT(&dirty_bitmap_mig_state.dbms_list);
> +
> +register_savevm_live(NULL, "dirty-bitmap", 0, 1,
> + &savevm_dirty_bitmap_handlers,
> + &dirty_bitmap_mig_state);
> +}
> diff --git a/migration/migration.c b/migration/migration.c
> index 179bd04..edf5623 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -122,6 +122,9 @@ MigrationIncomingState
> *migration_incoming_get_current(void)
> QLIST_INIT(&mis_current.loadvm_handlers);
> qemu_mutex_init(&mis_current.rp_mutex);
> qemu_event_init(&mis_current.main_thread_load_event, false);
> +
> +init_dirty_bitmap_incoming_migration();
> +
> once = true;
> }
> return &mis_current;
> diff --git a/migration/savevm.c b/migration/savevm.c
> index 54572ef..927a680 100644
> --- a/migration/savevm.c
> +++ b/migration/savevm.c
> @@ -1651,6 +1651,8 @@ static void loadvm_postcopy_handle_run_bh(void *opaque)
>
> trace_loadvm_postcopy_handle_run_vmstart();
>
> +dirty_bitmap_mig_before_vm_start();
> +
> if (autostart) {
> /* Hold onto your hats, starting the CPU */
> vm_start();
> diff --git a/migration/trace-events b/migration/trace-events
> index 0212929..38fca41 100644
> --- a/migration/trace-events
> +++ b/migration/trace-events
> @@ -222,3 +222,17 @@ colo_vm_state_change(const char *old, const char *new)
> "Change '%s' => '%s'"
> colo_send_message(const char *msg) "Send '%s' message"
> colo_receive_message(const char *msg) "Receive '%s' message"
> colo_failover_set_state(const char *new_state) "new state %s"
> +
> +# migration/block-dirty-bitmap.c
> +send_bitmap_header_enter(void) ""
> +send_bitmap_bits(uint32_t flags, uint64_t start_sector, uint32_t nr_sectors,
> uint64_t data_size) "\n flags:%x\n start_sector: %" PRIu64 "\n
> nr_sectors: %" PRIu32 "\n data_size:%" PRIu64 "\n"
> +dirty_bitmap_save_iterate(int in_postcopy) "in postcopy: %d"
> +dirty_bitmap_save_complete_enter(void) ""
> +dirty_bitmap_save_complete_finish(void) ""
> +dirty_bitmap_save_pending(uint64_t pending, uint64_t max_size) "pending %"
> PRIu64 " max: %" PRIu64
> +dirty_bitmap_load_complete(void) ""
> +dirty_bitmap_load_bits_enter(uint64_t first_sector, uint32_t nr_sectors)
> "chunk: %" PRIu64 " %" PRIu32
> +dirty_bitmap_load_bits_zeroes(void) ""
> +dirty_bitmap_load_header(uint32_t flags) "flags %x"
> +dirty_bitmap_load_enter(void) ""
> +dirty_bitmap_load_success(void) ""
> diff --git a/vl.c b/vl.c
> index b4eaf03..f1ee9ff 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -4405,6 +4405,7 @@ int main(int argc, char **argv, char **envp)
>
> blk_mig_init();
> ram_mig_init();
> +dirty_bitmap_mig_init();
>
> /* If the currently selected machine wishes to override the units-per-bus
> * property of its default HBA interface type, do so now. */
> --
> 1.8.3.1
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
set_speed) will use it after it was freed.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Dr. David Alan Gilbert
> ---
> migration/savevm.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/migration/savevm.c b/migration/savevm.c
> inde
* Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) wrote:
> 24.02.2017 16:26, Dr. David Alan Gilbert wrote:
> > * Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) wrote:
> > > Postcopy migration of dirty bitmaps. Only named dirty bitmaps,
> > > associated w
ld not stay in global migration state
> after
> + * this function finished */
> +ms->to_dst_file = NULL;
> +
> return ret;
> }
>
> --
> 2.11.1
>
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
t; > @@ -322,6 +326,10 @@ void vmstate_save_state(QEMUFile *f, const
> > VMStateDescription *vmsd,
> > int64_t old_offset, written_bytes;
> > QJSON *vmdesc_loop = vmdesc;
> >
> > +if (size == 0) {
> > +field++;
> > +continue;
> > +}
> > trace_vmstate_save_state_loop(vmsd->name, field->name,
> > n_elems);
> > if (field->flags & VMS_POINTER) {
> > first_elem = *(void **)first_elem;
>
> This is really a live migration fix, so I'm adding Juan and Dave to CC.
>
> I suspect the real question is why a field with size 0 was even stored
> in the vmstate to begin with.
Yes; which field is it that's failing?
Dave
> Kevin
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
uan and Dave to CC.
>
> You are right, this is migration stuff and has very little to do with
> qemu-block.
> >
> > I suspect the real question is why a field with size 0 was even stored
> > in the vmstate to begin with.
> >
>
> I have looked onto the issue. It
efinitely valid. I'm only questioning if
> 'savevm' (and by extension, any other command that modifies the VM or
> its images) should automagically regain control of the VM, or whether
> that should be more explicit.
How many things other than 'cont' and 'savevm' are there?
We should definitely fix it so a savevm there doesn't assert,
but I'm also unsure if it's worth a separate explicit command.
Dave
> Kevin
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
ssert_qmp(result, 'return', {})
> +
> +if __name__ == '__main__':
> + iotests.main()
> diff --git a/tests/qemu-iotests/175.out b/tests/qemu-iotests/175.out
> new file mode 100644
> index 00..8d7e996700
> --- /dev/null
> +++ b/tests/qemu-iotests/175.out
> @@ -0,0 +1,5 @@
> +...
> +--
> +Ran 3 tests
> +
> +OK
> diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
> index 985b9a6a36..1f4bf03185 100644
> --- a/tests/qemu-iotests/group
> +++ b/tests/qemu-iotests/group
> @@ -167,3 +167,4 @@
> 172 auto
> 173 rw auto
> 174 auto
> +175 auto quick
> --
> 2.11.1
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
_load_state and vmstate_save_state. And the assert fails.
> With this fix we can go back to the old behavior and support
> VMS_VBUFFER with size 0 and nullptr.
>
> Signed-off-by: QingFeng Hao
> Signed-off-by: Halil Pasic
Thanks, and fixes problem with vmxnet3 migration.
Reviewed-by:
; > +
> > break;
> > }
> > sector += BDRV_SECTORS_PER_DIRTY_CHUNK;
> > --
> > 1.8.3.1
> >
>
> Nice catch above all, thank you!
>
> Reviewed-by: Fam Zheng
Are you taking that via a block pull?
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
)
> > Error *local_err = NULL;
> > AioContext *aio_context;
> >
> > +if (runstate_check(RUN_STATE_FINISH_MIGRATE) ||
> > +runstate_check(RUN_STATE_POSTMIGRATE) ||
> > +runstate_check(RUN_STATE_PRELAUNCH))
> > + {
> > +bdrv_inval
* Kevin Wolf (kw...@redhat.com) wrote:
> Am 28.03.2017 um 12:55 hat Dr. David Alan Gilbert geschrieben:
> > * Kevin Wolf (kw...@redhat.com) wrote:
> > > Am 25.02.2017 um 20:31 hat Vladimir Sementsov-Ogievskiy geschrieben:
> > > > After migration all drives are inac
* Paolo Bonzini (pbonz...@redhat.com) wrote:
>
>
> On 28/03/2017 15:16, Vladimir Sementsov-Ogievskiy wrote:
> > 28.03.2017 15:09, Kevin Wolf wrote:
> >> Am 28.03.2017 um 13:13 hat Dr. David Alan Gilbert geschrieben:
> >>> * Kevin Wolf (kw...@redhat.com) wrot
101 - 200 of 513 matches
Mail list logo
