http://xenbits.xen.org/people/andrewcoop/feature-levelling/feature-levelling-E.pdf
From IRC #xen
20:20 -!- Irssi: #xen: Total of 238 nicks [6 ops, 0 halfops, 0 voices, 232 normal]
20:20 -!- Channel #xen created Fri Jun 24 00:03:57 2005
20:20 -!- Irssi: Join to #xen was synced in 1 secs
20:21 -!- P2Vme [uid89951@gateway/web/irccloud.com/x-lqngxzvluinixwai] has joined #xen
20:21 < sunkan> When using Linux PV domU's are there any restrictions on CPU compatibility for live migration other than i386/x86_64?
20:22 -!- PryMar56 [~prymar@unaffiliated/prymar56] has quit [Ping timeout: 264 seconds]
20:22 < epretorious> yes - both hosts must have the same set of capabilities.
20:22 < epretorious> sunkan: yes - both hosts must have the same set of capabilities.
20:23 < epretorious> sunkan: i.e., `cat /proc/cpuinfo`
20:26 < sunkan> epretorious: Ok, is it possible to "downgrade" a newer CPU to make it compatible with an older one?
20:26 < sunkan> epretorious: Like masking capabilities or something like that.
20:28 < andyhhp> in theory, yes
20:28 < andyhhp> in practice, more complicated
20:29 < andyhhp> http://xenbits.xen.org/people/andrewcoop/feature-levelling/feature-levelling-E.pdf
20:29 < andyhhp> I am literally right this moment trying to work on fixing it, but it is complicated
20:30 -!- cale250 [~cale250@unaffiliated/cale250] has quit [Ping timeout: 252 seconds]
20:30 < sunkan> Ok, well at this time it is for my home setup. But I think it may be needed at work some time as well.
20:31 < sunkan> For my knowledge, are there any differences between the requirements when comparing HVM/PV guests?
20:32 -!- cale250 [~cale250@unaffiliated/cale250] has joined #xen
20:32 -!- skylite [~skylite@5402F494.dsl.pool.telekom.hu] has joined #xen
20:33 < sunkan> Sounds like there are some differences (reading the PDF)
20:34 < andyhhp> correct
20:35 < sunkan> I have heard that we might be going to some hybrid instead ov PV guests, is that still ongoing work (or maybe completed, I'm not
up2date on that).
20:36 < andyhhp> that is PVH
20:37 < andyhhp> which falls into the "HVM" category as far as that document is concerned
20:37 < sunkan> Right, could not remember the acronym.. Is that something that is working yet?
20:37 < sunkan> I'm on Xen 4.4.1 (Debian Jessie)
20:38 < andyhhp> no - that is not working yet
20:38 -!- PryMar56 [~prymar@unaffiliated/prymar56] has joined #xen
20:39 -!- skweek [~skweek@USF-Gold-Wifi-nat-79.laptops.usf.edu] has quit [Ping timeout: 250 seconds]
20:40 < sunkan> I guess just trying some migrations does not guarantee anything just because they work. If the guest later on runs something
that uses some specific feature it can fail another time later on?
20:41 -!- cale250 [~cale250@unaffiliated/cale250] has quit [Ping timeout: 260 seconds]
20:41 < sunkan> I mean, when migrating between different CPU's and not masking anything.
20:45 -!- cale250 [~cale250@unaffiliated/cale250] has joined #xen
20:49 < sunkan> Interesting read, but I don't understand it all. But sounds like at this time HVM is easier than PV due to possibility to
control CPUID access to report different data to domU?
20:50 < epretorious> sunkan, fwiw: i believe that vmware esx/vsphere performs cpu-masking.
20:50 < andyhhp> sunkan: HVM is easier, but is still no less broken in the current implementation
20:50 < epretorious> sunkan, i don't know if vmware esxi is still "free" or not but that might suit your environment.
20:50 < sunkan> epretorious: Yes I'm pretty sure they do, we use it in our DC but they don't have pure PV machines at all.
20:51 < epretorious> sunkan, is there a requirement that your guests be paravirtualized?
20:52 < epretorious> sunkan, or just that your cpu's don't support the virt extensions?
20:52 < epretorious> sunkan, iirc: vmware esxi doesn't require VTx/SVE.
20:53 < sunkan> epretorious: No, but I have run PV machines since many many years back. It just feels better/smarter - but I think my opinions
on that will probably have to change with PVH as that was supposed to have some real benefits over plain PV.
20:54 -!- bdmc [bdmc@cl-745.bos-01.us.sixxs.net] has joined #xen
20:54 < sunkan> epretorious: At first I did not have any virtualization support on the CPU's but that has change since several years ago.
20:56 < sunkan> For now I will have to live with restarting guests in my "private" environment..
20:57 < sunkan> Anybody know whether XenServer 6.2 or 6.5 does any checking before live migrating machines between pools?
20:57 < sunkan> Or is that up to the administrator to keep track on?
20:58 < andyhhp> checks are made
20:59 < andyhhp> but all the XenServer problems in that document still apply
21:00 < sunkan> Not sure I understood them perfectly, but I guess it is not completely safe to migrate HVM guests between different CPUs in
XenServer then?
21:01 < andyhhp> what hardware have you got in your pool?
21:01 < andyhhp> older hardware will function, newer wont
21:02 < sunkan> I don't remember on top of my head. It's quite new Intel HP ProLiant blade servers.
21:02 < andyhhp> you will probably hit issues then
21:02 < andyhhp> depending on how different the two cpus are
21:03 < sunkan> I think we have had some issues already and did not think about this as a possible cause at the time. But will mention to my
collegues to think about it in the future. We normally don't migrate much between pools, but since it is possible now it is
sometimes discussed as an option for some non-interruptive maintenance work.
21:05 < andyhhp> I am working to fix it in XenServer Dundee
21:05 -!- bdmc [bdmc@cl-745.bos-01.us.sixxs.net] has quit [Ping timeout: 246 seconds]
21:05 < sunkan> Cool, we are not on Creedence yet though.. We usually have to take things a bit safe (slow)..
21:06 < andyhhp> it has been broken since forever, but doesn't show up on older hardware
21:07 < andyhhp> and now things are so bad that Xapi doesn't actually have a clue which features are actually advertised to the guest, so can't
even evaluate whether a migration is safe or not
21:07 < sunkan> Ouch
21:07 < andyhhp> there are problems at all levels, including the hypervisor
21:08 < sunkan> Hope you can find and fix them all then :)
21:10 < andyhhp> I am rewriting it from scratch