Xen devel - Jan 2013 - xen4.2 + qemu-upstream domain rename partial failure (& migration)

I am seeing a problem with domain renames which I think affects everything
running with the upstream qemu xen DM.

If I create a domain, and then rename it, it renames in the xenstore, but
it does not rename in qemu. This means that (interalia) the name on a VNC
connection is incorrect. I am seeing this with a migration (where a
libxl_domain_rename is done from "name--incoming" to "name"
is done
close to the end of the migration), but it also seems to happen with
"xl rename" from the command line (see below for how to replicate).

So, to be clear, it's renaming in xenstore (and xl list) but not the
rename is not being transmitted to qemu to affect (e.g.) the vnc name.
Hence after a migration, "--incoming" gets stuck on the end of the VNC
name even when a migration is successful.

I don't really understand how this is meant to work. Should something
be setting a watch on the xenstore "name" element? Or should libxl be
issuing QMP command on the name change?

Or is this just doomed to fail? In which case the name passed as -name
to the QEMU command line should probably be the original name, not the
name with "--incoming" on on a migration, and 'xl rename' is
just going
to fail to change it.

Code inspection suggests this is no different in xen-unstable but I
haven't tried it.

-- 
Alex Bligh


root@ubuntu:~# xl create /root/xlcreate-qcow.conf
Parsing config from /root/xlcreate-qcow.conf
xc: info: VIRTUAL MEMORY ARRANGEMENT:
 Loader:        0000000000100000->000000000019db88
 TOTAL:         0000000000000000->00000000bf800000
 ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
 4KB PAGES: 0x0000000000000200
 2MB PAGES: 0x00000000000003fb
 1GB PAGES: 0x0000000000000001
Daemon running with PID 6946
root@ubuntu:~# xl list
Name 
                                       ID 
  Mem VCPUs	State	Time(s)
Domain-0 
                                    0 
 5049     2     r-----    1682.6
Irrelevant 
                                  5 
 6912     2     -b----    2576.5
InitialName 
                                 6  3072 
    2     r-----       8.8
root@ubuntu:~#

InitialName is the newly created domain.

root@ubuntu:~# ps aux | grep qemu

root      6817  9.9  0.5 410360 26944 ?        SLsl 10:00 
  0:09 /usr/lib/xen/bin/qemu-system-i386 -xen-domid 6 -chardev 
socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-6,server,nowait -mon 
chardev=libxl-cmd,mode=control -name InitialName -vnc 0.0.0.0:0,password 
-serial pty -vga cirrus -boot order=cda -smp 2,maxcpus=2 -device 
rtl8139,id=nic0,netdev=net0,mac=00:16:3e:e9:96:a8 -netdev 
type=tap,id=net0,ifname=vif6.0-emu,script=no,downscript=no -M xenfv -m 3064 
-drive 
file=/root/test.qcow2,if=ide,index=0,media=disk,format=qcow2,cache=writeback

root@ubuntu:~# xl rename 6 NewName
root@ubuntu:~# xl list
Name 
                                       ID 
  Mem VCPUs	State	Time(s)
Domain-0 
                                    0 
 5049     2     r-----    1688.0
Irrelevant 
                                  5 
 6912     2     -b----    2580.4
NewName 
                                    6 
 3072     2     -b----      16.2
root@ubuntu:~# ps aux | grep qemu

root      6817  8.1  0.5 410360 26944 ?        SLsl 10:00 
  0:09 /usr/lib/xen/bin/qemu-system-i386 -xen-domid 6 -chardev 
socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-6,server,nowait -mon 
chardev=libxl-cmd,mode=control -name InitialName -vnc 0.0.0.0:0,password 
-serial pty -vga cirrus -boot order=cda -smp 2,maxcpus=2 -device 
rtl8139,id=nic0,netdev=net0,mac=00:16:3e:e9:96:a8 -netdev 
type=tap,id=net0,ifname=vif6.0-emu,script=no,downscript=no -M xenfv -m 3064 
-drive 
file=/root/test.qcow2,if=ide,index=0,media=disk,format=qcow2,cache=writeback




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

On Sat, 2013-01-12 at 10:26 +0000, Alex Bligh wrote:
> So, to be clear, it''s renaming in xenstore (and xl list) but not
the
> rename is not being transmitted to qemu to affect (e.g.) the vnc name.
> Hence after a migration, "--incoming" gets stuck on the end of
the VNC
> name even when a migration is successful.
Yes, this is a known issue unfortunately.
> I don''t really understand how this is meant to work. Should
something
> be setting a watch on the xenstore "name" element? Or should
libxl be
> issuing QMP command on the name change?
Assuming such a QMP command exists this would be the right thing to do I
think.
> Or is this just doomed to fail? In which case the name passed as -name
> to the QEMU command line should probably be the original name, not the
> name with "--incoming" on on a migration, and ''xl
rename'' is just going
> to fail to change it.
Yes, this approach has a couple of problems, firstly the "xl rename"
one
you''ve identified but secondly the renaming is all contained within xl
and the libxl API has to way to express a different name to pass to the
device model. The QMP renaming approach is probably best.
> Code inspection suggests this is no different in xen-unstable but I
> haven''t tried it.
>

Ian,

--On 16 January 2013 09:56:28 +0000 Ian Campbell <Ian.Campbell@citrix.com>
wrote:
> On Sat, 2013-01-12 at 10:26 +0000, Alex Bligh wrote:
>> So, to be clear, it''s renaming in xenstore (and xl list) but
not the
>> rename is not being transmitted to qemu to affect (e.g.) the vnc name.
>> Hence after a migration, "--incoming" gets stuck on the end
of the VNC
>> name even when a migration is successful.
>
> Yes, this is a known issue unfortunately.
>
>> I don''t really understand how this is meant to work. Should
something
>> be setting a watch on the xenstore "name" element? Or should
libxl be
>> issuing QMP command on the name change?
>
> Assuming such a QMP command exists this would be the right thing to do I
> think.
No such QMP command exists currently. Adding one to fix VNC would be
reasonably trivial. The ''change'' command currently exists to
change
the password, and we could add a ''hostname'' option. This would
have
the biproduct of allowing you to name your machine ''Foo''
rather than
''QEMU (Foo)'' on VNC - I for one find the latter annoying.
I''d be
happy to provide a patch for that if the QEMU folks would take it.

However, this won''t solve the entire issue as the machine name seems
to be used for several things in QEMU - to pick a random example, some
SPICE stuff that I have no idea about. I don''t know whether for all of
those things it''s going to be safe to rename them when the domain
is created. Certainly changing the ''ps'' line for qemu is not
going
to be trivial.
>> Or is this just doomed to fail? In which case the name passed as -name
>> to the QEMU command line should probably be the original name, not the
>> name with "--incoming" on on a migration, and ''xl
rename'' is just going
>> to fail to change it.
>
> Yes, this approach has a couple of problems, firstly the "xl
rename" one
> you''ve identified but secondly the renaming is all contained
within xl
> and the libxl API has to way to express a different name to pass to the
> device model. The QMP renaming approach is probably best.
I count only one problem there :-)

A ''nasty hack'' approach would simply be to delete
''--incoming'' from the
end of string before it is passed to QEMU.

A marginally less nasty hack might be to create the domain to start off
with without the ''--incoming'', then rename it to
''--incoming'', then
rename it back. Of course this has the risk of death between creation
and first rename.

-- 
Alex Bligh