search for: catchup

In http://libvirt.org/formatdomain.html#elementsTime , we could find there are three attributes of catchup tickpolicy: limit, threshold and slew. " The catchup element has three optional attributes, each a positive integer. The attributes are threshold, slew, and limit. " The xml format likes: <clock offset='utc'> <timer name='rtc' tickpolicy='catchup'&g...

On 03/13/2014 12:49 AM, Jincheng Miao wrote: > In http://libvirt.org/formatdomain.html#elementsTime , we could find there are > three attributes of catchup tickpolicy: limit, threshold and slew. > > " > The catchup element has three optional attributes, each a positive integer. > The attributes are threshold, slew, and limit. > " > The xml format likes: > <clock offset='utc'> > <timer name='...

On Thu, Mar 13, 2014 at 02:49:13AM -0400, Jincheng Miao wrote: > In http://libvirt.org/formatdomain.html#elementsTime , we could find there are > three attributes of catchup tickpolicy: limit, threshold and slew. > > " > The catchup element has three optional attributes, each a positive integer. > The attributes are threshold, slew, and limit. > " > The xml format likes: > <clock offset='utc'> > <timer name='...

...s to hook "I have discovered a truly marvelous proof of this, which this margin is too narrow to contain" :-) There is a very long history of different (hardware) issues Marcelo was fighting with and the current code is the survived Frankenstein. E.g. it is very, very unclear what "catchup", "always catchup" and masterclock-less mode in general are and if we still need them. That said I'm all for simplification. I'm not sure if we still need to care about buggy hardware though. > > And I don't see how it's even possible to pass kvmclock correctl...

...s to hook "I have discovered a truly marvelous proof of this, which this margin is too narrow to contain" :-) There is a very long history of different (hardware) issues Marcelo was fighting with and the current code is the survived Frankenstein. E.g. it is very, very unclear what "catchup", "always catchup" and masterclock-less mode in general are and if we still need them. That said I'm all for simplification. I'm not sure if we still need to care about buggy hardware though. > > And I don't see how it's even possible to pass kvmclock correctl...

...v wrote: >> >> There is a very long history of different (hardware) issues Marcelo was >> fighting with and the current code is the survived Frankenstein. > > Right, the code has to handle different TSC modes. > >> E.g. it >> is very, very unclear what "catchup", "always catchup" and >> masterclock-less mode in general are and if we still need them. > > Catchup means handling exposed (to guest) TSC frequency smaller than > HW TSC frequency. > > That is "frankenstein" code, could be removed. > >> That...

...v wrote: >> >> There is a very long history of different (hardware) issues Marcelo was >> fighting with and the current code is the survived Frankenstein. > > Right, the code has to handle different TSC modes. > >> E.g. it >> is very, very unclear what "catchup", "always catchup" and >> masterclock-less mode in general are and if we still need them. > > Catchup means handling exposed (to guest) TSC frequency smaller than > HW TSC frequency. > > That is "frankenstein" code, could be removed. > >> That...

Last night it seemed like the mailing list was playing catchup, as I got a flood of emails from the past few days. Has anyone else seen this? -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/2...

...n is > too narrow to contain" :-) > > There is a very long history of different (hardware) issues Marcelo was > fighting with and the current code is the survived Frankenstein. Right, the code has to handle different TSC modes. > E.g. it > is very, very unclear what "catchup", "always catchup" and > masterclock-less mode in general are and if we still need them. Catchup means handling exposed (to guest) TSC frequency smaller than HW TSC frequency. That is "frankenstein" code, could be removed. > That said I'm all for simplification...

...;feature policy='require' name='ds_cpl'/> <feature policy='require' name='xtpr'/> <feature policy='require' name='acpi'/> </cpu> <clock offset='localtime'> <timer name='rtc' tickpolicy='catchup' track='guest'> <catchup threshold='123' slew='120'/> </timer> <timer name='pit' tickpolicy='delay'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <o...

...he Pi skyrockets once the replication starts and I end up with thousands of double ups of all the mails ... which defeats the entire point of the process. If I do an identical configuration but on a third Gentoo x86_64 VM locally it all works as expected. No double ups of mails and the "catchup" between the two devices is practically instant. Same filesystem even. The only difference appears to be the system architecture. So main my question is this. Is there a known architecture/endian limitation on replication? I guess cross-arch replication is not something many people tr...

...allback='allow'/> > <topology sockets='2' cores='1' threads='1'/> > </cpu> > <clock offset='utc'> > <timer name='pit' tickpolicy='delay'/> > <timer name='rtc' tickpolicy='catchup'/> > <timer name='hpet' present='no'/> > </clock> > <on_poweroff>destroy</on_poweroff> > <on_reboot>restart</on_reboot> > <on_crash>destroy</on_crash> > <devices> > <emulator>/u...

.../> <smbios mode="sysinfo"/> </os> <features> <acpi/> <apic/> </features> <clock offset="utc"> <timer name="pit" tickpolicy="delay"/> <timer name="rtc" tickpolicy="catchup"/> </clock> <cpu mode="host-model" match="exact"/> <devices> <disk type="file" device="disk"> <driver name="qemu" type="qcow2" cache="none"/> <source file="/data...

...e='custom' match='exact'> <model fallback='allow'>cpu64-rhel6</model> <topology sockets='2' cores='2' threads='2'/> </cpu> <clock offset='localtime'> <timer name='rtc' tickpolicy='catchup'/> <timer name='pit' tickpolicy='delay'/> <timer name='hpet' present='no'/> <timer name='hypervclock' present='yes'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart<...

...es> <acpi/> <apic/> <pae/> </features> <cpu mode="custom" match="exact"> <model>SandyBridge</model> </cpu> <clock offset="utc"> <timer name="rtc" tickpolicy="catchup"/> <timer name="pit" tickpolicy="delay"/> <timer name="hpet" present="no"/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>destroy</on_reboot> <on_crash>destroy</on_crash...

...iscovered a truly marvelous proof of this, which this margin is > too narrow to contain" :-) > > There is a very long history of different (hardware) issues Marcelo was > fighting with and the current code is the survived Frankenstein. E.g. it > is very, very unclear what "catchup", "always catchup" and > masterclock-less mode in general are and if we still need them. > > That said I'm all for simplification. I'm not sure if we still need to > care about buggy hardware though. > >> >> And I don't see how it's even...

...;feature policy='require' name='ds_cpl'/> <feature policy='require' name='xtpr'/> <feature policy='require' name='acpi'/> </cpu> <clock offset='localtime'> <timer name='rtc' tickpolicy='catchup' track='guest'> <catchup threshold='123' slew='120'/> </timer> <timer name='pit' tickpolicy='delay'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <o...

...<apic/> > <pae/> > </features> > <cpu mode="custom" match="exact"> > <model>SandyBridge</model> > </cpu> > <clock offset="utc"> > <timer name="rtc" tickpolicy="catchup"/> > <timer name="pit" tickpolicy="delay"/> > <timer name="hpet" present="no"/> > </clock> > <on_poweroff>destroy</on_poweroff> > <on_reboot>destroy</on_reboot> > <on_crash...

Thanks for your interest. Here are the dir/files permissions for the kvmimages dir: # ls -ld /home /home/kvmimages /home/kvmimages/* drwxr-xr-x. 4 root root 4096 14 juin 23:05 /home drwxrwxrwx 2 root root 4096 15 juin 09:19 /home/kvmimages -rw-rw-rwx 1 root root 12884901888 14 juin 23:07 /home/kvmimages/eff1.img -rw-rw-rwx 1 root root 12884901888 14 juin 23:11

...dev/vda console=tty0 console=ttyS0</cmdline> </os> <features> <acpi/> <apic/> </features> <clock offset="utc"> <timer name="pit" tickpolicy="delay"/> <timer name="rtc" tickpolicy="catchup"/> </clock> <devices> <disk type="file" device="disk"> <driver name="qemu" type="qcow2" cache="none"/> <source file="/opt/stack/data/nova/instances/d9f007b9-584f-41c8-a706-e096f354575b/disk...