qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Cho <danielcho@qnap.com>
To: "Zhang, Chen" <chen.zhang@intel.com>
Cc: "lukasstraub2@web.de" <lukasstraub2@web.de>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: Network connection with COLO VM
Date: Mon, 2 Dec 2019 11:55:07 +0800	[thread overview]
Message-ID: <CA+XQNE4N0_K2zQ1NDToJgu+Toy1X3iqOZyYyvtScMMsdVARACg@mail.gmail.com> (raw)
In-Reply-To: <9CFF81C0F6B98A43A459C9EDAD400D780631C682@shsmsx102.ccr.corp.intel.com>

[-- Attachment #1: Type: text/plain, Size: 4776 bytes --]

Hi Zhang,

We use qemu-4.1.0 release on this case.

I think we need use block mirror to sync the disk to secondary node first,
then stop the primary VM and build COLO system.

In the stop moment, you need add some netfilter and chardev socket node for
COLO, maybe you need re-check this part.


Our test was already follow those step. Maybe I could describe the detail
of the test flow and issues.


Step 1:

Create primary VM without any netfilter and chardev for COLO, and using
other host ping primary VM continually.


Step 2:

Create secondary VM (the same device/drive with primary VM), and do block
mirror sync ( ping to primary VM normally )


Step 3:

After block mirror sync finish, add those netfilter and chardev to primary
VM and secondary VM for COLO ( *Can't* ping to primary VM but those packets
will be received later )


Step 4:

Start migrate primary VM to secondary VM, and primary VM & secondary VM are
running ( ping to primary VM works and receive those packets on step 3
status )




Between Step 3 to Step 4, it will take 10~20 seconds in our environment.

I could image this issue (delay reply packets) is because of setting COLO
proxy for temporary status,

but we thought 10~20 seconds might a little long. (If primary VM is already
doing some jobs, it might lose the data.)


Could we reduce those time? or those delay is depends on different VM?


Best Regard,

Daniel Cho.



Zhang, Chen <chen.zhang@intel.com> 於 2019年11月30日 週六 上午2:04寫道:

>
>
>
>
> *From:* Daniel Cho <danielcho@qnap.com>
> *Sent:* Friday, November 29, 2019 10:43 AM
> *To:* Zhang, Chen <chen.zhang@intel.com>
> *Cc:* Dr. David Alan Gilbert <dgilbert@redhat.com>; lukasstraub2@web.de;
> qemu-devel@nongnu.org
> *Subject:* Re: Network connection with COLO VM
>
>
>
> Hi David,  Zhang,
>
>
>
> Thanks for replying my question.
>
> We know why will occur this issue.
>
> As you said, the COLO VM's network needs
>
> colo-proxy to control packets, so the guest's
>
> interface should set the filter to solve the problem.
>
>
>
> But we found another question, when we set the
>
> fault-tolerance feature to guest (primary VM is running,
>
> secondary VM is pausing), the guest's network would not
>
> responds any request for a while (in our environment
>
> about 20~30 secs) after secondary VM runs.
>
>
>
> Does it be a normal situation, or a known issue?
>
>
>
> Our test is creating primary VM for a while, then creating
>
> secondary VM to make it with COLO feature.
>
>
>
> Hi Daniel,
>
>
>
> Happy to hear you have solved ssh disconnection issue.
>
>
>
> Do you use Lukas’s patch on this case?
>
> I think we need use block mirror to sync the disk to secondary node first,
> then stop the primary VM and build COLO system.
>
> In the stop moment, you need add some netfilter and chardev socket node
> for COLO, maybe you need re-check this part.
>
>
>
> Best Regard,
>
> Daniel Cho
>
>
>
> Zhang, Chen <chen.zhang@intel.com> 於 2019年11月28日 週四 上午9:26寫道:
>
>
>
> > -----Original Message-----
> > From: Dr. David Alan Gilbert <dgilbert@redhat.com>
> > Sent: Wednesday, November 27, 2019 6:51 PM
> > To: Daniel Cho <danielcho@qnap.com>; Zhang, Chen
> > <chen.zhang@intel.com>; lukasstraub2@web.de
> > Cc: qemu-devel@nongnu.org
> > Subject: Re: Network connection with COLO VM
> >
> > * Daniel Cho (danielcho@qnap.com) wrote:
> > > Hello everyone,
> > >
> > > Could we ssh to colo VM (means PVM & SVM are starting)?
> > >
> >
> > Lets cc in Zhang Chen and Lukas Straub.
>
> Thanks Dave.
>
> >
> > > SSH will connect to colo VM for a while, but it will disconnect with
> > > error
> > > *client_loop: send disconnect: Broken pipe*
> > >
> > > It seems to colo VM could not keep network session.
> > >
> > > Does it be a known issue?
> >
> > That sounds like the COLO proxy is getting upset; it's supposed to
> compare
> > packets sent by the primary and secondary and only send one to the
> outside
> > - you shouldn't be talking directly to the guest, but always via the
> proxy.  See
> > docs/colo-proxy.txt
> >
>
> Hi Daniel,
>
> I have try ssh to COLO guest with 8 hours, not occurred this issue.
> Please check your network/qemu configuration.
> But I found another problem maybe related this issue, if no network
> communication for a period of time(maybe 10min), the first message send to
> guest have a chance with delay(maybe 1-5 sec), I will try to fix it when I
> have time.
>
> Thanks
> Zhang Chen
>
> > Dave
> >
> > > Best Regard,
> > > Daniel Cho
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
>
>

[-- Attachment #2: Type: text/html, Size: 10091 bytes --]

  reply	other threads:[~2019-12-02  3:56 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-27  4:20 Network connection with COLO VM Daniel Cho
2019-11-27 10:51 ` Dr. David Alan Gilbert
2019-11-28  1:26   ` Zhang, Chen
2019-11-29  2:42     ` Daniel Cho
2019-11-29 18:04       ` Zhang, Chen
2019-12-02  3:55         ` Daniel Cho [this message]
2019-12-02  9:58           ` Dr. David Alan Gilbert
2019-12-03  9:08             ` Daniel Cho
2019-12-03 13:25               ` Dr. David Alan Gilbert
2019-12-04  8:32                 ` Zhang, Chen
2019-12-06  6:31                   ` Daniel Cho

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=CA+XQNE4N0_K2zQ1NDToJgu+Toy1X3iqOZyYyvtScMMsdVARACg@mail.gmail.com \
    --to=danielcho@qnap.com \
    --cc=chen.zhang@intel.com \
    --cc=dgilbert@redhat.com \
    --cc=lukasstraub2@web.de \
    --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).