Christopher DeMarco
2007-Jun-11 18:48 UTC
[Xen-users] Migrating domU and virtualization extensions
I have a dom0 with the Intel virtualization extensions, and one
without. For reference, Linux reports the first (with) as being
"model 6" in /proc/cpuinfo, and the second (without) as being
"model
4". The "flags" the first has which the second doesn''t
are
de
est
lahf_lm
pge
pse
sep
vme
vmx
Can I migrate a domU from the second dom0 (without the vme/vmx
extensions) to the first (with)?
--
Christopher DeMarco <demarco@maya.com>
Information Technology Supervisor
MAYA Group
+1-412-488-2900
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
Mark Williamson
2007-Jun-11 22:53 UTC
Re: [Xen-users] Migrating domU and virtualization extensions
> I have a dom0 with the Intel virtualization extensions, and one > without. For reference, Linux reports the first (with) as being > "model 6" in /proc/cpuinfo, and the second (without) as being "model > 4". The "flags" the first has which the second doesn''t are > > de > est > lahf_lm > pge > pse > sep > vme > vmx > > Can I migrate a domU from the second dom0 (without the vme/vmx > extensions) to the first (with)?Yes, I guess you should be able to - are they both the same manufacturer? Both Intel? What models are they, actually? If that works, you also may be able to migrate in the other direction... The main problem is that certain system software (e.g. the kernel, some libraries) check at startup what extensions are available (e.g. SSE version, etc). They get horribly confused if live migration happens - if they suddenly find themselves migrated to a system without the capabilities they were expecting, receive invalid operation exceptions, and probably crash. Because of this, migrating to a machine with "more" features ought to work - nothing disappears. However, if the domain reboots after being migrated to a system that has more features (or possibly if a library initialises itself after being migrated to that system) it won''t necessarily be safe to migrate it back! The VMX extensions don''t matter for this, since they won''t be in use in a domU anyhow... I''m not sure what all of the other flags mean: if any of them are used by applications or the kernel this could be a problem... There was talk about masking out some CPU feature bits for guests in order to avoid this but I''m not entirely sure what the status of this is. Hope that''s at least helped a bit. Cheers, Mark -- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Christopher DeMarco
2007-Jun-12 03:58 UTC
Re: [Xen-users] Migrating domU and virtualization extensions
On Mon, Jun 11, 2007 at 11:53:59PM +0100, Mark Williamson wrote:> Yes, I guess you should be able to - are they both the same manufacturer? > Both Intel? What models are they, actually?Well, I don''t get it. They''re both Intel Xeons, but on the old box, the contents of /proc/cpuinfo differ from the output of ``cpuid'''' -- cpuinfo doesn''t list vme/vmx, but cpuid does. Also, /proc/cpuinfo on the new system lists *8* cores, but I coulda sworn that Dell''s deal was for 2 dual-core Xeons. Gotta lookit that onsite tomorrow. But anyway, here''s a diff against ``cpuid'''' on both boxen. "onion" is the old one, "wilbur" is the new one: --- onion 2007-06-11 23:48:55.000000000 -0400 +++ wilbur 2007-06-11 23:49:42.000000000 -0400 @@ -1,35 +1,35 @@ eax in eax ebx ecx edx -00000000 00000005 756e6547 6c65746e 49656e69 -00000001 00000f41 01020800 0000641d bfebfbff -00000002 605b5001 00000000 00000000 007c7040 +00000000 00000006 756e6547 6c65746e 49656e69 +00000001 00000f64 03040800 0000e4bd bfebfbff +00000002 605b5001 00000000 00000000 007d7040 00000003 00000000 00000000 00000000 00000000 -00000004 00004121 01c0003f 0000001f 00000000 +00000004 04004121 01c0003f 0000001f 00000000 00000005 00000040 00000040 00000000 00000000 +00000006 00000000 00000000 00000000 00000000 80000000 80000008 00000000 00000000 00000000 -80000001 00000000 00000000 00000000 20100000 +80000001 00000000 00000000 00000001 20100000 80000002 20202020 20202020 20202020 20202020 80000003 6e492020 286c6574 58202952 286e6f65 -80000004 20294d54 20555043 30382e32 007a4847 +80000004 20294d54 20555043 30302e33 007a4847 80000005 00000000 00000000 00000000 00000000 -80000006 00000000 00000000 04006040 00000000 +80000006 00000000 00000000 08006040 00000000 80000007 00000000 00000000 00000000 00000000 80000008 00003024 00000000 00000000 00000000 -Vendor ID: "GenuineIntel"; CPUID level 5 +Vendor ID: "GenuineIntel"; CPUID level 6 Intel-specific functions: -Version 00000f41: +Version 00000f64: Type 0 - Original OEM Family 15 - Pentium 4 Extended family 0 -Model 4 - -Stepping 1 +Model 6 - +Stepping 4 Reserved 0 -Extended brand string: " Intel(R) Xeon(TM) CPU 2.80GHz" +Extended brand string: " Intel(R) Xeon(TM) CPU 3.00GHz" CLFLUSH instruction cache line size: 8 -Initial APIC ID: 1 -Hyper threading siblings: 2 +Hyper threading siblings: 4 Feature flags bfebfbff: FPU Floating Point Unit @@ -67,5 +67,5 @@ 60: unknown TLB/cache descriptor 40: No 2nd-level cache, or if 2nd-level cache exists, no 3rd-level cache 70: Trace cache: 12K-micro-op, 4-way set assoc -7c: 2nd-level cache: 1MB, 8-way set assoc, sectored, 64 byte line size -Processor serial: 0000-0F41-0000-0000-0000-0000 +7d: unknown TLB/cache descriptor +Processor serial: 0000-0F64-0000-0000-0000-0000> etc). They get horribly confused if live migration happens - if they > suddenly find themselves migrated to a system without the capabilities they > were expecting, receive invalid operation exceptions, and probably crash.Does this mean that an offline migration will work? If I can just shut down the domU and then ``tar | nc | tar'''', I''m thrilled. VMWare won''t run a VM from the old system on the new one. -- Christopher DeMarco <demarco@maya.com> Information Technology Supervisor MAYA Group +1-412-488-2900 _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Petersson, Mats
2007-Jun-12 09:00 UTC
RE: [Xen-users] Migrating domU and virtualization extensions
> -----Original Message----- > From: xen-users-bounces@lists.xensource.com > [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of > Christopher DeMarco > Sent: 12 June 2007 04:58 > To: xen-users@lists.xensource.com > Subject: Re: [Xen-users] Migrating domU and virtualization extensions > > On Mon, Jun 11, 2007 at 11:53:59PM +0100, Mark Williamson wrote: > > > Yes, I guess you should be able to - are they both the same > manufacturer? > > Both Intel? What models are they, actually? > > Well, I don''t get it. > > They''re both Intel Xeons, but on the old box, the contents of > /proc/cpuinfo differ from the output of ``cpuid'''' -- cpuinfo doesn''t > list vme/vmx, but cpuid does. Also, /proc/cpuinfo on the new system > lists *8* cores, but I coulda sworn that Dell''s deal was for 2 > dual-core Xeons. Gotta lookit that onsite tomorrow.8 cores would be "2 sockets * 2 cores * 2 hyperthreads" perhaps?> > But anyway, here''s a diff against ``cpuid'''' on both boxen. "onion" is > the old one, "wilbur" is the new one: > > --- onion 2007-06-11 23:48:55.000000000 -0400 > +++ wilbur 2007-06-11 23:49:42.000000000 -0400 > @@ -1,35 +1,35 @@ > eax in eax ebx ecx edx > -00000000 00000005 756e6547 6c65746e 49656e69 > -00000001 00000f41 01020800 0000641d bfebfbff > -00000002 605b5001 00000000 00000000 007c7040 > +00000000 00000006 756e6547 6c65746e 49656e69 > +00000001 00000f64 03040800 0000e4bd bfebfbff > +00000002 605b5001 00000000 00000000 007d7040 > 00000003 00000000 00000000 00000000 00000000 > -00000004 00004121 01c0003f 0000001f 00000000 > +00000004 04004121 01c0003f 0000001f 00000000 > 00000005 00000040 00000040 00000000 00000000 > +00000006 00000000 00000000 00000000 00000000 > 80000000 80000008 00000000 00000000 00000000 > -80000001 00000000 00000000 00000000 20100000 > +80000001 00000000 00000000 00000001 20100000 > 80000002 20202020 20202020 20202020 20202020 > 80000003 6e492020 286c6574 58202952 286e6f65 > -80000004 20294d54 20555043 30382e32 007a4847 > +80000004 20294d54 20555043 30302e33 007a4847 > 80000005 00000000 00000000 00000000 00000000 > -80000006 00000000 00000000 04006040 00000000 > +80000006 00000000 00000000 08006040 00000000 > 80000007 00000000 00000000 00000000 00000000 > 80000008 00003024 00000000 00000000 00000000 > > -Vendor ID: "GenuineIntel"; CPUID level 5 > +Vendor ID: "GenuineIntel"; CPUID level 6 > > Intel-specific functions: > -Version 00000f41: > +Version 00000f64: > Type 0 - Original OEM > Family 15 - Pentium 4 > Extended family 0 > -Model 4 - > -Stepping 1 > +Model 6 - > +Stepping 4 > Reserved 0 > > -Extended brand string: " Intel(R) Xeon(TM) CPU > 2.80GHz" > +Extended brand string: " Intel(R) Xeon(TM) CPU > 3.00GHz" > CLFLUSH instruction cache line size: 8 > -Initial APIC ID: 1 > -Hyper threading siblings: 2 > +Hyper threading siblings: 4Yup, you''ve got 2 hyperthreads per core -> 8 "cores" to Linux. Hyperthreads CAN help Xen in the sense that you could dedicate a hyperthread to Dom0, giving the CPU performance of the core to run DomU most of the time, but also avoiding a "world switch" when going to dom0, as it''s still got it''s dedicated core - but you do loose a little compared to giving a physical full core to Dom0 of course.> > Feature flags bfebfbff: > FPU Floating Point Unit > @@ -67,5 +67,5 @@ > 60: unknown TLB/cache descriptor > 40: No 2nd-level cache, or if 2nd-level cache exists, no 3rd-level > cache > 70: Trace cache: 12K-micro-op, 4-way set assoc > -7c: 2nd-level cache: 1MB, 8-way set assoc, sectored, 64 byte line > size > -Processor serial: 0000-0F41-0000-0000-0000-0000 > +7d: unknown TLB/cache descriptor > +Processor serial: 0000-0F64-0000-0000-0000-0000It doesn''t look to me like there are any "important" differences, such as SSE2 on one but not on the other. These are the type of things that could cause problems when migrating. -- Mats> > > > etc). They get horribly confused if live migration happens > - if they > > suddenly find themselves migrated to a system without the > capabilities they > > were expecting, receive invalid operation exceptions, and > probably crash. > > Does this mean that an offline migration will work? If I can just > shut down the domU and then ``tar | nc | tar'''', I''m thrilled. VMWare > won''t run a VM from the old system on the new one. > > > -- > Christopher DeMarco <demarco@maya.com> > Information Technology Supervisor > MAYA Group > +1-412-488-2900 > > _______________________________________________ > 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