patches for migration from xm (4.0.1) to xl (4.3) acceptable?

patches for migration from xm (4.0.1) to xl (4.3) acceptable?

[Vasiliy Tolstov]

Hi all. If i send patches for migration from xm to xl toolstack, does
it acceptable for upstream xen?
Nothing serious only minor fixes to provide correct qemu (upstream) args.

-- 
Vasiliy Tolstov,
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru

Re: patches for migration from xm (4.0.1) to xl (4.3) acceptable?

[Ian Campbell]

On Mon, 2014-04-28 at 20:02 +0400, Vasiliy Tolstov wrote:
> Hi all. If i send patches for migration from xm to xl toolstack, does
> it acceptable for upstream xen?
> Nothing serious only minor fixes to provide correct qemu (upstream) args.

Are these against 4.3 or 4.1? In either case the usual route for patches
in those trees would be via xen-unstable, it's not clear how that would
work in this case.

But in general it would probably be easier evaluate specific patches
rather than doing it in the abstract. 

Ian.

[PATCH] allow xm2xl migration for xen-4.3

[v.tolstov]

From: Vasiliy Tolstov <v.tolstov@selfip.ru>

Fixed some python stuff for path detection
Provide right qemu args (videoram size not passed not, but default
works fine - only forward version migration possible)

Signed-off-by: Vasiliy Tolstov <v.tolstov@selfip.ru>
---
 tools/python/xen/xend/XendCheckpoint.py |  4 ++--
 tools/python/xen/xend/XendConfig.py     | 12 ++++++------
 tools/python/xen/xend/XendDomainInfo.py |  2 +-
 tools/python/xen/xend/image.py          | 13 +++----------
 tools/python/xen/xm/create.py           |  2 +-
 5 files changed, 13 insertions(+), 20 deletions(-)

diff --git a/tools/python/xen/xend/XendCheckpoint.py b/tools/python/xen/xend/XendCheckpoint.py
index a433ffa..940c9bf 100644
--- a/tools/python/xen/xend/XendCheckpoint.py
+++ b/tools/python/xen/xend/XendCheckpoint.py
@@ -118,7 +118,7 @@ def save(fd, dominfo, network, live, dst, checkpoint=False, node=-1,sock=None):
         # enabled. Passing "0" simply uses the defaults compiled into
         # libxenguest; see the comments and/or code in xc_linux_save() for
         # more information.
-        cmd = [xen.util.auxbin.pathTo(XC_SAVE), str(fd),
+        cmd = [xen.util.auxbin.path_bin(XC_SAVE), str(fd),
                str(dominfo.getDomid()), "0", "0", 
                str(int(live) | (int(hvm) << 2)) ]
         log.debug("[xc_save]: %s", string.join(cmd))
@@ -299,7 +299,7 @@ def restore(xd, fd, dominfo = None, paused = False, relocating = False):
 
         superpages = restore_image.superpages
 
-        cmd = map(str, [xen.util.auxbin.pathTo(XC_RESTORE),
+        cmd = map(str, [xen.util.auxbin.path_bin(XC_RESTORE),
                         fd, dominfo.getDomid(),
                         store_port, console_port, int(is_hvm), pae, apic, superpages, 1])
         log.debug("[xc_restore]: %s", string.join(cmd))
diff --git a/tools/python/xen/xend/XendConfig.py b/tools/python/xen/xend/XendConfig.py
index 4a226a7..b205db1 100644
--- a/tools/python/xen/xend/XendConfig.py
+++ b/tools/python/xen/xend/XendConfig.py
@@ -493,11 +493,11 @@ class XendConfig(dict):
 
         if self.is_hvm() or self.has_rfb():
             if 'device_model' not in self['platform']:
-                self['platform']['device_model'] = auxbin.pathTo("qemu-dm")
+                self['platform']['device_model'] = auxbin.path_bin("qemu-dm")
             # device_model may be set to 'qemu-dm' or 'stubdom-dm' w/o a path
             if os.path.dirname(self['platform']['device_model']) == "":
                 self['platform']['device_model'] = \
-                    auxbin.pathTo(self['platform']['device_model'])
+                    auxbin.path_bin(self['platform']['device_model'])
             # If the device_model is not set the os.path.exists() would raise
             # an exception so we return our error message instead if applicable
             if not self['platform']['device_model']:
@@ -528,14 +528,14 @@ class XendConfig(dict):
                 # Old configs may have hvmloader set as PV_kernel param
                 if self.has_key('PV_kernel') and self['PV_kernel'] != '':
                     if self['PV_kernel'] == 'hvmloader':
-                        self['PV_kernel'] = auxbin.pathTo("hvmloader")
+                        self['PV_kernel'] = auxbin.path_bin("hvmloader")
                     self['platform']['loader'] = self['PV_kernel']
                     self['PV_kernel'] = ''
                 else:
-                    self['platform']['loader'] = auxbin.pathTo("hvmloader")
+                    self['platform']['loader'] = auxbin.path_bin("hvmloader")
                 log.debug("Loader is %s" % str(self['platform']['loader']))
             elif self['platform']['loader'] == 'hvmloader':
-                self['platform']['loader'] = auxbin.pathTo("hvmloader")
+                self['platform']['loader'] = auxbin.path_bin("hvmloader")
             if not os.path.exists(self['platform']['loader']):
                 raise VmError("kernel '%s' not found" % str(self['platform']['loader']))
 
@@ -1653,7 +1653,7 @@ class XendConfig(dict):
                     # is invoked for pvfb services
                     if 'device_model' not in target['platform']:
                         target['platform']['device_model'] = \
-                            auxbin.pathTo("qemu-dm")
+                            auxbin.path_bin("qemu-dm")
 
                     # Finally, if we are a pvfb, we need to make a vkbd
                     # as well that is not really exposed to Xen API
diff --git a/tools/python/xen/xend/XendDomainInfo.py b/tools/python/xen/xend/XendDomainInfo.py
index e9d3e7e..5b0f8b3 100644
--- a/tools/python/xen/xend/XendDomainInfo.py
+++ b/tools/python/xen/xend/XendDomainInfo.py
@@ -3239,7 +3239,7 @@ class XendDomainInfo:
         else:
             # Boot using bootloader
             if not blexec or blexec == 'pygrub':
-                blexec = auxbin.pathTo('pygrub')
+                blexec = auxbin.path_boot('pygrub')
 
             blcfg = None
             disks = [x for x in self.info['vbd_refs']
diff --git a/tools/python/xen/xend/image.py b/tools/python/xen/xend/image.py
index 832c168..7acd9aa 100644
--- a/tools/python/xen/xend/image.py
+++ b/tools/python/xen/xend/image.py
@@ -264,7 +264,7 @@ class ImageHandler:
     # Return a list of cmd line args to the device models based on the
     # xm config file
     def parseDeviceModelArgs(self, vmConfig):
-        ret = ["-domain-name", str(self.vm.info['name_label'])]
+        ret = ["-xen-domid", "%d" % self.vm.getDomid(), "-xen-attach", "-name", "%s" % str(self.vm.info['name_label']), "-m", "%d" % (self.getRequiredInitialReservation() / 1024)]
 
         xen_extended_power_mgmt = int(vmConfig['platform'].get(
             'xen_extended_power_mgmt', 0))
@@ -281,10 +281,6 @@ class ImageHandler:
             ret.append('-nographic')
             return ret
 
-        vram = str(vmConfig['platform'].get('videoram',4))
-        ret.append('-videoram')
-        ret.append(vram)
-
         vnc_config = {}
         has_vnc = int(vmConfig['platform'].get('vnc', 0)) != 0
         has_sdl = int(vmConfig['platform'].get('sdl', 0)) != 0
@@ -353,13 +349,10 @@ class ImageHandler:
 
             vnclisten = vnc_config.get('vnclisten',
                                        XendOptions.instance().get_vnclisten_address())
-            vncdisplay = int(vnc_config.get('vncdisplay', 0))
+            vncdisplay = int(vnc_config.get('vncdisplay', self.vm.getDomid() + 5900))
             ret.append('-vnc')
             ret.append("%s:%s%s" % (vnclisten, vncdisplay, vncopts))
 
-            if int(vnc_config.get('vncunused', 1)) != 0:
-                ret.append('-vncunused')
-
         if has_sdl:
             ret.append('-sdl')
             if int(vmConfig['platform'].get('opengl', opengl)) != 1 :
@@ -381,7 +374,7 @@ class ImageHandler:
 
     def getDeviceModelArgs(self, restore = False):
         args = [self.device_model]
-        args = args + ([ "-d",  "%d" % self.vm.getDomid() ])
+        args = args + ([ "-xen-domid",  "%d" % self.vm.getDomid() ])
         args = args + self.dmargs
         return args
 
diff --git a/tools/python/xen/xm/create.py b/tools/python/xen/xm/create.py
index 22841aa..592b44f 100644
--- a/tools/python/xen/xm/create.py
+++ b/tools/python/xen/xm/create.py
@@ -1121,7 +1121,7 @@ def make_config(vals):
     config_image = configure_image(vals)
     if vals.bootloader:
         if vals.bootloader == "pygrub":
-            vals.bootloader = auxbin.pathTo(vals.bootloader)
+            vals.bootloader = auxbin.path_boot(vals.bootloader)
 
         config.append(['bootloader', vals.bootloader])
         if vals.bootargs:
-- 
1.9.2

Re: [PATCH] allow xm2xl migration for xen-4.3

[Ian Campbell]

On Tue, 2014-04-29 at 20:57 +0400, v.tolstov@selfip.ru wrote:
> From: Vasiliy Tolstov <v.tolstov@selfip.ru>

Thanks. Which tree does this apply to and how would I go about using it?

I think it applies to xen 4.3 and is supposed to allow a guest started
by xm to be migrated with xl, to create an xl compatible vm, is that
correct? If not can you give the method for using it please.

> Fixed some python stuff for path detection

This is all the s/pathTo/path_(bin|boot)/ stuff? I'm not sure where e.g.
path_bin comes from, even Xen 4.4 seems to still use pathTo AFAICT and I
can't find any of this path_bin stuff in the tree.

> Provide right qemu args (videoram size not passed not, but default
> works fine - only forward version migration possible)

Can you expand on this, what does "right qemu args" mean? Since qemu is
restarted from scratch by the toolstack I'm not sure why this would
matter. I think this might become clearer once you explain how one is
supposed to make use of this.

Cheers,
Ian.

Re: [PATCH] allow xm2xl migration for xen-4.3

[Olaf Hering]

On Wed, Apr 30, Ian Campbell wrote:

> On Tue, 2014-04-29 at 20:57 +0400, v.tolstov@selfip.ru wrote:
> > From: Vasiliy Tolstov <v.tolstov@selfip.ru>
> 
> Thanks. Which tree does this apply to and how would I go about using it?
> 
> I think it applies to xen 4.3 and is supposed to allow a guest started
> by xm to be migrated with xl, to create an xl compatible vm, is that
> correct? If not can you give the method for using it please.

Does that migrate from qemu-xen-traditional to qemu-xen? And if so, is
that supposed to work anyway? I think the right approach would be to
start the remote side with device_model=qemu-xen-traditional.

Olaf

Re: [PATCH] allow xm2xl migration for xen-4.3

[Fabio Fantoni]

Il 30/04/2014 10:26, Ian Campbell ha scritto:
> On Tue, 2014-04-29 at 20:57 +0400, v.tolstov@selfip.ru wrote:
>> From: Vasiliy Tolstov <v.tolstov@selfip.ru>
> Thanks. Which tree does this apply to and how would I go about using it?
>
> I think it applies to xen 4.3 and is supposed to allow a guest started
> by xm to be migrated with xl, to create an xl compatible vm, is that
> correct? If not can you give the method for using it please.
>
>> Fixed some python stuff for path detection
> This is all the s/pathTo/path_(bin|boot)/ stuff? I'm not sure where e.g.
> path_bin comes from, even Xen 4.4 seems to still use pathTo AFAICT and I
> can't find any of this path_bin stuff in the tree.
>
>> Provide right qemu args (videoram size not passed not, but default
>> works fine - only forward version migration possible)

I not use qemu traditional for a year, but FWIK thevideoram setting is 
correctalso with xl like xm.
About upstream qemu you can have videoram setting working with these 2 
patches tested (with xen 4.4 and 4.5) and that FWIK are working:
fix cirrus vga videoram: 
http://lists.xen.org/archives/html/xen-devel/2014-04/msg02607.html
add stdvga videoram: 
http://lists.xen.org/archives/html/xen-devel/2014-04/msg03300.html

> Can you expand on this, what does "right qemu args" mean? Since qemu is
> restarted from scratch by the toolstack I'm not sure why this would
> matter. I think this might become clearer once you explain how one is
> supposed to make use of this.
>
> Cheers,
> Ian.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: [PATCH] allow xm2xl migration for xen-4.3

[Ian Campbell]

On Wed, 2014-04-30 at 10:41 +0200, Olaf Hering wrote:
> On Wed, Apr 30, Ian Campbell wrote:
> 
> > On Tue, 2014-04-29 at 20:57 +0400, v.tolstov@selfip.ru wrote:
> > > From: Vasiliy Tolstov <v.tolstov@selfip.ru>
> > 
> > Thanks. Which tree does this apply to and how would I go about using it?
> > 
> > I think it applies to xen 4.3 and is supposed to allow a guest started
> > by xm to be migrated with xl, to create an xl compatible vm, is that
> > correct? If not can you give the method for using it please.
> 
> Does that migrate from qemu-xen-traditional to qemu-xen?

Oh, I hadn't even considered that as a possibility!

> And if so, is that supposed to work anyway?

No

> I think the right approach would be to
> start the remote side with device_model=qemu-xen-traditional.

Yes.