|
thanks for those changes. i just tried
it and things appear to be working properly.
mike
On 11/06/2012 01:59 AM, Xiao Peng Wang wrote:
Mike,
The fixes for rmigrate and cpu
configuration issues have been included in the attached file,
you could have a try.
For the issue you mentioned
that how to make a vm binds to a specific host, my suggestion
is to run 'chdef <vm> vmhost=<specific host>' and
'chvm <vm>' after your migration, then the vm will boot
on the <specific host> in the next reboot.
(See attached file: rhevm.pm)
Thanks
Best Regards
----------------------------------------------------------------------
Wang Xiaopeng (王晓朋)
IBM China System Technology Laboratory
Tel: 86-10-82453455
Email: [email protected]
Address: 28,ZhongGuanCun Software Park,No.8 Dong Bei Wang West
Road, Haidian District Beijing P.R.China 100193
Mike Lovell ---2012/11/06
08:07:21---i've been doing some experimentation with the xcat
rhevm plugin and ran into a little bit of a snag
From: Mike Lovell
<[email protected]>
To: xCAT Users Mailing list
<[email protected]>, Xiao Peng
Wang/China/IBM@IBMCN, Jarrod B Johnson
<[email protected]>,
Cc: [email protected], Dave Jackson
<[email protected]>
Date: 2012/11/06 08:07
Subject: rmigrate with rhevm plugin
i've been doing some experimentation with the
xcat rhevm plugin and ran
into a little bit of a snag with rmigrate. if the
placement_affinity
vm.virt_flag is set to user_migratable then rmigrate fails
because the
rhev-m api returns the following error.
[root@rhev-ml moab]# rmigrate rhvvm2 server02
Error: rhvvm2: [Cannot migrate VM. VM is non migratable and
user did not
specify the force-migration flag].
it appears that an additional 'force' argument needs to be
specified on
the api request if the vm is 'user_migratable.' specifying the
following
xml as the body of a request resulted in the 'user_migratable'
vm being
migrated.
"<action><host
id='aec2a2ee-22e2-11e2-98c7-525400000055'/><force>true</force></action>"
i think it makes sense to support rmigrate with the
user_migratable flag
since not everyone using rhevm would want rhevm to be making
migration
decisions automatically. i did test having the 'force' flag in
a request
to a vm that was just 'migratable' so it doesn't appear to
have a
negative affect. also, if the vm is set to 'pinned' it will
not migrate
even if the 'force' flag is set.
do you all have any objections to just adding the
"<force>true</force>"
to the api request to rhevm for rmigrate? or making the force
option an
additional argument to rmigrate?
also, it appears that if a vm is migrated, shutdown, and
started that
the vm will start on the original host and not the host the vm
was
migrated to. i think this is due to how rhev-m tracks the vms.
should
things be changed so that vm.host is changed during rmigrate
and that
`rpower on` forces the host to start on? or that `rpower on`
can take an
additional argument to specify the host to start the vm on? do
you have
any other thoughts about this?
mike
|
------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
xCAT-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xcat-user