headers
Aaron Lippold | 1 Jul 23:56
Picon

Revisor / Cobbler and Revisor for CentOS5/RHEL5

Hi Mike,

I just wanted to let you know that the Revisor folks are very
interested in an integration / partnership with Cobbler. They said,
"we well * definitely * be putting cobbler integration into Revisor
2.1.x..." .

Did the Revisor folks email you at all?

Also, I was just wondering if your team has talked about putting a Web
Service - or web-ish system stuff - interface onto Cobbler given its
Enterprise scale? Just a thought. ( I have lots of those :) )

Yours,

Aaron
Permalink | Reply | 11 comments |
headers
Saori Fukuta | 2 Jul 11:29
Favicon

[PATCH] can not specify the type of driver device

Hi,

I opened the new bugzilla:
  Bugzilla Bug 246441: can not specify the type of driver device
  URL: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246441

And I attached the patch to fix this problem.

Thanks,
Saori Fukuta
Permalink | Reply | 5 comments |
headers
Nobuhiro Itou | 2 Jul 12:58

Re: Re: About keeping the cdrom in the permanent XMLfor a guest after install

Hi, Hugh and Dan

> > Hi there.
> > 
> > I still prefer the idea of leaving the CDROM mounted because the 
> > heuristic we use to determine if a Windows guest is being installed is a 
> > big hack, and because we don't use that code at all in virt-manager and 
> > I would like the cdrom to stay mounted by default in virt-manager 
> > installs as well.
> > 
> > However, if the earlier behavior is useful to anyone, I'd be happy to 
> > take a patch for a virtinst argument that would direct virtinst not to 
> > include the cdrom device in the post-install guest description.
> 
> How about leaving the CDROM device itself always attached, but not having
> any file (media) associated with it. That would keep the simplicity of
> always doing the same config for all OS, while still allowing people to
> use  'xm block-configure' for Windows guests to add the CDROM again.

The above-mentioned idea just corresponds to the state before correction.
Although Windows may be unique compared with other OS's,
the user can enough continue installation by using xm block-configure.

> On a side note, we really need a 'xm block-configure' equivalent API in
> libvirt, so that we can do CDROM media changes from the virt-manager GUI
> and virsh, for both KVM & Xen.

I think so, too.

Thanks,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael DeHaan | 2 Jul 16:52
Picon
Favicon

Re: Getting started with cobbler

drew einhorn wrote:
> Set up my first cobbler server.
>
> Tried my first PXE boot.
>
> After a brief burst of activity the PXE boot dies complaining about a
> tftp open timeout.
>
> Took a look at the network traffic using wireshark.
>
> I see what appears to be normal RARP/ARP/DHCP traffic where the host 
> doing the
> PXE boot gets an IP number, etc.
>
> The host then sends the server a:
> TFTP read request for /pxelinux.0
>
> The server immediately replies with
> ICMP
> Type 3 (Destination Unreachable)
> Code 10 (Host Administratievely prohibited)
>
> Have not found any other error messages etc.
>
> Found the archives for this list but as far as I can tell they are not
> searchable.
>
If it's not a firewall/network configuration problem, the other 
possibility I could think of
would be the content for /tftpboot isn't labelled properly for SELinux,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael DeHaan | 2 Jul 16:52
Picon
Favicon

Re: Re: Getting started with cobbler

drew einhorn wrote:
> Figured out the answers to my questions.
>
> The server is a CentOS5 box and I needed to add some rules to
> the default firewall settings.
Ah, good deal ... I should have read the rest of my email before replying :)

>
> And there is a searchable archive of this list at
> http://dir.gmane.org/gmane.linux.redhat.et-mgmt-tools
>
> On 6/29/07, drew einhorn <drew.einhorn@...> wrote:
>> Set up my first cobbler server.
>>
>> Tried my first PXE boot.
>>
>> After a brief burst of activity the PXE boot dies complaining about a
>> tftp open timeout.
>>
>> Took a look at the network traffic using wireshark.
>>
>> I see what appears to be normal RARP/ARP/DHCP traffic where the host 
>> doing the
>> PXE boot gets an IP number, etc.
>>
>> The host then sends the server a:
>> TFTP read request for /pxelinux.0
>>
>> The server immediately replies with
>> ICMP
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael DeHaan | 2 Jul 16:56
Picon
Favicon

Re: Re: Getting started with cobbler

drew einhorn wrote:
> Next problem.
>
> Now that I have the the firewall fixed to allow incomining tftp 
> requests for the PXE boot.
> Things perk along for a while, then it tries to get the kickstart file 
> from
>
>   http://<server-ip>/cblr/kickstarts_sys/<client-MAC>/ks.cfg
>
> Ok, add one more rule to the firewall config.
>
> Oops, there's no http server running on the server.

"cobbler check" (see also: manpage) can be used to detect basic problems 
in a server configuration, however it doesn't check
for service start/stop states.   This is something that can be added to 
the TODO list.   Not a bad idea :)

Examining the firewall configuration may also prove interesting.

--Michael

>
> On 6/29/07, *drew einhorn* < drew.einhorn@... 
> <mailto:drew.einhorn@...>> wrote:
>
>     Figured out the answers to my questions.
>
>     The server is a CentOS5 box and I needed to add some rules to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael DeHaan | 2 Jul 17:14
Picon
Favicon

Re: Revisor / Cobbler and Revisor for CentOS5/RHEL5

Aaron Lippold wrote:
> Hi Mike,
>
> I just wanted to let you know that the Revisor folks are very
> interested in an integration / partnership with Cobbler. They said,
> "we well * definitely * be putting cobbler integration into Revisor
> 2.1.x..." .
>
> Did the Revisor folks email you at all?

This is the first I've heard of it, though I'll definitely ping them.   
Neat.

>
> Also, I was just wondering if your team has talked about putting a Web
> Service - or web-ish system stuff - interface onto Cobbler given its
> Enterprise scale? Just a thought. ( I have lots of those :) )

Ideally the FOSS community is the team :)

To answer the question -- Cobbler is being used as the provisioning 
backend behind virt-factory (http://virt-factory.et.redhat.com) -- which 
has a Web UI --
though cobbler itself doesn't have it's own WebUI yet.   To be clear, 
virt-factory is somewhat specialized, so it doesn't fill the same niche, 
and uses only
a subset of cobbler features.  A couple of folks have expressed interest 
in doing a WUI for Cobbler before, though I don't believe anyone is 
actively pursuing it.   
I'd like one, though mostly I've been concentrating on the backend and
(Continue reading)

Permalink | Reply | 10 comments |
headers
Michael DeHaan | 2 Jul 17:33
Picon
Favicon

Re: VMware?

drew einhorn wrote:
> Cobbler / Koan supports Xen virtualization.
>
> Has anyone looked at what it would take to get koan working
> on other virtualization platforms?  I have a VMware ESX box
> I'd like to be able to use it on.
>

Not to my knowledge -- though I like the idea.  

As far as I'm aware, vmware does understand PXE installation, so koan 
would just need a way to create an "empty" guest
that would PXE itself.   I know this is the plan for how we're going to 
support fully automatic installs for other
virtualization types like KVM, Xen hardware virt, etc.

If there are any VMware experts on the list, patches would be great :)

It seems like the syntax needed would not need to even access the 
cobbler server the way --virt does today, ex:

koan --virt --virt-type=vmware --mac=AA:BB:CC:DD:EE:FF --virt-name=foo 
[...other options...]

--virt-type could default to "xenparavirt" and current behavior.

--Michael
Permalink | Reply | 5 comments |
headers
Richard W.M. Jones | 2 Jul 17:38
Picon
Favicon

Proposal: libvirt should remove or rename a save file after a successful restore

Chris Lalancette found this problem:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246105

<quote>
Once an "xm restore" has successfully completed, the -save file that it 
came from should really be deleted.  Restoring a domain a second time 
from the same save file will result in disk corruption; the kernel VM 
state (in the saved file) will be in an inconsistent state with respect 
to what is actually on disk (in the domain disk file).  The only valid 
use I can see for the -save file after a restore is possibly for some 
crash analysis, but even that could be worked around by renaming the 
save file after a success.  In particular, I just ran into this 
situation (and I'm worried customers might do the same):
[and then he goes on to describe a scenario in which you can commonly 
hit this situation]
</quote>

So the obvious and simple solution, it seems to me, is just to change 
libvirt.c:virDomainRestore so that if the driver underneath it returns 
from the restore without error, then we either remove or rename the 
restore file.

It's a trivial patch -- what do people think?

My thoughts:
* Removing the file might seem quite abrupt/unexpected, and there is the 
possibility of data loss.
* You have to rename the file as a hidden file (dotfile) in order for 
xendomains to ignore it.  However these files are big and having large,
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Levon | 2 Jul 17:48
Favicon
Gravatar

Re: Proposal: libvirt should remove or rename a save file after a successful restore

On Mon, Jul 02, 2007 at 04:38:48PM +0100, Richard W.M. Jones wrote:

> So the obvious and simple solution, it seems to me, is just to change 
> libvirt.c:virDomainRestore so that if the driver underneath it returns 
> from the restore without error, then we either remove or rename the 
> restore file.
> 
> It's a trivial patch -- what do people think?

This is not correct as it assumes that the filesystem(s) cannot be rolled
back to the state corresponding to that known by the saved domain.

regards
john
Permalink | Reply | 0 comments |

Gmane