Thanks for the feedback.
Please provide your thoughts or RFC so that we can start a discussion
to implement this feature.
Meanwhile I will request you to give a try to this patch. I tested the
patch once and found that setting the qemu path in the config is not
as good. We can do it in the same way as we do for a normal VM
creation assuming the kvm-autotest is installed on the remote under
the same directory tree as in the source. I will test it further and
provide my feedback.
On Mon, May 25, 2009 at 3:23 PM, Michael Goldish <mgoldish@xxxxxxxxxx> wrote:
>
> ----- "sudhir kumar" <smalikphy@xxxxxxxxx> wrote:
>
>> Michael,
>> any updates on this patch? Are you going to commit this or you have
>> any other plans/patch ?
>
> Currently we don't have a patch for remote migration other than yogi's.
> We would, however, like to take some time to think about it, because it
> might be a better idea to implement it as two tests ('migration_source'
> and 'migration_dest') that are synchronized by the server. This way we
> won't have to deal with remote VM objects in the framework.
>
> If the server idea turns out to be infeasible then yogi's patch looks
> like the way to go (assuming it gets some testing to make sure it doesn't
> break anything).
>
>> On Tue, May 5, 2009 at 1:12 AM, Michael Goldish <mgoldish@xxxxxxxxxx>
>> wrote:
>> > Thanks for the new patch. I'll comment on it later because I want to
>> take some more time to review it.
>> >
>> > The login prompt problem is my fault -- please see my comment
>> below.
>> >
>> > ----- "yogi" <anantyog@xxxxxxxxxxxxxxxxxx> wrote:
>> >
>> >> Hello everyone,
>> >>
>> >> I like to resubmit patch to add support for "remote migration" in
>> >> kvm-autotest, based on Michael Goldish's suggestions.
>> >>
>> >> To use this patch the following seven parameters should be added
>> to
>> >> the
>> >> existing migration test
>> >>
>> >> remote_dst = yes
>> >> hostip = <localhost ip or name>
>> >> remoteip = <remote host ip or name>
>> >> remuser = root
>> >> rempassword = <password>
>> >> qemu_path_dst = <qemu binary path on remote host>
>> >> image_dir_dst = <images dir on remote host>
>> >>
>> >>
>> >> For example:
>> >> - migrate: install setup
>> >> type = migration
>> >> vms += " dst"
>> >> migration_test_command = help
>> >> kill_vm_on_error = yes
>> >> hostip = 192.168.1.2
>> >> remoteip = 192.168.1.3
>> >> remuser = root
>> >> rempassword = 123456
>> >> remote_dst = yes
>> >> qemu_path_dst = /tmp/kvm_autotest_root/qemu
>> >> image_dir_dst = /tmp/kvm_autotest_root/images
>> >>
>> >> variants:
>> >>
>> >> The parameter "remote_dst = yes", indicates that the VM "dst"
>> should
>> >> be
>> >> started on the remote host.If the parameter qemu_path_dst and
>> >> image_dir_dst, it is assumed tht the qemu binary images path is
>> same
>> >> on
>> >> both local and remote host.
>> >>
>> >> > Regarding remote_login:
>> >> >
>> >> > - Why should remote_login return a session when it gets an
>> >> unexpected login prompt? If you get a login prompt doesn't that
>> mean
>> >> something went wrong? The username is always provided in the ssh
>> >> command line, so we shouldn't expect to receive a login prompt --
>> or
>> >> am I missing something? I am pretty confident this is true in the
>> >> general case, but maybe it's different when ssh keys have been
>> >> exchanged between the hosts.
>> >> >
>> >> > - I think it makes little sense to return a session object when
>> you
>> >> see a login prompt because that session will be useless. You can't
>> >> send any commands to it because you don't have a shell prompt yet.
>> Any
>> >> command you send will be interpreted as a username, and will most
>> >> likely be the wrong username.
>> >> >
>> >> > - When a guest is in the process of booting and we try to log
>> into
>> >> it, remote_login sometimes fails because it gets an unexpected
>> login
>> >> prompt. This is good, as far as I understand, because it means the
>> >> guest isn't ready yet (still booting). The next time remote_login
>> >> attempts to log in, it usually succeeds. If we consider an
>> unexpected
>> >> login prompt OK, we pass login attempts that actually should have
>> >> failed (and the resulting sessions will be useless anyway).
>> >> >
>> >> I have removed this from the current patch, so now the
>> remote_login
>> >> function is unchanged.I will recheck my machine configuration and
>> >> submit
>> >> it as new patch if necessary. I had exchanged ssh keys between the
>> >> hosts(both local and remote hosts), but the login sessions seem to
>> >> terminates with "Got unexpected login prompt".
>> >
>> > It seems the problem is caused by a "loose" regular expression in
>> kvm_utils.remote_login().
>> > In the list of parameters to read_until_last_line_matches, you'll
>> find something like "[Ll]ogin:".
>> > I put it there to match the telnet login prompt which indicates
>> failure, but it also matches the
>> > "Last login: Mon May 4 ... from ..." line, which appears when SSH
>> login succeeds.
>> > This regex should be made stricter, e.g. r"^[Ll]ogin:\s*$", which
>> means it must appear at the beginning
>> > of the line, and must be followed by nothing other than whitespace
>> characters.
>> >
>> > I'll commit a fix, which will also make the other regex's stricter
>> as well, but it won't appear in the
>> > public repository until Uri comes back from vacation.
>> >
>> > Thanks,
>> > Michael
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe kvm" in
>> > the body of a message to majordomo@xxxxxxxxxxxxxxx
>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>> >
>>
>>
>>
>> --
>> Sudhir Kumar
>
--
Sudhir Kumar
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
