qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Eric Wheeler <qemu-devel@lists.ewheeler.net>
Cc: qemu-devel@nongnu.org, peterx@redhat.com
Subject: Re: [Qemu-devel] Migration without memory page transfer
Date: Fri, 27 Apr 2018 10:24:14 +0100	[thread overview]
Message-ID: <20180427092413.GA2609@work-vm> (raw)
In-Reply-To: <alpine.LRH.2.11.1804262308190.12327@mail.ewheeler.net>

* Eric Wheeler (qemu-devel@lists.ewheeler.net) wrote:
> Hello all,

Hi Eric,

> This is my first time inside of the qemu code, so your help is greatly 
> appreciated!
> 
> I have been experimenting with stop/start of VMs to/from a migration 
> stream that excludes RAM pages and let the RAM pages come from memory file 
> provided by the memory-backend-file called '/dev/shm/mem'.
> 
> To disable writing of memory pages to the migration stream, I've disabled 
> calls to ram_find_and_save_block in ram_save_iterate() and 
> ram_save_complete() (see patch below).  Thus, the migration stream has the 
> "ram" SaveStateEntry section start/ends, but no pages:

You're in luck, because someone else has just done something very
similar.

> qemu-system-x86_64 \
> 	-object memory-backend-file,prealloc=no,mem-path=/dev/shm/mem,id=ram-node0,host-nodes=0,policy=bind,size=64m,share=on \
> 	-numa node,nodeid=0,cpus=0,memdev=ram-node0\
> 	-m 64 -vnc 0:0
> 
> Once the VM is running, I press ctrl-B to get the IPXE prompt and then 
> run 'kernel http://192.168.0.1/foo' to start a network request and watch 
> it in tcpdump.
> 
> Once the download starts, I save the migration file:
> 	migrate "exec:cat > /dev/shm/t"
> 
> 	# ls -lh /dev/shm/t
> 	-rw-r--r-- 1 root root 321K Apr 26 16:06 /dev/shm/t
> 
> Now I can kill qemu and boot it again with -incoming:
> 
> qemu-system-x86_64 \
> 	-object memory-backend-file,prealloc=no,mem-path=/dev/shm/mem,id=ram-node0,host-nodes=0,policy=bind,size=64m,share=on \
> 	-numa node,nodeid=0,cpus=0,memdev=ram-node0\
> 	-m 64 -vnc 0:0 \
> 	-incoming 'exec:cat /dev/shm/t'
> 
> It seems to work.  That is, network traffic continues (http from IPXE) 
> which I can see from tcpdump.  I can type into the console and it moves 
> the cursor around---but there is nothing on the screen except the blinking 
> text-mode cursor!  I can even blindly start a new transfer in ipxe: kernel 
> http://192.168.0.222/foo2 and see it in tcpdump.
> 
> So what am I missing here?  Is the video memory not saved to /dev/shm/mem?
> 
> Or perhaps it is saved, but VGA isn't initialized to use what is 
> already in /dev/shm/mem?  I've tried the cirrus, std, and vmware drivers 
> to see if they behave differently, but the do not seem to.

They have their own RAMBlocks, not the main RAM, so that does need
migrating.

The patch here:
   http://lists.gnu.org/archive/html/qemu-devel/2018-04/msg00003.html

should do what you want.
You need to turn on the bypass-shared-memory capability.
   migrate_set_capability bypass-shared-memory on

Dave


> Thanks for your help!


> --
> Eric Wheeler
> 
> 
> diff --git a/migration/ram.c b/migration/ram.c
> index 021d583..9f4bfff 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -2267,9 +2267,9 @@ static int ram_save_iterate(QEMUFile *f, void *opaque)
>      t0 = qemu_clock_get_ns(QEMU_CLOCK_REALTIME);
>      i = 0;
>      while ((ret = qemu_file_rate_limit(f)) == 0) {
> -        int pages;
> +        int pages = 0;
>  
> -        pages = ram_find_and_save_block(rs, false);
> +        if (0) pages = ram_find_and_save_block(rs, false);
>          /* no more pages to sent */
>          if (pages == 0) {
>              done = 1;
> @@ -2338,9 +2338,9 @@ static int ram_save_complete(QEMUFile *f, void *opaque)
>  
>      /* flush all remaining blocks regardless of rate limiting */
>      while (true) {
> -        int pages;
> +        int pages = 0;
>  
> -        pages = ram_find_and_save_block(rs, !migration_in_colo_state());
> +        if (0) pages = ram_find_and_save_block(rs, !migration_in_colo_state());
>          /* no more blocks to sent */
>          if (pages == 0) {
>              break;
> 
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

      parent reply	other threads:[~2018-04-27  9:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-26 23:33 [Qemu-devel] Migration without memory page transfer Eric Wheeler
2018-04-27  2:45 ` Peter Xu
2018-05-05 20:30   ` Eric Wheeler
2018-04-27  9:24 ` Dr. David Alan Gilbert [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180427092413.GA2609@work-vm \
    --to=dgilbert@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@lists.ewheeler.net \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).