date:20080530

Re: [libvirt] [PATCH 1/4] lxc: validate tty pid before kill()

2008-05-30 Thread Daniel Veillard

On Thu, May 29, 2008 at 03:20:05PM -0700, Dave Leskovec wrote:
 This patch adds a check of the tty forwarding process pid before kill()'ing it
 when destroying a domain.  If the pid value stored in the the vm structure is
 invalid, sending a SIGKILL may be very bad if the value in question is 
 something
 like -1 (which just happens to be it's initial value).

  Sanity test looks fine to me, sure, +1

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard  | virtualization library  http://libvirt.org/
[EMAIL PROTECTED]  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 4/4] lxc: store tty pid

2008-05-30 Thread Daniel Veillard

On Thu, May 29, 2008 at 03:44:24PM -0700, Dave Leskovec wrote:
 er, this time with the patch
 
 Dave Leskovec wrote:
  This patch will use a file in the lxc configuration directory to store the 
  tty
  forwarding process pid.  The pid is stored after the process is fork()'d.  
  It's
  loaded during startup when the config for a running container is loaded.  
  The
  file is deleted when the domain is undefined.  This should avoid losing 
  the
  tty pid over a libvirtd restart.
  

 the idea sounds fine,

 Index: b/src/lxc_driver.c
 ===
 --- a/src/lxc_driver.c2008-05-29 14:34:45.0 -0700
 +++ b/src/lxc_driver.c2008-05-29 14:34:51.0 -0700
 @@ -328,6 +328,8 @@
  
  vm-configFile[0] = '\0';
  
 +lxcDeleteTtyPid(vm);
 +
  lxcRemoveInactiveVM(driver, vm);
  
  return 0;
 @@ -798,6 +800,10 @@
  lxcTtyForward(vm-parentTty, vm-containerTtyFd);
  }
  
 +if (lxcStoreTtyPid(driver, vm)) {
 +DEBUG0(unable to store tty pid);
 +}
 +
  close(vm-parentTty);
  close(vm-containerTtyFd);

  Hum, I'm surprized the PID file is removed only in lxcDomainUndefine.
The PID file need to be re-created each time the domain is started. But
a domain could be started and stopped many time while being defined,
what happen in a (define/start/stop/start) sequence ? Looks to me the
O_CREAT flag in the second start would break because the PID file is still
here ...

  Maybe I'm just wrong but if you could just double check that scenario before
the commit, that would be nice :-)

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard  | virtualization library  http://libvirt.org/
[EMAIL PROTECTED]  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] Re: AW: AW: [et-mgmt-tools] ocaml-libvirt-0.4.0.1: Can't connect toXen-Host

2008-05-30 Thread Atsushi SAKAI

Hi, Guenter

If you want to avoid TLS.
Please try xen+tcp://x
In this case, I will recommend to use IPsec.

P.S.
libvirt default connection is using TLS.
On Windows, it supports TLS and tcp only.

Thanks
Atsushi SAKAI


Feichtinger G

\xBE 
\xBE 
\xBE \xBE 幔邵 續㍾芻庾捃闌鶚硼棱竇鸚鱚粫癆勉闕 
\xBE \xBE 檮瘟踉鏈續㍾芻庾捃闌鶚硼棱竇鸚鱚粫癆勉闕\xDD 附 装胄鱇\xE7 涬\xEE 藻齦鼈\xE9 啻冒\xC9
\xBE \xBE 賠黼鈔續\xBA 汝繪懲膃 外\xAE 浴\xE9 屋宛 姐佐\xB2
\xBE \xBE 綜\xBA 薙粹鱇ጛ蜴楨 浴釶艱辣銓 夬闌\xF3
\xBE \xBE 代揥繙羣 吶\xBA 宋\xBA 桿庾辯逕\xAD捃闌黥 閭瘢讚跚磑蜥庾握堪握浦 秩逾\xF4 
\xBE \xBE 竢銕繝\xF4 捃 懊遶被齡
\xBE \xBE 
\xBE \xBE 皮\xAC 舶緕扖\xF2
\xBE \xBE 
\xBE \xBE 俾縺黼 黼\xE5 肬跛阯蜴\xE7 鞜艱\xAE
\xBE \xBE 蔗捥痕妒蛯海鶯卡鱧娣纃阡絎蔗迪
\xBE \xBE 壽\xE5 黼笏蜿\xEE 閹 ∅緕纈癆蜴\xE7 毀\xD3 竇鶯蜀蜒癆纉\xA2
\xBE \xBE 瘤齬纈\xF3 籙㗄 髟纉拄闔\xAE
\xBE 
\xBE 蕪 抅纈\xE5 瘤\xF9 竟齠蛯蛹蜚\xF9 捃 椵\xE5 蜚 犾抅阨\xF4 竇鶯蜀蜒癆纉\xBF
\xBE 
\xBE \xBE 
\xBE \xBE 豫哺
\xBE \xBE 麗\xF7 \xC9 鱚瘡蝴繖\xAE
\xBE \xBE 閭瘢讚跚磑蜥\xF4 鼈阨趙 矼 粡黹椵黼\xE4 闔 跚磑蜥\xF4 楊\xAE
\xBE \xBE 蔗捥鷓嘆玦潾鱚粫癆勉闕妤瘟跋瘤妒蜩拄鈕鎭跚磑蜥㈹蜩\xF4
\xBE 
\xBE 峐癨\xAC \xC9  竏瘤艱 捃 抅\xE5 跚磑蜥\xF4 楊佈\xAE
\xBE 
\xBE 
\xBE 壽瘤謫\xAC
\xBE 舶緕扖\xF2
\xBE 
\xBE \xBE 
\xBE \xBE 壽瘤謫
\xBE \xBE 藻齦鼈\xE9 啻冒\xC9
\xBE \xBE 
\xBE \xBE 
\xBE \xBE 薙蜒蔗蜴艱\xF2 \xC7
\xBE \xBE 
\xBE \xBE \xBE 
\xBE \xBE \xBE \xBE 幔邵 續㍾芻庾捃闌鶚硼棱竇鸚鱚粫癆勉闕 
\xBE \xBE \xBE \xBE 檮瘟踉鏈續㍾芻庾捃闌鶚硼棱竇鸚鱚粫癆勉闕\xDD 附 装胄鱇\xE7 涬\xEE 藻齦鼈\xE9 
\xBE \xBE \xBE \xBE 啻冒\xC9
\xBE \xBE \xBE \xBE 賠黼鈔續\xBA 汝繪懲膃 外\xAE 浴\xE9 屋宛 扱艮\xB6
\xBE \xBE \xBE \xBE 綜\xBA 薙粹鱇ጛ蜴楨 浴釶艱辣銓 夬闌\xF3
\xBE \xBE \xBE \xBE 代揥繙羣 吶\xBA 桿庾辯逕\xAD捃闌黥 閭瘢讚跚磑蜥庾握堪握浦 秩逾\xF4 
\xBE \xBE 竢銕繝\xF4 捃 
\xBE \xBE \xBE \xBE 懊遶 被齡
\xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE 斐跛鍖
\xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE   搶\xF5 鼈阨趙 頤\xF4 闔 瑭姐 肅跂\xF3 捃 抅癆 鞜抅\xAE
\xBE \xBE \xBE 
\xBE \xBE \xBE 彦\xED 齒鴪磲 \xC9 粹逾\xF4 謗阯 犛癆 瑭姐 肅跂\xF3 辣瘤鶤
\xBE \xBE \xBE 
\xBE \xBE \xBE 壽瘤謫\xAC
\xBE \xBE \xBE 舶緕扖\xF2
\xBE \xBE \xBE 
\xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE 壽瘤謫
\xBE \xBE \xBE \xBE 藻齦鼈\xE9 啻冒\xC9
\xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE 薙蜒蔗蜴艱\xF2 \xC7
\xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE 斐跛\xEF 咏竏癇筱
\xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE \xC9 蜴揭懲跛繖 抅\xE5 閭瘢讚跚磑蜥庾握堪握窺纔\xE5 闔 羊\xAD 帷齡\xE1
\xBE \xBE \xBE \xBE 犾抅阨\xF4 頏閧跂逑\xAE
\xBE \xBE \xBE \xBE \xBE 糟齒 抅\xE5 海鶯㏍揥谺纔\xE5 齡癇揭 犾抅阨\xF4 頏閧跂逑\xAE
\xBE \xBE \xBE \xBE \xBE 濯\xF4 犛緕 \xC9 揥\xF9 捃 竢銕繝\xF4 捃 \xE1 懊遶被齡 \xC9 艱\xF4 
抅\xE5 辣齠瘍纉\xBA 
\xBE \xBE \xBE \xBE \xBE 跚磑蜥\xBA 吶迴扖 纈鳫\xF2 \xBA 秩銕阡 痺竇齠 蛋 竇鶯蜀蜒癆\xE5 
\xBE \xBE \xBE \xBE \xBE ⎿痕逑粔嘎佖妒閭瘡壠戾姝謇圡
\xBE \xBE \xBE \xBE \xBE 鮮竅竇鶯卣纃Ш 麗 齦竏 肅跂 闥 粡鱚笏闥\xF9 ┣\xA9
\xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE 俾縺黼 矼 齒 謇鈔 瘤\xE4 蒹跟\xAE
\xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE 吶艨鰾\xAC
\xBE \xBE \xBE \xBE \xBE \xC7
\xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE \xAA 汝闕\xBA ⊖蜒葹鰾 廴柚 倣鈬鵞 酒褊鈬\xF3 鱚粫癆 竢躱
\xBE \xBE \xBE \xBE \xBE \xAA 夬\xBA 薙粹鱇ጛ蜴楨 浴釶艱辣銓 夬闌\xF3 弱庾辯逕\xAD捃闌\xF3 
\xBE \xBE 鱚粫癆 竢躱
\xBE \xBE \xBE \xBE \xBE \xAA 囎礪繝彅 桿庾辯逕\xAD捃闌黥 匂篋 話瘢\xEC 砠鈔蜴苴 \xAD
\xBE \xBE \xBE \xBE 怏鈔阯\xF3 蜴齡瘡跂\xF2
\xBE \xBE \xBE \xBE \xBE \xAA 鶴扖\xBA 奕絳 宛 捕\xEE 屋宛 臼艮減街 ə旭\xB0
\xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE 莱艾\xF4 蜴扖鱚齡 齒辣 鞳關跂 闔 抅蜩 跚齡 佈\xAE
\xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE ⑬\xAD 代芍\xEE 羅齠瘍\xE5 ⑬\xAD
\xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE \xAA 汝闕\xBA ⊖蜒葹鰾 廴柚 倣鈬鵞 酒褊鈬\xF3 鱚粫癆 竢躱
\xBE \xBE \xBE \xBE \xBE \xAA 夬\xBA 跚磑蜥㈹蜩\xF4 殊蛯海鬮跚齡 鱚粫癆 竢躱
\xBE \xBE \xBE \xBE \xBE \xAA 囎礪繝彅 枳蛯海鰥 話瘢\xEC 砠鈔蜴苴 \xAD 怏鈔阯\xF3 
蜴齡瘡跂\xF2
\xBE \xBE \xBE \xBE \xBE \xAA 鶴扖\xBA 奕絳 宛 捕\xEE 屋宛 臼艮戯厩 ə旭\xB0
\xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE 壽蜩 蜩 \xE1 怏鈔阯\xF3 蜴齡瘡跂\xF2 肬\xF2 抅\xE5 話瘢\xEC 
跚磑蜥\xF4
\xBE \xBE \xBE \xBE 砠鈔蜴苴 瘤\xE4 頏閾鱇逑\xBA
\xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE 蔗捥痕妒蛯海鶯卡鱧婧阨鱆纉姒竅迪姒竅迪㈹蛯海鶯⑯佾佖佟勐皪
\xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE 膚 齒辣闔\xE5 葹\xF3 \xE1 ⋚蜥芍逾 怏鈔阯\xF3 齷齡纃 瘤\xE4 竢棭\xE4 
扖齡
\xBE \xBE \xBE \xBE 抅癆 抅\xE5 痰阮\xE5 蜴齡瘡跂\xF2 猪鳬鵺 鞜鶯蜒棭癇踟 肬\xF2 怏鈔阯\xF3 
\xBE \xBE \xBC 帷齡\xE1 瘤\xE4 
\xBE \xBE \xBE \xBE 肬\xF2 怏鈔阯\xF3 犛蜒\xE8 葹\xF3 鈿\xF4 葹\xE4 瘤\xF9 敗鋒莱酣\xD7 
粤洹跫齏緕\xF4 捃闌\xF3 
\xBE \xBE \xBE \xBE 蜴齡瘡跂筮 曹阨\xF4 弘\xA5 閹 抅\xE5 皷芾 閹 抅\xE5 蜴齡瘡跂\xF2 蜩 粹猨 
\xBE \xBE 捃 抅\xE5 敗\xCB 
\xBE \xBE \xBE \xBE 通約 瘤\xE4 竢鈕蜃㗄癆蜿\xEE 肅跂\xF3 犛蜒\xE8 鈬繖 捃 矼 竅鴪蜈\xE4 瘡闔\xE7 捃 
\xBE \xBE \xBE \xBE 齦韶闥\xF4 抅\xE5 敗\xCB 苒瘰蓍竅\xEC 頏閾鱇\xED ㊷蜥\xF4 衷銓鳫讒\xAE 部ヸ 
\xBE \xBE 竟齠蛯跂 抅癆 
\xBE \xBE \xBE \xBE \xC9 葹洹逾\xF4 韭痺繖 抅\xE5 敗\xCB 肅跂\xF3 蜴 纔痺挊\xF9 抅\xE5 鱸艾\xF4 
韭痺絳 齒 
\xBE \xBE \xBE \xBE 蜴齡縺\xE4 蜚 蜩 椵蜴\xE7 逋 阯\xEE 敗\xCB 粤洹跫齏緕\xF4 緕海鳫鉈緕廊
\xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE 噬鱚緕鼈阡\xF3 鼈阯蜴\xE7 抅\xE5 蜴齡瘡跂\xF2 蜴 痺拄闔\xBA
\xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE 蔗捥痕壒銕纔蛛卡鱧婭逅媄蜴蜴齡瘡跂鬮鵜粤鼡捃隰韲\xE7
\xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE   偵鼡捃隱 鈿抅蜴\xE7 蜴齡瘡跂筱 鼈阯蜴\xE7 抅\xE5 蜴齡瘡跂\xF2 蜒闔\xAE
\xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE 蔗捥痕壒銕纔蛛卡鱧婭逅媄蜴蜴齡瘡跂鬮沖鞜站瘍纉卣鈑
\xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE   也齡 閹

RE: [libvirt] ocaml-libvirt-0.4.0.1: Can'tconnect toXen-Host

2008-05-30 Thread Feichtinger Günter

Hi Atushi,

thanks for your prompt answer.
Now I get the Error: libvir: Remote error : Unknown error :-(

Regards,
Guenter

 Von: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] Im Auftrag von Atsushi SAKAI
 Gesendet: Freitag, 30. Mai 2008 10:31
 An: libvir-list@redhat.com
 Betreff: [libvirt] Re: AW: AW: [et-mgmt-tools] 
 ocaml-libvirt-0.4.0.1: Can'tconnect toXen-Host
 
 Hi, Guenter
 
 If you want to avoid TLS.
 Please try xen+tcp://x
 In this case, I will recommend to use IPsec.
 
 P.S.
 libvirt default connection is using TLS.
 On Windows, it supports TLS and tcp only.
 
 Thanks
 Atsushi SAKAI
 
 
 Feichtinger G
 
  
  
   Von: [EMAIL PROTECTED] 
   [mailto:[EMAIL PROTECTED] Im Auftrag von Atsushi 
   SAKAI
   Gesendet: Freitag, 30. Mai 2008 09:42
   An: Fedora/Linux Management Tools
   Betreff: Re: AW: [et-mgmt-tools] ocaml-libvirt-0.4.0.1: Can't 
   connect to Xen-Host
   
   Hi, Guenter
   
   Please see following page.
   http://libvirt.org/remote.html
   The section of Generating TLS certificates
   answers your question.
  
  Is there any possibility to use it without certificates?
  
   
   P.S.
   Now I realized.
   ocaml-libvirt should be discussed on libvirt ML.
   https://www.redhat.com/mailman/listinfo/libvir-list
  
  Okay, I  change to the libvirt ML...
  
  
  Thanks,
  Guenter
  
   
   Thanks
   Atsushi SAKAI
   
   
   Feichtinger G
   

 Von: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] Im Auftrag 
 von Atsushi 
 SAKAI
 Gesendet: Freitag, 30. Mai 2008 07:16
 An: Fedora/Linux Management Tools
 Betreff: Re: [et-mgmt-tools] ocaml-libvirt-0.4.0.1: Can't
   connect to
 Xen- Host
 
 Hello,
 
   You should put on x509 files to that path.

I'm sorry, I don't know what x509 files means.

Thanks,
Guenter

 
 Thanks
 Atsushi SAKAI
 
 Feichtinger G
 
  Hello Richard,
  
  I intstalled the ocaml-libvirt-0.4.0.1.exe on MS- Vista
 without problems.
  Also the virt-ctrl.exe starts without problems.
  But when I try to connect to a Xen-Host I get the messages: 
  libvir: Remote error : Cannot access CA certificate 
  'C:/msys/1.0/local/etc/pki/C
  A/cacert.pem': No such file or directory (2)
  
  Please be so kind and help.
  
  
  Regard,
  G
  
  
  
  
  
  
  * From: Richard W.M. Jones rjones redhat com
  * To: Fedora/Linux Management Tools et-mgmt-tools
   redhat com
  * Subject: [et-mgmt-tools] Fwd: OCaml bindings -
 Windows installer
  * Date: Tue, 08 Jan 2008 11:18:39 +
  
  Might interest some people on this list ...
  
  --- Begin Message ---
  
  * From: Richard W.M. Jones rjones redhat com
  * To: libvir-list libvir-list redhat com
  * Subject: [Libvir] OCaml bindings - 
 Windows installer
  * Date: Tue, 08 Jan 2008 11:15:19 +
  
  This is a Windows installer for the OCaml libvirt
 bindings and programs:
  
  
 http://libvirt.org/sources/ocaml/ocaml-libvirt-0.4.0.1.exe
  
  If someone has a 'virgin' Windows system and could test
 that the above installer works, particularly for Windows
Vista and
 for Windows which has not had any GTK/MinGW development tools 
 installed. About 90% of the size of the installer is down
   to the GTK
 DLLs and configuration files which need to be carried 
 along to 
 support the GTK graphical program (Virt Control). It's
   possible that
 I haven't placed the GTK files in exactly the right place, so 
 instead it is using my own GTK development environment.
  
  Screenshots showing the installer in action:
  
  http://annexia.org/tmp/wininstaller-1-desktop.png
  
Desktop, nothing installed, showing the 
 installer icon.
  
  http://annexia.org/tmp/wininstaller-2-packages.png
  
List of required, recommended and optional 
 subpackages.
  
  http://annexia.org/tmp/wininstaller-3-instpath.png
  
Select the installation path.
  
  http://annexia.org/tmp/wininstaller-4-installdone.png
  
Install complete.  Notice the desktop icons, ...
  
  http://annexia.org/tmp/wininstaller-5-menu.png
  
... and the menu entries and uninstaller program.
  
  http://annexia.org/tmp/wininstaller-6-virtctrl.png
  
Running Virt Control.
  
  http://annexia.org/tmp/wininstaller-7-uninstall.png
  
After uninstall.  Notice that the desktop 
 icons have gone.
  
  
  The installer uses NSIS (the Nullsoft Scriptable
 Install System, http://nsis.sf.net/) and is reasonably well 
 integrated into the autoconf / make build system. In
   particular if
 you are compiling under Windows and NSIS is

[libvirt] [PATCH] Add error message when the invalid XML file is defined.

2008-05-30 Thread Hiroyuki Kaguchi

Hi,

When cpuset that is the attribute of vcpu tag of the XML file is the invalid
string, virsh define succeeds.
(Ex. vcpu cpuset='aaa'4/vcpu
 vcpu cpuset=' '4/vcpu
 vcpu cpuset=',,,'4/vcpu )
The patch changes policy that the definition is failed and shows error message.

Thanks,
Signed-off-by: Hiroyuki Kaguchi [EMAIL PROTECTED]

Index: src/xm_internal.c
===
RCS file: /data/cvs/libvirt/src/xm_internal.c,v
retrieving revision 1.79
diff -u -p -r1.79 xm_internal.c
--- src/xm_internal.c   29 May 2008 19:20:23 -  1.79
+++ src/xm_internal.c   30 May 2008 05:27:35 -
@@ -2004,20 +2004,15 @@ virConfPtr xenXMParseXMLToConfig(virConn
 char *ranges;

 ranges = virConvertCpuSet(conn, cpus, 0);
-if (ranges != NULL) {
-VIR_FREE(cpus);
-if (xenXMConfigSetString(conf, cpus, ranges)  0) {
-VIR_FREE(ranges);
-goto error;
-}
+VIR_FREE(cpus);
+if (ranges == NULL) {
+goto error;
+}
+if (xenXMConfigSetString(conf, cpus, ranges)  0) {
 VIR_FREE(ranges);
-} else {
-if (xenXMConfigSetString(conf, cpus, cpus)  0) {
-VIR_FREE(cpus);
-goto error;
-}
-VIR_FREE(cpus);
+goto error;
 }
+VIR_FREE(ranges);
 }

 obj = xmlXPathEval(BAD_CAST string(/domain/os/type), ctxt);

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 4/4] lxc: store tty pid

2008-05-30 Thread Jim Meyering

Hi Dave,

All four of your patches look good.
I've included a few comments on the fourth below.

Dave Leskovec [EMAIL PROTECTED] wrote:
 Index: b/src/lxc_conf.h
 ===
...
 +int lxcStoreTtyPid(lxc_driver_t *driver, lxc_vm_t *vm);
 +int lxcLoadTtyPid(lxc_driver_t *driver, lxc_vm_t *vm);
 +int lxcDeleteTtyPid(lxc_vm_t *vm);

It looks like each of the above pointer parameters
may/should be const.

Renaming lxcDeleteTtyPid to lxcDeleteTtyPidFile would make it
clear that it deletes the file, not the PID.

 Index: b/src/lxc_conf.c
 ===
...
 +int lxcStoreTtyPid(lxc_driver_t *driver, lxc_vm_t *vm)
 +{
 +int rc = -1;
 +int fd = -1;

There is no need to initialize fd here.

 +FILE *file = NULL;
 +
 +if (vm-ttyPidFile[0] == 0x00) {
 +if (virFileBuildPath(driver-configDir, vm-def-name, .pid,
 + vm-ttyPidFile, PATH_MAX)  0) {
 +lxcError(NULL, NULL, VIR_ERR_INTERNAL_ERROR,
...

 +int lxcDeleteTtyPid(lxc_vm_t *vm)
 +{
 +if (vm-ttyPidFile[0] == 0x00) {
 +goto no_file;
 +}
 +
 +if (unlink(vm-ttyPidFile)  0) {
 +lxcError(NULL, NULL, VIR_ERR_INTERNAL_ERROR,
 + _(cannot remove ttyPidFile %s), vm-ttyPidFile);

Please include strerror(errno) in the diagnostic,
as you've done for other failed sys/lib calls.

Do you want to give a diagnostic even for ENOENT?

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] ocaml-libvirt-0.4.0.1: Can'tconnect toXen-Host

2008-05-30 Thread Atsushi SAKAI

Hi, Gunter

It seems [EMAIL PROTECTED] fails on getaddrinfo().
Is that correct URL?

By the way,
It seems need to use gdb or compiling to get more information of trouble.

Thanks
Atsushi SAKAI





Feichtinger G

\xBE 皮 藻椵蓍\xAC
\xBE 
\xBE 抅瘤謫 肬\xF2 籙㗄 頏闕頸 瘤齬纈\xAE
\xBE 麗\xF7 \xC9 艱\xF4 抅\xE5 湯鳫鮑 跚磑蜥\xBA ⊖纃阡\xE5 纈鳫\xF2 \xBA 寰謗阯\xEE 纈鳫鬆 梱\xA8
\xBE 
\xBE 吶艨鰾鵺
\xBE 舶緕扖\xF2
\xBE 
\xBE \xBE 幔邵 跚磑蜥㈹蜩庾硼棱竇鸚鱚粫癆勉闕 
\xBE \xBE 檮瘟踉鏈跚磑蜥㈹蜩庾硼棱竇鸚鱚粫癆勉闕\xDD 附 装胄鱇\xE7 涬\xEE 藻齦鼈\xE9 啻冒\xC9
\xBE \xBE 賠黼鈔續\xBA 汝繪懲膃 外\xAE 浴\xE9 屋宛 碓些\xB1
\xBE \xBE 綜\xBA 跚磑蜥㈹蜩徉鱚粫癆勉闕
\xBE \xBE 代揥繙羣 梃蛯海鶯\xDD 吶\xBA 宋\xBA 宋\xBA 桿庾辯逕\xAD捃闌黥 
\xBE \xBE 閭瘢讚跚磑蜥庾握堪握浦 秩逾戾闔鈬笏 捃懊遶被齡
\xBE \xBE 
\xBE \xBE 皮\xAC 舶緕扖\xF2
\xBE \xBE 
\xBE \xBE 膚 籙\xF5 燾銓 捃 癘濶\xE4 毀哺
\xBE \xBE 俾縺黼 揥\xF9 皪遨戾雕嘆睺睺\xF8
\xBE \xBE 侮 抅蜩 竅黼\xAC \xC9 犾跛 鱚竢迯緕\xE4 捃 椵\xE5 賓黼祟
\xBE \xBE 
\xBE \xBE 豫哺
\xBE \xBE 跚磑蜥\xF4 粤聲棭\xF4 竢銕繝拄闔 蜩 椵蜴\xE7 毀哺
\xBE \xBE Ḵ 怏鈔阯鵺 蜚 齦韶闥揭 毀\xD3 瘤\xE4 戾\xF0 闔踟\xAE
\xBE \xBE 
\xBE \xBE 壽瘤謫
\xBE \xBE 藻齦鼈\xE9 啻冒\xC9
\xBE \xBE 
\xBE \xBE 
\xBE \xBE 薙蜒蔗蜴艱\xF2 \xC7
\xBE \xBE 
\xBE \xBE \xBE 
\xBE \xBE \xBE 
\xBE \xBE \xBE \xBE 幔邵 續㍾芻庾捃闌鶚硼棱竇鸚鱚粫癆勉闕 
\xBE \xBE \xBE \xBE 檮瘟踉鏈續㍾芻庾捃闌鶚硼棱竇鸚鱚粫癆勉闕\xDD 附 装胄鱇\xE7 涬\xEE 藻齦鼈\xE9 
\xBE \xBE \xBE \xBE 啻冒\xC9
\xBE \xBE \xBE \xBE 賠黼鈔續\xBA 汝繪懲膃 外\xAE 浴\xE9 屋宛 姐佐\xB2
\xBE \xBE \xBE \xBE 綜\xBA 薙粹鱇ጛ蜴楨 浴釶艱辣銓 夬闌\xF3
\xBE \xBE \xBE \xBE 代揥繙羣 吶\xBA 宋\xBA 桿庾辯逕\xAD捃闌黥 閭瘢讚跚磑蜥庾握堪握浦 秩逾\xF4 
\xBE \xBE \xBE \xBE 竢銕繝\xF4 捃 懊遶被齡
\xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE 皮\xAC 舶緕扖\xF2
\xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE 俾縺黼 黼\xE5 肬跛阯蜴\xE7 鞜艱\xAE
\xBE \xBE \xBE \xBE 蔗捥痕妒蛯海鶯卡鱧娣纃阡絎蔗迪
\xBE \xBE \xBE \xBE 壽\xE5 黼笏蜿\xEE 閹 ∅緕纈癆蜴\xE7 毀\xD3 竇鶯蜀蜒癆纉\xA2
\xBE \xBE \xBE \xBE 瘤齬纈\xF3 籙㗄 髟纉拄闔\xAE
\xBE \xBE \xBE 
\xBE \xBE \xBE 蕪 抅纈\xE5 瘤\xF9 竟齠蛯蛹蜚\xF9 捃 椵\xE5 蜚 犾抅阨\xF4 竇鶯蜀蜒癆纉\xBF
\xBE \xBE \xBE 
\xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE 豫哺
\xBE \xBE \xBE \xBE 麗\xF7 \xC9 鱚瘡蝴繖\xAE
\xBE \xBE \xBE \xBE 閭瘢讚跚磑蜥\xF4 鼈阨趙 矼 粡黹椵黼\xE4 闔 跚磑蜥\xF4 楊\xAE
\xBE \xBE \xBE \xBE 蔗捥鷓嘆玦潾鱚粫癆勉闕妤瘟跋瘤妒蜩拄鈕鎭跚磑蜥㈹蜩\xF4
\xBE \xBE \xBE 
\xBE \xBE \xBE 峐癨\xAC \xC9  竏瘤艱 捃 抅\xE5 跚磑蜥\xF4 楊佈\xAE
\xBE \xBE \xBE 
\xBE \xBE \xBE 
\xBE \xBE \xBE 壽瘤謫\xAC
\xBE \xBE \xBE 舶緕扖\xF2
\xBE \xBE \xBE 
\xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE 壽瘤謫
\xBE \xBE \xBE \xBE 藻齦鼈\xE9 啻冒\xC9
\xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE 薙蜒蔗蜴艱\xF2 \xC7
\xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE \xBE 幔邵 續㍾芻庾捃闌鶚硼棱竇鸚鱚粫癆勉闕 
\xBE \xBE \xBE \xBE \xBE \xBE 檮瘟踉鏈續㍾芻庾捃闌鶚硼棱竇鸚鱚粫癆勉闕\xDD 附 装胄鱇\xE7 
\xBE \xBE 涬\xEE 藻齦鼈\xE9 
\xBE \xBE \xBE \xBE \xBE \xBE 啻冒\xC9
\xBE \xBE \xBE \xBE \xBE \xBE 賠黼鈔續\xBA 汝繪懲膃 外\xAE 浴\xE9 屋宛 扱艮\xB6
\xBE \xBE \xBE \xBE \xBE \xBE 綜\xBA 薙粹鱇ጛ蜴楨 浴釶艱辣銓 夬闌\xF3
\xBE \xBE \xBE \xBE \xBE \xBE 代揥繙羣 吶\xBA 桿庾辯逕\xAD捃闌黥 閭瘢讚跚磑蜥庾握堪握浦 秩逾\xF4
\xBE \xBE \xBE \xBE 竢銕繝\xF4 捃
\xBE \xBE \xBE \xBE \xBE \xBE 懊遶 被齡
\xBE \xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE \xBE 斐跛鍖
\xBE \xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE \xBE   搶\xF5 鼈阨趙 頤\xF4 闔 瑭姐 肅跂\xF3 捃 抅癆 鞜抅\xAE
\xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE 彦\xED 齒鴪磲 \xC9 粹逾\xF4 謗阯 犛癆 瑭姐 肅跂\xF3 辣瘤鶤
\xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE 壽瘤謫\xAC
\xBE \xBE \xBE \xBE \xBE 舶緕扖\xF2
\xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE \xBE 壽瘤謫
\xBE \xBE \xBE \xBE \xBE \xBE 藻齦鼈\xE9 啻冒\xC9
\xBE \xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE \xBE 薙蜒蔗蜴艱\xF2 \xC7
\xBE \xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE \xBE \xBE 斐跛\xEF 咏竏癇筱
\xBE \xBE \xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE \xBE \xBE \xC9 蜴揭懲跛繖 抅\xE5 閭瘢讚跚磑蜥庾握堪握窺纔\xE5 闔 羊\xAD 
帷齡\xE1
\xBE \xBE \xBE \xBE \xBE \xBE 犾抅阨\xF4 頏閧跂逑\xAE
\xBE \xBE \xBE \xBE \xBE \xBE \xBE 糟齒 抅\xE5 海鶯㏍揥谺纔\xE5 齡癇揭 犾抅阨\xF4 頏閧跂逑\xAE
\xBE \xBE \xBE \xBE \xBE \xBE \xBE 濯\xF4 犛緕 \xC9 揥\xF9 捃 竢銕繝\xF4 捃 \xE1 懊遶被齡 
\xC9 艱\xF4 抅\xE5 辣齠瘍纉\xBA 
\xBE \xBE \xBE \xBE \xBE \xBE \xBE 跚磑蜥\xBA 吶迴扖 纈鳫\xF2 \xBA 秩銕阡 痺竇齠 蛋 竇鶯蜀蜒癆\xE5 
\xBE \xBE \xBE \xBE \xBE \xBE \xBE ⎿痕逑粔嘎佖妒閭瘡壠戾姝謇圡
\xBE \xBE \xBE \xBE \xBE \xBE \xBE 鮮竅竇鶯卣纃Ш 麗 齦竏 肅跂 闥 粡鱚笏闥\xF9 ┣\xA9
\xBE \xBE \xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE \xBE \xBE 俾縺黼 矼 齒 謇鈔 瘤\xE4 蒹跟\xAE
\xBE \xBE \xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE \xBE \xBE 吶艨鰾\xAC
\xBE \xBE \xBE \xBE \xBE \xBE \xBE \xC7
\xBE \xBE \xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE \xBE \xBE \xAA 汝闕\xBA ⊖蜒葹鰾 廴柚 倣鈬鵞 酒褊鈬\xF3 鱚粫癆 竢躱
\xBE \xBE \xBE \xBE \xBE \xBE \xBE \xAA 夬\xBA 薙粹鱇ጛ蜴楨 浴釶艱辣銓 夬闌\xF3 
弱庾辯逕\xAD捃闌\xF3
\xBE \xBE \xBE \xBE 鱚粫癆 竢躱
\xBE \xBE \xBE \xBE \xBE \xBE \xBE \xAA 囎礪繝彅 桿庾辯逕\xAD捃闌黥 匂篋 話瘢\xEC 砠鈔蜴苴 \xAD
\xBE \xBE \xBE \xBE \xBE \xBE 怏鈔阯\xF3 蜴齡瘡跂\xF2
\xBE \xBE \xBE \xBE \xBE \xBE \xBE \xAA 鶴扖\xBA 奕絳 宛 捕\xEE 屋宛 臼艮減街 ə旭\xB0
\xBE \xBE \xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE \xBE \xBE 莱艾\xF4 蜴扖鱚齡 齒辣 鞳關跂 闔 抅蜩 跚齡 佈\xAE
\xBE \xBE \xBE \xBE \xBE \xBE \xBE 
\xBE \xBE \xBE \xBE \xBE \xBE \xBE

AW: [libvirt] ocaml-libvirt-0.4.0.1: Can'tconnect toXen-Host

2008-05-30 Thread Feichtinger Günter

Hi, Atsushi

the URL should be right, but I don't know, if and what I have to configure on 
the Xen-Host.
You see, I'm a Newbie. 

Maybe I should explain what I want to:
I have 3 Xen-Hosts (CentOS 5.1) and use virt-managaer local an this hosts. 
I'm looking for a possibility to manages xen-hosts from MS-Windows-Clients like 
VMWareServerConsole.
So I was looking around and found the port form Richard W.M. Jones of the 
virt-manager. 
If there is an other solution available, it is also fine for me. 
The most important requirement for me is, that I have to run on Windows as a 
stand-alone Applikation. 

Thanks, 
Guenter


 Von: Atsushi SAKAI [mailto:[EMAIL PROTECTED] 
 Gesendet: Freitag, 30. Mai 2008 11:53
 An: Feichtinger Günter
 Cc: libvir-list@redhat.com
 Betreff: Re: [libvirt] ocaml-libvirt-0.4.0.1: Can'tconnect toXen-Host
 
 Hi, Gunter
 
 It seems [EMAIL PROTECTED] fails on getaddrinfo().
 Is that correct URL?
 
 By the way,
 It seems need to use gdb or compiling to get more information 
 of trouble.
 
 Thanks
 Atsushi SAKAI
 
 
 
 
 
 Feichtinger G
 
  Hi Atushi,
  
  thanks for your prompt answer.
  Now I get the Error: libvir: Remote error : Unknown error :-(
  
  Regards,
  Guenter
  
   Von: [EMAIL PROTECTED] 
   [mailto:[EMAIL PROTECTED] Im Auftrag von 
 Atsushi SAKAI
   Gesendet: Freitag, 30. Mai 2008 10:31
   An: libvir-list@redhat.com
   Betreff: [libvirt] Re: AW: AW: [et-mgmt-tools]
   ocaml-libvirt-0.4.0.1: Can'tconnect toXen-Host
   
   Hi, Guenter
   
   If you want to avoid TLS.
   Please try xen+tcp://x
   In this case, I will recommend to use IPsec.
   
   P.S.
   libvirt default connection is using TLS.
   On Windows, it supports TLS and tcp only.
   
   Thanks
   Atsushi SAKAI
   
   
   Feichtinger G
   


 Von: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] Im Auftrag 
 von Atsushi 
 SAKAI
 Gesendet: Freitag, 30. Mai 2008 09:42
 An: Fedora/Linux Management Tools
 Betreff: Re: AW: [et-mgmt-tools] ocaml-libvirt-0.4.0.1: Can't 
 connect to Xen-Host
 
 Hi, Guenter
 
 Please see following page.
 http://libvirt.org/remote.html
 The section of Generating TLS certificates
 answers your question.

Is there any possibility to use it without certificates?

 
 P.S.
 Now I realized.
 ocaml-libvirt should be discussed on libvirt ML.
 https://www.redhat.com/mailman/listinfo/libvir-list

Okay, I  change to the libvirt ML...


Thanks,
Guenter

 
 Thanks
 Atsushi SAKAI
 
 
 Feichtinger G
 
  
   Von: [EMAIL PROTECTED] 
   [mailto:[EMAIL PROTECTED] Im Auftrag
   von Atsushi
   SAKAI
   Gesendet: Freitag, 30. Mai 2008 07:16
   An: Fedora/Linux Management Tools
   Betreff: Re: [et-mgmt-tools] ocaml-libvirt-0.4.0.1: Can't
 connect to
   Xen- Host
   
   Hello,
   
 You should put on x509 files to that path.
  
  I'm sorry, I don't know what x509 files means.
  
  Thanks,
  Guenter
  
   
   Thanks
   Atsushi SAKAI
   
   Feichtinger G
   
Hello Richard,

I intstalled the ocaml-libvirt-0.4.0.1.exe on MS- Vista
   without problems.
Also the virt-ctrl.exe starts without problems.
But when I try to connect to a Xen-Host I get 
 the messages: 
libvir: Remote error : Cannot access CA certificate 
'C:/msys/1.0/local/etc/pki/C
A/cacert.pem': No such file or directory (2)

Please be so kind and help.


Regard,
G






* From: Richard W.M. Jones rjones redhat com
* To: Fedora/Linux Management Tools et-mgmt-tools
 redhat com
* Subject: [et-mgmt-tools] Fwd: OCaml bindings -
   Windows installer
* Date: Tue, 08 Jan 2008 11:18:39 +

Might interest some people on this list ...

--- Begin Message ---

* From: Richard W.M. Jones rjones redhat com
* To: libvir-list libvir-list redhat com
* Subject: [Libvir] OCaml bindings -
   Windows installer
* Date: Tue, 08 Jan 2008 11:15:19 +

This is a Windows installer for the OCaml libvirt
   bindings and programs:


   http://libvirt.org/sources/ocaml/ocaml-libvirt-0.4.0.1.exe

If someone has a 'virgin' Windows system and could 
test
   that the above installer works, particularly for Windows
  Vista and
   for Windows which has not had any GTK/MinGW development 
   tools installed. About 90% of the size of the 
 installer is 
   down
 to the GTK
   DLLs and configuration files which need to be carried
   along to
   support the GTK graphical program (Virt Control). It's
 possible that

Re: [libvirt] [PATCH 4/4] lxc: store tty pid

2008-05-30 Thread Daniel P. Berrange

On Thu, May 29, 2008 at 03:44:24PM -0700, Dave Leskovec wrote:
 er, this time with the patch
 
 Dave Leskovec wrote:
  This patch will use a file in the lxc configuration directory to store the 
  tty
  forwarding process pid.  The pid is stored after the process is fork()'d.  
  It's
  loaded during startup when the config for a running container is loaded.  
  The
  file is deleted when the domain is undefined.  This should avoid losing 
  the
  tty pid over a libvirtd restart.

The PID file should not be put in SYSCONFDIR. Transient state needs to
go in LOCALSTATEDIR - which translates to /var. So /var/lib/libvirt/lxc/

Dan.
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 3/4] lxc: validate container process during load config

2008-05-30 Thread Daniel P. Berrange

On Fri, May 30, 2008 at 02:28:46AM -0400, Daniel Veillard wrote:
 On Thu, May 29, 2008 at 03:20:15PM -0700, Dave Leskovec wrote:
  +if (ESRCH == errno) {
  +rc = 0;
  +DEBUG(pid %d no longer exists, def-id);
  +goto done;
  +}
  +
  +lxcError(NULL, NULL, VIR_ERR_INTERNAL_ERROR,
  + _(error checking container process: %d %s),
  + def-id, strerror(errno));
  +goto done;
  +}
 
   The problem though is that by doing just  a passive test for the PID
 it feels like there is a possible race if the process counter rolled over and
 another process with the same PID got create in the meantime.
   i have the feeling that a test based on the state of the file descriptors
 used to communicate with the container would be more reliable. Basically if 
 the
 container disapear, then the pipe should get in a half-closed state, 
 detecting the change at that level sounds like it would be more reliable,
 don't you think so ?

Yes, after checking the PID still exists, it needs to validate /proc/$PID/exe
to verify it points to the binary we expect it to.

Regards,
Dan.
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] PATCH: Switch remote daemon to use memory alloc APIs

2008-05-30 Thread Daniel P. Berrange

THis patch switches over the remote daemon to use the memory allocation
APIs. This required exporting the 4 apis in the .so.  I discovered along
the way that none of the remote RPC dispatcher impls checked for malloc
failure, so I've had to add that in too.

 qemud/event.c   |   49 +++
 qemud/mdns.c|   53 ++--
 qemud/qemud.c   |   43 +-
 qemud/remote.c  |  200 ++--
 src/libvirt_sym.version |5 +
 src/memory.c|8 -
 src/memory.h|   16 +--
 7 files changed, 207 insertions(+), 167 deletions(-)

Regards,
Daniel

diff -r 06acc2c5c1fb qemud/event.c
--- a/qemud/event.c Thu May 29 16:05:55 2008 -0400
+++ b/qemud/event.c Fri May 30 10:36:42 2008 -0400
@@ -31,6 +31,7 @@
 
 #include qemud.h
 #include event.h
+#include memory.h
 
 #define EVENT_DEBUG(fmt, ...) qemudDebug(EVENT:  fmt, __VA_ARGS__)
 
@@ -82,16 +83,11 @@
 int virEventAddHandleImpl(int fd, int events, virEventHandleCallback cb, void 
*opaque) {
 EVENT_DEBUG(Add handle %d %d %p %p, fd, events, cb, opaque);
 if (eventLoop.handlesCount == eventLoop.handlesAlloc) {
-struct virEventHandle *tmp;
 EVENT_DEBUG(Used %d handle slots, adding %d more,
 eventLoop.handlesAlloc, EVENT_ALLOC_EXTENT);
-tmp = realloc(eventLoop.handles,
-  sizeof(struct virEventHandle) *
-  (eventLoop.handlesAlloc + EVENT_ALLOC_EXTENT));
-if (!tmp) {
+if (VIR_REALLOC_N(eventLoop.handles,
+  (eventLoop.handlesAlloc + EVENT_ALLOC_EXTENT))  0)
 return -1;
-}
-eventLoop.handles = tmp;
 eventLoop.handlesAlloc += EVENT_ALLOC_EXTENT;
 }
 
@@ -152,16 +148,11 @@
 }
 
 if (eventLoop.timeoutsCount == eventLoop.timeoutsAlloc) {
-struct virEventTimeout *tmp;
 EVENT_DEBUG(Used %d timeout slots, adding %d more,
 eventLoop.timeoutsAlloc, EVENT_ALLOC_EXTENT);
-tmp = realloc(eventLoop.timeouts,
-  sizeof(struct virEventTimeout) *
-  (eventLoop.timeoutsAlloc + EVENT_ALLOC_EXTENT));
-if (!tmp) {
+if (VIR_REALLOC_N(eventLoop.timeouts,
+  (eventLoop.timeoutsAlloc + EVENT_ALLOC_EXTENT))  0)
 return -1;
-}
-eventLoop.timeouts = tmp;
 eventLoop.timeoutsAlloc += EVENT_ALLOC_EXTENT;
 }
 
@@ -281,7 +272,7 @@
 }
 *retfds = NULL;
 /* Setup the poll file handle data structs */
-if (!(fds = malloc(sizeof(*fds) * nfds)))
+if (VIR_ALLOC_N(fds, nfds)  0)
 return -1;
 
 for (i = 0, nfds = 0 ; i  eventLoop.handlesCount ; i++) {
@@ -398,16 +389,11 @@
 
 /* Release some memory if we've got a big chunk free */
 if ((eventLoop.timeoutsAlloc - EVENT_ALLOC_EXTENT)  
eventLoop.timeoutsCount) {
-struct virEventTimeout *tmp;
 EVENT_DEBUG(Releasing %d out of %d timeout slots used, releasing %d,
eventLoop.timeoutsCount, eventLoop.timeoutsAlloc, 
EVENT_ALLOC_EXTENT);
-tmp = realloc(eventLoop.timeouts,
-  sizeof(struct virEventTimeout) *
-  (eventLoop.timeoutsAlloc - EVENT_ALLOC_EXTENT));
-if (!tmp) {
+if (VIR_REALLOC_N(eventLoop.timeouts,
+  (eventLoop.timeoutsAlloc - EVENT_ALLOC_EXTENT))  0)
 return -1;
-}
-eventLoop.timeouts = tmp;
 eventLoop.timeoutsAlloc -= EVENT_ALLOC_EXTENT;
 }
 return 0;
@@ -439,16 +425,11 @@
 
 /* Release some memory if we've got a big chunk free */
 if ((eventLoop.handlesAlloc - EVENT_ALLOC_EXTENT)  
eventLoop.handlesCount) {
-struct virEventHandle *tmp;
 EVENT_DEBUG(Releasing %d out of %d handles slots used, releasing %d,
eventLoop.handlesCount, eventLoop.handlesAlloc, 
EVENT_ALLOC_EXTENT);
-tmp = realloc(eventLoop.handles,
-  sizeof(struct virEventHandle) *
-  (eventLoop.handlesAlloc - EVENT_ALLOC_EXTENT));
-if (!tmp) {
+if (VIR_REALLOC_N(eventLoop.handles,
+  (eventLoop.handlesAlloc - EVENT_ALLOC_EXTENT))  0)
 return -1;
-}
-eventLoop.handles = tmp;
 eventLoop.handlesAlloc -= EVENT_ALLOC_EXTENT;
 }
 return 0;
@@ -466,7 +447,7 @@
 return -1;
 
 if (virEventCalculateTimeout(timeout)  0) {
-free(fds);
+VIR_FREE(fds);
 return -1;
 }
 
@@ -478,20 +459,20 @@
 if (errno == EINTR) {
 goto retry;
 }
-free(fds);
+VIR_FREE(fds);
 return -1;
 }
 if (virEventDispatchTimeouts()  0) {
-free(fds);
+VIR_FREE(fds);
 return -1;
 }
 
 if (ret  0 
 virEventDispatchHandles(fds)  0) {
-free(fds);
+VIR_FREE(fds);

Re: [libvirt] PATCH: Switch remote daemon to use memory alloc APIs

2008-05-30 Thread Daniel Veillard

On Fri, May 30, 2008 at 03:37:06PM +0100, Daniel P. Berrange wrote:
 THis patch switches over the remote daemon to use the memory allocation
 APIs. This required exporting the 4 apis in the .so.  I discovered along
 the way that none of the remote RPC dispatcher impls checked for malloc
 failure, so I've had to add that in too.

  Looks fine, this really cleans things up, especially reallocs

  if (getsockname(sock-fd, (struct sockaddr *)(sa), salen)  0)
 -return -1;
 +goto cleanup;
  

  Hum, changes the semantic but it looks like it will avoid leaking 
file descriptors too..

[..]
 +
 +cleanup:
 +for (i = 0; i  nfds; ++i)
 +close(fds[0]);
 +return -1;
[...]
 -if (ret-freeMems.freeMems_len == 0)
 +if (ret-freeMems.freeMems_len == 0) {
 +VIR_FREE(ret-freeMems.freeMems_val);
  return -1;
 +}
  
and memleaks ...

 diff -r 06acc2c5c1fb src/memory.c
 --- a/src/memory.cThu May 29 16:05:55 2008 -0400
 +++ b/src/memory.cFri May 30 10:36:42 2008 -0400
 @@ -104,7 +104,7 @@
   *
   * Returns -1 on failure to allocate, zero on success
   */
 -int virAlloc(void *ptrptr, size_t size)
 +int __virAlloc(void *ptrptr, size_t size)
  {
  #if TEST_OOM
  if (virAllocTestFail()) {
 @@ -137,7 +137,7 @@
   *
   * Returns -1 on failure to allocate, zero on success
   */
 -int virAllocN(void *ptrptr, size_t size, size_t count)
 +int __virAllocN(void *ptrptr, size_t size, size_t count)
  {
  #if TEST_OOM
  if (virAllocTestFail()) {
 @@ -171,7 +171,7 @@
   *
   * Returns -1 on failure to allocate, zero on success
   */
 -int virReallocN(void *ptrptr, size_t size, size_t count)
 +int __virReallocN(void *ptrptr, size_t size, size_t count)
  {
  void *tmp;
  #if TEST_OOM
 @@ -203,7 +203,7 @@
   * the 'ptrptr' variable. After release, 'ptrptr' will be
   * updated to point to NULL.
   */
 -void virFree(void *ptrptr)
 +void __virFree(void *ptrptr)
  {
  free(*(void**)ptrptr);
  *(void**)ptrptr = NULL;
 diff -r 06acc2c5c1fb src/memory.h
 --- a/src/memory.hThu May 29 16:05:55 2008 -0400
 +++ b/src/memory.hFri May 30 10:36:42 2008 -0400
 @@ -26,10 +26,10 @@
  #include internal.h
  
  /* Don't call these directly - use the macros below */
 -int virAlloc(void *ptrptr, size_t size) ATTRIBUTE_RETURN_CHECK;
 -int virAllocN(void *ptrptr, size_t size, size_t count) 
 ATTRIBUTE_RETURN_CHECK;
 -int virReallocN(void *ptrptr, size_t size, size_t count) 
 ATTRIBUTE_RETURN_CHECK;
 -void virFree(void *ptrptr);
 +int __virAlloc(void *ptrptr, size_t size) ATTRIBUTE_RETURN_CHECK;
 +int __virAllocN(void *ptrptr, size_t size, size_t count) 
 ATTRIBUTE_RETURN_CHECK;
 +int __virReallocN(void *ptrptr, size_t size, size_t count) 
 ATTRIBUTE_RETURN_CHECK;
 +void __virFree(void *ptrptr);
  
  /**
   * VIR_ALLOC:
 @@ -41,7 +41,7 @@
   *
   * Returns -1 on failure, 0 on success
   */
 -#define VIR_ALLOC(ptr) virAlloc((ptr), sizeof(*(ptr)))
 +#define VIR_ALLOC(ptr) __virAlloc((ptr), sizeof(*(ptr)))
  
  /**
   * VIR_ALLOC_N:
 @@ -54,7 +54,7 @@
   *
   * Returns -1 on failure, 0 on success
   */
 -#define VIR_ALLOC_N(ptr, count) virAllocN((ptr), sizeof(*(ptr)), (count))
 +#define VIR_ALLOC_N(ptr, count) __virAllocN((ptr), sizeof(*(ptr)), (count))
  
  /**
   * VIR_REALLOC_N:
 @@ -67,7 +67,7 @@
   *
   * Returns -1 on failure, 0 on success
   */
 -#define VIR_REALLOC_N(ptr, count) virReallocN((ptr), sizeof(*(ptr)), 
 (count))
 +#define VIR_REALLOC_N(ptr, count) __virReallocN((ptr), sizeof(*(ptr)), 
 (count))
  
  /**
   * VIR_FREE:
 @@ -76,7 +76,7 @@
   * Free the memory stored in 'ptr' and update to point
   * to NULL.
   */
 -#define VIR_FREE(ptr) virFree((ptr));
 +#define VIR_FREE(ptr) __virFree((ptr))

  ah, right we need to export those symbols now ...

   looks good to me, +1

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard  | virtualization library  http://libvirt.org/
[EMAIL PROTECTED]  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] PATCH: Switch all remaining code to memory alloc APIs

2008-05-30 Thread Daniel Veillard

On Fri, May 30, 2008 at 04:01:39PM +0100, Daniel P. Berrange wrote:
 This patch switches all remaining code over to use the memory allocation
 APIs, with exception of virsh which is going to be slightly more complex
 
 It was mostly a straight conversion - there were only a few places which 
 weren't checking for failure corecttly - the most notable being sexpr.c.
[...]
 -void *stack, *stacktop;
 +char *stack, *stacktop;
  
  /* allocate a stack for the container */
 -stack = malloc(stacksize);
 -if (!stack) {
 +if (VIR_ALLOC_N(stack, stacksize)  0) {

  hum, interesting side effect ... we must type stuff with the new macros.

[...]
 --- a/src/openvz_driver.c Fri May 30 10:36:42 2008 -0400
 +++ b/src/openvz_driver.c Fri May 30 10:55:44 2008 -0400
 @@ -49,8 +49,7 @@
  #include stdio.h
  #include sys/wait.h
  
 -#include libvirt/virterror.h
 -
 +#include internal.h

  a bit of cleanup there too.

[...]
 -static void
 +static int
  append(struct sexpr *lst, const struct sexpr *value)
  {

  okay, the sexpr code really needed to be changed, good !

 diff -r ff6b92c70738 src/xen_internal.c
 --- a/src/xen_internal.c  Fri May 30 10:36:42 2008 -0400
 +++ b/src/xen_internal.c  Fri May 30 10:55:44 2008 -0400
...
 @@ -1659,8 +1659,7 @@
  /* The allocated memory to cpumap must be 'sizeof(uint64_t)' byte *
   * for Xen, and also nr_cpus must be 'sizeof(uint64_t) * 8'   */
  if (maplen  8) {
 -new = calloc(1, sizeof(uint64_t));
 -if (!new) {
 +if (VIR_ALLOC_N(new, sizeof(uint64_t))  0) {

  That one worried me, but that works but because we have unsigned char *new

 --- a/src/xmlrpc.cFri May 30 10:36:42 2008 -0400
 +++ b/src/xmlrpc.cFri May 30 10:55:44 2008 -0400
 @@ -12,6 +12,7 @@

  Hum, i think that's dead code anyway, no ?

  #include xmlrpc.h
  #include internal.h
 +#include memory.h
  
  #include libxml/nanohttp.h
  
 @@ -47,9 +48,8 @@
  
  static xmlRpcValuePtr xmlRpcValueNew(xmlRpcValueType type)
  {
 -xmlRpcValuePtr ret = malloc(sizeof(*ret));
 -
 -if (!ret)
 +xmlRpcValuePtr ret = NULL;
 +if (VIR_ALLOC(ret)  0)

  I don't think we need to set ret to NULL, do we ? VIR_ALLOC always
initialize.


  Okay I think I really read all the patch and tried to check everything :-)

looks good, thanks a lot !

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard  | virtualization library  http://libvirt.org/
[EMAIL PROTECTED]  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 3/4] lxc: validate container process during load config

2008-05-30 Thread Dave Leskovec

Daniel P. Berrange wrote:
 On Fri, May 30, 2008 at 02:28:46AM -0400, Daniel Veillard wrote:
 On Thu, May 29, 2008 at 03:20:15PM -0700, Dave Leskovec wrote:
 +if (ESRCH == errno) {
 +rc = 0;
 +DEBUG(pid %d no longer exists, def-id);
 +goto done;
 +}
 +
 +lxcError(NULL, NULL, VIR_ERR_INTERNAL_ERROR,
 + _(error checking container process: %d %s),
 + def-id, strerror(errno));
 +goto done;
 +}
   The problem though is that by doing just  a passive test for the PID
 it feels like there is a possible race if the process counter rolled over and
 another process with the same PID got create in the meantime.
   i have the feeling that a test based on the state of the file descriptors
 used to communicate with the container would be more reliable. Basically if 
 the
 container disapear, then the pipe should get in a half-closed state, 
 detecting the change at that level sounds like it would be more reliable,
 don't you think so ?
 
 Yes, after checking the PID still exists, it needs to validate /proc/$PID/exe
 to verify it points to the binary we expect it to.

Hmmm  Worked with this a bit and I don't think we can reliably know what to
expect /proc/$PID/exe to point to.  For scripts, /proc/$PID/exe seems to point
the shell.  Also, if the container does an exec, /proc/$PID/exe points to
whatever it exec'd rather than the init program.

There currently isn't pipe into the container although one may be added as part
of the network support for other reasons.  My concern there is that if something
has happened that we're not getting SIGCHLD from exiting containers, wouldn't we
have lost the pipe as well?

-- 
Best Regards,
Dave Leskovec
IBM Linux Technology Center
Open Virtualization

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [Fwd: Re: [Xen-API] Retrieving XEN Server available and XEN memory]

2008-05-30 Thread Stefan de Konink


Can we use this for libvirt too? (Free memory for Xen)


Stefan
---BeginMessage---

Thanks for the quick response.  

-Original Message-
From: Roger R. Smith [mailto:[EMAIL PROTECTED] 
Sent: Friday, May 30, 2008 2:33 PM
To: Caruso, Joseph
Cc: [EMAIL PROTECTED]
Subject: Re: [Xen-API] Retrieving XEN Server available and XEN memory

Hi Joseph you can do something like this:

$guestRef = VM.get_guest_metrics($vmRef);
$getMet = VM_guest_metrics.get_record($guestRef);

$getMet['memory']['free']
$getMet['memory']['total']

Hope that helps.
-Rog

On Fri, May 30, 2008 at 1:32 PM, Caruso, Joseph
[EMAIL PROTECTED] wrote:
 Hello,



 Does anyone know how to retrieve either the amount of available server
 memory (not the total) or the amount of memory used by Xen? Using
the
 host metrics object I able to retrieve both the total and free server
 memory.   The Xen Center (see General tab)  memory section displays:



  Server:Sun-STZENS1:   1.7 GB free of 3.7 GB available
(4.0GB
 total)



  VMs:





  Xen:336.1 MB





 I want to retrieve the underlined values via the API.



 Thanks,
 Joe



 ___
 xen-api mailing list
 [EMAIL PROTECTED]
 http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api



___
xen-api mailing list
[EMAIL PROTECTED]
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

---End Message---
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 3/4] lxc: validate container process during load config

2008-05-30 Thread Daniel P. Berrange

On Fri, May 30, 2008 at 11:40:00AM -0700, Dave Leskovec wrote:
 Daniel P. Berrange wrote:
  On Fri, May 30, 2008 at 02:28:46AM -0400, Daniel Veillard wrote:
  On Thu, May 29, 2008 at 03:20:15PM -0700, Dave Leskovec wrote:
  +if (ESRCH == errno) {
  +rc = 0;
  +DEBUG(pid %d no longer exists, def-id);
  +goto done;
  +}
  +
  +lxcError(NULL, NULL, VIR_ERR_INTERNAL_ERROR,
  + _(error checking container process: %d %s),
  + def-id, strerror(errno));
  +goto done;
  +}
The problem though is that by doing just  a passive test for the PID
  it feels like there is a possible race if the process counter rolled over 
  and
  another process with the same PID got create in the meantime.
i have the feeling that a test based on the state of the file descriptors
  used to communicate with the container would be more reliable. Basically 
  if the
  container disapear, then the pipe should get in a half-closed state, 
  detecting the change at that level sounds like it would be more reliable,
  don't you think so ?
  
  Yes, after checking the PID still exists, it needs to validate 
  /proc/$PID/exe
  to verify it points to the binary we expect it to.
 
 Hmmm  Worked with this a bit and I don't think we can reliably know what 
 to
 expect /proc/$PID/exe to point to.  For scripts, /proc/$PID/exe seems to point
 the shell.  Also, if the container does an exec, /proc/$PID/exe points to
 whatever it exec'd rather than the init program.

Well the path won't change once launched, so why not store the original
value of /proc/$PID/exe in the /var/lib/libivrt/lxc/NAME.pid  file too,
so you can read it back out later  validate.

Dan.
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 3/4] lxc: validate container process during load config

2008-05-30 Thread Dave Leskovec

Daniel P. Berrange wrote:
 On Fri, May 30, 2008 at 11:40:00AM -0700, Dave Leskovec wrote:
 Daniel P. Berrange wrote:
 On Fri, May 30, 2008 at 02:28:46AM -0400, Daniel Veillard wrote:
 On Thu, May 29, 2008 at 03:20:15PM -0700, Dave Leskovec wrote:
 +if (ESRCH == errno) {
 +rc = 0;
 +DEBUG(pid %d no longer exists, def-id);
 +goto done;
 +}
 +
 +lxcError(NULL, NULL, VIR_ERR_INTERNAL_ERROR,
 + _(error checking container process: %d %s),
 + def-id, strerror(errno));
 +goto done;
 +}
   The problem though is that by doing just  a passive test for the PID
 it feels like there is a possible race if the process counter rolled over 
 and
 another process with the same PID got create in the meantime.
   i have the feeling that a test based on the state of the file descriptors
 used to communicate with the container would be more reliable. Basically 
 if the
 container disapear, then the pipe should get in a half-closed state, 
 detecting the change at that level sounds like it would be more reliable,
 don't you think so ?
 Yes, after checking the PID still exists, it needs to validate 
 /proc/$PID/exe
 to verify it points to the binary we expect it to.
 Hmmm  Worked with this a bit and I don't think we can reliably know what 
 to
 expect /proc/$PID/exe to point to.  For scripts, /proc/$PID/exe seems to 
 point
 the shell.  Also, if the container does an exec, /proc/$PID/exe points to
 whatever it exec'd rather than the init program.
 
 Well the path won't change once launched, so why not store the original
 value of /proc/$PID/exe in the /var/lib/libivrt/lxc/NAME.pid  file too,
 so you can read it back out later  validate.

AFAIK there's nothing restricting /proc/$PID/exe from changing for valid reasons
between the time it was stored and the time it's checked.  Say we store it right
after launching the container.  How do we know that we didn't happen to store it
right before an exec?  Take a simple container with an init that performs some
setup maybe of the network that takes an indeterminate amount of time.  It then
exec's sshd or apache.  If the value was stored right after the container was
started, it would no longer be valid after the exec.

-- 
Best Regards,
Dave Leskovec
IBM Linux Technology Center
Open Virtualization

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 4/4] lxc: store tty pid

2008-05-30 Thread Dave Leskovec

Daniel Veillard wrote:
 On Thu, May 29, 2008 at 03:44:24PM -0700, Dave Leskovec wrote:
...
 
   Hum, I'm surprized the PID file is removed only in lxcDomainUndefine.
 The PID file need to be re-created each time the domain is started. But
 a domain could be started and stopped many time while being defined,
 what happen in a (define/start/stop/start) sequence ? Looks to me the
 O_CREAT flag in the second start would break because the PID file is still
 here ...
 
   Maybe I'm just wrong but if you could just double check that scenario before
 the commit, that would be nice :-)
 
 Daniel
 

O_CREAT just causes the file to be created if it doesn't exist.  O_EXCL will
trigger an error if the file already exists.

I'd considered removing it after killing the tty process but don't recall now
why I didn't do that.  I think it makes sense to do that so I'll make the change
with the ones from Jim and Dan.

Thanks!

-- 
Best Regards,
Dave Leskovec
IBM Linux Technology Center
Open Virtualization

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 1/4] lxc: validate tty pid before kill()

Re: [libvirt] [PATCH 4/4] lxc: store tty pid

[libvirt] Re: AW: AW: [et-mgmt-tools] ocaml-libvirt-0.4.0.1: Can't connect toXen-Host

RE: [libvirt] ocaml-libvirt-0.4.0.1: Can'tconnect toXen-Host

[libvirt] [PATCH] Add error message when the invalid XML file is defined.

Re: [libvirt] [PATCH 4/4] lxc: store tty pid

Re: [libvirt] ocaml-libvirt-0.4.0.1: Can'tconnect toXen-Host

AW: [libvirt] ocaml-libvirt-0.4.0.1: Can'tconnect toXen-Host

Re: [libvirt] [PATCH 4/4] lxc: store tty pid

Re: [libvirt] [PATCH 3/4] lxc: validate container process during load config

[libvirt] PATCH: Switch remote daemon to use memory alloc APIs

Re: [libvirt] PATCH: Switch remote daemon to use memory alloc APIs

Re: [libvirt] PATCH: Switch all remaining code to memory alloc APIs

Re: [libvirt] [PATCH 3/4] lxc: validate container process during load config

[libvirt] [Fwd: Re: [Xen-API] Retrieving XEN Server available and XEN memory]

Re: [libvirt] [PATCH 3/4] lxc: validate container process during load config

Re: [libvirt] [PATCH 3/4] lxc: validate container process during load config

Re: [libvirt] [PATCH 4/4] lxc: store tty pid

18 matches

Site Navigation

Mail list logo

Footer information