headers
Takahashi Tomohiro | 2 May 10:39
Favicon

Re: [PATCH][virt-manager] Enable "Printscreen" toGuestOS from Virtual Machine console menu.

Hi,

Would you give me a comment on this virt-manager key-fixation patch?
If not, Please commit it.

Thanks
Tomohiro Takahashi

> Hi,
> 
> Virtual Machine Console can not send
> "Printscreen" to GuestOS from menu [Send key]-[Printscreen].
> 
> This patch fix this issue.
> 
> And I checked that the others [Send key] has not a problem.
> 
> Signed-off-by: Tomohiro Takahashi <takatom@...>
> 
> Thanks,
> Tomohiro Takahashi
>
Permalink | Reply | 1 comment |
headers
Daniel P. Berrange | 2 May 15:36
Picon
Favicon

Re: [PATCH][virt-manager] Enable "Printscreen" toGuestOS from Virtual Machine console menu.

On Fri, May 02, 2008 at 05:39:41PM +0900, Takahashi Tomohiro wrote:
> Hi,
> 
> Would you give me a comment on this virt-manager key-fixation patch?
> If not, Please commit it.

Sorry I missed this patch - it is comitted now.

Regards,
Daniel.
--

-- 
|: 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 :|
Permalink | Reply | 0 comments |
headers
Daniel P. Berrange | 2 May 15:40
Picon
Favicon

Re: [et-mgmt-tools] [RFE] virtual networks without DHCP

On Mon, Apr 28, 2008 at 08:52:12AM +0100, Richard W.M. Jones wrote:
> On Sun, Apr 27, 2008 at 02:57:54PM +0200, Geert Jansen wrote:
> > I think it would be nice if it were possible to create a virtual network 
> > with virt-manager without DHCP and DNS services. This is useful when you 
> > want to use a host-only network for testing a setup that includes a DHCP 
> > server.
> >
> > I am not sure whether this is a limitation in virt-manager or in libvirt.
> 
> It's a libvirt thing.  Replies redirected to libvir-list.
> 
> My understanding is that if the network doesn't contain a <ip...>
> element in the network XML then no DHCP server will be created.
> 
>   http://libvirt.org/formatnetwork.html

As Rich mentions, this is already supported in libvirt - simply omit
the <dhcp> tag. This is not exposed in the virt-manager UI though - it
always requires DHCP, so you'll need to use the command line to configure
this.

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 :|
Permalink | Reply | 0 comments |
headers
Michael DeHaan | 2 May 16:29
Picon
Favicon

Installing without PXE, and without the live CD -- "cobbler buildiso"

For a while Cobbler has had a solution based on koan and the live CD to 
enable network provisioning of bare metal in environments that either do 
not have DHCP, or do not have control over DHCP that is sufficient 
enough to set up a PXE environment.  Naturally, if you can set up a PXE 
environment with Cobbler, it's very useful to have, and you'll want it.

So, along came the live CD.

The live CD was built using a recent Fedora, and it had the magic 
ability to install any distro -- /except/ you had to use Fedora to build 
the Live CD, and the build process was slow, and the live image was a 
bit bigger than it needed to be.   However, due to driver constraints, 
it didn't always support the latest in storage technology -- that was a 
problem.

We have finally implemented the low-tech solution, thanks to various 
folks in Red Hat GPS, and some hacking I've done to integrate that 
closer into cobbler.

Using 0.9.X or later (it's checked in now into the git "devel" branch) 
you can do:

    cobbler buildiso [--iso=] [--tempdir=] [--profiles=]

This will automatically generate an ISO that allows for menus just like 
Cobbler's PXE boot menus, for installing new systems.  I also plan to 
allow a configurable default profile for those who want to mass deploy 
this image using remote management processors, etc.

The menu will contain an entry for each bare metal bootable profile,
(Continue reading)

Permalink | Reply | 7 comments |
headers
Michael DeHaan | 2 May 17:09
Picon
Favicon

Do you use cobbler's support for dnsmasq?

With John Eckersberg's recent patch (and likely future extensions), 
Cobbler will be acquiring very good support for bind, so Cobbler can 
manage DHCP and DNS at the same time using more scalable tools.     
Similarly, we can now manage DHCP without restarts (Pablo Iranzo Gomez's 
patch).    So then, I'm wondering what are the reasons we would have for 
continuing to support dnsmasq?

If you would be affected by removal of dnsmasq support, I'd like to hear 
from you, as to why you would like it to stay in place.   This does not 
neccessarily eliminate the ability to have seperate options in Cobbler 
for (more modular) DHCP/DNS choices in the future.  (Likely this is 
something we could use /etc/cobbler/modules.conf for).

--Michael
Permalink | Reply | 10 comments |
headers
Matt Hyclak | 2 May 17:13

Re: Do you use cobbler's support for dnsmasq?

On Fri, May 02, 2008 at 11:09:34AM -0400, Michael DeHaan enlightened us:
> With John Eckersberg's recent patch (and likely future extensions), 
> Cobbler will be acquiring very good support for bind, so Cobbler can 
> manage DHCP and DNS at the same time using more scalable tools.     
> Similarly, we can now manage DHCP without restarts (Pablo Iranzo Gomez's 
> patch).    So then, I'm wondering what are the reasons we would have for 
> continuing to support dnsmasq?
> 
> If you would be affected by removal of dnsmasq support, I'd like to hear 
> from you, as to why you would like it to stay in place.   This does not 
> neccessarily eliminate the ability to have seperate options in Cobbler 
> for (more modular) DHCP/DNS choices in the future.  (Likely this is 
> something we could use /etc/cobbler/modules.conf for).
> 

I use dnsmasq to handle the DNS for my internal server network and let
cobbler manage it. Saves me headache.

I have used bind before, and if the support is there I could probably make
the switch back, but I'd recommend getting it in for lots of testing before
removing dnsmasq support.

Matt

--

-- 
Matt Hyclak
Department of Mathematics 
Department of Social Work
Ohio University
(740) 593-1263
(Continue reading)

Permalink | Reply | 4 comments |
headers
John Eckersberg | 2 May 17:35
Picon
Favicon

Re: [PATCH] BIND DNS support


John Eckersberg wrote:
| Stephen John Smoogen wrote:
| | On Mon, Apr 28, 2008 at 8:58 AM, John Eckersberg <jeckersb@...>
| wrote:
| |> -----BEGIN PGP SIGNED MESSAGE-----
| |>  Hash: SHA1
| |>
| |>  Working well but probably needs a bit more cleanup...
| |>
| |
| | Well a 0 length patch usually works well. What are you wanting to
| | patch it against?
| |
| |
| |>  Patches to my patch are welcome :)
| |>
| |>  - --
| |>  John Eckersberg
| |>  Production Operations
| |>  Red Hat, Inc.
| |>
| |>

This is an updated patch:

http://jeckersb.fedorapeople.org/cobbler/0001-BIND-dns-support.patch

Which does two things:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael DeHaan | 2 May 17:54
Picon
Favicon

Re: Do you use cobbler's support for dnsmasq?

Matt Hyclak wrote:
> On Fri, May 02, 2008 at 11:09:34AM -0400, Michael DeHaan enlightened us:
>   
>> With John Eckersberg's recent patch (and likely future extensions), 
>> Cobbler will be acquiring very good support for bind, so Cobbler can 
>> manage DHCP and DNS at the same time using more scalable tools.     
>> Similarly, we can now manage DHCP without restarts (Pablo Iranzo Gomez's 
>> patch).    So then, I'm wondering what are the reasons we would have for 
>> continuing to support dnsmasq?
>>
>> If you would be affected by removal of dnsmasq support, I'd like to hear 
>> from you, as to why you would like it to stay in place.   This does not 
>> neccessarily eliminate the ability to have seperate options in Cobbler 
>> for (more modular) DHCP/DNS choices in the future.  (Likely this is 
>> something we could use /etc/cobbler/modules.conf for).
>>
>>     
>
> I use dnsmasq to handle the DNS for my internal server network and let
> cobbler manage it. Saves me headache.
>
> I have used bind before, and if the support is there I could probably make
> the switch back, but I'd recommend getting it in for lots of testing before
> removing dnsmasq support.
>
> Matt
>
>   

One idea that came up on IRC and that I've been thinking about is to use
(Continue reading)

Permalink | Reply | 3 comments |
headers
Michael DeHaan | 2 May 17:59
Picon
Favicon

Re: [PATCH] BIND DNS support

John Eckersberg wrote:

Applied and very cool!

I'm going to be working on integrating this into 
/etc/cobbler/modules.conf so don't be too alarmed if the code moves
around slightly.

Thanks!

--Michael

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> John Eckersberg wrote:
> | Stephen John Smoogen wrote:
> | | On Mon, Apr 28, 2008 at 8:58 AM, John Eckersberg 
> <jeckersb@...>
> | wrote:
> | |> -----BEGIN PGP SIGNED MESSAGE-----
> | |>  Hash: SHA1
> | |>
> | |>  Working well but probably needs a bit more cleanup...
> | |>
> | |
> | | Well a 0 length patch usually works well. What are you wanting to
> | | patch it against?
> | |
> | |
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael DeHaan | 2 May 18:00
Picon
Favicon

Re: Cobbler patch OMAPI v2 ;)

Pablo Iranzo Gómez wrote:
> 	Morning!
>
> El mar, 29-04-2008 a las 22:27 -0400, Michael DeHaan escribió:
>   

Applied to devel branch.    As with John's patch, I'm going to be 
working on moving this around
into the 'modules' directory, though this is very good to see.   Thanks!

--Michael

>> Should be applied Thursday or so barring any other comments, and that 
>> will make this easier for people to test.   I also need to do a test 
>> release for 0.9 soon (let's call this 0.9.1 ... there will be more test 
>> releases with some other features likely being added prior to the 1.0).
>>     
>
> 	Count with me for the beta-testing :)
>
>
>   
>> Quick question -- Should omapi in settings be off by default?  It only 
>> works with modifications to the dhcp.template to enable it -- though we 
>> /could/ enable that by default in the template and solve the problem.
>>     
>
> 	For me, as cobbler is rewriting dhcp info, should be enabled by
> default. This could need another check for the code I submitted
> yesterday to check if "manage dhcp is enabled for isc".
(Continue reading)

Permalink | Reply | 0 comments |

Gmane