All of lore.kernel.org
 help / color / mirror / Atom feed
* [KVM-AUTOTEST] [PATCH] support for remote migration
@ 2009-04-30 11:56 yogi
  2009-04-30 13:55 ` David Huff
  0 siblings, 1 reply; 10+ messages in thread
From: yogi @ 2009-04-30 11:56 UTC (permalink / raw)
  To: Uri Lublin, kvm

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

Hello everyone,

I like to submit patch to add support for "remote migration" in
kvm-autotest.

To use this patch the following four parameters should be added to the
existing migration test

        remote = dst
        hostip = <localhost ip or name>
        remoteip = <remote host ip or name>
        remuser = root
        rempassword = <password>

the field remote=dst indicates the VM "dst" should be created on remote
machine.
For example:
    - migrate:      install setup
        type = migration
        vms += " dst"
        migration_test_command = help
        kill_vm_on_error = yes
        remote = dst
        hostip = 192.168.1.2
        remoteip = 192.168.1.3
        remuser = root
        rempassword = 123456
        variants:

Three files r being modified in this patch kvm_utils.py, kvm_tests.py
and kvm_vm.py.
kvm_utils.py - if the  ssh-keys have been exchanged between the test
machines,then remote login fails with message "Got unexpected login
prompt", to prevent this, have made it return a session rather then None

kvm_tests.py - the host address used in migration is made dynamic

kvm_vm.py -    have replaced unix sockets with tcp sockets for monitor,
in both remote and local VM. Added two new variables(remote,ssh_port) to
class VM,remote set to True if the VM is on a  remote machine,ssh_port
contains the redirection port, funtion get_address() returns the ip of
the host whr the VM is(local or remote).

Thx
Yogi


[-- Attachment #2: remotemigration.patch --]
[-- Type: text/x-patch, Size: 8309 bytes --]

 kvm_tests.py |    2 -
 kvm_utils.py |    3 --
 kvm_vm.py    |   61 ++++++++++++++++++++++++++++++++++++++++++++---------------
 3 files changed, 48 insertions(+), 18 deletions(-)

Signed-off-by: Yogananth Subramanian <anantyog@in.ibm.com>
---
diff -aurp kvm-autotest.orgi//client/tests/kvm_runtest_2/kvm_tests.py kvm-autotest/client/tests/kvm_runtest_2/kvm_tests.py
--- kvm-autotest.orgi//client/tests/kvm_runtest_2/kvm_tests.py	2009-04-29 18:33:10.000000000 +0000
+++ kvm-autotest/client/tests/kvm_runtest_2/kvm_tests.py	2009-04-30 05:59:24.000000000 +0000
@@ -81,7 +81,7 @@ def run_migration(test, params, env):
     session.close()
 
     # Define the migration command
-    cmd = "migrate -d tcp:localhost:%d" % dest_vm.migration_port
+    cmd = "migrate -d tcp:%s:%d" % (dest_vm.hostip,dest_vm.migration_port)
     kvm_log.debug("Migration command: %s" % cmd)
 
     # Migrate
diff -aurp kvm-autotest.orgi//client/tests/kvm_runtest_2/kvm_utils.py kvm-autotest/client/tests/kvm_runtest_2/kvm_utils.py
--- kvm-autotest.orgi//client/tests/kvm_runtest_2/kvm_utils.py	2009-04-29 18:33:10.000000000 +0000
+++ kvm-autotest/client/tests/kvm_runtest_2/kvm_utils.py	2009-04-30 06:13:47.000000000 +0000
@@ -431,8 +431,7 @@ def remote_login(command, password, prom
                 return None
         elif match == 2:  # "login:"
             kvm_log.debug("Got unexpected login prompt")
-            sub.close()
-            return None
+            return sub
         elif match == 3:  # "Connection closed"
             kvm_log.debug("Got 'Connection closed'")
             sub.close()
diff -aurp kvm-autotest.orgi//client/tests/kvm_runtest_2/kvm_vm.py kvm-autotest/client/tests/kvm_runtest_2/kvm_vm.py
--- kvm-autotest.orgi//client/tests/kvm_runtest_2/kvm_vm.py	2009-04-29 18:33:10.000000000 +0000
+++ kvm-autotest/client/tests/kvm_runtest_2/kvm_vm.py	2009-04-30 06:31:34.000000000 +0000
@@ -3,6 +3,7 @@
 import time
 import socket
 import os
+import re
 
 import kvm_utils
 import kvm_log
@@ -105,6 +106,7 @@ class VM:
         self.qemu_path = qemu_path
         self.image_dir = image_dir
         self.iso_dir = iso_dir
+        self.remote = False
 
     def verify_process_identity(self):
         """Make sure .pid really points to the original qemu process.
@@ -124,8 +126,6 @@ class VM:
         file.close()
         if not self.qemu_path in cmdline:
             return False
-        if not self.monitor_file_name in cmdline:
-            return False
         return True
 
     def make_qemu_command(self, name=None, params=None, qemu_path=None, image_dir=None, iso_dir=None):
@@ -173,7 +173,6 @@ class VM:
 
         qemu_cmd = qemu_path
         qemu_cmd += " -name '%s'" % name
-        qemu_cmd += " -monitor unix:%s,server,nowait" % self.monitor_file_name
 
         for image_name in kvm_utils.get_sub_dict_names(params, "images"):
             image_params = kvm_utils.get_sub_dict(params, image_name)
@@ -211,6 +210,7 @@ class VM:
             redir_params = kvm_utils.get_sub_dict(params, redir_name)
             guest_port = int(redir_params.get("guest_port"))
             host_port = self.get_port(guest_port)
+            self.ssh_port = host_port
             qemu_cmd += " -redir tcp:%s::%s" % (host_port, guest_port)
 
         if params.get("display") == "vnc":
@@ -254,6 +254,17 @@ class VM:
         image_dir = self.image_dir
         iso_dir = self.iso_dir
 
+        # If VM is remote, set hostip to ip of the remote machine
+        # If VM is local set hostip to localhost or hostip param
+        if params.get("remote") == self.name:
+            self.remote = True
+            self.hostip = params.get("remoteip")
+        else:
+            self.remote = False
+            self.hostip = params.get("hostip","localhost")
+
+
+
         # Verify the md5sum of the ISO image
         iso = params.get("cdrom")
         if iso:
@@ -310,8 +321,28 @@ class VM:
             # Add -incoming option to the qemu command
             qemu_command += " -incoming tcp:0:%d" % self.migration_port
 
-        kvm_log.debug("Running qemu command:\n%s" % qemu_command)
-        (status, pid, output) = kvm_utils.run_bg(qemu_command, None, kvm_log.debug, "(qemu) ")
+        self.monitor_port = kvm_utils.find_free_port(5400, 6000)
+        qemu_command +=" -monitor tcp:0:%d,server,nowait" % self.monitor_port
+        
+        # If the VM is remote, get the username and password of remote host and lanch qemu
+        # command on the remote machine.
+        if self.remote:
+            remuser = params.get("remuser")
+            rempassword = params.get("rempassword")
+            sub = kvm_utils.ssh(self.hostip,22,remuser,rempassword,self.params.get("ssh_prompt", "[\#\$]"))
+            qemu_command +=" &"
+            kvm_log.debug("Running qemu command:\n%s" % qemu_command)
+            sub.sendline(qemu_command)
+
+            (status,output) = sub.read_up_to_prompt()
+            if "Exit " in output:
+                status = int(re.findall("Exit\s(\d+)",output)[0])
+            else:
+                pid = int(re.findall(".*] (\d+)",output)[0])
+                status = 0
+        else:
+            kvm_log.debug("Running qemu command:\n%s" % qemu_command)
+            (status, pid, output) = kvm_utils.run_bg(qemu_command, None, kvm_log.debug, "(qemu) ")
 
         if status:
             kvm_log.debug("qemu exited with status %d" % status)
@@ -363,9 +394,8 @@ class VM:
         # Connect to monitor
         kvm_log.debug("Sending monitor command: %s" % command)
         try:
-            s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
-            s.setblocking(False)
-            s.connect(self.monitor_file_name)
+            s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
+            s.connect((self.hostip,self.monitor_port))
         except:
             kvm_log.debug("Could not connect to monitor socket")
             return (1, "")
@@ -442,8 +472,9 @@ class VM:
     def is_alive(self):
         """Return True iff the VM's monitor is responsive."""
         # Check if the process exists
-        if not kvm_utils.pid_exists(self.pid):
-            return False
+        if not self.remote:
+            if not kvm_utils.pid_exists(self.pid):
+                return False
         # Try sending a monitor command
         (status, output) = self.send_monitor_cmd("help")
         if status:
@@ -468,7 +499,7 @@ class VM:
         address of its own).  Otherwise return the guest's IP address.
         """
         # Currently redirection is always used, so return 'localhost'
-        return "localhost"
+        return self.hostip
 
     def get_port(self, port):
         """Return the port in host space corresponding to port in guest space.
@@ -486,7 +517,7 @@ class VM:
     def is_sshd_running(self, timeout=10):
         """Return True iff the guest's SSH port is responsive."""
         address = self.get_address()
-        port = self.get_port(int(self.params.get("ssh_port")))
+        port = self.ssh_port
         if not port:
             return False
         return kvm_utils.is_sshd_running(address, port, timeout=timeout)
@@ -503,7 +534,7 @@ class VM:
         prompt = self.params.get("ssh_prompt", "[\#\$]")
         use_telnet = self.params.get("use_telnet") == "yes"
         address = self.get_address()
-        port = self.get_port(int(self.params.get("ssh_port")))
+        port = self.ssh_port
         if not port:
             return None
 
@@ -520,7 +551,7 @@ class VM:
         username = self.params.get("username", "")
         password = self.params.get("password", "")
         address = self.get_address()
-        port = self.get_port(int(self.params.get("ssh_port")))
+        port = self.ssh_port
         if not port:
             return None
         return kvm_utils.scp_to_remote(address, port, username, password, local_path, remote_path, timeout)
@@ -530,7 +561,7 @@ class VM:
         username = self.params.get("username", "")
         password = self.params.get("password", "")
         address = self.get_address()
-        port = self.get_port(int(self.params.get("ssh_port")))
+        port = self.ssh_port
         if not port:
             return None
         return kvm_utils.scp_from_remote(address, port, username, password, remote_path, local_path, timeout)

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [KVM-AUTOTEST] [PATCH] support for remote migration
  2009-04-30 11:56 [KVM-AUTOTEST] [PATCH] support for remote migration yogi
@ 2009-04-30 13:55 ` David Huff
  0 siblings, 0 replies; 10+ messages in thread
From: David Huff @ 2009-04-30 13:55 UTC (permalink / raw)
  To: yogi; +Cc: Uri Lublin, kvm

yogi wrote:
> Hello everyone,
> 
> I like to submit patch to add support for "remote migration" in
> kvm-autotest.
> 

Thanks for the patch, Uri is out on vacation for a while. I'll apply the 
patch to my test repo and do some validation testing, however may be a 
little while untill it makes it in.

-D

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [KVM-AUTOTEST] [PATCH] support for remote migration
  2009-05-27 14:27     ` Uri Lublin
@ 2009-05-27 16:50       ` sudhir kumar
  0 siblings, 0 replies; 10+ messages in thread
From: sudhir kumar @ 2009-05-27 16:50 UTC (permalink / raw)
  To: Uri Lublin; +Cc: Michael Goldish, yogi, kvm

On Wed, May 27, 2009 at 7:57 PM, Uri Lublin <uril@redhat.com> wrote:
> sudhir kumar wrote:
>>
>> Michael,
>> any updates on this patch? Are you going to commit this or you have
>> any other plans/patch ?
>>
>
> I'm not sure having the inter-host migration is best implemented on the
> autotest-client side. Actually this is one of the few tests I think belong
> to the autotest-server side.
This one was a minimal and the first point implementation. I am not
much expert in the server side. I will look into the code and design
of the server.
>
> On the other hand it is pretty simple to implement it here. So I think we'd
> better try first implementing it as a server test, and apply it to the
> client side only as a second choice.
>
> A few (minor) problems with it running on the client side:
> 1. We do not know what the other host is running (what version?, kvm-modules
> loaded? etc.)
> 2. There may be a conflict between a running local guest running on the
> remote (if it allowed to run tests while being a migration destination), and
> the remote guest.
Yes, especially in case of parallel job execution. This is imp to be handeled.
> 3. There may be a conflict between two remote guests running a migration
> test on two different hosts.
So you mean the server will enquire about this event if implemented
using autotest server?
> 3. get_free_ports run on the local machine, but expected/assumed to be free
> on the remote machine too.
> 4. For a migration to be successful, the image(s) must be shared by both
> hosts. On the other hand, when installing a guest OS (e.g. Fedora 8) on both
> hosts (let's assume they both are running fc8_quick) we want different
> images on different hosts.
This may be true only when the autoserver is running multiple parallel
jobs. Though less likely that one would like to run 2 instances of
same installation. However still this is a case.

>
> These are all can be solved easily by non-trivial pretty simple
> configuration on the server. One can configure the "remote" migration to run
> as a separate tests to all other tests.
>
I feel Virtmanager also will be taking care of such scenarios. Any
idea how do they handle it or they  just leave it to the user?
>
> Regards,
>    Uri.
>
>
>
Thanks for your comments.



-- 
Sudhir Kumar

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [KVM-AUTOTEST] [PATCH] support for remote migration
  2009-05-25  6:40   ` sudhir kumar
@ 2009-05-27 14:27     ` Uri Lublin
  2009-05-27 16:50       ` sudhir kumar
  0 siblings, 1 reply; 10+ messages in thread
From: Uri Lublin @ 2009-05-27 14:27 UTC (permalink / raw)
  To: sudhir kumar; +Cc: Michael Goldish, yogi, kvm

sudhir kumar wrote:
> Michael,
> any updates on this patch? Are you going to commit this or you have
> any other plans/patch ?
> 

I'm not sure having the inter-host migration is best implemented on the 
autotest-client side. Actually this is one of the few tests I think belong to 
the autotest-server side.

On the other hand it is pretty simple to implement it here. So I think we'd 
better try first implementing it as a server test, and apply it to the client 
side only as a second choice.

A few (minor) problems with it running on the client side:
1. We do not know what the other host is running (what version?, kvm-modules 
loaded? etc.)
2. There may be a conflict between a running local guest running on the remote 
(if it allowed to run tests while being a migration destination), and the remote 
guest.
3. There may be a conflict between two remote guests running a migration test on 
two different hosts.
3. get_free_ports run on the local machine, but expected/assumed to be free on 
the remote machine too.
4. For a migration to be successful, the image(s) must be shared by both hosts. 
On the other hand, when installing a guest OS (e.g. Fedora 8) on both hosts 
(let's assume they both are running fc8_quick) we want different images on 
different hosts.

These are all can be solved easily by non-trivial pretty simple configuration on 
the server. One can configure the "remote" migration to run as a separate tests 
to all other tests.


Regards,
     Uri.



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [KVM-AUTOTEST] [PATCH] support for remote migration
  2009-05-25  9:53 ` Michael Goldish
@ 2009-05-26  5:18   ` sudhir kumar
  0 siblings, 0 replies; 10+ messages in thread
From: sudhir kumar @ 2009-05-26  5:18 UTC (permalink / raw)
  To: Michael Goldish; +Cc: yogi, Uri Lublin, kvm

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@redhat.com> wrote:
>
> ----- "sudhir kumar" <smalikphy@gmail.com> 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@redhat.com>
>> 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@linux.vnet.ibm.com> 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@vger.kernel.org
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >
>>
>>
>>
>> --
>> Sudhir Kumar
>



-- 
Sudhir Kumar

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [KVM-AUTOTEST] [PATCH] support for remote migration
       [not found] <1818401549.327921243244441830.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
@ 2009-05-25  9:53 ` Michael Goldish
  2009-05-26  5:18   ` sudhir kumar
  0 siblings, 1 reply; 10+ messages in thread
From: Michael Goldish @ 2009-05-25  9:53 UTC (permalink / raw)
  To: sudhir kumar; +Cc: yogi, Uri Lublin, kvm


----- "sudhir kumar" <smalikphy@gmail.com> 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@redhat.com>
> 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@linux.vnet.ibm.com> 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@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> 
> 
> 
> -- 
> Sudhir Kumar

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [KVM-AUTOTEST] [PATCH] support for remote migration
  2009-05-04 19:42 ` Michael Goldish
@ 2009-05-25  6:40   ` sudhir kumar
  2009-05-27 14:27     ` Uri Lublin
  0 siblings, 1 reply; 10+ messages in thread
From: sudhir kumar @ 2009-05-25  6:40 UTC (permalink / raw)
  To: Michael Goldish; +Cc: yogi, Uri Lublin, kvm

Michael,
any updates on this patch? Are you going to commit this or you have
any other plans/patch ?

On Tue, May 5, 2009 at 1:12 AM, Michael Goldish <mgoldish@redhat.com> 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@linux.vnet.ibm.com> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Sudhir Kumar

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [KVM-AUTOTEST] [PATCH] support for remote migration
       [not found] <796594249.90621241466107981.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
@ 2009-05-04 19:42 ` Michael Goldish
  2009-05-25  6:40   ` sudhir kumar
  0 siblings, 1 reply; 10+ messages in thread
From: Michael Goldish @ 2009-05-04 19:42 UTC (permalink / raw)
  To: yogi; +Cc: Uri Lublin, kvm

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@linux.vnet.ibm.com> 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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [KVM-AUTOTEST] [PATCH] support for remote migration
  2009-04-30 14:10 ` Michael Goldish
@ 2009-05-04 14:15   ` yogi
  0 siblings, 0 replies; 10+ messages in thread
From: yogi @ 2009-05-04 14:15 UTC (permalink / raw)
  To: Michael Goldish; +Cc: Uri Lublin, kvm

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

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".  
> Other things:
> 
> - If I understand correctly, remote migration will only work if the remote qemu binary path is exactly the same as the local one. Maybe we should receive a qemu path parameter that will allow for some flexibility.
update the patch with this option by providing 2 new parameters
qemu_path_dst and image_dir_dst

> - In VM.make_qemu_command(), in the code that handles redirections, you add 'self.ssh_port = host_port'. I don't think this is correct because there can be multiple redirections, unrelated to SSH, so you certainly shouldn't assume that the only redirection is an SSH one. When you want the host port redirected to the guest's SSH port, you should use self.get_port(int(self.params.get("ssh_port"))). This will also work if for some reason 'ssh_port' changes while the guest is alive.

yes,should not have done that. So also  removed it from this patch
> - It seems that the purpose of 'remote = dst' is to indicate to 'dst' that it should be started as a remote VM. The preferred way to do this is to pass something like 'remote_dst = yes' and then in VM.create() you can test for params.get("remote") == "yes". See "Addressing objects" in the wiki (http://www.linux-kvm.org/page/KVM-Autotest/Parameters#Addressing_objects_.28VMs.2C_images.2C_NICs_etc.29).
> In general, any parameter you want to pass to a specific VM, you pass using <param>_<vmname> = <value>, e.g. 'mem_dst = 128', and then in VM.create() the parameter is accessible without the VM name extension (e.g. self.params.get("mem") will equal "128").
updated the patch with the above suggestion

Thank you,for your suggestion Michael, they were very helpful(srry i
took so long to reply,was traveling,so was not able to reply and
resubmit the patch).

Thx
yogi


[-- Attachment #2: remotemigration.patch --]
[-- Type: text/x-patch, Size: 5841 bytes --]

 kvm_tests.py |    2 +-
 kvm_vm.py    |   54 +++++++++++++++++++++++++++++++++++++++++++-----------
 2 files changed, 44 insertions(+), 12 deletions(-)


Signed-off-by: Yogananth Subramanian <anantyog@in.ibm.com>
---
diff -aurp kvm-autotest.orgi/client/tests/kvm_runtest_2//kvm_tests.py kvm-autotest/client/tests/kvm_runtest_2//kvm_tests.py
--- kvm-autotest.orgi/client/tests/kvm_runtest_2//kvm_tests.py	2009-04-29 18:33:10.000000000 +0000
+++ kvm-autotest/client/tests/kvm_runtest_2//kvm_tests.py	2009-04-30 05:59:24.000000000 +0000
@@ -81,7 +81,7 @@ def run_migration(test, params, env):
     session.close()
 
     # Define the migration command
-    cmd = "migrate -d tcp:localhost:%d" % dest_vm.migration_port
+    cmd = "migrate -d tcp:%s:%d" % (dest_vm.hostip,dest_vm.migration_port)
     kvm_log.debug("Migration command: %s" % cmd)
 
     # Migrate
diff -aurp kvm-autotest.orgi/client/tests/kvm_runtest_2//kvm_vm.py kvm-autotest/client/tests/kvm_runtest_2//kvm_vm.py
--- kvm-autotest.orgi/client/tests/kvm_runtest_2//kvm_vm.py	2009-04-29 18:33:10.000000000 +0000
+++ kvm-autotest/client/tests/kvm_runtest_2//kvm_vm.py	2009-05-04 09:06:32.000000000 +0000
@@ -3,6 +3,7 @@
 import time
 import socket
 import os
+import re
 
 import kvm_utils
 import kvm_log
@@ -105,6 +106,7 @@ class VM:
         self.qemu_path = qemu_path
         self.image_dir = image_dir
         self.iso_dir = iso_dir
+        self.remote = False
 
     def verify_process_identity(self):
         """Make sure .pid really points to the original qemu process.
@@ -124,8 +126,6 @@ class VM:
         file.close()
         if not self.qemu_path in cmdline:
             return False
-        if not self.monitor_file_name in cmdline:
-            return False
         return True
 
     def make_qemu_command(self, name=None, params=None, qemu_path=None, image_dir=None, iso_dir=None):
@@ -173,7 +173,6 @@ class VM:
 
         qemu_cmd = qemu_path
         qemu_cmd += " -name '%s'" % name
-        qemu_cmd += " -monitor unix:%s,server,nowait" % self.monitor_file_name
 
         for image_name in kvm_utils.get_sub_dict_names(params, "images"):
             image_params = kvm_utils.get_sub_dict(params, image_name)
@@ -254,6 +253,19 @@ class VM:
         image_dir = self.image_dir
         iso_dir = self.iso_dir
 
+        # If VM is remote, set hostip to ip of the remote machine
+        # If VM is local set hostip to localhost or hostip param
+        if params.get("remote") == "yes":
+            self.remote = True
+            self.hostip = params.get("remoteip")
+            self.qemu_path = params.get("qemu_path",qemu_path)
+            qemu_path = self.qemu_path
+            self.image_dir = params.get("image_dir",image_dir)
+            image_dir = self.image_dir
+        else:
+            self.remote = False
+            self.hostip = params.get("hostip","localhost")
+
         # Verify the md5sum of the ISO image
         iso = params.get("cdrom")
         if iso:
@@ -310,8 +322,28 @@ class VM:
             # Add -incoming option to the qemu command
             qemu_command += " -incoming tcp:0:%d" % self.migration_port
 
-        kvm_log.debug("Running qemu command:\n%s" % qemu_command)
-        (status, pid, output) = kvm_utils.run_bg(qemu_command, None, kvm_log.debug, "(qemu) ")
+        self.monitor_port = kvm_utils.find_free_port(5400, 6000)
+        qemu_command +=" -monitor tcp:0:%d,server,nowait" % self.monitor_port
+        
+        # If the VM is remote, get the username and password of remote host and lanch qemu
+        # command on the remote machine.
+        if self.remote:
+            remuser = params.get("remuser")
+            rempassword = params.get("rempassword")
+            sub = kvm_utils.ssh(self.hostip,22,remuser,rempassword,self.params.get("ssh_prompt", "[\#\$]"))
+            qemu_command +=" &"
+            kvm_log.debug("Running qemu command:\n%s" % qemu_command)
+            sub.sendline(qemu_command)
+
+            (status,output) = sub.read_up_to_prompt()
+            if "Exit " in output:
+                status = int(re.findall("Exit\s(\d+)",output)[0])
+            else:
+                pid = int(re.findall(".*] (\d+)",output)[0])
+                status = 0
+        else:
+            kvm_log.debug("Running qemu command:\n%s" % qemu_command)
+            (status, pid, output) = kvm_utils.run_bg(qemu_command, None, kvm_log.debug, "(qemu) ")
 
         if status:
             kvm_log.debug("qemu exited with status %d" % status)
@@ -363,9 +395,8 @@ class VM:
         # Connect to monitor
         kvm_log.debug("Sending monitor command: %s" % command)
         try:
-            s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
-            s.setblocking(False)
-            s.connect(self.monitor_file_name)
+            s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
+            s.connect((self.hostip,self.monitor_port))
         except:
             kvm_log.debug("Could not connect to monitor socket")
             return (1, "")
@@ -442,8 +473,9 @@ class VM:
     def is_alive(self):
         """Return True iff the VM's monitor is responsive."""
         # Check if the process exists
-        if not kvm_utils.pid_exists(self.pid):
-            return False
+        if not self.remote:
+            if not kvm_utils.pid_exists(self.pid):
+                return False
         # Try sending a monitor command
         (status, output) = self.send_monitor_cmd("help")
         if status:
@@ -468,7 +500,7 @@ class VM:
         address of its own).  Otherwise return the guest's IP address.
         """
         # Currently redirection is always used, so return 'localhost'
-        return "localhost"
+        return self.hostip
 
     def get_port(self, port):
         """Return the port in host space corresponding to port in guest space.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [KVM-AUTOTEST] [PATCH] support for remote migration
       [not found] <1708099165.481031241100420772.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
@ 2009-04-30 14:10 ` Michael Goldish
  2009-05-04 14:15   ` yogi
  0 siblings, 1 reply; 10+ messages in thread
From: Michael Goldish @ 2009-04-30 14:10 UTC (permalink / raw)
  To: yogi; +Cc: Uri Lublin, kvm


----- "yogi" <anantyog@linux.vnet.ibm.com> wrote:

> Hello everyone,
> 
> I like to submit patch to add support for "remote migration" in
> kvm-autotest.

Sounds like a good idea.

Also, the patch isn't too big, which I personally appreciate very much (makes it easier to read).

> To use this patch the following four parameters should be added to
> the
> existing migration test
> 
>         remote = dst
>         hostip = <localhost ip or name>
>         remoteip = <remote host ip or name>
>         remuser = root
>         rempassword = <password>
> 
> the field remote=dst indicates the VM "dst" should be created on
> remote
> machine.
> For example:
>     - migrate:      install setup
>         type = migration
>         vms += " dst"
>         migration_test_command = help
>         kill_vm_on_error = yes
>         remote = dst
>         hostip = 192.168.1.2
>         remoteip = 192.168.1.3
>         remuser = root
>         rempassword = 123456
>         variants:
> 
> Three files r being modified in this patch kvm_utils.py, kvm_tests.py
> and kvm_vm.py.
> kvm_utils.py - if the  ssh-keys have been exchanged between the test
> machines,then remote login fails with message "Got unexpected login
> prompt", to prevent this, have made it return a session rather then
> None
> 
> kvm_tests.py - the host address used in migration is made dynamic
> 
> kvm_vm.py -    have replaced unix sockets with tcp sockets for
> monitor,
> in both remote and local VM. Added two new variables(remote,ssh_port)
> to
> class VM,remote set to True if the VM is on a  remote
> machine,ssh_port
> contains the redirection port, funtion get_address() returns the ip
> of
> the host whr the VM is(local or remote).

I've only looked at the code briefly, and it looks very good overall, but I have a few comments/questions:

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).

Other things:

- If I understand correctly, remote migration will only work if the remote qemu binary path is exactly the same as the local one. Maybe we should receive a qemu path parameter that will allow for some flexibility.

- In VM.make_qemu_command(), in the code that handles redirections, you add 'self.ssh_port = host_port'. I don't think this is correct because there can be multiple redirections, unrelated to SSH, so you certainly shouldn't assume that the only redirection is an SSH one. When you want the host port redirected to the guest's SSH port, you should use self.get_port(int(self.params.get("ssh_port"))). This will also work if for some reason 'ssh_port' changes while the guest is alive.

- It seems that the purpose of 'remote = dst' is to indicate to 'dst' that it should be started as a remote VM. The preferred way to do this is to pass something like 'remote_dst = yes' and then in VM.create() you can test for params.get("remote") == "yes". See "Addressing objects" in the wiki (http://www.linux-kvm.org/page/KVM-Autotest/Parameters#Addressing_objects_.28VMs.2C_images.2C_NICs_etc.29).
In general, any parameter you want to pass to a specific VM, you pass using <param>_<vmname> = <value>, e.g. 'mem_dst = 128', and then in VM.create() the parameter is accessible without the VM name extension (e.g. self.params.get("mem") will equal "128").

Thanks,
Michael

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2009-05-27 16:50 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-04-30 11:56 [KVM-AUTOTEST] [PATCH] support for remote migration yogi
2009-04-30 13:55 ` David Huff
     [not found] <1708099165.481031241100420772.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
2009-04-30 14:10 ` Michael Goldish
2009-05-04 14:15   ` yogi
     [not found] <796594249.90621241466107981.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
2009-05-04 19:42 ` Michael Goldish
2009-05-25  6:40   ` sudhir kumar
2009-05-27 14:27     ` Uri Lublin
2009-05-27 16:50       ` sudhir kumar
     [not found] <1818401549.327921243244441830.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
2009-05-25  9:53 ` Michael Goldish
2009-05-26  5:18   ` sudhir kumar

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.