That problem was bother me long time ago.
Any ''guest'' part is need for some HVM-junk (like windows) and
do nothing
good for PV guests.
So we solve problem by creating ''faking tools'' (I post script
few weeks
ago in xen-api@) allowing us to migrate (and other operations) without
guest tools with any PV domain. Actually, I have plans to remove
xe-guest-tools from installation scripts of our customers with next
update...
More clear solution is removing checking guest tools version for PV
guest in xapi code...
On 24.03.2011 08:08, brooks@netgate.net wrote:>
> One of the issues I''ve had using XenServer in a multitenant
> environment is the requirement for the VMs to have xentools installed
> as it causes significant issues when upgrading the VM OS or the pool
> from one version of XenServer (XCP) to another. Having to touch
> hundreds VMs (by hand) after an upgrade just doesn''t scale nor is
> delegating the task to VM owners an option. Unfortunately a customer,
> even if they could be educated to do so, can''t easily install or
> update the tools unless the xs-tools iso is in the virtual DVD drive,
> and to load it into the DVD drive you need access to XenCenter or to
> the CLI (vm-cd-add, vm-cd-eject, vm-cd-insert, vm-cd-list,
> vm-cd-remove). On the flip side, even if we did cental admin for all
> the VMs (what a nightmare) we wouldn''t necessarily have root
access to
> the VM preventing us from installing the new tools.
>
> Not only does this create a management issue it also requires a fair
> amount of knowledge to do the right thing based on the VM. I''ve
seen
> situations where the kernel on the VM has been updated yet install.sh
> wants to downgrade the kernel. For example, I have a Debian Etch VM
> that is running an updated kernel:
>
> 2.6.18.8.xs5.5.0.15.449
>
> Yet, running install.sh on that VM without the -k option causes an
> older kernel to be installed:
>
> 2.6.18.8.xs1.0.0.16.450_1.0.0.16.450
>
> Not only that but the tools that get installed are for XCP 1.0.
>
> xe-guest-utilities_1.0.0-647_i386.deb
>
> I have installed the patch file (/etc/xensource/xapi_version_override)
> and XenCenter does report back the correct version:
>
> XenServer Version: 5.6.199
>
> Yet, if you run:
>
> install.sh -k
>
> warning: downgrading xe-guest-utilities from 5.5.0-466 to 1.0.0-647.
>
> It''s doing the correct thing by installing 1.0.0-647 (XCP 1.x),
but is
> certainly doesn''t look correct unless you do some digging. XCP
really
> needs it''s own version of XenCenter, or a better alternative.
>
> The XenServer 5.6fp1 manual states:
>
> --------------------------------------------------------------------------
>
>
> XenServer Tools must be installed for each Virtual Machine (Windows
> and Linux) in order for the VM to have a fully supported
> configuration, and to be able to use the XenServer management tools
> (the xe CLI or XenCenter). A Windows VM will function without them,
> but performance will be significantly hampered unless the tools are
> installed.
>
> Without the tools being installed, you cannot:
>
> - Cleanly shut down a VM
> - Cleanly reboot a VM
> - Suspend a VM
> - Migrate a running VM (aka XenMotion)
> - Use the checkpoint and roll back feature
> - Change the vCPUs Live
>
> --------------------------------------------------------------------------
>
>
> Given the above it would seem that it''s important to have windows
pv
> drivers, some older CentOS kernels, and the xe-guest-utilities
> installed in an XCP environment. But how do we manage it? The
> cloud.com guys (which is based on the free version of XenServer) seem
> to ignore the problem. What do you do?
>
> All ideas, comments, and opinons are welcome.
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users